说人话落地：加每轮注入 ＋ 英文硬核版整包纳入 ＋ 第①段补写作口径

一、用户令（逐字）
「humanizer（英文那份） 也要纳入」「重点就是做到说人话就行了」「但是 content_marketing_agent 的会话生成的文档并没有说人话，还是我手动要求的」

二、根因（两处，都不是"没整合"）
· **语气那一档只有指针、没有注入** ⇒ 实测没被读到（`SKILL.md` 必读表标题原写「三篇」而表里有 4 行，
  第 4 项＝作业规矩整包，被顶在"必读"之外；已订正为「四类」）。
· **写文档的执行会话那条链上一句写作口径都没有** —— 产品规划技能里「反 AI 味」只出现在**第③段界面**
  （且指的是界面不是文字），**第①段出文档那节零口径** ⇒ 产物自然是 AI 味。

三、改法
1. **每轮注入**（照排版那条现成机制，⛔ 不改 `main()`）：
   · `04-去AI味与说话方式.md` 顶部加 `<!-- VOICE-CORE -->` 紧凑块（≈450 字符：核心原则/四种高频 AI 味/交付前三问）；
   · `reply-style-guard.py` 里**原地重定义** `_core`（`_core_reply = _core` 后用新 `_core` 包住它并追加语气块）
     ⇒ 注入正文自动多一段，排版那条**不受影响**。
2. **产出侧补口径**：`product-planning` 第①段（stage-discovery）在 1b 表后新增「写作口径」块 ——
   落笔前读 `humanizer-zh` 或本包 04，**定稿前过「交付前快速清单」**，并列出六种禁用 AI 味；**适用本段全部五份产出**。
3. **英文硬核版整包纳入**：原独立技能 `humanizer` **逐字**搬入本包 `references/humanizer-en/`（6 文件、
   md5 逐个一致）：55 个模式 ＋ 5 种语气档 ＋ 0–100 AI 痕迹打分 ＋ `--file` 就地改；
   在 `04 §9` 关系表与 `SKILL.md` 对应物段登记（冲突以本包会话场景版为先）。

四、验收
· 新增 `selftest.py::t_voice_core`（4 项）；全量 **PASS 106 / FAIL 0**；manifest 70 → **76** 份、语法失败 0。
· 端到端喂真钩子：注入正文已含说人话块、排版块仍在。
· ⛔ 改的是钩子与技能目录（宿主直读）⇒ **不需要分发/重启**。

product-planning/references/_留痕/SKILL-总入口-20261007改说人话前.md

@@ -0,0 +1,260 @@
+---
+name: product-planning
+description: 产品规划总入口（唯一入口），四段式调度：① 产品需求 ② 产品功能 ③ 界面交互 ④ 原型说明文档。四段以 references/stage-* 承载，本文件是总调度与约束。可整段跑也可只调一段。当用户要做产品规划、从零做新产品、只做某一阶段、或不知道从哪开始时调用。
+---
+
+# 产品规划总入口（Product Planning）
+
+> **Trae 用法**：本 skill 由模型按需自动加载，没有斜杠命令。若对话中尚未明确对象，先按下面「项目与路径约定」定出 `<项目>`，**定不出来就停下问用户，不要自行假设**。
+
+## 用途
+
+用户只有一句模糊想法（例："我要做一个 AI 短剧分镜画布"）时，本 skill 负责判断阶段、只做该段最小必要工作、产出可交付物、并推进到下一段。
+
+**本 skill 只做调度与约束，不重复任何被调 skill 的内容。下游 skill 都是外部成熟工具，不要自己重写一遍。**
+
+## 四段结构（可整段跑，也可只调一段）
+
+| 段 | 回答的问题 | 子步 | 调用 | 产出物 |
+|---|---|---|---|---|
+| **① 产品需求** | 要做的东西**凭什么成立**：什么问题、为谁、为什么值得做 | 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 条）
+
+## 建议下一步
+→ 用 <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` 写到仓库根**：多项目会互相覆盖
+- **段间停下来问"要不要继续"**：全流程（自动处理）模式下直接进下一段，只在段末输出报告
+
+## 改名 / 改供给后的自检（⛔ 不许跳过）
+
+```bash
+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 的主流程却不声明、不记偏离单（应为：开工先声明、每个子步再声明、偏离当场声明）

product-planning/references/stage-discovery/SKILL.md

@@ -11,19 +11,20 @@ description: 产品规划第①段，产品需求。五个子步依次产出五
 
 ## ⭐⭐ 产出白名单（2026-10-06 用户定案 · 硬规矩）
 
-**本段只产出这五份，一份不多、一份不少**：
+**本段在 `research/` 顶层只产出这五份，一份不多、一份不少**：
 
 | 子步 | 产出 |
 |---|---|
 | **1a** 需求文档 | `research/1a-需求文档.md` |
-| **1b** 竞品分析 | `research/1b-竞品分析.md` |
+| **1b** 竞品分析 | `research/1b-竞品分析.md`（汇总对比体，恒一份）＋ `research/1b-独立分析/<竞品名>.md`（独立分析体，竞品池里每一个一份） |
 | **1c** 用户画像 | `research/1c-用户画像.md` |
 | **1d** 产品策略 | `research/1d-产品策略.md` |
 | **1e** 使用场景 | `research/1e-使用场景.md` |
 
 🔴 **用户原话**：「**禁止出现之前确定的以外的文档，除非用户明确要求**」。
-⛔ **不许自行新增第 6 份** —— 实测栽过：某轮因为"用户点名了参考产品"就自作主张多产了一份《参考实装拆解》，导致用户反复看到"冒出来的不相关的文档"。**"参考产品怎么做的"属 1b 竞品分析的取材范围，写进 `1b-竞品分析.md` 里，⛔ 不另立一份。**
-✅ **门禁可查**：`check_naming.py` 扫本段目录，出现白名单外的文件名即报红。
+⛔ **不许自行新增第 6 份** —— 实测栽过：某轮因为"用户点名了参考产品"就自作主张多产了一份《参考实装拆解》，导致用户反复看到"冒出来的不相关的文档"。**"参考产品怎么做的"属 1b 竞品分析的取材范围，写进本份里，⛔ 不另立一份。**
+⭐ **`1b-独立分析/` 子目录不算"第 6 份"**：它是 1b 的**既定体例之一**（2026-10-07 用户定案：「**竞品分析 有独立分析也有汇总分析 都应该要用上，谁说只有一份竞品分析了**」）。它的份数由**竞品池**决定，⛔ 不由人临时加。除此之外仍然只许上面那五份。
+✅ **门禁可查**：`check_naming.py` 扫 `research/` **顶层**的实际文件名，出现白名单外的文件名即报红（子目录天然放行）。
 
 ## 本段职责（2026-10-06 重划）
 
@@ -32,7 +33,7 @@ description: 产品规划第①段，产品需求。五个子步依次产出五
 | 问 | 子步 | 产出 | 性质 |
 |---|---|---|---|
 | **要解决什么问题、边界在哪** | 1a 需求文档 | `1a-需求文档.md` | 拍板 |
-| **别人做了什么、我们差在哪** | 1b 竞品分析 | `1b-竞品分析.md` | **外部取证** |
+| **别人做了什么、我们差在哪** | 1b 竞品分析 | `1b-竞品分析.md` ＋ `1b-独立分析/` | **外部取证** |
 | **用户是谁、他要办成什么事** | 1c 用户画像 | `1c-用户画像.md` | **外部取证** |
 | **为什么值得做、边界与风险** | 1d 产品策略 | `1d-产品策略.md` | 判断 |
 | **用户怎么用它** | 1e 使用场景 | `1e-使用场景.md` | 判断 |
@@ -72,35 +73,66 @@ description: 产品规划第①段，产品需求。五个子步依次产出五
 
 | 子步 | 读 | 产出 |
 |---|---|---|
-| 竞品拆解 | `references/competitor-analysis.md` | `docs/pm/<项目>/research/1b-竞品分析.md` |
+| 竞品拆解 · 独立分析 | `references/competitor-analysis.md` §11 | `docs/pm/<项目>/research/1b-独立分析/<竞品名>.md`（**竞品池里每一个一份**） |
+| 竞品拆解 · 汇总对比 | `references/competitor-analysis.md` §1—§10 | `docs/pm/<项目>/research/1b-竞品分析.md`（**恒一份**） |
 
-⭐ **用户点名的"参考实装"写进本份，⛔ 不另立文档**（见「产出白名单」）。它和通用竞品是同一件事的两层：**通用竞品**看这一类产品都怎么做，**点名参考**拆用户指定的那一个。两者并成一份的 §一 / §二。
+1b 交两种体例（2026-10-07 用户定案：「**竞品分析 有独立分析也有汇总分析 都应该要用上，谁说只有一份竞品分析了**」）。职责边界与数量见 `references/competitor-analysis.md` §0.4；只交一种 ⇒ **1b 没做完**。
+
+> 🔴 **写作口径（2026-10-07 补 · 用户报障逐字：「生成的文档并没有说人话，还是我手动要求的」）**
+> 本段产出是**给人看的文档**，⛔ 不是模型味的总结。落笔前读一遍其中一份：
+> 技能库 `humanizer-zh`（中文版，24 类 AI 写作模式）**或**会话技能包里的
+> `session-mechanism/references/作业规矩/04-去AI味与说话方式.md`（会话场景加固版，带交付前清单与质量评分）；
+> **定稿前按它的「交付前快速清单」过一遍**。
+> ⛔ 高频 AI 味一律禁：三段式排比连用、空转评价（「具有重要意义」「值得关注」）、
+> 以「…着」结尾的肤浅分析、模糊归因（「业内人士认为」）、过度加粗、把一句话拆成内联标题垂直列表。
+> ⚠️ 这条口径**适用于本段全部五份产出**（1a～1e），⛔ 不只 1b。
+
+⭐ **用户点名的"参考实装"写进本份，不另立文档**（见「产出白名单」）。它是**竞品池的第三层**（直接竞品 / 间接替代 / 点名参考），在 §3—§10 的每一节里与其它竞品**同列参与横向对比**。
 
 🔴 **目标**：从**产品视角**横向拆解竞品 —— 讲**用途**、讲**场景**、讲**功能**、讲**作用**、讲**优势**（2026-10-07 用户口径）。
 
+🔴 **核心模型 = 五问**（用途 → 场景 → 功能 → 作用 → 优势），本份每一节都在回答其中一问或几问。
+
 **执行**：
 1. 读 `references/competitor-analysis.md`（**唯一**方法论载体，含 §0 Scope 与文末《输出检查》）
 2. 按项目目标圈定竞品范围（直接竞品 ＋ 至少 1 个替代/间接方案 ＋ 点名的参考实装）
-3. 按 **用途 → 场景 → 功能 → 作用 → 优势** 横向比（⛔ 不按竞品逐个写）
-4. 输出优势与不足、可借鉴点与产品机会
-5. 交付前走一遍该方法论文末《输出检查》：任一条为「否」⇒ **退回修改，⛔ 不交付**
+3. **先出独立分析体**：竞品池里每一个一份，按 §11 的七节写（哪些节能答、哪些答不了，由 §11 的「取证范围 ↔ 可答节次」定）
+4. **再出汇总对比体**：按 **用途 → 场景 → 功能 → 作用 → 优势** 横向比（按用户处境横向铺开，不按竞品逐个写）
+5. 输出优势与不足、可借鉴点与产品机会
+6. 交付前走一遍该方法论文末《输出检查》：任一条为「否」⇒ **退回修改，不交付**
 
-🔴 **最低输出结构**（最低要求，⛔ 不是固定模板 —— 不同品类维度不同，可增不可缺）：
+🔴 **最低输出结构**（最低要求，按品类可增不可缺）：
+
+**甲 · 汇总对比体**（`research/1b-竞品分析.md`，恒一份）：
 
 | # | 节 | 回答什么 |
 |---|---|---|
-| 1 | 分析目标与范围 | 这次要回答什么 |
-| 2 | 竞品选择与范围 | 选了谁、为什么是它 |
+| 1 | 分析目标与范围 | 这次要回答什么；五问各落在哪节 |
+| 2 | 竞品选择与范围 | 选了谁、属哪一层、为什么是它 |
 | 3 | 竞品用途 | 是什么 / 给谁用 / 干什么用 |
-| 4 | 使用场景横向对比 | 用户在各处境下怎么把事办成 |
-| 5 | 功能横向对比 | 功能 → 解决什么问题 → 起什么作用 |
-| 6 | 产品机制与交互方式 | 为什么这样设计 |
-| 7 | 优势与不足 | 能力 → 场景 → 用户价值 |
+| 4 | 使用场景横向对比 | 用户什么时候、为什么用；怎么把事办成 |
+| 5 | 功能横向对比 | 有什么能力 / 解决什么问题 / 起什么作用 |
+| 6 | 产品机制与交互方式 | 怎么解决 / 为什么这样设计 ⇒ 给用户什么结果 |
+| 7 | 优势与不足 | 能力表现 × 场景 × **对比对象** × 用户价值 |
 | 8 | 竞品能力矩阵 | 共识 / 差异 / 独有 / 普遍短板 / 未解决需求 |
 | 9 | 可借鉴点与产品机会 | 该借鉴 / 该避开 / 可突破 |
 | 10 | 结论（产品层） | 本产品应优先解决什么 |
 
-⭐ **①段就是上表这 5 个子步**，每个子步一个方法论载体、一份产出 —— 这套结构**直接服务单机自用的产品**（用户本人就是唯一使用者）。
+**乙 · 独立分析体**（`research/1b-独立分析/<竞品名>.md`，每个竞品一份；结构细则与判据见方法论 §11）：
+
+| # | 节 | 回答什么 |
+|---|---|---|
+| 1 | 它是谁、属哪一层、为什么纳入 | 竞品名 / 所属层级 / 纳入理由 |
+| 2 | 用途 | 是什么 / 给谁用 / 干什么用 |
+| 3 | 场景 | 用户在什么处境下用它；把事办成的实际过程（取不到就显式标缺口） |
+| 4 | 能力 | 有哪些功能 / 各解决什么问题 / 起什么作用 |
+| 5 | 机制 | 怎么做到的；为什么这样设计 ⇒ 给用户什么结果 |
+| 6 | 强在哪、弱在哪 | 能力表现 × 场景 × 对比对象 × 用户价值 |
+| 7 | 对我们 | 该借鉴 / 该避开 / 可突破 |
+
+其中**第 2 / 3 / 6 节是必答项，写法固定**（每组几行、每行叫什么、什么顺序都定死，取不到就照写「取不到」）；第 1 / 4 / 5 / 7 节写法自由。**行名与行数见方法论 §11，本表不复述。**
+
+⭐ **①段就是上表这 5 个子步**，每个子步一个方法论载体 —— 产出份数上，**1b 是唯一一个交两种体例的子步（独立体多份 ＋ 汇总体一份）**，其余四个子步各一份。这套结构**直接服务单机自用的产品**（用户本人就是唯一使用者）。
 （历史：本段曾有过另外几个子步、以及一次子步合并，为什么收成 5 个 → `_留痕/①段-已删除产出与方法论.md`）
 
 ## 1c 用户画像（外部取证）
@@ -177,8 +209,10 @@ description: 产品规划第①段，产品需求。五个子步依次产出五
 - `1a-需求文档.md` 存在（含"做什么 / 为谁 / 不做什么"＋决策表），每项都标了来源（用户拍板 / `【假设】` / `【事实】`）
 - 顶部状态行给出「已确认 N / 模型补全 M（未经确认）」两个数；**每条 `【假设】` 都能在三种归宿里找到自己**（已确认 / 待实现已排时机 / 已按假设落地）
 - 1b 竞品分析 + 1c 用户画像 + 1d 产品策略 + 1e 使用场景 **四份齐全**
-- ⭐ **目录里不出现白名单外的任何文件**（第 6 份须有用户明确要求）
+- ⭐ **1b 两种体例都交了**（2026-10-07 新增）：`research/1b-竞品分析.md`（汇总对比体）**且** `research/1b-独立分析/` 下竞品池每一个一份（独立分析体）—— 只交一种 ⇒ **1b 没做完**
+- ⭐ **目录里不出现白名单外的任何文件**（第 6 份须有用户明确要求；`1b-独立分析/` 子目录是 1b 既定体例，不算第 6 份）
 - 1d/1e 每条结论都标了来源（哪份取证文件或本表哪一行，或 `【假设】`）
+- ⭐ **五份都过了「说人话」内容准则**（源技能 `humanizer` / `humanizer-zh`，门槛 ≥45/50）—— 口径见 `product-planning` 的「执行规则」内容准则条；段末报告须写明"已过内容准则，评分 X/50"
 
 ## 反面清单
 
@@ -189,11 +223,14 @@ description: 产品规划第①段，产品需求。五个子步依次产出五
 - ⛔ **只做 A 节、跳过 B 节**（2026-10-06 新增）：B 节即原②段的功能压测，跳过它等于把压测整个删掉，接口会带着没压测过的需求直接进②段与原型
 - ⛔ **在 B 节把页面结构写死**（2026-10-06 新增）：B 节只给粗粒度形态（有哪几页、大概几个板块）；精确板块清单与布局图归②段的《界面布局》
 - ⛔ **产出白名单外的第 6 份文档**（2026-10-06 新增）：⛔ 不许因为"用户点名了某个参考产品/某份素材"就另立文档 —— 写进 `1b-竞品分析.md` 里
+- ⛔ **1b 只交汇总对比体、把独立分析省掉**（2026-10-07 新增）：用户定案「竞品分析有独立分析也有汇总分析 都应该要用上」。⛔ 也不许把独立体写成仓库取证记录 —— 它必须按方法论 §11 的七节答产品面（用途 / 场景 / 能力 / 机制 / 强弱 / 对我们）
+- ⛔ **改本技能包的规则文件、却不过「说人话」这一关**（2026-10-07 新增）：规则和产出同一把尺子，⛔ 不许只给产出上锁、自己用另一套腔调写规则 —— 口径见 `product-planning` 的「执行规则」内容准则条
 - 没有取证就直接写策略
 - 把 11 个子步全跑一遍充数
 - 事实与假设混在一起不标注
 - **拿"frontier 为空 / 无遗留未决项"当闭合声明，而正文里还挂着未经确认的假设** —— 只读首屏的人会误读成需求已澄清
 - ⛔ **凭空给 Importance / Satisfaction 打分** —— 没有任何数据源支撑的数字，⛔ 不许出现在交付物里
+- ⛔ **五份没过「说人话」内容准则就落盘**（带 AI 腔：夸张意义 / 三段式强凑 / 破折号滥用 / 模糊归因 / 通用乐观结尾）—— 门槛 ≥45/50，见 `product-planning` 的「执行规则」内容准则条
 
 ## 反面清单（续）
 

product-planning/references/stage-discovery/references/competitor-analysis.md

@@ -24,21 +24,40 @@
 
 答不出这句话 ⇒ **1b 没做完**。
 
+### 0.4 两种交付体例（本档的排布）
+
+1b 交付两份体例，两份都要交（2026-10-07 用户定案：「**竞品分析有独立分析也有汇总分析，都应该要用上**」）：
+
+1. **独立分析体** —— 一个竞品一份，回答「**这一个**产品是什么、给谁用、怎么把事情办成、强在哪弱在哪、对我们有什么可拿的」。结构见 §11。
+2. **汇总对比体** —— 全池一份，回答「**放在一起比**：共识是什么、差异在哪、哪里没人做好」。结构见 §1—§10。
+
+**职责边界（本档定死，避免两边各写一遍、出现两套判据）**：
+
+- 单个竞品的形态 / 给谁用 / 干什么用、场景里用户把事办成的过程、它自己的能力与机制 → **归独立体（§11）**。
+- 跨竞品的横向铺开（同一场景谁怎么做）、能力矩阵、共识与空白、本产品优先解决什么 → **归汇总体（§1—§10）**。
+- 两边都要写的只有一样：**可借鉴 / 该避开 / 可突破** —— 独立体写「从这一个竞品拿什么」，汇总体写「三类分开汇总并追回 §4 / §5 / §7」。
+
+**数量**：独立体 = 竞品池里的每一个（用户点名要求合并的按用户口径合并，如「同源 fork 合成一份」）；汇总体 = 恒一份。
+
+**判据**：两种体例都交付了，才算 1b 完成。只交汇总体、或只交独立体 ⇒ **1b 没做完**。
+
 ---
 
 ## 1. 分析目标与范围
 
-**写什么**：把这次要回答的问题写死在文档开头，并让下列**五问**各有明确落点 ——
+**核心模型 = 五问**。本档后面每一节，都在回答五问里的一问或几问；§1 就是把它们摆明。
 
-| 五问 | 落在哪一节 |
-|---|---|
-| 用途：它是什么、给谁用、干什么用？ | §3 |
-| 场景：用户在什么处境下会用它？ | §4 |
-| 功能：它有哪些核心功能？ | §5 |
-| 作用：每个功能解决什么问题？ | §5 |
-| 优势：它在哪些场景下更强 / 更弱？ | §7 |
+| 五问 | 关注点 | 落在哪一节 |
+|---|---|---|
+| 用途：它是什么、给谁用、干什么用？ | What / Who | §3 |
+| 场景：用户在什么处境下会用它？ | When / Why | §4 |
+| 功能：它有哪些核心能力？ | What | §5 |
+| 作用：每项能力解决什么问题？ | What for | §5 |
+| 优势：它相对**谁**、在哪些场景下更强或更弱？ | vs Whom | §7 |
 
-**判据**：五问**各有一处明确落点**（⛔ 不是散落在正文里靠读者自己找）。
+**写什么**：把这次要回答的问题写死在文档开头（本次目标、本次竞品池、本次不展开的部分），并让五问各自落在上表那一节。
+
+**判据**：五问**各有一处明确落点**，读的人能在对应节里直接读到答案 —— 收口在 §8 矩阵与 §10 结论。
 
 ---
 
@@ -47,29 +66,30 @@
 **写什么**：竞品分三层，逐层交代为什么选它 ——
 
 1. **直接竞品**：解决同一个核心问题、目标用户高度重叠。
-2. **间接 / 替代方案**：同一需求的不同产品形态，或**用户不用这类产品**时的替代做法。
-3. **点名参考实装**：用户**点名指定**的那一个（技能层已定：与通用竞品并成《1b-竞品分析》的 §一 / §二两层，⛔ 不另立文档）。
+2. **间接 / 替代方案**：同一需求的不同产品形态，或**用户换一种做法**时的替代路径。
+3. **点名参考实装**：用户**点名指定**的那一个。
 
-**数量**：⛔ **不规定固定数量**。要求是「**直接竞品 ＋ 至少 1 个替代/间接方案**」，复杂项目自行加。
+**归属（本档定死，避免歧义）**：点名参考实装就是**竞品池的第三层**，写进同一份 `1b-竞品分析.md`，在 §3—§10 的每一节里**与其它竞品同列参与横向对比**，不单独成节、不另立文档。文档开头要写清「本次竞品池 = 哪几个 ＋ 各自属于哪一层」。
+
+**数量**：按项目目标自定。最低要求是「**直接竞品 ＋ 至少 1 个替代/间接方案**」；复杂项目自行加层加项。
 
 **判据**：
-- ⛔ **不许因为「名气大 / star 高 / 大家都在用」就把项目纳入竞品池** —— 纳入前必须能回答「**用户为什么会拿它和我们的产品做选择？**」
-- 点名参考实装**必须收录**，且与通用竞品**分开成两层**写。
+- 纳入池子的每一个，都能回答「**用户为什么会拿它和我们的产品做选择？**」（分水岭是**用户的选择**，不是名气大小）。
+- 点名参考实装已收录，且在池子里标明层级。
 
 ---
 
 ## 3. 竞品用途（是什么 / 给谁用 / 干什么用）
 
-**写什么**：每个竞品一小段，只答三件事 —— 它是什么形态的产品、服务谁、拿它干什么用。
+**关注点：What / Who。** 每个竞品一小段，只答三件事 —— 它是什么形态的产品、服务谁、拿它干什么用。
 
-**判据**：读完这段，**没接触过这个产品的人能说清它是干什么的**。
-⛔ 只答这三件事 —— 功能归 §5。
+**判据**：读完这段，**没接触过这个产品的人能说清它是干什么的**；三件事之外的内容归后面的节（能力归 §5、机制归 §6）。
 
 ---
 
 ## 4. 使用场景横向对比
 
-**写什么**：按**用户处境**横向铺开，⛔ **不按竞品逐个写** ——
+**关注点：When / Why —— 用户什么时候用、为什么要用。** 按**用户处境**横向铺开：
 
 ```
 场景          用户要办成什么      竞品A 怎么做    竞品B 怎么做    竞品C 怎么做
@@ -77,45 +97,53 @@
 场景 2        …
 ```
 
-重点⛔ 不是「有 / 没有这个功能」，而是「**用户在这个场景下，它具体怎么让用户把事办成**」：
-进入方式 → 操作路径 → 核心步骤 → 系统提供什么帮助 → 最终产出 → 哪一步最省力 → 哪一步最麻烦。
+写在 §4 的是「**什么时候、为什么用**」：用户处于什么处境、要办成什么事、为什么这件事必须做。
 
-**判据**：能描述出**用户实际使用的过程**。⛔ 只列功能名 = 未达标。
+展开时沿着用户的**实际动作链**走：进入方式 → 操作路径 → 核心步骤 → 系统提供什么帮助 → 最终产出 → 哪一步最省力 → 哪一步最麻烦。这一段要把**用户实际把事办成的过程**写出来，功能名与按钮细节归 §5 / §6。
+
+**判据**：能描述出**用户实际使用的过程**（谁、什么处境、办成了什么），并且能说清「**为什么在这个处境下会用它**」。
 
 ---
 
-## 5. 功能横向对比（功能 → 解决什么问题 → 起什么作用）
+## 5. 功能横向对比
 
-**写什么**：先建**一组统一维度**，再横向比。维度**按产品调整**，可用：核心功能 / 辅助功能 / 输入方式 / 处理方式 / 输出方式 / 编辑能力 / 管理能力 / 协作能力 / AI 能力 / 自动化能力。
+**关注点：What —— 有什么能力、能解决什么问题。** 先建**一组统一维度**，再横向比。维度**按产品调整**，可用：核心功能 / 辅助功能 / 输入方式 / 处理方式 / 输出方式 / 编辑能力 / 管理能力 / 协作能力 / AI 能力 / 自动化能力。
 
 **每个功能必须答三问**（本档硬要求）：
 
 > **是什么** → **解决什么问题** → **对用户起什么作用**
 
-**判据**：
-- ⛔ 「A 有 X，B 有 Y」这种罗列 = 未达标。
-- ⛔ **不给固定字段表** —— 不同品类维度本就不同，钉死字段会让方法论失效。
+维度按品类自定、可增不可缺 —— 每个维度都要出现「解决什么问题 / 起什么作用」这一层。
+
+**判据**：读的人能说清**每项能力是为什么问题而存在的**；只摆能力名、不接「解决什么问题」的写法不达标。
 
 ---
 
 ## 6. 产品机制与交互方式
 
-**写什么**：比「**为什么这么做**」。比较：核心任务流程 / 信息组织方式 / 导航结构 / 核心交互 / 默认行为 / 自动化机制 / AI 与用户的分工 / 关键反馈 / 异常处理 / 用户控制权。
+**关注点：How / Why —— 怎么解决、为什么这样设计。** 比较：核心任务流程 / 信息组织方式 / 导航结构 / 核心交互 / 默认行为 / 自动化机制 / AI 与用户的分工 / 关键反馈 / 异常处理 / 用户控制权。
 
-**判据**：写的是「**它为什么这样设计、这样设计给用户带来什么结果**」；⛔ 不是「界面长什么样」。
+写的是「**它为什么这样设计、这样设计给用户带来什么结果**」；界面外观描述归 §5 的能力层。
+
+**判据**：每条机制都能接出「**为什么这样设计 ⇒ 给用户带来什么结果**」，与 §4 的场景、§5 的能力形成因果链。
 
 ---
 
 ## 7. 优势与不足
 
-**写什么**：每个判断都落到 **能力 → 场景 → 用户价值**。
+**关注点：vs Whom —— 相对谁更强、相对谁更弱。**
+
+判断公式（本档硬要求）：
+
+> **优势 / 不足 ＝ 能力表现 × 使用场景 × 对比对象 × 用户价值**
 
 例：
 
-> 优势：批量处理能力强；场景：一次要处理大量内容时；作用：减少重复操作；结果：更快出稿。
+> 在「一次要处理大量内容」这个场景下，A 的批量处理能力**相对 B 少三步重复操作**，因此更适合高频批量生产。
 
-**判据**：任何「好 / 差 / 强 / 弱」都能说出**为什么**。
-⛔ 「体验很好」「设计很现代」这类**无据判断** = 未达标。
+四条要素都要落地：**能力表现**（强在哪）→ **使用场景**（在什么处境下）→ **对比对象**（比谁强/弱）→ **用户价值**（带来什么结果）。精确到「少几步」不是硬要求，但**比较基准必须写出来**。
+
+**判据**：任何「好 / 差 / 强 / 弱」都能说出**相对谁、在什么场景下、带来什么结果**。
 
 ---
 
@@ -128,7 +156,9 @@
 …               …         …         …         …
 ```
 
-**判据**：矩阵不是为了「显得专业」，而是要**看得出**五件事 —— 行业共识能力 / 竞品之间的差异能力 / 某家的独有能力 / 普遍做得不好的能力 / 还没被解决好的需求。
+**取值口径**：矩阵里的行**取有代表性、能区分竞品的能力与场景** —— 挑的是「看完这一张就能抓住差异」的那些行。
+
+**判据**：矩阵是为了**看得出**五件事 —— 行业共识能力 / 竞品之间的差异能力 / 某家的独有能力 / 普遍做得不好的能力 / 还没被解决好的需求。
 
 ---
 
@@ -142,7 +172,7 @@
 
 每条给：机会点 → 对应场景 → 用户问题 → 竞品现状 → 建议方向。
 
-**判据**：本节每一条都要能**追回 §4 / §5 / §7 的某一条**。⛔ 不许凭空提出机会。
+**判据**：本节每一条都要能**追回 §4 / §5 / §7 的某一条**。
 
 ---
 
@@ -150,26 +180,109 @@
 
 **写什么**（一律写成产品层的表述）：用户最核心的需求是什么 / 竞品共同解决了什么 / 竞品共同存在什么问题 / 哪些能力已经是基础能力 / 哪些能力还能形成差异 / 本产品应优先解决什么。
 
-**判据**：结论**只落在产品层**。
+**判据**：结论**只落在产品层**，并且能一句话接回 §0.3 的完成判据。
+
+---
+
+## 11. 独立分析体（每个竞品一份）
+
+**落点**：`docs/pm/<项目>/research/1b-独立分析/<竞品名>.md`。
+> 落点为什么选这个子目录：①段产出白名单闸门只扫 `research/` **顶层**的 `.md`（判据见 `scripts/check_naming.py` 的 `WHITELIST`），独立体放进子目录天然放行 —— 竞品再多也不会撞白名单，⛔ 不必为此扩白名单。
+> ⚠️ 存量项目里的 `证据附卷/` 是历史落点，**不强制迁移**；新项目按上面这条走。
+
+**七节齐全，一节不许缺。其中三节写法固定（必答项），另外四节写法自由。**
+
+> 口径（2026-10-07 用户定案，选「方案 A」）：**只把最容易漏的几组定死，不把整份写成填空题**。定太粗等于没定，定太细遇到形态不一样的竞品会别扭。
+
+**写法固定的三节** —— 每组几行、每行叫什么、什么顺序，都固定。取不到证据时**那一行照写，内容写「取不到：<原因>」**，⛔ 不许删行、也不许改写成一段话蒙过去。
+
+第 2 节「用途」固定四行：
+
+```
+- 形态：
+- 给谁用：
+- 干什么用：
+- 证据等级：
+```
+
+第 3 节「场景」固定六行，沿用户实际动作链：
+
+```
+- 进入方式：
+- 操作路径：
+- 核心步骤：
+- 系统帮了什么：
+- 最终产出：
+- 哪一步最省力 / 最麻烦：
+```
+
+（整节都取不到 ⇒ 六行全写「取不到：<原因>」，并把缺口列在节末。⛔ 不许拿功能名罗列冒充使用过程。）
+
+第 6 节「强在哪、弱在哪」每写一条强弱，就是固定四行；有几条就重复几组：
+
+```
+- 能力表现：
+- 在什么场景：
+- 相对谁：
+- 对用户什么结果：
+```
+
+**写法自由的四节**（结构自己定，判据照旧）：
+
+1. **它是谁、属哪一层、为什么纳入** —— 竞品名、形态、竞品池层级、纳入理由（分水岭是**用户的选择**，不是名气大小）。
+4. **能力：它有哪些功能，各解决什么问题、起什么作用** —— 每项能力答三问（**是什么 → 解决什么问题 → 对用户起什么作用**）；只摆能力名、不接「解决什么问题」的不达标。
+5. **机制：它怎么做到的，为什么这样设计 ⇒ 给用户什么结果** —— 每条机制都要接出「为什么这样设计 ⇒ 给用户带来什么结果」。
+7. **对我们：该借鉴 / 该避开 / 可突破** —— 每条给「机会点 → 对应场景 → 用户问题 → 它现在怎么做 → 建议方向」。
+
+**取证范围 ↔ 可答节次（⛔ 不许越级答）**：取证深度决定哪几节能真答，越级答就是编。
+
+- **只有官方自述与仓库元数据**（无源码、无界面）⇒ 第 4、5 节只能写「官方自述的能力」与「有据的推断」，并逐条标证据等级；**第 3 节的六行多半只能写「取不到」**，那就照实写并列出缺口。
+- **有源码** ⇒ 第 4、5 节可写实现级结论。
+- **有界面**（截图 / demo / 亲自跑过）⇒ 第 3 节才写得完整。
+
+**判据**：七节齐全；三组必答项的行都在，取不到的写「取不到」而不是留白；第 4 节每项能力都接了「解决什么问题 / 起什么作用」；第 6 节每条强弱都写了「相对谁」。
 
 ---
 
 ## 附：输出检查
 
-交付前逐条过。任一条为「否」⇒ **退回修改，⛔ 不交付**。
+交付前逐条过。任一条为「否」⇒ **退回修改，不交付**。
 
-- [ ] 五问（用途 / 场景 / 功能 / 作用 / 优势）各有明确落点
-- [ ] 点名参考实装已收录，且与通用竞品分成两层
-- [ ] 场景对比能描述出用户实际把事办成的过程
-- [ ] 每个功能都答了「解决什么问题 / 起什么作用」
-- [ ] 优势与不足都落到「能力 → 场景 → 用户价值」
-- [ ] 可借鉴点每一条都能追回场景 / 功能 / 优势的某一条
+**汇总对比体**（`research/1b-竞品分析.md`，§1—§10）：
+
+- [ ] §1 把本次目标与竞品池写死在开头，五问各有明确落点
+- [ ] 竞品池三层齐全，点名参考实装已收录并标明层级
+- [ ] §4 能说清「用户什么时候、为什么用」，并写出实际把事办成的过程
+- [ ] §5 每个维度都接了「解决什么问题 / 起什么作用」
+- [ ] §6 每条机制都接了「为什么这样设计 ⇒ 给用户什么结果」
+- [ ] §7 每条判断都写明了「相对谁、在什么场景、什么结果」
+- [ ] §8 矩阵取的是有代表性、能区分竞品的行，且看得出共识/差异/独有/短板/未解决需求
+- [ ] §9 每一条都能追回 §4 / §5 / §7
 - [ ] 全文只围绕用途 / 场景 / 功能 / 作用 / 优势展开
-- [ ] 结论只落在产品层
+- [ ] §10 结论只落在产品层，并可一句话回答 §0.3
+
+**独立分析体**（`research/1b-独立分析/<竞品名>.md`，§11）：
+
+- [ ] 第 1 节写了它属哪一层、为什么纳入（判据是用户的选择，不是名气）
+- [ ] 第 2 节的四行都在（形态 / 给谁用 / 干什么用 / 证据等级），没有留白
+- [ ] 第 3 节的六行动作链都在；取不到的写了「取不到」，⛔ 没有留白、也没有拿功能名罗列顶替
+- [ ] 第 4 节每项能力都接了「解决什么问题 / 起什么作用」
+- [ ] 第 5 节每条机制都接了「为什么这样设计 ⇒ 给用户什么结果」
+- [ ] 第 6 节的每组强弱都是四行（能力表现 / 在什么场景 / 相对谁 / 对用户什么结果）
+- [ ] 第 7 节三分类齐全（该借鉴 / 该避开 / 可突破）
+
+**两种体例齐备**：
+
+- [ ] 竞品池里每一个都有独立分析体（用户点名合并的按用户口径合并）
+- [ ] 汇总对比体存在，且没有把独立体的内容整段抄一遍（横向铺开才算汇总体）
 
 ---
 
 ## 变更历史
 
-- **2026-10-07**：全文重写为《竞品分析方法论（1b · 产品视角）》（用户口径：讲用途 / 场景 / 功能 / 作用 / 优势）。
-  新增 §0 Scope 与文末《输出检查》。改版前的英文版已退役留痕于 `_superseded-competitor-analysis-英文商业版.md`（⛔ 不再引用）。
+- **2026-10-07 第四版**：独立分析体定下「必答项」写法。用户 2026-10-07 在「只定必答项 / 七节全定死 / 只定最疼两处」三个候选里选了**方案 A**（只定必答项）。改动：§11 把第 2 节（用途）四行、第 3 节（场景）六行、第 6 节（强弱）每组四行定为固定写法，取不到照写「取不到」；第 1、4、5、7 节写法自由；《输出检查》同步改成按行核。
+
+- **2026-10-07 第三版**：补「两种交付体例」。起因：用户 2026-10-07 原话「**竞品分析 有独立分析也有汇总分析 都应该要用上，谁说只有一份竞品分析了**」—— 本档第二版只描述了汇总对比体（§1—§10），独立分析体一字未提，于是独立分析被写成仓库取证记录、没有产品面。本次改动：① 新增 §0.4「两种交付体例」定死职责边界与数量；② 新增 §11「独立分析体」给出七节结构与「取证范围 ↔ 可答节次」对应表；③ 《输出检查》拆成汇总对比体 / 独立分析体 / 两体例齐备三段。
+
+- **2026-10-07 第二版**：按评审意见收紧机制层。① §1 把「五问」明确定为**核心模型**并给出关注点列；② §4 / §5 / §6 明确职责边界（When·Why / What / How·Why）；③ §7 判断公式补上**对比对象**（相对谁）；④ §2 把「点名参考实装」的归属**定死在竞品池第三层**，消除与章节结构的歧义；⑤ §8 补矩阵取值口径；⑥ 全文改成正向表述。
+- **2026-10-07 第一版**：全文重写为《竞品分析方法论（1b · 产品视角）》（用户口径：讲用途 / 场景 / 功能 / 作用 / 优势）。新增 §0 Scope 与文末《输出检查》。改版前的英文版已退役留痕于 `_superseded-competitor-analysis-英文商业版.md`。

product-planning/references/stage-requirements/SKILL.md

@@ -148,6 +148,7 @@ description: 产品规划第②段，产品功能。只做一件事：把①段
 - ⛔ **全文零视觉词**（配色 / 字体 / 间距 / 组件样式 / 动效）
 - **每条假设都有归宿**（三选一，无第四种）；凡依据假设的功能 / 状态流转 / 分档，条目里都带上了假设状态标注
 - 本段所有「待确认 / 暂缓」条目都带齐 **复核人 / 复核时机 / 结论落点** 三字段
+- ⭐ **两份都过了「说人话」内容准则**（源技能 `humanizer` / `humanizer-zh`，门槛 ≥45/50）—— 口径见 `product-planning` 的「执行规则」内容准则条；段末报告须写明"已过内容准则，评分 X/50"
 
 ## 反面清单
 
@@ -167,6 +168,8 @@ description: 产品规划第②段，产品功能。只做一件事：把①段
 - 越界去出原型或写说明文档（那是第③④段）
 - **把 `【假设】` 原样带进②段当既定事实**；或假设已被实现却从不回填状态
 - **只写"暂缓"而不给复核人 / 复核时机 / 结论落点** —— 等于让这条永远挂着
+- ⛔ **两份没过「说人话」内容准则就落盘**（带 AI 腔：夸张意义 / 三段式强凑 / 破折号滥用 / 模糊归因 / 通用乐观结尾）—— 门槛 ≥45/50，见 `product-planning` 的「执行规则」内容准则条
+- ⛔ **改本技能包的规则文件、却不过「说人话」这一关**（2026-10-07 新增）：规则和产出同一把尺子 —— 口径见 `product-planning` 的「执行规则」内容准则条
 
 ## 本段读什么、守什么
 

product-planning/references/stage-requirements/references/create-prd.md

@@ -118,7 +118,7 @@
 
 ## 四、通用要求
 
-- **写给人看**：短句、少术语、能读给不熟悉项目的人听懂。
+- **写给人看**：短句、少术语，能读给不熟悉项目的人听懂。**落盘前必须过「说人话」内容准则**（源技能 `humanizer` / `humanizer-zh`，门槛 ≥45/50；五条核心原则与口径见 `product-planning` 的「执行规则」内容准则条）。
 - **每条都能追来源**：功能追①段场景，假设带状态标注，判据给一句话。
 - **⛔ 全文零视觉词**：配色 / 字体 / 间距 / 组件样式 / 动效，一个字都不许出现。
 - **保留修订记录**：改了实现必须回填条款正文，⛔ 不能只在修订记录里写。