AI 编程是怎么回事：从补全到 Agent

实战手记第 01 篇

前几天我让 Agent 更新博客里的两个项目案例。它先拉取最新代码，发现另一个会话刚提交了两个新案例；读完提交内容，它指出其中一页写进了客户的生产域名，于是改写文案、重画架构图、改了页面组件，跑完 171 项页面检查，在桌面和手机宽度截图核对，最后把站点发布到服务器，并回读线上页面确认没有横向溢出和失效图片。整个过程我只在开头说了一句需求，在结尾看了一遍报告。

同样叫“AI 写代码”，这件事和编辑器里自动补全下一行代码，已经不是同一种东西。这一篇讲清三代工具的差别，以及 Agent 那个“读、改、跑、看结果”的循环为什么既是能力的来源，也是风险的来源。读完你应该能解释：Agent 为什么能把一件事做完，又为什么会在没做完的时候说做完了。

三代工具：补全、对话、Agent

第一代是补全。你在编辑器里写代码，模型根据光标前后的内容猜下一行或下一段。它看到的只是当前文件附近的几十行，产出的是一段文本，要不要接受、接受以后能不能运行，全部由你判断。它犯错时，错误就在你眼前。

第二代是对话。你把报错信息、代码片段贴进聊天窗口，模型解释原因、给出改法。它能讨论更大的问题，但仍然只能看到你贴给它的内容，也不能自己验证建议是否正确。你在两个窗口之间复制粘贴，它就是一位只能听你转述的顾问。

第三代是 Agent。它直接运行在你的仓库和终端里：可以搜索文件、读日志、改代码、运行测试、打开浏览器、调用命令行工具，再根据输出决定下一步。这时它更像一位拿到了你电脑权限的新同事：能独立把事情推进好几步，但不熟悉你的项目历史，也不知道哪些操作在你们团队是禁区。

三者的根本差别不在模型本身。同一个模型放进补全插件里只能猜下一行，放进 Agent 的执行环境里就能把一件事做完。决定能力边界的，是它能用哪些工具、能看到哪些结果。

Agent 的工作循环

图里左上角是人给出的任务和边界：要达到什么结果，改动范围到哪里，用什么标准验收，哪些操作必须先问。之后 Agent 进入循环：读仓库和文档，改文件，运行构建、测试或浏览器，读结果并对照验收条件。没通过就回到读和改；通过了，带着证据交付。

回到开头的博客例子。“跑完 171 项页面检查”就是循环里的“跑”。在更早一次新增案例时，检查脚本报出“首页应有 12 个案例，实际 13 个”，Agent 读到这个结果，确认是新增案例带来的预期变化，更新期望值后重跑，这就是“没通过，回到读和改”。这一次它在截图里发现新案例的流程条右侧空了一大块，又回去改了 CSS，让列数跟着步骤数变化。每一次修正，依据的都是工具返回的真实输出，而不是它对代码的想象。

这个循环带来了 Agent 最有价值的能力：自我纠错。补全工具写错一行，要等你运行时才知道；Agent 写错了，测试会告诉它，它自己改。

同一个循环也会制造假完成

循环的终止条件是“对照验收条件通过”。问题在于，验收条件如果写得含糊，或者 Agent 选了一个比你预期更弱的检查，它就会在一个弱证据上宣布完成。

在一个移动端 SDK 项目里，Agent 曾在报告中写“PR 已合并”。实际情况是那个 PR 被关闭，改由另一个替代 PR 合并。在云平台项目里，一份记录写着某个前端构建已经通过验收，后来复查发现这是根据流水线状态推断出来的，没有人真正打开页面检查，记录被改成“推断不成立”。这两次都不是模型“撒谎”，而是它把手头最接近的信号当成了结论。

所以使用 Agent 时，人的工作重心会发生转移：从自己写代码，转到写清楚什么叫做完、检查它交回来的证据是否真的证明了这件事。第四篇会专门讲这件事。

权限：循环的每一步都要过关

Agent 能运行命令，也就能运行危险的命令。我的项目里，读文件、运行本地测试一般直接放行；推送代码、合并分支、发布到服务器、修改线上数据，则必须先停下来等我确认。

这条线不是按“命令看起来危不危险”画的，而是按能不能撤回画的。本地改错了，git diff 一眼就能看到，撤回成本几乎为零；线上数据改错了，可能要从备份恢复。第三篇会讲这些规则具体写在哪里，第六篇会讲怎样用“能否验证”和“能否撤回”决定任务的分工。

总结

补全猜下一行，对话给建议，Agent 自己运行命令、读取结果、修正错误，把一件事推进到可交付。它的能力来自“读、改、跑、看结果”的循环，它的风险也来自这个循环：验收条件含糊时，它会在弱证据上宣布完成；权限过宽时，它会执行你无法撤回的操作。

一个 Agent 会话好用以后，下一个问题很快会出现：同时开五个会话，各自推进不同项目，会话结束以后它们知道的事情去了哪里？下一篇讲多会话的分工和交接。