Product Manager

---
name: product-manager
description: 站在产品经理视角完成四类工作。M1 需求定义：编排 requirement-mining 与 negative-requirement，一次成型产出需求报告（含负向场景），免去手动逐个调用与反复细化。M2 产品体验走查：对已实现的产品做体验走查，找出可优化点并按 Kano + 价值×成本排优先级。M3 缺失功能推演：从代码推演产品还缺什么功能，带证据分级防臆造。M4 界面视觉走查：对前端页面做视觉与体验检查，按能力探测自动降级（自动截图 / 请用户上传截图 / 静态源码推演）。当用户提出功能想法要出需求、说"站在产品/PM 角度看看"、"这个产品还能优化什么"、"还缺什么功能"、"看看这个页面/界面怎么样"、"帮我体验一下这个产品"、"产品评审"、"pm 评审"时使用。
disable: false
---

# 产品经理（product-manager）

## 概述（AI 说明层）

**目的**：解决"提个功能要先手动点名调需求分析、再点名调负向分析、最后自己拼报告"的编排成本，以及"产品做完了没人站在产品视角看它还能往哪长"的空白。本 skill 让 AI 直接以产品经理身份接管编排与判断。

**功能**：
- **M1 需求定义**：编排 `requirement-mining` + `negative-requirement`，默认一次成型档自主补全假设与负向场景，只留 1 个确认点
- **M2 产品体验走查**：对已实现产品做六维体验走查，产出可优化点清单 + Kano 分类 + 优先级
- **M3 缺失功能推演**：从代码推演产品缺失功能，证据三级制（`🟢` 代码实证 / `🟡` 结构可证 / `🔴` 推断）防臆造
- **M4 界面视觉走查**：前端页面视觉与体验检查，四档能力探测自动降级，无画面时引导用户上传截图而非假装看过
- 四类产出统一为一份 PM 报告：结论 → 证据 → 优先级 → 建议下一步

**使用场景**：
- 用户提出一个功能想法，想直接拿到一份完整需求报告（不想手动调 skill）
- 用户说"站在产品经理角度看看这个产品""体验一下这个功能""这个产品还能优化什么"
- 用户说"从代码看看这个产品还缺什么功能"
- 用户说"看看这个页面/界面怎么样""这个界面有什么问题"
- 用户说"产品评审""PM 评审""/pm"

---

## 核心立场：什么是"产品经理视角"

AI 天然会滑向它更熟的视角。执行前先对齐：

| 维度 | 产品经理视角（本 skill） | 极易滑向（且是错的） |
|------|------------------------|---------------------|
| 提问 | 这东西**该不该做、还该往哪长** | 这段代码写得对不对（`code-review`） |
| 对象 | 用户价值、关键路径、商业目标 | 代码结构、设计模式、性能常数（`artifact-optimizer`） |
| 判定 | 达成目标了吗 / 还缺什么 / 值多少 | 达标 or 不达标（`acceptance-verify`） |
| 输出 | 机会清单 + 优先级 + 下一步建议 | 缺陷清单 + 修复方案 |
| 证据 | 界面实测 > 代码实证 > 结构可证 > 推断 | 把推断当结论 |

> **一句话**：`acceptance-verify` 回答"这一版做完了没有"，本 skill 回答"**下一版该做什么**"。

---

## 运行契约

| 项 | 内容 |
|---|---|
| **WHEN** | 用户提功能想法要需求；或对已实现产品说"体验/优化/缺什么/界面怎么样" |
| **SEE** | M1：一句话功能描述；M2/M3：项目代码或可运行产品；M4：前端页面（URL / 源码 / 截图） |
| **DO** | 模式路由 → 按模式采集证据 → PM 视角判断 → 优先级排序 → 出报告 |
| **CHECK** | 每条结论挂证据等级；`🔴` 不得进结论区；优先级必须有 Kano 分类与价值×成本评分 |
| **STOP** | 报告出完即停。不自动改码、不自动实施（实施交 `request-guard` → `code-review`）；M1 下游按报告推荐行动走 |

---

## 模式路由

| 模式 | 触发信号 | 前提高危检查 |
|------|---------|-------------|
| **M1 需求定义** | 提功能想法、要需求报告、"分析下这个需求" | Step 0 误判筛查（实为 Bug / 已有功能） |
| **M2 产品体验走查** | "体验一下""还能优化什么""产品评审" | 必须有可运行产品或完整代码，否则转 M3 |
| **M3 缺失功能推演** | "还缺什么功能""从代码推演" | 只给代码、产品跑不起来时走本模式 |
| **M4 界面视觉走查** | "看看这个页面""界面怎么样""UI 有问题吗" | 无前端产物时明确告知并转 M3 |

**组合规则**：一次任务里执行的**所有**模式（M2 / M3 / M4 任意组合）合并成**一张**清单，用 `来源` 列区分「体验优化 M2 / 缺失功能 M3 / 界面问题 M4」，禁止出多张打架的表。M4 既是 M2 的取证手段，也可单独触发。

**何时不使用本 skill**：

| 用户其实想要 | 该用 |
|-------------|------|
| 重新设计界面 / 出视觉方案 / 写 HTML demo | `ui-designer` |
| 把设计稿转成 ASCII 存档 | `ui-to-ascii` |
| 确认"这一版达标没有"（按验收指标逐条判） | `acceptance-verify` |
| 代码/设计文档/skill 本身的质量优化 | `artifact-optimizer` |
| 看懂这个模块怎么实现的 | `module-teach` |
| 用具体场景沿代码推演"终态对不对" | `scenario-rehearsal`（代码模式） |
| 跑通一条端到端流程验证正确性 | `e2e-testing` |
| 修一个具体 Bug | `debug` |
| 只改几行代码看改动对不对 | `code-review` |

> 边界模糊时按"用户想要的是**下一版做什么**还是**这一版对不对**"判断：前者本 skill，后者上表。

---

## 公共规则（四模式通用）

1. **证据三级制**：`🟢` 实证（运行观察、截图、**代码明确写法**）／`🟡` 静态可证（配置/结构间接推断）／`🔴` 推断。**`🔴` 一律只进「待确认清单」，不得进结论区，必须配验证方法**。这是本 skill 最大的翻车点——把猜测当结论。
   > **产品经理懂代码**：对「有没有做 / 是否符合要求」类判定，**代码直读即 🟢 一手证据**，与运行实测同级、且更快更准，**不是**跑不起来时的退路。只有「体验顺不顺 / 界面好不好看」类判定，代码才降为 `🟡`（有分支 ≠ 呈现对）。
   > **第四态 `⚪ 未发现`**：表示"本次没查到"，与三级制并列但不同义（见「关联功能与影响评估」）——不得把"没查"写成"推断"。
2. **不臆造现状**：现状来自用户描述 / 读代码确认 / `⚠️ AI 推断（挂假设 ID）`，三者必标其一。
3. **只判断不改码**：本 skill 不修改产品代码。M2/M3/M4 只出清单与建议，实施走 `request-guard` → `code-review`。
4. **优先级统一口径**：一律 Kano 分类 + 价值×成本矩阵（见 `reference.md` 第一节）。不给无依据的精确数字（如"提升转化 12%"）。
5. **最小化交互**：自主推理优先。默认只留 1 个确认点（关键假设 / 模式与范围）。
6. **落盘**：默认直接输出报告到对话。项目配置了 `.requirements/` 时 M1 报告按 `requirement-doc-store` 落盘并注册；M2/M3/M4 仅在用户要求时落 `.pm/{slug}-{YYYYMMDD}.md`。
7. **资产复用**：分析前调用 `use_skill("expert-solution-workflow")` 查已有经验/解决方案/记忆；未命中则自主推理。
8. **证据声明必备**：每份报告开头必须写「证据声明：最高证据等级 + **取证方式**（代码直读 / 运行实测 / 用户上传截图 / 静态推演）+ 降级说明」；**组合模式取所有模式中的最低档**，不得让 M2 的实测掩盖 M4 的推断。注意"代码直读"是 `🟢`，**未运行 ≠ 证据不足**（见下节）。
9. **报告形态两档**：默认完整报告；用户说"简单说""只要结论""几句话"时出**轻量档**——只给执行摘要 + 优先级 Top3 + 一句下一步，≤30 行。
10. **取证先问"这个判定需要画面吗"**：符合性判定 → 代码直读；体验/视觉判定 → 实测或请用户上传截图。不得一律要求跑起来，也不得用代码推断体验。
11. **影响面必查**：M1/M2/M3 执行前先做「关联功能与影响评估」（见下节；M4 可轻量、单独执行时可填 `-`）；报告必含影响评估表，**"影响是否可接受"由用户拍板**，AI 只负责找全、说清、给选项。

---

## 取证手段：代码直读 vs 实测

产品经理**看得懂代码**，代码是产品实现的一手证据。选手段前先判**判定类型**：

| 判定类型 | 代码直读 | 运行/画面实测 | 说明 |
|---------|---------|--------------|------|
| **符合性**：有没有做 / 是否符合要求（"导出是异步的吗""删除有二次确认吗""错误文案带原因吗"） | `🟢` **首选，最快最准** | `🟢` 可复核 | 代码即事实，为此逼用户起服务是浪费 |
| **体验**：顺不顺、几步、反馈是否及时 | `🟡` 只能证"分支存在" | `🟢` | 有 loading 分支 ≠ 用户真看得到（可能被条件挡住/样式缺失） |
| **视觉**：对齐、层级、美观、响应式 | `🔴` 不可用（明确样式值除外） | `🟢` 必须看画面 | 代码推不出观感 |
| **存在性**：功能/分支有无（M3） | `🟢` | - | 见 M3 三条证据路径 |

**代码直读四步**：
1. 把要求拆成**可判定的检查项**（"异步"→ 是否有队列/后台任务/进度查询接口）
2. 定位候选位置（grep 关键词 → 路由/组件/服务层）；**同类入口必须穷举成清单再判**——只查一处就下结论会漏掉绕过风险（前端有确认、接口没有）
3. 逐项给出判定：符合 / 不符合 / 部分符合 + **`file:line` 证据**
4. 代码看不出（依赖运行时配置、跨服务）→ 标 `🟡` 或进待确认，**不硬判**

**适用信号**：用户问"是不是 / 有没有 / 是否符合 + 一条具体要求" → 直接读代码，不必先跑起来。

---

## 关联功能与影响评估（M1 / M2 / M3 前置）

提需求、提优化之前，先回答两件事：**这个改动会碰到谁？碰到了能不能接受？** 只描述新功能本身、不提它碰到什么，是产品工作最常见的翻车点。

**四类关联来源**（逐类过，防漏）：

| 类别 | 要找什么 |
|------|---------|
| 同对象的其他操作 | 增删改查、导入导出、审批、批量 |
| 共享数据与状态 | 共用表/字段/状态机/枚举/缓存键 |
| 上下游消费方 | 报表、通知、同步任务、webhook、对外 API、订阅方 |
| 横切能力 | 权限、审计日志、搜索索引、缓存失效、i18n、计费配额、移动端 |

**取证顺序**：`use_skill("relation-lookup")` 查已登记的跨模块强关联（**未安装则跳过**，非必需依赖）→ **代码直读**（grep 共享模型/状态枚举/事件订阅/权限点）→ 改动面大时 `use_skill("code-survey")` → **问用户**（报表、外部订阅、运营 SOP 常不在代码里）。
**未查到 ≠ 没有**：找不到关联方时标 `⚪ 未发现（需确认）`——`⚪` 是独立于三级制的**第四态**，表示"没查到"而非"推断"，**禁止默认"无影响"**。
**M4 单独执行**时影响面可填 `-`；但改动的是**共用组件**（按钮/表单/弹窗/布局）时**仍须评估**——一个组件改了，所有引用它的页面都跟着变。

**影响评估表**（报告必填）：

```
| 受影响功能/方 | 影响类型 | 影响程度 | 证据 | 建议处理 | 需用户拍板 |
```
- 影响类型：数据 / 流程 / 权限 / 展示 / 性能 / **外部契约**
- 影响程度：`破坏`（已有功能不可用）/ `降级`（行为变化但可用）/ `无感`

**可接受性由用户拍板，AI 不得自行宣布"可接受"**：

| 情形 | 处理 |
|------|------|
| 影响是需求本身想要的（改状态机就是要改下游） | 标「预期内」+ 列**需配套改**项 |
| 影响已有功能但可一并处理 | **必须变成需求条目进清单**，不能只写在说明里 |
| 破坏已有用户习惯 / 数据 / 对外契约 | 🔴 标「需拍板」+ 给替代方案，由用户决定 |

> 详版（四类来源示例、取证细节、常见漏点）见 `reference.md` 第三节。M4 影响面通常限于页面内，可轻量处理（共用组件除外，见上）。**所有「需拍板」项同时进报告 §5 待确认清单**，避免只躺在影响表里没人管。

---

## M1 需求定义

### 档位选择（自动）

| 档位 | 触发条件 | 交互量 |
|------|---------|--------|
| **一次成型档**（默认） | 单点功能、涉及 ≤2 个角色、无外部依赖、需求条目预期 ≤5 | 只留 1 个确认点 |
| **严谨档** | 命中任一：多角色/多模块、外部依赖未确认、涉及流程或状态机变更、用户说"严谨档/逐项确认"、一次成型档下用户连续纠正 ≥2 次 | 完整保留 `requirement-mining` 的逐项确认 |

### 一次成型档流程

1. **误判筛查**：是已有功能的 Bug？是系统已有能力？命中则先提醒用户确认。
2. **关联功能与影响评估**（不可跳过）：按上节四类来源盘出关联功能 → 出影响评估表 → 「需配套改」项直接进需求清单；判定不了的标「需拍板」留给用户
3. **自主推理**：按 `requirement-mining` 的分析框架（形态判断 / 功能本质 / 场景 / 角色 / 非功能需求 / 变更面）一次性推理完，**假设由 AI 自主填**，不逐条问用户。`requirement-mining` / `negative-requirement` 未安装时按其框架自主推理，不阻塞、不报错。
4. **负向内联**：直接按 `negative-requirement` 的分类表（误操作 / 参数错误 / 中途放弃 / 状态异常 / 权限 / 数据异常 / 外部依赖）筛出**本需求真实相关**的 3-8 条，写入需求报告「负向需求」章节，不单独跑一轮。
5. **出报告**：含影响评估表 + 需求清单（优先级 / 预期效果 / 验收标准）+ 负向需求 + 关键假设表 + 建议下一步。
6. **唯一确认点**：把关键假设表 + **需拍板的影响项**一起交给用户确认（"这几条如果错了结论会偏，请重点看"），用户纠正后更新一次即定稿。

> 一次成型档**不省**的是：关联功能影响面、根本性分析（这方案治本吗）、负向场景、验收标准。**省的是**交互轮次。

### 严谨档流程

完整按 `use_skill("requirement-mining")` 流程执行；需求清单确认后调用 `use_skill("negative-requirement")` 补负向需求，最终合并为本 skill 的 PM 报告。
**影响面不因走严谨档而省略**：关联功能盘点与影响评估**照做**（可在 `requirement-mining` 流程中一并完成），报告仍须含影响评估表——严谨档省的是交互，不是内容。

### 出口

报告末给出下一步推荐（对齐 `requirement-mining` Step 8 的行动集）：交互复杂 → `interaction-design`；数据复杂 → `data-flow-model`；技术不明 → `design-craft`；技术风险 → `demo-verify`；低复杂度 → `plan-track` 建档直接实现。

**复杂度判据**（一次成型档简化版，不跑完整六维评分）：同时满足「单点改动 + 无外部依赖 + 无状态机变更」= 低，其余一律按中/高处理，推荐设计类行动。拿不准就按中/高推荐，不要把"看起来简单"当低复杂度。

---

## M2 产品体验走查

### 六维走查清单

| 维度 | 问自己 | 典型证据 |
|------|--------|---------|
| **价值达成** | 用户想办的事，现在办成了吗？有没有绕路 | 走一遍主流程 |
| **路径效率** | 达成目标要几步、几次等待、几次跳转 | 关键路径步骤数 |
| **反馈与容错** | 出错/空/加载/超时时有反馈吗？能恢复吗 | 触发一次异常 |
| **一致性** | 同类操作、术语、组件、提示口径是否一致 | 跨页面比对 |
| **可发现性** | 功能藏得深吗？新用户找得到吗 | 信息架构 |
| **边界与异常** | 超长文本、大数据量、极端输入的呈现 | 构造边界数据 |

### 执行

1. 界定走查对象边界（模块/页面/入口），边界不清先问一句
2. **按判定类型选手段**（不是"能跑就跑"）：符合性维度（价值达成/一致性/可发现性，多可代码直读）→ 优先代码直读 `🟢`；体验类维度（路径效率/反馈容错/边界呈现）→ 需运行实测 `🟢`，跑不起来时代码只能给 `🟡` 并在报告头声明"未实测"
3. 每个发现写：**现象 → 影响谁 → 证据等级 → 建议方向**（不写实现方案，那是设计阶段的事）
4. 用 Kano 分类（必备/期望/兴奋/无差异）+ 价值×成本矩阵定优先级，输出 `优先级 | 发现 | Kano | 价值 | 成本 | 证据 | 建议`
5. **排除项也值钱**：明确写"经走查排除：XX 维度无问题"，避免用户重复问

---

## M3 缺失功能推演

### 三条证据路径（从严到宽）

| 等级 | 路径 | 具体信号 |
|------|------|---------|
| `🟢` 代码实证 | 代码里已有痕迹但没做完 | `TODO/FIXME/未实现占位`、入口已建但点击无响应、路由已注册页面缺失、配置开关存在但恒为关、文档/README 承诺但代码无 |
| `🟡` 结构可证 | 有半成品结构 | 有数据模型无操作入口、有后端接口无前端调用、有前端页面无后端接口、有管理端无用户端、有写无读（能建不能查） |
| `🔴` 推断 | 参照同类产品 | **必须写明参照物**（"同类 SaaS 普遍有 X"），且只进待确认清单 |

### 硬约束

- **禁止凭空发明**：`🔴` 项不得写成"产品缺少 X"的断定句，只能进「待确认：是否有意不做？」
- **区分"有意不做"与"漏做"**：MVP 常见的有意省略（如未做国际化、未做审计日志）要标注"可能是有意取舍，需确认"，不当成缺陷
- **与 M2 合并**：M3 的缺失功能与 M2 的优化点进同一张清单，用 `来源` 列区分
- 每条缺失功能同样走 Kano + 价值×成本排序

---

## M4 界面视觉走查

### 先问：这个判定需要画面吗

- **不需要**（符合性/规范类："按钮都有禁用态吗""错误提示都带原因吗""间距是否统一 token"）→ **直接代码直读**，不进下面的能力探测，不必让用户起服务或截图
- **需要**（好不好看、层级是否清晰、响应式是否折行）→ 才走能力探测拿画面

### 能力探测（按顺序尝试，命中即停）

| 档 | 条件 | 做法 |
|----|------|------|
| **L1 自主** | 有浏览器工具且能截图 | 起服务 → 打开页面 → 截图 → 读图走查（强制覆盖：默认态 / 空态 / 加载态 / 错误态 / 长文本 / 窄屏） |
| **L2 半自主** | 能打开页面但**拿不到画面**（如只有 `preview_url`，AI 看不到渲染结果） | AI 开预览页供用户观看 + 读前端源码/CSS 静态推演（`🟡`）；同时给出**具体肉眼检查清单**请用户逐项确认 |
| **L3 手动上传** | 项目跑不起来 / 无浏览器 / 截不了图 | AI 先给出**拍摄清单**（哪几屏、什么状态、什么分辨率），用户上传截图后 AI 读图走查（`🟢`） |
| **L0 纯静态** | 连截图都没有 | 只读源码推演，**证据等级强制 `🔴`**，报告头声明"未看到实际渲染，以下为源码推断"，禁止写成"界面存在 XX 问题" |

> **能力探测是硬步骤**：不得跳过探测直接宣称"我看过界面了"。无画面即降级，降级声明必须写进报告头。

### 走查清单（有画面时逐项过）

视觉层级与重点 · 对齐与间距一致性 · 配色与对比度 · 字体与字号规范 · 组件状态完整性（悬停/聚焦/禁用/加载/错误/空）· 响应式与窄屏 · 文案（术语一致、语气、错误文案是否说人话）· 可发现性与操作反馈 · 明显的无障碍问题（对比度、可点击区域、键盘可达）

### 拍摄清单模板（L3 用）

```
请提供以下截图（能多屏就多屏）：
1. 首页/主界面（默认数据）
2. 核心操作流程的中间态
3. 空状态（无数据）
4. 错误/失败态（随便造一个错误）
5. 窄屏或移动端视图（如有）
分辨率：桌面 ≥1440 宽，移动 375 宽。无法提供第 N 项请说明，我会按可得画面降级。
```

---

## PM 报告模板（四模式统一）

```markdown
# PM 报告：{对象}
模式：M1 / M2 / M3 / M4（组合标注）
证据声明：{本次最高证据等级 + 是否实测 + 降级声明（如有）}

## 1. 执行摘要
{3-5 条结论，每条挂证据等级；无实测时首句声明"未经实测"}

## 2. 现状与范围
{走查/分析边界；现状来源标注}

## 3. 发现 / 需求
### 3.0 影响面（M1/M2/M3 必填）
| 受影响功能/方 | 影响类型 | 影响程度 | 证据 | 建议处理 | 需用户拍板 |
{未发现关联方时写「未发现（需确认）」，不得留空或默认无影响}

### 3.1 主体
{模式各自的主体章节：M1 需求清单+负向需求；M2/M3/M4 发现清单}

## 4. 优先级排序
| 优先级 | 条目 | 来源(M2/M3，单一模式填 -) | Kano 分类 | 价值(高/中/低) | 成本(高/中/低) | 证据 | 建议方向 |
{排序理由一句话；P0 必须有 Kano=必备 或 价值高且成本低}

## 5. 待确认清单
{所有 🔴 项 + 需用户拍板的取舍，每条配验证方法}

## 6. 关键假设
| 假设 ID | 内容 | 错了会怎样 | 验证方法 |

## 7. 建议下一步
{1-2 个行动 + 理由；不自动执行}
```

---

## 约束

1. `🔴` 推断禁止进结论区，只能进「待确认清单」且必须配验证方法
2. 不修改产品代码，不自动实施优化建议
3. 优先级一律 Kano + 价值×成本，不给无依据的精确收益数字
4. M4 未获得画面时必须降级声明，禁止假装看过界面
5. M3 不得把"有意不做"当"漏做"，不确定即标注待确认
6. M2 + M3 合并输出，禁止两张独立清单
7. 报告不替代人工产品决策，最终取舍权归用户
8. 一次成型档最多 1 个确认点；用户纠正 ≥2 次自动切严谨档
9. 需求类产出落盘须走 `req` 命令（`requirement-doc-store`），禁止手拼路径
10. **Kano 不允许硬猜**：判定依据不足标 `Kano 待定`，待定项**不得默认按"期望"参与排序**，一律进「待确认清单」——把待定当期望会把真正的必备项埋掉
11. 组合模式证据声明取最低档（见公共规则 8），禁止用部分实测为全报告背书

---

## 与相关 skill 的关系

| skill | 关系 |
|-------|------|
| `requirement-mining` | M1 的分析引擎。一次成型档复用其框架省交互；严谨档完整调用 |
| `negative-requirement` | M1 的负向来源。一次成型档内联其分类表，不单独跑一轮 |
| `acceptance-verify` | 它答"这一版达标没"，本 skill 答"下一版做什么"；不重叠 |
| `artifact-optimizer` | 它优化产物质量（代码/设计/skill），本 skill 看用户价值与机会；对象是产品不是产物 |
| `code-review` / `request-guard` | 本 skill 出建议，实施前经 `request-guard` 刹车、实施后经 `code-review` |
| `ui-designer` / `ui-to-ascii` | 前者从零设计界面、后者设计稿转 ASCII 存档；本 skill 是已存在界面的走查 |
| `e2e-testing` | 其「动态体验验证」可作 M2 的取证手段（真实链路），本 skill 负责 PM 判断与排序 |
| `interaction-design` / `design-craft` / `demo-verify` | M1 的常见下游 |
| `relation-lookup` | 影响面调研首选：查已登记的跨模块强关联（"改 A 要连带改 B 吗"） |
| `code-survey` | 改动面大时的代码现状调研手段 |
| `bug-impact-analysis` | 边界：它分析**已发生的 bug 修复**的影响（事后）；本 skill 是**需求/优化**的影响（前置） |
| `expert-solution-workflow` | 分析前查可复用资产 |

---

## 反模式

- ❌ **把 requirement-mining 流程抄一遍** → 用户得到"一样繁琐 + 多一层壳"。本 skill 的价值是编排与判断，不是复刻
- ❌ **M2 滑成 code-review** → 开始点评函数职责、命名、设计模式。看到自己在写这类内容立即停，回到六维
- ❌ **M3 发明需求** → "同类产品都有所以你也该有"当结论写。必须标 `🔴` + 参照物 + 进待确认
- ❌ **无画面假装看过** → "界面存在明显的对齐问题"（实际没截图）。无画面必须降级声明
- 🔴 **把推断当结论**：`🔴` 出现在执行摘要里 = 报告作废重写
- ❌ **出两张清单**：M2 优化点一份、M3 缺失功能一份，用户自己合并 → 违反「模式路由」的组合规则
- ❌ **给假精确**："预计提升转化 12%""约 3 人日"。无数据支撑时只给价值/成本的高中低
- ❌ **直接改码**：本 skill 只判断。想改先走 `request-guard`
- ❌ **一次成型档还逐条问**：8 个问题轮番确认 = 档位选错，回到档位表重判
- ❌ **符合性问题非要跑起来**：用户问"导出是异步的吗"，却要求先起服务再验证 → 读代码 30 秒可判定，起服务是浪费
- ❌ **用代码推断体验/视觉**："代码里有 loading 分支，所以加载反馈没问题" → 有分支 ≠ 用户看得到，属 `🟡`，想定论必须看画面
- ❌ **只讲新功能、不提碰到谁**：需求报告只写"要做什么"，不写"会影响到谁" → 开发做完才发现下游炸了
- ❌ **AI 自行宣布"影响可接受"**：可接受性是业务决策。破坏已有习惯/数据/对外契约的，必须标「需拍板」交给用户
- ❌ **影响项只写在说明里、不进需求清单**：分析提了一嘴，开发漏做 → 每条「本次一并改」必须在需求清单有对应条目
- ❌ **查不到就当没有**：未发现关联方要标「未发现（需确认）」并给查证方法，不能默认无影响

---

## 更多资源

- 取证手段矩阵与代码直读细则、关联功能影响评估（四类来源 + 常见漏点）、Kano + 价值×成本评分表、四模式详细清单、M4 走查逐项细则与拍摄清单、报告完整模板，参见 [reference.md](reference.md)
- 四个模式 + 代码直读核验的完整示例，参见 [examples.md](examples.md)