最近一直在折腾 AI 编程 Agent。刚开始跟大多数开发者一样，关心的无非是：Bug 能不能找到、代码能不能改对、项目能不能跑起来、比我自己写快多少。

用得越多越觉得，这些只是第一阶段的问题。把 Agent 放进一个复杂一点的项目之后，我开始在意另一件事：它说"改好了"，我凭什么相信它？
倒不是说信不过模型。正常开发流程里，本来就不存在一句"改好了"就结束的情况。同事提 PR 我要看 Diff，改核心逻辑要问为什么这么改，涉及数据库、权限、事务，还得顺着调用链再看一遍。结果轮到 AI，很多时候变成：
"已完成修改，共修复 3 个问题。"
然后就没了。这种交付我是不太敢直接合的。
我现在看 Agent，先看它能不能把过程留下来：动了哪些文件；每个文件改了几行；为什么选这个方案；中间查过哪些代码、调过什么工具；判断错了能不能撤回。
这和我们平时做 Code Review 没区别，只是 Review 的对象从人写的代码换成了 Agent 写的代码。以后 Agent 越强，这部分反而越重要——一次改几十个文件、跨几个模块、自己连续跑几个小时，你再让人从结果倒推它中间干了什么，成本太高了。
以前我觉得 AI 编程产品最重要的是聊天框，现在反而觉得 Diff 可能比聊天框更重要。聊天框解决"我要它干什么"，Diff 解决"它到底干了什么"，这两件事不在一个层级上。尤其是 Agent 自己读项目、找问题、改多个文件之后，漏改都不可怕，可怕的是它顺手改了我根本不知道的东西。能按文件展开 Diff、逐行看前后对比、发现问题直接撤销的设计，比再多一个"自动修复"按钮有意义。
最近用 XunOPC 跑了趟实测，它修了几个 Bug、快了几秒，我都没太记住。"执行过程可以回放"这个设计倒是让我想了很多——事务 Bug 最后可能就改十几行，值钱的是：Agent 为什么没选另一个更简单的方案？先看了什么？排除了什么？这些过程不消失，Review 才有得看。
以后 Agent 进企业，这东西还涉及审批、审计、责任边界。出了问题，总不能围着一句"这是 AI 自动生成的"研究半天。谁让它执行的、看了什么、调了什么、改了什么、最后谁确认的，都应该留痕。
前两年大家都讲"以后 AI 能自己把整个项目做完"。真用了以后，我对"全自动"越来越谨慎。代码能跑只能证明一部分东西，权限、支付、审批、数据库、生产环境这些地方，我宁愿 Agent 多给点证据，也不希望它很自信地告诉我"放心，已经处理好了"。
现在判断一个 AI 编程 Agent 好不好用，标准慢慢变成：它做完以后，我敢不敢 Review、敢不敢合、出了问题能不能查。
能写代码的模型会越来越多，能修 Bug 的 Agent 也会越来越多。但如果 AI 要从"编程辅助工具"变成一个能接任务的工程角色，最后拼的可能不是谁更会写，而是谁能让人放心地把事情交给它。
#AI工具#工作日常#AI编程#