补入本地今日改动：session-mechanism ＋ product-planning（按用户令改推本仓库）
背景：旧远端 work.alotbuy.com 今天一直连不上（222／22 端口都不通）⇒ 今天本地累积多条提交推不上去； 用户令改推本仓库 [email protected]:admin/workbuddy_skills.git（只推这 5 个技能： browser-harness / humanizer / humanizer-zh / product-planning / session-mechanism）。 本次改动（对照本机已安装的技能源逐文件 md5 比对得出，⛔ 是「补差异」不是「整体覆盖」）： · session-mechanism：含今天两条钩子改动（派活收工闸、点名加载收工闸）、 rules.md §9「只写正向范围」、检查程序静默阈值 10→6、检查排期补 workspace_scope（修未分组）、 以及今天修的三处陈旧指针（旧技能名 dsh-decision / agent-operating-rules 与旧路径编号）。 · product-planning：第③段「随段样式风格库」并入 design-system-tiaoyue、竞品分析方法论重写等。 · humanizer / humanizer-zh：已一致，零改动。 · browser-harness：比对出的 7 个「本地独有」全是**它自己 .gitignore 里就排除的**构建产物 （src/*.egg-info/ 与 uv.lock）⇒ 按该技能自己的规矩不推（用户口径「不要环境」）。 仓库级配置（与旧仓一致）：core.autocrlf=false；身份 maogeigei <[email protected]>。 ⚠️ 克隆时仓库默认 autocrlf=true（会把行尾转成 CRLF）⇒ 已改回 false 并重新暂存， 核对索引 blob 均为 LF、真实差异 23 个（⛔ 不是把几百个文件一起改掉）。
This commit is contained in:
admin committed
1 parent
0abd33b3a0
commit
61962f1726
23 files changed
+741
-250
No files matched your search
@@ -30,8 +30,7 @@ description: 产品规划总入口（唯一入口），四段式调度：① 产
|
||||
| ② → ③ | ② | **功能清单（每条带优先级 + 状态流转）+ 界面布局（有哪几页 / 每页几个板块 / 板块怎么排 / 跨页关系）+ 每页主操作 + 信息承载分档（主屏常驻 / 可点入）** | **视觉**（配色 / 字体 / 间距 / 组件样式 / 动效 —— 那是③段的活）；⛔ **也不许只给功能不给骨架**（骨架不给全，③段就一版一个样） |
|
||||
| ③ → ④ | ③ | 已跑通的单文件原型 HTML | 说明区与演示引导（④段的活，③段顺手写就是越界） |
|
||||
|
||||
> ⚠️ **2026-10-06 交接口口径反转**：②→③ 原写的是「⛔ 不许给页面结构」，**已废**。
|
||||
> **新口径：②段钉骨架，③段做皮肉。** 用户原话：「3 是负责设计和交互，**页面关系和布局必须在第二步确认清楚，不然第三步没有方向 一会一个样子**」。
|
||||
> **口径：②段钉骨架，③段做皮肉。** 用户原话：「3 是负责设计和交互，**页面关系和布局必须在第二步确认清楚，不然第三步没有方向 一会一个样子**」。
|
||||
> ⇒ **②段必须给**：有哪几页、每页几个板块、板块怎么排、跨页关系。**③段⛔ 不许增删移动板块**，缺板块回②段改 ②段。
|
||||
> ⛔ **仍归③段**：配色 / 字体 / 间距 / 组件样式 / 动效，以及每个板块的视觉与交互实现。
|
||||
|
||||
@@ -45,15 +44,12 @@ description: 产品规划总入口（唯一入口），四段式调度：① 产
|
||||
> ①叫「产品需求」而不叫「需求调研」：该段产出 `research/1a-需求文档.md`、`1b-竞品分析.md`、`1c-用户画像.md` **也**产出 `1d-产品策略.md`、`1e-使用场景.md`，"调研"二字盖不住后半截。
|
||||
|
||||
⭐⭐ **`grill-me` 全场只有①段一份（2026-10-06 用户定案）**：用户原话「**grill 也应该拿到第一步了，第二部就是细化功能**」。
|
||||
合并后①段那份**按 A / B 两节提问**：**A 节**「要做什么、为谁、边界在哪」（原①段火力点）｜**B 节**「做成什么样、哪些情况不成立、状态怎么流转」（原②段火力点）。
|
||||
⇒ **②段不再有 `grill-me.md`，也不再产出 `grill-decisions.md`**；B 节的结论落进 `research/1a-需求文档.md`。
|
||||
⛔ **不许在②段再加回一份** —— ②段从 2026-10-06 起**只细化功能，不再反问需求**。
|
||||
①段那份**按 A / B 两节提问**：**A 节**「要做什么、为谁、边界在哪」（原①段火力点）｜**B 节**「做成什么样、哪些情况不成立、状态怎么流转」（原②段火力点）；B 节结论落进 `research/1a-需求文档.md`。
|
||||
|
||||
⭐⭐ **②段产出从 7 份收成 1 份（2026-10-06 用户定案）**：用户原话「**不需要 就用使用场景，其余6分都不需要了**」。
|
||||
**删掉** `prd/grill-decisions.md`｜`prd/user-stories.md`｜`prd/priorities.md`｜`prd/pre-mortem.md`｜`ux/state-machine.md`｜`ux/diagrams/*`。
|
||||
**留下的两份**：`prd/2a-产品功能.md`（功能清单：做哪些 / 不做哪些 / 每条带优先级 + 状态流转）＋ `prd/2b-界面布局.md`（页面关系 + 页面内板块布局）。
|
||||
融合去向：状态机 → 进功能条目；用户故事 → 归①段《使用场景》（`1e-使用场景.md`）；图示 → 改名「界面布局」并独立成 `2b`；优先级 → 进功能条目。
|
||||
🔴 **2026-10-07 用户定案**：「**2 产品功能 和 界面布局不就是两个文档嘛**」⇒ 原「两半合成一份 `PRD.md`」的写法**推翻**，`PRD.md` 已废。
|
||||
⭐⭐ **②段产出两份（2026-10-06 收窄 · 2026-10-07 定为两份）**：用户原话「**不需要 就用使用场景，其余6分都不需要了**」「**2 产品功能 和 界面布局不就是两个文档嘛**」。
|
||||
`prd/2a-产品功能.md`（功能清单：做哪些 / 不做哪些 / 每条带优先级 + 状态流转）＋ `prd/2b-界面布局.md`（页面关系 + 页面内板块布局）。
|
||||
|
||||
（历史：交接口反转前的口径、②段收窄前的产出清单与其去向 → `references/_留痕/③段与总入口-旧口径.md`）
|
||||
⚠️ **本段功能的组织方式是按「使用场景」**（一条场景可跨多个页面），⛔ 不按页面组织。
|
||||
|
||||
段内的子步顺序、方法论文档、硬约束、完成标准，**都在各段自己的 `SKILL.md` 与 `references/` 里，本文件不重复**。
|
||||
@@ -183,7 +179,7 @@ description: 产品规划总入口（唯一入口），四段式调度：① 产
|
||||
- **反问优先，允许自动补全**：`grill-me` 的默认动作是把问题抛给用户并附推荐答案。用户说"你定"、连续两轮不回应、或属事实类问题时，模型自行给答案并标 `【假设】`，换来"不卡住"；但每轮结束要汇出**待复核清单**，未经复核的 `【假设】` 不得在下游当事实用。
|
||||
- **MVP 边界优先**：任何阶段都先回答"第一版做什么 / 不做什么"。
|
||||
- **必须落盘**：产出写入文件，不要只在对话里输出。
|
||||
- **无来源就标注**：市场规模、竞品数据无法查证时标为"估算"并写明口径，禁止编造数字当事实。
|
||||
- **无来源就标注**：任何查不到来源的数据都标为"估算"并写明口径，⛔ 不编造数字当事实。
|
||||
- **禁止长文**：单份产出物默认一页纸（≤120 行）；超长必须拆分。
|
||||
|
||||
## 每段的标准收尾格式
|
||||
@@ -235,7 +231,7 @@ python scripts/check_naming.py
|
||||
**第二次（2026-10-06，本轮）**：②段收窄为「只细化功能」（7 份产出 → 1 份）后，**各段 `SKILL.md` 都改了，但总入口 `product-planning/SKILL.md` 的三处仍写着旧结构** ——
|
||||
① 四段表的②段子步列仍是「2a 功能定义与压测 / 2b 功能流转 / 2c 功能图示」；
|
||||
② 四段表的①段子步列「1c 产品定位与商业设计」未随段内改名（段内已改称「产品定位与场景」）；
|
||||
③ 正文仍写「**① 与 ② 各跑一次 `grill-me`**」并指向两份同名文档（②段那份已删）。
|
||||
③ 正文仍写「**① 与 ② 各跑一次 `grill-me`**」并指向两份同名文档 —— 实际全场只有①段一份。
|
||||
⇒ **闸门当场报 6 个 FAIL**，根因就是这处「**改了承载段、忘了总入口**」。
|
||||
⭐ **由此立一条硬纪律（与记忆里的「换供给不能只改承载段」同型）**：**凡改子步结构 / 段内产出清单 / 段间交接口，必须连带改总入口 `product-planning/SKILL.md` 的「四段结构」表与「交接口」表** —— 不改就是**半改状态（比不改更糟）**。
|
||||
|
||||
|
||||
@@ -0,0 +1,85 @@
|
||||
# ①段留痕 · 已删除的产出与方法论
|
||||
|
||||
> **本档不在技能上下文里** —— `SKILL.md` 只在需要溯源时指向它，⛔ 正文不展开这些内容。
|
||||
> **为什么外置**（2026-10-07 用户定案）：「**技能中不需要写不用于XXXX，会造成上下文污染，直接写用于什么，把不相干的内容都删除**」。
|
||||
> **性质**：2026-10-07 从 `../SKILL.md` 逐字搬出的原文，**只增不删**，作为「为什么删」的唯一可读留痕。
|
||||
> **防复活不靠本档** —— 由 `scripts/check_naming.py` 的 `DEAD_OUTPUTS` / `DEPRECATED` / `WHITELIST` 机器判。
|
||||
> ⚠️ 原文里提到的路径（如 `待清理/`）是当时的记录，**不代表现在存在**。
|
||||
|
||||
---
|
||||
|
||||
## 一、`1a` 曾拆成两份（`00-问题定义.md` / `01-需求澄清.md`）
|
||||
|
||||
> 🔴 **本子步的产出是「一份」文档，不再拆成「一句话」和「决策表」两份**（2026-10-06 用户定案）。
|
||||
> ⛔ **已废的两份**：`00-问题定义.md`（一句话＋范围表）、`01-需求澄清.md`（决策表）—— 它们说的本来就是同一件事，拆两份只会打架。**内容合并进 `1a-需求文档.md`**：开头写清"做什么 / 为谁 / 不做什么"，往下摊开成决策表——目标、用户、范围与"明确不做什么"、手上已有的素材、约束、依赖、替代方案。
|
||||
|
||||
## 二、`grill-me` 曾有两份（①段一份 + ②段一份）
|
||||
|
||||
> ⭐ **`grill-me` 全场只有本段这一份**（2026-10-06 用户定案：「grill-me 也应该拿到第一步了，第二步就是细化功能」）。
|
||||
> 原②段另有一份 `grill-me.md`（火力点是"做成什么样、状态怎么流转"），**已删除并合并进本份**。合并后本份**按 A / B 两节提问**。
|
||||
|
||||
## 三、子步从 6 个收成 5 个
|
||||
|
||||
> ⭐ **子步从 6 个收成 1 个**（2026-10-02 用户定案「全部删除」）—— 市场分群、访谈准备、访谈整理、反馈分析**四项方法论已删**。删除理由不是"暂时没做"，是**结构性不可用**：
|
||||
>
|
||||
> - ⛔ **市场分群**：唯一使用者是用户本人，⛔ 不存在"要分群的多个市场"。
|
||||
> - ⛔ **访谈三类**：单机自用、**没有外部用户可访谈**；拿自己当访谈对象产出的就是自证材料（与机会树同病）。
|
||||
> - ⛔ **反馈分析**：需要真实反馈数据（评论/问卷/工单），⛔ 本项目一条都没有。
|
||||
>
|
||||
> ⭐ **同时把机会树也删了**（用户原话：「完全没用，都是编的」）。
|
||||
|
||||
## 四、`user-stories.md` 曾独立成文
|
||||
|
||||
> ⛔ **不用另写一份"用户故事"**：原②段的 `user-stories.md` 已删除，其内容归入本份。
|
||||
|
||||
## 五、商业模式与变现（精益画布 / 变现策略）
|
||||
|
||||
> ⭐ **商业模式与变现已删**（2026-10-02 用户定案）—— **精益画布与变现策略两份方法论一并移除**。删除理由是**结构性不可用**：产出本产品**不售卖、不融资、不面向付费用户**（`1b-竞品分析.md` 开头自己写着「这不是要售卖的产品，所以不做市场规模、份额、定价、融资」）。⚠️ 若将来某个项目**真的要做售卖**，这两项要重新补回来 —— **方法论副本在 `待清理/`**，可直接取回。
|
||||
|
||||
## 六、「需求文档」落点表里删掉的 5 行
|
||||
|
||||
> | ~~`prd/user-stories.md`~~ | **已删（2026-10-06）** | 用户故事归①段《使用场景》（`1e-使用场景.md`） |
|
||||
> | ~~`ux/state-machine.md`~~ | **已删（2026-10-06）** | 状态机**整合进 ②段功能清单** |
|
||||
> | ~~`ux/diagrams/*`~~ | **已删（2026-10-06）** | 图示改名「**界面布局**」并**整合进 ②段（独立成 `prd/2b-界面布局.md`）** |
|
||||
> | ~~`00-问题定义.md`~~ | **已废（2026-10-06）** | 并入 `1a-需求文档.md` |
|
||||
> | ~~`01-需求澄清.md`~~ | **已废（2026-10-06）** | 并入 `1a-需求文档.md` |
|
||||
|
||||
## 七、原「已删除的产出」整节（原文）
|
||||
|
||||
### ⛔ 机会树（`research/20-机会树.md` + `references/opportunity-solution-tree.md`）
|
||||
|
||||
**用户原话**：「完全没用，都是编的，不如去掉」。
|
||||
|
||||
**实测支撑**（原 `docs/pm/proto-versioning/` 七份取证产出里只有它零证据可查；⚠️ 该目录已于 2026-10-06 整体清除，备份在 `归档/proto-versioning清除备份__20261006-051003/`）：
|
||||
|
||||
- 全文零外链、零【事实】、仅 1 处【假设】。
|
||||
- 它的 Importance / Satisfaction 分数（0.90 / 0.10 / Score 0.81…）**没有任何数据来源**，是纯主观填数。
|
||||
- 它自己首段就写着「**无真实数据，全部为用研判断**」—— 诚实标注了，但**标注不等于成立**：一份自己都承认没数据的文档，占着「1b 取证」的名额产出。
|
||||
- 它的下游产物（`strategy/31`、`strategy/30`、②段的 `priorities.md`）大量引用这些分数 ⇒ **编的数会一路传到功能优先级**。
|
||||
|
||||
**替代**：⛔ 不产出任何替代文档。**它的真实内容（"我改错了回不去""文档互相踩"）已经由 `1a-需求文档.md` 的用户原话承载** —— 用户自己说的问题不需要打分。
|
||||
|
||||
⭐ **由此立的一条纪律**：**打分必须有数据源；没有数据源就不打分，写清"这是判断"即可。** `⛔ 凭空打分` 进反面清单。
|
||||
|
||||
### 价值主张 → 使用场景 → 用户故事（`strategy/31-价值主张.md` → `31-使用场景.md`）
|
||||
|
||||
**用户原话**（2026-10-02）：「价值主张 不如改为使用场景」。
|
||||
**用户原话**（2026-10-06）：「1 中的 使用场景 就是 用户故事 按照用户如何使用解决什么问题来梳理」。
|
||||
|
||||
**两次改的理由**：
|
||||
|
||||
**第一次（价值主张 → 使用场景）**：原文档是 Who / Why / What Before / How / What After / Alternatives 六段，其中 **Who 与 What After 在旧稿（已废的 `PRD.md`）§7.1.1 的 S1–S5 场景表里已经写过一遍**（谁、什么时候、要办成什么、落在主线哪一步）。⇒ 两份文档描述同一批人、同一条链，**必然打架**，而且价值主张里那套 What After 是"改成什么样"的想象，不是可核的交付。
|
||||
|
||||
**第二次（三段式 → 用户故事格式，2026-10-06）**：改称使用场景后，文档写成了「处境 / 现在怎么凑合 / 不用会用什么」三段 —— **是分析者视角，不是用户视角**，读起来像一份论证，不像用户的话。用户定案改成**用户故事格式**（作为…当…我要…这样…），并明确它就是用户故事。
|
||||
|
||||
**改成什么**：`references/usage-scenario.md` —— **唯一句式** `作为【谁】，当【什么处境】，我要【办成什么】，这样【得到什么结果】`，四槽位缺一不算完成。
|
||||
**旧三段式的残留价值不丢**：处境 → 「当…」槽位；凑合与替代 → 「这样…」的反面与对照（映射表见该文件 §5）。
|
||||
**边界（2026-10-06 重划）**：场景的**归口是①段本份**（②段**按它梳理功能**，⛔ 不重写场景，重写必打架）；⛔ **不许在①段写"每页放哪几块"那种界面话**（那是②段《界面布局》与③段 D0 的活）。
|
||||
**与②段的接口**：**《使用场景》是②段功能清单的直接推导依据** —— ②段每列一项功能都要能追回某条场景；追不回的该砍。
|
||||
|
||||
### 反面清单里被删掉的一条
|
||||
|
||||
> ⛔ **重新产出机会树**（已删除）
|
||||
|
||||
- **把推演出来的用户画像当用研结论进 1c** —— 三个 JTBD 若都追不到一句用户原话，那是自证不是用研
|
||||
- 越界去写 ②段、出原型或写原型说明文档（那是第②③④段）
|
||||
@@ -0,0 +1,55 @@
|
||||
# ②段留痕 · 已删除的产出与方法论
|
||||
|
||||
> **本档不在技能上下文里** —— `SKILL.md` 只在需要溯源时指向它，⛔ 正文不展开这些内容。
|
||||
> **为什么外置**（2026-10-07 用户定案）：「**技能中不需要写不用于XXXX，会造成上下文污染，直接写用于什么，把不相干的内容都删除**」。
|
||||
> **性质**：2026-10-07 从 `../SKILL.md` 逐字搬出的原文，**只增不删**，作为「为什么删」的唯一可读留痕。
|
||||
> **防复活不靠本档** —— 由 `scripts/check_naming.py` 的 `DEAD_OUTPUTS` / `DEPRECATED` / `WHITELIST` 机器判。
|
||||
|
||||
---
|
||||
|
||||
## 一、产出从 7 份收成 2 份
|
||||
|
||||
> **⭐⭐ 2026-10-06 用户定案：本段收窄为「只细化功能」——产出从 7 份收成 2 份。**
|
||||
> **⭐⭐ 2026-10-07 用户定案：「2 产品功能 和 界面布局不就是两个文档嘛」** —— 原「两半合成一份」的写法**推翻**，
|
||||
> 两件事各成一份：**产品功能**（做什么）＋ **界面布局**（长什么样）。
|
||||
>
|
||||
> **删掉的 6 份产出**（⛔ 不许加回来，理由逐条列在文末「已删除的产出」）：
|
||||
> `prd/grill-decisions.md`｜`prd/user-stories.md`｜`prd/priorities.md`｜`prd/pre-mortem.md`｜`ux/state-machine.md`｜`ux/diagrams/*`
|
||||
>
|
||||
> **留下的两份**：`prd/2a-产品功能.md`（功能清单）＋ `prd/2b-界面布局.md`（页面骨架）。
|
||||
> ⚠️ 原 `prd/PRD.md` **已废**（它把两件事塞在一份里）。
|
||||
>
|
||||
> **融合去哪了**：
|
||||
> - **状态机** ⇒ 整合进②段的功能清单（每个功能条目带自己的状态流转，⛔ 不再单独成文）
|
||||
> - **用户故事** ⇒ 归①段《使用场景》（`1e-使用场景.md`）（它就是用户故事）
|
||||
> - **grill / 压测** ⇒ 归①段 1a（全场唯一一份 `grill-me`）
|
||||
> - **图示** ⇒ 改名「**界面布局**」，整合进 ②段（独立成 `prd/2b-界面布局.md`）
|
||||
> - **优先级** ⇒ 进功能条目本身（每条标优先级，⛔ 不再单独成文）
|
||||
> - **事前验尸** ⇒ 删除（风险由①段《产品策略》的「假设与风险」承载）
|
||||
|
||||
## 二、②—③ 交接口的旧口径
|
||||
|
||||
> **旧口径（已废）**：②段**不给页面结构**，②定"房间"、③定"家具"。
|
||||
|
||||
## 三、反面清单里被删掉的一条
|
||||
|
||||
> ⛔ **产出 7 份里的任何第二份**（`grill-decisions` / `user-stories` / `priorities` / `pre-mortem` / `state-machine` / `diagrams`）—— 已删。
|
||||
|
||||
## 四、原「已删除的产出」整节（原文）
|
||||
|
||||
**用户原话**：「不需要 就用使用场景，其余6分都不需要了 grill 也应该拿到第一步了，第二部就是细化功能」。
|
||||
|
||||
| 删掉的 | 去向 |
|
||||
|---|---|
|
||||
| `prd/grill-decisions.md` | **合并进①段** —— `references/grill-me.md` 的决策表，落点 `research/1a-需求文档.md` |
|
||||
| `prd/user-stories.md` | **归①段《使用场景》（`1e-使用场景.md`）** —— 它就是用户故事 |
|
||||
| `prd/priorities.md` | **进功能条目本身** —— 每条标 P0/P1/P2 |
|
||||
| `prd/pre-mortem.md` | **删除** —— 风险由①段《产品策略》的「假设与风险」承载 |
|
||||
| `ux/state-machine.md` | **整合进 ②段功能清单** —— 每个功能条目自带状态流转 |
|
||||
| `ux/diagrams/*` | **改名「界面布局」并整合进 ②段（独立成 `prd/2b-界面布局.md`）** |
|
||||
|
||||
> ⚠️ **同时删掉的 4 份方法论**：`references/grill-me.md`（并入①段那份）、`references/user-stories.md`、`references/prioritization-frameworks.md`、`references/pre-mortem.md`。
|
||||
> **保留的 2 份**：`references/create-prd.md`（功能清单的方法论）、`references/state-machine.md`（**六项治理清单仍要读**，只是落点变成功能条目内）、`assets/diagram-design/`（整树保留，供画布局图）。
|
||||
>
|
||||
> ⭐ **为什么删的是这几份**：它们的**内容全部有归宿**（见上表），但**每一份独立成文都会与另一份打架** ——
|
||||
> `priorities.md` 与②段的功能条目抢优先级、`user-stories.md` 与①段《使用场景》（`1e-使用场景.md`）抢同一批人、`state-machine.md` 与功能清单抢"状态挂在哪"。
|
||||
@@ -0,0 +1,31 @@
|
||||
# ③段与总入口留痕 · 旧口径与已删除产出
|
||||
|
||||
> **本档不在技能上下文里** —— `SKILL.md` 只在需要溯源时指向它，⛔ 正文不展开这些内容。
|
||||
> **为什么外置**（2026-10-07 用户定案）：「**技能中不需要写不用于XXXX，会造成上下文污染，直接写用于什么，把不相干的内容都删除**」。
|
||||
> **性质**：2026-10-07 从 `../SKILL.md` 与 `../references/stage-delivery/SKILL.md` 逐字搬出的原文，**只增不删**。
|
||||
> **防复活不靠本档** —— 由 `scripts/check_naming.py` 的 `DEAD_OUTPUTS` / `DEPRECATED` / `WHITELIST` 机器判。
|
||||
|
||||
---
|
||||
|
||||
## 一、总入口 · 交接口 ②→③ 的旧口径
|
||||
|
||||
> ⚠️ **2026-10-06 交接口口径反转**：②→③ 原写的是「⛔ 不许给页面结构」，**已废**。
|
||||
|
||||
## 二、总入口 · `grill-me` 与 ②段产出的收缩记录
|
||||
|
||||
> ⭐⭐ **`grill-me` 全场只有①段一份（2026-10-06 用户定案）**：用户原话「**grill 也应该拿到第一步了，第二部就是细化功能**」。
|
||||
> ⇒ **②段不再有 `grill-me.md`，也不再产出 `grill-decisions.md`**；B 节的结论落进 `research/1a-需求文档.md`。
|
||||
> ⛔ **不许在②段再加回一份** —— ②段从 2026-10-06 起**只细化功能，不再反问需求**。
|
||||
>
|
||||
> ⭐⭐ **②段产出从 7 份收成 1 份（2026-10-06 用户定案）**：用户原话「**不需要 就用使用场景，其余6分都不需要了**」。
|
||||
> **删掉** `prd/grill-decisions.md`｜`prd/user-stories.md`｜`prd/priorities.md`｜`prd/pre-mortem.md`｜`ux/state-machine.md`｜`ux/diagrams/*`。
|
||||
> 融合去向：状态机 → 进功能条目；用户故事 → 归①段《使用场景》（`1e-使用场景.md`）；图示 → 改名「界面布局」并独立成 `2b`；优先级 → 进功能条目。
|
||||
> 🔴 **2026-10-07 用户定案**：「**2 产品功能 和 界面布局不就是两个文档嘛**」⇒ 原「两半合成一份 `PRD.md`」的写法**推翻**，`PRD.md` 已废。
|
||||
|
||||
## 三、③段 · 页面骨架归属的旧口径
|
||||
|
||||
> **旧口径（已废）**：「页面结构归本段，唯一落点是 3a 的 D0 设计契约」。②段只给"必须在界面上发生什么"，本段**独立推导**"几个页面、每页放什么"。
|
||||
|
||||
## 四、③段手册 · D0 锚需求的旧口径
|
||||
|
||||
> 本节原文写的是「先把②段的界面描述降级为功能约束，那份视图清单本身不许当结构用」——**这条已废**。
|
||||
@@ -64,10 +64,9 @@ description: 产品规划第③段，界面交互。设计工程供给来自 ope
|
||||
|
||||
> **为什么换掉原来的主干**（2026-10-02 用户定案）：原主干 `ui-page-design` 在磁盘上已不存在，③段只剩规则壳；而壳里全是减法型判据，机检能判"不违规"却判不出"好看"，18 轮回改把页面越推越白。**换供给的同时必须换判据结构：正向目标为主，禁令只留最关键的。**
|
||||
|
||||
> ⭐⭐ **页面骨架不归本段了 —— 2026-10-06 用户定案，推翻本节原口径。**
|
||||
> ⭐⭐ **本段在②段给定的骨架里做视觉与交互**（2026-10-06 用户定案）。
|
||||
>
|
||||
> **旧口径（已废）**：「页面结构归本段，唯一落点是 3a 的 D0 设计契约」。②段只给"必须在界面上发生什么"，本段**独立推导**"几个页面、每页放什么"。
|
||||
> **新口径**：**②段钉骨架，③段做皮肉。**
|
||||
> **口径**：**②段钉骨架，③段做皮肉。**
|
||||
>
|
||||
> | 归②段（本段⛔ 不许动） | 归本段（②段⛔ 不许写） |
|
||||
> |---|---|
|
||||
|
||||
@@ -86,9 +86,8 @@
|
||||
|
||||
### 2.1 D0 锚需求 → 设计契约
|
||||
|
||||
> ⭐⭐ **2026-10-06 口径反转（用户定案）：骨架归②段，本段做皮肉。**
|
||||
> 本节原文写的是「先把②段的界面描述降级为功能约束，那份视图清单本身不许当结构用」——**这条已废**。
|
||||
> **新口径**：②段《界面布局》里的**页面清单 / 每页板块 / 板块排列 / 跨页关系**就是**骨架定稿**，
|
||||
> ⭐⭐ **口径（2026-10-06 用户定案）：骨架归②段，本段做皮肉。**
|
||||
> ②段《界面布局》里的**页面清单 / 每页板块 / 板块排列 / 跨页关系**就是**骨架定稿**，
|
||||
> 本段⛔ **不许增删移动板块**，**要改回②段改 ②段**。本段在给定骨架内决定**视觉与交互实现**。
|
||||
> **理由（用户原话）**：「页面关系和布局必须在第二步确认清楚，不然第三步没有方向 一会一个样子」。
|
||||
> ⛔ **仍归本段的**：配色 / 字体 / 间距 / 组件样式 / 动效 / 板块内的排版与交互行为 / 响应式。
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: stage-discovery
|
||||
description: 产品规划第①段，产品需求。五个子步依次产出五份文档：1a 需求文档（用 grill-me 反问澄清需求，用户不答时给推荐答案并标【假设】继续）、1b 竞品分析、1c 用户画像、1d 产品策略、1e 使用场景（按用户故事格式写：谁、在什么处境下、要办成什么）。当用户要做竞品分析、用户画像、产品策略、使用场景，或说"只做产品需求"时调用。⛔ 不含市场分群/访谈/反馈分析/商业模式/变现（已按结构性不可用删除），不含功能清单与界面。
|
||||
description: 产品规划第①段，产品需求。五个子步依次产出五份文档：1a 需求文档（用 grill-me 反问澄清需求，用户不答时给推荐答案并标【假设】继续）、1b 竞品分析、1c 用户画像、1d 产品策略、1e 使用场景（按用户故事格式写：谁、在什么处境下、要办成什么）。当用户要做竞品分析、用户画像、产品策略、使用场景，或说"只做产品需求"时调用。
|
||||
---
|
||||
|
||||
# ① 产品需求
|
||||
@@ -50,15 +50,14 @@ description: 产品规划第①段，产品需求。五个子步依次产出五
|
||||
|---|---|---|
|
||||
| **需求文档（grill-me）** | `references/grill-me.md` | `docs/pm/<项目>/research/1a-需求文档.md` |
|
||||
|
||||
🔴 **本子步的产出是「一份」文档，不再拆成「一句话」和「决策表」两份**（2026-10-06 用户定案）。
|
||||
⛔ **已废的两份**：`00-问题定义.md`（一句话＋范围表）、`01-需求澄清.md`（决策表）—— 它们说的本来就是同一件事，拆两份只会打架。**内容合并进 `1a-需求文档.md`**：开头写清"做什么 / 为谁 / 不做什么"，往下摊开成决策表——目标、用户、范围与"明确不做什么"、手上已有的素材、约束、依赖、替代方案。
|
||||
🔴 **本子步的产出是「一份」文档**（2026-10-06 用户定案）：`1a-需求文档.md` 一份说清全部 —— 开头写清"做什么 / 为谁 / 不做什么"，往下摊开成决策表：目标、用户、范围与"明确不做什么"、手上已有的素材、约束、依赖、替代方案。
|
||||
（历史：为什么从两份并成一份 → `_留痕/①段-已删除产出与方法论.md`）
|
||||
|
||||
**默认反问用户，附推荐答案**；用户说"你定"、连续两轮不回应、或问题属事实类时，模型自行补答案并标 `【假设】`，但每轮结束要汇出**待复核清单**让用户一次性过。未经复核的 `【假设】` 不得在 1d 当事实用。
|
||||
|
||||
**本子步不受"提问上限 3 个"约束**——把需求问清楚正是它的全部价值。进入前先声明"接下来会连续多轮提问"。这是本段唯一例外（详见 `references/grill-me.md`）。
|
||||
|
||||
⭐ **`grill-me` 全场只有本段这一份**（2026-10-06 用户定案：「grill-me 也应该拿到第一步了，第二步就是细化功能」）。
|
||||
原②段另有一份 `grill-me.md`（火力点是"做成什么样、状态怎么流转"），**已删除并合并进本份**。合并后本份**按 A / B 两节提问**：
|
||||
⭐ **`grill-me` 全场只有本段这一份**（2026-10-06 用户定案：「grill-me 也应该拿到第一步了，第二步就是细化功能」）。本份**按 A / B 两节提问**：
|
||||
|
||||
| 节 | 火力点 | 原归属 |
|
||||
|---|---|---|
|
||||
@@ -77,13 +76,32 @@ description: 产品规划第①段，产品需求。五个子步依次产出五
|
||||
|
||||
⭐ **用户点名的"参考实装"写进本份，⛔ 不另立文档**（见「产出白名单」）。它和通用竞品是同一件事的两层：**通用竞品**看这一类产品都怎么做，**点名参考**拆用户指定的那一个。两者并成一份的 §一 / §二。
|
||||
|
||||
⭐ **子步从 6 个收成 1 个**（2026-10-02 用户定案「全部删除」）—— 市场分群、访谈准备、访谈整理、反馈分析**四项方法论已删**。删除理由不是"暂时没做"，是**结构性不可用**：
|
||||
🔴 **目标**：从**产品视角**横向拆解竞品 —— 讲**用途**、讲**场景**、讲**功能**、讲**作用**、讲**优势**（2026-10-07 用户口径）。
|
||||
|
||||
- ⛔ **市场分群**：唯一使用者是用户本人，⛔ 不存在"要分群的多个市场"。
|
||||
- ⛔ **访谈三类**：单机自用、**没有外部用户可访谈**；拿自己当访谈对象产出的就是自证材料（与机会树同病）。
|
||||
- ⛔ **反馈分析**：需要真实反馈数据（评论/问卷/工单），⛔ 本项目一条都没有。
|
||||
**执行**：
|
||||
1. 读 `references/competitor-analysis.md`（**唯一**方法论载体，含 §0 Scope 与文末《输出检查》）
|
||||
2. 按项目目标圈定竞品范围（直接竞品 ＋ 至少 1 个替代/间接方案 ＋ 点名的参考实装）
|
||||
3. 按 **用途 → 场景 → 功能 → 作用 → 优势** 横向比（⛔ 不按竞品逐个写）
|
||||
4. 输出优势与不足、可借鉴点与产品机会
|
||||
5. 交付前走一遍该方法论文末《输出检查》：任一条为「否」⇒ **退回修改，⛔ 不交付**
|
||||
|
||||
⭐ **同时把机会树也删了**（用户原话：「完全没用，都是编的」）—— 详见文末「已删除的产出」。
|
||||
🔴 **最低输出结构**（最低要求，⛔ 不是固定模板 —— 不同品类维度不同，可增不可缺）：
|
||||
|
||||
| # | 节 | 回答什么 |
|
||||
|---|---|---|
|
||||
| 1 | 分析目标与范围 | 这次要回答什么 |
|
||||
| 2 | 竞品选择与范围 | 选了谁、为什么是它 |
|
||||
| 3 | 竞品用途 | 是什么 / 给谁用 / 干什么用 |
|
||||
| 4 | 使用场景横向对比 | 用户在各处境下怎么把事办成 |
|
||||
| 5 | 功能横向对比 | 功能 → 解决什么问题 → 起什么作用 |
|
||||
| 6 | 产品机制与交互方式 | 为什么这样设计 |
|
||||
| 7 | 优势与不足 | 能力 → 场景 → 用户价值 |
|
||||
| 8 | 竞品能力矩阵 | 共识 / 差异 / 独有 / 普遍短板 / 未解决需求 |
|
||||
| 9 | 可借鉴点与产品机会 | 该借鉴 / 该避开 / 可突破 |
|
||||
| 10 | 结论（产品层） | 本产品应优先解决什么 |
|
||||
|
||||
⭐ **①段就是上表这 5 个子步**，每个子步一个方法论载体、一份产出 —— 这套结构**直接服务单机自用的产品**（用户本人就是唯一使用者）。
|
||||
（历史：本段曾有过另外几个子步、以及一次子步合并，为什么收成 5 个 → `_留痕/①段-已删除产出与方法论.md`）
|
||||
|
||||
## 1c 用户画像（外部取证）
|
||||
|
||||
@@ -111,10 +129,11 @@ description: 产品规划第①段，产品需求。五个子步依次产出五
|
||||
|
||||
四个槽位缺一不算完成；⛔ **「我要办成什么」里不许出现功能名**（出现即越界到②段）。
|
||||
它是②段功能清单的**直接推导依据** —— ②段每列一项功能，都要能追回本份的某一条场景；②段**按使用场景梳理功能**（一条场景可跨多个页面）。
|
||||
⛔ **不用另写一份"用户故事"**：原②段的 `user-stories.md` 已删除，其内容归入本份。
|
||||
⭐ **本份就是用户故事** —— `1e-使用场景.md` 一份承载全部；②段的功能清单直接追回本份。
|
||||
⭐ **旧三段式（处境 / 现在怎么凑合 / 不用会用什么）改挂到四槽位**：处境 → 「当…」；凑合与替代 → 「这样…」的反面与对照。映射表见 `references/usage-scenario.md` §5。
|
||||
|
||||
⭐ **商业模式与变现已删**（2026-10-02 用户定案）—— **精益画布与变现策略两份方法论一并移除**。删除理由是**结构性不可用**：产出本产品**不售卖、不融资、不面向付费用户**（`1b-竞品分析.md` 开头自己写着「这不是要售卖的产品，所以不做市场规模、份额、定价、融资」）。⚠️ 若将来某个项目**真的要做售卖**，这两项要重新补回来 —— **方法论副本在 `待清理/`**，可直接取回。
|
||||
⭐ **1d《产品策略》与 1b《竞品分析》都落在产品层** —— 回答"谁在什么处境下拿它办成什么事、做哪些功能、强在哪"，面向本产品自用的定位。
|
||||
（历史：本段原还挂过两份面向售卖场景的方法论，若某个项目真要做售卖可从 `_留痕/①段-已删除产出与方法论.md` 取回）
|
||||
|
||||
## 「需求文档」在本段的落点（2026-10-02 定 · 2026-10-06 更新，避免误搬家）
|
||||
|
||||
@@ -129,11 +148,6 @@ description: 产品规划第①段，产品需求。五个子步依次产出五
|
||||
| `research/1e-使用场景.md` | **①段** | 用户怎么用它；**使用场景 = 用户故事** |
|
||||
| `prd/2a-产品功能.md` | **②段** | 它是**功能清单**（做哪些 / 不做哪些 / 优先级 + 每条的状态流转） |
|
||||
| `prd/2b-界面布局.md` | **②段** | 它是**页面骨架**（页面关系 + 页面内板块布局 —— 有哪几页、每页几个板块） |
|
||||
| ~~`prd/user-stories.md`~~ | **已删（2026-10-06）** | 用户故事归①段《使用场景》（`1e-使用场景.md`） |
|
||||
| ~~`ux/state-machine.md`~~ | **已删（2026-10-06）** | 状态机**整合进 ②段功能清单** |
|
||||
| ~~`ux/diagrams/*`~~ | **已删（2026-10-06）** | 图示改名「**界面布局**」并**整合进 ②段（独立成 `prd/2b-界面布局.md`）** |
|
||||
| ~~`00-问题定义.md`~~ | **已废（2026-10-06）** | 并入 `1a-需求文档.md` |
|
||||
| ~~`01-需求澄清.md`~~ | **已废（2026-10-06）** | 并入 `1a-需求文档.md` |
|
||||
|
||||
> **分界线一句话**：**①段回答「要解决什么问题、用户怎么用它」，②段回答「要做哪些功能、长成什么骨架」。**
|
||||
> 判据：一份文档若主体是**功能条目的有无与优先级、页面与板块骨架** → 归②；若主体是**问题、用户、取证与取舍理由** → 归①。
|
||||
@@ -179,40 +193,11 @@ description: 产品规划第①段，产品需求。五个子步依次产出五
|
||||
- 把 11 个子步全跑一遍充数
|
||||
- 事实与假设混在一起不标注
|
||||
- **拿"frontier 为空 / 无遗留未决项"当闭合声明，而正文里还挂着未经确认的假设** —— 只读首屏的人会误读成需求已澄清
|
||||
- ⛔ **重新产出机会树**（已删除，见下节）
|
||||
- ⛔ **凭空给 Importance / Satisfaction 打分** —— 没有任何数据源支撑的数字，⛔ 不许出现在交付物里
|
||||
|
||||
## 已删除的产出（2026-10-02 用户定案 · 防加回来）
|
||||
## 反面清单（续）
|
||||
|
||||
### ⛔ 机会树（`research/20-机会树.md` + `references/opportunity-solution-tree.md`）
|
||||
|
||||
**用户原话**：「完全没用，都是编的，不如去掉」。
|
||||
|
||||
**实测支撑**（原 `docs/pm/proto-versioning/` 七份取证产出里只有它零证据可查；⚠️ 该目录已于 2026-10-06 整体清除，备份在 `归档/proto-versioning清除备份__20261006-051003/`）：
|
||||
|
||||
- 全文零外链、零【事实】、仅 1 处【假设】。
|
||||
- 它的 Importance / Satisfaction 分数（0.90 / 0.10 / Score 0.81…）**没有任何数据来源**，是纯主观填数。
|
||||
- 它自己首段就写着「**无真实数据，全部为用研判断**」—— 诚实标注了，但**标注不等于成立**：一份自己都承认没数据的文档，占着「1b 取证」的名额产出。
|
||||
- 它的下游产物（`strategy/31`、`strategy/30`、②段的 `priorities.md`）大量引用这些分数 ⇒ **编的数会一路传到功能优先级**。
|
||||
|
||||
**替代**：⛔ 不产出任何替代文档。**它的真实内容（"我改错了回不去""文档互相踩"）已经由 `1a-需求文档.md` 的用户原话承载** —— 用户自己说的问题不需要打分。
|
||||
|
||||
⭐ **由此立的一条纪律**：**打分必须有数据源；没有数据源就不打分，写清"这是判断"即可。** `⛔ 凭空打分` 进反面清单。
|
||||
|
||||
### 价值主张 → 使用场景 → 用户故事（`strategy/31-价值主张.md` → `31-使用场景.md`）
|
||||
|
||||
**用户原话**（2026-10-02）：「价值主张 不如改为使用场景」。
|
||||
**用户原话**（2026-10-06）：「1 中的 使用场景 就是 用户故事 按照用户如何使用解决什么问题来梳理」。
|
||||
|
||||
**两次改的理由**：
|
||||
|
||||
**第一次（价值主张 → 使用场景）**：原文档是 Who / Why / What Before / How / What After / Alternatives 六段，其中 **Who 与 What After 在旧稿（已废的 `PRD.md`）§7.1.1 的 S1–S5 场景表里已经写过一遍**（谁、什么时候、要办成什么、落在主线哪一步）。⇒ 两份文档描述同一批人、同一条链，**必然打架**，而且价值主张里那套 What After 是"改成什么样"的想象，不是可核的交付。
|
||||
|
||||
**第二次（三段式 → 用户故事格式，2026-10-06）**：改称使用场景后，文档写成了「处境 / 现在怎么凑合 / 不用会用什么」三段 —— **是分析者视角，不是用户视角**，读起来像一份论证，不像用户的话。用户定案改成**用户故事格式**（作为…当…我要…这样…），并明确它就是用户故事。
|
||||
|
||||
**改成什么**：`references/usage-scenario.md` —— **唯一句式** `作为【谁】，当【什么处境】，我要【办成什么】，这样【得到什么结果】`，四槽位缺一不算完成。
|
||||
**旧三段式的残留价值不丢**：处境 → 「当…」槽位；凑合与替代 → 「这样…」的反面与对照（映射表见该文件 §5）。
|
||||
**边界（2026-10-06 重划）**：场景的**归口是①段本份**（②段**按它梳理功能**，⛔ 不重写场景，重写必打架）；⛔ **不许在①段写"每页放哪几块"那种界面话**（那是②段《界面布局》与③段 D0 的活）。
|
||||
**与②段的接口**：**《使用场景》是②段功能清单的直接推导依据** —— ②段每列一项功能都要能追回某条场景；追不回的该砍。
|
||||
- **把推演出来的用户画像当用研结论进 1c** —— 三个 JTBD 若都追不到一句用户原话，那是自证不是用研
|
||||
- 越界去写 ②段、出原型或写原型说明文档（那是第②③④段）
|
||||
- 越界去写 ②段、出原型或写原型说明文档（那是第②③④段）
|
||||
|
||||
📎 **本段删过的产出与方法论**（原产出长什么样、为什么删、原反面清单里被撤掉的那一条）见 `_留痕/①段-已删除产出与方法论.md` —— 正文不展开；防复活由 `scripts/check_naming.py` 的 `DEAD_OUTPUTS` 机器判。
|
||||
+116
@@ -0,0 +1,116 @@
|
||||
> 🔴 **已退役留痕（2026-10-07）** —— 本档**不再作为方法论使用**，仅供回溯。
|
||||
>
|
||||
> 退役原因：它是**英文的「市场商业分析」框架**（市场规模/份额、融资、定价、GTM、12–18 个月商业风险），
|
||||
> 与技能层 `../SKILL.md` 第 117 行「不做市场规模、份额、定价、融资」**直接矛盾**，
|
||||
> 且全篇不含「用途 / 场景 / 功能 / 作用 / 优势」这类产品视角要求。
|
||||
> 处置：`competitor-analysis.md` 已全文重写为**中文产品视角方法论**；本档为改版前原件的**逐字留痕**（5,106 B）。
|
||||
> ⛔ 引用请引 `competitor-analysis.md`。
|
||||
|
||||
# Competitor Analysis
|
||||
|
||||
> **Trae 用法**：本 skill 由模型按需自动加载，没有斜杠命令。若对话中尚未明确对象，先向用户确认，不要自行假设。
|
||||
> **产出约定**：结果写入 `docs/pm/<项目>/<阶段>/<主题>-<类型>.md`，阶段取 `research` / `strategy` / `prd` / `ux`；`<项目>` 是项目 slug，定义见 `product-planning` 的「项目与路径约定」。
|
||||
|
||||
## Purpose
|
||||
Conduct a comprehensive competitive analysis to understand the landscape, identify 5 direct competitors, and uncover differentiation opportunities. This skill maps competitive positioning, synthesizes competitor strengths and weaknesses, and highlights opportunities for strategic differentiation.
|
||||
|
||||
## Instructions
|
||||
|
||||
You are a strategic product analyst and competitive intelligence expert specializing in competitive positioning and market landscape mapping.
|
||||
|
||||
### Input
|
||||
Your task is to analyze the competitive landscape for **the product/feature in focus** in the **[market/industry segment]** (if specified).
|
||||
|
||||
Conduct web research to identify direct competitors. If the user provides market research, competitor data, pricing sheets, feature comparisons, or customer feedback about competitors, read and analyze them directly. Synthesize data into a comprehensive competitive view.
|
||||
|
||||
### Analysis Steps (Think Step by Step)
|
||||
|
||||
1. **Market Scoping**: Define the market, industry, and addressable customer base for the product/feature in focus
|
||||
2. **Competitor Identification**: Use web search to identify 5 primary direct competitors
|
||||
3. **Competitive Intelligence**: Research each competitor's positioning, features, pricing, go-to-market strategy
|
||||
4. **Strengths & Weaknesses**: Assess competitor capabilities, limitations, and market positioning
|
||||
5. **Differentiation Mapping**: Identify gaps, overlaps, and opportunities for the product/feature in focus to differentiate
|
||||
6. **Strategic Synthesis**: Develop insights about competitive dynamics and future threats
|
||||
|
||||
### Output Structure
|
||||
|
||||
**Market Overview & Definition**
|
||||
- Market size and growth trends
|
||||
- Primary customer segments and use cases
|
||||
- Key success factors in this market
|
||||
- Market dynamics and competitive intensity
|
||||
|
||||
**Competitive Set Summary**
|
||||
- 5 primary direct competitors identified
|
||||
- Market positions: leaders, challengers, niche players
|
||||
- Estimated market share or positioning
|
||||
- Notable adjacent or indirect competitors
|
||||
|
||||
For each of the 5 competitors:
|
||||
|
||||
**Competitor Profile**
|
||||
- Company name, founding date, funding/status
|
||||
- Primary market focus and customer segments served
|
||||
- Estimated market share or customer base size
|
||||
- Market positioning and go-to-market strategy
|
||||
|
||||
**Core Product Strengths**
|
||||
- Key features and capabilities
|
||||
- Unique competitive advantages
|
||||
- Customer value proposition
|
||||
- Technology differentiation or moats
|
||||
- Customer satisfaction and retention signals
|
||||
|
||||
**Product Weaknesses & Gaps**
|
||||
- Missing features or use cases
|
||||
- Known limitations or pain points for customers
|
||||
- Technical or operational weaknesses
|
||||
- Market positioning gaps
|
||||
- Customer dissatisfaction areas
|
||||
|
||||
**Business Model & Pricing**
|
||||
- Pricing structure (per-seat, per-usage, flat-fee, freemium, etc.)
|
||||
- Price point(s) in market
|
||||
- Go-to-market channels and sales motion
|
||||
- Revenue model and growth stage
|
||||
|
||||
**Competitive Threats & Advantages**
|
||||
- How this competitor threatens the product/feature in focus
|
||||
- Existing customer base and switching costs
|
||||
- Strategic partnerships or ecosystems
|
||||
- Recent product updates or strategic moves
|
||||
|
||||
**Differentiation Opportunities for the product/feature in focus**
|
||||
|
||||
- Unmet customer needs across competitive set
|
||||
- Feature/pricing/UX opportunities to stand out
|
||||
- Target segments underserved by competitors
|
||||
- Jobs-to-be-done not effectively solved by competitors
|
||||
- Channel or go-to-market approaches not yet deployed
|
||||
- Potential partnerships or integrations competitors lack
|
||||
|
||||
**Competitive Positioning Recommendation**
|
||||
- Recommended competitive positioning for the product/feature in focus
|
||||
- Key differentiators to emphasize
|
||||
- Segments or use cases to target or avoid
|
||||
- Competitive threats to monitor
|
||||
- 12-18 month competitive risks and opportunities
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Research current competitor websites, pricing pages, and customer reviews
|
||||
- Use web search to identify product launches, funding, executive moves
|
||||
- Distinguish between direct competitors and adjacent alternatives
|
||||
- Validate competitive insights across multiple sources
|
||||
- Identify both obvious and subtle differentiation opportunities
|
||||
- Consider customer pain points not yet addressed in market
|
||||
- Look for emerging competitors or new market entrants
|
||||
- Flag competitors gaining traction or gaining market share
|
||||
- Consider long-term competitive dynamics and market shifts
|
||||
|
||||
---
|
||||
|
||||
### Further Reading
|
||||
|
||||
- [Market Research: Advanced Techniques](https://www.productcompass.pm/p/market-research-advanced-techniques)
|
||||
- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate)
|
||||
@@ -1,108 +1,175 @@
|
||||
# Competitor Analysis
|
||||
|
||||
> **Trae 用法**：本 skill 由模型按需自动加载，没有斜杠命令。若对话中尚未明确对象，先向用户确认，不要自行假设。
|
||||
> **产出约定**：结果写入 `docs/pm/<项目>/<阶段>/<主题>-<类型>.md`，阶段取 `research` / `strategy` / `prd` / `ux`；`<项目>` 是项目 slug，定义见 `product-planning` 的「项目与路径约定」。
|
||||
|
||||
## Purpose
|
||||
Conduct a comprehensive competitive analysis to understand the landscape, identify 5 direct competitors, and uncover differentiation opportunities. This skill maps competitive positioning, synthesizes competitor strengths and weaknesses, and highlights opportunities for strategic differentiation.
|
||||
|
||||
## Instructions
|
||||
|
||||
You are a strategic product analyst and competitive intelligence expert specializing in competitive positioning and market landscape mapping.
|
||||
|
||||
### Input
|
||||
Your task is to analyze the competitive landscape for **the product/feature in focus** in the **[market/industry segment]** (if specified).
|
||||
|
||||
Conduct web research to identify direct competitors. If the user provides market research, competitor data, pricing sheets, feature comparisons, or customer feedback about competitors, read and analyze them directly. Synthesize data into a comprehensive competitive view.
|
||||
|
||||
### Analysis Steps (Think Step by Step)
|
||||
|
||||
1. **Market Scoping**: Define the market, industry, and addressable customer base for the product/feature in focus
|
||||
2. **Competitor Identification**: Use web search to identify 5 primary direct competitors
|
||||
3. **Competitive Intelligence**: Research each competitor's positioning, features, pricing, go-to-market strategy
|
||||
4. **Strengths & Weaknesses**: Assess competitor capabilities, limitations, and market positioning
|
||||
5. **Differentiation Mapping**: Identify gaps, overlaps, and opportunities for the product/feature in focus to differentiate
|
||||
6. **Strategic Synthesis**: Develop insights about competitive dynamics and future threats
|
||||
|
||||
### Output Structure
|
||||
|
||||
**Market Overview & Definition**
|
||||
- Market size and growth trends
|
||||
- Primary customer segments and use cases
|
||||
- Key success factors in this market
|
||||
- Market dynamics and competitive intensity
|
||||
|
||||
**Competitive Set Summary**
|
||||
- 5 primary direct competitors identified
|
||||
- Market positions: leaders, challengers, niche players
|
||||
- Estimated market share or positioning
|
||||
- Notable adjacent or indirect competitors
|
||||
|
||||
For each of the 5 competitors:
|
||||
|
||||
**Competitor Profile**
|
||||
- Company name, founding date, funding/status
|
||||
- Primary market focus and customer segments served
|
||||
- Estimated market share or customer base size
|
||||
- Market positioning and go-to-market strategy
|
||||
|
||||
**Core Product Strengths**
|
||||
- Key features and capabilities
|
||||
- Unique competitive advantages
|
||||
- Customer value proposition
|
||||
- Technology differentiation or moats
|
||||
- Customer satisfaction and retention signals
|
||||
|
||||
**Product Weaknesses & Gaps**
|
||||
- Missing features or use cases
|
||||
- Known limitations or pain points for customers
|
||||
- Technical or operational weaknesses
|
||||
- Market positioning gaps
|
||||
- Customer dissatisfaction areas
|
||||
|
||||
**Business Model & Pricing**
|
||||
- Pricing structure (per-seat, per-usage, flat-fee, freemium, etc.)
|
||||
- Price point(s) in market
|
||||
- Go-to-market channels and sales motion
|
||||
- Revenue model and growth stage
|
||||
|
||||
**Competitive Threats & Advantages**
|
||||
- How this competitor threatens the product/feature in focus
|
||||
- Existing customer base and switching costs
|
||||
- Strategic partnerships or ecosystems
|
||||
- Recent product updates or strategic moves
|
||||
|
||||
**Differentiation Opportunities for the product/feature in focus**
|
||||
|
||||
- Unmet customer needs across competitive set
|
||||
- Feature/pricing/UX opportunities to stand out
|
||||
- Target segments underserved by competitors
|
||||
- Jobs-to-be-done not effectively solved by competitors
|
||||
- Channel or go-to-market approaches not yet deployed
|
||||
- Potential partnerships or integrations competitors lack
|
||||
|
||||
**Competitive Positioning Recommendation**
|
||||
- Recommended competitive positioning for the product/feature in focus
|
||||
- Key differentiators to emphasize
|
||||
- Segments or use cases to target or avoid
|
||||
- Competitive threats to monitor
|
||||
- 12-18 month competitive risks and opportunities
|
||||
|
||||
## Best Practices
|
||||
|
||||
- Research current competitor websites, pricing pages, and customer reviews
|
||||
- Use web search to identify product launches, funding, executive moves
|
||||
- Distinguish between direct competitors and adjacent alternatives
|
||||
- Validate competitive insights across multiple sources
|
||||
- Identify both obvious and subtle differentiation opportunities
|
||||
- Consider customer pain points not yet addressed in market
|
||||
- Look for emerging competitors or new market entrants
|
||||
- Flag competitors gaining traction or gaining market share
|
||||
- Consider long-term competitive dynamics and market shifts
|
||||
|
||||
---
|
||||
|
||||
### Further Reading
|
||||
|
||||
- [Market Research: Advanced Techniques](https://www.productcompass.pm/p/market-research-advanced-techniques)
|
||||
- [User Interviews: The Ultimate Guide to Research Interviews](https://www.productcompass.pm/p/interviewing-customers-the-ultimate)
|
||||
# 竞品分析方法论（1b · 产品视角）
|
||||
|
||||
> **定位**：本档是 1b 竞品分析**唯一的方法论载体**。技能层（`../SKILL.md` §1b）定「必须交付什么」，本档定「怎么分析」。
|
||||
> **产出落点**：`docs/pm/<项目>/research/1b-竞品分析.md`（①段产出白名单五份之一）。
|
||||
> **口径来源**：2026-10-07 用户定案 ——「分析重点是讲**用途**、讲**场景**、讲**功能**、讲**作用**、讲**优势**，其余跟产品规划不相关的都去掉」。
|
||||
|
||||
---
|
||||
|
||||
## 0. Scope
|
||||
|
||||
### 0.1 本方法用于
|
||||
|
||||
为一款**将要做的产品**，横向拆解同类产品**在产品层面**是怎么解决用户问题的 —— 讲**用途**、讲**场景**、讲**功能**、讲**作用**、讲**优势**。
|
||||
|
||||
### 0.2 上层约束
|
||||
|
||||
`../SKILL.md` §1b 定「必须交付什么」，本档定「怎么分析」。两者冲突时**以技能层为准**，并回头修正本档。
|
||||
|
||||
### 0.3 完成判据（一句话）
|
||||
|
||||
做完 1b 必须能回答：
|
||||
|
||||
> 如果我要做这个产品：竞品已经怎么做了？哪里做得好？哪里没做好？我该学什么、避开什么、突破什么？
|
||||
|
||||
答不出这句话 ⇒ **1b 没做完**。
|
||||
|
||||
---
|
||||
|
||||
## 1. 分析目标与范围
|
||||
|
||||
**写什么**：把这次要回答的问题写死在文档开头，并让下列**五问**各有明确落点 ——
|
||||
|
||||
| 五问 | 落在哪一节 |
|
||||
|---|---|
|
||||
| 用途：它是什么、给谁用、干什么用？ | §3 |
|
||||
| 场景：用户在什么处境下会用它？ | §4 |
|
||||
| 功能：它有哪些核心功能？ | §5 |
|
||||
| 作用：每个功能解决什么问题？ | §5 |
|
||||
| 优势：它在哪些场景下更强 / 更弱？ | §7 |
|
||||
|
||||
**判据**：五问**各有一处明确落点**（⛔ 不是散落在正文里靠读者自己找）。
|
||||
|
||||
---
|
||||
|
||||
## 2. 竞品选择与范围
|
||||
|
||||
**写什么**：竞品分三层，逐层交代为什么选它 ——
|
||||
|
||||
1. **直接竞品**：解决同一个核心问题、目标用户高度重叠。
|
||||
2. **间接 / 替代方案**：同一需求的不同产品形态，或**用户不用这类产品**时的替代做法。
|
||||
3. **点名参考实装**：用户**点名指定**的那一个（技能层已定：与通用竞品并成《1b-竞品分析》的 §一 / §二两层，⛔ 不另立文档）。
|
||||
|
||||
**数量**：⛔ **不规定固定数量**。要求是「**直接竞品 ＋ 至少 1 个替代/间接方案**」，复杂项目自行加。
|
||||
|
||||
**判据**：
|
||||
- ⛔ **不许因为「名气大 / star 高 / 大家都在用」就把项目纳入竞品池** —— 纳入前必须能回答「**用户为什么会拿它和我们的产品做选择？**」
|
||||
- 点名参考实装**必须收录**，且与通用竞品**分开成两层**写。
|
||||
|
||||
---
|
||||
|
||||
## 3. 竞品用途（是什么 / 给谁用 / 干什么用）
|
||||
|
||||
**写什么**：每个竞品一小段，只答三件事 —— 它是什么形态的产品、服务谁、拿它干什么用。
|
||||
|
||||
**判据**：读完这段，**没接触过这个产品的人能说清它是干什么的**。
|
||||
⛔ 只答这三件事 —— 功能归 §5。
|
||||
|
||||
---
|
||||
|
||||
## 4. 使用场景横向对比
|
||||
|
||||
**写什么**：按**用户处境**横向铺开，⛔ **不按竞品逐个写** ——
|
||||
|
||||
```
|
||||
场景 用户要办成什么 竞品A 怎么做 竞品B 怎么做 竞品C 怎么做
|
||||
场景 1 …
|
||||
场景 2 …
|
||||
```
|
||||
|
||||
重点⛔ 不是「有 / 没有这个功能」，而是「**用户在这个场景下，它具体怎么让用户把事办成**」：
|
||||
进入方式 → 操作路径 → 核心步骤 → 系统提供什么帮助 → 最终产出 → 哪一步最省力 → 哪一步最麻烦。
|
||||
|
||||
**判据**：能描述出**用户实际使用的过程**。⛔ 只列功能名 = 未达标。
|
||||
|
||||
---
|
||||
|
||||
## 5. 功能横向对比（功能 → 解决什么问题 → 起什么作用）
|
||||
|
||||
**写什么**：先建**一组统一维度**，再横向比。维度**按产品调整**，可用：核心功能 / 辅助功能 / 输入方式 / 处理方式 / 输出方式 / 编辑能力 / 管理能力 / 协作能力 / AI 能力 / 自动化能力。
|
||||
|
||||
**每个功能必须答三问**（本档硬要求）：
|
||||
|
||||
> **是什么** → **解决什么问题** → **对用户起什么作用**
|
||||
|
||||
**判据**：
|
||||
- ⛔ 「A 有 X，B 有 Y」这种罗列 = 未达标。
|
||||
- ⛔ **不给固定字段表** —— 不同品类维度本就不同，钉死字段会让方法论失效。
|
||||
|
||||
---
|
||||
|
||||
## 6. 产品机制与交互方式
|
||||
|
||||
**写什么**：比「**为什么这么做**」。比较：核心任务流程 / 信息组织方式 / 导航结构 / 核心交互 / 默认行为 / 自动化机制 / AI 与用户的分工 / 关键反馈 / 异常处理 / 用户控制权。
|
||||
|
||||
**判据**：写的是「**它为什么这样设计、这样设计给用户带来什么结果**」；⛔ 不是「界面长什么样」。
|
||||
|
||||
---
|
||||
|
||||
## 7. 优势与不足
|
||||
|
||||
**写什么**：每个判断都落到 **能力 → 场景 → 用户价值**。
|
||||
|
||||
例：
|
||||
|
||||
> 优势：批量处理能力强；场景：一次要处理大量内容时；作用：减少重复操作；结果：更快出稿。
|
||||
|
||||
**判据**：任何「好 / 差 / 强 / 弱」都能说出**为什么**。
|
||||
⛔ 「体验很好」「设计很现代」这类**无据判断** = 未达标。
|
||||
|
||||
---
|
||||
|
||||
## 8. 竞品能力矩阵
|
||||
|
||||
**写什么**：一张横向矩阵收口 ——
|
||||
|
||||
```
|
||||
能力 / 场景 竞品A 竞品B 竞品C 机会
|
||||
… … … … …
|
||||
```
|
||||
|
||||
**判据**：矩阵不是为了「显得专业」，而是要**看得出**五件事 —— 行业共识能力 / 竞品之间的差异能力 / 某家的独有能力 / 普遍做得不好的能力 / 还没被解决好的需求。
|
||||
|
||||
---
|
||||
|
||||
## 9. 可借鉴点与产品机会
|
||||
|
||||
**写什么**：三类分开写 ——
|
||||
|
||||
1. **该借鉴**：竞品已验证有效，且与本产品目标一致。
|
||||
2. **该避开**：竞品存在明显问题，不应照搬。
|
||||
3. **可突破**：需求真实存在，但竞品解决得不够好。
|
||||
|
||||
每条给：机会点 → 对应场景 → 用户问题 → 竞品现状 → 建议方向。
|
||||
|
||||
**判据**：本节每一条都要能**追回 §4 / §5 / §7 的某一条**。⛔ 不许凭空提出机会。
|
||||
|
||||
---
|
||||
|
||||
## 10. 结论（产品层）
|
||||
|
||||
**写什么**（一律写成产品层的表述）：用户最核心的需求是什么 / 竞品共同解决了什么 / 竞品共同存在什么问题 / 哪些能力已经是基础能力 / 哪些能力还能形成差异 / 本产品应优先解决什么。
|
||||
|
||||
**判据**：结论**只落在产品层**。
|
||||
|
||||
---
|
||||
|
||||
## 附：输出检查
|
||||
|
||||
交付前逐条过。任一条为「否」⇒ **退回修改，⛔ 不交付**。
|
||||
|
||||
- [ ] 五问（用途 / 场景 / 功能 / 作用 / 优势）各有明确落点
|
||||
- [ ] 点名参考实装已收录，且与通用竞品分成两层
|
||||
- [ ] 场景对比能描述出用户实际把事办成的过程
|
||||
- [ ] 每个功能都答了「解决什么问题 / 起什么作用」
|
||||
- [ ] 优势与不足都落到「能力 → 场景 → 用户价值」
|
||||
- [ ] 可借鉴点每一条都能追回场景 / 功能 / 优势的某一条
|
||||
- [ ] 全文只围绕用途 / 场景 / 功能 / 作用 / 优势展开
|
||||
- [ ] 结论只落在产品层
|
||||
|
||||
---
|
||||
|
||||
## 变更历史
|
||||
|
||||
- **2026-10-07**：全文重写为《竞品分析方法论（1b · 产品视角）》（用户口径：讲用途 / 场景 / 功能 / 作用 / 优势）。
|
||||
新增 §0 Scope 与文末《输出检查》。改版前的英文版已退役留痕于 `_superseded-competitor-analysis-英文商业版.md`（⛔ 不再引用）。
|
||||
@@ -5,8 +5,7 @@
|
||||
> 来源：`mattpocock/skills`（MIT）的 `grilling`。上游把 `grill-me` 做成只含一句 `Call the Skill tool with "grilling"` 的 stub，在 Trae 里属于多余跳转，故合并为一个自包含 skill 并做 PM 适配。
|
||||
>
|
||||
> ⭐⭐ **2026-10-06 用户定案：「grill-me 也应该拿到第一步了，第二步就是细化功能」。**
|
||||
> 原②段另有一份 `grill-me.md`（火力点：做成什么样、状态怎么流转），**已删除并合并进本份**。
|
||||
> ⇒ **本份是全场唯一一份 grill-me**，⛔ 不许在②段再加回一份。
|
||||
> ⇒ **本份是全场唯一一份 grill-me**，A / B 两节覆盖需求与功能两轮提问。
|
||||
|
||||
## 适用位置
|
||||
|
||||
@@ -131,7 +130,7 @@ frontier 为空 = 决策树每个分支都走过、没有静默假设，且**待
|
||||
| 权限 | 谁能看、谁能改、越权怎么处理 |
|
||||
| 并发与幂等 | 同一件事被做两次会怎样、多个人同时改会怎样 |
|
||||
|
||||
> ⭐ **B 节的产出必须落进 `1a-需求文档.md`**（⛔ 不另开 `grill-decisions.md`）—— 该文件已删除（2026-10-06）。
|
||||
> ⭐ **B 节的产出落进 `1a-需求文档.md`。**
|
||||
> ⭐ **B 节问的是「做成什么样」，⛔ 不问「做成什么样好看」**：配色 / 字体 / 间距 / 动效一律不在这里问（那是③段）。
|
||||
> ⭐ **B 节的"形态与骨架"是粗粒度**：本轮只确认"有哪几页、大概几个板块"，**精确的板块清单与布局图归②段**。
|
||||
> ⛔ **不许在 B 节就把页面结构写死** —— 那会让②段的《界面布局》变成照抄。
|
||||
|
||||
@@ -35,7 +35,7 @@
|
||||
- ②段**按使用场景梳理功能**（一条场景下的功能可能**跨好几个页面**），并标优先级。
|
||||
- 反向也成立：本份某条场景**在②段一条功能都推不出来** ⇒ 这条场景是空愿望，要么补功能，要么删场景。
|
||||
|
||||
> ⛔ **不用另写一份"用户故事"**：原②段的 `user-stories.md` 已删除（2026-10-06），其内容归入本份。
|
||||
> ⭐ **本份就是用户故事** —— 一份承载全部。
|
||||
> ⛔ **不写验收标准**（那是②段功能清单的事）；⛔ **不写 Design / 交互**（那是③段）。
|
||||
|
||||
## 三、⛔ 四条硬禁令
|
||||
@@ -44,7 +44,7 @@
|
||||
|
||||
Importance / Satisfaction / Score / 优先级分数，**没有数据源就不许出现**。
|
||||
|
||||
> 来源：本项目 2026-10-02 实测 —— 机会树的 0.90/0.10/0.81 全是主观填数，且一路传到②段的 `priorities.md`。**一份自己都写"无真实数据"的文档不该占着"取证产出"的名额。**
|
||||
> 来源：本项目实测 —— 分数一旦填进去，会一路传到下游的功能优先级。**判断就写成判断，不要伪装成数。**
|
||||
> ✅ 正确写法：`【判断】我改错了回不去（依据：`1a-需求文档.md` Q1 用户原话）` —— 把来源标出来，不假装是数。
|
||||
|
||||
### ⛔ 2. 不许写"改成什么样"
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
---
|
||||
name: stage-requirements
|
||||
description: 产品规划第②段，产品功能。只做一件事：把①段《使用场景》（`1e-使用场景.md`）细化成功能清单（做哪些 / 不做哪些 / 优先级），并钉死页面骨架（《界面布局》：有哪几页、每页几个板块、板块怎么排、跨页关系）。当用户要写②段两份、列产品功能、定优先级、梳理功能、定页面与板块布局，或说"只做产品功能"时调用。⛔ 不含需求澄清与 grill 反问（那已全部归①段），不含视觉规范 / 交互 / 动效（那归③段）。
|
||||
description: 产品规划第②段，产品功能。只做一件事：把①段《使用场景》（`1e-使用场景.md`）细化成功能清单（做哪些 / 不做哪些 / 优先级），并钉死页面骨架（《界面布局》：有哪几页、每页几个板块、板块怎么排、跨页关系）。当用户要写②段两份、列产品功能、定优先级、梳理功能、定页面与板块布局，或说"只做产品功能"时调用。
|
||||
---
|
||||
|
||||
# ② 产品功能
|
||||
@@ -16,28 +16,24 @@ description: 产品规划第②段，产品功能。只做一件事：把①段
|
||||
> **与①段的分界**：**①回答「要解决什么问题、用户怎么用它」，②回答「要做哪些功能、长成什么骨架」。**
|
||||
> 判据：文档主体是**功能条目的有无与优先级、页面与板块骨架** → 归②；是**问题、用户、取证与取舍理由** → 归①。
|
||||
>
|
||||
> **⭐⭐ 2026-10-06 用户定案：本段收窄为「只细化功能」——产出从 7 份收成 2 份。**
|
||||
> **⭐⭐ 2026-10-07 用户定案：「2 产品功能 和 界面布局不就是两个文档嘛」** —— 原「两半合成一份」的写法**推翻**，
|
||||
> 两件事各成一份：**产品功能**（做什么）＋ **界面布局**（长什么样）。
|
||||
> **⭐⭐ 2026-10-06 用户定案：本段收窄为「只细化功能」。**
|
||||
> **⭐⭐ 2026-10-07 用户定案：「2 产品功能 和 界面布局不就是两个文档嘛」** —— 两件事各成一份：**产品功能**（做什么）＋ **界面布局**（长什么样）。
|
||||
> **用户原话**：「不需要 就用使用场景，其余6分都不需要了，grill 也应该拿到第一步了，第二部就是细化功能」。
|
||||
>
|
||||
> **删掉的 6 份产出**（⛔ 不许加回来，理由逐条列在文末「已删除的产出」）：
|
||||
> `prd/grill-decisions.md`｜`prd/user-stories.md`｜`prd/priorities.md`｜`prd/pre-mortem.md`｜`ux/state-machine.md`｜`ux/diagrams/*`
|
||||
> **本段就这两份**：`prd/2a-产品功能.md`（功能清单）＋ `prd/2b-界面布局.md`（页面骨架）。
|
||||
>
|
||||
> **留下的两份**：`prd/2a-产品功能.md`（功能清单）＋ `prd/2b-界面布局.md`（页面骨架）。
|
||||
> ⚠️ 原 `prd/PRD.md` **已废**（它把两件事塞在一份里）。
|
||||
> **别处的内容在本段怎么落地**：
|
||||
> - **状态流转** ⇒ 每个功能条目自带（不单独成文）
|
||||
> - **优先级** ⇒ 每条功能自己标（不单独成文）
|
||||
> - **用户故事** ⇒ ①段《使用场景》（`1e-使用场景.md`），本段按它推功能
|
||||
> - **grill / 压测** ⇒ ①段 1a（全场唯一一份 `grill-me`）
|
||||
> - **风险** ⇒ ①段《产品策略》的「假设与风险」
|
||||
>
|
||||
> **融合去哪了**：
|
||||
> - **状态机** ⇒ 整合进②段的功能清单（每个功能条目带自己的状态流转，⛔ 不再单独成文）
|
||||
> - **用户故事** ⇒ 归①段《使用场景》（`1e-使用场景.md`）（它就是用户故事）
|
||||
> - **grill / 压测** ⇒ 归①段 1a（全场唯一一份 `grill-me`）
|
||||
> - **图示** ⇒ 改名「**界面布局**」，整合进 ②段（独立成 `prd/2b-界面布局.md`）
|
||||
> - **优先级** ⇒ 进功能条目本身（每条标优先级，⛔ 不再单独成文）
|
||||
> - **事前验尸** ⇒ 删除（风险由①段《产品策略》的「假设与风险」承载）
|
||||
> （历史：本段收窄前的产出清单与其去向 → `_留痕/②段-已删除产出与方法论.md`）
|
||||
|
||||
## ⭐⭐ ②—③ 交接口（2026-10-06 用户定案，推翻旧口径）
|
||||
## ⭐⭐ ②—③ 交接口（2026-10-06 用户定案）
|
||||
|
||||
**旧口径（已废）**：②段**不给页面结构**，②定"房间"、③定"家具"。
|
||||
**口径**：**②段钉骨架，③段做皮肉。**
|
||||
|
||||
**新口径**：**②段钉骨架，③段做皮肉。**
|
||||
|
||||
@@ -104,7 +100,7 @@ description: 产品规划第②段，产品功能。只做一件事：把①段
|
||||
- **P0**：不做则①段某条使用场景**整条办不成**
|
||||
- **P1**：不做则场景**能办成但要多绕**（本可用一次点击，变成三步）
|
||||
- **P2**：不做**不影响场景办成**，只是更好用
|
||||
> ⛔ **不许用 Importance × Satisfaction / ICE / RICE 之类的分数** —— 本项目没有数据源，填出来的是主观数（机会树的 0.90/0.10/0.81 就是这么来的）。判据必须是**可复述的一句话**，不是数字。
|
||||
> 优先级判据 = **一句可复述的话**（本项目没有数据源，不填数字）。
|
||||
|
||||
### 2b 界面布局怎么写
|
||||
|
||||
@@ -156,7 +152,7 @@ description: 产品规划第②段，产品功能。只做一件事：把①段
|
||||
## 反面清单
|
||||
|
||||
- ⛔ **在本段重开一轮 grill 反问**（2026-10-06）：反问已整套前移①段 1a，本段只细化功能
|
||||
- ⛔ **产出 7 份里的任何第二份**（`grill-decisions` / `user-stories` / `priorities` / `pre-mortem` / `state-machine` / `diagrams`）—— 已删，见文末
|
||||
- ⛔ **产出本段两份之外的文档**（本段只 `2a` 与 `2b`，白名单由 `check_naming.py` 机器判）
|
||||
- ⛔ **把「产品功能」与「界面布局」又塞回一份**（2026-10-07 用户定案：这就是两个文档）
|
||||
- ⛔ **`2a` 里描述页面结构** / **`2b` 里写功能条目的有无与优先级**（越界即重写）
|
||||
- ⛔ **按页面组织功能清单**（2026-10-06）：功能要**按使用场景**组织，一条场景可跨多页；按页面组织会把跨页场景切碎，并与①段《使用场景》（`1e-使用场景.md`）对不上
|
||||
@@ -172,22 +168,10 @@ description: 产品规划第②段，产品功能。只做一件事：把①段
|
||||
- **把 `【假设】` 原样带进②段当既定事实**；或假设已被实现却从不回填状态
|
||||
- **只写"暂缓"而不给复核人 / 复核时机 / 结论落点** —— 等于让这条永远挂着
|
||||
|
||||
## 已删除的产出（2026-10-06 用户定案 · 防加回来）
|
||||
## 本段读什么、守什么
|
||||
|
||||
**用户原话**：「不需要 就用使用场景，其余6分都不需要了 grill 也应该拿到第一步了，第二部就是细化功能」。
|
||||
- **方法论两份**：`references/create-prd.md`（功能清单）、`references/state-machine.md`（**六项治理清单仍要读**，落点变成功能条目内）。
|
||||
- **绘图资产**：`assets/diagram-design/`（整树保留，供画布局图）。
|
||||
- **贯穿纪律**：**同一件事只写一遍** —— 同一批人 / 同一批场景若在①②两段各写一份，必然打架。
|
||||
|
||||
| 删掉的 | 去向 |
|
||||
|---|---|
|
||||
| `prd/grill-decisions.md` | **合并进①段** —— `references/grill-me.md` 的决策表，落点 `research/1a-需求文档.md` |
|
||||
| `prd/user-stories.md` | **归①段《使用场景》（`1e-使用场景.md`）** —— 它就是用户故事 |
|
||||
| `prd/priorities.md` | **进功能条目本身** —— 每条标 P0/P1/P2 |
|
||||
| `prd/pre-mortem.md` | **删除** —— 风险由①段《产品策略》的「假设与风险」承载 |
|
||||
| `ux/state-machine.md` | **整合进 ②段功能清单** —— 每个功能条目自带状态流转 |
|
||||
| `ux/diagrams/*` | **改名「界面布局」并整合进 ②段（独立成 `prd/2b-界面布局.md`）** |
|
||||
|
||||
> ⚠️ **同时删掉的 4 份方法论**：`references/grill-me.md`（并入①段那份）、`references/user-stories.md`、`references/prioritization-frameworks.md`、`references/pre-mortem.md`。
|
||||
> **保留的 2 份**：`references/create-prd.md`（功能清单的方法论）、`references/state-machine.md`（**六项治理清单仍要读**，只是落点变成功能条目内）、`assets/diagram-design/`（整树保留，供画布局图）。
|
||||
>
|
||||
> ⭐ **为什么删的是这几份**：它们的**内容全部有归宿**（见上表），但**每一份独立成文都会与另一份打架** ——
|
||||
> `priorities.md` 与②段的功能条目抢优先级、`user-stories.md` 与①段《使用场景》（`1e-使用场景.md`）抢同一批人、`state-machine.md` 与功能清单抢"状态挂在哪"。
|
||||
> ⇒ **本项目反复踩的坑就是"同一件事写两遍"，这次是一次性收口。**
|
||||
📎 **本段收窄前的产出清单与其去向**（含方法论去留）见 `_留痕/②段-已删除产出与方法论.md` —— 正文不展开；防复活由 `scripts/check_naming.py` 的 `DEAD_OUTPUTS` / `WHITELIST` 机器判。
|
||||
@@ -47,9 +47,7 @@
|
||||
| **P1** | 不做则场景**能办成但要多绕**（本可一次点击，变成三步） |
|
||||
| **P2** | 不做**不影响场景办成**，只是更好用 |
|
||||
|
||||
> ⛔ **禁用**：Importance × Satisfaction / Opportunity Score / ICE / RICE / 任何打分。
|
||||
> **理由**：本项目**没有数据源**，填出来的是主观数 —— 机会树的 0.90/0.10/0.81 就是这么来的，而且一路传到了功能优先级。
|
||||
> ✅ 优先级必须是**一句可复述的话**，不是数字。
|
||||
> ✅ **优先级 = 一句可复述的话**（本项目没有数据源，不填数字；数字一旦填进去，就会一路传到功能条目）。
|
||||
|
||||
### 「不做」清单（必须逐条对照，不许自行裁剪）
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
> 状态流转**整合进②段的功能清单** —— 每个功能条目自带一个「状态流转」字段。
|
||||
> 本份保留的原因是它给出的**六项治理清单**（失败恢复 / 持久化 / 并发 / 幂等 / 超时 / 不可逆二次确认）**仍要逐项覆盖**，
|
||||
> 只是**落点从 `ux/state-machine.md` 移进 `prd/2a-产品功能.md` 的功能条目内**。
|
||||
> ⛔ **旧产出 `ux/state-machine.md` 已删除，不许再加回来。**
|
||||
> ⭐ **本份只作方法论读** —— 落点是功能条目内的「状态流转」字段。
|
||||
|
||||
## 何时用
|
||||
|
||||
@@ -85,6 +85,4 @@ stateDiagram-v2
|
||||
|
||||
## 落盘
|
||||
|
||||
⛔ **不再落 `ux/state-machine.md`**（2026-10-06 该产出已删除）。
|
||||
|
||||
✅ **落点：`docs/pm/<项目>/prd/2a-产品功能.md` 的功能清单内** —— 每个功能条目自带一个「状态流转」字段，按上表格式写；无状态的功能写"无状态"。
|
||||
@@ -44,6 +44,9 @@
|
||||
3. **历史记录按时间倒排** —— **新的在前面，旧的在后面**（⛔ 追加只能往前插，⛔ 不许接在末尾）。
|
||||
4. **简明扼要有效** —— **单条 ≤6 KB**；⛔ 论证过程／对比表格／逐条展开全删；
|
||||
⚠️ 但**判据要点一个不许丢**（长度达标而判据被删 = **更坏**，那是假绿）。
|
||||
5. 🔴 **只写正向范围，⛔ 不写「不用于 XXXX」**（2026-10-07 用户令）
|
||||
—— 规则正文在 **`rules.md §9`**（⛔ 只一处，本行只作指针）。一句话：技能/文档的"用途／范围"段
|
||||
一律写**用于什么**；列"不用于 A／B／C"会**把 A／B／C 喂进自动匹配面** ⇒ 反而更容易被误命中。
|
||||
|
||||
## 三、🔴 为什么「存档」不等于「读得到」（10-04 实证）
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
# manifest · 包内文件清单
|
||||
|
||||
> 生成方式：逐文件 `compile()` / `json.loads` ＋ md5 ｜ **最近一次全量重算：2026-10-07 08:15 （加载闸门：派活族不受冷却 ＋ 冷却跳过留痕（含新判据））**
|
||||
> 生成方式：逐文件 `compile()` / `json.loads` ＋ md5 ｜ **最近一次全量重算：2026-10-07 20:30 （修三处陈旧指针（旧技能名 dsh-decision / agent-operating-rules 与旧路径编号））**
|
||||
> ⚠️ **2026-10-05 局部增量**：`references/pitfalls.md`（P0-77 拆条 ＋ P0-73/P0-77 压缩）与
|
||||
> `scripts/goalctl.py`（`--switch-goal` 确认闸 ＋ 旧目标归档）两行的 md5/大小已按当天实测值更新；**其余行仍是 10-04 基线**。
|
||||
> ⛔ 本表**不含** `install.log`（运行日志）与 `references/manifest.md`（自引用，写完即失真）。
|
||||
@@ -120,7 +120,7 @@
|
||||
| `assets/design-tokens.css` | 6364 | `0668feb3a4729f1022e579ac0c5d2569` | — |
|
||||
| `install.py` | 37297 | `55603c2e739e7b531998f5563f15f789` | ok |
|
||||
| `references/00-动手前必过.md` | 7181 | `33bc86e442ccd4fcbb930c79c4ad0641` | — |
|
||||
| `references/01-文档索引.md` | 4159 | `ea4185d568b94d7aa915f84f259b9773` | — |
|
||||
| `references/01-文档索引.md` | 4518 | `f401dd36b2d30cbc89ac91f9d633b72c` | — |
|
||||
| `references/02-功能优先协作协议.md` | 35529 | `9122a6715bde02ab549805d69866d1cf` | — |
|
||||
| `references/03-回复排版-核心块.md` | 7766 | `01277367d560383669ad493538e45587` | — |
|
||||
| `references/04-决策方法论.md` | 35566 | `eb5bdf8f100beb8eacb9f20b042df86c` | — |
|
||||
@@ -138,8 +138,8 @@
|
||||
| `references/karpathy-output-ladder/references/ladder-workflow.md` | 2684 | `d49840707d19302d8f61f4e1d7f4ea2e` | — |
|
||||
| `references/karpathy-output-ladder/references/ste100.md` | 3022 | `fdbe3271c21a3c17f326d1e71de33b0d` | — |
|
||||
| `references/pitfalls.md` | 311254 | `d321a71e38dd246b8014b4c9100b12c7` | — |
|
||||
| `references/rules.md` | 8106 | `95af3566066d27c3c224ce681a82efc1` | — |
|
||||
| `references/supervise-persistence.md` | 34783 | `3c68c146984133449b8bd6a1240909f1` | — |
|
||||
| `references/rules.md` | 9218 | `a8fd1e616600defb724fa64af67a7348` | — |
|
||||
| `references/supervise-persistence.md` | 34799 | `d18d44d36fd939924f7d5752b7c2be40` | — |
|
||||
| `references/taskgraph.md` | 3521 | `be6c6540be86475bb3430688c2987afc` | — |
|
||||
| `references/作业规矩/00-作业总规矩（原 agent-operating-rules）.md` | 70243 | `80fc5471015b237ee7aacd6976eda6fe` | — |
|
||||
| `references/作业规矩/02-工作区纪律.md` | 21351 | `1a679fdeb9cca0883a47f619d1aec85d` | — |
|
||||
@@ -150,9 +150,9 @@
|
||||
| `scripts/board-launch.py` | 2794 | `998a66b9d335ab1863b5b871a527bf4f` | ok |
|
||||
| `scripts/board.py` | 146111 | `d90395d1f1a7c3f94419a33cdf444384` | ok |
|
||||
| `scripts/board_ext.py` | 45655 | `2319fb9d2d21bf961e03a42da9a1ad4b` | ok |
|
||||
| `scripts/collabctl.py` | 28124 | `827fe07da25b86b773a3f701e86db351` | ok |
|
||||
| `scripts/collabctl.py` | 32007 | `1c597185be099821c7b1d6dc66fadb05` | ok |
|
||||
| `scripts/collabd.config.example.json` | 1158 | `6655c15c411a84e3ca12fd136dbe2c60` | ok |
|
||||
| `scripts/collabd.py` | 434710 | `00bded98f6c49fa30881434df168642e` | ok |
|
||||
| `scripts/collabd.py` | 434806 | `d4350022bbd75f37a35db63fa0472f88` | ok |
|
||||
| `scripts/deliver-gateway-token.py` | 5685 | `cbba9648d404ecd2683061e19dbdb24a` | ok |
|
||||
| `scripts/deploy_code.py` | 5325 | `a79cf5e5ffb3e8c60a31b4d0d8845f40` | ok |
|
||||
| `scripts/forensics/proc-parent.py` | 2347 | `8cdfff2dbb88303298752c3777da7b20` | ok |
|
||||
@@ -163,10 +163,10 @@
|
||||
| `scripts/hooks/decision-rules-hook.py` | 12399 | `c521237bada7487aecf5e54ad4d19ace` | ok |
|
||||
| `scripts/hooks/lock-guard-hook.py` | 20363 | `641457de0297ee7a812ccde57f67dc2b` | ok |
|
||||
| `scripts/hooks/prompt-guards.py` | 9332 | `0aa1d1fdd2bf5a40cda2e60d7a785534` | ok |
|
||||
| `scripts/hooks/reply-style-guard.py` | 11040 | `7e271b342f91e2e98cbc03631b7e68f3` | ok |
|
||||
| `scripts/hooks/reply-style-guard.py` | 11283 | `1e52b65f279c0b4df70bb53bc613a774` | ok |
|
||||
| `scripts/hooks/session-log-guard.py` | 24636 | `4dd13b24d541d1afc7b4874dba6bb1eb` | ok |
|
||||
| `scripts/hooks/skill-load-guard.py` | 27515 | `d544387152d9140380484d046051c023` | ok |
|
||||
| `scripts/hooks/stop-dialog-guard.py` | 46083 | `fab654dfacfeb6253fc751707bebcac6` | ok |
|
||||
| `scripts/hooks/skill-load-guard.py` | 29994 | `2450b93b4bac87cf9e99697703efa78f` | ok |
|
||||
| `scripts/hooks/stop-dialog-guard.py` | 51240 | `3e0791e42f41c37438601a9d2314dd8e` | ok |
|
||||
| `scripts/hooks/supervise-ensure-hook.py` | 14308 | `dc6f62584a8384baba0a1f2460828013` | ok |
|
||||
| `scripts/hooks/wb-result-hook.py` | 37199 | `2d4f694acd031222bf03b98a859b6e90` | ok |
|
||||
| `scripts/init_workspace.py` | 24042 | `dda53acd24bcc66d509bbdab3ebc0488` | ok |
|
||||
@@ -177,7 +177,7 @@
|
||||
| `scripts/lock/op-lock.sh` | 4690 | `1a31eda3642e23693a65e1519860c744` | — |
|
||||
| `scripts/lock/preflight-lock.sh` | 8673 | `e985ec1cb853fae4c351cd03b171355d` | — |
|
||||
| `scripts/mut_run.py` | 13323 | `3bffc12e1e57d5efc743bac55e584b62` | ok |
|
||||
| `scripts/selftest.py` | 488379 | `9f5d2f8d1888866c8a7a590e2471d85c` | ok |
|
||||
| `scripts/selftest.py` | 490245 | `8cb5187bd927ecdecb216a6df4d855c4` | ok |
|
||||
| `scripts/session-rules-check.py` | 44412 | `b2b468992d80421106316eaf451e2477` | ok |
|
||||
| `scripts/stop-collab.py` | 10462 | `d8043bedd23b52b6642aaf7ec8b8c980` | ok |
|
||||
| `scripts/supervise-launch.py` | 2503 | `f416a2f197e5524a8859c1d227ba1d05` | ok |
|
||||
|
||||
@@ -76,3 +76,16 @@
|
||||
- ⛔ **反例（10-05，同一件事栽到第四次）**：常驻的起法只写在当天日志里 ⇒ 之后每一轮都重新折腾一遍、每一轮都得出同样的结论。
|
||||
✅ 正解：结论**同时**落三处 —— `SKILL.md` 第一屏（会被读）＋ `pitfalls.md` 一条（有来龙去脉）＋ 本档一条规矩（约束以后怎么写）。
|
||||
- 🔴 **配套**：凡"换会话容易忘、忘了就会重来"的结论，**优先放第一屏**，⛔ 不要塞进长文档。
|
||||
|
||||
## 9 🔴 只写正向范围，⛔ 不写「不用于 XXXX」（2026-10-07 用户令）
|
||||
|
||||
**技能与文档的「用途／范围」段一律写"用于什么"**，⛔ 不列"不用于 A／B／C"。
|
||||
|
||||
- **为什么（机制性，不只"占地方"）**：技能的 `description` 与首屏是**自动匹配面**（技能靠描述匹配被加载）
|
||||
⇒ 在里面列"不用于 X"，等于**把 X 这些词喂进匹配面** ⇒ **反而更容易被不该命中的请求选中**
|
||||
（实测形态：`draw-ui` 描述里列了「不用于普通插画／海报／故事板」⇒ 用户说"做个海报"时它更可能被选上）。
|
||||
- **例外（用户 2026-10-07 明确给出）**：**经验沉淀可以写"如何避免踩坑"** ——
|
||||
禁令**不删**，但写成「**正向目标 ＋ 依据（曾栽过什么）**」的形态
|
||||
（例：「本方法只出产品视角」＋「曾因照英文商业框架产出而跑偏」）。
|
||||
- ⛔ **别与"事实陈述"混**：「配置里不含本工作区」「该目录不含 `board.py`」是在**描述事实**，
|
||||
不在本条管辖内 —— 一刀切会把它们误删。
|
||||
@@ -374,7 +374,7 @@ $p = Get-Process -Id <pid> -ErrorAction SilentlyContinue # $null = 已死
|
||||
|
||||
## 六、⚠️ 还没有它就不算长期（两条，别自欺）
|
||||
|
||||
1. **静默基准**：检查会话要 `静默 ≥ 10 分钟` 才建（🔴 **2026-10-07 由 20 改 10**，用户原话
|
||||
1. **静默基准**：检查会话要 `静默 ≥ 6 分钟` 才建（🔴 **2026-10-07 两度调整：20 → 10 → 6**，用户原话
|
||||
「把检查程序的等待时间由 20分钟 改为 10分钟」；阈值＝`collabd.py::CHECK_IDLE_MIN`，闸门与 `--dry-run` 试算同源）。
|
||||
基准＝**本工作区排期的 `updated_at` 最大值**（`_last_progress_ts()`）；
|
||||
⚠️ 本行原先写「基准取台账 `tasks.json` 的 mtime」——**那句与代码不符**，已按代码订正。
|
||||
|
||||
@@ -2067,7 +2067,8 @@ TASK_EVENTS = INBOX / "tasks-events.jsonl" # 只作审计（append-only，⛔
|
||||
TO_MAIN = INBOX / "TO-MAIN.md" # 投递给主会话的通知（投影 · 供人/AI 直接读）
|
||||
TASK_STATES = ("pending", "running", "done", "blocked") # 需求台账四态：待执行/执行中/已完成/有阻碍
|
||||
QUEUE_IDLE_MIN = 5 # 唤醒**限流桶**（分钟）：同一状态下最多每 **5** 分钟发一次（2026-09-30 用户拍板：30→10→**5**）；⛔ 触发条件是 supervise() 的**四条件**（不是计时器）
|
||||
CHECK_IDLE_MIN = 10 # 🔴🔴 2026-10-07 用户拍板：**20 → 10 分钟**（原话「把检查程序的等待时间由 20分钟 改为 10分钟」）
|
||||
CHECK_IDLE_MIN = 6 # 🔴🔴 2026-10-07 用户两度拍板：**20 → 10 → 6 分钟**
|
||||
# 原话一：「把检查程序的等待时间由 20分钟 改为 10分钟」；原话二：「检查程序的等待时间改为6分钟」（当日 18:25）。
|
||||
# 「检查程序」判"已经静默够久、可以建检查会话"的阈值（`queue-empty` 那条闸）。
|
||||
# ⚠️ 改这个数必须**一起改三处**，否则文案与判据打架：
|
||||
# ① 本常量（闸门 `maybe_spawn_check_agent()` ＋ `--dry-run` 试算都读它）；
|
||||
@@ -4316,14 +4317,14 @@ CHECK_PROMPT_RESULT = (
|
||||
+ _CHECK_TAIL_A + _CHECK_TAIL_B
|
||||
)
|
||||
|
||||
# 【目标检查】—— 队列**空**且静默 >10 分钟时：核对目标完成状态（阈值＝`CHECK_IDLE_MIN`，2026-10-07 由 20 改 10）
|
||||
# 【目标检查】—— 队列**空**且静默 >6 分钟时：核对目标完成状态（阈值＝`CHECK_IDLE_MIN`，2026-10-07 由 20 改 10）
|
||||
CHECK_PROMPT_GOAL = (
|
||||
"**【目标检查会话 · 第 %d 棒】**本轮只做这一件事：**核对目标完成状态**，**做完即停**。\n"
|
||||
"\n"
|
||||
"目标：%s\n"
|
||||
"\n"
|
||||
"## 一、为什么是你（🔴 触发条件已满足，不必重判）\n"
|
||||
"**所有会话都已结束** ＋ **队列为空** ＋ **已静默 ≥10 分钟** ＋ **本项目没有别的待执行排期**。\n"
|
||||
"**所有会话都已结束** ＋ **队列为空** ＋ **已静默 ≥6 分钟** ＋ **本项目没有别的待执行排期**。\n"
|
||||
"\n"
|
||||
"## 二、🔴 先读这五样，⛔ **只读这五个文件**，读完直接判断（⛔ 别到处找信息）\n"
|
||||
"> ⚠️ **不要在本工作区里到处翻文件**：2026-10-03 实测，检查会话因无边界地找资料\n"
|
||||
@@ -4569,7 +4570,7 @@ def artifacts_unverifiable() -> list:
|
||||
|
||||
|
||||
def _last_progress_ts() -> float:
|
||||
"""**最近一次有实质进展的时刻**（epoch 秒）—— 判「静默够久没」（阈值 `CHECK_IDLE_MIN`，现 10 分钟）的基准。
|
||||
"""**最近一次有实质进展的时刻**（epoch 秒）—— 判「静默够久没」（阈值 `CHECK_IDLE_MIN`，现 6 分钟）的基准。
|
||||
|
||||
🔴 取「本工作区排期的 `updated_at` 最大值」；读不到 ⇒ 判**刚有过活动**（0）
|
||||
⇒ ⛔ 不建（fail-safe：宁可少建，不误判成"已静默够久"）。
|
||||
|
||||
@@ -20,7 +20,9 @@
|
||||
🔴 三条设计判据（本需求的关键，⛔ 都别改）
|
||||
──────────────────────────────────────────
|
||||
1. **真相源在技能里**（不在本文件、也不在某个工作区）：
|
||||
`<技能库>/agent-operating-rules/references/回复排版-核心块.md`
|
||||
`<技能库>/session-mechanism/references/03-回复排版-核心块.md`
|
||||
⚠️ 2026-10-07 订正：原写 `<技能库>/agent-operating-rules/references/回复排版-核心块.md` ——
|
||||
该技能**已于 2026-10-06 整包并入 `session-mechanism`**，旧路径已不存在（属「指针陈旧」族）。
|
||||
⇒ 技能是**跨工作区**的 ⇒ 一次改动，**所有会话**都跟着变。
|
||||
⛔ **绝不在本文件里写死规则文本** —— 写死就变成第二真相源，两边必然漂。
|
||||
2. **每轮都注入，⛔ 不设冷却**：这条规矩的价值就在"紧贴用户消息、每轮重述"。
|
||||
|
||||
@@ -116,6 +116,7 @@ COOLDOWN = 300 # 同会话注入冷却（秒
|
||||
# 起因（用户令逐字）：「**重点问题是 会话接收到 调用执行会话完成目标 没有去调用对应技能去执行**」——
|
||||
# 本钩子原来**只注入提醒**，AI 照不照做没人管；实测会话 `b232218f` 里用户连说三遍，一次都没拉起执行会话。
|
||||
DISPATCH_REL = os.path.join('.workbuddy', '.dispatch-pending')
|
||||
LOAD_REL = os.path.join('.workbuddy', '.load-pending')
|
||||
_DISPATCH_WORDS = ('使用执行会话', '使用任务会话', '执行会话完成', '任务会话完成',
|
||||
'调用执行会话', '调用任务会话', '派任务会话', '建任务会话')
|
||||
|
||||
@@ -156,13 +157,15 @@ TRIGGERS = (
|
||||
# 命中词 → 该加载哪个技能（2026-09-22 加：从"只会推决策技能"扩为按命中词分流）
|
||||
# 🔴 2026-10-02 修：本行原写 `dsh-decision-method`，而它**已于 2026-09-28 合并退役**
|
||||
# ⇒ 注入文本让人去加载一个**不存在的技能**（找得到才怪 ⇒ 规则仍不进上下文；属静默失效族）。
|
||||
# 现名 `dsh-decision`，两档全文：`references/00-决策方法论.md`（原 decision-method）
|
||||
# ／ `references/01-功能优先协作协议.md`（原 feature-first，含 §5.1 结论骨架 ＋ §5.4 排版硬约束）。
|
||||
# 🔴 2026-10-07 再修：`dsh-decision` **已于 2026-10-06 整份删除**（实体早已搬入本包），
|
||||
# 且上面那句写的路径编号也错了 ⇒ 两档实体**现在就在本包**：
|
||||
# `references/04-决策方法论.md`（原 decision-method）
|
||||
# ／ `references/02-功能优先协作协议.md`（原 feature-first，含 §5.1 结论骨架 ＋ §5.4 排版硬约束）。
|
||||
_LOAD_RULES = ('按规则来', '按规则做', '按作业规则', '遵守规则', '按规矩来',
|
||||
'回复排版', '执行结果排版', '回复格式', '怎么回复', '排版')
|
||||
|
||||
# ── 分组 3 的词 → 加载 `session-mechanism`（2026-10-05 加）─────────────────────
|
||||
# 与 `_LOAD_RULES`（→ agent-operating-rules）并列的第三条路由。
|
||||
# 与 `_LOAD_RULES`（该技能已于 2026-10-06 整包并入本包）并列的第三条路由。
|
||||
# 🔴 为什么单列一族：这三族**目标技能不同**，⛔ 不能混在一个 if 里 ——
|
||||
# 命中"使用任务会话完成目标"的人，要的是**会话机制本体**（怎么建排期／怎么派活／
|
||||
# 自决策白名单在 `references/02-功能优先协作协议.md`），⛔ 不是决策方法论。
|
||||
@@ -171,6 +174,17 @@ _LOAD_SESSION = ('使用任务会话', '使用执行会话', '使用协作会话
|
||||
'会话技能', '会话机制', '创建任务会话', '建任务会话',
|
||||
'派任务会话', '任务会话', '执行会话', '协作会话', '多会话')
|
||||
|
||||
# 🔴🔴 2026-10-07 「点名族」＝ TRIGGERS 里**除派活族外的全部**（决策方法族 ＋ 作业规则/排版族）。
|
||||
# 用途：命中任意一个 ⇒ 写 `<ws>/.workbuddy/.load-pending` 待办，交给 `stop-dialog-guard.py`
|
||||
# 做**收工前自检**（本会话到底有没有真的 `Skill` 加载过本技能）。
|
||||
# 起因（用户令逐字）：「**问题是 会话没有加载决策方法，之前的优化改动无效**」——
|
||||
# 实测（`content_marketing_agent` 那条会话的闸门日志）：
|
||||
# `20:09:45 HIT … hits=决策方法` **注入确实发出了**，可会话**仍未去加载**；
|
||||
# ⇒ 根因＝**本钩子只"注入提醒"，没有任何东西核对 Skill 到底调没调**（与"派活触发句"同族洞）。
|
||||
# ⛔ **不许再抄一份词表** —— 从 `TRIGGERS` 里**减**出来，否则加词时两处必然漂移。
|
||||
_LOAD_WORDS = tuple(w for w in TRIGGERS
|
||||
if w not in _LOAD_SESSION and w not in _DISPATCH_WORDS)
|
||||
|
||||
|
||||
def _read_stdin():
|
||||
try:
|
||||
@@ -270,6 +284,33 @@ def _mark_dispatch(workdir, sid, prompt, hits):
|
||||
pass
|
||||
|
||||
|
||||
def _is_load(prompt):
|
||||
"""本轮是不是**点名族**（点名方法／规则／排版）。与 `_is_dispatch` 并列，⛔ 别各写一遍。"""
|
||||
try:
|
||||
seg = re.sub(r'\s+', '', prompt or '')
|
||||
return any(w in seg for w in _LOAD_WORDS)
|
||||
except Exception:
|
||||
return False
|
||||
|
||||
|
||||
def _mark_load(workdir, sid, prompt, hits):
|
||||
"""命中「点名族」⇒ 写一条待办（TSV：会话 id / 时间戳 / 命中词），交给收工闸核。
|
||||
|
||||
判据（收工闸会核）：**本会话有没有真的 `Skill` 加载过 `session-mechanism`**。
|
||||
⚠️ 与 `_mark_dispatch` 同规矩：**写在冷却判定之前**（重复点名常被冷却吞掉，写完才有痕迹）。
|
||||
⛔ 全程 fail-open。
|
||||
"""
|
||||
try:
|
||||
if not _is_load(prompt):
|
||||
return
|
||||
with io.open(os.path.join(_norm_path(workdir), LOAD_REL),
|
||||
'w', encoding='utf-8', newline='\n') as f:
|
||||
f.write('%s\t%.3f\t%s\n' % (sid, time.time(), ','.join(hits)))
|
||||
_log(workdir, 'LOAD_PENDING sid=%s hits=%s' % (sid[:8], ','.join(hits)))
|
||||
except Exception:
|
||||
pass
|
||||
|
||||
|
||||
def _cooling(workdir, sid):
|
||||
"""同一会话 COOLDOWN 秒内不重复注入。"""
|
||||
try:
|
||||
@@ -326,14 +367,15 @@ def main():
|
||||
|
||||
# 🔴 先留待办（⛔ 必须在冷却之前，见 `_mark_dispatch` 注释）
|
||||
_mark_dispatch(workdir, sid, prompt, hits)
|
||||
_mark_load(workdir, sid, prompt, hits)
|
||||
|
||||
# 🔴🔴 2026-10-07 两处改（用户问「有什么影响 该如何处理」时落的）：
|
||||
# ① **派活族显式触发句不受冷却** —— 那是最明确的一类"要动作"，被 300 s 吞掉最亏。
|
||||
# ① **派活族 ＋ 点名族都不受冷却** —— 它们都是"用户明确点名"的一类，被 300 s 吞掉最亏。
|
||||
# 实测：会话 `b232218f` 里 01:32:00 命中后，01:33:46（105 s，最明确的那句）
|
||||
# 被冷却吞掉、**连日志都没有**。
|
||||
# ② **被冷却跳过也要留一行**（`COOL_SKIP`）—— 否则"没命中"与"被吞"在日志上分不出来，
|
||||
# 排查时只能靠状态文件时间戳旁证反推（上一次就是这么反推的）。
|
||||
if _cooling(workdir, sid) and not _is_dispatch(prompt):
|
||||
# 被冷却吞掉、**连日志都没有**；同型复现在 `content_marketing_agent` 的「决策方法」上
|
||||
# （20:09:45 注入 → 20:09:54 重复点名被 COOL_SKIP）。
|
||||
# ② **被冷却跳过也要留一行**（`COOL_SKIP`）—— 否则"没命中"与"被吞"在日志上分不出来。
|
||||
if _cooling(workdir, sid) and not (_is_dispatch(prompt) or _is_load(prompt)):
|
||||
_log(workdir, 'COOL_SKIP sid=%s hits=%s（冷却中，本轮不注入）'
|
||||
% (sid[:8], ','.join(hits)))
|
||||
return
|
||||
|
||||
@@ -710,6 +710,95 @@ def _dispatch_gate(payload):
|
||||
return True
|
||||
|
||||
|
||||
# ── 🔴🔴 2026-10-07 「点名了机制却没加载」闸 ────────────────────────────────────
|
||||
# 起因（用户令逐字）：「**问题是 会话没有加载决策方法，之前的优化改动无效**」。
|
||||
# 实测（`content_marketing_agent` 那条会话的闸门日志）：
|
||||
# `20:09:45 HIT … hits=决策方法` ⇒ **注入确实发出了**；可会话**仍未去加载**
|
||||
# ⇒ 根因＝`skill-load-guard.py` **只"注入提醒"，没有任何东西核对 `Skill` 到底调没调**。
|
||||
# 形态：命中「点名族」时它写 `<ws>/.workbuddy/.load-pending`（会话/时间/命中词），
|
||||
# 本闸在**收工前**核一次：**同会话 ＋ 未过期 ＋ 转录尾部里没有"真的 `Skill` 加载过本技能"** ⇒ 拦一次。
|
||||
# ⛔ 三条安全底线：① 全程 fail-open（读不到转录 = 判"不确定" ⇒ **放行**）；② 只拦一次（复用 10 分钟限流）；
|
||||
# ③ 待办 15 分钟过期。⛔ 只读转录**尾部**（1.5 MB），绝不整读（有 200 MB 级的转录）。
|
||||
LOAD_REL = os.path.join('.workbuddy', '.load-pending')
|
||||
LOAD_GRACE = 60 # 命中后给 60 秒去加载（⛔ 不拦"刚说完、还没轮到"）
|
||||
LOAD_EXPIRE = 900 # 待办最长存活 15 分钟
|
||||
LOAD_TAIL_BYTES = 1500000 # 只看转录最后 1.5 MB（足够覆盖"刚被点名"的那几轮）
|
||||
LOAD_REASON = (
|
||||
'⛔ **收工前自检：用户点名了机制问题（决策方法／作业规则／排版），但这条会话没有真的加载过它。**\n'
|
||||
'你点名的那些判据**不在你的记忆里**，就在技能包里 —— 先调用 Skill 工具加载 `session-mechanism`，再收工。\n'
|
||||
'⚠️ **提醒 ≠ 加载**：本机制的钩子只会"注入一句提醒"，⛔ 它拦不住你直接干活；\n'
|
||||
' 实测栽过（`content_marketing_agent`）：20:09:45 已注入「决策方法」提醒，会话却始终没去加载\n'
|
||||
' ⇒ 用户原话「**会话没有加载决策方法，之前的优化改动无效**」。'
|
||||
)
|
||||
|
||||
|
||||
def _has_skill_load(tp):
|
||||
"""转录尾部里有没有『**真的** Skill 加载过本技能』。
|
||||
|
||||
返回 True／False／**None**（读不到 ⇒ 不确定 ⇒ 调用方放行，fail-open）。
|
||||
⚠️ 转录里技能名被**转义引号**包着：`"arguments":"{\\"skill\\": \\"session-mechanism\\"}"`
|
||||
（⛔ 按普通引号匹配必然全不命中 —— 本项目 2026-10-07 实测踩过这个假阴性）。
|
||||
"""
|
||||
if not tp or not os.path.isfile(tp):
|
||||
return None
|
||||
try:
|
||||
with open(tp, "rb") as f:
|
||||
try:
|
||||
f.seek(0, 2)
|
||||
size = f.tell()
|
||||
f.seek(max(0, size - LOAD_TAIL_BYTES))
|
||||
except OSError:
|
||||
f.seek(0)
|
||||
raw = f.read().decode("utf-8", "replace")
|
||||
except Exception:
|
||||
return None
|
||||
for pat in (r'\\"skill\\":\s*\\"session-mechanism\\"',
|
||||
r'\\"command\\":\s*\\"session-mechanism\\"',
|
||||
r'"skill":\s*"session-mechanism"',
|
||||
r'"command":\s*"session-mechanism"'):
|
||||
if re.search(pat, raw):
|
||||
return True
|
||||
return False
|
||||
|
||||
|
||||
def _load_gate(payload):
|
||||
"""见上面那段注释。返回 True ＝ 已发出阻拦 ⇒ 调用方**直接 return**。"""
|
||||
try:
|
||||
ws = str(payload.get('cwd') or '') or \
|
||||
(os.environ.get('CODEBUDDY_PROJECT_DIR') or os.environ.get('DSH_WORKSPACE') or '')
|
||||
if not ws:
|
||||
return False
|
||||
p = os.path.join(_norm_path(ws), LOAD_REL)
|
||||
if not os.path.isfile(p):
|
||||
return False
|
||||
parts = (io.open(p, encoding='utf-8').read().strip().split('\t') + ['', '', ''])[:3]
|
||||
sid_m, ts_s, hits = parts
|
||||
sid_now = str(payload.get('session_id') or '')
|
||||
if not sid_now or sid_m != sid_now: # ⛔ 不是本会话的待办 ⇒ 不碰
|
||||
return False
|
||||
ts = float(ts_s or 0)
|
||||
age = time.time() - ts
|
||||
if age > LOAD_EXPIRE: # 过期 ⇒ 作废
|
||||
os.remove(p)
|
||||
return False
|
||||
if age < LOAD_GRACE: # 刚说完、还没轮到 ⇒ 放行
|
||||
return False
|
||||
got = _has_skill_load(str(payload.get('transcript_path') or ''))
|
||||
if got is None: # 读不到转录 ⇒ 不确定 ⇒ 放行
|
||||
return False
|
||||
if got: # 已经加载过 ⇒ 待办销账
|
||||
os.remove(p)
|
||||
return False
|
||||
except Exception:
|
||||
return False # ⛔ fail-open
|
||||
root = _norm_path(ws)
|
||||
if _rate_limited(root, sid_now): # 同一会话 10 分钟最多拦 1 次
|
||||
return False
|
||||
log(root, 'load-gate 命中：点名了机制但本会话未加载（hits=%s｜待办 %.0fs）' % (hits, age))
|
||||
_emit({'continue': False, 'reason': LOAD_REASON})
|
||||
return True
|
||||
|
||||
|
||||
def main():
|
||||
raw = _read_stdin_text() # ⚠️ 必须走 buffer：`-E` 下 sys.stdin 是 cp936（见 _read_stdin_text 注释）
|
||||
payload = None
|
||||
@@ -729,6 +818,9 @@ def main():
|
||||
# ⛔ 它只在"本工作区确实有本会话的派活待办"时才可能生效，其余情形一次都不触发。
|
||||
if _dispatch_gate(payload):
|
||||
return
|
||||
# 🔴🔴 2026-10-07 「点名了机制却没加载」闸 —— 同样放在自作用域判定之前（同上理由）。
|
||||
if _load_gate(payload):
|
||||
return
|
||||
if not _in_scope(tp): # 作用域外 → 放行
|
||||
return
|
||||
if os.environ.get('DSH_STOP_GUARD_OFF'): # 急停（环境变量）→ 放行
|
||||
|
||||
@@ -797,7 +797,7 @@ def t_two_kinds_of_check_agent():
|
||||
用户原话两条：
|
||||
1、会话全结束（**还要加上 定时任务中没有本项目待执行的任务**）且**队列不为空** ⇒
|
||||
**结果检查会话**去跟进任务会话执行结果，判断是否创建对应任务会话继续完成目标；
|
||||
2、会话全结束（同上）且**队列为空 >10 分钟** ⇒ **目标检查会话**去核对目标完成状态，
|
||||
2、会话全结束（同上）且**队列为空 >6 分钟** ⇒ **目标检查会话**去核对目标完成状态，
|
||||
判断是建任务会话还是**修改目标状态**，并执行。
|
||||
|
||||
⇒ 改前**两套 prompt 完全共用一个模板** ⇒ 结果检查会话拿到了"改目标状态"的出口（越权），
|
||||
@@ -7358,12 +7358,38 @@ def t_skillguard_cooldown():
|
||||
src = (HERE / "hooks" / "skill-load-guard.py").read_text(encoding="utf-8", errors="replace")
|
||||
return [
|
||||
("有共用的 `_is_dispatch()`（⛔ 别在两处各写一遍判定）", "def _is_dispatch(" in src),
|
||||
("冷却旁路在：`_cooling(...) and not _is_dispatch(...)`",
|
||||
"_cooling(workdir, sid) and not _is_dispatch(prompt)" in src),
|
||||
("冷却旁路在：`_cooling(...) and not (_is_dispatch(...) or _is_load(...))`",
|
||||
"_cooling(workdir, sid) and not (_is_dispatch(prompt) or _is_load(prompt))" in src),
|
||||
("被跳过写 `COOL_SKIP`（⛔ 否则「没命中」与「被吞」分不出来）",
|
||||
"COOL_SKIP" in src),
|
||||
]
|
||||
|
||||
|
||||
@case("⛔ 点名了机制却没加载：注入之外还要有「收工前自检」抓手")
|
||||
def t_load_gate():
|
||||
"""🔴 2026-10-07 立（用户令逐字：「**问题是 会话没有加载决策方法，之前的优化改动无效**」）。
|
||||
|
||||
实测（`content_marketing_agent` 的闸门日志）：`20:09:45 HIT … hits=决策方法` ⇒ **注入确实发出**，
|
||||
可会话**仍未去加载** ⇒ 根因＝注入只是"劝"，**没有任何东西核对 `Skill` 到底调没调**。
|
||||
两处处置：① 点名族命中即写 `<ws>/.workbuddy/.load-pending`；
|
||||
② `stop-dialog-guard.py` 收工前核「转录尾部里有没有**真的** Skill 加载过本技能」。
|
||||
⚠️ 源码级判据（跑真钩子会动到真工作区的状态，⛔ 不适合进回归套）。
|
||||
"""
|
||||
a = (HERE / "hooks" / "skill-load-guard.py").read_text(encoding="utf-8", errors="replace")
|
||||
b = (HERE / "hooks" / "stop-dialog-guard.py").read_text(encoding="utf-8", errors="replace")
|
||||
return [
|
||||
("点名族词表从 `TRIGGERS` **减**出来（⛔ 不另抄一份：`_LOAD_WORDS = tuple(...)`）",
|
||||
"_LOAD_WORDS = tuple(w for w in TRIGGERS" in a),
|
||||
("命中即写待办 `LOAD_PENDING`（⛔ 写在冷却之前）",
|
||||
"LOAD_PENDING" in a and "_mark_load(" in a),
|
||||
("收工闸在：`_load_gate(payload)` 已接进 main，且在自作用域判定之前",
|
||||
"def _load_gate(" in b and "if _load_gate(payload):" in b),
|
||||
("判据认**转义引号**那种编码（⛔ 普通引号匹配 ＝ 恒假阴性）",
|
||||
'\\\\"skill\\\\":\\s*\\\\"session-mechanism' in b),
|
||||
("只读转录**尾部**（⛔ 不整读，有 200 MB 级转录）", "LOAD_TAIL_BYTES" in b),
|
||||
("读不到转录 ⇒ 判「不确定」放行（fail-open）", "got is None" in b),
|
||||
]
|
||||
|
||||
|
||||
if __name__ == "__main__":
|
||||
sys.exit(main())
|
||||
Reference in new issue
Block a user