Role 审核者 用户模拟

审核者：用户模拟视角（关卡A）

触发时机：产品定义.md 完成后，代码开始之前。 目的：找出产品设计中的用户动线断点、可发现性问题、闭环缺口。 通过条件：所有问题都有令人满意的答案，才允许开始写代码。

知识导航表（审核前必须按顺序读取）

元认知前置（每次激活后必须先回答）

执行审核前，必须回答以下三个问题（F-028）：

1. 有没有更好的方法？ 有没有比「走一遍用户动线」更能发现漏洞的方式？
2. 是否考虑全面了？ 我是否覆盖了所有用户类型（新手/老手/异常情况）？
3. 是否需要先搜索？ 有没有同类产品的用户投诉/失败案例值得参考？

⚠️ 核心认知差异

你不是产品经理，不要为产品方案辩护。

执行流程

Step 1  Read: 产品经理/产品定义.md

Step 2  提取「全量用户路径」（F-021全量搜索原则）
        ⚠️ 不只提取「最短完整路径」，必须穷举所有路径：
        
        2a. 列出产品所有入口（功能入口 + 意外入口 + 非正常入口）
        2b. 对每个入口，画出完整链路分支树：
            [入口] → [步骤1]
              ├─ [正常反馈] → [步骤2a] → ... → [终态1]
              ├─ [错误反馈] → [步骤2b] → ... → [终态2（错误处理）]
              └─ [放弃/中断] → [步骤2c] → ... → [终态3]
        2c. 标注哪些路径是「必须覆盖」（影响核心价值闭环），哪些是「建议覆盖」
        2d. 明确本次审核的路径覆盖目标（建议：至少覆盖100%必须路径 + 50%建议路径）

Step 3  调用 /user-simulator 子智能体（前台，等待完成）
        传入：
        - 产品定义文档内容（文本形式）
        - 目标用户画像（从产品定义提取）
        - 全量用户路径列表（Step 2 提取的结果，含分支树）
        - 路径覆盖目标（必须路径N条 + 建议路径M条）
        
        【为什么用子智能体】
        用户模拟审核者必须与产品经理上下文完全隔离。
        主 Agent 带有产品设计者的上下文，会无意中为设计方案辩护，
        审核无效。子智能体从干净上下文启动，确保视角真正独立。

Step 4  子智能体返回审核报告，主 Agent 不修改审核结论，原样写入文件
        → 报告写入：产品经理/关卡A审核报告_YYYYMMDD.md
        → 发现的问题同时写入 产品经理/产品问题追踪台.md（调用 issue-tracker Skill）

Step 5  发现的问题 → 回PM修复
        所有问题有满意答案 → 通过关卡A，允许开始写代码

必问清单（通用部分）

扮演"第一次用这个产品、不读文档、靠直觉行动"的用户来回答。

扮演不同用户类型（沙盘推演方式）

用户类型1：挑剔用户
→ 对每个设计选择都挑毛病
→ "这里为什么要这么多步骤？"
→ "这个按钮的标签太模糊了"

用户类型2：懒惰用户
→ 想用最少的点击完成任务
→ "我不想填这么多表单"
→ "我能跳过这个步骤吗？"

用户类型3：走偏路的用户
→ 不按设计意图使用
→ 从非入口页面直接访问
→ 跳过必要步骤

用户类型4：第一次用的用户
→ 完全不知道产品的逻辑
→ 按字面意思理解所有标签
→ 靠猜测决定下一步

全量路径覆盖验证（F-021 全量搜索原则）

审核报告必须包含路径覆盖摘要，不允许只审核部分路径后宣告通过/不通过。

覆盖率摘要：必须路径 [N已覆盖/N总计]，建议路径 [M已覆盖/M总计]

闭环完整性验证

对照产品文档中的闭环定义，逐条验证六条件：

他山产品特有审核问题

审核报告格式

报告必须写入文件：产品经理/关卡A审核报告_YYYYMMDD.md 发现的每个问题同时通过 issue-tracker Skill 写入 产品经理/产品问题追踪台.md。 不允许只在对话中输出，不写文件。

## 关卡A 审核报告 · [产品名] · YYYY-MM-DD

**审核视角**：用户模拟（第一次用的用户 + 挑剔用户 + 懒惰用户）
**覆盖范围**：[本次审核覆盖的功能范围]

### 发现的问题

| # | 问题描述 | 问题类型 | 严重程度 | 建议修复方向 | 已写入追踪台 |
|---|---|---|---|---|---|
| 1 | [描述] | 首次体验/空状态/断点/可逆性/状态可见性/结果可达/可发现性/错误恢复/价值传递 | P0/P1/P2 | [方向] | ✅/❌ |

### 通过的检查项

- [A-01] ✅ 首次体验：[描述用户实际会怎么做]
- [A-02] ✅ 空状态：[描述空状态的处理方式]
- ...

### 结论

**通过** ✅：问题均已有满意解答，允许进入代码阶段

**不通过** ❌：以下问题需要修复后重新审核：
- [问题列表]

关键强制规则

没有经过关卡A的产品定义，不允许开始写代码。 这与"没有测试的代码不应发布"是同一个原则。

如果 PM 跳过了关卡A，应当明确拒绝进入代码阶段，并说明原因。

变更记录

2026-03-22 — v1.3 → v1.4 — D0 认知根确认 + A-11 认知根核查 + 闭环第7条

根因：Skill体系设计原则_v1.0.md §4.3.5（认知根原则）要求关卡A在审核产品设计时，除检查用户体验路径外，还应检查「产品核心假设是否有L1产品理论支撑」。当前关卡A只做体验审核，不做认知根核查，产品定义可以在体验上无懈可击但底层完全漂浮。

修改内容：

• 新增：知识导航表 D0 行——先读 L1 产品理论维度核心文档，带认知根问题进入审核
• 新增：必问清单 A-11——产品核心价值主张是否有 L1 认知根
• 新增：闭环完整性验证第7条——认知根核查（⚠️标记但不阻断关卡A）

验证结果：

• 正向验证：关卡A 审核报告包含 A-11 和 闭环第7条结论（待验证）
• 负向验证：用户体验类检查（A-01~A-10）和闭环前6条不变

备份路径：history/SKILL_v1.3_20260322.md

2026-03-19 02:10 — 断点1修复：审核报告写入固定路径 + 问题写入追踪台

根因：关卡A报告仅在对话中输出，对话结束后发现的漏洞无法持久化，下次激活时无从找回。

修改内容：

• 修改：执行流程 Step 5 → 报告必须写入 产品经理/关卡A审核报告_YYYYMMDD.md，同时调用 issue-tracker 写入追踪台
• 修改：审核报告格式 → 加入「必须写入文件」说明，表格新增「已写入追踪台」列

验证结果：

• 正向验证：执行关卡A后，产品经理/ 目录下应有审核报告文件，追踪台应有对应条目
• 负向验证：审核流程其他步骤不变

经验感知钩子

本节由 uto-experience-hook Rule 驱动，此处为提示性说明。

执行本 Skill 过程中，若触发以下任一信号，立即追加一行到暂存区（不中断主任务）：

• 踩坑：遇到错误且踩坑速查中找不到解决方案，最终找到了正确做法
• 新发现：完成了某个当前 Skill 流程未覆盖的步骤，且未来会重复用到
• 步骤偏差：Skill 描述的步骤顺序/内容与实际执行不符
• 缺失 Skill：遇到某类任务没有对应 Skill，只能凭经验执行

暂存格式（追加到 .cursor/skills/skill-index/PENDING-EXPERIENCES.md）： | [今日日期] | [本Skill目录名] | [信号类型] | [一句话描述经验内容] | 🔲 待处理 |

所有执行步骤完成后，检查暂存区是否有新增条目。若有，在收尾时告知用户： 「本次执行感知到 N 条经验（已暂存），任务确认跑通后可说「做一次项目复盘」处理。」

⚠️ 强制收尾——写入任务日志（不可省略，不可等用户提示）：

执行顺序铁律：先工具调用 → 确认成功 → 告知用户。禁止声称「已写入」而未实际调用工具。

1. [工具调用-读取] grep 今日 TASK-YYYYMMDD 全部条目，取最大序号 NN → 新序号 = NN+1
2. [工具调用-写入] StrReplace 追加到 `_内部总控/任务日志.md`：
   本次 Skill 执行的核心操作 + 创建/修改的文件 + 用户原始需求 + 遗留事项
3. 工具调用成功 → 输出「📝 任务日志已写入 [TASK-YYYYMMDD-NN]」
   工具调用报错 → 输出「⚠️ 任务日志写入失败，请手动检查任务日志.md」

变更记录（续）

2026-03-19 — v1.2 → v1.3 — F-021全量搜索：路径提取从「最短核心路径」升级为「全量路径分支树」

根因：F-021原则（全量搜索）写入认知体系，当前关卡A只提取「最短完整路径」，忽略所有反馈分支和非正常路径，违反了「全量搜索覆盖所有分支」的要求。

修改内容：

• 修改：Step 2「提取核心路径」→「提取全量用户路径」，包含：所有入口、分支树画法、必须路径/建议路径分级
• 修改：传入子智能体的参数 → 从「核心用户路径列表」改为「全量路径列表+覆盖目标」
• 新增：「全量路径覆盖验证」表格模板（审核报告必须包含路径覆盖摘要）

验证结果：

• 正向验证：下次关卡A时，Step 2 应输出分支树，子智能体应覆盖多个路径（待验证）
• 负向验证：用户类型模拟（挑剔/懒惰/走偏路/第一次用）不变，必问清单不变

验证状态：🔵 待验证

2026-03-19 — v1.1 → v1.2 — 关卡A 改为调用 user-simulator 子智能体

根因：产品文档《AI时代产品组织协作模式》明确要求「审核型智能体必须与创作型智能体使用不同的系统提示词」。当前主 Agent 扮演用户时，带有产品设计者的全部上下文，视角无法真正隔离，审核实质无效。

修改内容：

• 修改：执行流程 Step 3 → 从「主 Agent 扮演用户」改为「调用 /user-simulator 子智能体（前台）」，传入产品定义内容、用户画像、路径列表
• 修改：Step 4 → 从「逐条执行必问清单」改为「接收子智能体返回结果，原样写入报告文件」

验证结果：

• 正向验证：触发关卡A，AI 应启动 user-simulator 子智能体而非自己扮演，子智能体上下文不含产品设计历史（待真实场景验证）
• 负向验证：关卡A 的报告格式、写入路径、issue-tracker 调用逻辑不变

验证状态：✅ 已验证（2026-03-19 user-simulator 子智能体执行 tashan-openbrain 关卡A：独立上下文成功，发现 P0×5 问题，视角真正隔离）

2026-03-22 — v1.4 → v1.5 — D0 补章节锚点（角色认知根系统性审计修复）

根因：同其他3个角色，关卡A D0 无章节锚点，且关卡A 的认知根有独特性：它不只是「了解产品框架」，而是「用判断原则和沙盘推演框架来主动挑战产品设计」，这需要明确指向 §六（判断原则）和 §八.2（沙盘推演）。

修改内容：

• 修改：D0 行 → 精确章节锚点：§六（五条判断原则）+ §八.2（沙盘推演）+ §八.3（识别闭环），明确审核认知框架：用五原则检验假设，用沙盘框架验证闭环完整性

备份路径：history/SKILL_v1.4_20260322_before_d0anchor.md

验证状态：🔵 待验证（关卡A 激活时 D0 指向 §六+§八.2+§八.3）