夜雨聆风后端把 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 份文档的本质是：每份只装一类东西，改一件事只动该动的那几份。
| 文档编号 | 它装什么 | 不装什么 |
| 01 | 编号规则、写作铁律 | 业务内容 |
| 02 | 会议纪要、邮件、访谈原始记录 | API、字段 |
| 03 | Phase 1 交付块、范围简表 | SQL、接口 |
| 04 | 用户场景、业务规则（带数值） | 前端像素、数据库 |
| 05 | 需求编号、用户故事、AC 验收条款 | JSON 示例 |
| 06 | 前端展示文案、错误提示、交互行为 | 业务规则原文 |
| 07 | 性能指标、可用性目标 | 功能逻辑 |
| 08 | 组件划分、部署架构、技术选型 | 代码实现 |
| 09 | 端点路径、请求/响应字段、错误码 | UI 文案 |
| 10 | 表名、字段名、类型、约束、索引 | HTTP 状态码 |
| 11 | 认证、授权、敏感数据处理 | 业务规则 |
| 12 | WBS 分解、排期、里程碑 | 技术细节 |
| 13 | 测试用例编号、断言条件、边界值 | 产品规则 |
| 14 | 正向追溯行（REQ→US→API→TC） | 正文 |
回到"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· 采集与立项
把散落的口头需求变成结构化的立项材料。
演示中输入两条原始素材：
| 素材 | 写入文档 | 产出 |
| 运营："618 前要完成活动配置和券发放" | 02 需求来源 | S-01 会议纪要条目 |
| 产品："每人限领 3 张券" | 04 产品需求说明 | R-02: limitPerUser = 3 |
同时写 03 立项提案，冻结 Phase 1 范围（活动管理/领券/试算/结算），明确不做清单（跨境支付、多租户运营 v2）。
这一步的价值：口头需求有了可追溯的编号。后续任何人问"限领 3 张是谁提的"，回到 02 的 S-01 就能找到一手来源。
@mumu-spec-r2-align· 双锚对齐（全文最关键一轮）
同时写 05 用户故事和 09 API 接口规格，确保需求和技术契约首次对齐。
这是最容易出问题的环节——产品和开发各写各的，最后发现对不上。这个 Skill 强制两边同时写、互相校验：
| 05 用户故事 | 09 API 接口规格 | 对齐检查 |
| US-002: 领取 618 优惠券 | POST /coupons/receive | 路径对应 |
| AC-002-02: 已领 3 张再领→拒绝 | limitPerUser: 3（服务端校验） | 数字一致 |
| AC-002-02: 提示"已达上限" | 403 COUPON_LIMIT_EXCEEDED | 错误码可断言 |
不混层规则在这里严格执行：
- 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 自动判定变更类型、列出联动顺序、按序修改：
| 联动顺序 | 操作文档 | 具体改了什么 |
| ① | 04 产品需求说明 | R-02: |
| ② | 05 用户故事 | AC-002-02: "已领 3 张" → "已领 5 张" |
| ③ | 09 API 接口规格 | 示例值 3 → 5 |
| ④ | 06 功能规格说明 | UI 文案"已领 x/3 张" → "x/5 张" |
| ⑤ | 13 测试策略 | TC-011: "第 4 次拒绝" → "第 6 次拒绝" |
| ⑥ | 14 追溯矩阵 | 更新变更记录 |
不同变更类型有不同的联动顺序：
| 变更类型 | 先改 | 再改 |
| 行为/AC 变化 | 05 | 09/10 → 13 → 14 |
| API 字段变化 | 09 | 10 → 05 AC → 13 TC → 14 |
| 表结构变化 | 10 | 09 → 13 → 14 |
| 范围增删 | 03 → 04 | 05 → 下游全套 |
这一步的价值：传统模式靠经验记"改了这个还要改那个"，MumuSpec 靠规则。改了 04 的 R-02，联动清单自动出来，少改一份就是少亮一格。
@mumu-spec-tasks· 任务拆分
把 05 用户故事拆成开发任务，按依赖排序：
T-001: 创建 CouponClaim 表及索引 [数据] 2hT-002: 实现 POST /coupons/receive 接口 [后端] 4h ← 依赖 T-001T-003: 实现 limitPerUser 校验逻辑 [后端] 2h ← 依赖 T-002T-004: 前端领取按钮 + 已领计数展示 [前端] 3h ← 依赖 T-002T-005: 编写 TC-009~012 单元测试 [测试] 3h ← 依赖 T-002, T-003辅助技能：3 个，查状态、跑质量
@mumu-spec-check· 质量检查
四项维度扫描 01-14：
| 维度 | 检查什么 | 示例失败项 |
| 完整性 | 14 份文档是否都在 | 缺 07 非功能需求 |
| 一致性 | 编号全局唯一 | REQ 编号重复 |
| 可追溯性 | 14 每行填满 | REQ-011 无 TC |
| 质量规则 | AC 无模糊词 | 出现"友好""尽量" |
@mumu-spec-status· 版本看板
扫描所有文档的元数据，输出版本状态：
📊 Spec 状态看板项目: 电商618促销 最后更新: 2026-05-1601 写作总则 v1.0 Approved02 需求来源 v1.1 Review04 产品需求 v1.1 Review ← 变更进行中05 用户故事 v1.2 Draft ← 变更进行中09 接口规格 v1.2 Draft ← 变更进行中13 测试策略 v1.0 Approved四、用SKILL之前 vs 用SKILL之后
| 没有 MumuSpec | 有 MumuSpec | |
| 需求来源 | "运营开会说过的"——靠记忆 | 02 文档 S-01 编号可追溯 |
| 改一个数字 | 改代码、看漏 UI/测试/API 示例 | @mumu-spec-sync |
| 验收标准 | "用户体验友好"——无法断言 | "返回 403 COUPON_LIMIT_EXCEEDED"——可测 |
| 交接 | 新人读代码猜业务规则 | 04 文档 R-02 写清 limitPerUser 数值和来源 |
| 发布前 | "测过了吧？""测了吧" | 14 追溯矩阵：REQ→US→API→TC 逐行对账 |
| BUG 定位 | "是需求没定？API 不对？测试没覆盖？" | 14 追溯行直接定位断层在哪 |
五、这个全景图的实际用途
| 场景 | 怎么用 |
| 内部演示 | 点"一键播放"，10 分钟看完全链路。比读 Skill 文档快 |
| 客户演示 | 3 分钟展示 10 个 Skill 各干什么、生成什么。问"R-02 是什么"，直接指给他看 |
| 变更演练 | 单独选 |
| 自查 | 点亮后看哪些字段还半透明，就知道哪些文档没写到位 |
六、一句话
MumuSpec 不是人从头写到尾的，是 Skill 按轮次、按规则、按链路往 14 份文档里填出来的。
空模板 → R1 采集 → R2 双锚 → R3 展开 → R4 收口 → 变更联动 → 质量检查。
改一个数字，6 份文档联动，少一份就没点亮。不靠嘴说，靠亮不亮。
《企业级AI Coding成熟度模型》V1.0发布 1个场景(618促销)5种范式(Spec/Vibe/Glue/TDD/Harness) ，企业级AI Coding经验分享(附代码示例) 反常识，企业开发Spec Coding不如Vibe Coding代码惊艳，但Spec Coding才是精准“靶向药”（附G1～G6上下文阶梯图） 越早发现越便宜：企业级AI Coding的7道代码分层质量拦截防线 企业级AI Coding「Landing Zone」 企业级 AI Coding：有了 Landing Zone，为什么还要谈「脚手架」？ 企业级AI Coding ｜ 公开一套经过企业用户验证的14份Spec文档 企业级AI Coding ｜ 以618促销为例的14份Spec模板 企业级 AI Coding，先算清「爆炸半径」：用 Spec + Skill 做检测、报告、评估与改单建议 MumuSpec 实战指南：10个SKILL + 14篇Spec文档 在这里，自评AI Coding成熟度级别，Get进阶下一步路线图
《企业级AI Coding成熟度模型》PDF已开源至GitHub，这些资料也会逐步同步到GitHub
https://github.com/lvzhaobo/mumu-coding/
