前言
现在用 AI 写代码，最常见的一句话大概是：
帮我修一下这个 bug。
这句话很自然，也很方便。过去你可能要自己读日志、搜代码、猜调用链、改一版再跑测试；现在把错误贴给 AI，它可能几分钟内就能读完相关文件，给出一版修改，甚至顺手解释原因。
但问题也藏在这里。
AI 很容易让人产生一种错觉：它改得快，所以它是可靠的。可在工程里，快不等于对，更不等于可托付。真正关键的问题不是它有没有改代码，而是它能不能证明：
问题被复现过。
根因被定位过。
改动是最小的。
测试真的跑过。
风险被说明过。
失败会被记录下来。
所以我越来越觉得，AI 操作方式正在经历一个很重要的演进：
Prompt -> Skill -> Loop
Prompt 让 AI 听懂你。Skill 让 AI 按经验做事。Loop 让 AI 做完之后必须留下证据，并从失败中改变下一次行为。
换句话说：
Skill 是 Prompt 的工程化。
Loop 是 Skill 的责任化。
一、Prompt 阶段：一次性的意图表达
Prompt 的优点非常明显：低成本、灵活、自然。
你可以直接说：
登录页打开后报错，帮我看一下。
模型会根据当前上下文去理解问题。它可能会读页面组件、查接口调用、看错误栈、修改某个字段名，然后告诉你“已经修好了”。
这个阶段适合探索问题，也适合做一次性的辅助判断。但它有一个根本缺陷：流程是隐含的。
你没有明确告诉它：
- 必须先复现问题。
- 必须说明错误从哪里来。
- 必须只做最小修改。
- 必须跑哪些测试。
- 必须列出没有验证的部分。
- 必须说明改动可能影响哪些地方。
于是模型很容易从“解决问题”滑向“看起来解决了问题”。
它可能直接根据错误信息猜一个原因，改一段代码，给出一段很顺的解释。解释可能听起来合理，但如果没有复现、没有测试、没有 diff 边界，它仍然只是一个未经证明的答案。
这就是 Prompt 阶段的边界：它能让模型开始做事，但不能保证模型按工程流程做事。
二、Skill 阶段：把修 Bug 变成工程流程
当同类任务反复出现时，继续靠 Prompt 就会变得浪费。
如果你每次都要提醒 AI：
先别急着改。
先复现。
只改相关文件。
改完跑测试。
说明风险。
那说明这些要求不应该继续停留在聊天窗口里。它们应该被沉淀成 Skill。
Skill 不是更长的 Prompt。它更像一份可复用的任务协议。对于修 Bug，一个 Debug Skill 至少应该要求 AI 按这样的顺序工作：
读取错误现象和相关上下文
确认复现路径
定位可能根因
提出最小修改方案
修改代码
运行相关测试
展示 diff
说明验证结果和剩余风险
这里最重要的变化是：经验被工程化了。
Prompt 里，流程依赖模型临场发挥。Skill 里，流程变成默认约束。模型不再只是“帮我修一下”，而是要按一套调试协议行动。
这会带来几个直接好处。
第一，输出更稳定。不同时间、不同模型、不同上下文下，任务仍然有统一的执行骨架。
第二，结果更容易审查。你可以检查它有没有复现、有没有测试、有没有解释改动边界。
第三，团队经验可以复用。一个人踩过的坑，不需要每次重新写进 Prompt，而可以变成 Skill 的一部分。
但 Skill 仍然不够。
因为流程写在那里，不代表每次都执行对了。模型可能声称跑了测试，但其实没跑；可能说是最小修改，但实际改动越界；可能复现失败，却继续猜测原因。
所以从 Skill 往前走，还需要 Loop。
三、Loop 阶段：让 Skill 承担责任
Loop 的重点不是让 AI 更会说，而是让 AI 的行为可观察、可验证、可复盘。
一个 Debug Loop 不应该只关心“这次有没有修好”，还应该记录这次修复是怎么发生的：
输入是什么
目标是什么
问题如何复现
修改了哪些文件
为什么这样改
跑了哪些测试
哪些结果被验证
哪些地方没有验证
失败属于哪一类
下一次 Skill 应该如何调整
这才是 AI 修 Bug 里的责任闭环。
如果测试失败，Loop 不应该只是让模型道歉，然后重新生成一版。它应该追问：
失败发生在复现阶段，还是修改阶段？
是需求理解错了，还是根因判断错了？
是测试没覆盖，还是改动范围过大？
这次失败能不能沉淀成下一次的检查项？
这和我之前思考 Agent 责任感时的结论是一致的：责任感不是一种语气，而是一套外部结构。
模型不会因为说了“抱歉”就真的承担后果。真正有效的是系统约束：
- 没有复现记录，就不能声称定位完成。
- 没有测试输出，就不能声称修复完成。
- diff 超出范围，就必须说明原因。
- 同类失败重复出现，就要更新 Skill。
- 高风险改动，需要人工确认。
Loop 不是把模型拟人化，而是把模型的行为工程化、审计化、可纠正化。
四、同一个 Bug 的三种处理方式
可以用一个登录页报错来对比三种阶段。
Prompt 版本
帮我修登录页报错。
AI 可能会直接读代码、改字段、调整接口调用，然后告诉你修好了。
这个版本最快，但风险也最大。你不知道它有没有复现，不知道它是不是猜的，不知道它有没有改到别的流程，也不知道它所谓的“修好”有没有证据。
Skill 版本
按 Debug Skill 执行：先复现，再定位，做最小修改，运行测试，说明风险。
这时 AI 的行为开始变得像工程流程。它需要先确认错误，再定位根因，再给出最小修改。你可以根据 Skill 的步骤检查它有没有漏项。
Skill 让一次修复变得可审查。
Loop 版本
如果复现失败、测试失败、diff 越界或同类错误重复出现，触发复盘，并更新 Debug Skill。
这时重点不只是当前 bug 修没修好，而是这次任务有没有让下一次更可靠。
如果模型因为没有检查接口字段导致修错，那么 Loop 应该把“核对接口契约”加入 Debug Skill。如果它改动范围太大，那么 Loop 应该提高 diff 审查要求。如果它没跑测试却说完成，那么 Loop 应该降低这类输出的可信度。
Prompt 解决当下。Skill 解决复用。Loop 解决改进。
五、为什么 Loop 比“更聪明的模型”更重要
很多时候，我们会把希望寄托在更强的模型上。
模型更强，当然有用。它能读更多代码，理解更复杂的调用链，写出更像样的修复方案。
但模型能力提升并不会自动带来工程可靠性。
越强的模型，越容易给出一段听起来非常合理的解释。它能把错误原因、修改理由、验证结论都说得很顺。可如果这些结论没有证据链，顺滑反而会变成风险。
AI 修 Bug 最危险的地方，不是它完全不会，而是它“差一点就像真的会”。
Loop 要防的正是这些行为：
- 没复现就修改。
- 没测试就说修好了。
- 改动超出问题范围。
- 用漂亮解释掩盖不确定性。
- 失败后只道歉，不复盘。
- 下一次重复同类错误。
更聪明的模型提高上限，Loop 稳定下限。工程系统真正需要的，往往是稳定下限。
六、结论：AI 操作的重点从表达走向约束
Prompt、Skill、Loop 不是三个时髦词，而是 AI 操作方式的三个层级。
Prompt 让 AI 听懂你。
Skill 让 AI 按经验做事。
Loop 让 AI 做事后必须留下证据，并从失败中改变下一次行为。
所以，AI 编程的进步不应该只看模型能写多少代码、能读多少上下文、能不能一次猜中原因。
更重要的是：
它有没有复现？
有没有证据？
有没有测试？
有没有边界？
有没有复盘？
有没有把失败变成下一次的约束？
如果没有这些，AI 只是更快地生成了一次答案。
如果有这些，AI 才开始接近一个可以被托付的工程助手。
从 Prompt 到 Skill，再到 Loop，本质上就是从“让 AI 会做事”，走向“让 AI 按规矩做事，并为结果留下可检查的证据”。