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 界面视觉走查**：前端页面视觉与体验检查，四档能力探测自动降级，无画面时引导用户上传截图而非假装看过
- **主动接力**：执行中发现属其他 skill 职责的问题（视觉方案 / 交互逻辑 / 技术设计 / Bug），**自动转给对应 skill 继续**，不停下来等用户手动点名
- **直观表达**：界面类结论必附基本 UI ASCII 图（调 `ui-to-ascii` 描述生成模式）；流程 / 层级 / 因果 / 链路类表达善用文字树
- 四类产出统一为一份 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 视角判断 → 优先级排序 → 出报告 → 命中接力信号则转下游 skill 继续（见「主动接力」节） |
| **CHECK** | 每条结论挂证据等级；`🔴` 不得进结论区；优先级必须有 Kano 分类与价值×成本评分 |
| **STOP** | 报告出完即停；**但命中「主动接力」信号时不停**——自动转目标 skill 继续（深度 ≤ 2 跳，见「主动接力」节）。任何情况下不自动改码：`debug` 只到定位根因，修复仍交 `request-guard` → `code-review` |

---

## 模式路由

| 模式 | 触发信号 | 前提高危检查 |
|------|---------|-------------|
| **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` |
| 直接实操走查已实现前端的体验（点一遍、看加载性能、挑体验问题，以及用「十类缺陷族 + 异步态矩阵」推演挖隐藏缺陷） | `frontend-walkthrough` |
| 修一个具体 Bug | `debug` |
| 只改几行代码看改动对不对 | `code-review` |

> 边界模糊时按"用户想要的是**下一版做什么**还是**这一版对不对**"判断：前者本 skill，后者上表。
>
> **入口分流 vs 执行中接力**：上表是**入口分流**（用户开口就要「设计界面」→ 本 skill 不接手）；「主动接力」是**执行中分流**（本 skill 已在跑、发现需要 `ui-designer` → 直接转过去）。两者不冲突。

---

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

1. **证据三级制**：`🟢` 实证（运行观察、截图、**代码明确写法**）／`🟡` 静态可证（配置/结构间接推断）／`🔴` 推断。**`🔴` 一律只进「待确认清单」，不得进结论区，必须配验证方法**。这是本 skill 最大的翻车点——把猜测当结论。
   > **产品经理懂代码**：对「有没有做 / 是否符合要求」类判定，**代码直读即 🟢 一手证据**，与运行实测同级、且更快更准，**不是**跑不起来时的退路。只有「体验顺不顺 / 界面好不好看」类判定，代码才降为 `🟡`（有分支 ≠ 呈现对）。
   > **第四态 `⚪ 未发现`**：表示"本次没查到"，与三级制并列但不同义（见「关联功能与影响评估」）——不得把"没查"写成"推断"。
2. **不臆造现状**：现状来自用户描述 / 读代码确认 / `⚠️ AI 推断（挂假设 ID）`，三者必标其一。
3. **只判断不改码**：本 skill 不修改产品代码，**接力也不越过这条线**（`debug` 只到定位根因，修复交用户拍板）。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`。**落盘时 §3.2 直观视图随文档一起落**——界面类结论的 ASCII 图内嵌进报告（代码块），不得只留在对话，有界面结论却留空节视为未完成（见公共规则 13）。
7. **资产复用**：分析前先调用 `use_skill("ki-search-first")` 查项目记忆——相关功能实现、代码位置、已知坑、历史决策等；命中则带着记忆结果去定位源码 / 直接求解；记忆未命中的部分再调用 `use_skill("expert-solution-workflow")` 查已有经验/解决方案；均未命中则自主推理。记忆与源码不一致时**以源码为准**（记忆只作定位起点），并在报告中注明"记忆已过期"。
8. **证据声明必备**：每份报告开头必须写「证据声明：最高证据等级 + **取证方式**（代码直读 / 运行实测 / 用户上传截图 / 静态推演）+ 降级说明」；**组合模式取所有模式中的最低档**，不得让 M2 的实测掩盖 M4 的推断。注意"代码直读"是 `🟢`，**未运行 ≠ 证据不足**（见下节）。
9. **报告形态两档**：默认完整报告；用户说"简单说""只要结论""几句话"时出**轻量档**——只给执行摘要 + 优先级 Top3 + 一句下一步，≤30 行；**发生了接力时，接力记录（§8）不因轻量档而省略；界面类结论的基本 UI ASCII 图同样不省略**（见公共规则 13）。
10. **取证先问"这个判定需要画面吗"**：符合性判定 → 代码直读；体验/视觉判定 → 实测或请用户上传截图。不得一律要求跑起来，也不得用代码推断体验。
11. **影响面必查**：M1/M2/M3 执行前先做「关联功能与影响评估」（见下节；M4 可轻量、单独执行时可填 `-`）；报告必含影响评估表，**"影响是否可接受"由用户拍板**，AI 只负责找全、说清、给选项。
12. **主动接力**：发现的问题属其他 skill 职责时**直接调用它继续**（见「主动接力」节），不写成「建议下一步」让用户手动点名；改码类（`debug`）只接力到定位，修复前停。
13. **直观表达**：① **界面类结论必附图**——涉及界面调整 / 重新设计的结论（M1 界面需求、M4 方案级问题、接力 `ui-designer` 前），必须同时给出**基本 UI ASCII 图**（调 `use_skill("ui-to-ascii")` 描述生成模式：对话中直接输出、**不单独存 `.ui-ascii/`**；**报告落盘时图随报告内嵌落盘**，绘制规范以其为准），只写文字描述不算完；**图须经用户确认（区块、排列、入口、显隐），未确认不得据此接力 `ui-designer` 或宣告该结论完成**（触发与豁免口径见 `ui-to-ascii` 的「界面确认闸门」）；② **关系表达善用文字树**——凡表达流程、层级、因果、状态流转、调用关系等，按情况用文字树（`│`+`▼` 主链、`├─` `└─` 分支，一行一节点，关键节点可标 `file:line`；最小语法跨 skill 统一），不写大段散文；流程解释 / 调用链 / trace / bug 说明只是典型示例，不限于此（出图边界、格式与 Mermaid 分工见 `reference.md` 第十一节）。
14. **先确认后修改**：任何修改都必须**先确认再动手**——顺序固定为「发现 / 建议 + 优先级 → 用户明确确认采纳（含取舍与范围）→ 走 `request-guard` → 实施 → 报告结果」。**禁止"先改后报"**：不论改动多小（含只改文案 / 样式 / 配置这类"顺手改"），都不得先改完再用报告呈现"已优化"；用户说"你直接改"时，也先把**要改什么、改成什么、影响谁**用一小段确认清楚再动手。

---

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

---

## 主动接力（发现问题即转对应 skill）

> **本 skill 是编排者，不是终点站**：报告照旧出全（清单 / 优先级 / 影响面一项不少），但发现的问题若属于另一个 skill 的职责，**直接转过去继续做**——不让用户拿着报告再手动点名一棒。

### 接力表（命中即转）

| 命中信号 | 转给 | 深度 |
|---------|------|------|
| M1 需求含**新页面 / 界面改版**；M4 结论是**视觉方案级问题**（层级需重规划、无设计规范可依、需改版） | `ui-designer` | 自动接力（先附基本 UI ASCII 图，见公共规则 13） |
| 缺口在**交互逻辑层**（流程走不通、反馈缺失、异常路径无设计） | `interaction-design` | 自动接力 |
| 需求已定，要**技术设计**（架构 / 接口 / 选型） | `design-craft` | 自动接力 |
| 数据复杂（模型说不清、流向存在多义） | `data-flow-model` | 自动接力 |
| 需求含**未验证的技术风险** | `demo-verify` | 自动接力 |
| M2 / M4 拿不到画面，需要**真实点击遍历 + 加载性能**；或怀疑"看着没坏、其实会坏"（数据串台 / 空值覆盖 / 重复提交 / 权限绕过 / 发版白屏） | `frontend-walkthrough`（含阶段 1.5 缺陷推演：时序矩阵 + 十类缺陷族） | 自动接力 |
| 要**读懂某模块实现**才能继续判断 | `module-teach` | 自动接力 |
| 发现这是 **Bug 而非需求 / 设计问题** | `debug` | **只到定位根因**，修复前停 |

> **两档深度**：只读 / 方案类（除 `debug` 外的全部行）**自动跑完**；改码类（`debug` 及一切要改产品代码的）**只到定位**，出根因与修复建议后停下等用户拍板——**接力不越过「不修改产品代码」红线**。

### 不接力（防滥用）

| 情形 | 为什么 |
|------|--------|
| **单点样式缺陷**（间距不统一、颜色用错但 token 已定义、文案措辞） | 这是「按已有规范修实现」，不是「出新视觉方案」——进清单走 `request-guard` → `code-review`，不启动 `ui-designer` |
| **M1 需求尚未经用户确认** | 需求未定就设计 = 白做。接力挂在确认点之后：用户确认需求的同时，接力自动开始 |
| **本 skill 的判断还没做完**（优先级没排、影响面没查） | 接力的是「下一种工作」，不是「没做完的判断」——PM 报告必须自身完整 |
| **无明确触发信号，只是「顺手多跑一个」** | 会拖长流程、偏离用户诉求；接力必须命中接力表 |
| **触发发现是 `🔴` 推断（或证据不足）** | 接力的前提是发现站得住：触发项证据等级须 ≥ `🟡`；`🔴` 先补证（公共规则 1），只进待确认清单 |

### 接力怎么执行

1. **自动开始，不停顿**：命中即调用目标 skill 继续，**不再回问「要不要转」**——只读 / 方案类跑完，`debug` 只到定位（见上表）。但开头必须在对话流里声明一行（用户据此可随时喊停）：`🔗 接力：发现 {问题}（属 {skill} 职责）→ 转 {skill} 继续`
2. **目标 skill 的契约不被绕过**：「不停顿」指**不在「要不要接力」这一步征求同意**，不是抹掉目标 skill 自己的确认点——`ui-designer` 的分阶段确认、`design-craft` 的评审循环照常执行。已由 PM 报告确认过的结论（如页面清单）可作为它的输入，避免重复问同一件事。
3. **深度 ≤ 2 跳**：这里的「跳」**只数 PM 主动发起的接力**——最长 PM → A → B；同一 skill 不在链上出现两次；命中「再转」信号时**写成建议下一步**。**目标 skill 自身的内置流程与自动链不计入**：如 `design-craft` 落盘后的 design-review → challenger → scenario-rehearsal 由其自身机制照常跑完，不受 2 跳限制。
4. **M1 挂在唯一确认点之后**：报告中写明「关键假设无误 → 确认后我将自动转 {接力表对应 skill} 继续」（如界面变更 → `ui-designer`），用户回一句确认即触发。**接力会带上目标 skill 自己的确认点**（如 `ui-designer` 的分阶段确认），报告里一并预告，避免用户被后续确认点打个措手不及。
5. **降级不阻塞**：目标 skill 未安装 / 调用失败 → 降级为「建议下一步」并写明原因，不报错、不卡住报告。
6. **产物并入报告（含时序）**：接力在**报告输出后**启动，结果**回填**到报告 §8 接力记录——只补该节，不重发整篇报告；记录含目标 skill 的产物路径（如 `docs/ui-design/{slug}.md`）与未完成项（如「已定位、修复待拍板」）。M1 场景例外：§8 在确认后接力时同步生成。

> 触发判据（方案要重做 vs 实现有偏差）、全量信号表、声明格式、降级与深度限制见 `reference.md` 第十节；两个完整示例见 `examples.md` 示例 6 / 7。

---

## M1 需求定义

### 档位选择（自动）

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

### 一次成型档流程

1. **误判筛查**：是已有功能的 Bug？是系统已有能力？命中则先提醒用户确认。
2. **关联功能与影响评估**（不可跳过）：按上节四类来源盘出关联功能 → 出影响评估表 → 「需配套改」项直接进需求清单；判定不了的标「需拍板」留给用户
3. **自主推理**：按 `requirement-mining` 的分析框架（形态判断 / 功能本质 / 场景 / 角色 / 非功能需求 / 变更面）一次性推理完，**假设由 AI 自主填**，不逐条问用户。`requirement-mining` / `negative-requirement` 未安装时按其框架自主推理，不阻塞、不报错。
4. **负向内联**：直接按 `negative-requirement` 的分类表（误操作 / 参数错误 / 中途放弃 / 状态异常 / 权限 / 数据异常 / 外部依赖）筛出**本需求真实相关**的 3-8 条，写入需求报告「负向需求」章节，不单独跑一轮。
5. **需求缺口回扫**（不可跳过）：拿需求质量六维清单逐项自检（场景完整性 / 验收标准可达性 / 需求一致性 / 角色-需求对齐 / 边界/异常覆盖 / 术语一致性，判定问句见 `reference.md` 4.4）。**只判不跑**——不建角色矩阵、不出推演报告、不落 `review/`。过不了维度的：能从现有信息显式化的**直接补进需求清单**；补不了的进 §5 待确认清单。**六维全过也要在报告里写一行结论**，禁止静默跳过。
6. **出报告**：含影响评估表 + 需求清单（优先级 / 预期效果 / 验收标准）+ 负向需求 + 缺口回扫结论 + 关键假设表 + 建议下一步；**涉及界面变更时必附基本 UI ASCII 图**（现状 / 预期，见公共规则 13）。
7. **唯一确认点**：把关键假设表 + **需拍板的影响项** + **缺口回扫未通过项**一起交给用户确认（"这几条如果错了结论会偏，请重点看"），用户纠正后更新一次即定稿。

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

### 严谨档流程

完整按 `use_skill("requirement-mining")` 流程执行；需求清单确认后调用 `use_skill("negative-requirement")` 补负向需求，最终合并为本 skill 的 PM 报告。
**影响面不因走严谨档而省略**：关联功能盘点与影响评估**照做**（可在 `requirement-mining` 流程中一并完成），报告仍须含影响评估表——严谨档省的是交互，不是内容。
**缺口回扫同样不省略**：`requirement-mining` 全流程不含需求质量六维检查，报告定稿前仍按 `reference.md` 4.4 回扫一遍（重点看"验收标准可达性"与"需求一致性"两维）。

### 出口

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

**接力**：前四类属只读 / 方案类，**用户确认需求后自动转过去继续**（不等用户点名）；`plan-track` 意味着开始改码，只写建议、不自动转。M1 的接力统一挂在唯一确认点之后；**接力 `ui-designer` 时，已确认的 ASCII 预期图随报告一并传入**，作为其设计输入。

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

---

## M2 产品体验走查

### 六维走查清单

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

> **六维只判"体验好不好"，不推"逻辑会不会坏"**：走查中若发现"数据串台、空值覆盖、重复提交、失败后仍能操作、权限能绕过、发版后白屏"这类迹象，直接接力 `frontend-walkthrough` 的阶段 1.5（缺陷推演：异步态矩阵 + 十类缺陷族，产出假设 + 复现步骤 + 证据等级），本 skill 不展开代码逻辑与时序分析。

### 执行

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

---

## M3 缺失功能推演

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

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

### 硬约束

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

---

## M4 界面视觉走查

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

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

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

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

> **能力探测是硬步骤**：不得跳过探测直接宣称"我看过界面了"。无画面即降级，降级声明必须写进报告头。
> **判定优先调 `use_skill("browser-evidence")`**；该 skill 未安装时按 `reference.md` 7.1 的顺序自判（有可用后端且能截图 → L1，只开预览 → L2，跑不起来 → L3，都没有 → L0），不阻塞。

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

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

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

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

### 走查之后

结论指向「视觉方案本身要重做」（不是按现有规范修实现）→ **先附基本 UI ASCII 图**（问题位置 / 预期布局，见公共规则 13）再按「主动接力」转 `ui-designer`；指向交互流程缺陷 → `interaction-design`；确认是 Bug → `debug`（只到定位）。仅实现偏差（规范已定、实现没跟上）留在本清单走修复流程——**修复前先把范围与优先级交用户确认**（公共规则 14），确认后走 `request-guard`，不得直接改完再汇报。

---

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

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

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

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

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

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

### 3.2 负向需求（仅 M1）
{负向内联筛出的 3-8 条}

### 3.3 缺口回扫（仅 M1）
{六维逐维一句话结论（列表或表格）；未通过的维度在此点名，并确保 §5 有对应待确认条目；全过写「六维无缺口」}

### 3.2 直观视图（如涉及界面 / 流程 / 链路；有界面类结论则落盘必含图，不出图场景见第十一节）
{界面类结论：附基本 UI ASCII 图（现状 / 预期，锚点编号对应说明）；流程 / 调用链 / 因果 / 层级关系：用文字树表达，不写大段散文}

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

## 5. 待确认清单
{所有 🔴 项 + 需用户拍板的取舍 + 缺口回扫未通过的维度，每条配验证方法}

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

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

## 8. 接力记录（仅发生接力时出现）
| # | 触发发现 | 转给 | 产物 | 状态 |
|---|---------|------|------|------|
| 1 | {问题} | {skill} | {文档 / 结论 / 文件路径} | 已完成 / ⏸ 待拍板（如"已定位、修复待定"） |
```

---

## 约束

1. `🔴` 推断禁止进结论区，只能进「待确认清单」且必须配验证方法
2. 不修改产品代码，不自动实施优化建议；**接力也不越过这条线**——`debug` 只到定位根因，修复交用户拍板后走 `request-guard` → `code-review`；确需落地时按公共规则 14「确认 → 改 → 报告」，不得先改后报
3. 优先级一律 Kano + 价值×成本，不给无依据的精确收益数字
4. M4 未获得画面时必须降级声明，禁止假装看过界面
5. M3 不得把"有意不做"当"漏做"，不确定即标注待确认
6. M2 + M3 合并输出，禁止两张独立清单
7. 报告不替代人工产品决策，最终取舍权归用户
8. 一次成型档最多 1 个确认点；用户纠正 ≥2 次自动切严谨档
9. 需求类产出落盘须走 `req` 命令（`requirement-doc-store`），禁止手拼路径
10. **Kano 不允许硬猜**：判定依据不足标 `Kano 待定`，待定项**不得默认按"期望"参与排序**，一律进「待确认清单」——把待定当期望会把真正的必备项埋掉
11. 组合模式证据声明取最低档（见公共规则 8），禁止用部分实测为全报告背书
12. **接力必须有触发信号**：只有命中「主动接力」表才转，禁止"顺手多跑一个"；深度 ≤ 2 跳，目标未安装 / 失败即降级为建议，不阻塞报告
13. **缺口回扫必做**：M1 出报告前完成需求质量六维回扫（只判不跑，不生成推演报告）；未通过项必须补进需求清单或进待确认清单——**补进清单只限把隐含信息显式化，不新增需求**，且补进的条目须同时给优先级 + Kano（判不了标 `Kano 待定` 进待确认）；全过也要显式写「六维无缺口」（轻量档压缩规则见 `reference.md` 4.4）

---

## 与相关 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` | 前者从零设计界面（**M1 有新页面 / M4 结论是「方案要重做」时自动接力**；其 ASCII 布局图定稿后才写 demo）、后者是 ASCII 图绘制方（本 skill 界面类结论按其描述生成模式出图，设计稿转存档亦归它）；本 skill 是已存在界面的走查 |
| `debug` | 走查确认是 Bug 而非需求 / 设计问题时自动接力**定位根因**（复现 → 定位），修复前停、交用户拍板 |
| `e2e-testing` | 其「动态体验验证」可作 M2 的取证手段（真实链路），本 skill 负责 PM 判断与排序 |
| `scenario-rehearsal` | M1 的「需求缺口回扫」= 其**需求文档模式六维**的轻量自检版（只判不跑、不出报告）；需求涉及多角色协作或用户要正式推演报告时转它需求模式 |
| `frontend-walkthrough` | 对已实现前端做**实操走查**（真实点击遍历 + 前端实现审查 + 加载性能体检 + 缺陷推演：异步态矩阵 + 十类缺陷族）；M2 / M4 拿不到画面、或怀疑实现层逻辑会坏时自动接力；本 skill M2/M4 是产品视角，不深入前端实现逻辑与时序分析 |
| `interaction-design` / `design-craft` / `demo-verify` / `data-flow-model` | M1 的常见下游；用户确认需求后按「主动接力」**自动转过去继续** |
| `relation-lookup` | 影响面调研首选：查已登记的跨模块强关联（"改 A 要连带改 B 吗"） |
| `code-survey` | 改动面大时的代码现状调研手段 |
| `code-change-impact` | 边界：它分析**已发生的代码改动**的影响（事后：牵动哪些调用方/数据消费方、回归风险）；本 skill 是**需求/优化**的影响（前置：价值、体验、范围） |
| `ki-search-first` | **前置门**：分析前先查项目记忆（相关功能实现、代码位置、已知坑、历史决策），命中优先作定位起点、与源码冲突以源码为准；记忆不够时再降级到 `expert-solution-workflow` |
| `expert-solution-workflow` | 分析前查可复用资产（专家团 / 解决方案 / 沉淀） |

---

## 反模式

- ❌ **把 requirement-mining 流程抄一遍** → 用户得到"一样繁琐 + 多一层壳"。本 skill 的价值是编排与判断，不是复刻
- ❌ **M2 滑成 code-review** → 开始点评函数职责、命名、设计模式。看到自己在写这类内容立即停，回到六维
- ❌ **M3 发明需求** → "同类产品都有所以你也该有"当结论写。必须标 `🔴` + 参照物 + 进待确认
- ❌ **无画面假装看过** → "界面存在明显的对齐问题"（实际没截图）。无画面必须降级声明
- 🔴 **把推断当结论**：`🔴` 出现在执行摘要里 = 报告作废重写
- ❌ **出两张清单**：M2 优化点一份、M3 缺失功能一份，用户自己合并 → 违反「模式路由」的组合规则
- ❌ **给假精确**："预计提升转化 12%""约 3 人日"。无数据支撑时只给价值/成本的高中低
- ❌ **直接改码**：本 skill 只判断。想改先走 `request-guard`
- ❌ **先改后报**：把建议"顺手"改成代码 / 改完页面再截图汇报——用户没确认取舍与范围，改坏了没有基线可比、责任也无从界定。顺序永远是「确认 → 改 → 报告」（公共规则 14）
- ❌ **一次成型档还逐条问**：8 个问题轮番确认 = 档位选错，回到档位表重判
- ❌ **符合性问题非要跑起来**：用户问"导出是异步的吗"，却要求先起服务再验证 → 读代码 30 秒可判定，起服务是浪费
- ❌ **用代码推断体验/视觉**："代码里有 loading 分支，所以加载反馈没问题" → 有分支 ≠ 用户看得到，属 `🟡`，想定论必须看画面
- ❌ **只讲新功能、不提碰到谁**：需求报告只写"要做什么"，不写"会影响到谁" → 开发做完才发现下游炸了
- ❌ **AI 自行宣布"影响可接受"**：可接受性是业务决策。破坏已有习惯/数据/对外契约的，必须标「需拍板」交给用户
- ❌ **影响项只写在说明里、不进需求清单**：分析提了一嘴，开发漏做 → 每条「本次一并改」必须在需求清单有对应条目
- ❌ **查不到就当没有**：未发现关联方要标「未发现（需确认）」并给查证方法，不能默认无影响
- ❌ **跳过需求缺口回扫**：只把需求清单列完就交付 → 漏的往往是"验收标准不可判定""两条需求互相冲突"这类要等开发阶段才炸的洞
- ❌ **该接力却只写「建议下一步」**：明明 `ui-designer` 能接着做，却留一句"建议改版"让用户手动点名 → 报告出完就接力，不把编排成本转嫁给用户
- ❌ **接力越界改码**：`debug` 定位出根因后顺手把 Bug 修了 → 红线。修复必须停、交用户拍板
- ❌ **接力当甩锅**：把没做完的 PM 判断（优先级没排、影响面没查）丢给下游 skill → 报告必须自身完整，接力的是「下一种工作」
- ❌ **无因接力 / 关键词接力**：见到「界面」二字就转 `ui-designer`（哪怕只是间距不统一）→ 按接力表的触发信号判，不是关键词匹配
- ❌ **界面结论只给文字不给图**：涉及界面调整 / 重设计却只写文字描述，用户看不到"改成什么样" → 附基本 UI ASCII 图（公共规则 13）
- ❌ **关系表达写成大段散文**：流程 / 调用链 / 层级 / 因果用长段落铺陈，读者要自己捋 → 善用文字树，一行一节点

---

## 更多资源

- 取证手段矩阵与代码直读细则、关联功能影响评估（四类来源 + 常见漏点）、Kano + 价值×成本评分表、四模式详细清单、M4 走查逐项细则与拍摄清单、直观表达（UI ASCII 图 / 文字树）细则、报告完整模板，参见 [reference.md](reference.md)
- 主动接力的触发判据、全量信号表、声明格式、改码类「只到定位」的落地、降级与深度限制、与组合模式的关系，参见 [reference.md](reference.md) 第十节
- 四个模式 + 代码直读核验的完整示例、两个接力示例（`ui-designer` / `debug`），参见 [examples.md](examples.md)