只有通过运行程序才能发现的bug
标题：只有通过实际运行才能发现的Bug
上周我写了一篇关于自己不擅守纪律以及为此构建了一个补救工具的文章 —— ArDD，这是一套 Claude Code 技能，它通过制品、计划和任务来推进项目，而不是让 agent 从一行提示直接跳到代码。那篇文章的结尾，我怀疑它到底是不是一个穿上戏服的 CLAUDE.md。我是唯一使用 ArDD 的人（截至撰写本文时），所以下文其实是一份决策记录，去掉了私密部分。但它教会我的东西超出了这一件工具的范畴，而正是这种泛化让我决定把它记下来：直到我实际运行并观察真实情况之前，这些 Bug 是隐形的，通过更长时间地阅读代码永远无法发现。
状态放在了错误的位置
ArDD 的核心循环是：计划 → 任务 → 实现，而实现可以将工作交给在自己的 git worktree（工作树）中运行的子 agent，这样你就不必守着单线程 agent 了。最初的设计试图谨慎处理交接：在委派之前，它先把一些粗粒度的状态（计划、任务列表）提交到主分支，其逻辑是，被委派的工作树需要一个稳定、已经落地的点作为分支起点。这个逻辑是错的，我之所以发现，是因为我进行了现场冒烟测试，而不是信任设计：我提交了一个一次性计划和任务文件，将工作委派给一个在全新 worktree 中的子 agent，然后实际查看了这个 worktree 的内容。结果不匹配。这个 worktree 是从 origin/main 分支的，并且不包含我刚刚在本地进行的两次提交。工具链是从远程追踪分支创建 worktree，而不是本地 HEAD，而且这不是我能通过技能自身的文本控制的行为。更糟的是，根据问题追踪器的记录，它在不同工具链版本之间方向翻转 —— 所以“总是假设全新”和“总是假设同步”一样错误。唯一的正确姿态是：验证，永不假设。
同样是这次运行，暴露了一个我至今无法解释的问题。创建 worktree 竟然把我主检出的 git 配置改成了 core.bare = true，这会导致那个检出中的普通 git 操作失常，直到你手动发现并恢复。
git worktree add 不该碰触你运行它的那个检出目录的配置，而我始终没找到其机制。所以我没假装修复它：协调器现在会在每次委派运行后检查那个翻转，如果再次发生就大声报错。对一个不明原因的装备Bug设置一个绊线并非修复，我也不打算称之为修复——但一个响亮已知的未知总比沉默的未知要好。针对数据分叉的修复是一个小脚本worktree-align.sh，委派子智能体将其作为强制第一动作运行：将本地默认分支快进到新工作树分支，如果这不是一次干净的快进则拒绝继续。不尝试调和混乱的分叉——只是一个要么通过、要么停止运行的确定性检查。但比两个修复都更持久的变化是它们迫使的一次重新设计。旧流程在存在证明其合理性的工作之前就提交了协调状态，留下了两个可能不一致的副本。现在状态位于它所产出的分支上，并在合并时与代码一起着陆——那是它们保证同时到达的唯一时刻。一个任务文件的复选框、它的待办→进行中→已完成状态、特性注册表的待定→已实现翻转，都位于工作分支上，而不是提前活在main分支上。回报是：一次失败的运行现在成了空操作。如果委派的工作树中途死亡，main分支从未见过它半完成的状态，因此无需调和。main分支只说它之前说过的话，而且仍然正确。它要么合并了，要么没合并。这个特性才是关键，也是这里我唯一要告诉任何构建并行智能体工具的人去复制的东西：不要在超前于工作的地方具体化协调状态；设计使得被遗弃的智能体不留下需要清理的混乱。
底层的姿态
第一篇帖子中的框架批评仍然成立：ArDD不会为你做架构判断，将来也不会。变化只是更窄了。