https://codexer.com/tags/tdd/Recent content in TDD on CodexerHugozh-cnWed, 08 Jul 2026 10:00:00 +0800https://codexer.com/posts/2026-07-08-convergo-review-loop-convergence/Wed, 08 Jul 2026 10:00:00 +0800https://codexer.com/posts/2026-07-08-convergo-review-loop-convergence/<p>如果你最近在用 AI 编程代理做稍微复杂一点的工作，你大概经历过这样一个场景：你让 AI 审查另一个 AI 写的代码。第一个审查者发现了三个问题。你让 AI 修复，然后让同一个审查者再看一遍，通过了。但你不放心，又找了一个新的审查者看，结果它发现了三个完全不同的问题。</p> <p>你深吸一口气，修复，再来。第五轮的时候，代码没变好多少，但 <code>docs/impl-notes.md</code> 已经长到了 500 行。</p> <p>这就是 AI 编程代理的审查循环问题。它不是 AI 不够聪明，而是审查循环本身有结构性缺陷：每一轮都在<strong>发散</strong>，而不是<strong>收敛</strong>。</p> <h2 id="审查循环为什么发散">审查循环为什么发散？</h2> <p>先定义一下概念。当我说「审查循环」，我指的是这样一个流程：</p> <ol> <li>AI Agent A 写了一些代码</li> <li>AI Agent B 审查这些代码，给出修改建议</li> <li>AI Agent A 根据建议修改</li> <li>AI Agent B 重新审查</li> <li>重复 2-4，直到 B 说「没问题」</li> </ol> <p>这个流程看起来没毛病。但实际上，它经常不收敛，而且失败的方式很隐蔽：</p> <p><strong>问题一：审查者只看到症状，看不到根因。</strong> 一个缺失的不变量在八个不同的地方产生了影响，审查者可能把这些当成八个独立的问题，一个接一个地发现，一轮接一轮地修复。本该一次修补计划就能解决的事，变成了八轮局部打补丁。</p> <p><strong>问题二：写代码的 AI 在修补丁，而不是修结构。</strong> 当审查者说「这里有个 bug」，写代码的 AI 倾向于在出问题的地方打个补丁。但如果这个 bug 的根源是一个不完整的设计决策，贴补丁只会让代码库越来越复杂，而问题依然存在。</p> <p><strong>问题三：每一轮都在增加内容，而不是减少不确定性。</strong> 审查发现一个问题，写代码的 AI 加一段文字解释。下一轮发现另一个问题，再加一段文字。经过几轮之后，artifacts 越来越长，越来越模糊，伪代码越来越多，这些伪代码又成为新一类审查发现的来源。这是一个正向反馈循环，方向是错的。</p> <p><strong>问题四：同一审查者的「通过」不可信。</strong> 同一个 AI 审查者在看完第六轮修改后说「通过」，可能是因为它已经适应了代码的风格，或者它已经「累了」。它的通过不是真正的无疵，而是认知惯性的产物。</p> <p>这四个问题叠加起来，就形成了一个典型的发散螺旋：越改越大，越改越模糊，越改越不确定什么时候算「改好了」。</p> <h2 id="convergo-的三条核心规则">Convergo 的三条核心规则</h2> <p><a href="https://github.com/gomilesf/convergo">Convergo</a> 是 Miles 在七月初发布的一个开源插件，同时支持 Claude Code 和 Codex。它源自 <a href="https://github.com/EveryInc/compound-engineering-plugin">Compound Engineering</a> 的设计理念，但加了一个关键的改进：<strong>边界</strong>。Convergo 的目标不是让审查更彻底，而是让审查循环<strong>必然终止</strong>。</p>https://codexer.com/posts/2026-07-02-ai-coding-workflow-evolution/Thu, 02 Jul 2026 10:00:00 +0800https://codexer.com/posts/2026-07-02-ai-coding-workflow-evolution/<p>去年这个时候，你打开 ChatGPT 或者 Claude，让它帮你写一个函数，然后复制粘贴到编辑器里，这事已经算「AI 辅助编程」了。到了 2026 年，事情已经完全变了。</p> <p>现在的日常是：你打开终端，启动一个 Coding Agent，跟它说「把这个系统的用户认证模块重构一下」，然后 Agent 自己去读代码、写计划、拆任务、创建分支、写测试、实现功能、跑 CI，最后把 PR 递到你面前。你只需要 review 一下，决定合并还是打回去。</p> <p>这不是科幻。这是 Karpathy、Addy Osmani、Simon Willison 这批人正在系统化推广的 <strong>Agentic Engineering</strong>。</p> <p>但问题也随之而来：当你不再亲手写每一行代码，而是管理一群能写代码的 Agent 时，你需要一套全新的工作方法。怎么安排任务？怎么保证质量？怎么避免 Agent 把代码库搞成灾难现场？</p> <p>日本工程师 Sakasegawa 最近发表了一篇非常全面的综述《A Survey of Development Workflows in the Coding Agent Era》，把 2026 年 AI 编程工作流的「江湖格局」梳理得很清楚。本文基于这篇综述，加上我自己的实践经验，画一张这个新世界的导航图。</p> <h2 id="从-vibe-coding-到-agentic-engineering一年间的范式跃迁">从 Vibe Coding 到 Agentic Engineering：一年间的范式跃迁</h2> <p>2025 年 2 月，Karpathy 提出了 <strong>Vibe Coding</strong> 这个概念。当时的含义很简单：你不再亲手写代码，而是让 AI Coding Agent 凭「感觉」去写，你只负责描述需求。</p> <p>这个提法在当时很有争议。批评者认为这是放弃了对代码质量的把控，支持者则认为这是解放生产力的必经之路。</p> <p>一年后的 2026 年 2 月，Karpathy 把这个概念升级为 <strong>Agentic Engineering</strong>。定义也清晰了很多：你 99% 的时间花在编排和监督 Agent 上，而不是直接写代码。</p>