这个"病"长什么样
你跟 AI 说："这里有个 bug，帮我修一下。"
它开始分析：
- "问题可能由以下原因导致……"
- "根据日志分析，根因在于……"
- "建议从以下几个方面进行修复……"
- "1. 检查 XX 逻辑 2. 修改 YY 参数 3. 重构 ZZ 模块"
条理清晰，逻辑严密，你看得连连点头。
然后——
它停了。
你等它继续，它不继续了。你追问："那修了吗？"
它说："建议您按照上述步骤进行修复，如有需要我可以进一步协助。"
分析写了一大篇，一行代码没改。
我的真实案例
我在做一个测试用例生成 Agent。它负责读取用户的需求文档，然后输出结构化的测试用例。
有一版 Prompt 效果不好——覆盖率只有 69%，离目标 100% 差很远。
我让 AI 分析原因。它给了非常详细的回复：
经过分析，覆盖率不足可能由以下原因导致：
- 边界条件覆盖不足：当前 Prompt 未明确要求覆盖边界值和异常场景
- 需求理解偏差：LLM 在提取功能点时可能遗漏了隐含的需求约束
- 输出格式不一致：部分用例的粒度定义不统一，导致去重时丢失
- 覆盖维度不完整：缺少对非功能性需求（性能、安全）的覆盖
建议优化方向：
- 在 Prompt 中增加边界值分析的强制要求
- 添加覆盖元素自检步骤
- 统一输出格式的粒度标准
- ……
对。每一条都分析到了点子上。
但它不会改 Prompt。
它把问题列了一遍，然后等着我下一步指令。
这一轮对话消耗了 3000 多 token。下一轮我得把问题重新说一遍："按你说的第 1 条和第 2 条去改 Prompt。" 它改完之后，我又得验证效果。再来一轮。
如果它分析的时候就直接改了，一个回合就搞定的事，变成了三四个回合。
为什么 AI 会这样？
不是 AI"懒"。根本原因是：
1. 默认行为倾向：AI 被训练成"建议者"而非"执行者"
大模型的训练方式决定了它倾向于给你"信息"而不是"行动"。它输出分析和建议，本质上和输出知识问答没有区别——都是"生成文本"。而"直接修改代码并执行"需要它跨越从"说"到"做"的鸿沟。
2. 不确定性规避：改了可能改坏，不改最安全
如果它直接改了，改坏了怎么办？"只分析不执行"是一个安全的策略——分析总是对的，执行可能出错。模型在训练过程中"学到"了这种保守倾向。
3. Prompt 中缺少明确的"执行"指令
大多数时候我们给 AI 的指令是"帮我看看这个问题"、"分析一下原因"——这些措辞本身就在引导 AI 只做分析。如果你不说"直接改"，它就默认你只需要分析。
怎么治
方法 1：指令里明确写"直接修改，不要等我确认"
❌ 错误示范：
"覆盖率只有 69%，帮我分析一下原因"
✅ 正确示范：
"覆盖率只有 69%，分析原因并直接修改 Prompt，修改完输出完整的新版 Prompt"
关键词是 "直接修改" 和 "输出新版" 。把"分析"和"执行"合在一个指令里，不留"分析完可以停"的空间。
方法 2：拆成明确的三步
如果你不放心让它一步到位（有时候分析方向确实需要你确认），那就拆成三步，但每一步都给明确的执行指令：
- 第 1 步："分析原因，列出修复方案，标注推荐方案"（这一步只分析）
- 第 2 步："按推荐的第 X 条方案，直接修改，输出修改后的完整代码/Prompt"（这一步执行）
- 第 3 步："用以下测试用例验证修改效果：……"（这一步验证）
关键是第 2 步不能省。 很多人做完第 1 步觉得"分析得对"，然后开始自己动手改——那就变成你干 AI 的活了。
方法 3：用 System Prompt 预设行为模式
在你的 System Prompt 里加一条规则：
"当用户提出 bug 或问题时，你必须：1) 简要分析原因（不超过 3 行）；2) 直接给出修复后的完整代码/Prompt；3) 说明你改了什么。禁止只输出分析不输出修复。"
这样不管你怎么提问，AI 都会自动带上修复。
一句话总结
AI 天生是"顾问"，不是"工程师"。你不明确命令它"动手改"，它就只动嘴不动手。