北京
几周前，我还在反思自己缺少纪律性，于是动手做了一个工具来弥补这个短板。这个工具叫 ArDD，本质上是一套为 Claude Code 内置的技能脚本，它能推着项目走完需求文档、计划和任务清单，而不是让一个智能体从一句提示直接跳到写代码的步骤。那篇文章结尾，我留下了一个疑问：说到底，这会不会只不过是一个包装漂亮的 CLAUDE.md？
直到目前，ArDD 只有我一个人在用。所以接下来这些记录，更像是刮掉了私密细节的内部决策复盘。但这件事教会我的东西，完全超出了这个工具本身。更重要的是，如果我没有实际运行它，而是反复读代码，就永远看不到这些教训——它们只出现在真实的执行现场里，藏在代码审查永远扫不到的那一层。
ArDD 的核心循环是“计划→任务→实现”，其中“实现”环节可以把工作分发给一个子代理，这个子代理跑在自己专属的 Git 工作树里。这样就不必盯着单线程的代理一步步推进。原始设计在交接上小心翼翼：在委派子代理之前，先把一部分粗略的状态——比如计划和任务清单——提交到主分支。我的逻辑是，分出去的工作树需要一个稳定、已经落地的基点来创建分支。
这个逻辑错了。发现错误靠的不是对设计的信任，而是一次实打实的冒烟测试。我先提交了一份用完就丢的计划和任务文件，接着把工作委派到一个全新的工作树里，然后直接检查这个工作树内部到底装着什么。
结果对不上。工作树是从 origin/main 分支出来的，里面根本没有我刚刚在本地做的两次提交。这套自动化骨架在创建工作树时，用的是远程跟踪分支，而不是本地的 HEAD，而这个行为在技能的说明文字里完全没法操控。更麻烦的是，根据问题跟踪器里的记录，不同版本的骨架在这点上的行为还会翻转——所以“默认拉取最新”和“默认保持同步”两种假设，都是错的。唯一可靠的姿势是：先验证，永远不要假定。
同一次运行还暴露了一个我至今解释不了的问题。创建工作树的动作，居然把我主工作区的 Git 配置项 core.bare 改成了 true。这会让普通 Git 命令在那个工作区里直接坏掉，直到我注意到并手动改回来为止。git worktree add 理论上根本没有权利去动调用它的那个工作区的配置，而我也始终没找到触发机制。既然找不到根源，我就不假装去修复它。现在的协调器会在每次委派运行之后检查这个配置项有没有再次被篡改，一旦就发警报。用一道绊马索去应对一个无法解释的骨架级 Bug，这称不上修复，我也不打算把它叫作修复——但一个会大声报警的“已知未知”，总好过一个沉默的“未知未知”。
针对工作树分支与本地不一致的问题，我写了一个小脚本 worktree-align.sh，作为每一个被委派的子代理必须执行的第一项任务：把本地的默认分支快进合并到新工作树的分支里，如果做不到干净的快进，就直接拒绝继续运行。这里没有尝试去调和五花八门的分歧，只做一次确定性的检查——要么通过，要么停止整个进程。
比这两项修复活得都久的，是由它们逼出来的一次流程重设计。按照作者原本的设计，工作流会先将协调状态提交到主分支，然后再……（此处原文记录不完整）。最后定下的方案，把协调状态挪到了工作树内部，不再依赖主分支的提交来传递。这次重设的根由很清楚：当“运行前提交状态”的设计被事实证明不可靠之后，唯一能信任的，就是从运行现场拿到的实时数据。
整个事件链条给出了一条朴实但常被忽略的经验：很多行为偏差写在骨架的版本差异里，写在 runtime 的副作用里，唯独不会写在代码的静态文本里。你不可能靠盯着 CLI 参数说明或者脚本源码，就猜出工作树究竟会从哪个分支分叉，更猜不到它会偷偷修改一个看似无关的配置项。只有让程序完整跑一遍，再去检查它实际生产出来的每一个产物、每一个残留状态，才能把这类问题从沉默的暗处拽到明处。这也解释了为什么这条教训很适合从个人工具里长出来——因为如果没有亲自运维的执念，没有对着实际输出刨根问底的下意识，这些 Bug 可能永远埋在自动化流程的底层，偶尔炸一次，然后被归为“环境问题”一笔带过。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
