用途
qa-persona-testing 用于把有证据支撑的 ICP 或用户细分转化为可执行的行为规格，并以该角色的身份通过浏览器自动化操作系统，最终报告被追踪的缺陷与偏好假设。它是角色模拟，不是端到端测试编写：它发现的是摩擦、困惑、信任断裂与放弃行为，不替代基于断言的回归测试（由 qa-testing-playwright 承担），也不替代真实用户研究（由 software-ux-research 承担）。
主要能力
- 寻找或推导 ICP/角色群体：通过兄弟技能链补充证据，例如 startup-idea-validation、startup-gtm-strategy（明确 ICP 是谁）、research-review-mining、research-painpoint-scanner（真实用户抱怨）、marketing-product-analytics（漏斗与流失行为数据）、software-ux-research（角色方法与偏差控制）、product-management（产品上下文）。
- 把角色转成可执行规格：使用 assets/persona-profile.md 与 references/persona-construction.md 生成含行为特征与场景包的角色档案。行为特征（耐心、技术熟练度、阅读风格、信任姿态、错误反应）是让模拟区别于通用 QA 的关键杠杆。
- 以角色身份运行浏览器会话：每个会话为「一个角色 × 一个场景」，从角色真实入口点（营销页、应用商店链接、分享链接）出发，而非角色不可能拥有的深链。
- 保持模拟诚实（反谄媚）：通过耐心预算、强制放弃、角色内困惑、不使用测试者知识等契约约束。
- 输出改进报告：使用 assets/findings-report.md 与 references/reporting-and-validity.md 生成按严重程度排序的发现、优先级修复建议与有效性说明。
使用方式
第一阶段 — DEFINE（定义角色档案）
目标是得到有证据支撑的角色，而非凭空捏造的刻板印象。先明确测试要支撑的决策（发布就绪、改版检查、转化摩擦、无障碍适配），再用最小充分的兄弟技能链获取 ICP 证据，并对来源与置信度做记录。假设性的角色允许使用，但必须标注为假设，其发现也需相应加限定。每次运行最多选 1-3 个角色，建议一个主 ICP 加一个边界角色（如低技术熟练度或有无障碍需求者）。
第二阶段 — SETUP（配置角色）
复制 assets/persona-profile.md 并填写全部字段；编写场景包：3-7 个以角色口吻表述的任务，每个任务包含入口点、可观察的成功标准和该角色特有的风险点；采用档案中的反谄媚契约（耐心预算、强制放弃、角色内困惑、不使用测试者知识）；按角色配置环境：视口/设备模拟、语言区域，若角色为移动/低带宽用户则加网络限速。
第三阶段 — EXECUTE（执行浏览器会话）
使用浏览器工具驱动应用，方式见 references/browser-execution.md：
- Playwright MCP（browser_navigate、browser_snapshot、browser_find、browser_click 等）——默认方式。
- Chrome DevTools MCP——当还需要控制台/网络/性能证据、设备/网络模拟或按场景隔离浏览器上下文时使用。
- Playwright 脚本——CI 或无 MCP 浏览器时的回退方案。
每一步都要把双通道轨迹记入 assets/session-log.md：角色内「出声思考」+ 角色外观察 + 证据（截图、控制台错误、延迟）。只依据快照中可见内容行动，遵守耐心预算，在该角色会放弃时放弃——每项任务都能完成的代理是失效的模拟。实时记录摩擦事件并按 Nielsen 0-4 严重度标记。
第四阶段 — REPORT（报告与改进）
把会话日志汇总到 assets/findings-report.md：先按严重程度、再按独立可复现性对已确认的机械缺陷排序；未确认的观察放入验证队列；角色重复情况单独报告，模拟频率不能估计真实用户普遍性。每条发现必须引用被记录的步骤，并尽可能给出角色原话与证据物。分为三类清单：改进（带预期效果的优先级修复）、避免（会损害该 ICP 的改动）、保持（通过的流程，用回归测试保护）。依据 references/reporting-and-validity.md 的有效性规则：有证据且可独立复现的机械故障（流程断裂、报错、死胡同）算已确认缺陷；情感/偏好类发现是待真实用户验证的假设，并指明估算普遍性或转化影响所需的缺失分析或真实用户研究。后续交接：严重度 ≥3 交给 qa-testing-playwright 做回归测试；主要偏好假设交给 software-ux-research；测试暴露的 ICP 疑问交给 startup-idea-validation。
适用场景
- 「像 {{首次用户 / 忙碌的会计 / 60 岁 iPad 用户 / 我们的 ICP}} 那样测试这个应用」。
- 「我们的目标客户真的能走完注册引导吗？」
- 「跑一次合成用户/角色化走查，告诉我哪里要改进」。
- 真实用户测试尚不可行时的发布前 UX 快速检查。
- 针对有商业意义的角色对改版流程做回归。
限制
以下情况不应使用本技能，应改用对应方案：
- 编写基于断言的 E2E/回归测试 → qa-testing-playwright。
- 与真实用户做研究（访谈、可用性测试、问卷）→ software-ux-research。
- 不基于角色的启发式/无障碍审计 → software-ui-ux-design、qa-testing-accessibility。
- 验证 ICP 本身是否适合业务 → startup-idea-validation。
- 测试 LLM 代理或机器人（被测系统本身是代理）→ qa-agent-testing。
- 负载、性能或安全测试 → qa-testing-performance、qa-security-testing。
已知陷阱
- 谄媚型角色：LLM 完成每个任务并称赞应用。对策：在档案的反谄媚契约中设置耐心预算与强制放弃规则并执行，交付报告前做谄媚审计。
- 角色漂移：长会话中代理会滑回 QA 工程师口吻。对策：每个场景开始时重读档案，保持双通道日志，标记角色口吻使用测试者词汇的步骤。
- 测试者知识泄漏：角色通过猜 URL 或开发捷径「找到」页面。对策：只能从声明入口点经可见 UI 导航。
- 过度声称：把模拟情绪当作用户研究呈现。对策：报告的 Validity 部分为必填，偏好发现标注为假设。
- 角色扁平化/刻板化：用人口统计漫画代替行为规格。对策：特征必须映射到可观察行为，来源必须注明证据。
- 保真度陷阱：完美的角色遵从读起来像成功，却与漫画化相关——保真度最高的模型产出最刻板的群体（arXiv:2604.24698）。对策：检查会话是否出现刻板行为与漂移，对可归结为「该人群果然如此」的发现打折。
- 单个巨型会话：在一个浏览器上下文中测试所有场景会让状态（认证、购物车、Cookie）在场景间串味。对策：每个会话使用全新上下文。
资源与资产
- references/persona-construction.md — ICP 到角色的转换、行为特征校准、反谄媚契约、漂移检查。
- references/browser-execution.md — Playwright MCP / Chrome DevTools MCP / 脚本执行模式、证据捕获、环境模拟。
- references/reporting-and-validity.md — 严重度模型、排序、报告组装、模拟能与不能声称的内容。
- data/sources.json — 主要来源（研究 + 工具文档）及其验证日期。
- assets/persona-profile.md — 可执行角色规格模板。
- assets/session-log.md — 双通道（角色内/外）会话轨迹模板。
- assets/findings-report.md — 最终报告模板（改进 / 避免 / 保持 / 有效性）。
验证说明
浏览器工具行为（Playwright MCP 工具名、Chrome DevTools MCP 能力、模拟标志）变化很快，规定具体工具调用前须对照当前官方文档验证。关于合成用户有效性的研究主张必须引用具体研究，不要泛化单一基准结果。已知缺陷、框架坑与版本特定变通方案在被当作当前事实前须对照最新一手来源核实。绝不能把模拟的角色反应当作真实用户证据呈现。