MumuSpec各角色协作全景图，让每一个角色都找得到自己的位置

当 PRD、FSD、API 文档、测试用例各自散落在不同地方，跨团队协作就像在迷雾中行军。我们设计了一张 Spec 协作视图，让每个人都能看清全局。

一、为什么需要一张协作图？

在一个涉及产品、前端、后端、测试的研发团队中，最常见的痛点是：

• PM写完 PRD，不知道开发有没有看懂
• 前端拿到 FSD，不确定后端 API 是否匹配
• 后端设计完数据模型，发现和 PRD 的业务规则对不上
• 测试拿到需求，AC 早就过时了

这些问题的根源不在于某个人不努力，而在于 信息没有在同一张画布上对齐。

我们的答案是：Spec 协作视图——以一份统一的 Spec（规格文档）为唯一真源，将四个角色、四个阶段、六个自动化校验点串联成一条清晰的主线。

二、四条角色线，各有其责

📋 PM/ 产品

产出：PRD → 业务规则 → 用户故事 + 验收条件

PM 是需求的发起者。从立项到 PRD 再到 US+AC，PM 负责把业务需求拆解为可执行的规格。这份输出是整个协作链条的起点，也是后续所有人对齐的基准。

🎨 前端工程师

产出：FSD（前端规格文档）

前端以 Spec 为唯一真源，依据 FSD 实现前端代码。不再需要在群聊里翻聊天记录确认交互细节——Spec 里写清楚了，就看 Spec。

⚡ 后端工程师

产出：API 文档 + 数据模型

后端同样以 Spec 为唯一真源。每一个接口字段、每一条数据模型，都要能回溯到 PRD 中的业务规则。没有 Spec 背书的设计，不上线。

🧪 测试工程师

产出：测试策略 + 追溯矩阵

测试从 Spec 中提取 AC，设计测试用例，验收通过后将结果回写至 Spec。更重要的是，每一条 AC 都必须有至少一条测试用例覆盖——这是质量的底线。

三、一条 Spec 主线，贯穿始终

Spec 本身按阶段组织为四大模块：

需求定义 → 方案设计 → 技术实现 → 验证交付

每个阶段包含若干文档（共 14 份），从 01 总则到 14 追溯矩阵，形成完整链路。

其中，标注 橙色底边的文档是需要「拉会对齐」的——这些文档涉及多方交叉引用，必须在会上逐条确认。

四、拉会对齐：把分歧消灭在会前

需要拉会对齐的文档包括：

• 需求定义阶段：03 立项、04 PRD、05 US+AC
• 方案设计阶段：06 FSD、08 架构
• 技术实现阶段：09 API、10 数据模型
• 验证交付阶段：13 测试策略、14 追溯矩阵

对齐会不是「读文档大会」。会议要求：

1. 相关方提前阅读对应文档
2. 会上只讨论交叉引用处的不一致
3. 逐条确认，由 Skill 自动校验

五、Skill 自动校验：六个节点，六道关

人脑会漏，但自动化不会。我们在协作流程中嵌入了 六个 Skill 校验节点：

只有全部通过，才能冻结 Spec。冻结后的 Spec，AI 才能读取并生成代码。

六、整体协作流程

① 各角色写草稿
      ↓
② 拉会对齐拍板
      ↓
③ 转 Spec 归档
      ↓
④ Skill 自动校验
      ↓
⑤ 门禁全部通过
      ↓
⑥ 冻结 → AI 读取 09+10 生成代码

整个流程像一个精密的生产线：

PM写入→ 拉会校准→ Spec承载→ Skill 校验→ 门禁拦截→ AI 产出

每一个环节的产出，都是下一个环节的输入。没有孤岛，没有遗漏。

七、写在最后

Spec 协作视图想解决的核心问题只有一个：

让每个角色在任何时候都知道：自己要做什么、别人在做什么、现在对齐了吗。

协作不是靠默契，而是靠机制。当 PRD、FSD、API、测试用例都在同一份 Spec 上对齐，当自动化校验在六个关键节点兜底，团队就不再需要靠「多问一句」来降低风险——因为系统本身就保证了信息的一致。

这份协作视图不是一天建成的，但它一旦跑起来，就是团队效率的倍增器。