跨团队统一规格

问题：规格在交接处断裂

跨团队协作最常见的失败模式，不是没人写文档，而是文档各自为政：产品写的是故事，开发读的是接口，QA 看到的是边界条件。结果下游各自脑补，等到验收时才发现 REQ-* 没有对应的 AC-*，或者测试用例是孤立的孤儿。Accord 要解决的，就是这种「规格在交接处断裂」的问题。

另一个被低估的代价是返工：CMG SEI 的数据表明，需求阶段的缺陷如果在后期才暴露，修复成本是需求阶段的十倍以上。Knight Capital 的 440M 美元亏损，根因就是限流这类跨功能约束在 L1 阶段被推迟，直到上线才暴露。

技能如何工作

Accord 不写代码、不画 UI，它只做一件事：把一个规格从愿景一路走到验收标准，并且让每一步都可追溯。

核心流程按 L0→L3 分阶段展开：

• L0 Vision：一页纸说清楚做什么、不做什么，以及为什么
• L1 Requirements：拆出用户故事，每个故事 3-5 条 AC-*，同时把跨功能需求（CFR）显式列出
• L2 Team Detail：按角色分视图，Biz 看业务规则、Dev 看技术约束、Design 看用户流程，但保持同一个 truth source
• L3 Acceptance Criteria：用 BDD 的 Given/When/Then 写可执行验收标准，每个场景只测一个业务行为

关键约束是双向可追溯性：REQ-* → AC-* → SC-* 形成完整链路，测试用例能反向追到需求，需求也能看到自己被哪些场景覆盖。Full 模式下还需要生成 .traceability.yaml 台账，初始状态全部 NOT_TESTED，由下游工具验证。

BDD 在这里不是测试工具，而是对齐工具。三条硬规则：场景必须用业务语言（不写 DOM 选择器或 SQL）、必须通过 Three Amigos 评审（产品+开发+QA）、每个 Rule: 块只描述一条业务规则。超过 12 个场景或单故事超过 7 条 AC，就该拆分而不是堆砌。

适用边界与注意点

Accord 不做的事很明确：不写实现代码、不画视觉稿、不做架构决策。L2-Dev 里的技术选型必须交给 Atlas 或专门的架构技能，L2-Design 里的线框图必须交给 Vision。Accord 只负责把决策点标出来，不替人做决定。

适用场景是：多个团队需要基于同一份规格工作，或者下游有 AI Agent（Builder/Radar/Voyager）要消费这份规格。如果只是一个 PRD 文档，用 Scribe 更合适；如果直接写代码，用 Builder。

还有一点容易被忽略：LLM 生成的需求不能直接入库。研究显示，LLM 会系统性遗漏领域约束，还会编造不存在的假设。Accord 强制要求所有 AI 草稿的需求经过 Three Amigos 评审后才能写入 L1/L2，这是防止自动化偏见的关键闸门。