From 1d7d31a529cad39f4086691ae79c73cf8f08eb37 Mon Sep 17 00:00:00 2001 From: maogeigei Date: Thu, 8 Oct 2026 22:22:38 +0800 Subject: [PATCH] =?UTF-8?q?=E6=92=A4=E9=94=80=E8=AF=AF=E7=94=A8=E7=9A=84?= =?UTF-8?q?=E3=80=8C=E9=A1=B9=E7=9B=AE=E4=BC=9A=E8=AF=9D=E3=80=8D=E6=9B=B4?= =?UTF-8?q?=E5=90=8D=20=EF=BC=8B=20=E8=AF=B4=E4=BA=BA=E8=AF=9D=E6=96=B0?= =?UTF-8?q?=E7=A8=BF=E6=8C=89**=E5=90=88=E5=B9=B6**=E8=90=BD=E5=9C=B0?= =?UTF-8?q?=EF=BC=88141=20=E5=A4=84=E6=8E=AA=E8=BE=9E=E6=9B=BF=E6=8D=A2?= =?UTF-8?q?=EF=BC=89?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 一、用户令（逐字） 1. `1、A方案` 2. `执行会话没问题 。是之前的说法有问题：应该叫 项目机制 不叫 项目会话` 二、🔴 先撤回上一轮的错误更名（用户更正了目标词） 上一轮我按「执行会话（协作会话）改为 项目会话」把术语改成了**项目会话** ⇒ 本轮用户明确： **「执行会话没问题」**、要叫的是「**项目机制**」、**⛔ 不是「项目会话」**。 ⇒ 已**全量撤回**（6 处）：`SKILL.md` 的术语更名口径块／三类会话表那行／第 0 步触发句插入， 以及 `skill-load-guard.py` 词表里新增的"项目会话族"。 ⚠️ 复核时看到的另外 4 处「项目会话」是**巧合的普通词组**（「本项目会话共 N 个」「不算本项目会话」）， ⛔ 不是更名产物 ⇒ 未动。 🔴 **教训**：改名属"影响面变更"的**目标词**，一次说错就要全量撤回 —— 所以我这轮**没有再自行猜**（见待拍板项）。 三、A 方案：7 份按「**合并**」落地（不是覆盖） · 规则（保守）：只应用**两侧都 ≤8 行、且在现文件里唯一**的"措辞替换"；**更大的块一律保留现文件原样** （那些块是别的会话今天加的新内容，例如 `stage-delivery/SKILL.md` 里 106 行的增量）。 · 结果：7 份共应用 **141 处**措辞替换（9／6／17／12／27／10／60），逐份有残留大块未动（已列出）。 · **改前备份** ⇒ `待清理/技能包-说人话合并前备份-20261008/`（7 份，可回退）。 · ⚠️ 加上上一轮直落的 9 份，A 方案的 16 份**全部处理完毕**：9 份直落（差异只在措辞）＋ 7 份按合并（保留新内容）。 四、验收 selftest.py rc=0 PASS 106 / FAIL 0；manifest 76 份、语法失败 0。 --- product-planning/SKILL.md | 496 +++++----- .../references/stage-delivery/SKILL.md | 759 ++++++++-------- .../references/execution-runbook.md | 847 +++++++++--------- .../references/layouts-tooling.md | 32 +- .../references/stage-discovery/SKILL.md | 25 +- .../references/stage-requirements/SKILL.md | 46 +- .../references/create-prd.md | 19 +- session-mechanism/SKILL.md | 15 +- session-mechanism/references/manifest.md | 6 +- .../scripts/hooks/skill-load-guard.py | 11 +- 10 files changed, 1119 insertions(+), 1137 deletions(-) diff --git a/product-planning/SKILL.md b/product-planning/SKILL.md index 65c5827..494f415 100644 --- a/product-planning/SKILL.md +++ b/product-planning/SKILL.md @@ -1,248 +1,248 @@ ---- -name: product-planning -description: 产品规划总入口（唯一入口），四段式调度：① 产品需求 ② 产品功能 ③ 界面交互 ④ 原型说明文档。四段以 references/stage-* 承载，本文件是总调度与约束。可整段跑也可只调一段。当用户要做产品规划、从零做新产品、只做某一阶段、或不知道从哪开始时调用。 ---- - -# 产品规划总入口 - -> 本 skill 由模型按需自动加载，没有斜杠命令。对话里还没定出对象时，先按「项目与路径约定」定出 `<项目>`；定不出来就停下问用户，不要自行假设。 - -## 用途 - -用户丢来一句模糊想法（例如「我要做一个 AI 短剧分镜画布」）时，本 skill 判断该走哪一段，只做那一段的最小必要工作，产出可交付物，再推进到下一段。 - -本文件管调度与约束。各段怎么做，写在 `references/stage-*` 各自的文件里。 - -## 四段结构（可整段跑，也可只调一段） - -| 段 | 回答的问题 | 子步 | 调用 | 产出物 | -|---|---|---|---|---| -| **① 产品需求** | 要做的东西凭什么成立：什么问题、为谁、为什么值得做 | 1a 需求文档（grill 压测）/ 1b 竞品分析 / 1c 用户画像 / 1d 产品策略 / 1e 使用场景 | `stage-discovery` | `docs/pm/<项目>/research/*`。其中 1b 交两种体例：`research/1b-竞品分析.md`（汇总对比）＋ `research/1b-独立分析/<竞品名>.md`（独立分析） | -| **② 产品功能** | 要做哪些功能、什么不做、长成什么骨架 | 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 节：做成什么样 / 哪些情况不成立 / 状态怎么流转）、取证结论（1b 汇总对比体 ＋ 1b 独立分析体、1c 用户画像）、产品定位、《使用场景》＝用户故事（②段功能的直接推导依据） | 功能清单归②段产出，1a 写到需求与形态为止 | -| ② → ③ | ② | 功能清单（每条带优先级 ＋ 状态流转）、界面布局（有哪几页 / 每页几个板块 / 板块怎么排 / 跨页关系）、每页主操作、信息承载分档（主屏常驻 / 可点入） | 视觉归③段。骨架必须给全，骨架不给全，③段就一版一个样 | -| ③ → ④ | ③ | 已跑通的单文件原型 HTML | 说明区与演示引导归④段 | - -> 口径：②段钉骨架，③段做皮肉。两侧逐行对照与用户原话只在②段 `references/stage-requirements/SKILL.md` 的 §②—③ 交接口 定义一次 —— 本入口不复述。要点两条：②段要给全「归②段」列；③段不许增删移动板块，缺板块回②段改。 - -> ②→③ 最容易搞坏。旧病灶：②段说「必须能读到」，③段读成「必须常驻主屏」，五类信息就全铺一屏成了信息墙。分档表把「读到」明确成「一次点击内可达」，防的就是这句歧义。骨架是灰块（有哪些块、什么顺序），③段给的是视觉与交互实现（排版、点哪有什么反馈、空态、响应式）。两件事各管一维，③段不会退化成照抄。 - -> 四段各占一个词，互不共用（2026-10-02 定）：产品 / 功能 / 界面 / 说明。改段名前先对照这张表；两个段名里出现同一个词，边界一定在漂。旧名「调研与方案 / 需求与结构」都含「需求」，③段旧名里的「交付」是三段共有的属性，都属名实不符，已改。 -> ①叫「产品需求」不叫「需求调研」：该段产出 `research/1a-需求文档.md`、`1b-竞品分析.md`、`1c-用户画像.md`，也产出 `1d-产品策略.md`、`1e-使用场景.md`，「调研」二字盖不住后半截。 -> ⭐ 1b 是①段唯一交两种体例的子步：独立分析体 `research/1b-独立分析/<竞品名>.md`（竞品池每一个一份），汇总对比体 `research/1b-竞品分析.md`（恒一份）。职责边界与定案原话见 `references/stage-discovery/references/competitor-analysis.md` §0.4。 - -⭐ `grill-me` 全场只有①段一份（2026-10-06 用户定案）：①段那份按 A / B 两节提问，火力点划分、节次归属与定案原话见 `references/stage-discovery/references/grill-me.md` —— ⛔ 本入口不复述。B 节结论落进 `research/1a-需求文档.md`。 - -⭐ ②段产出两份（2026-10-06 收窄，2026-10-07 定为两份）：`prd/2a-产品功能.md`（功能清单：做哪些 / 不做哪些 / 每条带优先级 ＋ 状态流转）与 `prd/2b-界面布局.md`（页面关系 ＋ 页面内板块布局）。定案原话与理由见 `references/stage-requirements/SKILL.md` 开头。 - -（交接口反转前的口径、②段收窄前的产出清单与去向 → `references/_留痕/③段与总入口-旧口径.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/<项目>/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 交付）。先判页型：营销页取③段 §供给·版式骨架 的可选档，工具型页面取其默认档 | 不判页型就套可选档种子——那是营销落地页骨架，会把后台做成营销页 | -| 设计规范文件 | ③段 3a 生成 `DESIGN.md`（令牌表取自③段选定套，见③段 §供给·定调与令牌；再加该项目②段的界面需求） | 凭空编一套 token | -| 架构图 / 流程图 / 时序图 | `diagram-design` | 手写 Mermaid | -| 状态迁移的守卫、副作用、并发 | `state-machine` | 指望 diagram-design 覆盖这些 | -| 审美方向 / 风格定调 | ③段 §供给·定调与令牌 的默认档里选一套（可选档亦见该处），读候选套按页面类型挑。⛔ 每次只选一套 | 「米白＋衬线＋陶土色」这类默认审美，或凭感觉编 | -| 多方向比选 / 独立评审打分 | ③段 §供给·多方向比选 与 §供给·独立评审协议 | 拿它的评分循环替代本段 Gate-1/2/3 | - -③段的页面设计供给 —— 默认主线、定调与令牌、版式骨架、工艺数值判据、独立评审协议、多方向比选，共六档；各档的默认来源 / 可选来源 / 路径只在③段 `references/stage-delivery/SKILL.md` 的 §供给 定义一次，本入口不复述，要改供给只改那一块（2026-10-08 起）。`oil-ui-pro` 是界面设计方法论：五步流程（探索方向 → 建结构 → 取实证 → 独立评审打分 → 验证交付），加风格对比页与截图工具；它自带联网版本检查与自动更新，是用户明确要求全量搬入的例外项（既有纪律是「依赖外部服务一律不收」），已记录在案，不扩散。 - -默认走 `oil-ui-pro` 主线，不与可选档缝成一条流水线：可选档只在 §供给 里列，选了才作补强（多一路定调候选、多一套工艺数值判据），不选也不影响开工。 - -四样东西供给件里都没有对应，由 `stage-delivery` 自己扛：设计契约十二字段、结构骨架、交互清单、工具型版式库。 - -页型分流（2026-10-05 新增）：③段 §供给·版式骨架 的可选档是营销落地页向，工具型页面照它做会长出「标题上下各一行小字」的三段式（骨架名单与理由见③段 `references/stage-delivery/references/layouts-tooling.md` 开头）。本项目实测踩过这个坑，结构判据全绿也拦不住。所以③段 D0 必须先判页型，工具型页面版式一律走 §供给·版式骨架 的默认档。 - -只读一处来源：同一条判据若在默认档与可选档各有一份且口径不同，以本项目追加条为准 —— ⛔ 但追加条不得放宽基础层（`oil-ui-pro` 是基础层、其余是叠加层，分层规则见③段 §供给），并在 runbook §3.4 显式标注「本项目追加」。 - -DESIGN.md 说明：`@google/design.md` 提供 `lint` / `diff` / `export` / `spec` 四个子命令，目前是 alpha（v0.4.0）。非 TTY 的管道里可能不回显输出，需在真实终端里确认。本机实测该命令完全不可用，不要拿它当校验关卡；改由 D3 收口与 D5 终检按真实像素人工复测对比度（判据见③段 §供给·工艺数值判据 里配色那一份）。原两把门禁脚本（静态文案检查 / 渲染机检）已随旧主干从磁盘移除，当前没有机器复现，结论只能记「人工判定」，不得写成「脚本已通过」。 - -## 可调用工具（自然语言触发） - -> 两个随段携带的独立工具，装在③段 `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/` 里搬运的抽取脚本，不需要任何外部服务在场。用法与边界见各自 `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/<项目>/prd/*`；缺失时同样标 `【假设】`继续 -- ④只读 `designs/<项目>/*.html`，另按需读 `docs/pm/<项目>/prd/*` 校准术语；缺失时标 `【假设】`继续 - -## 执行规则 - -只有三种模式，没有第四种： - -| 模式 | 段之间 | 段之内 | -|---|---|---| -| 全流程（自动处理） | 一路跑完，段间不停下来问（含①段末）。每段结束按「标准收尾格式」输出一段报告，输出完即刻进下一段 | 子步之间不反问，做完直接进下一个子步 | -| 方案确认 | 与全流程完全相同，只有一处不同：①段末停下等你确认方案；确认后②③④一路跑完、段间不停 | 同上 | -| 单段 | 不涉及 | 不越界，不催促回补前段 | - -这两条是全流程模式下的两个独立分支，不要混：全流程（自动处理）没有①段末的强制停；「停下等确认方案」只在「方案确认」模式下发生。二选一由用户定（界面里点【生成原型和文档】时选「自动处理」或「先确认方案」，或在会话里直接说明）；用户没明说时按自动处理走，不要在自动处理模式下自作主张停下来问。 - -「停下」指什么，不要读成「每一步都要反问用户」。只有这四种情况才停： - -1. 信息不足且查不到，必须用户给（如「项目与路径约定」slug 第 4 条）——停下问 -2. 破坏性 / 不可逆动作——二次确认 -3. 用户显式要求某个子步做完停下 -4. ①段末的方案确认（仅「方案确认」模式）——把方案摆给用户：做什么 / 不做什么 / MVP 边界 / 未复核的 `【假设】`，明说「等你确认方案，确认前不进②段」 - -段末报告：全流程（自动处理）模式下，所有段（含①）都只输出报告，不提问、不等回答；方案确认模式下①段是唯一例外，其余段同样只输出报告。 - -①段末的确认是回环，不是一次问答（仅「方案确认」模式）：用户看到方案后可以提问题要求改，可能多轮，每轮的「问题＋怎么改的」都要留痕、不得覆盖上一轮；改完由用户显式说「确认方案」才算过闸门。该模式下，没拿到用户确认的方案不得当成既定事实带进②段——这是实测踩过的坑：②段拿着未经确认的方案往下跑，把用户已拍板的需求裁掉了。 - -其余规则： - -- 声明制（全段适用，不止③段）：开工前、每进一个子段或子步、每处偏离，都要声明三件事——当前在哪、依据哪个文件的哪一节、产出落哪；偏离当场写明原因与影响，段末附偏离单。不许静默偏离。实测踩过的坑：③段 3b 交付了原型却没走当时声明的主流程、没读依据文件，也没当场说，用户追问「基于哪个 skill」才知道。 -- 不做八股：不介绍方法论来源，不列人名，不复述框架历史，直接给结论。 -- ⭐ 内容准则：一切落盘文字都要先过「说人话」这一关（2026-10-07 用户定案，同日扩大到规则文件）。用户原话：「当作第一步 和 第二步 生成文档时 必须遵循的内容准则」「不管是写规则 还是 写文档 都要严格按照说人话的技能去执行」。 - - 适用面两类都算，只改产出不改规则等于半改。一是产出文档：`research/1a-需求文档.md` 到 `1e-使用场景.md`（5 份）、`research/1b-独立分析/`（独立分析体）、`prd/2a-产品功能.md` 与 `prd/2b-界面布局.md`（2 份）。二是规则本身：本技能包内的一切落盘文字，`SKILL.md`、`references/**`、模板与清单。 - - 判据来源（单一可信源，本文件不复述模式清单）：`humanizer`（55 条模式、5 种口吻档 casual / professional / technical / warm / blunt），`humanizer-zh`（24 条模式、快速检查清单、50 分制评分）。两份技能都在 `E:/ProgramData/.workbuddy/skills/`，完整判据以源技能正文为准。 - - 门槛：按 `humanizer-zh` 五维评分（直接性 / 节奏 / 信任度 / 真实性 / 精炼度）≥45 / 50 才准落盘；低于 45 回炉重写。 - - 五条核心原则（源技能《核心规则速查》摘引）：删填充短语（开场白、强调性拐杖词）；打破公式结构（二元对比、戏剧性分段、修辞性设置）；变化节奏（长短交错，两项优于三项，段尾多样）；信任读者（直接陈述事实，跳过软化、辩解、手把手引导）；删金句（读起来像可引用的话，就重写它）。 - - 交付留证：产出文档在段末报告里写明「已过内容准则，评分 X/50」；改规则文件时，在当日 memory 里记下这一关过了。 -- 只调一段时不越界：用户说「只做第 N 段」，就跑该段，不展开其他段，也不用「你还没做调研」去催促。 -- 提问上限 3 个：其余用合理假设，并在文档里标注 `【假设】`。例外是 `grill-me` 提问模式，不受此限（①段的「需求澄清」与②段的「需求压测」各一次），该模式的价值就是穷尽提问；此时须先声明「将连续多轮提问」，退出后恢复本约束。 -- 反问优先，允许自动补全：`grill-me` 的默认动作是把问题抛给用户并附推荐答案。用户说「你定」、连续两轮不回应、或属事实类问题时，模型自行给答案并标 `【假设】`，换来「不卡住」；但每轮结束要汇出待复核清单，未经复核的 `【假设】` 不得在下游当事实用。 -- 停线规则（**单一真源，全包只在本节写一次**，各段一律引用、⛔ 不复述）：只有三种情况停 —— ① 信息不足且查不到；② 破坏性／不可逆动作；③ 用户显式要求。 -- MVP 边界优先：任何阶段都先回答「第一版做什么、不做什么」。 -- 必须落盘：产出写入文件，不要只在对话里输出。 -- 无来源就标注：任何查不到来源的数据都标为「估算」并写明口径，不编造数字当事实。 -- 禁止长文：单份产出物默认一页纸（≤120 行），超长必须拆分。 - -## 每段的标准收尾格式 - -``` -## 本段结论 -- （3-5 条，可直接决策的话） - -## 已落盘 -- ... - -## 待确认（最多 3 条） - -## 建议下一步 -→ 用 完成 <具体事> -``` - -## 反面清单 - -- 为一个小功能跑完整调研 -- 输出长文却给不出一个结论 -- 跳过「不做什么」 -- 用户只问单点，却强行拉进全链路 -- 把估算数据写成确凿事实 -- 跳过③段 D0 的 Gate-1（未定死令牌表与设计契约）就开写页面代码 -- 在 `grill-me` 提问模式下仍套用「提问上限 3 个」，把提问做成走过场 -- 只跑一次 `grill-me`：①没定义需求就去取证，或②拿①段的需求定义代替功能压测直接写②段 -- 把自动补全当默认动作：用户没说话就替用户拍板，还没标 `【假设】`、没进待复核清单 -- 把④的说明区写进产品功能范围，或让③顺手把说明文档一起写了（该调 `stage-proto-doc` 就调） -- 手写 Mermaid 代替 diagram-design，手写 token 表代替 DESIGN.md -- 绕过四段自己手搓，或重写它们的内容（该调 `stage-*` 就调） -- 把供给件的内部路径按本 skill 目录去拼，或改它们的正文 —— 供给件指③段自带的 `oil-ui-pro`，以及 §供给 各档落在 `assets/` 下的件（它们是随③段携带的供给件，改动只写 `stage-delivery` 自己的 `SKILL.md` / `references/`；默认档与可选档平行，不缝成一条流水线，也不把 `oil-ui-pro` 的评分循环当成本段 Gate 的替代） -- 猜 `<项目>`：定不出来还硬写，把产物落到别的项目目录下 -- 把 `DESIGN.md` 写到仓库根：多项目会互相覆盖 -- 段间停下来问「要不要继续」：全流程（自动处理）模式下直接进下一段，只在段末输出报告 -- 把两种模式混用：在自动处理模式下自作主张停下问方案，或在「方案确认」模式下确认前就开跑②③④ -- 在「方案确认」模式下把①段的方案当成已确认就往下跑：该模式下①段末必须停下等用户确认（含「不做什么」） -- 下游擅自裁剪上游已拍板项：②③④发现要砍①段或决策表里已拍板的东西时，不许自行裁掉或改口径，必须列成「与已定决策的差异」交用户显式确认 -- 把模式当成段：模式是「要不要在①段末停」的开关，不是第五个段，别为它单独造段或造产物 -- 跑了却不说：没声明当前段 / 子步与依据文件，或偏离了被调 skill 的主流程却不声明、不记偏离单（应为：开工先声明、每个子步再声明、偏离当场声明） - -## 改名 / 改供给后的自检 - -```bash -python scripts/check_naming.py --ws <工作区> -``` - -它查四段段名与子步名在「总入口 ↔ 各段 `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` 都改了，但总入口的三处仍写着旧结构——四段表的②段子步列仍是「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/`（未直删，可随时取回）。 +--- +name: product-planning +description: 产品规划总入口（唯一入口），四段式调度：① 产品需求 ② 产品功能 ③ 界面交互 ④ 原型说明文档。四段以 references/stage-* 承载，本文件是总调度与约束。可整段跑也可只调一段。当用户要做产品规划、从零做新产品、只做某一阶段、或不知道从哪开始时调用。 +--- + +# 产品规划总入口 + +> 本 skill 由模型按需自动加载，没有斜杠命令。对话里还没定出对象时，先按「项目与路径约定」定出 `<项目>`；定不出来就停下问用户，不要自行假设。 + +## 用途 + +用户丢来一句模糊想法（例如「我要做一个 AI 短剧分镜画布」）时，本 skill 判断该走哪一段，只做那一段的最小必要工作，产出可交付物，再推进到下一段。 + +本文件管调度与约束。各段怎么做，写在 `references/stage-*` 各自的文件里。 + +## 四段结构（可整段跑，也可只调一段） + +| 段 | 回答的问题 | 子步 | 调用 | 产出物 | +|---|---|---|---|---| +| **① 产品需求** | 要做的东西凭什么成立：什么问题、为谁、为什么值得做 | 1a 需求文档（grill 压测）/ 1b 竞品分析 / 1c 用户画像 / 1d 产品策略 / 1e 使用场景 | `stage-discovery` | `docs/pm/<项目>/research/*`。其中 1b 交两种体例：`research/1b-竞品分析.md`（汇总对比）＋ `research/1b-独立分析/<竞品名>.md`（独立分析） | +| **② 产品功能** | 要做哪些功能、什么不做、长成什么骨架 | 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 节：做成什么样 / 哪些情况不成立 / 状态怎么流转）、取证结论（1b 汇总对比体 ＋ 1b 独立分析体、1c 用户画像）、产品定位、《使用场景》＝用户故事（②段功能的直接推导依据） | 功能清单归②段产出，1a 写到需求与形态为止 | +| ② → ③ | ② | 功能清单（每条带优先级 ＋ 状态流转）、界面布局（有哪几页 / 每页几个板块 / 板块怎么排 / 跨页关系）、每页主操作、信息承载分档（主屏常驻 / 可点入） | 视觉归③段。骨架必须给全，骨架不给全，③段就一版一个样 | +| ③ → ④ | ③ | 已跑通的单文件原型 HTML | 说明区与演示引导归④段 | + +> 口径：②段钉骨架，③段做皮肉。用户原话：「3 是负责设计和交互，页面关系和布局必须在第二步确认清楚，不然第三步没有方向 一会一个样子」。②段要给全的是有哪几页、每页几个板块、板块怎么排、跨页关系；③段不许增删移动板块，缺板块回②段改。配色 / 字体 / 间距 / 组件样式 / 动效，以及每个板块的视觉与交互实现，都归③段。 + +> ②→③ 最容易搞坏。旧病灶：②段说「必须能读到」，③段读成「必须常驻主屏」，五类信息就全铺一屏成了信息墙。分档表把「读到」明确成「一次点击内可达」，防的就是这句歧义。骨架是灰块（有哪些块、什么顺序），③段给的是视觉与交互实现（排版、点哪有什么反馈、空态、响应式）。两件事各管一维，③段不会退化成照抄。 + +> 四段各占一个词，互不共用（2026-10-02 定）：产品 / 功能 / 界面 / 说明。改段名前先对照这张表；两个段名里出现同一个词，边界一定在漂。旧名「调研与方案 / 需求与结构」都含「需求」，③段旧名里的「交付」是三段共有的属性，都属名实不符，已改。 +> ①叫「产品需求」不叫「需求调研」：该段产出 `research/1a-需求文档.md`、`1b-竞品分析.md`、`1c-用户画像.md`，也产出 `1d-产品策略.md`、`1e-使用场景.md`，「调研」二字盖不住后半截。 +> ⭐ 1b 是①段唯一交两种体例的子步（2026-10-07 用户定案「竞品分析 有独立分析也有汇总分析 都应该要用上」）：独立分析体 `research/1b-独立分析/<竞品名>.md`（竞品池每一个一份），汇总对比体 `research/1b-竞品分析.md`（恒一份）。职责边界见 `references/stage-discovery/references/competitor-analysis.md` §0.4。 + +⭐ `grill-me` 全场只有①段一份（2026-10-06 用户定案）：用户原话「grill 也应该拿到第一步了，第二部就是细化功能」。①段那份按 A / B 两节提问：A 节问「要做什么、为谁、边界在哪」，B 节问「做成什么样、哪些情况不成立、状态怎么流转」，B 节结论落进 `research/1a-需求文档.md`。 + +⭐ ②段产出两份（2026-10-06 收窄，2026-10-07 定为两份）：用户原话「不需要 就用使用场景，其余6分都不需要了」「2 产品功能 和 界面布局不就是两个文档嘛」。`prd/2a-产品功能.md`（功能清单：做哪些 / 不做哪些 / 每条带优先级 ＋ 状态流转）与 `prd/2b-界面布局.md`（页面关系 ＋ 页面内板块布局）。 + +（交接口反转前的口径、②段收窄前的产出清单与去向 → `references/_留痕/③段与总入口-旧口径.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」才知道。 +- 不做八股：不介绍方法论来源，不列人名，不复述框架历史，直接给结论。 +- ⭐ 内容准则：一切落盘文字都要先过「说人话」这一关（2026-10-07 用户定案，同日扩大到规则文件）。用户原话：「当作第一步 和 第二步 生成文档时 必须遵循的内容准则」「不管是写规则 还是 写文档 都要严格按照说人话的技能去执行」。 + - 适用面两类都算，只改产出不改规则等于半改。一是产出文档：`research/1a-需求文档.md` 到 `1e-使用场景.md`（5 份）、`research/1b-独立分析/`（独立分析体）、`prd/2a-产品功能.md` 与 `prd/2b-界面布局.md`（2 份）。二是规则本身：本技能包内的一切落盘文字，`SKILL.md`、`references/**`、模板与清单。 + - 判据来源（单一可信源，本文件不复述模式清单）：`humanizer`（55 条模式、5 种口吻档 casual / professional / technical / warm / blunt），`humanizer-zh`（24 条模式、快速检查清单、50 分制评分）。两份技能都在 `E:/ProgramData/.workbuddy/skills/`，完整判据以源技能正文为准。 + - 门槛：按 `humanizer-zh` 五维评分（直接性 / 节奏 / 信任度 / 真实性 / 精炼度）≥45 / 50 才准落盘；低于 45 回炉重写。 + - 五条核心原则（源技能《核心规则速查》摘引）：删填充短语（开场白、强调性拐杖词）；打破公式结构（二元对比、戏剧性分段、修辞性设置）；变化节奏（长短交错，两项优于三项，段尾多样）；信任读者（直接陈述事实，跳过软化、辩解、手把手引导）；删金句（读起来像可引用的话，就重写它）。 + - 交付留证：产出文档在段末报告里写明「已过内容准则，评分 X/50」；改规则文件时，在当日 memory 里记下这一关过了。 +- 只调一段时不越界：用户说「只做第 N 段」，就跑该段，不展开其他段，也不用「你还没做调研」去催促。 +- 提问上限 3 个：其余用合理假设，并在文档里标注 `【假设】`。例外是 `grill-me` 提问模式，不受此限（①段的「需求澄清」与②段的「需求压测」各一次），该模式的价值就是穷尽提问；此时须先声明「将连续多轮提问」，退出后恢复本约束。 +- 反问优先，允许自动补全：`grill-me` 的默认动作是把问题抛给用户并附推荐答案。用户说「你定」、连续两轮不回应、或属事实类问题时，模型自行给答案并标 `【假设】`，换来「不卡住」；但每轮结束要汇出待复核清单，未经复核的 `【假设】` 不得在下游当事实用。 +- 停线规则（**单一真源，全包只在本节写一次**，各段一律引用、⛔ 不复述）：只有三种情况停 —— ① 信息不足且查不到；② 破坏性／不可逆动作；③ 用户显式要求。 +- MVP 边界优先：任何阶段都先回答「第一版做什么、不做什么」。 +- 必须落盘：产出写入文件，不要只在对话里输出。 +- 无来源就标注：任何查不到来源的数据都标为「估算」并写明口径，不编造数字当事实。 +- 禁止长文：单份产出物默认一页纸（≤120 行），超长必须拆分。 + +## 每段的标准收尾格式 + +``` +## 本段结论 +- （3-5 条，可直接决策的话） + +## 已落盘 +- ... + +## 待确认（最多 3 条） + +## 建议下一步 +→ 用 完成 <具体事> +``` + +## 反面清单 + +- 为一个小功能跑完整调研 +- 输出长文却给不出一个结论 +- 跳过「不做什么」 +- 用户只问单点，却强行拉进全链路 +- 把估算数据写成确凿事实 +- 跳过③段 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` 写到仓库根：多项目会互相覆盖 +- 段间停下来问「要不要继续」：全流程（自动处理）模式下直接进下一段，只在段末输出报告 +- 把两种模式混用：在自动处理模式下自作主张停下问方案，或在「方案确认」模式下确认前就开跑②③④ +- 在「方案确认」模式下把①段的方案当成已确认就往下跑：该模式下①段末必须停下等用户确认（含「不做什么」） +- 下游擅自裁剪上游已拍板项：②③④发现要砍①段或决策表里已拍板的东西时，不许自行裁掉或改口径，必须列成「与已定决策的差异」交用户显式确认 +- 把模式当成段：模式是「要不要在①段末停」的开关，不是第五个段，别为它单独造段或造产物 +- 跑了却不说：没声明当前段 / 子步与依据文件，或偏离了被调 skill 的主流程却不声明、不记偏离单（应为：开工先声明、每个子步再声明、偏离当场声明） + +## 改名 / 改供给后的自检 + +```bash +python scripts/check_naming.py --ws <工作区> +``` + +它查四段段名与子步名在「总入口 ↔ 各段 `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` 都改了，但总入口的三处仍写着旧结构——四段表的②段子步列仍是「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/`（未直删，可随时取回）。 diff --git a/product-planning/references/stage-delivery/SKILL.md b/product-planning/references/stage-delivery/SKILL.md index c9f360c..c691d5b 100644 --- a/product-planning/references/stage-delivery/SKILL.md +++ b/product-planning/references/stage-delivery/SKILL.md @@ -1,377 +1,384 @@ ---- -name: stage-delivery -description: 产品规划第③段，界面交互。设计工程供给默认来自 oil-ui-pro（方法主线与独立评审）加本段自带样式库（定调与令牌），另有可选供给档（本段自带、可选择使用；供给关系见正文 §供给）：先落设计契约与令牌表（Gate-1 硬闸），再构建页面，再收口/动效/终检（Gate-2/3），中途加一轮 GPT 参考版。判据结构为「正向目标为主、禁令只留最关键三条」。当用户要做 UI 规范、设计系统、页面原型、交互动效、界面审查、视觉打磨，或说"只做界面交互"时调用。 ---- - -# ③ 界面交互 - -回答两个问题：长什么样、怎么操作。产出 `docs/pm/<项目>/DESIGN.md` 与 `designs/<项目>/*.html`。 - -> 段名为什么是「界面交互」（2026-10-02 定）： -> 删「交付」：①②③都产出落盘文件，「交付」是三段共有的属性，不是③的专属；④段也在交付（原型的说明区），留着会让人以为③管完就结束了。 -> 补「交互」：本段原先只讲「长什么样」，可 3b 原型硬要求每个按钮、每个跳转都真能走（`:236`），3c 的参考版对照也要逐项看空态 / 加载 / 错误 / 反馈（`:148`、`:150`）。交互判据一直在做，却没有名字，补上才与本段实际职责相符。 -> 与④段的界：③造物（界面与交互本身），④描述物（说明区与演示引导）。 - -> `<项目>` 按 `product-planning` 的「项目与路径约定」定；定不出来就停下问用户，不许猜。`DESIGN.md` 放项目目录，不放仓库根，避免多项目互相覆盖。 - -## 供给（唯一权威处 · 改供给只改这一块） - -> 🔴 ③段的供给关系**只在本块定义一次**。本文件其余章节、`references/execution-runbook.md`、`references/layouts-tooling.md`、以及总入口 `product-planning/SKILL.md`，提到供给时一律**引用本块的行名**（写成「见 §供给·定调与令牌」这样，行名就取下面那张表的左列），⛔ 不许再复述「谁是默认、路径在哪、装了才有」。 -> 改了供给 ⇒ 只改本块，然后跑 `scripts/check_naming.py`；发现别处有复述 ⇒ 删掉、改成引用。 -> ⚠️ 边界：本块管「有哪几档、谁默认、路径从哪个根起」。各档内部的具体篇目（如可选档工艺判据下的某一篇）属执行细节，留在 `references/execution-runbook.md` 各步里 —— 那些不算复述，改档不会牵动它们。 -> ⚠️ 为什么立这一块（2026-10-08 用户定）：此前这一个事实被复述约 40 处，改一次（默认主线由 `open-design` 换成 `oil-ui-pro`）动三份文件 17 处，仍然漏掉 13 处口径 —— 那是复述式写法必然的代价。单一可信源才拦得住漏改。 - -| 供给位 | 默认来源 | 可选来源 | 管什么 | 用在哪 | -|---|---|---|---|---| -| 方法主线 | `oil-ui-pro`（全局技能，按技能名引用） | 无 | 方向探索 → 建结构 → 取实证 → 独立评审打分 → 验证交付 | 全段；3a / 3d 最重 | -| 定调与令牌 | 自带样式库 `assets/design-systems/<选定一套>/`（随段携带，现 1 套 `design-system-tiaoyue`） | `assets/open-design/design-systems/<选定一套>/`（153 套） | 调性、全套令牌、组件形态。⚠️ **能力边界（2026-10-08 实测补充）**：自带样式库实测只到**调色板级** —— 语义色 / 圆角 / 字体栈 / 按钮与输入框令牌；**几何与版式不在包内**（栏宽、项高、内衬、间距、组件尺寸一律没有），参考 `design-system.html` 里也**不含源站的界面骨架**。⛔ 不许把「供给在位」读成「已经有设计系统了」；要几何就**回源站实测**或另找来源，拿不到就在 3d 里明说无来源 | 3a 的 D1 | -| 版式骨架 | `references/layouts-tooling.md`（工具型页面用） | `assets/open-design/design-templates/web-prototype/`（营销页向；工具型⛔ 不许套） | 工具型九档的名单与判读见 `references/layouts-tooling.md` §0（⛔ 本块不复述名单；2026-10-08 追加「导航栏」一档 = §4.9） | 3b | -| 工艺数值判据 | `references/execution-runbook.md` §3.4 ＋ `references/layouts-tooling.md` §5.5 | `assets/open-design/craft/`（13 份） | 字阶 / 配色 / 状态齐备 / 动效纪律 / 反 AI 味 / 无障碍。⚠️ **未选可选档时，后四项（反 AI 味 / 无障碍 / 动效纪律 / 表单校验）没有供给来源** ⇒ 必须在 `3d-审查报告.md` 里逐项显式记为**本段证据缺口**（写「无供给来源，本项未判」），⛔ 不许默不作声地跳过、也⛔ 不许拿别的判据冒充它过了 | 3a 判据、3d 终检 | -| 独立评审协议 | `oil-ui-pro` 的 `references/visual-review.md` ＋ `references/tools.md` | 无 | 没看过制作过程的评审打分 ＋ 截图取证 | 3d | -| 多方向比选 | `oil-ui-pro` 的 `references/design-direction.md` ＋ `references/style-explorer.md` | 无 | 方向卡与风格对比页 | 3a 按需 | - -> 🔴 供给是**分层**的（2026-10-08 用户定案）：`oil-ui-pro` 是**基础层** —— 视觉与体验的底线判据都出自它；其余各档（定调与令牌 / 版式骨架 / 工艺数值判据 / 本段自有的 `execution-runbook.md` 与 `layouts-tooling.md`）都是**叠加层**：可以在它之上叠加更多设计规范，只许**更严、更具体**，⛔ 不许**放宽或推翻**基础层。叠加层与基础层冲突 ⇒ **以基础层为准**。 - -> ⭐ 可选来源只有一处：`open-design` —— **随段携带的本地裁剪件**（源 `nexu-io/open-design@0.23.1`，Apache-2.0；署名与裁剪说明见 `assets/open-design/ATTRIBUTION.md`，装在 `assets/open-design/`）。它是**独立技能、可选择使用**：选了才用，不选不影响本段开工。 - -`open-design`（上面那张表的可选来源）给三处，都在 `assets/open-design/` 下： - -1、`design-systems/<选定一套>/`：`DESIGN.md` 定调性 ＋ `tokens.css` 给全套数值（圆角与阴影在这里）＋ `components.html` 给组件形态。 - -2、`craft/`：字号刻度 / 配色配额 / 状态齐备 / 动效纪律 / 反 AI 味 / 无障碍。 - -3、`design-templates/web-prototype/`：种子 `assets/template.html` ＋ 8 个版式骨架 ＋ 自查清单。 - -⭐ 选了自带的 `design-system-tiaoyue` 时怎么读（⚠️ 套内命名与 `open-design` 不同形，别按 `DESIGN.md` 去找）： - -| 要什么 | 套内路径 | -|---|---| -| 入口（规范总纲、生成时的参考范围） | `assets/design-systems/design-system-tiaoyue/SKILL.md` | -| 令牌（含暗色一套） | 同目录 `assets/tokens.css` ＋ `assets/tokens-dark.css`（色值原始记录 `assets/brand.json`） | -| 组件形态 | 同目录 `references/components.md` ＋ `references/design-system.html`（组件族清单 `references/library.json`） | -| 已知冲突 / 取舍记录 | 同目录 `references/known-conflicts.md` ＋ `references/capture-notes.md` | - -> ⚠️ 路径怎么找：自带件一律按**段内相对路径**引用（`assets/open-design/...`、`assets/design-systems/...`），⛔ 不按绝对路径爬、⛔ 不写死 `../` 层数；`oil-ui-pro` 按技能名引用（宿主按名加载，与物理位置无关）。 -> 🔴 定调来源唯一：每次设计只选一套，默认与可选**不混用**（混用 = 没有调性）。套名与选择理由写进 `DESIGN.md`。 -> ⛔ 判据正文仍只在本段（`references/execution-runbook.md` 与 `references/layouts-tooling.md`）。⚠️ 供给是分层的，分层定义见 §供给：`oil-ui-pro` 是**基础层**，本段自有判据是**叠加层**；同一条判据两处都有且口径不同时，⛔ 本段不许放宽基础层，只许更严、更具体，并在 runbook §3.4 标注「本项目追加」。 -> ⛔ 不许把 `oil-ui-pro` 的评分循环当成 D 阶段的替代：它是评审方法，Gate-1/2/3 该过还得过。 -> ⛔ 不动用可选来源时，⛔ 不许凭感觉编一套顶上（那正是本项目反复踩的坑）；craft 独有的那几项（反 AI 味 / 无障碍 / 表单校验 / 动效纪律）明说「本次无供给来源」。 -> ⚠️ `oil-ui-pro` 自带联网版本检查与自动更新（每次使用会连 `ui.oiloil.org`，发现新版用 `npx` 覆盖自身目录）。这是本项目收录时用户明确要求全量搬入的例外项，与「依赖外部服务一律不收」的既有纪律冲突，记录在案，不扩散到其他技能。想关掉设环境变量 `OIL_NO_UPDATE_CHECK=1`。 -> 供给件都不依赖付费云 / MCP / API Key 才能用于设计：`open-design` 去掉那些之后剩下的全是静态 md / css / html（其 daemon、云模型服务、`packages/components` 的 tsx 未收录）；`oil-ui-pro` 的设计方法宿主中立、离线可用（联网仅用于版本检查）。 -> 冲突处以 §供给·方法主线（基础层）为准；本段自有判据与 `DESIGN.md` 是叠加层，只许更严，⛔ 不许与基础层相反。供给件的价值在给正向目标、给方法。 - -> 为什么换掉原来的主干（2026-10-02 用户定案）：原主干 `ui-page-design` 已从磁盘移除，③段只剩规则壳，壳里又全是减法型判据，机检能判「不违规」却判不出「好看」，18 轮回改把页面越推越白。换供给的同时必须换判据结构：正向目标为主，禁令只留最关键的。 - -> ⭐⭐ 本段在②段给定的骨架里做视觉与交互（2026-10-06 用户定案）。 -> -> 口径：②段钉骨架，③段做皮肉。 -> -> 🔴 「②段管什么、本段管什么」的完整清单（含两侧逐行对照）只在②段 `references/stage-requirements/SKILL.md` -> 的 §②—③ 交接口 定义一次 —— ⛔ 本文件不复述那张表，免得两处漂。用户原话也放在那一节，此处不再抄。 -> -> 🔴 旧口径站不住的地方：它把「有哪几页」留在本段，于是本段做一版一个样，②段手里没有任何东西能判断本段改得对不对。 -> ⭐ 本段拿到的骨架是冻结的：⛔ 不许新增 / 移动 / 删除板块。缺板块要回②段改②段（见「硬约束」的对应禁令）。 -> -> 仍在本段手里的两个字段（它们在给定骨架之内决定怎么摆得好看）： -> - `必要内容`（减法）：⚠️ 口径已调整。它不再决定哪些内容上屏（那是②段分档表的活），而是核对②段给的信息是否都在骨架里有落点；⛔ 本段不得以它为由增删信息档位。 -> - `结构骨架`（加法）：⚠️ 口径已调整。它不再独立决定几个区块，而是把②段给的板块清单翻译成具体的骨架档 / 列宽 / 密度目标（骨架档选哪个、密度多少，仍是本段的活）。 -> -> ⛔ 本段不许回头改②段的骨架（那是②段）；⛔ 也不许无视②段骨架自己另起一套。判据：D0 里的页面清单与每页板块，必须与②段《界面布局》逐条对得上；对不上就停下来问②段要哪一版。 - -顺序 3a → 3b → 3c → 3d。先有规范再出原型，不许反过来；原型能点通后先取一份外部参考版，再收口打磨。 - -> 照 `references/execution-runbook.md` 逐步走。那是本段的固化执行手册：按 D 阶段排的必读表、每步验收判据、脚本跑法、偏离单格式、完成标准清单都在里面。本文件写规则，手册写顺序与验收。 -> 开工前先声明、每进一个子步再声明、偏离当场声明（三字段：当前子步 / 依据文件 + 小节号 / 产出落点）。这条不可商量。 - -## 子步与产物 - -| ③段子步 | 做什么 | 产物 | 闸 | -|---|---|---|---| -| 3a 视觉规范 | 定契约（减法 + 加法）→ 定调（选定设计系统）→ 落令牌表〔方法主线按 `oil-ui-pro` 的方向探索走；要拉开方向让用户挑时用它的对比页〕 | 设计契约 + 令牌表 → `DESIGN.md` | Gate-1 方向门 | -| 3b 原型 | 按模板种子 + 版式骨架构建 | `designs/<项目>/<原型>.html` | — | -| 3c GPT 参考版 | 让 GPT 按需求＋风格**独立生成一版当参照物**（本段特有，两个设计技能都不覆盖） | `3c-GPT参考版.md` | — | -| 3d 审查与打磨 | 收口 → 动效 → 终检〔按 `oil-ui-pro` 的评审协议做一轮独立评审打分〕 | file:line 清单 + `3d-审查报告.md` | Gate-2 / Gate-3 | - -挡位开工前定一次，默认标准：纯原型可降快速（定契约 → 定调 → 构建 → 终检）；常规页面走标准（全跑）；对外页面走严格（三闸全开 + 中间产物落盘）。 -`Gate-1` 与 `Gate-3` 是硬闸，任何挡位都不可跳，哪怕只做原型，也要打开看一眼。 - -## 三条铁律（只留不可省略的） - -| # | 铁律 | 违反后果 | -|---|---|---| -| 1 | 先定死，再写码。未产出设计契约与令牌表前，禁止写任何组件代码；禁止边写边调样式。 | 返工、风格漂移 | -| 2 | 状态穷举。`loading / empty / error / success / disabled / 无权限` 逐项给结论（判据见 §供给·工艺数值判据）。 | 上线即翻车（最高频漏项） | -| 3 | 不渲染不算完。交付前必须在真实环境渲染一次并肉眼确认。 | 裁切/重叠/失效控件逃过检查 | - -> 禁令就这三条，其余一律去 §供给·工艺数值判据 里查（默认档按本段两份的对应章节；可选档按其工艺篇目，逐篇见 §供给·工艺数值判据）。 -> ⛔ 不在本文件里抄写禁令清单。抄了就变两份，两份必然漂；更要紧的是，抄禁令会把正向目标挤出视野，这正是改版前③段只剩「不要什么」、页面越改越白的根因。 -> 一条例外（本项目特有，供给件里没有）：结构性容器靠底色差 + 阴影分层，不挂围合边框（来源：本项目 E-62 / E-63 实测）。当选定设计系统写「卡片描边」时，以本条为准。 -> 限载：同一时刻只读 1~2 份供给原文，用完释放。这条不再单列铁律，但仍是硬约束（可选档定调候选与工艺判据份数都不小，全读必然互相稀释）。 - -## 必读（限载：一次只读 1~2 份，用完释放） - -| 环节 | 取哪些供给位（定义见 §供给） | -|---|---| -| 3a 方法主线 | §供给·方法主线 | -| 3a 定调 | §供给·定调与令牌（默认档；要用可选档就在 `DESIGN.md` 写明理由）。入口 / 令牌 / 组件形态按 §供给 里的「套内怎么读」取 | -| 3a 判据 | §供给·工艺数值判据（本项目追加条在 `references/execution-runbook.md` §3.4） | -| 3a 多方向比选（按需） | §供给·多方向比选 | -| 3b 构建 | §供给·版式骨架 ＋ §供给·工艺数值判据（工具型只取默认档） | -| 3d 独立评审 | §供给·独立评审协议 | -| 3d 终检 | §供给·工艺数值判据 ＋ §供给·版式骨架 | - -> ⚠️ 3b 只取 §供给·版式骨架 的默认档。可选档那套（`web-prototype`）是营销落地页向，只在判「要不要套它的流程」时读。 -> ⚠️ 本表只写「哪一步取哪个供给位」，⛔ 不写路径、不写默认判断 —— 那些只在 §供给 定义一次。 -> 本段 `references/` 只放流程规则，⛔ 不放风格；随段携带的样式风格一律放 `assets/design-systems/<套>/`（🔴 2026-10-07 用户令两条：「把 `design-system-tiaoyue` 整合到 `product-planning` 作为一种样式风格」＋「后续可以添加多种风格，每次只能选择一种进行设计」⇒ 只把「不放风格」这条放宽到 `assets/`，`references/` 仍不放）。 -> ⚠️ 续加新风格时的硬要求：目录名与可选档同形（`assets/design-systems/<套名>/`），套内自带入口文件（`SKILL.md` 或 `DESIGN.md`）；⛔ 不许改已入套的文件内容，原样搬入、只在本文件登记去向。 -> 🔴 定调来源唯一（两档见 §供给·定调与令牌）：每次设计只选一套，⛔ 不许混用两档（混用 = 没有调性）。套名与选择理由写进 `DESIGN.md`。 -> 既有项目中凡引用旧风格来源（`minimalist-ui` / 皮肤族 / `ui-ux-pro-max` 检索结果）的 `DESIGN.md` 行，重跑 3a 时一律改写为选定套 + 留痕对照。 - -## 3a 视觉规范（定契约 + 定调 + Gate-1） - -第 0 步 · 供给核对（每轮必做，防漂移）：按 §供给 逐档核对在位 —— 默认档必核，可选档**选了才核**（其可选来源那三处，见 §供给 表）。核完把选定套名与 `DESIGN.md` 里记录的上次套名比对。 - -- 一致 → 直接定契约。 -- 不一致或供给缺失 → 先停下报告，⛔ 不许拿别的套顶上，也不许凭记忆写风格。把差异列成「供给变更清单」，在会话里向用户呈现并确认后，再改 `DESIGN.md`，把新套名与清单写进修订记录。 -- 本步存在的理由：`DESIGN.md` 是上一次供给状态下产出的。供给换了却没核对，就会长期拿着旧调性当准绳。 - -D0 锚需求：按 `references/execution-runbook.md` §2.1 的契约模板产出设计契约（十二个字段）。字段清单与逐条判据以 §2.1 为准 —— ⛔ 本文件不重复列，免得两处漂。 - -> ⭐⭐ 第十二字段「交互清单」是 2026-10-02 新增，段名改名的直接后果（段名从「界面与交付」改成「界面交互」，但「交互」在流程里此前没有落点：可点通在 3b、查反馈在 3c、动效在 3d，三处各判一部分，谁也不负责整体）。 -> 它写什么：逐个可点元素一行，四列——元素（哪个）｜触发（点了/输了/滚到哪，发生什么）｜反馈（状态怎么变、给什么提示、多久消失）｜何时不可点（哪些条件下 `:disabled`，条件是什么）。 -> 它不写：动效参数（归 3d 按 §供给·工艺数值判据）、视觉样式（归令牌表）、状态六项的有无判定（归下一字段 `状态覆盖`，本字段只写「这个元素可点时点了会怎样」）。 -> 为什么是契约字段而不是新子步：交互一旦单独成文，就会与 `必要内容`、`状态覆盖` 三处互相矛盾——这正是记忆里「同一事实多处落点必然打架」的病。收进契约 = 一个字段、一处裁决、一个门禁。 -> 判定「漏没漏」：页面里每一个能点的东西都必须在这张表里出现。表里没有 ⇒ 它不该可点（改成静态文本，或回 D0 补进 `必要内容` 再点）。 - -D1 定调：从 §供给·定调与令牌 的默认档里选一套；要用可选档就从可选档里选（⛔ 每次只选一套，两档不混用），不凭感觉编，也不全读： - -- 怎么选：按本项目的页面类型挑。读候选套 `DESIGN.md` 的第 1 章 `Visual Theme & Atmosphere`，认准写明该类的那一句（工具型数据密集界面 ⇒ 认 `data-dense, enterprise` 这类描述）。可选档的候选分两代模板（A 组 / B 组章节名不同），按自己那套的章节读，不必统一。 -- ⚠️ 选了自带库那套（`design-system-tiaoyue`）时：套内没有 `DESIGN.md` ⇒ 读它自己的 `SKILL.md`（规范总纲 ＋ 生成时的参考范围）＋ `references/known-conflicts.md`（已知取舍）；入口 / 令牌 / 组件形态按 §供给 里那张「套内怎么读」表取，⛔ 别按可选档那套的三件套去找。 -- 选定后读三件：`DESIGN.md`（调性 + 色值 + 字号刻度 + 间距刻度 + 动效基调）→ `tokens.css`（圆角与阴影只有这里）→ `components.html`（组件实际长相）。 -- 要换风格 ⇒ 下一轮重跑 D1 重选一套，旧套留痕（用户 2026-10-07：「后续可以添加多种风格，每次只能选择一种进行设计」）。 -- 没找到匹配的套 ⇒ 换一个类型词再挑一次；仍不行就直说「未找到匹配」，不许拿泛化结果当结论落盘。 -- ⚠️ 工具型页面的版式不在可选档的模板里（可选档是营销页向；骨架名单与理由见 `references/layouts-tooling.md` 开头）。工具型页面的版式由 D0 的 `结构骨架` 字段决定，不从模板抄。 - -- 产出令牌表：色值 / 字体（标题字体是关键项）/ 间距两档（主刻度 `4/8/16/24/32/64` 供布局 + 控件层微网格 `2/4/6/8/12` 仅供按钮内衬、徽章内衬、图标间隙、开关与进度轨微几何）/ 圆角 / 字阶定值表（七档各一个 px，不是区间）/ 高度层级（每层都有多层叠层值）/ 布局脚手架（骨架档落到具体列宽 + 窄屏变化）/ 组件规格（按钮三档 + 卡片两档 + 输入框 + 徽章的具体高度与内衬；实底底色 ≥2 种）/ 动效基调——全部为具体值，禁止「待定」，每档只许一个定值 - -落盘 `docs/pm/<项目>/DESIGN.md`：令牌表内容并入本项目既有的三层 token 结构（primitive → semantic → component；组件只引语义层、语义层只引 primitive），设计契约作首节。`DESIGN.md` 是原型的绑定规范，原型只许引它的 token。 - -Gate-1 方向门（硬闸，不可跳）——按本表逐项自检（字段定义与填写位见 `references/execution-runbook.md` §2.1；⛔ 供给件没这一项，十二字段只能在此判）： - -| 检查项 | 通过条件 | -|---|---| -| 设计契约 | 十二个字段全部填写，无一为空或「待定」；有重复项时重复项的信息量已逐条列出次级信息 | -| 页型判定（2026-10-05 新增） | 已写出「营销页还是工具型页面」+ 依据；工具型页面的 D0 里零 `.eyebrow` / 零 `.lead` / 零 `.hero` | -| 结构骨架（加法面） | 骨架档 / 区块划分 / 密度目标三者已写；区块 ≥2 个且每个有文字标题；`必要内容` 每条都有归属区块 | -| 交互清单（加法面，2026-10-02 新增） | 页面上每一个可点元素都在表里（元素 / 触发 / 反馈 / 何时不可点 四列齐全）；表里没有的可点元素为 0 | -| 状态覆盖 | 六个状态逐项有结论（勾选，或「不适用 + 理由」） | -| 令牌表 | 色值 / 字体 / 间距两档且适用面已分开写 / 圆角 / 阴影全为具体值 | -| 字阶定值表 | 七档每档一个 px 定值（不是区间）；相邻档差 ≥2px；每档只许一个定值 | -| 高度层级 | 每层都有多层叠层值；同层级同值 | -| 布局脚手架 | 骨架档已落到具体列宽；窄屏变化写具体 | -| 组件规格 | 按钮三档 + 卡片两档 + 输入框 + 徽章均为具体值；同一父区块内主档 ≤1；实底底色 ≥2 种 | -| 供给核对（本项目附加） | 按 §供给 逐档核对在位（默认档必核，可选档选了才核）；选定套名与 `DESIGN.md` 记录一致；不一致则变更清单已确认并写入修订记录 | -| 反 slop | 无紫→粉渐变、标题未用禁用字体、强调色已写明允许位置 | -| 拒绝清单 | ≥3 条，且每条可判定 | -| token 引用完整性（本项目附加） | 语义层只引 primitive、组件层只引语义层、无孤立 token | - -任一项不过 → 停在 3a 补齐，不进 3b。 - -> 对比度门槛见 §供给·工艺数值判据 里配色那一份（数值登记在 `references/execution-runbook.md` §3.4 的数值判据段），由终检阶段按真实像素复测（静态算不准 CSS 变量叠加后的结果）。 -> 已知环境问题：`npx @google/design.md lint` 在本机完全不可用（alpha + clack 交互库，非 TTY 管道下静默且 exit 0）。不要拿它当校验关卡，也不要因它无输出就认为通过。 - -## 3b 原型（构建） - -> ⛔ 开工前先判页型（2026-10-05 新增，硬前置）：写下「本页是营销页还是工具型页面，依据是什么」。 -> 两种页型的目的不同，骨架不能通用：营销页目的是说服（主张 → 论据 → CTA），工具型页面目的是完成一件工作（数据 + 操作）。 -> 判别口径：要用户「下决心去做某事」⇒ 营销页；要用户「把这件事做完」⇒ 工具型页面。⚠️ 判不准时按工具型处理（默认取严）。 -> 判不出来不许进 3b，停下来回改 D0 的 `结构骨架`。 -> 🔴 为什么这条是硬前置：§供给·版式骨架 可选档那套的种子 `assets/template.html` 是营销落地页骨架，自带 `.eyebrow`（眉标）与 `.lead`（副标题）。不判页型就照种子做，会得到「标题上方一行小字 + 大标题 + 下方一行灰色小字」的三段式——那是 2026-10-05 用户实测指出「像实习生画的」的唯一根因，而且结构判据全绿（判据判类名合法性，判不出「这不是工具界面的排版」）。页型不判，后面换什么设计系统都救不回来。 - -要选可选档时，可按它那份 `SKILL.md`（§供给·版式骨架 的可选档）的六步走：读种子 → 把 `assets/template.html` 复制成 `index.html` 并替换 `:root` 令牌 → 先定版式节奏再粘骨架 → 填充 → 自查 P0/P1/P2 → 落盘。不选它就按默认档（`references/layouts-tooling.md`）的骨架与落地自检走。两条路线都要求「先选定一个明确的美学方向再写码」，与铁律 1 同向。 - -- ⭐ 工具型页面先判形态，再挑骨架（2026-10-02 新增）：读 §供给·版式骨架 的默认档。本项目是工具型数据密集界面，可选档那套是营销页向、与本项目不匹配（名单与理由见 `references/layouts-tooling.md` 开头）。 - ⚠️ 两份工具型文件的分工（2026-10-05 补）：本技能 `references/layouts-tooling.md` 给可粘贴 HTML 骨架 + 逐条判据正文（§5.5），是默认档；选了可选档时，它那份 `tooling.md` 另给四形态判定句 + 通用红线纲要，只作指路。⛔ 判据只在 `layouts-tooling.md` 展开，`tooling.md` 只指路，两处展开必然漂。 - 形态判定一句话：页面上能数出「并列的同类记录」⇒ 列表型（工具型默认首选）；数不出、页面围绕单个对象展开 ⇒ 详情型；主操作要在两个工作面之间来回 ⇒ 侧区型。 - ⛔ 不许拿营销页骨架顶替工具型，那是「没做形态判定」的默认行为，等于退回 18 轮前的病根。判不出形态就去改 D0 的 `结构骨架` 字段，⛔ 不许随手挑一个。 -- 不许从零手写 `
`：先挑最接近的骨架粘进去再改。用了可选档时，可选档那套的 `layouts.md` 开头的类清单（`section` / `container` / `card` / `btn-primary` / `grid-3` …）必须在种子 `template.html` 的 `