diff --git a/.workbuddy/memory/2026-10-08.md b/.workbuddy/memory/2026-10-08.md index 991ee62..ca3bcee 100644 --- a/.workbuddy/memory/2026-10-08.md +++ b/.workbuddy/memory/2026-10-08.md @@ -971,3 +971,23 @@ **这解释闸门 12 条 FAIL 的真根因**：9 条复述类的源头就是那 4 处权威声明被删 —— 声明一没，别处复述看似"合法"，而闸门 AUTHORITY 表仍要求声明所在的结构成立，于是集体报红。**所以正确修序是「先恢复权威声明、再清复述」。** **当前状态**：我已在**被覆盖的基线**上改了约 20 处（B 方案 4 处 ＋ 12 条里的十来处），**已停手等用户定基线**，未提交。 + +--- + +## 第十三轮 · B 方案执行完毕：存档 ＋ 整包回退（用户令「B方案」） + +**① 存档**（工作区 `归档/技能包-说人话改写-被覆盖存档-20261008/`）： +- `改动对照.diff` —— `44d42b0` → `1d7d31a` 全量 diff，2445 行 +- `说人话版全文/` —— `1d7d31a` 版的 7 个文件全文（照原目录结构） +- `README.md` —— 这是什么／怎么用（⛔ **只取措辞、不取 5 类结构损坏**，逐条列明）／可复现判据／教训 + +**② 替换**：`git checkout 44d42b0 -- product-planning/`（在全局技能仓；⛔ 没碰 `session-mechanism/references/manifest.md`，那是另一会话在改的） + +**③ 复查全绿**： +- 闸门 `2060 ｜ 0 ｜ 27` ✅（与 `44d42b0` 时完全一致） +- 「唯一权威处」声明 2 个文件 ✅｜`## 供给（唯一权威处 · 改供给只改这一块）` 标题 ✅｜六行供给表（方法主线 ＝ `oil-ui-pro`）✅ +- `runbook`「供给能力边界已核对」勾选项 ✅｜「本条无机检」2 处 ✅ +- `3c GPT参考版` 在 SKILL.md ／ stage-delivery ／ runbook ／ `check_naming.py` **四处一致** ✅ + +**④ 技能仓提交**：`8fc9a92`（已推 `46bee95..8fc9a92`）。 +⇒ 我工作区那约 20 处修补随替换一并作废（它们本就是在被覆盖的基线上做的），属于预期。 diff --git a/.workbuddy/memory/MEMORY.md b/.workbuddy/memory/MEMORY.md index 7d5e6b8..00073b5 100644 --- a/.workbuddy/memory/MEMORY.md +++ b/.workbuddy/memory/MEMORY.md @@ -46,7 +46,7 @@ - 🔴 **工作区已 git 化**（2026-10-08 08:1x）：远端 `git@ssh.alotbuy.com:admin/contentm_agent.git`（Gitea，SSH deploy key **有写权限**），本地分支 `main`，首次提交 `df56c2c`（1773 文件 / 205 MiB pack）、第二次 **`eee042c`**（10-08 22:xx，③段第八轮收口，48 文件），均已推送。`.gitignore` 排运行时噪音（collab 日志／脚本 `.bak*`／`supervise.pid`／`.workbuddy/tmp/`／`tmp/_*.txt`／`**/ui/_scratch/`／`__pycache__/`／`tmp/_bh_shots/`·`_figma_preview/`·`_gpt_dl/`／`.workbuddy/.load-pending`），**参考资料 231M 抽帧素材全量入库**（⛔ 不打折）。提交者身份是**局部**配置的 `WorkBuddy `（全局 git config 未动），可推翻。 - 🔴 **全局技能仓**（`E:/ProgramData/.workbuddy/skills`）是**独立仓**：远端 `git@ssh.alotbuy.com:admin/workbuddy_skills.git`，分支 `master`（⛔ **无 upstream 配置** ⇒ 必须 `git push origin master` 显式推，且 `git status -sb` **不显示 ahead**，别拿它判断同步与否），提交者身份是**全局** `maogeigei `（与工作区仓的局部 `WorkBuddy` 不同，属正常，⛔ 别"统一"）。⚠️ **该仓被多会话并发写、推进以分钟计**：2026-10-08 我推 `44d42b0` 后数分钟内，另一会话又推了 5 个提交（撤销「项目会话」更名 ＋ 141 处说人话替换 ／ 机制对外改叫「项目机制」 ／ **把 9 个此前未纳管的技能目录入库 `e03465c`** ／ 修 draw-ui·oil-motion 的子模块指针），HEAD 已到 `237a09a`。⇒ **本仓任何结论都带时效，用前先 `git log -1` 校准**；那 9 个目录（AI HOT／draw-ui／dsh-* ×6／oil-motion／skills-security-check）**已入库，不再是"未纳管"**。 - 🔴 **并发覆盖实录与 B 方案补落（2026-10-08）**：我第八轮在 `stage-delivery/SKILL.md` 供给块的三处（能力边界 ／ 九档 ／ 证据缺口）被另一会话那轮重写覆盖（供给块整体换成另一种表结构），§5.5.2 标题也被换回旧写法，还留下一段**重复的「实证」**。用户选 B 方案后由其转告「另一会话已完成」，**核实现场不符**（HEAD 与 mtime 都没动、远端无新提交）⇒ 本会话于 22:4x 补落（提交 `46bee95`）：四处锚点全部回填 ＋ 清掉重复实证行。⛔ 判"改动是否还在"一律 `git show HEAD:<文件> | grep`，⛔ 别看 `--stat` 行数。⚠️ 教训：同批改动里我自己顺手列了那 8 个骨架名，撞上「名单只许在 layouts-tooling 开头写一次」的复述禁令 ⇒ **写"不复述"时别把名单抄进来**。 -- 🔴🔴 **全局技能包当前版本不是最新调整版（2026-10-08 22:5x 查明，用户追问后坐实）**：`1d7d31a` 提交信息写「说人话新稿按**合并**落地」，实际是**整文件覆盖** product-planning 下 7 个文件 —— 新稿编写时点**早于**被覆盖文件的修改时点，不做三方合并 ⇒ 必丢中间调整。**硬指标：「单一可信源」类声明 5 处 → 1 处**（丢的是 `stage-delivery/SKILL.md` 的 **`## 供给（唯一权威处 · 改供给只改这一块）` 整节标题 ＋ 六行供给表**、`layouts-tooling.md` 开头的名单权威声明、`stage-requirements/SKILL.md` 的②—③交接口声明）。**🔴 供给口径被翻转**：用户定案是「默认主线 ＝ `oil-ui-pro`，`open-design` 只是可选的随段携带件」，当前文件却写「`open-design` ＝ 本段默认主线」。⇒ **凡在本包上干活，先确认基线是不是最新调整版**（拿 `git diff --stat <上次收口提交> HEAD` 与「唯一权威处」计数比）；**闸门 12 条 FAIL 的真根因就是这几处权威声明被删，修序必须是「先恢复权威声明、再清复述」**。 +- 🔴🔴 **全局技能包当前版本不是最新调整版（2026-10-08 22:5x 查明，用户追问后坐实）**：`1d7d31a` 提交信息写「说人话新稿按**合并**落地」，实际是**整文件覆盖** product-planning 下 7 个文件 —— 新稿编写时点**早于**被覆盖文件的修改时点，不做三方合并 ⇒ 必丢中间调整。**硬指标：「单一可信源」类声明 5 处 → 1 处**（丢的是 `stage-delivery/SKILL.md` 的 **`## 供给（唯一权威处 · 改供给只改这一块）` 整节标题 ＋ 六行供给表**、`layouts-tooling.md` 开头的名单权威声明、`stage-requirements/SKILL.md` 的②—③交接口声明）。**🔴 供给口径被翻转**：用户定案是「默认主线 ＝ `oil-ui-pro`，`open-design` 只是可选的随段携带件」，当前文件却写「`open-design` ＝ 本段默认主线」。⇒ **凡在本包上干活，先确认基线是不是最新调整版**（拿 `git diff --stat <上次收口提交> HEAD` 与「唯一权威处」计数比）；**闸门 12 条 FAIL 的真根因就是这几处权威声明被删，修序必须是「先恢复权威声明、再清复述」**。✅ **2026-10-08 23:0x 已整包回退到 `44d42b0`（技能仓提交 `8fc9a92`），闸门回 `2060 ｜ 0 ｜ 27`，「唯一权威处」2 文件 ／ `## 供给` 块与六行表 ／ runbook 两条勾选项 ／ 3c 四处一致均已回来**；那批「说人话」改写另存于工作区 `归档/技能包-说人话改写-被覆盖存档-20261008/`（对照 diff ＋ 全文 ＋ 用法说明），将来只取措辞、⛔ 不取结构改动。 - 🔴 **闸门 12 条 FAIL 的归因（已坐实）**：由提交 `1d7d31a`（10-08 22:22，作者 maogeigei）**一步引入** —— 验证法（可复现）：`git archive <版本> product-planning` 抽出来各跑一次闸门，`44d42b0` ⇒ **全过**、`1d7d31a` ⇒ **失败 12**；且 `git diff --stat 44d42b0..HEAD -- product-planning/scripts/check_naming.py` **为空**（判据零改动，排除"判据变严翻旧账"）。该提交改了 product-planning 下 **7 个文件**，性质像**回退**：把「②—③ 交接口（**唯一权威处** · 改边界只改这一块）」的权威声明整段删掉、删掉「为什么立这一块」的立法理由段 ⇒ **权威处声明一弱化，复述就重新长回来**。⛔ 修法顺序：**先恢复权威处声明，再清复述**，反了会反复。⛔ 别默认是"自己上次的债"。 - 🔴 **本工作区现名 `contentm_agent`**（2026-10-08 定，旧名 `content_marketing_agent`，再早是 `agent-product`）。机制登记**已全部改成现名**：`collabd.config.json` 的 `workspace` ＋ `collabctl.py` 的 `WORKSPACES`/`KEEPALIVE_TASKS`（**源 ＋ 3 个区副本共 4 份，改一处要改 4 份**）＋ ai1net 的 `peer_workspaces`。旧空壳目录改名 `content_marketing_agent.RETIRED-20261008` 保留（零删除）。⚠️ ai1net 改了 peer ⇒ **看板要重启**才生效（配置模块级只读一次）。 diff --git a/归档/技能包-说人话改写-被覆盖存档-20261008/README.md b/归档/技能包-说人话改写-被覆盖存档-20261008/README.md new file mode 100644 index 0000000..b8091eb --- /dev/null +++ b/归档/技能包-说人话改写-被覆盖存档-20261008/README.md @@ -0,0 +1,55 @@ +# 「说人话」改写存档 · 被 `1d7d31a` 覆盖掉的那一批（2026-10-08） + +## 这是什么 + +`product-planning` 技能包在 2026-10-08 22:22 被提交 `1d7d31a`（作者 `maogeigei`）**整文件覆盖**过一轮，理由是「说人话新稿按合并落地（141 处措辞替换）」。核查后发现它并不是"合并"，而是**用一份基于较早版本写成的新稿覆盖了整包** —— 那一批「说人话」措辞改写本身有价值（2026-10-07 用户定案：一切落盘文字都要过说人话），所以在此存档，供将来重新叠加时取用。 + +整包已回退到 `44d42b0`（2026-10-08 第八轮收口版，闸门 `2060 ｜ 0 ｜ 27` 全过）。 + +## 文件 + +1、`改动对照.diff` —— `44d42b0` → `1d7d31a` 的全量 diff（2445 行）。要叠加说人话时对着它逐块看。 + +2、`说人话版全文/` —— `1d7d31a` 版的 7 个文件全文，照原目录结构放： + +- `SKILL.md` +- `references/stage-delivery/SKILL.md` +- `references/stage-delivery/references/execution-runbook.md` +- `references/stage-delivery/references/layouts-tooling.md` +- `references/stage-discovery/SKILL.md` +- `references/stage-requirements/SKILL.md` +- `references/stage-requirements/references/create-prd.md` + +## 怎么用（关键：只取措辞，不取结构） + +在 `44d42b0` 基线上逐块比对，**只采纳措辞层面的改写**。下面这些**⛔ 一律不要采纳**，它们不是措辞问题，是那次覆盖造成的结构损坏： + +1、**四处「单一可信源」声明**被删（`44d42b0` 有 5 处，覆盖后只剩 1 处）—— 其中 `stage-delivery/SKILL.md` 的 `## 供给（唯一权威处 · 改供给只改这一块）` **整节标题连同六行供给表一起被换成了另一种三列表**。这是用户 2026-10-08 定的口径，必须保留原样。 + +2、**供给口径被翻转** —— 用户定案是「默认主线 ＝ `oil-ui-pro`（基础层），`open-design` 只是随段携带的**可选件**、选了才用」；覆盖版写的是「`open-design` ＝ 本段默认主线」。⛔ 不要采纳。 + +3、**`execution-runbook.md` §7 完成标准丢了两条勾选项** —— 「供给能力边界已核对」（含反 AI 味 / 无障碍 / 动效纪律 / 表单校验四项记为证据缺口）与「页型已判…每条都要附取值记录」（含"给不出取值的条目改写为本条无机检"）。 + +4、**`3c` 子步改名** —— 覆盖版把「3c GPT 参考版」改成「3c GPT 会诊」（总入口四段表、`stage-delivery` 详情、`runbook` 三处），但没同步 `scripts/check_naming.py` 的 `STAGES` 表，直接让闸门报 FAIL。回退版三处一致，是自洽的。 + +5、**复述与旧路径** —— 覆盖版让 9 条「复述」类 FAIL 与 2 条废路径（`strategy/`、`ux/`）重新长回来，因为权威声明一被削弱，复述就不再被视为违规。回退版没有这些问题。 + +## 一个可复现的判据 + +``` +cd E:/ProgramData/.workbuddy/skills +for c in 44d42b0 1d7d31a; do + rm -rf /tmp/pp-$c && mkdir -p /tmp/pp-$c + git archive $c product-planning | tar -x -C /tmp/pp-$c + printf "=== %s ===\n" "$c" + (cd /tmp/pp-$c/product-planning && \ + E:/ProgramData/.workbuddy/binaries/python/versions/3.13.12/python.exe \ + scripts/check_naming.py --root . --ws "E:/ProgramData/AIProject/contentm_agent" 2>&1 | tail -2) +done +``` + +`44d42b0` ⇒ 全过；`1d7d31a` ⇒ `失败 12`。判据脚本 `check_naming.py` 在该区间**零改动**，所以差异只能来自内容。 + +## 教训 + +「新稿落地」时不做三方合并、直接整文件覆盖，**必然丢掉晚于新稿编写时点的改动**。这类操作前应先比对新稿的编写时点与被覆盖文件的最新修改时点；反过来，收到覆盖性提交后，第一件事是拿「唯一权威处」这类结构标记计数做体检（`git grep -c "唯一权威处" -- product-planning`），而不是只看闸门绿不绿。 diff --git a/归档/技能包-说人话改写-被覆盖存档-20261008/改动对照.diff b/归档/技能包-说人话改写-被覆盖存档-20261008/改动对照.diff new file mode 100644 index 0000000..203f880 --- /dev/null +++ b/归档/技能包-说人话改写-被覆盖存档-20261008/改动对照.diff @@ -0,0 +1,2445 @@ +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` 的 `