Spec

我最近在整理一套 spec-driven 的 AI coding 流程，叫 agent workflow。 它解决的不是“哪个模型写代码更强”，而是另一个更实际的问题：需求、实现、验收如果都挤在同一个长对话里，最后很容易分不清到底是 spec 模糊、实现跑偏，还是验收只是在迁就已经写出来的代码。 agent workflow 的做法很简单：把角色拆开。 Claude 负责把模糊需求拷问成 spec 和可执行 issue，实现时负责钉死 spec、复审和验证；写代码的活交给 Codex 的 gpt-5.6-sol，验收判定也由它在另一个干净线程里做。两个模型之间不靠聊天记录交接，只靠两样东西：GitHub Issues 和仓库里落盘的文档。 整条链画出来是这样： 入口（三选一） 一般需求 → /grill-with-docs 烤问对齐，术语进 CONTEXT.md，决策进 ADR 雾大的活 → /wayfinder 在 tracker 上建图，多会话逐张解雾 外部 issue → /triage 状态机分诊，产出 ready-for-agent │ Claude：把想清楚的东西固化成规格 /to-spec → spec issue：目标、非目标、验收标准、测试 seam /to-tickets → 垂直切片 tickets，每张标 blocked-by │ ├─◄ 交接面：GitHub Issues + repo docs │ 不是聊天记录。所以每一步都能换会话、换模型 ▼ /implement-codex #N Claude 钉死 spec，在约定 seam 写红测，选推理档 │ brief：issue 原文 + 红测 + 仓库约定 + 验证命令 ▼ Codex 冷启动线程：写代码、跑测试。不 commit、不 push │ 工作树 diff，这是它唯一的输出 ▼ Claude 不信它的汇报，自己跑 typecheck 和全量测试 /code-review 审 diff ① Claude 审 Codex 的代码 commit 引用 #N。到此为止不 push、不关单 │ ▼ /accept-issue #N（硬规则：必须新会话，不能是实现会话） Codex 法官：跑 verify 入口，用测试没用过的输入实测行为， 逐条裁决并附上命令和输出 ② Codex 审 Claude 的 spec Claude 书记员：只查形式。缺证据就打回，不脑补，不推翻裁决 │ ├─ 通过 → /land-issue #N：push、留验收摘要、close └─ 不通过 → 写回 issue 保持 open，交给下一个冷启动会话 跨模型检查是双向的： ① code-review 阶段，Claude 审 Codex 写的代码 ② 验收阶段，Codex 审 Claude 写的 spec 下面提到的 skill 我都放在这个仓库里，多台机器之间同步用：https://github.com/sleepingF0x/skills ...