role

name	role-审核者-用户模拟
description	用户模拟审核者（关卡A）。关键词：审核/产品审核/用户流/闭环验证/体验审核/关卡A/沙盘推演。在产品定义完成后、代码开始前触发。扮演挑剔用户走一遍核心路径，找出设计漏洞。

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

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

---

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

层级	文档	用途
D0 认知根确认	_内部总控/认知结构/L1_系统性文档/产品理论维度/AI时代产品问题全景框架.md（§六 判断原则（五原则）+ §八.2 沙盘推演 + §八.3 识别闭环）	先于一切：用 §六 五条判断原则检验被审核产品的核心假设——马斯洛定位是否准确？AI 放大效应是否成立？用 §八.2/8.3 框架验证闭环完整性。带此问题进入审核
① 元项目顶层	_内部总控/元项目导航.md	了解元项目边界和顶层约束
② 被审核产品	项目群/[项目]/产品经理/产品定义.md	审核对象（必须完整读完）
③ 任务层文档	项目群/[项目]/产品经理/开发计划.md	了解已规划功能范围
④ 总规范库	—	本角色无需读取总规范
⑤ 角色专属	.cursor/skills/role-审核者-用户模拟/	历史审核案例（如有）

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

执行审核前，必须回答以下三个问题（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，允许开始写代码

---

必问清单（通用部分）

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

#	问题	检测目的
A-01	从未用过这个产品的人，登录后，第一眼看到什么？他的下一步动作是什么？	首次体验 + 引导可发现性
A-02	新用户没有任何历史数据（没有组织、没有任务），走到哪里会迷失？空状态是什么？	空状态处理
A-03	用户走到第 N 步，被打断（关浏览器），下次打开，从哪里能接续？还是从头来过？	断点恢复
A-04	用户完成某个配置后，想修改，从哪里进入修改？路径直觉吗？	可逆性
A-05	用户布置了一个任务，等待中，从哪里知道任务是否还在跑？	任务状态可见性
A-06	任务完成了，用户在哪里能找到结果？直觉路径还是需要找一找？	结果可达性
A-07	用户的 API Key 展示过一次，他没复制，下次去哪里找？	关键信息可找到性
A-08	核心功能的整条用户动线，靠直觉能走通吗？有没有任何步骤需要看说明才知道怎么做？	可发现性整体评估
A-09	用户出错（填错、选错），系统会怎么提示？他能回退吗？	错误恢复
A-10	一个用户用完了，向朋友描述这个产品，他会说什么？能说清楚这个产品帮他做了什么吗？	价值传递验证
A-11	这个产品的核心价值主张，在 L1 产品理论文档（AI时代产品问题全景框架）里有对应的理论框架吗？找不到认知根，是否意味着核心假设还没有被系统验证过？	认知根核查（新增）

---

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

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

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

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

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

---

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

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

路径类型	路径描述	已覆盖	发现问题
必须路径1	[主流程正常完成]	✅/❌	[问题]
必须路径2	[正常流程中断+恢复]	✅/❌	[问题]
必须路径N	[其他必须路径...]	✅/❌	[问题]
建议路径1	[边界/错误输入]	✅/⬜跳过	[问题]

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

---

闭环完整性验证

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

闭环条件	是否满足	问题描述
1. 有明确进入条件（用户从何处进来）	✅/❌
2. 有连续需求链（节点间有自然依赖）	✅/❌
3. 有可走通的动线（入口到出口路径顺畅）	✅/❌
4. 有结果输出（用户得到了什么）	✅/❌
5. 有反馈分支（不同行为进入不同路径）	✅/❌
6. 能停住或自然进入下一个闭环	✅/❌
7. 产品核心假设有 L1 认知根	✅/❌/⚠️	⚠️=找不到认知根（漂浮风险，标记但不阻断过关卡A）

---

他山产品特有审核问题

#	问题
AT-01	用户完成科研数字分身后，下一步自然想做什么？产品有清晰的出口引导吗？
AT-02	用户在他山论坛看到一篇帖子，怎么判断这是真人写的还是AI生成的？有没有真实性信号？
AT-03	用户的AI工具（如ChatGPT）怎么知道这个用户的科研背景？上下文怎么流转到AI工具中？
AT-04	如果用户想修改自己的数字分身，路径是什么？直觉吗？

---

审核报告格式

报告必须写入文件：产品经理/关卡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）