workbuddy_skills/product-planning/SKILL.md

name, description

name	description
product-planning	产品规划总入口（唯一入口），四段式调度：① 产品需求 ② 产品功能 ③ 界面交互 ④ 原型说明文档。四段以 references/stage-* 承载，本文件是总调度与约束。可整段跑也可只调一段。当用户要做产品规划、从零做新产品、只做某一阶段、或不知道从哪开始时调用。

产品规划总入口（Product Planning）

Trae 用法：本 skill 由模型按需自动加载，没有斜杠命令。若对话中尚未明确对象，先按下面「项目与路径约定」定出 <项目>，定不出来就停下问用户，不要自行假设。

用途

用户只有一句模糊想法（例："我要做一个 AI 短剧分镜画布"）时，本 skill 负责判断阶段、只做该段最小必要工作、产出可交付物、并推进到下一段。

本 skill 只做调度与约束，不重复任何被调 skill 的内容。下游 skill 都是外部成熟工具，不要自己重写一遍。

四段结构（可整段跑，也可只调一段）

段	回答的问题	子步	调用	产出物
① 产品需求	要做的东西凭什么成立：什么问题、为谁、为什么值得做	1a 需求文档（grill 压测）/ 1b 竞品分析 / 1c 用户画像 / 1d 产品策略 / 1e 使用场景	stage-discovery	docs/pm/<项目>/research/*
② 产品功能	要做哪些功能、什么不做、长成什么骨架	2a 产品功能 / 2b 界面布局	stage-requirements	docs/pm/<项目>/prd/2a-产品功能.md · prd/2b-界面布局.md（两份）
③ 界面交互	长什么样、怎么操作	3a 视觉规范 / 3b 原型 / 3c GPT会诊 / 3d 审查打磨	stage-delivery	docs/pm/<项目>/DESIGN.md · designs/<项目>/*.html · designs/<项目>/3c-GPT会诊.md
④ 原型说明文档	每个状态有哪些场景、每步做什么、边界在哪、坏了怎样	4a 场景盘点 / 4b 说明区 / 4c 演示引导	stage-proto-doc	同一份原型 HTML 里的说明区与演示引导

四段只通过落盘文件耦合，逐段交接口如下（这是段间唯一契约，越界即失效）：

交接	由谁给	给什么	⛔ 不许给什么
① → ②	①	问题定义、需求澄清决策表（含 grill 压测的 B 节：做成什么样 / 哪些情况不成立 / 状态怎么流转）、取证结论、产品定位、《使用场景》= 用户故事（②段功能的直接推导依据）	功能清单（那是②段的产出，1a 写了就越界）
② → ③	②	功能清单（每条带优先级 + 状态流转）+ 界面布局（有哪几页 / 每页几个板块 / 板块怎么排 / 跨页关系）+ 每页主操作 + 信息承载分档（主屏常驻 / 可点入）	视觉（配色 / 字体 / 间距 / 组件样式 / 动效 —— 那是③段的活）；⛔ 也不许只给功能不给骨架（骨架不给全，③段就一版一个样）
③ → ④	③	已跑通的单文件原型 HTML	说明区与演示引导（④段的活，③段顺手写就是越界）

⚠️ 2026-10-06 交接口口径反转：②→③ 原写的是「⛔ 不许给页面结构」，已废。 新口径：②段钉骨架，③段做皮肉。 用户原话：「3 是负责设计和交互，页面关系和布局必须在第二步确认清楚，不然第三步没有方向 一会一个样子」。 ⇒ ②段必须给：有哪几页、每页几个板块、板块怎么排、跨页关系。③段⛔ 不许增删移动板块，缺板块回②段改 ②段。 ⛔ 仍归③段：配色 / 字体 / 间距 / 组件样式 / 动效，以及每个板块的视觉与交互实现。

⚠️ ②→③ 仍是本流水线最容易被搞坏的一环，但病灶换了位置：旧病灶是「②段 说"必须能读到"，③段读成"必须常驻主屏"」→ 五类信息全铺一屏 → 信息墙。 分档表就是为这句歧义而生的：它把"读到"明确成"一次点击内可达"这一档。该纪律照旧有效，只是现在骨架不由③段独立推导，而是②段给定、③段在骨架内兑现分档。

💡 ③段为什么在骨架给定后仍然不会"退化成照抄"：它做的仍是另一类工作 —— 骨架是灰块（有哪些块、什么顺序），③段要给的是视觉与交互实现（怎么排版好看、点哪有什么反馈、空态怎么呈现、响应式怎么变）。两者不是同一样东西的粗细两版，是两个维度。

四段各占一个词，互不共用（2026-10-02 定）：产品 / 功能 / 界面 / 说明。 改段名前先对照这张表——若两个段名里出现同一个词，边界一定在漂。历史上「调研与方案 / 需求与结构」两段名里都含"需求"、③段名里的"交付"是全三段共有的属性，都属名实不符，已改。 ①叫「产品需求」而不叫「需求调研」：该段产出 research/1a-需求文档.md、1b-竞品分析.md、1c-用户画像.md 也产出 1d-产品策略.md、1e-使用场景.md，"调研"二字盖不住后半截。

⭐⭐ grill-me 全场只有①段一份（2026-10-06 用户定案）：用户原话「grill 也应该拿到第一步了，第二部就是细化功能」。 合并后①段那份按 A / B 两节提问：A 节「要做什么、为谁、边界在哪」（原①段火力点）｜B 节「做成什么样、哪些情况不成立、状态怎么流转」（原②段火力点）。 ⇒ ②段不再有 grill-me.md，也不再产出 grill-decisions.md；B 节的结论落进 research/1a-需求文档.md。 ⛔ 不许在②段再加回一份 —— ②段从 2026-10-06 起只细化功能，不再反问需求。

⭐⭐ ②段产出从 7 份收成 1 份（2026-10-06 用户定案）：用户原话「不需要 就用使用场景，其余6分都不需要了」。 删掉 prd/grill-decisions.md｜prd/user-stories.md｜prd/priorities.md｜prd/pre-mortem.md｜ux/state-machine.md｜ux/diagrams/*。 留下的两份：prd/2a-产品功能.md（功能清单：做哪些 / 不做哪些 / 每条带优先级 + 状态流转）＋ prd/2b-界面布局.md（页面关系 + 页面内板块布局）。 融合去向：状态机 → 进功能条目；用户故事 → 归①段《使用场景》（1e-使用场景.md）；图示 → 改名「界面布局」并独立成 2b；优先级 → 进功能条目。 🔴 2026-10-07 用户定案：「2 产品功能 和 界面布局不就是两个文档嘛」⇒ 原「两半合成一份 PRD.md」的写法推翻，PRD.md 已废。 ⚠️ 本段功能的组织方式是按「使用场景」（一条场景可跨多个页面），⛔ 不按页面组织。

段内的子步顺序、方法论文档、硬约束、完成标准，都在各段自己的 SKILL.md 与 references/ 里，本文件不重复。

①段 1a 需求文档：全程最先做（且只做一次）——用 grill-me 与用户互动，产出一份 docs/pm/<项目>/research/1a-需求文档.md（开头写清做什么/为谁/不做什么，往下是决策表）。

项目与路径约定（单一真源）

四段全部遵守本节。各段 SKILL.md 与 references/ 里出现 docs/pm/... 时，<项目> 一律指本节定义的 slug，不另作解释。

<项目> 是什么

项目 slug：小写字母 / 数字 / 连字符（例 my-tool、video-canvas）。 它同时是 docs/pm/<项目>/ 与 designs/<项目>/ 的目录名——两处必须同名，一个字都不能差。

slug 怎么定（按序取第一个成立的，不许猜）

序	条件	取值
1	用户在当前会话里明确说了项目名	该名字 slug 化
2	.registry/current-project 存在且非空	其内容
3	docs/pm/ 下恰有一个非 _ 开头的目录	该目录名
4	以上都不成立	停下问用户，不许自行假设

写任何文件之前先核对：目标路径里的 <项目> 段与按上表得出的 slug 是否一致；不一致就停下说明，不要"先写了再说"。猜错会把产物写进别的项目，事后极难拆干净。

产物落哪

段	路径
① 产品需求	docs/pm/<项目>/research/
②	docs/pm/<项目>/prd/、docs/pm/<项目>/ux/、docs/pm/<项目>/ux/diagrams/
③	docs/pm/<项目>/DESIGN.md、designs/<项目>/*.html、designs/<项目>/3c-GPT会诊.md
④	写进原型 HTML 自身（designs/<项目>/*.html），不额外落 md

DESIGN.md 为什么在项目目录、不在仓库根

DESIGN.md 是 ③ 段的绑定视觉规范，一个项目一份，③ 段按当前项目的 slug 去读它。仓库根只能放一份，多项目会互相覆盖，所以一律放 docs/pm/<项目>/DESIGN.md。

推论（硬规则）：读 DESIGN.md 时，路径必须由本节定义的 <项目> slug 拼出，不许用"当前工作目录碰巧有 DESIGN.md"这类推断。仓库根不放任何项目的 DESIGN.md。

工具选择规则（防止选错，最重要的一节）

下表是选型总则。这些工具都已封装在对应段内，本文件只负责让你不选错，不负责给出调用路径——具体路径见各段 SKILL.md。

要什么	用谁	不要用什么
页面设计全链（规范 → 原型 → 审查）	③ 段 stage-delivery 自己的 D0→D5 流水线（判据与素材由两个页面设计技能供给）	不要另找风格库、也不要自己手搓一套 token 与门禁
评审用的可点原型 / 生产级前端页面	③ 段 3b（按 D2 构建，单文件 HTML 交付；先判页型：营销页取 open-design 技能的 design-templates/web-prototype/，工具型页面取 ③段 references/layouts-tooling.md）	⛔ 不要不判页型就套 web-prototype 种子 —— 那是营销落地页骨架，会把后台做成营销页
设计规范文件	③ 段 3a 生成 DESIGN.md（令牌表由 open-design 技能选定套的 tokens.css 产出 + 该项目②段的界面需求）	不要凭空编一套 token
架构图 / 流程图 / 时序图	diagram-design	不要手写 Mermaid
状态迁移的守卫/副作用/并发	state-machine	diagram-design 不覆盖这些，别指望它
审美方向 / 风格定调	open-design 技能里选一套（读候选套 DESIGN.md 第 1 章，按页面类型挑）	不要用"米白+衬线+陶土色"这类默认审美，也不要凭感觉编
多方向比选 / 独立评审打分	oil-ui-pro 技能（方向探索 design-direction.md＋对比页 style-explorer.md；评审协议 visual-review.md）	⛔ 不要拿它的评分循环替代本段 Gate-1/2/3

③ 段的页面设计供给来自两个独立技能（2026-10-05 定），都装在 .workbuddy/skills/ 技能仓库、都可脱离本段单独使用：

• open-design（判据供给库）：design-systems/（153 套，定调只从这里选，不凭感觉编）｜craft/（13 份工艺判据：状态穷举 / 字阶 / 配色 / 动效 / 反 AI 味 / 无障碍）｜design-templates/web-prototype/（版式骨架种子，⚠️ 营销页向）。
• oil-ui-pro（界面设计方法论）：五步流程（探索方向 → 建结构 → 取实证 → 独立评审打分 → 验证交付）＋ 风格对比页与截图工具。⚠️ 它自带联网版本检查与自动更新，是用户明确要求全量搬入的例外项（既有纪律是"依赖外部服务一律不收"），记录在案、不扩散。
• ⭐ 两者平行同层级、不缝成一条流水线：多数页面走 open-design 主线；需要「先拉开方向让用户挑」或「独立评审打分」时取 oil-ui-pro。

⛔ 四样东西两个技能都没有对应，必须由 stage-delivery 自己扛：设计契约十二字段 / 结构骨架 / 交互清单 / 工具型版式库。 🔴 页型分流（2026-10-05 新增）：web-prototype 的种子与 8 骨架全是营销落地页结构（hero / features / stats / quote / CTA），自带 .eyebrow（眉标）与 .lead（副标题）。工具型页面（后台 / 控制台 / 列表 / 详情）照它做会长出「标题上下各一行小字」的三段式 —— 这是本项目实测踩过的坑，且结构判据全绿也拦不住。⇒ ③段 D0 必须先判页型，工具型页面零 .eyebrow / 零 .lead / 零 .hero，版式走 ③段 references/layouts-tooling.md。 ⛔ 只读一处来源 —— 同一条判据若在 stage-delivery 与 craft 各有一份且口径不同，以本项目追加条为准，并在 runbook §3.4 显式标注「本项目追加」。

DESIGN.md 说明：@google/design.md 提供 lint / diff / export / spec 四个子命令，目前是 alpha（v0.4.0）。在非 TTY 的管道里可能不回显输出，需在真实终端里确认结果。本机实测该命令完全不可用，不要拿它当校验关卡；改由 D3 收口与 D5 终检按真实像素人工复测对比度（判据见 open-design 技能的 craft/color.md）。⚠️ 原两把门禁脚本（静态文案检查 / 渲染机检）已随旧主干从磁盘移除，当前没有机器复现 ⇒ 结论只能记「人工判定」，不得写成「脚本已通过」。

可调用工具（自然语言触发）

两个「随段携带」的独立工具，装在 ③段 references/stage-delivery/assets/ 下；按用户说法直接触发，产物落项目目录。它们不是新的段，只是叫得动的工具。

用户说	触发工具	做什么	产物
「分析 XXX 视频」「把这个视频抽帧」「拆一下这条视频的画面」	stage-delivery/assets/video-capture/	取视频（本地文件 / 直链 URL）＋ 抽帧（双因素 ＋ 首尾 ＋ 补帧）	关键帧 frames/ ＋ frame_times.json（供 ①竞品分析 / ③视觉参考）
「获取 XXX 网站的设计风格」「抓这个网站的风格/组件/配色」	stage-delivery/assets/design-capture/	抓网页设计系统（色彩 / 排版 / 组件）→ 生成样式模板	一套 design-system-<名>/（与 design-system-tiaoyue 同构，可直接被 ③段 D1 选用）

• 两者都独立、可单跑：video-capture 只依赖 ffmpeg；design-capture 只依赖本机 Chrome（CDP）＋ vendor/ 里搬运的抽取脚本，⛔ 不依赖 open-design daemon。
• 用法与边界见各自 SKILL.md；来源与署名见各自 ATTRIBUTION.md。
• 触发时机：①②段拆竞品视频 → video-capture；③段要新建样式或拆参考站 → design-capture。
• ⛔ 两工具都只做合规最小集（不抓平台页内视频、⛔ 不调付费接口）；抽取结果须先目视比对再采用。

进入方式

你说什么	模式	从哪开始
"规划 XX" / "从零做 XX"	全流程（自动处理）	stage-discovery → stage-requirements → stage-delivery → stage-proto-doc，一路跑完，段间不停下来问（含 ① 段末）
"先确认方案" / "跑完方案停下等我" / "规划 XX，先给方案"	方案确认	同全流程、同一套四段，唯一差别是 ① 段末停下等你确认方案，确认后才进 ②③④
"只做产品需求" / "只做产品功能" / "只做界面交互" / "只做原型说明文档"	单段	只调对应那一个 stage skill，不展开其他段，也不催促回补前段
已有 ②段，要出原型	单段	直接调 stage-delivery，从它的 3a 起
已有原型，要补说明	单段	直接调 stage-proto-doc，从它的 4a 起
只问某个单点	单段	不跑任何段，在对应 stage skill 内点名子步，或直接说要看哪份方法论

为什么"只调一段"成立：四段之间只通过落盘文件耦合，没有隐式状态。

• ② 只读 docs/pm/<项目>/research/* 与 docs/pm/<项目>/strategy/*；缺失时标注 【假设】 继续，不强制回补 ①
• ③ 只读 docs/pm/<项目>/prd/* 与 docs/pm/<项目>/ux/state-machine.md；缺失时同样标 【假设】 继续
• ④ 只读 designs/<项目>/*.html，另按需读 docs/pm/<项目>/prd/* 与 docs/pm/<项目>/ux/state-machine.md 校准术语；缺失时标 【假设】 继续

执行规则

只有三种模式（对应上表），没有第四种：

模式	段之间	段之内
全流程（自动处理）	一路跑完，段间不停下来问（含 ① 段末）。每段结束按「标准收尾格式」输出一段报告，输出完即刻进下一段	子步之间不反问，做完直接进下一个子步
方案确认	与全流程完全相同，只有一处不同：① 段末停下等你确认方案；确认后 ②③④ 一路跑完、段间不停	同上
单段	不涉及	同上；不越界、不催促回补前段

这两条是全流程模式下的两个独立分支，不要混：全流程（自动处理）没有 ① 段末的强制停；「停下等确认方案」只在"方案确认"模式下发生。二选一由用户定（界面里点【生成原型和文档】时选「自动处理」或「先确认方案」，或在会话里直接说明）；用户没明说时按自动处理走，不要在自动处理模式下自作主张停下来问。

"停下"到底指什么——不要读成"每一步都要反问用户"。只有这四种情况才停：

1. 信息不足且查不到，必须用户给（如「项目与路径约定」slug 第 4 条）——停下问
2. 破坏性 / 不可逆动作——二次确认
3. 用户显式要求某个子步做完停下
4. ① 段末的方案确认（仅"方案确认"模式）——把方案摆给用户：做什么 / 不做什么 / MVP 边界 / 未复核的 【假设】，明说"等你确认方案，确认前不进 ② 段"

段末报告：全流程（自动处理）模式下，所有段（含 ①）都只输出报告，不提问、不等回答；方案确认模式下 ① 段是唯一例外，其余段同样只输出报告。

① 段末的确认是回环，不是一次问答（仅"方案确认"模式）：用户看到方案后可以提问题要求改（可能多轮），每轮的"问题 + 怎么改的"都要留痕、不得覆盖上一轮；改完由用户显式说"确认方案"才算过闸门。该模式下，没拿到用户确认的方案不得当成既定事实带进 ② 段（这是本项目真实踩过的坑：② 段拿着未经确认的方案往下跑，把用户已拍板的需求裁掉了）。

其余规则：

• 声明制（全段适用，不止 ③ 段）：开工前、每进一个子段/子步、每处偏离，都要声明三件事——当前在哪 / 依据哪个文件的哪一节 / 产出落哪；偏离当场写明原因与影响，段末附偏离单。不许静默偏离。 这是本项目踩过的坑：③ 段 3b 交付了原型却没走当时声明的主流程、没读依据文件，也没有当场说，用户直到追问"基于哪个 skill"才知道。
• 不做八股：不介绍方法论来源，不列人名，不复述框架历史。直接给结论。
• 只调一段时不越界：用户说"只做第 N 段"，就跑该段，不展开其他段，也不用"你还没做调研"去催促。
• 提问上限 3 个：其余用合理假设，并在文档里标注 【假设】。例外：进入 grill-me 提问模式时不受此限（① 段的"需求澄清"与 ② 段的"需求压测"各是一次）——该模式的价值就是穷尽提问。此时须先声明"将连续多轮提问"，退出后恢复本约束。
• 反问优先，允许自动补全：grill-me 的默认动作是把问题抛给用户并附推荐答案。用户说"你定"、连续两轮不回应、或属事实类问题时，模型自行给答案并标 【假设】，换来"不卡住"；但每轮结束要汇出待复核清单，未经复核的 【假设】 不得在下游当事实用。
• MVP 边界优先：任何阶段都先回答"第一版做什么 / 不做什么"。
• 必须落盘：产出写入文件，不要只在对话里输出。
• 无来源就标注：市场规模、竞品数据无法查证时标为"估算"并写明口径，禁止编造数字当事实。
• 禁止长文：单份产出物默认一页纸（≤120 行）；超长必须拆分。

每段的标准收尾格式

## 本段结论
- （3-5 条，可直接决策的话）

## 已落盘
- ...

## 待确认（最多 3 条）

## 建议下一步
→ 用 <skill-name> 完成 <具体事>

反面清单

• 为一个小功能跑完整调研
• 输出长文却给不出一个结论
• 跳过"不做什么"
• 用户只问单点，却强行拉进全链路
• 把估算数据写成确凿事实
• 跳过 ③ 段 D0 的 Gate-1（未定死令牌表与设计契约）就开写页面代码
• 在 grill-me 提问模式下仍套用"提问上限 3 个"，把提问做成走过场
• 只跑一次 grill-me：① 没定义需求就去取证，或 ② 拿①段的需求定义代替功能压测直接写 ②段
• 把自动补全当默认动作：用户没说话就替用户拍板，还没标 【假设】、没进待复核清单
• 把 ④ 的说明区写进产品功能范围，或让 ③ 顺手把说明文档一起写了（该调 stage-proto-doc 就调）
• 手写 Mermaid 代替 diagram-design，手写 token 表代替 DESIGN.md
• 绕过四段自己手搓（该调 stage-* 就调，不要重写它们的内容）
• 把两个页面设计技能（open-design / oil-ui-pro）的内部路径按本 skill 目录去拼，或改它们的正文（它们是技能仓库里的供给技能，改动只写 stage-delivery 自己的 SKILL.md / references/；⛔ 两个技能平行同层级，不缝成一条流水线，也不把 oil-ui-pro 的评分循环当成本段 Gate 的替代）
• 猜 <项目>：定不出来还硬写，把产物落到别的项目目录下
• 把 DESIGN.md 写到仓库根：多项目会互相覆盖
• 段间停下来问"要不要继续"：全流程（自动处理）模式下直接进下一段，只在段末输出报告

改名 / 改供给后的自检（⛔ 不许跳过）

python scripts/check_naming.py

它查什么：四段段名与子步名在「总入口 ↔ 各段 SKILL.md ↔ 各段 references/」之间有没有漂 —— 包括 H1 与子步表是否一致、总入口子步列有没有漏项、runbook 必读表有没有引用已移除的资产、两份副本是否一致。纯静态比对，不需要渲染、不需要外部依赖。

为什么必须有它（不是"为了严谨"，是实测当天就漏过两次，且没有任何门禁会报错）：

第一次（2026-10-02）：段名从「需求调研 / 功能规划 / 界面与交付」改成「产品需求 / 产品功能 / 界面交互」时 —— SKILL.md 改了，但 references/stage-discovery/references/grill-me.md 的 H1 仍写「需求澄清（grill-me · 调研段）」；references/stage-requirements/SKILL.md 子步表写「2b 功能流转」而正文 H2 写「## 2b 状态机」；总入口④段子步列只写「4a 说明区/ 演示引导」漏了 4b/4c。三处都只能靠回读发现。

第二次（2026-10-06，本轮）：②段收窄为「只细化功能」（7 份产出 → 1 份）后，各段 SKILL.md 都改了，但总入口 product-planning/SKILL.md 的三处仍写着旧结构 —— ① 四段表的②段子步列仍是「2a 功能定义与压测 / 2b 功能流转 / 2c 功能图示」； ② 四段表的①段子步列「1c 产品定位与商业设计」未随段内改名（段内已改称「产品定位与场景」）； ③ 正文仍写「① 与 ② 各跑一次 grill-me」并指向两份同名文档（②段那份已删）。 ⇒ 闸门当场报 6 个 FAIL，根因就是这处「改了承载段、忘了总入口」。 ⭐ 由此立一条硬纪律（与记忆里的「换供给不能只改承载段」同型）：凡改子步结构 / 段内产出清单 / 段间交接口，必须连带改总入口 product-planning/SKILL.md 的「四段结构」表与「交接口」表 —— 不改就是半改状态（比不改更糟）。

⛔ 改了段名 / 子步名 / 判据供给源之后必须跑一次，并把结果记进当日 memory —— 这是"不渲染不算完"的同型要求：改完不校验，下次读契约的人拿到的是错的配方。

⚠️ 本脚本的能力边界：它只查文本一致性（H1 ↔ 子步表 ↔ 总入口 ↔ 副本），查不出"判据口径是否自相矛盾"。 例如「②段到底该不该给页面结构」这种反转，闸门一个字都报不出来（两版写法都合法）。 ⇒ 口径类改动要靠人工回读，且必须把反转理由与用户原话写进文档留痕。 ⚠️ 脚本输出里的 [提示] 项（旧名出现）不计入失败，但要人工看一眼是不是落在「废止理由块」里 —— 落在里面是正当留痕，散落在正文里就是真残留。 🔴 2026-10-07 起本技能只在全局一份：E:/ProgramData/.workbuddy/skills/product-planning/ —— 它就是本体，⛔ 不再有「主 / 副 / 装入」三副本，也⛔ 不再需要「三处 md5 复核」 （那只在有副本时才有意义）。改完只跑一次：check_naming.py --ws <工作区>。 用户原话：「把产品规划复制到 workbuddy 全局skills中 后续维护和使用全局技能」。 ⚠️ 工作区原先那三份已归档到 归档/技能迁全局-20261007/（未直删，可随时取回）。

• 把两种模式混用：在自动处理模式下自作主张停下问方案，或在"方案确认"模式下确认前就开跑 ②③④
• 在"方案确认"模式下把 ① 段的方案当成已确认就往下跑：该模式下 ① 段末必须停下等用户确认（含"不做什么"）
• 下游擅自裁剪上游已拍板项：②③④ 发现要砍 ① 段或决策表里已拍板的东西时，不许自行裁掉或改口径，必须列成"与已定决策的差异"交用户显式确认
• 把模式当成段：模式是"要不要在 ① 段末停"的开关，不是第五个段，别为它单独造段或造产物
• 跑了却不说：没声明当前段/子步与依据文件，或偏离了被调 skill 的主流程却不声明、不记偏离单（应为：开工先声明、每个子步再声明、偏离当场声明）