从「更会写」到「敢合并」：AI 编程可闭环协作方法论

过程轨、结构轨与 Epic 验收如何叠放 系列《AI 编程可闭环协作》· 方法论地图

## 目录

---

摘要

AI 写代码的交付质量，常见瓶颈 不在模型够不够强，而在两件事没补齐：改哪里、会影响谁 的结构化上下文，以及 何时算做完、凭什么合并 的验收闭环。

本方法论用两条 正交轨道 叠放：

结构轨（技术图谱：入口、依赖、契约与机器可核对）回答「从哪进、动哪片」；

过程轨（任务单、书面签收、合并前检查等 协作落点）与 结构轨（技术图谱）如何叠放，后文 §2 说明；Inform / Constrain / Verify 三支柱源于 规格驱动开发（SDD），后文 §3 展开。Harness 一词在本系列中指两种相近概念：业界讨论的 Harness Engineering（驾驭工程），以及本连载具体化的 「Harness 协作流程」（任务单、阶段流、合并前检查等）。后者是 实践 SDD 的一种工程化路径，不是 三支柱的定义来源。

过程轨回答「本趟敢不敢合、谁负责」。一轮有边界的交付（下文称 Epic）至少具备 意图、成果、验收 三要素；缺验收就不算收尾。

合完之后，可把教训 可选 蒸馏成经验卡片、团队 Skill 或 跨轮回顾摘要——它们像路口上的警示牌，不替代 地图与关卡。操作实例、对照实验与存量案例在连载 卷一～卷五；本文只给 可迁移的原则地图。

---

1. 问题陈述：失败常不在模型

许多团队已经习惯：自然语言描述需求 → Agent 改文件 → 人眼看 diff → 合并。然而即便换用更强、更贵的模型，往往仍会遇到：

这些问题与「会不会写代码」有关，却 **不能** 单靠 Prompt 技巧或事后炼 Skill 根治：Skill 记住的是 **习惯与教训**，若在一次任务中 **既没有技术图谱，也没有验收门禁**，仍可能漏改、仍不敢合并。

与模型能力解耦：同一份任务单、同一张子图、同一套合并前检查，换 Auto 里不同档位的模型，交付口径仍可对齐——工具会变，意图 / 成果 / 验收 不应随模型脾气漂移。评测与 Mentor 类工作尤其需要这一点：你要教的是 可测的题面 + 可签收的结论 + 可复盘的轨迹，而不是某次对话里模型「看起来懂了」。

---

2. 双主轴：过程轨与结构轨

与 §3 的分工：双轨 是本系列的两类 落点（图谱 × 协作执行）；Inform / Constrain / Verify 来自 SDD（§3）。Harness 是落实 SDD 的 工具/纪律层之一（任务单、阶段流、CI），勿与 SDD、勿与「过程轨」混成同一个词。

### 2.1 各答一问

说明：结构轨表格中的 CI 指 图谱 CI——入口清单、契约锚点等 结构文档与代码一致性 的自动检查，不是替代合并前业务测试的流水线。

两条轨 **正交**：同一 Epic 里，你可以既有「图谱入口：从登录子图进入」，又有「验收：单测 + lint 全绿 + Tech Lead 书面签收」——**指标不混表**（不能用「对话很短」代替「检查绿了」）。

2.2 只炼 Skill 或只上 CI，各缺什么

本系列主张：**结构进图谱**；**过程侧按 SDD 三支柱落实**（任务单、签收、合并前检查，见 §3），其中 **Harness 协作流程** 是常用 **工具层**；合完后 **可选** 把习惯与决策炼进 Skill 或 **跨轮回顾摘要**（详见 §5）。

2.3 一段比喻（可选理解，非规范定义）

可以把协作想成工地运输：技术图谱 是带方向的道路图，规定从哪扇门进、会连到哪些工区；Agent 默认只领 一小张局部地图（具体形式见连载 卷二 §9），而不是背下整座城市。关卡 对应 SDD 三支柱里的 Verify（及过程轨上的签收）：检查绿了没有、审查签了没有，过关才上主路。经验卡片或 Skill 是路口上的 警示牌——目的地仍在图上的 入口节点，不在牌子上。

---

3. SDD 三支柱：Inform · Constrain · Verify

规格驱动开发（Spec-Driven Development，SDD） 强调 先规格、后实现：用可执行的说明（Spec / 任务单）明确行为边界，再改代码，并以检查证明对齐。卷一的 意图 · 成果 · 验收 与 SDD 同向；卷三标题里的 「Harness 与 SDD」 指：SDD 是上层方法论，Harness（协作流程、阶段流、合并前检查）是 把 SDD 落到 AI 协作里的一种工程化路径——不是 三支柱的定义来源。

Inform（告知）· Constrain（约束）· Verify（验证） 是 SDD 语境下组织协作的 三支柱（卷一写作「告知 · 约束 · 验证」）。它们回答：开工前 告知 够不够、执行中 约束 能否核对、合并前 验证 能否重复。本系列 不发明 第四支柱；双轨（§2）只是把 SDD 三支柱 落实 到两类落点：

SDD（规格驱动 · 上层方法论）
  └── ICV 三支柱（Inform / Constrain / Verify）
          ├──► 结构轨 · 技术图谱
          └──► 过程轨 · 任务单、签收、合并前检查
（过程轨上常经 Harness 协作流程、Harness Engineering 等工具落实，非 ICV 的子节点）

图 1 · SDD、ICV、双轨与 Harness 的归属（Harness 落实 过程轨，不是 与 ICV 平级的第四支柱）：

### 3.1 易混：SDD 与 Harness Engineering（驾驭工程）

二者 协同，但 不是同一套东西。SDD 讨论里也会出现「约束」「验证」等词，通常指 规格本身应具备的特征；而 ICV 在本系列中指 工程里可执行的组件与纪律（任务单字段、CI、签收），勿混读。

Harness Engineering「典型口号」一句为 业界讨论，非本系列独创。

**为何容易混（三条）**：

1. SDD 讨论里也会出现「约束」「验证」——多指 规格应具备的特征，不是 Harness 里的工程组件名。
2. Harness 是实践 SDD 的路径之一（尤其把 Verify 落到 CI、签收），不是 Inform / Constrain / Verify 的定义来源。
3. Harness Engineering 更像 独立工程话语，可与多种开发流程结合；本连载的「Harness 协作流程」与之同向，但落盘在 任务单 + 阶段流 + 检查，不绑定某一商业产品。

类比（秒懂）：SDD ≈ 合同 + 验收标准；Harness ≈ 工地 闸机、巡检、签字——前者定交付与怎么验，后者把纪律落到协作现场（见图 1）。

「Harness」兼指业界 Harness Engineering 与本连载 任务单 + 阶段流 + 检查（卷三）。图谱轨 服务 SDD 的 Inform / Constrain（读哪里、契约一致）。

**Verify 加厚（评测向）**：Mentor 或评测团队关心的是 **验收证据**——验收项能否被测试或检查 **证伪**；协作过程是否留下 **可复盘轨迹**（谁、何时、基于什么材料签收）。这与「多堆对话日志当训练数据」不是一回事：日志若没有对齐 **意图 / 成果 / 验收**，很难还原「当时什么叫做完」。

轨迹表述（抽象）：开工前有任务依据；合并前有检查结论；关键节点有 书面记录（可检索，而非仅聊天窗口）。不用 合并率、单次 token 账单或「感觉差不多」充当 Epic 收尾标准。

与「只堆对话数据」的边界：训练或评测若只收集长对话，往往难以还原 当时 的验收标准与非范围。过程轨要求把 可失败 的验收项写进任务单，并把 检查结论与签收 留在仓库可检索处——这样事后分析的是 交付决策链，而不是聊天记录里的语气与猜测。

粒度对照（Mentor 向）：

---

4. Epic：意图 · 成果 · 验收

Epic 在本文中指：有边界的一包工程交付，而不是和模型无限续聊。它可以对应产品上的一个主题，也可以对应仓库里 一条任务链（一个主任务单 + 若干关联子任务）。再小的单次改动，也建议 具备三要素（可写在同一张任务单里）：

**任务单** 是 Epic 内更小工单的常见载体；**验收不可省**。任务单 + 签收在本系列里也称 **本轮交付依据**（即本轮 **唯一可信的「做完」依据**——以书面记录与检查为准，而非聊天结论）。

专题收尾（合并后的归档、可选摘要编译）属于 合之后 的纪律，见连载卷四；合并本身不自动生成 跨轮回顾摘要。

图 2 · 一轮 Epic 的简化交付链（端到端心智模型；不是 卷三完整阶段流或卷二主图+子图细节）：

4.1 迷你题集示例（虚构 · 泛化）

下面 一题 展示「题集 / 作业」应如何写清三要素——可迁移写法，不是 某仓库的真题，不可整包照搬为你们的基准集（见 §6）。

题：为公开 HTTP API 增加按 IP 的速率限制

评测读者可据此检查：题面是否 **可测**、预期结果是否 **可验收**、失败是否 **可记录**——而不是只有「模型改得像样」。

---

5. 记忆轨与 Skill 的边界

Skill、编辑器 Rules、经验卡片，在本框架里属于 习惯层或 Constrain 的延伸：减少重复 Prompt，统一命名与测试顺序。它们不替代：

• 结构轨：改架构仍要 改图谱（PR 顺手维护），不能只加 Skill；
• 过程轨：合并前检查 + 书面签收 不能省——在平台上点一下 Approve 不等于 本系列意义上的交付。

跨轮回顾摘要（从已收尾材料 编译 出的 Epic 级决策页）帮助半年后少翻冗长留痕；不是 产品 Wiki 全文，不能 代替图谱做影响分析。与 LLM Wiki、PRD 的分工，连载卷四 有表；此处只记一句：摘要/Wiki 层不替代「敢不敢合」的闸。

冷 / 温 / 热 在连载里指 协作记忆分层（结构地图 / 协作轨迹 / 远期运行时记忆），不是 软件架构里的三层。不是 架构冷层、温层、热层——若团队内部另有同名术语，请在术语表写清映射，避免与系列混用（详见 卷五 §23.1；总论不展开）。

---

6. L3 → L2 → L1：什么能抄、什么不能

回应「能直接复制你们仓库吗」：**能抄纪律与题集写法，不能抄整包数字与目录。** 原则（L3）是离职后个人对多条项目实践的 **归纳**；此前所在团队 **并未** 形成与本文等价的完整体系——本文是可迁移的 **通用工程协作框架**，不是某司内部制度说明。

---

7. 与 TDD、Code Review、DevOps 的关系

• TDD / 单测：仍负责「行为对不对」；本方法论负责「这次改动 有没有测试策略、失败路径写没写、敢不敢合并」。契约检查绿了，仍可能 行为逻辑错——门牌号对了，屋里逻辑还要靠测试（连载卷五 FAQ 有对照）。
• Code Review：过程轨（Verify + Inform）把「聊过」变成 可检索的审查记录；图谱让 Reviewer 更快看 影响面。
• CI/CD：Verify 的硬背压；Agent 自检 不能 代替流水线。
• Jira / 飞书工单：产品沟通层；任务单是 工程交付依据——宜 叠加，不宜再搞第三套互相打架的流程（存量降级见卷三）。

叠加，不替换：你没有 TDD 或 CI，应先补 「验得动」（哪怕先是手动门禁写进任务单），再谈 Agent 规模化。

---

8. 阅读地图：五卷各答什么

读完本文，可按处境选连载（均 无卷号依赖 于本篇，但卷二起建议顺序阅读）：

系列版本与发表链接见 [OUTLINE](../ARTICLE_AI_Coding_可闭环协作_公众稿_OUTLINE_v1.0.0_zh.md)。

---

9. 诚实边界：本系列不承诺什么

本方法论 **不** 绑定某一品牌 Agent、**不** 把 OpenSpec / 特定编排工具写为标配；能力等价物是 **任务单 + 测试/lint + 契约或入口检查**。

---

10. 结语

若你只想用 15 分钟建立全局心智：读完本文即可知道 SDD 与 ICV 三支柱、Harness 在其中的位置、双轨叠放、Epic 三要素 与 五卷分工。

若要动手：新读者从 卷一 最小起步；要地图读 卷二；要敢合并读 卷三；要合后沉淀读 卷四；老项目直接看 卷五 阶段 0，但仍建议 浏览 卷一～卷三要点。

SDD 定规格与验收，结构进图谱，过程经 Harness 等落实 ICV，习惯与决策合后再沉淀。 先认路，再干活，过关放行，再可选挂牌。

---

许可：CC BY 4.0 · 署名可转载与改编 · 系列文稿：ai-coding-closed-loop-articles