企业级 AI Coding ｜ MumuSpec全自动演示视频，通过SKILL自动填充Spec文档

后端把 3 改成 5，上线后前端还显示"已领 x/3 张"，测试用例还在断言"第 4 次拒绝"。这个线上 BUG，每个研发团队都遇到过。

一、一个"3 改 5"，改漏了 5 个地方

运营说：618 加码，每人限领从 3 张改到 5 张。

后端开发者找到代码，把 limitPerUser = 3改成 limitPerUser = 5，提交、合并、上线。

三天后：

• 前端领券页还显示**"已领 2/3 张"**——UI 文案漏改了
• 用户领到第 4 张时居然成功了——测试用例还在断言"第 4 次应拒绝"
• API 文档示例请求体里还写着**"limitPerUser": 3**——联调时前端对着旧文档问"到底 3 还是 5？"
• 测试同学根本不知道需求变了——PRD 没人同步改，AC 没人更新

一个数字，6 份文档要联动。传统模式下，这 6 份文档的改动分散在 PM 的 PRD、开发的代码、测试的用例里，没人知道"改完没有"。

这就是我们做 618 · Skills 全景 MumuSpec 全景图的原因：把"改漏了"变成"没亮就是没改到位"。

二、14 份文档，是不是官僚主义？

看到"14 份"的第一反应一定是：我们写 1 份都嫌多，你搞 14 份？关键不在数量，在不混层。

如果你把 SQL 写在 PRD 里 | 数据库改了，PRD 就过期了 |

如果你把 UI 描述写在 API 文档里 | 前端改版了，API 文档就乱了 |

如果你把测试用例抄在产品规则里 | 规则变了，测试和规则一起过期 |

14 份文档的本质是：每份只装一类东西，改一件事只动该动的那几份。

回到"3 改 5"——知道动哪几份就够了：

• 04（业务规则）先改
• 05（AC）、09（API 示例）、06（UI 文案）、13（测试断言）联动
• 14（追溯矩阵）对账

不是 14 份全改，是 6 份联动。但你不写清楚这 6 份分别装什么，就永远不知道还漏了哪几份。

三、10 个 Skill，按重要性分层

不是所有 Skill 每天都用。我们把它们分成三层：核心轮次（建文档）、维护技能（改文档）、辅助技能（查文档）。

核心轮次：4 个，把空模板变成完整 Spec

这是每个项目必经的流水线。14 份文档不是按 01→14 顺序写的，而是分四轮逐步展开：

空模板
  ↓ R1（02→03→04）  采集纪要、冻结范围、写业务规则
  ↓ R2（05↔09）     用户故事与 API 互校准 ← 最关键的一轮
  ↓ R3（08+10→06+07+11）  架构、数据、交互、NFR、安全
  ↓ R4（12+13→14）  排期、测试用例、追溯矩阵终检

@mumu-spec-init· 建骨架

新项目一键创建 14 份文档骨架，每份自带元数据表（模块编号/名称/版本/状态）和章节结构。不用手动复制模板。

@mumu-spec-main· 总控路由

入口 Skill。你把会议纪要/需求/变更丢给它，它判断该调用哪个轮次 Skill。自己做路由，不直接写文档。

@mumu-spec-r1-proposal· 采集与立项

把散落的口头需求变成结构化的立项材料。

演示中输入两条原始素材：

同时写 03 立项提案，冻结 Phase 1 范围（活动管理/领券/试算/结算），明确不做清单（跨境支付、多租户运营 v2）。

这一步的价值：口头需求有了可追溯的编号。后续任何人问"限领 3 张是谁提的"，回到 02 的 S-01 就能找到一手来源。

@mumu-spec-r2-align· 双锚对齐（全文最关键一轮）

同时写 05 用户故事和 09 API 接口规格，确保需求和技术契约首次对齐。

这是最容易出问题的环节——产品和开发各写各的，最后发现对不上。这个 Skill 强制两边同时写、互相校验：

不混层规则在这里严格执行：

• 05 不写完整 JSON Schema（引用 09）
• 09 不写用户价值叙事（留在 05）

这一步的价值：AC 里的"拒绝"必须能在 09 找到对应的错误码。如果找不到，说明这个验收条款不可测试，当场暴露。

@mumu-spec-r3-design· 展开设计

按顺序写架构（08）、数据模型（10）、功能规格（06）、非功能需求（07）、安全设计（11）。

关键规则：数据模型字段必须与 09 API 的 DTO 对齐，10 的持久化字段能在 09 响应中找到对应。

@mumu-spec-r4-finalize· 收口终检

写实施计划（12）、测试用例（13）、追溯矩阵（14）。

每条 P0 需求必须有至少 1 个测试用例——不是建议，是门禁。

输出终检清单：

[ ] 每条 P0 US 在 14 有行
[ ] 每条 REQ 在 13 有 ≥1 TC
[ ] 09 示例请求/响应/错误齐全
[ ] 10 索引与约束齐全
[ ] 03 Phase 1 与 05 P0 范围一致

维护技能：2 个，日常用得最多

建好 Spec 后，日常 80% 的工作在这两个 Skill。

@mumu-spec-sync· 变更联动（最高频）

回到开头的"3 改 5"。这个 Skill 自动判定变更类型、列出联动顺序、按序修改：

不同变更类型有不同的联动顺序：

这一步的价值：传统模式靠经验记"改了这个还要改那个"，MumuSpec 靠规则。改了 04 的 R-02，联动清单自动出来，少改一份就是少亮一格。

@mumu-spec-tasks· 任务拆分

把 05 用户故事拆成开发任务，按依赖排序：

T-001: 创建 CouponClaim 表及索引        [数据]  2h
T-002: 实现 POST /coupons/receive 接口   [后端]  4h  ← 依赖 T-001
T-003: 实现 limitPerUser 校验逻辑       [后端]  2h  ← 依赖 T-002
T-004: 前端领取按钮 + 已领计数展示       [前端]  3h  ← 依赖 T-002
T-005: 编写 TC-009~012 单元测试         [测试]  3h  ← 依赖 T-002, T-003

辅助技能：3 个，查状态、跑质量

@mumu-spec-check· 质量检查

四项维度扫描 01-14：

@mumu-spec-status· 版本看板

扫描所有文档的元数据，输出版本状态：

📊 Spec 状态看板
项目: 电商618促销    最后更新: 2026-05-16

01 写作总则  v1.0  Approved
02 需求来源  v1.1  Review
04 产品需求  v1.1  Review   ← 变更进行中
05 用户故事  v1.2  Draft    ← 变更进行中
09 接口规格  v1.2  Draft    ← 变更进行中
13 测试策略  v1.0  Approved

四、用SKILL之前 vs 用SKILL之后

五、这个全景图的实际用途

六、一句话

MumuSpec 不是人从头写到尾的，是 Skill 按轮次、按规则、按链路往 14 份文档里填出来的。

空模板 → R1 采集 → R2 双锚 → R3 展开 → R4 收口 → 变更联动 → 质量检查。

改一个数字，6 份文档联动，少一份就没点亮。不靠嘴说，靠亮不亮。

《企业级AI Coding成熟度模型》PDF已开源至GitHub，这些资料也会逐步同步到GitHub

https://github.com/lvzhaobo/mumu-coding/

图片