每个人刚开始使用AI时，都会遇到这样的时刻：模型给出令人失望的回答，然后你要么耸耸肩接受它，要么新开一段对话并重写提示词。如果回答已经接近到足以诊断问题，更好的做法往往是直接回复并引导后续工作。
本文给出一套有步骤的工作流程：第一次回答接近目标、偏离目标，以及表面看起来没问题、实际却有错时该怎么做。读完后，你将掌握一种可重复的方法，不靠巧妙措辞也能改进并检查草稿。
为什么大多数人停得太早
把AI想象成自动售货机，输入提示词就取出答案，会忽略聊天界面真正能做的事。后续轮次会把新指令和你的反馈加入工作上下文。当第一次回答是可用的起点时，这些上下文能帮助你指出哪些要保留、哪些要修改。
即使第一条提示词很强，这种方式也可能有帮助，因为后续轮次会包含你对草稿的反馈。厂商指南把“起草、审核、改进”描述为常见的提示词链式模式，同时也建议：如果中间审核必须被查看或记录，就要使用明确标准和相互独立的步骤（Anthropic提示词最佳实践）。
不断提出异议可能让人觉得有点不礼貌，也可能因为第一条提示词没有做到完美而显得低效。但你是在编辑生成的草稿，不是在与人协商。只要每一轮都带来具体、可审核的改进，就继续；当累积的上下文已经妨碍任务时，再重新开始。
四种动作
这套工作流程先使用四类后续动作，再进行最终验证。
- 批评：具体指出模型哪里有问题。
- 聚焦：要求扩展回答中的某一部分。
- 转向：改变角度或受众。
- 压力测试：要求列出假设、证据、失败情形或可信的反方论点。
下面逐一介绍。
把这四种动作视为一套可重复使用的工作流程，而不是一袋巧妙的后续提示词。对于重复性工作，将这套顺序保存为团队可以复用的模板。
动作1：批评
当第一次回答大体上不错、但某些地方不对时，使用批评。准确告诉模型问题在哪里。
第二段太正式了。写得更紧凑一些。
删掉“感谢你的耐心等待”这句，我不会这样说话。
把第三个项目符号换成更具体的内容。
开头第一句太泛泛了，放在任何产品上都成立。改成与我们的产品直接相关。
批评时有三条规则：
要具体。“写得更好”毫无用处。“第三个项目符号太长了，把它缩成一句话”才有效。
要直接。“我觉得或许可以考虑修改一下……”只是在浪费文字。“重写第三个项目符号”就很好。
肯定有效的部分。“保留第一段的结构，重写第二段。”否则，模型可能把整篇内容全部重写，让你失去已经写得不错的部分。
一个实用模式是：先告诉模型保留什么，再告诉它修改什么。“保留开头、结构和语气，但把中间三句话写得更有力、更简短。”
动作2：聚焦
第一次回答涉及面很广，但你真正想要的只是其中一小部分。让模型进一步展开那一部分。
我想深入研究第三个方案。进一步展开它：实际会是什么样、成本多少、需要哪些人参与？
取第二段的第二句话“……该法规可能影响现有合同……”，将它扩展为三段。
在你列出的五项风险中，重点分析第三项。一步一步说明它实际会如何发生。
有些人会稍微修改原问题后再次提问，其实可以直接指出有价值的部分，要求做更深入的处理。模型已经生成较广的草稿；现在你是在缩小任务范围。
动作3：转向
第一次回答本身没有问题，但受众或角度不对。
现在为一个从未在金融行业工作过的人重写这段内容。
现在重写一遍，假设我要把它发给一位持怀疑态度的CFO，而不是一位表示理解的同事。
使用同一组论据，把它们整理成单页幻灯片摘要，而不是备忘录。
现在反过来：针对你刚才提出的全部论点，给出最有力的反方论证。
转向会复用对话中已有的材料，并根据不同目的重新塑造。它是否比完全重新开始更快或效果更好，取决于任务、累积的上下文和模型。如果这种选择很重要，请在有代表性的工作上比较两种方法。
分析任务中特别实用的一种转向是：“现在请唱反调。针对你自己的回答，提出最可信的反驳。”回答可能暴露假设或缺失的证据，但它仍然只是另一份生成草稿，并非独立专家审核。
动作4：压力测试
第一次回答看似合理，但你不确定它是否正确。让模型为其辩护，或者反驳它。
哪些证据会让你改变对问题2的回答？
这份回答中，你对哪些地方最不确定？哪些内容可能是错的？
对这一立场最聪明的批评者会说什么？
如果资深专家阅读这段内容，他们会在哪里提出异议？
压力测试有助于揭示被流畅文字掩盖的弱点。要求模型说明假设，指出哪些主张需要外部证据，并构建可信的反方论点。随后应由你自行评估这些输出，不要把模型当作自身回答的独立裁判。
一个适用于事实性回答的压力测试是：“哪些观点依赖本次对话之外的事实？请为每一点列出我应核查的原始来源，并说明你作出的假设。”把回答当作自己后续核验的线索清单。模型自报的信心并不是经过校准的真实性证据。
第五种动作：验证
前四种动作能改进回答，却不能证明回答为真。只要输出会影响决策、客户沟通、政策、代码变更或公开发布的内容，就要加上最后一轮验证。
使用一份简短清单：
| 检查项 | 要问的问题 | 下一步行动 |
|---|---|---|
| 来源 | 哪些主张依赖这段对话之外的事实？ | 查阅原始来源或可信参考资料。 |
| 边界 | 模型作出了哪些我并未提供依据的假设？ | 删除、确认或标明这些假设。 |
| 风险 | 如果内容有误，最严重的后果是什么？ | 对高影响输出增加人工审核。 |
| 完整性 | 缺少了哪种重要情况？ | 明确要求补充缺失的情况。 |
| 可用性 | 我能否按现有表述直接行动？ | 将模糊建议转化为步骤、负责人、日期或示例。 |
迭代可以让草稿变得更好；验证则决定它能否安全使用。
本文链接的配套工作流程卡片将这五种动作整理成一页，帮助你养成习惯。
组合使用：一次完整迭代
下面用一个真实示例演示四种动作。假设你以这条提示词开始：
你是一名经验丰富的人力资源总监。为我这家拥有80名员工的公司起草一份单页提案，建议实行每周四天工作制。回应显而易见的顾虑，提出试行方案，并以建议结尾。
第一次回答是一份还不错的草稿，但并不完美。接下来怎么做？
动作1（批评）：
“显而易见的顾虑”这一节太单薄了：你谈到了生产力，却漏掉了客户服务覆盖，以及这对按小时计薪的支持团队有何影响。深入补充这两点。
动作2（聚焦）：
试行方案才是我真正会使用的部分。把它扩展为四段计划：哪些人参加试行、持续多久、衡量什么，以及怎样才算成功。不要捏造公司事实或阈值；需要我补充或批准的值一律写成
[missing]。
动作3（转向）：
现在重写同一份提案，假设受众是我们的投资人董事会，而不是内部人力资源团队。顾虑和措辞都应有所不同。
动作4（压力测试）：
指出这项提案最可信的失败情形。不要暗示亲身经历，也不要捏造案例研究。把一般推理与需要外部来源支持的主张分开。
为了直观展示效果，以下是动作2如何改变试行方案部分的一组代表性前后对比。请为自己的版本运行提示词；措辞和细节都会不同。
修改前：“我们建议让一个团队试行一个季度的每周四天工作制，然后评估结果。”
修改后：“由
[team or teams to confirm]试行[duration to approve]。启动前，记录客户服务覆盖情况、约定产出指标、计划外加班，以及一项自愿参与且经过隐私审查的员工脉搏调查指标的基线。试行负责人必须在开始日期前批准成功阈值和停止条件；在此之前一律标记为[missing]，不得捏造数字。按约定间隔审核结果，并记录是否有工作量转移到试行范围之外的团队。”
还是同一个模型、同一段对话。差别不在智能水平。动作2告诉了模型哪部分最关键、“扩展”具体意味着什么，以及哪些地方不允许猜测。
完成这些后续操作后，你得到的提案会比盲目重启更容易检查改动。它是否更好，仍取决于任务、模型、提供的信息和你的验证步骤。
哪些迹象说明“继续迭代，不要重来”
遇到以下情况时，应留在当前对话中，而不是新开一段：
- 模型已经答对了大部分，而你有具体意见。
- 输出主题正确，但呈现形式不对。
- 你想探索替代方案或不同版本。
- 你想测试回答是否稳健。
- 你意识到自己忘了提及某项重要信息。
遇到以下情况时，应该新开一段对话：
- 模型已经完全偏离你的目标。
- 对话累积了足够多的材料，重要指令开始被忽略、相互矛盾、压缩掉或挤出上下文。
- 你想从全新上下文测试同一条提示词，看看之前是否得到了异常回答。
- 即使你提出异议，模型仍反复给出相同建议。
几个有帮助的小习惯
**只在线程上下文仍有帮助时继续使用它。**不同聊天产品管理长对话的方式不同：请求可能保留早期轮次、采用滚动窗口，或压缩较早内容。上下文窗口更长，也不保证每个细节都会被正确使用。Anthropic上下文窗口文档解释了工作记忆限制和当前的压缩行为；也应查看你实际使用产品的文档。
准确指出位置。“第二段”“第三个项目符号”“你建议的第二个方案”。具体指代比模糊批评更便于模型执行。
直截了当。“太正式了，再试一次。”“不，这版更差。回到第一版，只修改结尾。”直接的编辑指令可以减少歧义。
**问模型如何理解。**如果你已提出具体批评，模型却仍未领会，可以问：“你认为我要求的是什么？用你自己的话重述目标。”它的重述可能暴露错位之处，让你获得一个可具体纠正的点。
第一次回答之后，继续推进
未经审核就接受第一次回答，可能会留下重要的质量工作。批评、聚焦、转向、压力测试和验证构成一套实用的后续流程。关键技能不只是写出更好的第一条提示词，还包括判断下一轮何时能澄清任务、何时需要外部验证，以及何时从干净上下文重启更安全。
