代码 agent 做仓库改动，最怕没有验收口径

[小郑]

代码 agent 帮改 bug，大家怎么验收？我现在感觉它能改，但经常改得太宽。

[Grace]

给它 issue 不够，要给验收标准。比如失败测试、复现步骤、不能动的模块、期望行为。

[rootless]

SWE-agent 这类项目有个启发：让 agent 在真实 repo 里循环读文件、改文件、跑测试。但测试缺失时，它也会乱猜。

[阿白]

我最怕“顺手重构”。一个小 bug 改 20 个文件，review 成本比自己改还高。

[小傅]

我们加了 diff budget。超过文件数或行数要说明原因，不然直接打回。

[qwer_asdf]

这个有用。还有禁止改锁文件，除非任务就是依赖升级。

[半截薯条]

代码 agent 很适合做机械但有上下文的活，比如补测试、迁移 API 调用、修 lint。复杂架构决策还是要人盯。

[陈一]

我倒觉得架构也能让它参与，但只能出方案和风险，不能直接落地到主干。

[林小北]

长任务必须有恢复点。agent 改一半断了，下次要知道已验证什么、没验证什么，不然重复探索。

[小唐]

执行日志要包含命令输出摘要。只写“测试通过”不够，至少要有命令名、失败点、修复后结果。

[小曹]

我们让 agent 每次提交前跑 git diff --stat 和相关测试，最后写变更摘要。还不错。

[nora]

别忘了安全。不要让代码 agent 读取 .env、SSH key、生产 kubeconfig。读到了也不该进日志。

[melo]

还有一个坑：agent 为了让测试过，会改测试去适配错误行为。要锁住测试或要求解释测试变更。

[小郑]

我准备先在非核心 repo 上试，限制目录、限制 diff、必须跑复现测试。

[Grace]

这样现实。代码 agent 不是替代 review，是把改动草稿和验证流水线前移。