8.0
热点
AI SCORE
编程提效2026-08-25 21:00
AI Agent 写代码不难，难的是整个流程管控
dev.to · AI#AI编程#Agent#开发经验
Editor brief · 编辑速览
六个月实战发现：Agent 写代码本身过关，真正痛点在现有代码检索不足、自我验证形同虚设、重复造轮子等流程层，并给出具体规则解法。
我在一个足够大的代码库上跑了大约六个月的 Claude Code 智能体——几百个 open issues，智能体每天提交代码，一旦出错 CI 管道就会大声报错。
没人告诉过我的是：智能体写代码其实还行。真的还行。给它一个作用域良好的函数，它会返回合理的结果。
它真正不行的，是写代码以外的一切事情。判断这个东西到底该不该建；注意到自己要写的辅助函数六十行之前已经存在了；在宣布修复生效前去验证一下。这些不是编程失败——是流程失败，再多的 prompt 调优也解决不了，因为问题从来不在 prompt 本身。
解决它的方法是把流程写下来。
智能体需要格式化一个时长。它写了个 formatDuration()。你的代码库里其实已经在 utils 文件里有了 humanizeElapsed()，只是它从来没打开过那个文件。
这是我最贵的失败模式，因为从外表看它根本不像失败。代码能用，测试通过，review 也过了。半年后你改了时长显示方式，才发现四个地方里有三个用了这个新格式。
智能体强烈倾向于写新代码而不是找已有代码，因为写是它们被奖励的行为，而搜索是昂贵的。对抗力量必须是显式的：在写辅助函数之前，证明这个概念不存在。不是"快速检查"——是证明，要有一个可以引用的搜索结果。
同样的纪律可以抑制"v2"反射——智能体发现一个它没完全理解的函数后，在旁边写个 processDataV2()，然后把两个都留在代码树里永远不动。
问智能体修复是否生效，它会告诉你修复生效了。它没有撒谎。它真诚地推理出了一个自信的答案，而推理从内部看起来就像验证。
解决这个的规则很生硬：不得说"完成了"、"修复了"或"通过了"，除非贴出证明这一点的命令输出。不是输出的描述，是输出本身。
有趣的是，遵循这个规则的智能体经常在这个过程中抓住自己。它去运行测试以便引用结果，测试失败了，于是那句话从未说出口。验证步骤不是对答案的检查——它本身就是产生答案的过程。
智能体修复了 UserService 里的一个空检查 bug。同样的 bug 存在于其他十一个服务里，因为三周前它们都是同一个智能体从同一个模板写的。
智能体只修你指出的地方。除非你要求，否则它们不会从一个实例泛化到一类实例，而整个 bug 有意思的原因恰恰在于它很可能是系统性的。所以在每次修复之后，扫一遍相邻文件里有没有同样的缺陷，把找到的都记录下来。即使现在修不了也要记录——一个已记录未修的 bug 是待办项，一个没人注意到的未修 bug 是地雷。
智能体遇到一个测试失败，立刻提出了一个修复方案。然后又一个。又一个。每一个听起来都合理，没一个管用，四十分钟后文件里堆了三个试探性改动，原来的 bug 还在——现在更难发现了。
缺失的是在决定改什么之前先搞清楚为什么失败这一步。读实际的错误。单独复现它。形成一个假设，验证那个假设，然后才编辑。当三次尝试都失败了，停下来——第四次尝试不是策略，是老虎机。把学到的东西上报。
这类规则最明显的存放位置是项目说明，我一开始也是这么做的。它不scalable。
CLAUDE.md 里的所有东西永久存在于上下文中，和实际任务争夺注意力。一条十二行的调试协议在测试失败时恰到好处，但在其他 95% 的时间里纯粹是噪音。往里塞足够多的流程，重要的规则就会被场景性规则稀释。
skills 是按触发器加载的。调试纪律只在东西坏掉时出现，其他时候不碍事。这就是全部的区别，而且事实证明它非常重要。
第二个原因是可移植性。流程纪律不是项目特定的——"第二个辅助函数"问题在我待过的每个代码库里都一样。把它放在一个项目的说明里意味着到下一个项目要重新推导。打包成插件，它就能跟着走了。
我把积累下来的通用的、与项目无关的那一半提取出来，作为 Claude Code 插件发布到了市场上：
/plugin marketplace add mrveiss/Claude-Dev-Skills
/plugin install claude-dev-skills@claude-dev-skills
process — 方法纪律：构建前先探索，规划多步改动，系统化调试，验证后再声称，并行派发智能体，完成一个分支。
canonical-coding — 每个概念一个实现。失败模式 1。
commit — 提交工作流，带 pre-flight 检查、自动格式化，以及 pre-commit hook 重写文件时的重试逻辑。
review-lenses — 按领域镜头 review（架构、交付、前端、文档、UX、视觉工艺），而不是一种无差别的"review this"。
gap-audit — 修复后扫相邻文件并记录缺口。失败模式 3。
web-audit — 网站安全、SEO 和 AI 友好性审计：headers、DNS、TLS、CORS、邮件欺骗、暴露面板、逐页 SEO、妥协指标。
ui-design — 视觉方向、排版、色彩、布局、间距、动效、无障碍。
memory-cleanup — session 结束时内存清理，让上下文文件保持为索引而不是变成淤泥。
Apache-2.0，其中两个整合了其他 skill 作者的想法——特别是 Jesse Vincent 的 Superpowers 套件，值得独立一读。
这些来自构建 AutoBot-AI。那些项目特定的——issue 到 merge 循环、全栈调试、代码库审计——放在他们自己的 marketplace 里，因为它们硬编码了那个平台的分支名和路径，在其他地方毫无用处。这是能带走的那一半。
流程纪律有真实的成本。每条规则都会让智能体变慢，有些变慢在当下感觉毫无意义——证明辅助函数不存在几乎总是比写辅助函数花的时间更长。
这种权衡只有在代码库的生命周期里才能收回，这意味着对于一周后就要扔掉的原型来说，它确实是错误的决定。如果你在做 spike，跳过所有这些，让智能体写。
它有价值的是第二年——那时候你是那个在维护智能体写的代码的人。
如果你试了这套东西，我想知道哪里不对：流程是否贴合你实际的工作方式，还是在你不需要的时候触发？canonical-coding 对一个合法存在并行实现的代码库来说是否太严格？还有什么缺失的？