Spec文档太大？要分层分场景

在AI Coding的团队落地过程中，一个普遍却容易被忽视的问题是：瓶颈往往不在代码生成本身，而在代码生成之前的各方对齐。PM提出一个需求，研发在AI IDE中开始编写Spec和代码，写到一半发现某个字段的含义与PM预期不符；测试拿到功能后发现验收标准与需求存在偏差。这些场景揭示了一个核心矛盾：AI IDE面向开发者设计，它无法理解PM的业务规则应该对应哪个接口字段，也不清楚测试用例是否覆盖了所有验收标准。

三级分级的核心逻辑

基于这一洞察，Spec分级框架应运而生。该框架定义了一套团队协作的Spec规范体系，包含三大核心要素：文档模板定义「写什么」，三级分级定义「写多细」，交叉校验定义「怎么算对齐」。整个文档体系由14份文档组成，覆盖从需求采集到测试追溯的完整链路，包括需求来源与采集记录、立项提案与范围说明、产品需求说明PRD、用户故事与验收标准US+AC、功能规格说明FSD、非功能需求与约束、系统架构与技术选型、API接口规格、数据模型与存储规格、安全设计规格、实施计划与里程碑、测试策略与质量门禁、需求追踪矩阵RTM等。

文档分工与交叉校验机制

并非所有需求都需要完整的14份文档。根据需求的风险等级，框架设计了三种不同的处理模式：L1轻量级适用于单团队可独立判断和完成的事项，如修改文案、增加展示字段等，准入条件为只涉及一个团队、不影响已有业务规则、不涉及合规、回滚时间不超过30分钟；L2标准级适用于需要PM、研发、测试三方配合但不出系统边界的新增功能，核心环节是一场30分钟的对齐会，三方逐条确认业务规则与API字段的对应关系、验收标准与测试用例的覆盖情况；L3重量级适用于跨系统数据链路改造、监管合规变更等高风险场景，核心理念是「文档先行，门禁兜底」，开发必须在文档完成并冻结之后才能启动。

AI工具的精准定位

在整体分工上，PM负责02-05号文档（需求来源、立项提案、PRD、用户故事与验收标准），研发负责06-11号文档（功能规格、非功能需求、架构、技术选型、API、数据模型、安全设计），测试负责13-14号文档（测试策略与质量门禁、需求追踪矩阵）。文档冻结后，AI IDE直接消费09号API接口规格和10号数据模型与存储规格来生成代码，而完整的14份文档则用于校验逻辑严谨性，让复杂的产品功能模块能够通过文档清晰表达业务逻辑。

十项Skill降低文档生成成本

为降低文档生成的人工成本，框架提供了10个AI Skill，每个Skill负责特定文档的初稿生成。例如@mumu-spec-r1-proposal负责需求采集结构化到立项提案再到PRD的文档生成，@mumu-spec-r2-align负责US+AC和API双面对齐，@mumu-spec-r3-design负责架构、数据模型、FSD、非功能、安全等设计文档。AI写初稿、人工审核确认，被认为是最高的文档生产效率模式。团队可以根据实际需要自定义每个Skill的Prompt和输出格式。

如有侵权，请联系删除。