本文最后更新于 2026-08-05，文章内容可能已经过时。

AI 做得很完整，却完全不是你要的：一套“先问清楚再动手”的 Prompt 方法

你只想让 AI 改一下按钮颜色，它顺手重构了整个页面；你让它写一篇产品介绍，它输出了一篇看似专业、却无法发布的行业报告。

最麻烦的不是 AI 不会做，而是它太积极——还没问清楚，就已经做完了。

很多人的解决办法，是把 Prompt 越写越长：补背景、加限制、列格式，最后像写合同一样写了几百字。可现实是，我们自己也未必能在开始时想清全部细节。

更有效的方法，是为 AI 增加一道“需求检查”：

先识别信息缺口，再提出关键问题，确认后才执行。

这不是让 AI 变得啰嗦，而是把它从“猜需求的执行者”，变成“会做需求澄清的搭档”。

为什么 AI 越“听话”，有时错得越离谱

常见翻车通常发生在三个地方：

产品方案：文档结构完整、功能丰富，却服务了错误的用户。
代码修改：代码能运行，却改变了返回字段，导致旧客户端无法兼容。
内容写作：文章语言流畅，却不符合发布渠道和品牌语气。

它们的共同问题并不是模型能力不足，而是输入缺少了目标、边界、上下文或验收标准。

例如“帮我优化登录接口”，至少存在三种完全不同的理解：

1. 降低接口延迟；

2. 修复登录安全问题；

3. 重构代码，提高可维护性。

如果用户没有说明，AI 往往会自行选择一种解释，并继续补齐技术栈、兼容策略和修改范围。结果越完整，返工成本反而越高。

因此，高质量 Prompt 不应只规定“怎么执行”，还应告诉 AI：

什么情况下信息不足；
哪些问题必须确认；
哪些细节可以采用默认值；
什么时候才能开始执行。

但澄清也不能变成“无限反问”。改一句标题，不需要做用户调研；修改生产数据库，则不能依赖猜测。真正需要询问的，是那些答案不同、会显著改变结果的问题。

普通 Prompt 与澄清式 Prompt，有什么不同

普通方式：
模糊需求 → AI 自动假设 → 直接执行 → 结果偏差 → 多轮返工

澄清方式：
初始需求 → 识别信息缺口 → 提出关键问题
→ 用户确认 → 总结约束 → 执行 → 按标准验收

澄清式工作流并不一定减少对话轮次，但它能把沟通放在成本更低的阶段：先花一分钟确认方向，而不是等结果全部生成后推倒重来。

一套可以直接复制的通用模板

在开始执行前，请先不要直接给出最终结果。

请先完成以下步骤：
1. 用一句话复述你理解的任务目标。
2. 找出当前信息中可能影响结果的缺失项、歧义或隐含假设。
3. 只提出最关键的 3—5 个澄清问题，并按重要性排序。
4. 区分哪些问题“必须由我确认”，哪些可以由你采用合理默认值。
5. 如果信息已经足够，请明确说明“无需继续澄清”，然后给出执行计划。
6. 得到我的回答后，先总结双方已确认的要求，再开始执行。

如果我回复“你来决定”，请列出你采用的假设，然后继续完成任务。
不要为了提问而提问，也不要重复询问我已经提供的信息。

这段模板包含六个关键动作：

复述目标：检查双方是否在解决同一个问题。
识别歧义：找出 AI 准备偷偷“脑补”的部分。
问题排序：先问会改变整体方向的问题。
限制数量：避免一次抛出十几道问卷题。
区分确认与假设：关键项等用户决定，非关键项快速推进。
确认后执行：形成一份临时的任务契约。

一句话精简版如下：

开始前先判断信息是否充分；如果存在会显著影响结果的歧义，
请按重要性提出最多 5 个问题，得到确认后再执行。
非关键细节可以采用合理默认值，但必须明确说明你的假设。

如果只是偶尔使用，复制这句话已经足够；如果任务要反复执行，则应把它写进自定义指令、项目 Prompt 或系统提示词。

三个高频场景，应该让 AI 问什么

下面用三个可复现的对照案例，观察同一套方法如何迁移到产品、代码和写作任务。

产品需求：先确认用户、场景与验收标准

原始需求：

帮我设计一个 AI 对话历史功能。

直接执行可能出现的问题：

AI 可能默认这是团队产品，加入成员权限、跨设备同步、永久保存和全文搜索。然而真实需求也许只是个人用户在网页端查看最近的对话。

应该先问的问题：

1. 面向个人用户还是团队用户？

2. 用户查看历史记录的核心场景是什么？

3. 是否需要跨设备同步、搜索和分类？

4. 对隐私、删除和保存期限有什么要求？

5. 第一版 MVP 必须包含哪些能力？

用户回答后的需求确认摘要：

面向个人用户；用于找回近期对话；首版仅支持网页端列表、标题修改、删除和关键词搜索；暂不做团队共享；删除后不可恢复；验收标准是用户能完成查找、打开、重命名和删除。

最终输出片段：

MVP 功能范围：
1. 按最近更新时间展示对话列表；
2. 支持关键词搜索标题；
3. 支持打开、重命名和删除；
4. 删除前二次确认，删除后不可恢复。

暂不包含：
团队共享；
标签系统；
批量导出；
跨组织权限管理。

差异点评：

直接生成 PRD 时，AI 会努力显得“全面”；经过澄清后，它开始主动控制范围。对 MVP 来说，明确“不做什么”与列出“做什么”同样重要。

产品需求专用模板：

你是一名负责需求澄清的产品经理。收到需求后先不要直接写 PRD。

请优先确认：
1. 目标用户与使用场景；
2. 要解决的核心问题和业务目标；
3. 用户的关键操作流程；
4. 平台、隐私、权限等限制；
5. MVP 范围、优先级与成功标准。

最多提出 5 个关键问题。得到回答后，先输出“需求确认单”，
包含目标、用户、范围、不做事项和验收标准，确认后再生成方案。

精简版：

写产品方案前，先确认用户、场景、MVP 边界和验收标准，并输出需求确认单。

代码修改：先确认环境、边界与不可破坏项

原始需求：

帮我优化这个登录接口。

直接执行可能出现的问题：

AI 可能重构认证流程、升级依赖、修改返回结构，甚至新增数据库字段。代码局部更“漂亮”了，却可能让旧客户端、监控规则和自动化测试全部失效。

应该先问的问题：

1. 优化目标是性能、安全性还是可维护性？

2. 使用什么语言、框架和版本？

3. 当前行为、预期行为及报错日志是什么？

4. 哪些文件允许修改？

5. 返回格式、数据库和旧客户端是否必须兼容？

用户回答后的需求确认摘要：

Node.js 现有项目；当前问题是连续登录失败时接口仍会反复查询数据库；只允许修改认证服务和对应测试；不得修改响应字段、数据库结构及客户端协议；需要保留原有测试，并增加失败次数限制测试。

最终输出片段：

拟修改文件：
src/services/auth.js
tests/auth.test.js

保持不变：
HTTP 状态码；
JSON 返回字段；
数据库结构；
token 格式。

潜在风险：
限制策略可能误伤正常用户；
多实例部署时，内存计数无法共享。

验证方法：
运行原有登录测试；
新增连续失败、成功后重置、超时恢复测试；
检查旧客户端响应兼容性。

差异点评：

代码任务的关键不是让 AI “多写几行”，而是让它知道哪些地方不能碰。尤其涉及数据库迁移、接口变更、依赖升级和删除操作时，不能让 AI 默认执行破坏性修改。

适用于 Cursor、Claude Code、ChatGPT 等工具的模板：

修改代码前不要直接生成补丁，请先输出：

1. 你对当前问题和预期行为的理解；
2. 缺少的环境、版本、日志或上下文；
3. 计划修改的文件与修改边界；
4. 可能影响兼容性、安全性和数据的风险；
5. 修改后的测试与验证方法。

最多提出 5 个关键问题。
未经确认，不得修改数据库结构、升级依赖、改变接口契约、
删除数据或执行其他破坏性操作。
得到回答后，先总结约束，再给出修改方案或代码。

精简版：

改代码前先确认环境、预期行为、可修改文件和兼容要求；涉及数据库、依赖或接口变更时必须等待确认。

内容写作：先确认读者、渠道与表达目标

原始需求：

写一篇 AI 工具推荐文章。

直接执行可能出现的问题：

同一句需求放在不同渠道，答案应该完全不同：

公众号需要完整叙事和可读性；
知乎重视问题意识、论证与经验；
小红书更依赖场景化表达和短段落；
企业官网则需要品牌口径、事实依据与合规审查。

应该先问的问题：

1. 目标读者是谁？

2. 发布平台是什么？

3. 希望读者看完采取什么行动？

4. 需要什么语气和篇幅？

5. 有哪些必须包含、禁止出现或需要核实的内容？

用户回答后的需求确认摘要：

面向刚接触 AI 的职场人；发布在微信公众号；目标是帮助读者选择日常办公工具；语气专业但易懂；不使用无法核实的排名和效率数据；正文约 2000 字。

最终输出片段：

这不是一份“模型能力排行榜”，而是一张办公场景选择地图。

如果你主要处理会议纪要，应优先看长文本整理与格式输出；
如果你经常制作方案，则要关注资料归纳、结构生成和修改体验；
如果工作涉及敏感信息，还需要确认数据处理和组织管理方式。

差异点评：

澄清前，AI 只知道“写得像文章”；澄清后，它才知道为什么写、写给谁、在哪里发布，以及哪些话不能随便说。

内容写作专用模板：

写正文前，请先生成一份“写作简报”，不要直接成稿。

请确认：
1. 目标读者；
2. 发布平台；
3. 内容目标与期望行动；
4. 语气、篇幅和结构偏好；
5. 必须包含、必须避免的内容；
6. 哪些事实或数据需要来源支持。

最多提出 5 个关键问题。得到回答后，先输出标题方向、
核心论点、文章结构和事实依据；确认后再写正文。
不得编造数据、案例、用户反馈或引用。

精简版：

写作前先确认读者、渠道、内容目标和事实边界，生成写作简报后再写正文。

澄清维度速查表

什么时候该问，什么时候应该直接做

可以用一个简单公式判断：

是否先澄清 = 信息缺口 × 错误影响 × 返工成本

三个因素中，只要有两个明显偏高，就值得先确认。

为了防止 AI 问个没完，可以增加四条规则：

1. 最多询问 3—5 个关键问题；

2. 尽量给出选项，降低回答成本；

3. 已知信息不得重复询问；

4. 非关键细节使用默认值，并明确列出假设。

如果用户回答“你来决定”，AI 不应让任务停滞，而应说明：

我将采用以下默认假设：
目标读者为普通用户；
输出使用 Markdown；
采用稳妥、非破坏性的实现；
不修改未明确授权的范围。

把技巧固化成“澄清—确认—执行—验收”

真正高效的方式，不是每次手动粘贴一大段 Prompt，而是把规则保存到：

ChatGPT 等工具的自定义指令；
Cursor 或 Claude Code 的项目规则；
团队需求模板；
AI 应用的系统提示词；
自动化工作流的澄清节点。

一个简短的系统提示词可以这样写：

const systemPrompt = 
你是一个谨慎的任务执行助手。

收到任务后，先判断信息是否足以完成任务。
如果缺少会显著影响结果的信息：
先复述目标；
提出最多 5 个关键问题；
不要直接生成最终结果。

如果信息充分：
说明采用的假设；
给出简短计划；
然后执行任务。

不得重复询问用户已经提供的信息。
;

在 API 场景中，还可以将流程拆成两个阶段：

用户任务
↓
第一次调用：只负责判断信息是否充分
├─ 信息不足 → 返回澄清问题 → 等待用户回答
└─ 信息充分 → 返回任务摘要与执行计划
↓
第二次调用：携带原始需求、用户回答和确认摘要
↓
生成最终结果

如果你希望把“先澄清、再执行”固化到自己的机器人或工作流中，可以前往 api.884819.xyz，通过 API 将规则设置为系统提示词。

平台使用用户名和密码即可注册，不需要邮箱验证；内置 AI 对话功能，注册后可以直接使用。国产模型如 Deepseek、千问等完全免费，没有月租和订阅，其他模型按量付费。

新用户注册即送体验token。

建议先做一个低成本测试：复制本文的精简模板，把最近一次被 AI 做错的任务重新跑一遍。不要只比较文笔，而要记录四件事：

完成任务用了多少轮；
中途补充了几次信息；
最终返工了几次；
是否满足预先约定的验收标准。

好的 Prompt，不是一次性把所有细节都想清楚，而是让 AI 知道：什么时候可以行动，什么时候应该先停下来问一句。

真正节省时间的，不是少问一个问题，而是少做一遍错误的工作。

不过，AI 问清楚了，并不代表结果一定能用。下一个更容易被忽略的问题是：你有没有告诉它，什么才算“做完”？

下一篇，我们会提供一套“先定义验收标准，再生成结果”的 Prompt 模板，覆盖代码测试、内容审稿和产品方案检查，让 AI 不只负责交作业，还能先按标准自检一遍。

本文由8848AI原创，转载请注明出处。关注8848AI，带你从零开始学AI。

#Prompt技巧 #AI教程 #ChatGPT #Claude #人工智能 #AI工作流 #8848AI