新用户产品诊断

新用户产品诊断：Agent 扮演第一次来的新用户，亲手操作真实浏览器使用 ZenStory AI 的 Web 产品（以 AI 写作类产品为主），站在用户视角判断产品动线和指引是否清晰、会不会用、有没有继续用下去的欲望；再以 AI 内容创作者身份按内容类型真实完成创作任务（写一篇完整短篇、长篇写满 5 章、短剧大纲加前 3 集、改写/续写/去 AI 味），记录过程中产品展示的一切信息、bug 与输出质量，产出带证据的中文诊断报告。当有人说“模拟新用户”“新用户视角试用”“产品动线诊断”“首次体验评测”“像新用户一样把产品用一遍”“first-run audit”“new-user walkthrough”“onboarding audit”时使用。

本 skill 让 Agent 当一回真正的新用户：不看代码、不看文档，从官网进门，注册、建项目、 用 AI 写东西，一路记下自己的困惑、惊喜和想走的瞬间；然后换成挑剔的创作者，按内容 类型把一件完整的作品写出来，评判产品给出的信息与 AI 产出的质量。最终交付一份团队能直接 据此排优先级的诊断报告。

产品专属信息放在 references/<产品>.md（运行须知）与 references/<产品>-facts.md（产品事实）， 本文只写通用方法。参考文件：

文件	何时读
references/zenstory.md	开跑前读：环境、访问方式、账号、安全边界
references/zenstory-facts.md	首轮体验结束后才读（产品事实，提前读会破坏首轮）
references/scenario-library.md	选创作任务时
references/disposable-inbox.md	需要真实注册、收验证邮件时
references/fiction-quality-rubric.md	评判 AI 产出时
references/report-template.md	写报告时

1. 开跑前确认（缺什么就按默认值写进报告的「假设」）

项	要确认的内容	默认
目标	产品 URL、环境（staging / production）	staging
授权	production 必须有操作者明确授权（一句“可以在线上跑”即可），并写进报告	无授权则只跑 staging
角色	1–3 个 persona（谁、想写什么、熟练度、设备）	见第 3 节
内容类型	每个 persona 一个主任务，从场景库选	每种项目类型各一
账号	一次性邮箱真实注册 / 操作者提供的预验证测试账号文件	staging 可用测试账号；production 走真实注册
预算	每个 persona 最多 AI 消息数、总时长	免费额度内；每 persona ≤ 90 分钟
禁区	不付款、不改他人数据、不联系客服、不用真实个人信息、操作者额外列出的事项	第 8 节全部

预算到了就停，宁可报告写“未完成，原因：预算”，也不要超额。

2. 浏览器操作

首选 agent-browser CLI。第一次使用前先跑 agent-browser skills get core --full，按其中 的 snapshot → ref → 重新 snapshot 循环操作；没有它就用 Playwright 或宿主提供的其他浏览器工具， 方法不变。

宿主的 shell 状态不会跨命令保留（Claude Code 等 Agent 每次 Bash 调用都是新 shell）： export、变量和 cd 下一条命令就没了。所以运行目录只算一次、写成字面路径，persona 每条 命令显式传。

开跑时执行一次，记下它打印的路径：

bash

RUN=~/audit-runs/$(date +%Y%m%d-%H%M)-zenstory-staging   # 末尾换成 <产品>-<环境>；放在任何仓库之外
mkdir -p "$RUN"/shots "$RUN"/logs && chmod 700 "$RUN"
printf 'RUN=%s\nPRODUCT=zenstory\nTARGET=staging\n' "$RUN" > "$RUN/env.sh"
echo "$RUN"                                              # 之后所有命令都用这个字面路径

之后每条命令都先 source 这个文件（把下面的路径换成上一步打印的字面值），并给每条 agent-browser 命令显式加 --session <persona>（每个 persona 一个独立浏览器会话、独立 cookie）：

bash

. ~/audit-runs/20261008-1400-zenstory-staging/env.sh
agent-browser --session novelist open "https://app.example.com"   # URL 由操作者给定
agent-browser --session novelist snapshot -i                     # 拿 @eN refs；页面变了就重拍
agent-browser --session novelist screenshot "$RUN/shots/novelist-01-landing.png"
agent-browser --session novelist console > "$RUN/logs/novelist-console.txt"   # 每阶段结束各收一次
agent-browser --session novelist errors  > "$RUN/logs/novelist-errors.txt"
agent-browser --session novelist network requests --status 400-599 > "$RUN/logs/novelist-failed.txt"
agent-browser --session novelist set viewport 390 844 2          # 移动端那一轮（或 set device "iPhone 15 Pro"）
agent-browser --session novelist close                           # 该 persona 结束时

不要依赖 export AGENT_BROWSER_SESSION=...：它在下一条命令就失效，后续命令会落回默认会话， 多个 persona 共享 cookie，隔离就没了。

多个 persona 并行时各用各的 --session，不关闭别人的会话。

规则：

• 每个关键步骤截图，文件名 <persona>-<序号>-<步骤>.png，报告里引用相对路径。出声思考日志 和截图随步骤写，不要留到结尾凭记忆补。
• 真实等待 AI 生成：发出消息后每 10–20 秒 snapshot 或 wait --text 一次，最长等到产品 自己给出完成/失败信号；记录首字时间和完成时间。不要连点、不要重复发同一条消息。
• 读控制台与失败请求时只记录现象（状态码、接口路径、报错文字），不要把响应里的 token、 cookie 或个人信息抄进日志。
• 遇到受保护的预览环境，按产品参考文件里的方式带访问头，不要把访问令牌打印出来。

3. 角色与第一轮纪律

第一轮不许用内部知识。 体验完之前不读代码、不读产品文档、不读产品事实文件 （ZenStory 为 references/zenstory-facts.md）；只凭页面上看得到的 东西做判断。产品没说清楚的，就当用户也不知道。

为每个 persona 写一段设定再开跑，例如：

• 小白作者：第一次用 AI 写作，想写一篇能发到平台的短篇，手机为主，没耐心看教程。
• 连载作者：日更网文作者，想让 AI 帮忙出大纲、续章节，在意设定一致和章节衔接。
• 短剧编剧：接了竖屏短剧的活，要大纲和前几集剧本，在意格式与节奏。

全程用 persona 的口吻写出声思考日志 $RUN/journal-<persona>.md，每条带时间戳：

text

14:02 [到达] 首页大标题看懂了是写小说的，但“Agent”是什么意思？我先点“免费开始”。
14:05 [注册] 验证邮件 40 秒到，链接点开直接登录了，挺顺。 friction=1

每一步打一个摩擦分：0 顺畅 / 1 小停顿 / 2 明显困惑但自己解决 / 3 卡住需要猜或求助 / 4 放弃。 同时标记惊喜时刻（想继续用的瞬间）和流失时刻（想关掉页面的瞬间）。

第一轮结束后才读产品事实文件（references/zenstory-facts.md），开第二轮核对：哪些困惑是产品确实没讲清，哪些是设计如此； 把核对结果写进报告的「事实与观点」区分里。

4. 账号

• 优先真实注册一个新用户：用一次性邮箱 API 收验证邮件，流程见 references/disposable-inbox.md。
• 账号命名一眼能看出是诊断账号：昵称 audit-<persona>-<YYYYMMDD>，项目名带 [audit] 前缀。
• 绝不使用真实客户账号，也不用自己的私人账号。
• 凭据存到运行目录之外的 ~/.config/product-audit/<产品>-<环境>.json，权限 0600，按 persona 分键合并写入（不要覆盖整个文件，否则前一个 persona 的凭据会丢）；不进任何仓库，不进报告 （报告只写邮箱，不写密码）。
• staging 可以改用操作者提供的预验证测试账号文件；但「注册与验证」阶段就要标为“未覆盖”。
• 撞到额度或付费墙：先完整记录这次体验（文案、是否解释清楚为什么被拦、升级路径几步、价格 是否透明、能否返回继续），然后停在支付页之前。任何情况都不付真钱。 只有操作者提供测试 升级（测试订阅、兑换码、后台开通）时才继续，并在报告里注明。被套餐挡住的能力标为“未覆盖”； 页面上另有相近的免费功能时，可以试，但要分开写，不能把它当成付费能力已经测过。

5. 体验旅程与检查点

按顺序走，每个阶段至少一张截图、一条日志。

1. 到达（官网 → 应用）：五秒测试——只看首屏五秒，写下“它是做什么的、给谁用的、我该点 哪里”。核对首屏承诺与后面真实体验是否一致；从官网到应用的跳转是否顺。
2. 注册与验证：字段多少、错误提示是否说人话、验证邮件多久到、邮件内容与链接是否可用、 验证后落到哪里、有没有被要求填自己不理解的东西（邀请码、偏好问卷）。
3. 首个项目与引导：空状态告诉我做什么了吗？项目类型的区别看得懂吗？引导是帮忙还是挡路， 能不能跳过、跳过后还能找回吗？第一次看到工作区时，能不能在 1 分钟内说出每块区域干什么。
4. 核心创作任务：按 persona 从 场景库 选任务，像真作者一样 写到交付标准（例如短篇写完整、长篇写满 5 章）。记录用了几条 AI 消息、几轮返工。
5. AI 交互质量：有没有进度反馈；首字/完成耗时；看不看得懂 AI 在做什么（读了什么、写到了 哪里）；中途停止、继续、追问是否可靠；AI 有没有复读、反复读同一文件、把内容写错文件类型或 位置、无视明确指令。产出是否真的用上了给定的设定、素材或修改意见（逐条对照，不只看有没有产出）。 出了错能不能自然接着做：提示是否可行动、重试或回答之后是否回到正轨、已经写好的东西有没有丢。 界面提示的“下一步”是否符合真实进度（例如 AI 还在等我回答，界面却催我做别的；照着点了又绕回原地）。
6. 编辑与修改：手动改文字是否顺手、自动保存是否可信；让 AI 局部改写/续写/去 AI 味，结果是否 落在预期位置、能否对比或撤回。
7. 额度与升级：剩余额度是否随时可见、数字是否前后一致；被拦时的说明与升级路径（见第 4 节）。
8. 离开再回来：刷新、关标签再打开、隔一段时间重新登录——内容、对话、选中文件是否还在 （以刷新或重新登录后实际看到的为准，界面显示“已保存”不算）； 版本历史能否找到并回滚；导出能否成功、格式是否可用（打开导出文件看一眼）。
9. 移动端：换手机视口把关键路径走一遍：首页、登录、打开项目、读一章、发一条 AI 消息； 看是否溢出、遮挡、按钮够不着、键盘顶掉输入框。

6. 观察维度

维度	看什么
动线与指引	下一步是否总是显而易见；有无死胡同、绕路、需要猜的地方
动机	惊喜时刻与流失时刻；到第几步时“我想继续用”或“我想走”
可学性	不看帮助能不能完成；第二次做同一件事是否明显更快
信息展示	原始 i18n 键（如 chat.error.xxx）、内部术语、前后矛盾、数字不对（额度、字数、章节数）、中英混杂
Bug	控制台报错、4xx/5xx 请求、白屏/空状态错误、布局溢出、按钮无反应、状态不同步
输出质量	按 写作质量评分表：完成度含字数目标、连贯与跨章衔接、人物一致、节奏与钩子、题材契合、行文自然度/AI 味、格式
Agent 行为	循环、重复读取、写错文件类型或位置、无视指令、过度确认、擅自改动未要求的内容
消耗	每个 persona 用掉的 AI 消息数、总时长、完成任务所需轮次

7. 严重度与证据

级别	定义
P0 阻断	新用户无法完成注册、创建或核心创作；数据丢失；越权或泄露
P1 严重	核心路径能走通但大概率导致流失：明显错误信息、AI 产出不可用、额度/计费数字错误
P2 一般	造成困惑或返工，用户能自己绕过
P3 轻微	文案、视觉、细节打磨

每一条问题都要有：复现步骤、截图路径、期望 vs 实际、对用户的影响；有日志的附日志片段 （去掉敏感信息）。只出现过、复现不了的标“偶现（n 次里 m 次）”，不要升级严重度来弥补证据不足； 专门去找却没出现的写“本轮未复现（n 次里 0 次）”，不写“已修复”或“不存在”；看到了但还不能确定是缺陷的 标“观察”，最高 P2。

事实与观点分开写：事实是“点击后 12 秒无反馈，控制台出现 500”；观点是“我觉得这里应该有 进度条”。观点可以有，但要标明是 persona 的主观感受。设计如此的限制（免费版额度、付费功能被拦； 拦截说明不清仍要记）、操作者明确排除的事项、个人口味，不写成缺陷。首轮盲测发现的，和第二轮或按已知 问题专门去核对的，分开标注来源。

测试工具或测试方自己用的东西出问题（会话串号、页面被工具关掉、一次性邮箱、自己的网络）时，不算产品 问题、也不诊断原因：标出受影响的步骤和结论，能补测就补测，补不了写进未覆盖。产品界面里出现的报错 仍按体验问题记（提示说了什么、能不能恢复），同一时段集中出现的合成一条，不必查原因。

8. 安全边界

• production 只在明确授权后操作；按预算控制 AI 消息数，不压测、不并发刷接口。
• 不付款，不填真实支付信息，不触发真实扣款或退款流程。
• 不使用真实个人信息（姓名、手机、身份证、真实邮箱）；昵称与内容都用虚构的。
• 不给客服、工单、反馈入口灌测试内容；确需验证反馈入口，只发一条并写明“产品诊断测试”。
• 结束时清理或清楚标注创建的内容：删除测试项目，或保留但项目名带 [audit]，并在报告附录列出。
• production 上注册的诊断账号会留在用户表里：能删就删（写明删除方式），删不了就在附录列出邮箱， 提醒团队从增长、激活、留存指标中排除。
• 报告、日志、截图里不出现密码、令牌、cookie、验证链接；截图里有这些就打码或重截。

9. 交付

按 references/report-template.md 写中文报告到 $RUN/report.md，至少包含：一段话结论与“我还会继续用吗”0–10 分及理由；旅程时间线与每步摩擦分； 问题表；输出质量评分与短摘录；按影响/成本排序的改进建议；留给团队的开放问题；附录（使用的账号 不含密码、消耗的 AI 消息数、运行目录）。

交付前自查：

• 每条 P0/P1 都有截图和复现步骤
• 输出质量评分附了原文摘录，而不是只给分数
• 报告与日志里搜过 password、token、Bearer、cookie，没有泄露
• 创建的账号与内容已清理或标注，附录已列出
• 结论里的“会不会继续用”与旅程中的流失时刻能对上
• “本轮未复现”“未覆盖”没有写成“已修复”，受测试工具或外部问题影响的部分已标注