Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
我最怕“顺手重构”。一个小 bug 改 20 个文件,review 成本比自己改还高。
我们加了 diff budget。超过文件数或行数要说明原因,不然直接打回。
这个有用。还有禁止改锁文件,除非任务就是依赖升级。
代码 agent 很适合做机械但有上下文的活,比如补测试、迁移 API 调用、修 lint。复杂架构决策还是要人盯。
我倒觉得架构也能让它参与,但只能出方案和风险,不能直接落地到主干。
长任务必须有恢复点。agent 改一半断了,下次要知道已验证什么、没验证什么,不然重复探索。
执行日志要包含命令输出摘要。只写“测试通过”不够,至少要有命令名、失败点、修复后结果。
我们让 agent 每次提交前跑 git diff --stat 和相关测试,最后写变更摘要。还不错。
git diff --stat
别忘了安全。不要让代码 agent 读取 .env、SSH key、生产 kubeconfig。读到了也不该进日志。
.env
还有一个坑:agent 为了让测试过,会改测试去适配错误行为。要锁住测试或要求解释测试变更。
我准备先在非核心 repo 上试,限制目录、限制 diff、必须跑复现测试。
这样现实。代码 agent 不是替代 review,是把改动草稿和验证流水线前移。
你好!看起来您对这段对话很感兴趣,但您还没有一个账号。
厌倦了每次访问都刷到同样的帖子?您注册账号后,您每次返回时都能精准定位到您上次浏览的位置,并可选择接收新回复通知(通过邮件或推送通知)。您还能收藏书签、为帖子顶,向社区成员表达您的欣赏。
有了你的建议,这篇帖子会更精彩哦 💗