用任务图和文件验收驱动 AI 交付

让一个 AI 会话从头做到尾，启动很快，任务变大后却容易出现同一批问题：自己写代码、自己验收，测试难过就悄悄改目标，聊久了又忘记最初的约束。作者基于 Claude Code，把工单拆成固定步骤，由不同 Agent 接力完成，再用脚本检查磁盘上的证据决定能否继续。

这套个人工作流最有价值的部分，是把项目上下文、验收标准和交接记录从聊天里搬出来。它提供了一种可借鉴的工程方法，但还没有足够数据证明，多 Agent 一定更省钱或更可靠。

为什么先写项目文档，再编排 Agent

作者最初遇到的问题，很多都源于同一个地方：工作的唯一记录藏在会话记忆里。长会话经过压缩，早期细节可能丢失；换一个 Agent，之前讨论过的决定又得重新解释。

因此，作者先搭建了 harness，再做 graph。这里的 harness 可以理解为一套让新会话直接接手工作的项目说明、上下文、规则和检查机制。graph 则是建立在这套基础上的流程程序。

作者参考 Learn Harness Engineering 课程，把信息分成四层：

• 入口文件保持简短，说明项目做什么、怎样运行、怎样检查，并指向更详细的文档。作者分别维护个人、工作区和仓库层面的规则。
• 持续维护的文档记录架构、代码归属、编码规范及功能设计，代码变化时同步修改。
• 每个调查过的工单都有独立目录，事实关联到文件和行号，再用索引帮助后续会话定位。
• 进度文件记录计划、审查结果、决策、下一步和阻塞原因。

当聊天和文件冲突时，以文件为准。

不过，文档还需要检查机制托底。作者把 lint、test、type-check 放进完成条件，并通过 hooks，也就是工具动作前后执行的小脚本，阻止常见的绕过行为。

作者还采用一个很容易复用的检查办法：新开一个会话，只给仓库，让它回答项目和当前工作的基本问题。凡是需要猜的地方，都说明上下文存在缺口。先补这些缺口，再增加 Agent 数量，才有意义。

一张流程图，怎样让工单走到草稿 PR

作者把职责分给三个角色：graph 保存路线并检查证据；driver 是一个 Claude 会话，严格执行 graph 输出的下一步；各阶段 Agent 负责写规格、实现代码或审查，每次都是全新会话。

这里的 graph 是普通程序。它不写代码，也不评价方案；给定相同的磁盘文件，就输出相同的下一步。需要判断的工作放进具体阶段，推进流程的程序保持确定性。

输入工单编号和基线分支后，工单经过四个阶段，最后停在 draft pull request。路径会按类型分叉：bug 先复现再写规格；spike，也就是研究型工单，以书面结论结束。

其中，最重要的约束发生在写代码之前。

首先，Agent 编写规格和验收标准。签核后，程序对验收标准那一部分计算 hash，后续再比对，防止实现遇到困难时偷偷改掉「完成」的定义。其次，另一个 Agent 检查目标是否正确：即使所有验收条件都满足，是否真的解决了工单的问题？如果没有，就在投入开发前停下来。

实现阶段分为 UI 和其他工作两条流水线，两者都要求先写失败测试，再写代码。修改代码的阶段之后，由没有看过构建过程的新 Agent 审查，避免作者自己给自己打分。

Agent 说完成不算完成，证据文件通过检查才算。

脚本会检查文件是否存在、是否在当前步骤期间生成、是否包含必要章节，以及是否以通过结论结束。旧文件不能直接冒充本次结果。每个循环有次数上限，每个步骤有截止时间；无法继续的工单会记录原因并暂停，其他工单继续运行。

最终只为通过检查的那个 commit 创建独立分支上的 draft PR。转为可审查状态、添加 reviewer 和合并，仍由作者负责。等待依赖工单合并、等待空余 PR 名额时，则交给后台脚本，不让模型持续运行。

如何减少打断，又控制模型开销

每个步骤启动前，一个小型 sizing Agent 会根据简短任务说明选择模型和 effort level。重命名这样的任务使用较小模型，复杂设计判断使用较强模型。driver 不参与选择，避免它承担额外判断。

失败后的升级顺序也固定：先提高同一模型的思考强度，再换更大的模型。但程序会先区分失败原因，检查 transcript 和启动记录。缺少 worktree 属于执行环境问题，不能靠换更贵的模型解决。

模型选择会被记录，但验收检查不能读取这个选择，防止模型对任务难度的猜测反过来影响是否通过。每步还会留下成本记录，stats 命令据此统计工单花费和升级次数。

这仍有一个盲区：大模型成功完成的步骤，可能小模型也能完成，日志无法提供这个反事实。作者承认，失败容易观察，过度使用大模型却很难从现有记录里识别。

减少人工打断则靠 first mate。这个 Agent 使用作者手头最强的模型，先依据代码、文档和书面规则处理问题。只有涉及作者意图、优先级或权限的真正阻塞才升级给人，并附上选项和推荐答案。

规格默认也由 first mate 签核；项目设置可以改回人工签核。运行结束后，作者集中复查已记录的决策，不同意就推翻，并从较早步骤重跑。

作者还把「实施与审查分离」推广到普通会话，用 implementer、reviewer 角色标签帮助守卫判断最后一次修改之后是否发生过审查。不过，两道守卫都采用 fail open：守卫自身出错时允许动作继续，以免冻结会话。这是可用性上的取舍。

我的判断

我赞同把上下文落盘、提前锁定验收标准，以及让新的会话独立审查。这些做法分别处理了交接、目标漂移和自我确认问题，即使不搭完整 graph，也可以单独采用。

但文件检查能证明的事情有限。文件存在、章节齐全、末尾写着通过，不等于代码正确；hash 能防止验收标准被静默修改，也不能保证最初的标准足够好。作者增加「目标是否正确」的审查很合理，最终仍要看测试质量和审查依据。

新 reviewer 没有参与实现，能减少对原有推理的依赖，却仍可能与 implementer 共享同一种模型偏差。原文没有提供缺陷率、返工率、人工耗时或总成本的对照数据，因此「更可靠、更便宜」目前只能视为作者的经验判断。

first mate 同样依赖前提：项目规则足够完整，而且部分决策允许事后纠正。一般团队里的业务优先级和授权边界未必能从仓库推导出来，不能直接照搬默认签核方式。

作者用约一周从第一个命令行入口推进到无人值守运行，系统仍很年轻。最多三个完整会话并行、轮流使用共享开发环境进行手工测试，还只是计划。事件日志逐行串联，可以暴露历史被修改的迹象，但作者也明确说它不是安全屏障。

与单会话相比，这套方案增加了交接和编排成本。对小改动，收益未必覆盖这些成本；对经常跨会话、需要反复验收的任务，它更值得尝试。

能拿来做什么

• 先给前端或 Node 仓库补齐运行命令、检查命令、目录职责和当前工单记录，再用全新会话验证它能否接手；把它需要猜测的内容补进文档。
• 在下一次 AI 编程任务中，先让一个会话实现，再让新会话依据工单、代码差异和测试结果审查，保留可供后续读取的审查记录。
• 对容易发生范围漂移的工单，开发前写清验收标准，并检查这些标准是否真的解决原问题；需要调整时明确记录原因，避免实现过程悄悄改变目标。
• 如果开始编写自动化流程，就为步骤设置输出文件、超时、重试上限和明确的停止条件，并把等待交给普通脚本，先验证这些基础机制再扩展模型调度。