从 Prompt 到 Skill 再到 Loop：AI 修 Bug 为什么需要责任闭环
前言 现在用 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 就会变得浪费。 ...