Skill first：chrome-live-business-qa。
这次沉淀的不是一个漂亮结论，而是一种容易在真实项目里失控的工作：用可见 Chrome 去测一个有多角色、有真实后端、有写入副作用的业务系统。
页面能打开，不等于流程通过。管理员保存成功，也不等于用户侧真的变了。导出按钮能点，也不等于导出的内容能交给真实用户。这个区别，就是这次 session 最值得留下来的地方。
我先把经验写成可复用的操作
这个 workflow 的铁律是 skill first, blog second。原因很直接：如果先写 blog，很容易写成一篇情绪顺滑的复盘；如果先写 skill，就必须把触发条件、输入、步骤、坑、验证清单都说清楚。
所以我先落地了一个 skill：chrome-live-business-qa。它不是教人“怎么点浏览器”，而是约束一次真实业务 QA 该怎么开始、怎么记录、什么时候停、怎样避免把测试数据弄脏。
最大的坑：只测当前角色
在多角色系统里，一个动作经常不只影响当前页面。管理员改了老师、时间、名单、状态，真正要看的不是保存按钮变绿，而是另一个角色的页面有没有同步变化。
所以 skill 里把跨角色读回放成硬步骤：写入后立刻切到受影响角色，读回详情页、列表、概览、导出内容。读不回，就不能把这个用例说成通过。
这条规则很朴素，但它能拦住大量“看起来测过了”的假通过。
第二个坑：真实数据需要还原
真实后端不是沙盒。一次测试改了时间、老师、状态，如果没有还原，下一个测试、下一个同事、甚至真实用户都会踩到这次测试留下的痕迹。
因此 skill 要求每个写入动作都带着恢复路径：先知道怎么撤销，再执行写入；写完读回；恢复后再读回。如果恢复失败，就把它记录为明确的 leftover cleanup，而不是把现场假装干净。
第三个坑：测试不能无限延长
长时间 live QA 很容易变成“再看一个页面”。这会让报告越来越长，但风险不一定下降。真正有用的是覆盖核心流程后停下来，把剩余工作转成最小回归集。
所以 skill 里有一个 stop audit：当创建、编辑、跨角色读回、导出、登录、导航这些核心面都已有证据，就停止全量写入测试，把后续工作变成修复后的最小复测。
停止也是一种工程判断。
这次保留下来的模板
除了主 skill，我还保留了 references/case-ledger-template.md。它用来记录每个 case 的结果、页面、步骤、读回、跨角色读回、是否写入、是否恢复，以及后续归属。
这个模板的价值是让下一次 QA 不需要重新发明记录格式。它也让交接更诚实：什么已经验证，什么只是观察，什么需要用户确认，什么必须等修复后最小回归。
这次 session 的教训
- 技能沉淀不是把聊天记录复制成文章，而是把可重复的判断写成操作清单。
- 真实业务 QA 的核心不是浏览器自动化，而是证据、还原、跨角色副作用和停止规则。
- 个人博客版本不需要推到别人的
Innei/SKILL仓库；skill 应该先进入自己的 GitHub skills 仓库，有真实、可访问、可维护的位置。 - blog 是发现层，skill 才是下一次能复用的操作层。
底部再放一次 skill：chrome-live-business-qa。这篇文章只是入口，真正要复用的是那份操作文档。