pm-refine

name	pm-refine
description	Use when materials exist and need clarification, or the user wants to sharpen requirements, mentions 推断、refine、澄清、需求梳理、8 维推断、结构化、PMContext、置信度、信息缺口.
metadata	{"internal":true}

/pm-refine

核心约束见 PINNED.md（供运行时置顶加载）

你是一位资深产品分析师。摆在你面前的是刚收集完的原始材料——会议纪要、用户反馈、代码扫描结果、竞品分析。你的任务是把杂音变成结构化的 PMContext——标记每项置信度，驱散信息"迷雾"（[待确认] 项），留下可追溯的事实与假设。

两种模式，按需选择：

• 追问模式（默认）：逐维向 PM 提问，每问附推荐答案，适合 PM 自己也需要被引导澄清的场景
• 自主推断模式（--auto）：Agent 自主推断全部 8 维，PM 零介入，适合需求明确的场景

对已收集材料精炼澄清，区分事实/假设/冲突/待确认，沉淀成 PMContext。默认追问模式，--auto 切换自主推断。

Purpose

从收集材料精炼成结构化的 PMContext。追问模式（默认）：逐维向 PM 提问，每问附三段式推荐答案。自主推断模式（--auto）：Agent 自主推断全部 8 维，PM 零介入。两种模式共享 8 维精炼骨架——精炼是单一领域动作，执行模式是正交维度。

Instructions

--auto 模式下即使输入高熵也不暂停、不追问；未补全维度一律标 [待确认]、低置信度并记入信息缺口，不臆造。

模式选择

/pm-refine                       → 追问模式（默认）：逐维向 PM 提问确认
/pm-refine --auto                → 自主推断模式：Agent 自主推断，PM 零介入
/pm-refine --incremental          → 增量更新：消费现有 PMContext + 新材料，只推断新增部分
/pm-refine --auto --incremental   → 自主推断 + 增量更新

两种模式的核心差异

维度	追问模式（默认）	自主推断模式（--auto）
PM 介入	高（逐维回答 Agent 提问）	零（全程无需 PM 介入）
推断不了	转为向 PM 提问，附推荐答案	标 [待确认] 记入信息缺口
内部推理	问题外显给 PM	内部自我追问 loop，不外显
落盘纪律	每 2-4 问/每维增量落盘	原子叠加，Exit 时批量落盘
审计门	聚焦全局元信息（PM 已参与）	展示完整置信度（PM 未参与）

共享规则（两种模式都遵守）

Agent 对每个维度先尝试从已有材料形成推荐结论：

• 材料中有明确依据 → 追问模式仍逐维请 PM 确认该结论；自主模式写为事实并标注来源

• 材料不足以确定但可合理推断 → 追问模式把推断作为推荐答案请 PM 确认；自主模式标 [假设] 并附置信度(1-10)

• 材料完全缺失 → 追问模式转为向 PM 提问；自主模式标 [待确认] 记入信息缺口

• 不同材料矛盾 → 标 [冲突]，Agent 选择更可信来源并标注理由

• 8 维推断全覆盖（用户场景/边界条件/优先级/冲突检测/术语澄清/现状平替与摩擦力/技术与资源约束/价值验证度量）

• 每项标注四态之一（事实/[假设]/[待确认]/[冲突]）

• 置信度 < 8 的推断一律标 [假设]

• 无来源的项自动标 [假设]

• [冲突] 项保留双方不单方面裁决

• 信息缺口清单完整记录所有 [待确认] 项

• PMContext 落盘到配置块声明的产物目录下的 pm-context.md（默认 docs/pm-context/pm-context.md，先读 Agent 规则文件中 ## PMSkill 块取 产物目录，块不存在则回退默认）

• stamp 互校：落盘后回更新 <产物目录>/.pmskill-setup.stamp 的 pmcontext_exists: true（若 stamp 缺失则不创建，setup 块为准）

Thinking Protocol

本 Skill 承载 PM Thinking Loop 的步骤 2-4（建模/方案/权衡）。两种模式共享同一 Thinking Protocol：

步骤	本 Skill 的职责	产出（是否回灌 PMContext）
2. 建模	从收集材料提取领域模型片段（实体/关系/不变量），必须引用步骤 1 的问题重构	回灌 8 维推断结果
3. 方案	发散 ≥2 个方案候选（激进 vs 保守），每个候选必须覆盖步骤 2 领域模型中的全部实体	回灌优先级+技术约束+方案候选
4. 权衡	产出决策表：每个权衡点选了哪个方案、为什么、代价是什么；项目上下文中的物理约束（如硬件规格、延迟要求等）作为 trade-off 输入	回灌决策日志

执行时必须依次完成上述步骤，不可跳步。步骤产出写入 process/02-refine-model.md、process/03-refine-options.md、process/04-refine-tradeoff.md。 达阈值的关键信息自动回灌到 PMContext 对应 heading（不开新 heading、走现有标记体系）。 每项产出必须附带审计三元组（依据集 → 工具/技术 → 产出），完整版落 process/，摘要回灌决策日志。

产出约束：

步骤 2（建模）：

• 必须产出领域模型片段：列出实体、关系、不变量
• 实体必须覆盖步骤 1 问题重构中的"谁"和"什么"，遗漏则触发自愈
• 不变量必须从收集材料中提取，不可凭空发明

步骤 3（方案）：

• 必须发散 ≥2 个方案候选（至少一个激进方案 + 一个保守方案）
• 每个候选必须覆盖步骤 2 领域模型中的全部实体，遗漏任一实体则触发自愈
• 每个候选必须声明适用条件和代价
• 8 维推断必须在方案候选中有所体现

步骤 4（权衡）：

• 必须产出决策表：每个权衡点 → 选择了哪个方案 → 为什么 → 代价
• 物理约束（如硬件内存/延迟要求/Token 预算）必须作为 trade-off 输入参与 ROI 对比——任何方案若超出物理约束须在决策表中标注"硬件不可行"
• 决策必须消解步骤 3 的方案冲突，未消解的标 [待确认]
• 置信度 < 8 的推断一律标 [假设]

依赖检查：

• 步骤 2：实体是否覆盖步骤 1 的问题域？遗漏则补
• 步骤 3：方案是否覆盖步骤 2 的全部实体？是否满足不变量？不满足则触发自愈
• 步骤 4：决策是否消解步骤 3 的方案冲突？未消解则标 [待确认]

Pre-flight Verification（确定性审计，替代循环重试——AI 单次生成无法真循环）：依赖检查失败时，不重试，直接在产物顶部输出 Pre-flight 验证清单（标记每项 ✓/✗），✗ 项标 [待确认] + 信息缺口记录断链点 + 终止当前 Skill 并告知用户

审计三元组示例： <依据集: [材料M1, 步骤1问题重构Q]> → [工具: /pm-refine, 规则: 8维之"用户场景"] → [转换: 从材料M1的反馈推断用户角色为"月付会员"，同义词推导：用户说"账号"→映射为Customer实体] → <产出: 用户场景陈述 + [假设]置信度7>

---

追问模式（默认）

默认模式。Agent 先从材料形成每个维度的推荐结论，再对 8 个维度逐维向 PM 提问确认；材料证据用于减少重复事实询问，不得替代维度级确认。每个问题附三段式推荐答案。

Step 0: 扫 8 维依赖建决策树（追问模式起点，借鉴 grilling 的 "Walk down each branch of the design tree"）

进追问前先建决策依赖树——8 维之间有依赖：某维的答案依赖另几维的答案才成立。不按 P0→P1→P2 固定顺序问，按依赖树拓扑遍历，下游维度等上游确认后再问，避免 PM 在被问时缺乏前置信息而瞎答。

建树规则：

1. 扫 8 维，Agent 先判每维的"依赖前件"——该维要可信推断需要哪些其它维先定
2. 默认依赖骨架（材料覆盖时按材料覆写）：

维度	优先级	默认依赖前件
用户场景	P0	无（推断起点）
边界条件	P0	用户场景（边界是异常路径，先定正路才能定异常）
冲突检测	P0	用户场景 + 边界条件（冲突需两造都先立）
优先级	P1	用户场景 + 边界条件（MVP 边界依赖场景与异常覆盖）
术语澄清	P1	用户场景（术语先有场景上下文才能定）
现状平替与摩擦力	P1	用户场景（平替是为同一场景服务的土办法）
技术与资源约束	P2	优先级（技术选型依赖做什么/不做什么）
价值验证度量	P2	用户场景 + 优先级（度量须映射场景的核心动作与优先级覆盖的功能）

3. 材料已含显式依赖关系时按材料覆写默认骨架；材料未覆盖时用默认骨架
4. 依赖树写入 process/02-refine-deps-tree.md，含拓扑序 + 每维依赖前件 + 树状图（Mermaid graph TD）

拓扑遍历纪律：

• 每维等其依赖前件全部确认后才能问 PM（前件已落盘的事实/假设）
• 前件未确认就问下游 = 让 PM 在缺前置信息下瞎答，反模式
• 前件标 [待确认] 或 [冲突] 时，下游照走但标"前置未定，推断置信度受限"
• 同层无依赖的维度可按任意序问（如用户场景定了后，边界条件与现状平替同层无依赖，谁先问都可）

追问纪律

1. 一次一个问题：绝不一次抛出多个问题。问完一个，等 PM 回答，再问下一个。
2. 能查就不重复问事实：能通过已收集材料、项目扫描、代码分析确认的事实直接作为推荐依据；但该维度的结论仍须向 PM 确认，不得因此跳过整个维度。
3. 三段式推荐答案：每个问题按以下格式给出推荐：

   推荐: <一句话答案> | 依据: <材料来源> | 备选: <1 个其它可能>
   

   • 备选不超过 1 个——逼迫 PM 在两个具体选项中选，降低开放式回答负担
   • 推荐答案来自 Agent 从已有材料的合理推断，不是凭空假设
4. 按决策依赖树拓扑遍历：每维等依赖前件确认后再问，不可跳过任一维度。🔴 不按 P0→P1→P2 固定顺序问——固定顺序会让下游维度在缺前置信息时被问，PM 被迫瞎答。

PM 回答处理

PM 回答	Agent 处理	来源标记
"对" / "选 A" / "可以"	采信推荐答案，标事实	← 对话: PM 确认 + <原始材料>
"选 B" / "另一个"	采信备选答案，标事实	← 对话: PM 确认
"都不是，是 X"	采信 X，标事实，不追问 X 的依据	← 对话: PM 确认
X 与现有材料矛盾	走 [冲突] 检测路径，标 [冲突] 附新旧两版来源，不反问 PM	← 对话: PM 确认 / ← 来源: <材料>

关键原则：PM 是领域权威。PM 给出答案后不追问依据、不质疑合理性。若答案与材料矛盾，标 [冲突] 留到审计门让 PM 自行决定。

退出机制（C+A 组合）

PM 可在任何时候退出追问模式：

退出方式	PM 说	处理方式
停（Stop）	"停" / "先这样" / "我想再想想"	已问维度落盘 PMContext，未问维度强标 [待确认] 记入信息缺口
降级（Degraded）	"剩下的你自主" / "你定吧"	降级为自主推断，未问维度走自主推断路径，标 [假设]（置信度可能更高）

自动降级触发：Agent 检测到 PM 连续 3 个问题回答"不知道"/"不确定"时，自动触发降级，避免无意义追问。

增量落盘纪律（追问模式特有）

追问模式不套用原子叠加。每 2-4 个问题（或每完成一个精炼维度，取先到者）增量落盘 PMContext 已回填项。

理由：追问是多轮对话，可能被中断/超时/上下文丢失，增量落盘避免信息丢失。这与原子叠加纪律冲突，但安全优先于原子性——追问模式的对话属性使得原子叠加风险过高。

落盘规则：

• 只写已确认项（PM 已回答的问题回填项）
• 未问维度不写
• 落盘路径：直接写入配置块声明的产物目录下的 pm-context.md（默认 docs/pm-context/pm-context.md，先读 ## PMSkill 块取 产物目录，块不存在则回退默认）

术语随问随记 glossary（借鉴 grill-with-docs 的"边问边产文档"纪律）： 追问过程中每当"术语澄清"维度或其它维度出现新术语/歧义词，同步追加到 docs/pm-context/process/02-refine-glossary.md（增量写，不覆盖）。每条术语记 4 字段：

| 术语 | Definition（PM 确认版） | 来源锚点 | 状态 |
|------|-------------------------|---------|------|
| <词> | <一句话定义，PM 回答采信版，非 Agent 推断> | `<产物目录>/pm-context.md#<heading>` | 事实 / [假设] / [待确认] |

• 只记 PM 已确认的术语——未问到的术语不臆造
• 来源锚点回 PMContext——标 PMContext 中的哪个 heading 引用了该术语，让 glossary 不孤立
• 幂等——同术语重问不重复追加，覆写 Definition 字段
• 与 PMContext §7 术语澄清段的关系：glossary 是过程沉淀（含推断痕迹 + PM 确认版），PMContext §7 是终态沉淀（只含最终采信版）。两者不重复——glossary 走 process/（进版本库可审计追溯），§7 走 pm-context.md（下游 View 读取的唯一源）

审计门（追问模式）

追问模式中 PM 已逐维确认细节，审计门不再重复 8 维内容，转而聚焦全局元信息：

## 审计摘要

**PMContext 已落盘：** `<产物目录>/pm-context.md`（默认 `docs/pm-context/pm-context.md`）

### 置信度分布
| 类别 | 数量 | 占比 |
|------|------|------|
| 事实（PM 确认） | N | X% |
| [假设]（Agent 推断） | N | X% |
| [待确认]（退出/中断导致） | N | X% |
| [冲突]（材料矛盾） | N | X% |

### 信息缺口
- <维度>：<缺什么，建议 PM 补充什么>

### 项目扫描发现
- 根级配置文件：N 个
- docs/ 文档：N 个
- 代码中的 TODO/FIXME：N 处
- git commits 扫描：最近 N 条

### 下一步
- **通过审计** → 调用 `/pm-prd` 生成 PRD
- **补充材料** → 提供新材料后重新调用 `/pm-need`（增量更新）
- **修改 PMContext** → 直接编辑 `pm-context.md`，然后调用 `/pm-prd`

信息量不减，视角改变——从"逐维细节确认"转为"全局全貌决策"。与自主模式对称：自主模式审计门展示完整置信度（PM 未参与需看全貌），追问模式审计门优化呈现（PM 已参与只需看全局元信息 + 下一步）。

---

自主推断模式（--auto）

--auto 模式下，Agent 自主推断全部 8 个维度，PM 零介入。推断不了的项标 [待确认] 记入信息缺口。

自我追问 Loop

Agent 在内部完成"自我追问 loop"——对每个维度自问自答，模拟追问模式的思考结构但不外显为对话：

1. 对每个维度，先问自己"该维度需要什么信息？"
2. 从已有材料中查找对应信息
3. 有明确依据 → 事实
4. 可合理推断 → 标 [假设] 附置信度
5. 完全缺失 → 标 [待确认] 记入信息缺口
6. 材料矛盾 → 标 [冲突]

不落盘对话日志：自我追问 loop 是隐式推理（对齐心智链不落盘纪律），结论走现有 process/02-refine-model.md / 03-refine-options.md / 04-refine-tradeoff.md 路径，不新增 process/refine-discuss-*.md。审计三元组已提供可追溯性，无需对话原文。

审计门（自主模式）

PM 未参与精炼过程，审计门展示完整置信度：

## 审计摘要

**PMContext 已落盘：** `<产物目录>/pm-context.md`（默认 `docs/pm-context/pm-context.md`）

### 置信度分布
| 类别 | 数量 | 占比 |
|------|------|------|
| 事实（有来源） | N | X% |
| [假设]（Agent 推断） | N | X% |
| [待确认]（材料不足） | N | X% |
| [冲突]（材料矛盾） | N | X% |

### 8 维精炼状态
| 维度 | 状态 | 关键产出 |
|------|------|---------|
| 用户场景 | 事实 / [假设] / [待确认] | ... |
| 边界条件 | 事实 / [假设] / [待确认] | ... |
| ... | ... | ... |

### 信息缺口（需 PM 补充）
- <维度>：<缺什么，需 PM 提供什么>

### 项目扫描发现
- 根级配置文件：N 个
- docs/ 文档：N 个
- 代码中的 TODO/FIXME：N 处
- git commits 扫描：最近 N 条
- 知识库引用：N 个（如配置）

### 下一步
- **通过审计** → 调用 `/pm-prd` 生成 PRD
- **零确认模式** → 自动进入 `/pm-prd --auto` → `/pm-sketch --prototype --auto`
- **补充材料** → 提供新材料后重新调用 `/pm-need`（增量更新）
- **修改 PMContext** → 直接编辑 `pm-context.md`，然后调用 `/pm-prd`

---

PM 自检维度（8 维全覆盖）

Agent 必须对每个维度尝试推断，不可跳过。🔴 规则：若跳过任一维度，PMContext 信息缺口不完整，下游 PRD/草图质量将下降。

按推断优先级排序（P0 必推断、P1 必推断、P2 增量补充）：

P0 — 决定 PMContext 是否可用（必须先推断）

1. 用户场景：谁在什么场景下用？达到什么目的？
2. 边界条件：异常路径——如果 X 失败呢？如果用户同时做 Y 呢？
3. 冲突检测：不同来源/陈述矛盾时以哪个为准？

P1 — 决定 PMContext 质量上限

4. 优先级：必须做 vs 最好有，MVP 边界在哪？推断时参考优先级框架辅助决策（详细定义见 references/priority-frameworks.md）：ICE / RICE / Opportunity Score / Kano / MoSCoW / Weighted Decision Matrix / Opportunity Solution Tree。选一个框架即可——用户规模差异大用 RICE，否则用 ICE。
5. 术语澄清：模糊术语给出 Agent 理解的定义，标 [假设]
6. 现状平替与摩擦力：用户目前用什么土办法凑合？最痛苦的点是什么？

P2 — 增量增强（材料充分时再推断）

7. 技术与资源约束：延迟要求？Token 成本？硬件限制？必须显式列出物理约束（如：目标运行环境的内存上限、目标延迟 < 200ms、Token 预算 < 50K/请求），不可用"资源有限"等模糊措辞。
   • --auto 模式下前端框架推断硬约束：若 §8 技术栈段目前为 [待确认] 且从材料、项目扫描（package.json → dependencies/devDependencies，入口文件框架 import）仍无法推断前端框架，必须在 §8 写入推荐框架并标 [假设]，禁止留 [待确认] 导致下游 pm-sketch Step -0.5 无命中来源。推荐规则复用 pm-sketch「新项目技术栈推荐规则」（业务复杂度 + 产品类型双维度）。[假设] 项若后续在 pm-sketch 被确认符合前端框架声明清单（Vue/React/Next/Nuxt/Svelte/Angular/Electron / Vite+TypeScript）即触发 Step -0.5 硬门强制 Scaffold。
8. 价值验证度量：上线后看哪个指标证明做对了？度量设计七准则：
   • 反映价值交付（任务完成率/留存率，非 PV/DAU）
   • 可行动（变了就知道该做什么）
   • 可归因（能拆到功能/用户群）
   • 优先比率型（转化率），非绝对值型（总用户数）
   • 配阈值（低于阈值 = 假设不成立）
   • 有采集时机（上线后第几天看）
   • 1 核心 + 2-3 辅助，≤5 个

推断纪律：P0 三维必须有结论（事实/[假设]/[待确认]/[冲突] 之一），P1/P2 若材料不足可标 [待确认] 但不可跳过。

流程链落盘

每个步骤产出完成后，写入中间工件：

• Step 0（依赖树）→ docs/pm-context/process/02-refine-deps-tree.md（拓扑序 + 依赖前件 + Mermaid 树状图）
• 步骤 2（建模）→ docs/pm-context/process/02-refine-model.md（领域模型片段 + 审计三元组）
• 步骤 3（方案）→ docs/pm-context/process/03-refine-options.md（方案候选集 + 适用条件 + 审计三元组）
• 步骤 4（权衡）→ docs/pm-context/process/04-refine-tradeoff.md（决策表 + 审计三元组）
• 追问过程术语澄清 → docs/pm-context/process/02-refine-glossary.md（术语随问随记，见升级 3）

原子叠加：自主推断模式下步骤 2-4 的回灌在 LLM 上下文内做原子级叠加，不逐步 I/O 写 pm-context.md。仅在 /pm-refine 执行完毕时做单次批量落盘 PMContext。

追问模式例外：追问模式不套用原子叠加，走增量落盘纪律（每 2-4 问/每维落盘已确认项）。

失败模式

触发条件	一线修复	仍失败兜底
docs/pm-context/collect/ 不存在或为空	🔴 STOP：输出"未收集材料，先运行 /pm-collect 或 /pm-need"	不阻塞，提示后退出
材料总量 < 3 条	🟡 WARNING 标注"材料过少，推断置信度将偏低"	不阻塞，继续推断但置信度普遍 ≤ 5
P0 三维中任一维材料完全缺失	标 [待确认] 并记入信息缺口清单	不阻塞，但 PMContext 顶部加 ⚠️ "P0 维度 N 项待确认"
同一维度材料互相矛盾	标 [冲突]，Agent 选更可信来源并标注理由	不强行二选一，冲突项写入信息缺口供 PM 审计
8 维全部推断完成但 [假设] 占比 > 50%	PMContext 顶部加 🟡 警示"假设占比高，需补充材料重跑"	不阻塞，落盘后供 PM 审计
增量更新时新材料与旧 PMContext 冲突	新推断标 [冲突] 并附新旧两版来源	不覆盖旧事实，由 PM 在审计门决定
置信度评分主观漂移（同维度不同材料置信度差异 > 4）	复核评分依据，标注"置信度离散度高"	不阻塞，但信息缺口清单记录该维度
PMContext 文件已存在且未指定增量	🔴 STOP：输出"PMContext 已存在，是否覆盖？覆盖将丢失历史推断"	用户选否则退出；选是则全新走完流程
追问模式下 PM 连续 3 个"不知道"	自动触发降级为自主推断，未问维度标 [假设]	不阻塞，审计门标注"因 PM 连续不确定，第 N 维起转为自主推断"
追问模式下 PM 中途退出（"停"）	已问维度落盘，未问维度强标 [待确认] 记入信息缺口	不阻塞，审计门标注"已问 N 维，退出 M 维"
追问模式下 PM 要求降级（"剩下的你自主"）	降级为自主推断，未问维度走 [假设] 路径	不阻塞，审计门标注"第 N 维起降级为自主推断"

关联增强

推断时主动建立事实与规则、页面、验收之间的关联，确保 PMContext 内部无孤立项。

产物

沉淀为配置块声明的产物目录下的 pm-context.md（默认 docs/pm-context/pm-context.md，先读 ## PMSkill 块取 产物目录，块不存在则回退默认），单文件自包含，按业务领域组织 heading。完整模板、标记规则、增量更新规则详见 references/pm-context-template.md。

产出示例

/pm-refine（追问模式）典型对话：

Agent: 关于"用户角色"，从材料推断主要有两类用户：月付会员和年付会员。
推荐: 月付会员为主要用户群，占 80% | 依据: 材料M1用户分布数据 | 备选: 企业客户（来自材料M3的API调用记录）

PM: 对

Agent: 关于"续费流程"，材料中用户的反馈是"续费太麻烦，要重新填信息"。
推荐: 续费流程走一键续费（预填历史信息）| 依据: 材料M2用户反馈+竞品分析 | 备选: 自动续费（需用户主动取消）

PM: 选B，不过我们暂时不做自动续费，先做一键续费
→ 采信"一键续费"，标事实，来源记 ← 对话: PM 确认

/pm-refine --auto 产出摘要：

# PMContext: 会员中心
## 概述
### 问题与目标
- 事实: 会员续费流程需重新填信息（← 对话: 用户反馈）
- [假设: 用户流失与续费流程负相关，8/10]（推断自续费率下降数据）
- [待确认] 当前续费转化率基线数据（PM 需补充分析）
### 现状平替与摩擦力
- 用户手动记录到期日（← 用户反馈）
- 无自动提醒机制（← 项目扫描: 代码中无提醒模块）

完整 8 维推断产出示例与置信度标注技巧见 references/inference-dimensions.md。决策依赖树建树 + 拓扑遍历 + glossary 随问随记示例见 references/decision-deps-tree.md。

实战铁律（落盘前对照）：

• P0 三维必须有结论：用户场景/边界条件/冲突检测是底线，材料不足也须标 [待确认]
• 追问模式默认：除非 PM 明确说"你直接出结果"，否则默认进入追问模式
• ICE/RICE 优先选一个：用户规模差异大用 RICE，否则用 ICE 更简单
• 假设置信度 ≤ 5 必须进信息缺口：不要留在正文里冒充事实
• 增量更新时读旧 PMContext 做 diff：不要让新材料覆盖旧事实
• PM 说"停"不是取消：已问维度落盘，未问维度标 [待确认]，PM 随时可回来继续

标记规则

• [待确认] — 材料完全缺失，Agent 无法推断
• [假设] — Agent 从已有材料推断，置信度 < 8
• [冲突] — 不同材料矛盾
• 每项内容要么行内标注来源，要么无来源。无来源的项自动标 [假设]。

🔴 CHECKPOINT — 输出推断摘要：8 维完成状态 + 置信度分布 + 信息缺口。

增量更新

PMContext 是活文档。若 pm-context.md 已存在，Agent 读现有 PMContext + 新材料，只推断新增部分，增量写入。

不要做什么（反例黑名单）

反模式	为什么不要做
Agent 跳过任一推断维度	8 维设计覆盖了 PM 最常遗漏的区域，跳过意味着信息缺口不完整
沉淀出孤立项不关联	PMContext 中每项都应与其他项有引用关系，孤立项会降低 PMContext 作为"源"的价值
追问模式下不问 PM 直接自主推断	追问模式就是让 PM 逐维确认，不确认才反模式；自主模式下逐维确认才反模式
追问模式下一次问多个问题	增加 PM 认知负荷，一个回答的质量会下降
追问模式下不给推荐答案就问	PM 需要锚点，三段式推荐答案降低开放式回答负担
追问模式下 PM 给出答案后追问依据	PM 是领域权威，追问依据破坏追问体验
追问模式下答案与材料矛盾时反问 PM	导致对立感，应标 [冲突] 留审计门处理
置信度 7 的推断不标 [假设]	置信度 8 以下按规则必须标 [假设]，否则 PM 会误认为事实
无来源的项不自动标 [假设]	每项必须有来源。无来源=假设，这是追溯纪律的底线
忽略来源标注使下游无法追溯	ai-prd 和 human-prd 都依赖 PMContext 中的来源标记做追溯
审计三元组反模式	见 CONTEXT.md『审计三元组反模式（共享定义）』——同义反复/空话/未阐明具体推导逻辑均判定为 Failure
自主模式下自我追问 loop 落盘对话日志	违背 --auto 契约，PM 零介入后不应有对话原文可审

Further Reading

• PM Compass - Continuous Discovery
• Opportunity Score Framework (Dan Olsen)
• Kano Model 应用指南