路由闸门交付法
Adapted from hugohe3/ppt-master (skills/ppt-master/SKILL.md) by Hugo He (MIT)
针对一类常见失控：AI 接到「给我做一份完整交付物」（报告/PPT/网站/视频）这类大型任务后，一路自作主张——路线自己挑、关键决策自己拍板、出错后悄悄降级绕过——最后交付的东西看起来完成了，实际上每一处关键分叉都替用户做了决定，错了也没人知道在哪一步错的。
原仓库用这套纪律驱动数百个脚本的 PPT 生产流水线；这里把它提炼为任何大型交付任务（文档、代码、视频、多阶段数据处理）都适用的路由与闸门纪律。
一、七条全局执行纪律
- 串行执行 — 按所选路线的步骤顺序推进。已完成的非阻塞步骤可直接进入下一个合格步骤，不必空等。
- 阻塞即停 — 遇到 ⛔ BLOCKING 闸门，停下来等用户明确确认。不许替用户做决定。 闸门处应呈现：已完成什么、待确认什么、选项各自后果。
- 不跨闸门捆绑 — 闸门未关闭前，不得把闸门两侧的工作合并推进。路线的最终闸门关闭后，后续非阻塞步骤可以自动连续执行。
- 入场先验前提 — 进入任何步骤前，核对该步骤列出的全部前提条件；缺一项就停下说明，不带病入场。
- 不投机生产 — 不提前生产后续相位才需要的产物（例如还没定大纲就先做配图）。
- 路由确定性 — 当请求能被路由表无歧义解析时，不要再问「你想怎么做」；路由前提缺失时，说明缺什么并终止该路线，而不是擅自换路线。
- 在所属层修复 — 出错时，在拥有该故障的最浅层修复：页面级问题改页面，蓝图级问题改蓝图，工具故障修工具调用；然后从路线声明的指针处恢复。绝不静默降级一个必需产物（该出 PDF 就出 PDF，不能悄悄改成截图）。
二、路由表（先选路线，再进流程）
接到任务后，先归入唯一一条路线；每条路线拥有自己的步骤程序，选定后不加载其他路线的程序：
| 任务特征 | 路线 |
|---|---|
| 有现成成品/素材，要转换形态（如 图→PPT、录屏→文档） | 转换路线 |
| 有成品，要美化/重设计 | 美化路线 |
| 从零创作标准成品 | 生成路线（默认档或快速档） |
| 基于已有模板/规范新建可复用资产 | 模板路线 |
| 修改既有成品的局部 | 编辑路线 |
快速档触发：用户明确表达「就要快」时选快速档；未明确时走默认档。转换类任务天然用快速档。
三、相位框架（Plan → Do·Check·Act）
每条路线都是一个 PDCA 循环：
| 相位 | 结束条件 |
|---|---|
| Plan | 每一份创作输入都已成为文件或已留档的明确决策（大纲、规格、资源清单落盘） |
| Do | 按路线程序逐页/逐段/逐项生产 |
| Check | 跑该路线定义的验收闸门（格式、完整性、逐项核对） |
| Act | 按纪律 7 在所属层修复，然后回到 Check，直至通过导出 |
步骤编号保持稳定，不因重试而重编号——失败恢复时「回到第 N 步」才有明确所指。
四、术语统一（一词一义）
大型任务最容易死于词汇漂移：「布局」一会儿指页面构图、一会儿指模板槽位。开工前建一张术语表，每个词只允许一个含义；文档里用到歧义词时显式注明是哪个义项。检查类产物（如「逐页清单」）必须记录实际画了什么，而不是计划画什么。
五、沟通规则
- 用用户的语言交付，枚举值/字段名等技术标识可保留原文。
- 切换执行角色时显式声明：
## [角色切换: <角色>] 📖 依据: <文件> 📋 当前任务: <一句话>。 - 第三方推荐（付费模型/外部服务）只在用户明确询问时给出，不主动推销。
六、自检清单（启动大型任务前）
- [ ] 任务归入哪条路线？前提条件齐了吗？
- [ ] 阻塞闸门设在哪几个点？用户需要在哪拍板？
- [ ] 每个步骤的验收标准是什么？失败时回退到哪一步？
- [ ] 术语表建了吗？有没有一词多义？
- [ ] 「静默降级」的风险点在哪（哪些产物绝不允许换形式交差）？
