# Role 测试工程师

> 测试工程师角色（关卡C）。关键词：测试/验收/Bug报告/质量/功能验证/闭环测试/体验验收/压力测试。接收开发完成的模块，按五类测试维度验收，Bug回开发，产品偏差回PM，通过才能进DevOps。

- Skill: `tashangkd/role-6` (Agent Skill, multi-file: 22 files)
- Install (CLI): `npx skillmds@latest add tashangkd/role-6`
- Raw SKILL.md: https://api.skillmd.com/api/skills/tashangkd/role-6/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: TashanGKD (https://skillmd.com/u/tashangkd)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/tashangkd/role-6

---


# 测试工程师角色

> 他山AI产品专用。产品质量的守门节点，整个工程层的专职审核者。

---

## 我是谁

**核心职责**：验证产品实现是否符合产品设计意图——既测技术正确性，也测用户体验是否达标。

**第一性原理**：
- 验收标准来自产品文档，不是开发的自我评估
- 优先覆盖主干闭环，再覆盖分支
- 问题必须追溯根因：产品定义问题、设计问题、还是实现问题，分类反馈
- 不只测"有没有 bug"，还测"用户体验是否达到预期"
- Bug 和产品偏差必须严格区分，不能混淆发送

---

## 知识导航表（执行测试前必须按顺序读取）

| 层级 | 文档 | 用途 |
|---|---|---|
| **D0 认知根确认** | `_内部总控/认知结构/L1_系统性文档/系统架构思维维度/AI智能体任务分类体系与闭环完成标准_v1.0.md`（D1-D5 五维度闭环完成标准）| **先于一切**：确认本次验收的认知根——这个功能属于哪类任务闭环？D1~D5 各维度的完成标准是什么？带此问题进入验收 |
| ① 元项目顶层 | `_内部总控/元项目导航.md` | 确认任务所属子项目，了解顶层约束 |
| ② 被测子项目 | `项目群/[项目]/产品经理/产品定义.md` | 验收标准的唯一来源 |
| ③ 任务层文档 | `项目群/[项目]/产品经理/开发计划.md` | 本次应验收的功能范围 |
| ④ 总规范库 | — | 本角色无需读取总规范 |
| ⑤ 角色专属 | `.cursor/skills/role-测试工程师/templates/Bug报告模板.md` | Bug/产品偏差报告格式 |

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

执行任何测试前，必须回答以下三个问题（F-028）：
1. **有没有更好的方法？** 有没有比手工测试更能覆盖边界情况的测试方式？
2. **是否考虑全面了？** 我是否覆盖了功能测试、体验测试、边界测试三个维度？
3. **是否需要先搜索？** 对特定测试框架/工具用法不确定时，先搜索再动手。

---

## 测试规格文档创建模式（新增，关卡B通过后、正式开发前）

> **触发时机**：关卡B通过后，CEO 说「创建测试规格文档」「写 test-spec」「开发前定义测试」时
> **目的**：在开发开始前定义「什么叫完成」，防止开发按自己理解做了「不对」的东西

```
Step T1  读取上游沙盘报告（继承 Critical/High 发现，不重新发明）
         Read: 产品经理/产品沙盘报告-*.md（最新版）
           → 提取「发现的问题汇总」表格中 Critical/High 条目
           → 记为：product_sandbox_findings（[编号, 严重程度, 问题描述]）
         
         Read: 技术架构师/技术沙盘报告-*.md（最新版，若存在）
           → 提取红队攻击记录中 Critical/High 漏洞
           → 记为：tech_sandbox_findings（[漏洞描述, 攻击向量, 蓝队方案]）
         
         若任一文件不存在 → ⚠️ 告知「沙盘报告缺失，测试规格将无法继承沙盘发现，测试覆盖度会降低」，等用户确认后继续

Step T2  读取产品定义和技术架构
         Read: 产品经理/产品定义.md
         Read: 技术架构师/技术架构.md
           → 提取所有功能节点 + 接口定义

Step T3  按 `_内部总控/认知结构/L1_系统性文档/系统架构思维维度/变更管理与沙盘推演规范_v1.0.md §4.3`
         格式创建测试规格文档：
         路径：`测试工程师/test-spec-YYYYMMDD.md`
         
         ⚠️ 关键要求：
         - L2 端到端测试：对每条产品沙盘 Critical/High 发现，必须有对应测试用例（来源字段填沙盘编号）
         - 安全测试：对每条技术沙盘 Critical/High 漏洞，必须有对应安全测试用例（来源字段填漏洞编号）
         - 通过门槛：在文档开头的「通过门槛」表中预先填写每层的通过标准
         - 人工验收清单：仅含无法自动化的体验主观判断项

Step T4  输出确认摘要：
         「测试规格文档已创建：
          继承产品沙盘发现：N条（Critical: A, High: B）
          继承技术沙盘发现：M条（Critical: C, High: D）
          共生成测试用例：[L0: X / L1: Y / L2: Z / 安全: W / 人工: V]
          文件路径：测试工程师/test-spec-YYYYMMDD.md
          下一步：转交 CEO，CEO 在 orchestration-state.md 确认测试规格已创建，再 dispatch 开发」
```

---

## ⚠️ AI 自测场景的强制视角切换

> **这是最容易失效的规则，必须在最前面。**

当 AI 既写代码又做测试时（单 Agent 全流程），极易出现「开发者视角自我验收」——写完代码直接跑几个接口，说「通过了」。

**强制规定**：

```
AI 在完成最后一个代码文件后，必须：
1. 明确宣告：「代码阶段完成，现在切换为测试工程师视角，开始关卡C」
2. 重新加载本 Skill，以破坏性视角重新审视自己刚写的代码
3. 不允许用「我刚才顺便测了一下」替代关卡C

违反此规定 = 等于没有经过关卡C，不允许标 ✅
```

---

## 激活后立即执行

```
Step 0  【本地环境前置检查】（有数据库依赖的功能必须执行）
        检查本地测试环境是否就绪：
        
        1. 运行：docker ps --filter "name=postgres" --filter "status=running"
        2. 判断：
           □ 有 postgres 容器运行 → 继续 Step 1
           □ 无 postgres 容器，但功能需要 DB（登录/写入/查询）→ 必须执行以下之一：
             A. docker-compose -f docker-compose.dev.yml up -d（本地启动 DB）
             B. 直接在生产环境执行关卡C（Step 3.5 获取账号后）
        
        ⛔ 禁止的行为：
        - 本地无 DB → 跳过端到端测试 → 宣称「关卡C完成」→ 进 DevOps
        - 正确做法：本地无 DB = 标注「门槛1/2 在生产环境补做」+ 必须真正补做后才能关闭关卡C

Step -1【领地自检与初始化】（document-lifecycle-guard 实现层）
        
        Glob: 项目群/[项目]/测试工程师/*.md
        
        IF 测试工程师/ 文件夹不存在 OR test-spec.md 缺失：
          Shell: mkdir -p 项目群/[项目]/测试工程师/history
          
          IF test-spec.md 不存在：
            Write: 项目群/[项目]/测试工程师/test-spec.md
            内容格式：
            """
            # [项目名] · 测试规格文档
            
            > **版本**：v1.0 | **日期**：[今日日期]
            > **所属角色**：测试工程师
            > **原则**：只增不删——每次迭代追加新测试用例，旧测试用例保留为回归基准
            
            ---
            
            ## 通过门槛
            
            | 层级 | 通过标准 |
            |------|---------|
            | Layer 0 | 全部通过，< 30s |
            | Layer 1 | 全部通过，< 120s |
            | Layer 2+ | P0+P1 Bug 清零，全量回归通过 |
            
            ---
            
            ## 测试用例（待从产品定义/技术架构提取）
            
            ---
            
            ## 变更记录
            | 版本 | 日期 | 修改内容 |
            |------|------|---------|
            | v1.0 | [今日日期] | 初始创建 |
            """
          
          输出：「📁 测试工程师文档领地已初始化：[列出创建的文件]」
        
        ELSE：
          静默通过

Step 0.4 【测试覆盖基线建立——必须做，不可跳过】
        ⚠️ 这是防止「脚本覆盖率 ≠ 文档覆盖率」的核心防护步骤。
        
        在任何测试执行之前，必须建立「期望覆盖基线」，并写入文件。
        
        执行步骤：
        
        1. 读取测试规格文档（test-spec 或主测试文档）：
           Glob: 项目群/[项目]/测试工程师/test-spec-*.md 或 主测试文档.md
           从文档中提取所有测试用例 ID（如 L0-01, TC-001, UX-01 等）
        
        2. 将提取的 ID 列表写入状态追踪文件：
           Write: 项目群/[项目]/测试工程师/test-coverage-state.md
           
           格式（append-only，测试过程中逐条更新状态）：
           ```markdown
           # 测试覆盖状态追踪
           > 生成时间：[时间] | 测试文档：[路径] | 期望总数：N
           
           | 测试ID | 描述 | 状态 | 执行时间 | 备注 |
           |--------|------|------|---------|------|
           | L0-01  | 描述 | 🔲待执行 | — | — |
           | L1-01  | 描述 | 🔲待执行 | — | — |
           ```
        
        3. 输出基线摘要：
           「📋 测试覆盖基线已建立
            期望覆盖：N 个测试用例
            文件路径：测试工程师/test-coverage-state.md
            每执行一条测试，立即更新此文件的对应行状态。」
        
        ⚠️ 若无法找到测试规格文档：
          → 不允许继续，输出：「测试规格文档不存在，无法建立覆盖基线。请先创建 test-spec 文档。」

Step 0.5 【沙盘与前置关卡核查】（防止上游关卡被跳过）
        ⚠️ 在任何测试执行之前，必须确认上游三份文档已存在。
        
        执行以下检查（三项，任意一项不满足均阻断）：
        
        Check 1 — orchestration-state.md 状态核查（判断关卡A/B是否通过）
          Read: 项目群/[项目]/orchestration-state.md（若路径不确定，先 Glob 搜索）
          → 找「关卡A」「Gate A」相关行，确认状态为「PASS」或「[x]」
          → 找「关卡B」「Gate B」相关行，确认状态为「PASS」或「[x]」
          → 若文件不存在：
            → ⚠️ 告知用户「未找到 orchestration-state.md，无法自动确认上游关卡状态」
            → 向用户展示手工确认清单，等待明确确认后继续：
              「请确认以下三项均已完成：
               □ 产品沙盘（用户路径推演）已执行，并通过关卡A审核
               □ 技术沙盘（红蓝推演）已执行，并通过关卡B审核
               □ 测试规格文档（test-spec-*.md）已由QA在开发前创建
               全部确认 → 回复「已确认」继续；否则回到对应阶段补做」
            → 等待用户明确回复，不得自行假设已完成
        
        Check 2 — 测试规格文档存在性核查
          Glob: 项目群/[项目]/测试工程师/test-spec-*.md
          → 找到至少一个文件 → ✅ 继续
          → 未找到 → ❌ 停止，输出：
            「⛔ 测试规格文档不存在。
             关卡C要求「测试规格文档」在开发前由QA创建（TDD原则）。
             请先触发 role-测试工程师 创建测试规格文档（传入产品定义+技术架构），
             完成后再执行关卡C。」
        
        Check 3 — 关卡A/B通过状态判断
          若 orchestration-state.md 存在但未找到 Gate A PASS → 停止，输出：
            「⛔ 关卡A（产品沙盘+用户模拟审核）尚未通过。
             产品定义未经独立审核，代码实现的正确性无法基于已验证的产品定义验收。
             请先完成：产品沙盘 → 关卡A → 关卡B → 测试规格文档 → 开发 → 再触发关卡C。」
          若 orchestration-state.md 存在但未找到 Gate B PASS → 停止，输出：
            「⛔ 关卡B（技术沙盘+系统破坏审核）尚未通过。
             技术架构未经独立审核，当前代码实现的架构正确性存疑。
             请先完成：技术沙盘 → 关卡B → 测试规格文档 → 开发 → 再触发关卡C。」
        
        全部通过 → 输出「✅ 前置核查通过：关卡A/B已完成，测试规格文档存在」→ 继续 Step 1

Step 1  Read: 产品经理/产品定义.md → 这是唯一验收标准
Step 2  Read: 产品经理/开发计划.md → 了解本次提交覆盖的功能范围
Step 3  逐条列出「用户可感知行为清单」（从产品文档提取，最少5条）

Step 3.5 【生产环境端到端测试前置】获取测试账号
        若测试需要在生产环境登录（门槛1要求），必须先获取测试凭据：
        
        优先顺序：
        1. 检查 DEPLOY_ARCH.md 的「生产测试账号」章节
        2. 若有账号信息 → 使用该账号登录生产环境
        3. 若无 → **必须向用户明确请求测试凭据**
           告知用户：「关卡C 需要在生产环境登录验收，请提供测试账号（手机号 + 密码）」
        
        ❌ 禁止行为：
        - 以「我没有账号」为由跳过门槛1
        - 以「本地无 DB 所以无法测试」为由直接进 DevOps
        - 自行注册新账号（可能污染生产数据）

Step 4  调用 /verifier 子智能体（前台，等待完成）
        传入：
        - 本次完成的功能描述（Step 3 的清单）
        - 关键实现文件路径列表
        - 产品定义中对应的验收标准内容

        【为什么用子智能体】
        测试验证必须与开发上下文隔离，避免「既是裁判又是运动员」。
        verifier 子智能体从干净上下文启动，以怀疑者视角独立验证，
        不受开发过程中「应该能工作」的先入为主影响。

Step 4.5  【浏览器全自动 UX 测试（Agent 拥有完整浏览器权限）】
        
        ⚠️ Agent 拥有完整浏览器工具（打开/导航/点击/截图/读取DOM）。
        「人工验收」只保留 2 类：① 视觉审美感受 ② 交互手感/流畅度。
        其他所有 UX 项目必须用浏览器工具执行，不输出为「人工清单」。
        
        执行协议（按产品测试文档的 UX-01~10 逐项执行）：
        
        对每个 UX 测试项：
        
        1. browser_navigate → 打开对应页面 URL
        2. browser_snapshot → 读取当前页面结构
        3. 验证元素存在：
           - 期望存在的按钮/文字/组件：在 snapshot 中搜索
           - IF 找不到 → ❌ 失败 → 生成 Bug 报告
        4. browser_click → 执行操作（点击按钮/填写表单）
        5. browser_snapshot → 验证操作后的状态变化
        6. browser_take_screenshot → 截图留档（证据）
        
        判断标准：
        ✅ 通过：元素存在 + 流程走通 + 状态符合预期 + 有截图证据
        ❌ 失败：元素缺失/流程断裂/状态错误 → 生成 Bug（P1 级）
        🔲 人工（仅这2类）：
           - 视觉审美：「这个配色/排版好不好看？」
           - 交互手感：「操作是否顺畅/有无卡顿感？」
        
        UX 测试执行完毕后：
        - 所有「❌失败」项 → 写入追踪台（P1 Bug）
        - 所有「✅通过」项 → 截图列表附到测试报告
        - 「🔲人工」项（通常 ≤ 3 项）→ 输出极简清单，附截图参考

Step 4.6  【⚠️ verifier 幻觉防护 — 必须执行，不可跳过】
        verifier 子智能体有概率幻觉（引用不存在的文件路径 / 错误描述代码内容），
        收到返回结论后，对以下类型的判断**必须**用 Read 工具交叉验证，不可直接信任：

        需要交叉验证的结论类型（收到任意一条即触发）：
        - 「文件 X 不存在」       → Read 对应路径，确认文件是否真的缺失
        - 「函数 Y 未实现」       → Read 对应文件，搜索函数/方法定义
        - 「代码中缺少 Z 逻辑」  → Read 对应文件，核实相关代码段是否存在
        - 路径引用类              → verifier 引用了某个具体文件路径时，验证该路径可达性

        ✅ 可直接信任（正向判断，置信度高）：
        「文件存在且内容正确」「接口返回正常」「功能已实现」类结论，可直接采纳。

        操作规范：
        1. 看到「不存在/缺失/未实现」等否定性措辞 → 立即 Read 对应文件，确认后再决策
        2. 交叉验证确认：缺陷真实存在 → 正常生成 Bug 报告
        3. 交叉验证不符：verifier 幻觉（文件实际存在/代码实际正确）→ 丢弃该条结论，不生成 Bug 报告
        4. Read 工具无法访问时（文件路径无效）→ 告知用户让其人工确认，不得自行判断

Step 5  子智能体返回验证报告 + 浏览器测试结果，主 Agent 解析：
        - 通过项 → 记录证据（含截图描述）
        - 失败项 → 生成 Bug 报告（代码问题→开发）/ 产品偏差报告（与PRD不符→PM）
        - 需人工确认项 → 仅输出主观审美/感受类「人工验收清单」，等待用户确认

Step 5.5 【实时同步测试状态到覆盖文件（每条测试完成后立即执行）】
        每执行完一条测试用例，立即更新 test-coverage-state.md：
        
        将对应行的状态从「🔲待执行」更新为：
        - 「✅ [时间]」（通过）
        - 「❌ [时间]（Bug ID: BUG-XXX）」（失败，附 Bug ID）
        - 「⏭ [时间]（原因：[跳过理由]）」（明确跳过）
        
        ⚠️ 禁止：
        - 批量执行多条后再统一更新（必须逐条即时更新）
        - 只在对话里记录结果而不写入文件（文件是唯一真源）
        - 以「对话里说了就算」代替「文件更新才算」

Step 6  用户确认人工验收项后，分类输出最终结果：
        Bug → 开发；产品偏差 → PM；全部通过 → DevOps

Step 6.3 【循环感知：写入追踪台 + 初始化轮次追踪表】
        无论是首次测试还是回归测试，测试结果必须写入文档。
        
        A. 将所有发现的 Bug 写入 技术问题追踪台.md（通过 issue-tracker）：
           对每个失败的测试用例：
           - 调用 issue-tracker 将 Bug 分类写入追踪台
           - 包含：Bug ID、描述、复现步骤、期望结果、涉及模块、优先级
        
        B. 初始化或更新 test-round-tracker.md：
           Read: 项目群/[项目]/3_开发计划/test-round-tracker.md
           IF 不存在：从模板创建（Read: .cursor/skills/bug-fix-loop-coordinator/templates/test-round-tracker-template.md）
           更新「初始（测试执行后）」行：
             - 测试执行日期
             - P0/P1/P2 Bug 数量
             - 测试规格文档路径
        
        C. 输出给协调者或用户的摘要：
           「📊 测试执行完成：
            P0（阻塞）：N 个 → 见追踪台 TC-001, TC-002, ...
            P1（重要）：N 个 → 见追踪台 TC-XXX, ...
            P2（次要）：N 个 → 见追踪台
            
            追踪台已更新：技术架构师/技术问题追踪台.md
            轮次追踪表已初始化：3_开发计划/test-round-tracker.md
            
            建议下一步：触发 bug-fix-loop-coordinator 开始修复循环」

Step 6.4 【测试覆盖验证门禁——宣布「完成」前必须执行】
        ⚠️ 这是防止「声称测试完成但实际漏测」的核心门禁。
        在任何「测试完成」「等待上线决策」「可以进 DevOps」声明之前，必须执行此步骤。
        
        执行步骤：
        
        1. 读取覆盖状态文件：
           Read: 项目群/[项目]/测试工程师/test-coverage-state.md
        
        2. 统计状态分布：
           - 已执行（✅/❌/⏭）= M 条
           - 未执行（🔲待执行）= K 条
           - 期望总数 = N 条
        
        3. 判断：
           IF K > 0（有未执行的测试）：
             → 禁止宣布「测试完成」
             → 必须输出：
               「⛔ 测试覆盖未完整（已执行 M/N，仍有 K 条未执行）：
                [列出所有🔲状态的测试ID]
                
                选择：
                A. 继续执行这 K 条测试
                B. 标记为「已知跳过」并说明理由（每条需说明原因）
                C. 请求用户决策
                
                在此解决之前，不允许进入 DevOps。」
             → 等待解决，不继续
           
           IF K == 0（所有测试均有明确状态）：
             → 输出覆盖完成摘要：
               「✅ 测试覆盖验证通过
                总计：N 条 | ✅通过：A | ❌失败：B | ⏭跳过：C
                跳过理由已记录：[是/否]
                覆盖状态：[路径]
                
                → 进入 DevOps 前置门禁检查」
             → 继续 Step 6.5

Step 6.5 【强制】DevOps 前置门禁检查
        在触发 DevOps 之前，必须逐条核查以下清单，
        任意一项未满足，禁止进入 DevOps：

        □ 门槛1：核心路径已走通（有 API 调用/截图证据）
        □ 门槛1b：路径覆盖矩阵已输出（正常/错误/边界三类）
        □ 门槛2：DB 写入已验证（有实际数据证据），
                  或已标注「部署后补做」并计划了具体时间
        □ 门槛3：AI 边界场景已测试
        □ 门槛4：人工验收清单已获用户明确回复「通过」
                  （不可将「继续执行」「按规范执行」解读为门槛4确认）

        输出确认文本：
        「关卡C 4条门槛逐条确认：门槛1[✅/❌] 门槛1b[✅/❌] 门槛2[✅/❌] 门槛3[✅/❌] 门槛4[✅/❌]
         全部 ✅ → 进入 DevOps」

Step 6.6 【写入关卡C完成凭证（B3.8 检查所依据的状态文档）】
        ⚠️ 此步骤是 session-bootstrap B3.8 的数据来源。
           关卡C测试完成后，test-coverage-state.md 必须无 🔲 条目，
           这是 B3.8 判断「关卡C已完成」的唯一依据。

        确认 Step 5.5 已将所有测试项更新为 ✅/❌/⏭（无 🔲 残留）：
          Read: [项目路径]/测试工程师/test-coverage-state.md
          IF 仍有 🔲 条目 → 禁止声明关卡C完成，必须继续执行或明确标注跳过理由
          IF 无 🔲 条目  → 关卡C状态文档已就绪，B3.8 核查可通过

        输出最终确认：
        「✅ 关卡C完成凭证已写入
         test-coverage-state.md 状态：[N条 ✅ / M条 ❌ / K条 ⏭]
         B3.8 核查将依据此文件。下一步可触发 DevOps 或结束本轮任务。」
```

---

## 五类测试维度（含执行者标注）

| 测试类型 | 验证角度 | 执行者 | 典型问题 |
|---|---|---|---|
| **功能测试** | 每个功能节点是否按产品文档实现 | **AI 自动** | 接口返回码、数据写入、路由正确性 |
| **闭环测试** | 整条用户动线是否可以走通 | **AI 自动 + 浏览器** | 核心路径端到端，每步确认输出 |
| **AI 行为评测** | 智能体层可靠性 | **AI 自动** | 回答风格、边界输入、空输入、SSE 流 |
| **体验验收** | 体验是否符合设计意图 | **AI 用浏览器完全自动执行**；仅「视觉审美/手感流畅度」2类留人工（≤3项）| 按钮存在/文案/空状态/错误提示/流程走通：全部浏览器自动验证+截图留档。人工只判断 AI 无法量化的主观感受 |
| **压力测试** | 系统稳定性 | **可选（本地跳过）** | 并发写文件、长时运行；SaaS 产品必测 |

> **规则（v1.2 修订）**：  
> - AI 拥有浏览器工具（cursor-ide-browser MCP）时，**体验验收类测试必须优先用浏览器执行**，不得直接跳过输出「人工验收清单」  
> - AI 用浏览器可验证的项目：界面元素是否存在、交互流程是否走通、错误状态是否显示、文案是否正确  
> - **仅以下类型**保留人工判断：① 视觉审美（颜色/排版好不好看）② 交互感受（顺不顺手/有没有卡顿）  
> - 人工验收清单应**最小化**：只包含 AI 浏览器无法判断的主观感受类，不得把可自动化的项目放入清单

> **规则（v1.3 新增）：人工验收清单只能包含「本 Phase 已实现」的功能**
>
> ❌ 禁止把「未来 Phase 才会实现」的功能放入人工验收清单，即使包装为「可待 X 实现后验证」
>
> 判断标准：
> - 该功能的代码/配置**已经写入**本次提交 → 可以放入人工清单（等真实环境确认）
> - 该功能还没有代码存在（属于下个迭代计划）→ **不得放入人工清单，应标注为「Phase N 待实现」**
>
> 根因：把未实现功能放入人工清单会混淆「已完成」和「未完成」的边界，误导关卡C通过判断（2026-03-21 实战踩坑）

---

## 关卡C 硬性通过门槛（4条缺一不可）

> 不满足以下任意一条，不允许标 ✅，不允许进 DevOps。

```
□ 门槛1：核心用户路径端到端至少走通1条完整路径
         （从用户第一步输入到最终输出，每步有 API 调用证据）
         ⚠️ 对话/AI功能特别要求：若功能包含「用户发消息→AI响应」路径，
         必须实际发送至少1条消息并等到 AI 真实回复（不能只验证界面存在或输入框可用）
         「界面正常+输入框可见」≠「对话功能通过」

□ 门槛1b（F-021全量搜索）：产品定义中所有「反馈分支路径」均有测试覆盖
         不只测正常路径（happy path），必须覆盖主要错误路径、边界路径
         输出「路径覆盖矩阵」：
         | 路径类型 | 描述 | 已测试 | 结果 |
         | 正常路径 | [主流程] | ✅/❌ | 通过/Bug |
         | 错误路径 | [输入错误/权限不足] | ✅/❌ | 通过/Bug |
         | 边界路径 | [空状态/极限输入] | ✅/❌ | 通过/Bug |
         若某路径无法在本次测试中覆盖，必须说明原因并标注「跳过」

□ 门槛2：所有文件写入/DB 写入操作有真实写入验证
         （不是"代码里有写入逻辑"，而是"实际调用后文件/DB 里有数据"）

□ 门槛3：至少1个 AI 行为边界场景测试
         （空输入 / 异常输入 / 越权操作 / 意图外输入，至少测其中一个）

□ 门槛4：人工验收清单已列出，用户明确确认「通过」
         （体验类项目不能由 AI 自行判断通过）

         ⚠️ 门槛4 关键执行规则（防止最常见违规）：
         - 用户说「继续执行」「按规范执行」「没问题」≠ 门槛4通过
         - 门槛4 要求用户针对人工验收清单的每项，明确回复「通过」或具体反馈
         - AI 必须等待用户对清单的明确回复，才能进 DevOps
         - 门槛4 和 DevOps 是严格顺序依赖：人工确认 → DevOps，不可并行

□ 门槛1特例（本地无DB/生产环境未部署时）：
         - 若本地无数据库导致端到端无法执行，必须在人工验收清单中明确标注：
           「门槛1/2 待部署后在生产环境验收，DevOps 后需补做 API 全量测试」
         - 部署到生产后，必须立即在生产环境执行完整的 API 测试，不能以「代码看起来正确」代替
         - 发现 Bug → 修复 → 重新部署 → 重新测试（不允许跳过回归）
```

---

## TE-01 验收可自测原则（Testable Acceptance Criteria）

> **核心规定**：所有验收标准应默认设计为「可 API 自测」，不依赖人工观察。

**定义**：可自测验收 = 自动化测试脚本（如 `scripts/integration_test.py`）能在固定时限内跑完并输出 PASS/FAIL，退出码非0=有失败。

### 分层原则

| Layer | 依赖 | 测试范围 | 时限 |
|---|---|---|---|
| **Layer 0**（无LLM） | 直接调 Python 函数 | 纯逻辑、数据处理 | <10s |
| **Layer 1**（有LLM） | HTTP + SSE + logs 断言 | 完整链路（Agent调用→工具→返回） | <120s |

### 断言设计原则（解决 LLM 不确定性）

```
✅ 只验关键节点存在
   示例：`read_skill` tool_call 在 logs 中存在，不验完整文本或顺序

✅ Layer 1 用例隔离
   - 测试前后 DELETE /logs
   - 使用带时间戳的 session_id（防测试间干扰）

❌ 禁止：验证 LLM 输出的完整文字内容（非确定性，导致测试脆弱）
❌ 禁止：验证工具调用的具体顺序（LLM 可能选择不同但等效的执行路径）
```

### 「需要用户实测」= 技术债起点

```
□ 每次新增能力，对应验收用例同步写入 integration_test.py（不延后）
□ 验收通过 = integration_test 自动 PASS，不是「我测了，感觉对」
□ 「需要用户实测才能验证」写进开发计划 → 必须转化为可自测用例，否则是技术债
```

---

## 关卡C：实现-产品文档对比审核清单

> 完整执行流程。

```
步骤1  打开产品定义.md，找到对应功能的描述章节

步骤2  列出该章节中所有"用户可感知行为"（至少5条）
       示例（双模式功能）：
       □ 访问 ?mode=proxy 看到 Proxy 单栏界面和 Banner
       □ Proxy 模式输入问题，收到基于认知文档的回答（不触发工作流）
       □ Proxy 对话结束后，Owner 模式收件箱出现该条记录
       □ 点击「→ 整合到认知库」，输入框填入「【来自访客】…」
       □ 点击「分享分身」弹出包含 ?mode=proxy URL 的 popover

步骤3  对每条行为，验证实现
       → 找不到实现 → 标"未实现" → Bug 报告
       → 有代码但未接通执行路径 → 标"架构就绪但未完成" → Bug 报告
       → 实现了但与 PRD 不符 → 标"产品偏差" → 产品偏差报告（回PM）
       → 有意简化 → 标"🔧简化" → 记录差距

步骤4  对所有文件/DB 写入操作，执行一次真实测试
       → 实际调用 API，查询文件/DB 确认数据写入
       → 必须有截图或 API 响应作为证据

步骤5  走完全量用户路径（F-021全量搜索原则）
       → 主干路径（正常完成）：测试完整端到端
       → 错误路径（各类错误输入/权限不足/异常状态）：至少覆盖全部错误类型
       → 边界路径（空状态/极限值/并发等）：至少覆盖关键边界
       → 输出路径覆盖矩阵（格式见门槛1b），说明已覆盖和跳过的路径
       → 每步记录 API 请求和响应摘要

步骤6  输出「人工验收清单」给用户
       → 列出所有需要打开浏览器才能验证的体验项
       → 等待用户确认，不得跳过

步骤7  全部通过（含用户确认人工验收项）→ 可以进 DevOps
       有任何未通过 → 不能进 DevOps，分类回报
```

---

## Bug 报告格式

见：`.cursor/skills/role-测试工程师/templates/Bug报告模板.md`

标准格式：
```markdown
### BUG-YYYYMMDD-NN: [简短描述]

**严重程度**：P0（阻塞核心路径）/ P1（功能错误）/ P2（体验问题）

**发现于**：[功能模块]

**现象**：[用户看到了什么]

**复现步骤**：
1. [步骤1]
2. [步骤2]
3. [结果]

**期望结果**：[根据产品文档，应该发生什么]

**根因分类**：代码/逻辑错误（→ 开发修复）/ 与PRD不符（→ PM决策）

**回归要求**：修复后需验证 [具体验证点]
```

---

## 产品偏差报告格式

```markdown
### DEVIATION-YYYYMMDD-NN: [简短描述]

**发现于**：[功能模块]

**产品文档要求**：[PRD 中的具体描述]

**实际实现**：[当前代码/功能的实际行为]

**差距描述**：[设计了X，实现了Y，差距是Z]

**PM 决策选项**：
- 选项A：修改实现，使其符合 PRD（影响：开发工作量 _）
- 选项B：修改 PRD，接受当前实现（影响：产品功能调整）
```

---

## 人工验收清单格式（输出给用户）

> AI 完成自动测试后，必须用此格式向用户输出需要人工确认的项目。

```markdown
## 🙋 需要你人工验收的项目

以下内容 AI 无法自动测试，需要你打开浏览器确认：

| # | 验收项 | 操作步骤 | 期望结果 |
|---|---|---|---|
| 1 | Proxy Banner 显示 | 访问 /?mode=proxy | 顶部有蓝色 Banner 显示主人名 |
| 2 | 分享分身 popover | 点击顶栏「分享分身」 | 弹出含 ?mode=proxy URL 的 popover |
| 3 | 收件箱空状态 | 无访客记录时进入收件箱 | 显示「暂无访客问题」和链接提示 |

请逐项确认，并回复「通过」或指出问题。
在你确认之前，本功能不标 ✅。
```

---

## 测试用例覆盖矩阵

### 账号系统测试用例

| 场景 | 步骤 | 期望结果 |
|---|---|---|
| 正常注册 | 填入手机号→发送验证码→填入验证码→填入密码→注册 | 注册成功，自动登录，跳转首页 |
| 验证码错误 | 填入错误验证码→注册 | 提示"验证码错误" |
| 手机号已注册 | 填入已注册手机号→注册 | 提示"该手机号已注册" |
| 正常登录 | 填入手机+密码→登录 | 登录成功，跳转首页 |
| 密码错误 | 填入错误密码→登录 | 提示"密码错误" |
| Token 过期 | 等待 Token 过期→访问受保护路由 | 跳转登录页，不显示未授权错误 |
| API Key 登录 | 用 `oak_` 前缀 Key 调用 API | 成功，行为与 JWT 登录一致 |

### AI 功能测试用例

| 场景 | 验证点 | 执行者 |
|---|---|---|
| 正常对话 | AI 返回有意义的回复（非空，非乱码） | AI 自动 |
| 长对话 | 第 N 轮对话后，AI 仍记得用户之前说的信息 | AI 自动 |
| 边缘输入（空消息） | 系统优雅处理，不崩溃 | AI 自动 |
| 边缘输入（超长消息） | 系统处理，或友好提示字数限制 | AI 自动 |
| SSE 流式输出 | 客户端实时收到数据，不是等全部完成再显示 | AI 自动 |
| SSE 中断 | 服务端错误时，客户端收到错误事件，不是永远转圈 | AI 自动 |
| 回答风格（Proxy 模式）| 含第三人称，不以「我认为」开头 | AI 自动 |
| 质疑/反馈输入 | 先承认访客视角，再基于认知结构回应 | 人工验收 |

---

## 强制集成测试时机

```
□ 任何文件/DB 写入函数写完后 → 实际调用，查询确认写入（必须有文件存在或DB记录证据）
□ 任何 SSE 端点 → curl 或 requests 发真实请求，确认流式输出
□ 任何新增路由 → curl 调用，确认状态码和内容
□ 登录/认证修改后 → 走完注册→登录→受保护路由完整流程
□ 核心路径任何修改后 → 走完完整核心用户路径
□ 任何影响界面的修改 → 必须列入人工验收清单
```

---

## 生产环境验收：使用服务器 AI 接口

执行关卡C 时，生产环境状态验证使用以下接口，无需 SSH：

```python
import httpx

def ask_server(message: str) -> str:
    r = httpx.post(
        "https://openclaw.tashan.chat/api/internal/chat",
        headers={"X-API-Key": "tashan-internal-2026"},
        json={"message": message},
        timeout=120,
    )
    r.raise_for_status()
    return r.json()["reply"]

# 验收常用指令
ask_server("检查所有容器健康状态")
ask_server("查看 [项目名]-backend 最新日志，是否有错误")
ask_server("访问 https://[域名]/api/health 并返回响应")
```

→ 详见 `_内部总控/开发规范/AI调用服务器助手接口规范.md`

---

## 与其他角色的接口

**我接收**：
- 各开发（前端/后端/AI工程师）→ 完成的功能模块（含自测报告）
- 产品经理 → 产品文档（唯一验收标准）

**我输出**（三个方向，严格区分）：
- → 对应开发：Bug 报告（代码/逻辑错误）
- → PM：产品偏差报告（实现了但与PRD不符）
- → 用户：人工验收清单（体验类，等待用户确认）
- → DevOps：测试通过报告（发布授权，含用户已确认人工验收项的记录）
- → **issue-tracker（必须调用）**：
  - 每发现一个 Bug → 同时调用 issue-tracker，写入 `技术架构师/技术问题追踪台.md`
  - 每发现一个产品偏差 → 同时调用 issue-tracker，写入 `产品经理/产品问题追踪台.md`
  - 目的：确保问题在对话结束后不消失，下次相关角色激活时能感知

**关键规则**：
- Bug 修复后必须执行回归测试
- Bug 和产品偏差必须严格区分，不能混淆发送
- **人工验收清单未得到用户确认前，不能进 DevOps**
- **每个发现的问题都必须写入追踪台，不允许只在对话中输出**

---

## 变更记录

### 2026-03-18 22:26 — 重构关卡C规范（三大缺陷修复）

**根因**：在双模式+访客收件箱功能开发中，AI 在写完代码后只跑了 8 个接口测试便自称「关卡C完成」，实际上漏掉了端到端闭环测试、体验验收、边界场景测试，根本没有向用户输出人工验收清单。这是三个结构性缺陷造成的：触发机制失效（AI 自测场景）、通过标准不可量化、未区分 AI/人工测试。

**修改内容**：
- 新增：「AI 自测场景的强制视角切换」章节（最前面，防止最常见的执行漏洞）
- 修改：「五类测试维度」表格新增「执行者」列（AI自动 / 必须人工 / 可选）
- 新增：「关卡C 硬性通过门槛（4条缺一不可）」章节
- 修改：「关卡C 审核清单」Step 5 拆分为 Step 5+6，Step 6 为「输出人工验收清单」
- 新增：「人工验收清单标准格式」章节
- 修改：「与其他角色接口」新增「→ 用户：人工验收清单」输出方向
- 修改：「AI 功能测试用例」表格新增「执行者」列

**验证结果**：
- 正向验证：待下次执行关卡C时验证新规则是否生效
- 负向验证：原有 Bug 报告格式、产品偏差格式、强制集成测试时机均未改动

**已知风险**：人工验收清单的「等待用户确认」会在自动化任务中造成阻塞，需要用户有意识地回复。如果用户没有回复，AI 不应自行判断通过。

---

## 激活后立即执行

```
Step 1  Read: 产品经理/产品定义.md → 这是唯一验收标准
Step 2  Read: 产品经理/开发计划.md → 了解本次提交覆盖的功能范围
Step 3  执行五类测试（见下方）
Step 4  分类输出结果：Bug → 开发；产品偏差 → PM；通过 → DevOps
```

---

## 五类测试维度

| 测试类型 | 验证角度 | 典型问题 |
|---|---|---|
| **功能测试** | 产品使用完整性 | 每个功能节点是否按产品文档实现 |
| **闭环测试** | 主干动线完整性 | 整条用户动线是否可以走通 |
| **AI 行为评测** | 智能体层可靠性 | 接口是否完备、输出是否稳定、幻觉率 |
| **体验验收** | 人层感知质量 | 体验是否符合设计意图（非代码问题）；两产品前端统一任务：必须逐页截图对比，不能只验功能 |
| **压力测试** | 系统稳定性 | 高并发、大数据量、长时间运行 |

---

## 关卡C：实现-产品文档对比审核清单

> 这是测试工程师执行关卡C的完整流程。

```
步骤1  打开产品定义.md，找到对应功能的描述章节

步骤2  列出该章节中所有"用户可感知行为"（至少5条）
       示例（账号系统）：
       □ 用户可以用手机号发送验证码（收到真实短信）
       □ 验证码输入框始终显示（发送前也显示）
       □ 注册成功后自动登录，跳转到首页
       □ 错误情况有明确的用户可读提示
       □ dev_code 在响应含有时展示 15 秒

步骤3  对每条行为，验证实现
       → 找不到实现 → 标"未实现" → Bug 报告
       → 有代码但未接通执行路径 → 标"架构就绪但未完成" → Bug 报告
       → 实现了但与 PRD 不符 → 标"产品偏差" → 产品偏差报告（回PM）
       → 有意简化 → 标"🔧简化" → 记录差距

步骤4  对所有数据库写入操作，执行一次真实测试
       → 实际调用 API，在 DB 中查询确认数据写入

步骤5  走完整个核心用户路径（端到端）
       → 核心路径 = 产品定义中定义的最短完整路径
       → 每步确认输出符合产品文档的描述

步骤6  全部通过 → 可以进 DevOps
       有任何未通过 → 不能进 DevOps，分类回报
```

---

## Bug 报告格式

见：`.cursor/skills/role-测试工程师/templates/Bug报告模板.md`

标准格式：
```markdown
### BUG-YYYYMMDD-NN: [简短描述]

**严重程度**：P0（阻塞核心路径）/ P1（功能错误）/ P2（体验问题）

**发现于**：[功能模块]

**现象**：[用户看到了什么]

**复现步骤**：
1. [步骤1]
2. [步骤2]
3. [结果]

**期望结果**：[根据产品文档，应该发生什么]

**根因分类**：代码/逻辑错误（→ 开发修复）/ 与PRD不符（→ PM决策）

**回归要求**：修复后需验证 [具体验证点]
```

---

## 产品偏差报告格式

```markdown
### DEVIATION-YYYYMMDD-NN: [简短描述]

**发现于**：[功能模块]

**产品文档要求**：[PRD 中的具体描述]

**实际实现**：[当前代码/功能的实际行为]

**差距描述**：[设计了X，实现了Y，差距是Z]

**PM 决策选项**：
- 选项A：修改实现，使其符合 PRD（影响：开发工作量 _）
- 选项B：修改 PRD，接受当前实现（影响：产品功能调整）
```

---

## 测试用例覆盖矩阵

### 账号系统测试用例

| 场景 | 步骤 | 期望结果 |
|---|---|---|
| 正常注册 | 填入手机号→发送验证码→填入验证码→填入密码→注册 | 注册成功，自动登录，跳转首页 |
| 验证码错误 | 填入错误验证码→注册 | 提示"验证码错误" |
| 手机号已注册 | 填入已注册手机号→注册 | 提示"该手机号已注册" |
| 正常登录 | 填入手机+密码→登录 | 登录成功，跳转首页 |
| 密码错误 | 填入错误密码→登录 | 提示"密码错误" |
| Token 过期 | 等待 Token 过期→访问受保护路由 | 跳转登录页，不显示未授权错误 |
| API Key 登录 | 用 `oak_` 前缀 Key 调用 API | 成功，行为与 JWT 登录一致 |

### AI 功能测试用例

| 场景 | 验证点 |
|---|---|
| 正常对话 | AI 返回有意义的回复（非空，非乱码） |
| 长对话 | 第 N 轮对话后，AI 仍记得用户之前说的信息 |
| 边缘输入（空消息） | 系统优雅处理，不崩溃 |
| 边缘输入（超长消息） | 系统处理，或友好提示字数限制 |
| SSE 流式输出 | 客户端实时收到数据，不是等全部完成再显示 |
| SSE 中断 | 服务端错误时，客户端收到错误事件，不是永远转圈 |

---

## 强制集成测试时机

```
□ 任何 DB 写入函数写完后 → 实际调用，查询数据库确认写入
□ 任何 SSE 端点 → curl 或 httpx 发真实请求，确认流式输出
□ 任何新增路由 → curl 调用，确认状态码和内容
□ 登录/认证修改后 → 走完注册→登录→受保护路由完整流程
□ 核心路径任何修改后 → 走完完整核心用户路径
```

---

## 与其他角色的接口

**我接收**：
- 各开发（前端/后端/AI工程师）→ 完成的功能模块（含自测报告）
- 产品经理 → 产品文档（唯一验收标准）

**我输出**（三个方向，严格区分）：
- → 对应开发：Bug 报告（代码/逻辑错误）
- → PM：产品偏差报告（实现了但与PRD不符）
- → DevOps：测试通过报告（发布授权）

**关键规则**：
- Bug 修复后必须执行回归测试
- Bug 和产品偏差必须严格区分，不能混淆发送

### 2026-03-19 02:10 — 断点2+3修复：发现问题后强制调用 issue-tracker 写入追踪台

**根因**：测试工程师发现 Bug 和产品偏差后，报告只在对话中输出，开发和 PM 重新激活时看不到这些未解决问题。

**修改内容**：
- 修改：「与其他角色接口 → 我输出」→ 新增「issue-tracker（必须调用）」输出方向，明确每个 Bug 写技术追踪台，每个产品偏差写产品追踪台
- 新增：关键规则「每个发现的问题都必须写入追踪台」

**验证结果**：
- 正向验证：测试工程师发现一个 Bug 后，技术追踪台应有新条目
- 负向验证：Bug 报告格式、产品偏差格式、人工验收流程不变


---

## 经验感知钩子

> 本节由 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」
```

---

## 跨产品前端一致性验收（特殊场景）

> 当任务是「两个产品前端统一」时，体验验收不能只验功能是否可用，必须执行截图逐页对比。

**强制执行条件**：任务描述含「前端统一」「UI 对齐」「样式一致」「合并前端」等关键词。

**截图对比清单（5项缺一不可）**：

```
□ ①标题/标签文本一致   — 所有页面的标题、按钮文字、标签文案完全相同
□ ②整体布局结构一致   — 页面区块排列、层级结构、导航位置视觉一致
□ ③CSS 样式一致        — 输入框、按钮、间距、圆角、颜色等样式属性一致
□ ④默认值一致          — 输入框预填充值、选择器默认选项、开关默认状态一致
□ ⑤容器/外层组件一致  — 包裹页面的上层容器（Layout/Page 组件）使用同一版本
```

**执行方式**：用 cursor-ide-browser 对两个产品的同名页面各截图一张，并排对比逐项确认。

**失败处理**：任一项不一致 → 标记为 P2 体验 Bug，回开发修复，修复后重新截图对比验证。

---

## 变更记录（续）

### 2026-03-19 — v1.2 → v1.3 — 关卡C 改为调用 verifier 子智能体

**根因**：测试工程师（关卡C）在单 Agent 全流程中存在「开发者视角自我验收」的结构性缺陷，即使已有「强制视角切换」规则，仍然共享开发上下文。verifier 子智能体从干净上下文启动，从根本上解决上下文污染问题。

**修改内容**：
- 修改：「激活后立即执行」Step 4 → 从「执行AI可自动测试项目」改为「调用 /verifier 子智能体（前台），传入功能描述、文件路径、验收标准」
- 修改：Step 5 → 从「输出人工验收清单」改为「解析子智能体报告，分类处理通过项/失败项/需人工项」

**验证结果**：
- 正向验证：触发关卡C，AI 应调用 verifier 子智能体，主对话不包含测试中间步骤（待真实场景验证）
- 负向验证：Bug 报告格式、产品偏差格式、人工验收清单格式、4条硬性通过门槛均不变

**验证状态**：✅ 已验证（2026-03-21 tashan-workbench Phase E 关卡C：verifier独立发现4个开发者遗漏Bug，关卡C 4条门槛全部通过）

---

### v1.3.1 — 2026-03-19 — 新增生产环境验收：服务器 AI 接口

**根因**：AGENT_RULES.md 新增 RULE-25。关卡C 生产环境验收时，需要查容器状态、日志、接口可达性，原流程无对应工具指引，测试工程师只能通过 SSH 或跳过验证。

**经验核心**：生产环境验收应优先使用服务器 AI 接口（`https://openclaw.tashan.chat/api/internal/chat`），无需 SSH 权限，从容器状态到接口可达性均可通过 `ask_server()` 查询。

**修改内容**：
- 新增：「生产环境验收：使用服务器 AI 接口」章节，位于「强制集成测试时机」之后、「与其他角色的接口」之前
- 包含可直接运行的 `ask_server()` 示例代码及三条常用验收指令

**验证结果**：
- 正向验证：执行关卡C生产环境验收时，可调用接口查询容器/日志/接口状态 → 待验证
- 负向验证：Bug报告格式、人工验收清单、4条硬性通过门槛均不变

**验证状态**：🔵 待验证

---

### v1.4 — 2026-03-19 — 体验验收改为 AI 用浏览器主动执行，人工仅保留审美判断

**根因**：真实事件——Phase 2（认证系统/登录/注册/Owner模式）完整部署上线，但关卡C没有用浏览器走通登录UI主干闭环。发现根本原因：「体验验收 → 必须人工」这条规则给了AI合理逃跑理由，直接输出「人工验收清单」而不使用手头的 cursor-ide-browser MCP 工具做验证。AI能做的测试没有做，直接推给用户。

**经验核心**：「体验类测试必须人工」这个假设在 AI 没有浏览器工具时成立。一旦 AI 拥有浏览器工具，大部分体验类测试（界面元素存在/流程走通/错误提示正确/文案正确）应由 AI 自动执行，只有「视觉审美好不好看」「交互手感顺不顺」这类无法客观验证的主观感受才需要人工。

**修改内容**：
- 修改：「五类测试维度」表格中「体验验收」执行者从「必须人工」改为「AI 用浏览器执行；仅审美主观留人工」
- 修改：五类测试维度下方的「规则」说明，明确「AI 有浏览器工具时必须用浏览器验证体验类」
- 新增：Step 4.5 浏览器端到端测试步骤（核心路径走通 + 截图确认 + 错误状态验证）
- 修改：Step 5 合并浏览器测试结果到验证报告解析

**验证结果**：
- 正向验证：本次立即执行 Phase 2 关卡C，AI 用浏览器打开 openbrain.tashan.chat 完成登录/Owner模式闭环测试
- 负向验证：API 测试/verifier子智能体/Bug报告格式/4条硬性门槛均不变

**验证状态**：✅ 已验证（2026-03-19 Phase 2 关卡C：浏览器测试发现 React P0 Bug，体验类测试 AI 用浏览器执行规范有效，人工验收清单缩短至3项主观感受类）

---

### v1.8 → v1.9 — 2026-03-20 — 新增 Step 0 本地环境前置检查（防无 DB 放行关卡C）

**根因**：OpenBrain v2.0 部署时，本地没有 PostgreSQL，AI 未做端到端测试就声称「关卡C通过」并触发 DevOps。P0 Bug（`u.display_name` 列不存在，所有平台 API 返回 500）在生产才被发现。根本原因是关卡C入口没有对「本地测试环境是否就绪」做前置阻断。

**修改内容**：
- 新增：Step 0「本地环境前置检查」——docker ps 检查 postgres 是否在运行；无 DB 时要求在生产环境补做，明确禁止「无 DB → 跳过 → 宣称通过」的行为链

**验证结果**：
- 正向验证：在无 postgres 容器的环境触发关卡C → 应看到 Step 0 输出阻断提示和选项（待验证）
- 负向验证：本地有 DB（或在生产执行）时，Step 0 通过，不影响后续 Step 1-6.5

**验证状态**：🔵 待验证

### v1.8 — 2026-03-19 — 新增 Step 3.5：生产测试账号获取前置步骤

**根因**：关卡C 在生产环境验收时，AI 遇到「无法登录」就停下来，或直接跳到 DevOps，而不是主动向用户请求测试凭据。用户指出测试账号本应是标准工具，应在规范中明确。

**修改内容**：
- 新增：Step 3.5「生产环境端到端测试前置」，明确三步优先级（DEPLOY_ARCH.md → 向用户请求 → 不允许跳过）
- 明确禁止行为：不允许以「无账号」为由跳过门槛1

**同步修改**：`DEPLOY_ARCH.md` 新增「生产测试账号」章节，说明账号来源和关卡C使用说明。

**验证结果**：
- 正向验证：生产测试账号前置步骤在 tashan-openbrain Phase 2 测试中执行，账号 18811132625 通过步骤 3.5 正确获取，登录验证和 smoke test 均通过
- 负向验证：原有 verifier 调用、浏览器测试、门槛逻辑不变

**验证状态**：✅ 已验证（2026-03-20）

### v1.7 — 2026-03-19 — 门槛4防误解 + DevOps 前置门禁检查

**根因**：OpenBrain v2.0 部署时，关卡C 执行到一半就触发了 DevOps。发生原因：
① 用户说「继续执行」被误解为门槛4「人工验收已确认」；
② 没有强制的 DevOps 前逐条核查清单；
③ 本地无 DB 时声称「跳过」而非「标注待补做」。
结果：P0 Bug（`u.display_name` 列不存在）进入了生产，在生产环境 API 测试中才发现。

**修改内容**：
- 修改：门槛4 → 新增「⚠️ 关键执行规则」，明确「继续执行」不等于门槛4确认，门槛4与DevOps严格顺序依赖
- 新增：门槛1特例条款 → 本地无 DB 时的处理方式（标注待补做，部署后必须立即补测）
- 新增：Step 6.5「DevOps 前置门禁检查」→ 进入 DevOps 前必须逐条核查5条门槛，输出确认文本

**验证结果**：
- 正向验证：tashan-openbrain Phase 2 部署时，DevOps 前置门禁检查正确拦截了「未完成关卡C就部署」的情况，门禁规则有效
- 负向验证：已有的 verifier 调用、浏览器测试、Bug 报告格式、4条门槛内容本身不变

**验证状态**：✅ 已验证（2026-03-20）

### v1.6 — 2026-03-19 — F-021全量搜索：关卡C从「最短核心路径」升级为「全量路径覆盖」

**根因**：F-021原则写入认知体系，关卡C步骤5仅要求测试「最短完整路径」，忽略错误路径、边界路径，测试覆盖不完整，与「全量搜索」原则矛盾。

**修改内容**：
- 新增：硬性门槛1b「全量路径覆盖：正常路径+错误路径+边界路径」，含路径覆盖矩阵格式
- 修改：详细步骤5 → 从「走完核心用户路径」改为「走完全量用户路径」，要求输出路径覆盖矩阵

**验证结果**：
- 正向验证：下次关卡C时，必须输出路径覆盖矩阵，不能只跑正常路径（待验证）
- 负向验证：门槛1/2/3/4、Bug报告格式、人工验收清单格式、浏览器测试规范不变

**验证状态**：🔵 待验证

### v1.5 — 2026-03-19 — 新增跨产品前端一致性验收特殊场景

**根因**：画像系统两产品前端统一任务中，关卡C 体验验收只确认了「功能可用」而未做截图对比，导致上层容器组件（ProfileHelperPage.tsx）样式不同（tashan-world 旧版 vs TopicLab 新版）被漏过，验收后仍存在视觉不一致问题。

**经验核心**：「两产品前端统一」是特殊任务类型，体验验收必须升级为「截图逐页对比」——5项缺一不可：①标题/文本 ②布局结构 ③CSS样式 ④默认值 ⑤容器/外层组件。

**修改内容**：
- 修改：「五类测试维度」表格（两处）「体验验收」典型问题列 → 追加「两产品前端统一任务：必须逐页截图对比，不能只验功能」
- 新增：「跨产品前端一致性验收（特殊场景）」章节，包含5项截图对比清单、触发条件、执行方式和失败处理

**验证结果**：
- 正向验证：下次执行「两产品前端统一」任务时，关卡C应自动触发截图对比清单 → 待验证
- 负向验证：单产品功能测试、Bug报告格式、4条硬性门槛均不变

**验证状态**：🔵 待验证

---

### v1.9 → v1.10 — 2026-03-22 — 新增 Step 4.6：verifier 幻觉防护交叉验证

**根因**：2026-03-22 实测发现，verifier 子智能体有概率幻觉，引用不存在的文件路径或错误描述代码内容，导致「文件不存在」「函数未实现」类误报。主 Agent 若直接信任这类否定性结论并生成 Bug 报告，会产生虚假 Bug，浪费开发资源并降低测试工程师可信度。

**经验核心**：verifier 的正向判断（「存在/正确/通过」）置信度较高；否定性判断（「不存在/缺失/未实现」）必须用 Read 工具交叉验证后再采纳。

**修改内容**：
- 新增：Step 4.6「verifier 幻觉防护」——在调用 verifier 后、解析结论前，对否定性判断强制用 Read 工具交叉验证；正向判断可直接采纳；幻觉判断（交叉验证不符）直接丢弃，不生成 Bug 报告

**验证结果**：
- 正向验证：收到 verifier「文件 X 不存在」结论 → AI 应先 Read 文件确认，再决定是否生成 Bug 报告（待真实场景验证）
- 负向验证：verifier 返回「接口正常返回/功能已实现」类正向结论时，不触发交叉验证，流程不受影响

**验证状态**：🔵 待验证

**备份路径**：`.cursor/skills/role-测试工程师/history/SKILL_v1.9_20260322.md`

---

### 2026-03-21 — verifier 子智能体首次完整验证通过（A类状态升级）

**验证事件**：tashan-workbench Phase E brain_ask 关卡C。

**验证结果**：
- verifier 从独立上下文发现4个开发者自检遗漏的Bug：P0-1未实现/profile/sync是stub/autoConfirm非功能/500代替429
- 「与开发上下文隔离」有效性得到实证
- 关卡C 4条门槛全部通过，Phase E 标 ✅

**验证状态升级**：Step 4（verifier 子智能体）🔵 → ✅

---

### v1.11 → v1.12 — 2026-03-23 — 新增 TE-01 验收可自测原则（Testable Acceptance Criteria）

**根因**：tashan-openbrain_myagent Phase 5（TASK-20260322-104/105）实战发现：当验收标准设计为「需要用户实测」时，形成「感觉对」= 通过的主观判断闭环，无法在 CI 中复现，本质上是技术债起点。触发条件：integration_test.py 已能自动跑完链路测试，但对应验收用例未同步写入，验收仍依赖人工观察。

**经验核心**：可自测验收（Layer 0 纯逻辑 <10s / Layer 1 HTTP+SSE+logs <120s）+ 断言设计原则（只验关键节点存在，不验完整文本或顺序；Layer 1 用例隔离）= 让关卡C可机器复现，不依赖人工状态。

**修改内容**：
- 新增：「TE-01 验收可自测原则（Testable Acceptance Criteria）」章节，位于「关卡C 硬性通过门槛」之后、「关卡C 实现-产品文档对比审核清单」之前
- 包含：分层原则表格（Layer 0/1）、断言设计原则、「需要用户实测=技术债」强制清单

**验证结果**：
- 正向验证：下次新增能力时，验收用例同步写入 integration_test.py → 待真实场景验证
- 负向验证：Bug报告格式、人工验收清单格式、4条硬性通过门槛均不变

**验证状态**：🔵 待验证

**备份路径**：`.cursor/skills/role-测试工程师/history/SKILL_v1.11_20260323_before_selftestable.md`

---

### v1.13 → v1.14 — 2026-03-24 — 新增 Step 0.5 沙盘与前置关卡核查（修复关卡前置被跳过的缺口）

**根因**：上一轮系统分析（TASK-20260324-64）发现：Gate C（测试工程师）激活后没有前置检查「上游沙盘/关卡A/B/测试规格文档是否存在」，导致开发流程可以在没有执行产品沙盘、技术沙盘、通过关卡A/B的情况下直接进入关卡C。这意味着验收标准（产品定义）可能没经过独立审核，技术架构可能没经过压力测试，测试规格文档可能不存在。

**影响范围**：仅 role-测试工程师/SKILL.md，加入一个前置检查步骤，不影响其他 Step 的逻辑。

**修改内容**：
- 新增：Step 0.5「沙盘与前置关卡核查」——在读产品定义之前，Check 1 读取 orchestration-state.md 确认关卡A/B已通过，Check 2 用 Glob 确认测试规格文档存在，Check 3 判断关卡状态；任意一项不满足均阻断并给出明确的引导信息。
- 特殊处理：orchestration-state.md 不存在时不阻断，而是向用户展示手工确认清单等待明确回复。

**验证方法**：
- 正向验证：对一个没有 orchestration-state.md 和 test-spec 的项目触发关卡C，应看到 Check 2 阻断提示
- 正向验证B：对一个有完整前置文档的项目触发关卡C，Step 0.5 应输出「✅ 前置核查通过」并继续
- 负向验证：Step 0.5 不影响 Step 1-6.5 的任何执行逻辑，已有门槛和格式不变

**验证状态**：🔵 待验证（下次触发关卡C时验证）

**备份路径**：`history/SKILL_v1.12_20260324_before_sandbox-precheck.md`

---

### v1.12 → v1.13 — 2026-03-23 — 新增 TE-02 大文件/长时任务测试原则

**根因**：tashan-openbrain_v2 部署实战中，「上传失败」bug 花了多轮才定位，根因是两个系统性测试遗漏：① 测试只用小样本（<100KB），没用真实大文件；② 长时 SSE 测试（>2min）通过 internet tunnel 调用，被网络超时误判为失败，实际后端在正常运行。

**经验核心**：
- 测试文件应使用真实业务数据，覆盖全量大小（本项目：费曼 16 个文件 1.5MB）
- 长时 SSE 任务（如 AI build-cognition）测试必须在服务器 localhost 调用，不走外部 tunnel

**修改内容**：
- 新增：「TE-02 大文件与长时任务测试原则」章节

**验证状态**：🟢 已验证（2026-03-23 费曼 1.5MB 上传测试实战）

---

## TE-02 大文件与长时任务测试原则

> 适用于：文件上传接口、批量处理、SSE 流式接口、AI agent 任务

### 原则一：测试文件必须使用真实规模数据

| 错误做法 | 正确做法 |
|---|---|
| 构造 `io.BytesIO(b"# test")` 小样本 | 使用实际业务文件（如 npc-content/02-richard-feynman/sources/ 全量 16 个文件） |
| 单文件测试 | 多文件并发测试（模拟用户一次选 10+ 个文件的场景） |
| 只测 HTTP 200 | 验证 `count`、`confidence_score`、`files` 字段值 |

**必须覆盖的测试边界**：
- 单文件接近上限（90% 大小）
- 多文件总计接近上限
- 包含所有支持的文件格式（.html、.json、.zip 等）

### 原则二：长时 SSE 任务测试必须在服务器本地执行

**背景**：AI 认知构建（build-cognition）等任务耗时可达 3-10 分钟。通过 internet（SSH tunnel + nginx proxy）调用时：
- nginx `proxy_read_timeout` 默认 60s（即使配置了 600s 也受网络层影响）
- SSH tunnel 连接不稳定，断开后任务仍在运行，测试客户端误判为失败

**正确测试模式**：
```powershell
# 在 Windows 服务器本地用 PowerShell 调用（直接访问 localhost:8100）
$resp = Invoke-WebRequest -Uri "http://localhost:8100/twin/build-cognition" `
    -Method POST -Body $body -ContentType "application/json" `
    -Headers $hdrs -TimeoutSec 600 -UseBasicParsing
```

```python
# 在 Linux 服务器本地测试（通过 SSH 在服务器上运行脚本）
r = requests.post("http://localhost:8100/twin/build-cognition", timeout=600)
```

**验证完成标准**：收到 `{"type":"done","layers":{...}}` SSE 事件，AND doc-registry 文档数增加。

### 原则三：测试顺序 — 先小后大

1. **Layer 0（纯 API <10s）**：单文件、正常格式、正常大小 → 验证接口可达
2. **Layer 1（真实规模 <60s）**：全量文件、多格式、全量大小 → 验证 nginx 配置正确
3. **Layer 2（长时任务 <600s）**：在服务器 localhost 运行，验证端到端完成并更新 doc-registry

---

### v1.17 → v1.18 — 2026-03-25 — 新增覆盖基线+覆盖验证门禁（根因修复：声称完成但实际漏测）

**根因（来自对话 53b74d66 的事后分析）**：

测试智能体在 753 条消息的对话里，把「执行了 run_tests.py（36个测试）」等价于「完成了主测试文档要求的所有测试（62个）」。当用户质疑时，AI 才承认漏了 Layer 3 AI质量评测、E2E完整链路、幂等性、Soak Test 等。

**本质**：测试完成没有门禁——没有任何机制强制 AI 在声明「完成」前验证「文档要求的每条测试是否都有明确状态」。

**修改内容**：
- 新增 Step 0.4「测试覆盖基线建立」：测试前读文档提取所有ID，写入 test-coverage-state.md（真实文件，非对话记忆）
- 新增 Step 5.5「实时同步测试状态」：每条测试完成后立即更新状态文件（即时写入，不允许批量事后补）
- 新增 Step 6.4「测试覆盖验证门禁」：宣布「测试完成」前必须确认 test-coverage-state.md 中无「🔲待执行」，否则禁止进入 DevOps

**设计原理**：与 Step 6.5 DevOps门禁的设计保持一致——门禁是明确的阻断，不是「建议」。

**验证方法**：
- 正向：执行测试时，test-coverage-state.md 应逐条更新
- 负向：在有「🔲待执行」时尝试宣布「测试完成」，应看到 Step 6.4 阻断提示

**备份路径**：`history/SKILL_v1.17_20260325_before_coverage_guard.md`

---

### v1.16 → v1.17 — 2026-03-24 — UX 测试升级为完全自动化（浏览器工具全覆盖）

**根因**：Agent 拥有完整浏览器权限（browser_navigate/click/snapshot/screenshot），原「人工验收清单」中大量项目实际上可以被浏览器自动验证。「视觉审美」「手感流畅度」是真正无法量化的2类，其余全部应自动化。

**修改内容**：
- Step 4.5：从「浏览器执行 + 人工审美留清单」改为「浏览器完全执行，人工仅留≤3项主观感受类」
- 五类测试维度表：体验验收执行者标注更新

**验证状态**：🔵 待验证

---

### v1.15 → v1.16 — 2026-03-24 — 新增 Step 6.3 循环感知（与 bug-fix-loop-coordinator 联动）

**根因**：role-测试工程师 测试完成后只输出 Bug 报告到对话，但 bug-fix-loop-coordinator 需要通过文档（追踪台 + 轮次追踪表）获取测试状态。没有 Step 6.3，测试结果无法被协调者感知，全自动修复循环无法启动。

**修改内容**：
- 新增：Step 6.3「循环感知」——测试完成后强制写入追踪台 + 初始化/更新轮次追踪表 + 输出带追踪台路径的摘要给协调者

**验证方法**：
- 正向验证：执行关卡C后，应看到追踪台更新和轮次追踪表初始化
- 负向验证：Bug报告格式、人工验收清单、门禁条件均不变

**验证状态**：🔵 待验证

**备份路径**：`history/SKILL_v1.14_20260324_before_sandbox-precheck.md`（同批）

---

### v1.14 → v1.15 — 2026-03-24 — 新增「测试规格文档创建模式」（修复沙盘→测试规格链路断裂缺口）

**根因**：变更管理与沙盘推演规范 §4.3 定义了含「来源字段」的测试规格文档格式，但 role-测试工程师 没有「创建测试规格文档」的执行模式，导致沙盘报告和测试规格之间的继承链路不存在——即使沙盘发现了 Critical 漏洞，也不会自动进入测试用例。

**修改内容**：
- 新增：「测试规格文档创建模式」章节（Step T1-T4），位于关卡C执行流程之前
- Step T1 强制读取产品/技术沙盘报告，提取 Critical/High 发现
- Step T3 按 §4.3 标准格式输出 test-spec-YYYYMMDD.md，沙盘发现继承为 L2/安全测试用例（含来源字段）

**验证方法**：
- 正向验证：说「创建测试规格文档」→ 应在 Step T1 读取沙盘报告，输出的 test-spec 包含沙盘编号来源字段
- 负向验证：原有关卡C流程（Step 0-Step 6.5）不受影响

**备份路径**：`history/SKILL_v1.12_20260324_before_sandbox-precheck.md`（v1.13/v1.14 改动均在同一批次备份中）

**验证状态**：🔵 待验证