Bug 复现：从 issue 到可复现包

💡 一句话总结：用 Grok Bot 建立你的 AI Bug 复现流水线 —— 读报告、连 issue 跟踪和 staging、用全新测试账号亲手复现，产出带确切步骤、截图和环境信息的可复现包，凭据全程不进聊天。

这是路线 B（程序员）的第一课，和性能调查出自同一页官方角色、用同一套官方六步法。本课对应官方 use-cases 页 8 个角色里的 Bug reproduction（Bug 复现专员）。官方给它的定位是：把 bug 报告变成可靠的复现包（reproduction packs）——不是「帮你解读一下报错」，而是开发能直接拿来定位的可靠交付。官方点名的两类连接是 issue 跟踪系统和 staging 环境。

整课约 12 分钟。官方对这个角色还有一条特别要求：测试凭据走安全交接（secure handoff），不进聊天——本课第 3 步专门讲怎么落地。

学完你能做什么

• 建一个「Bug 复现专员」Bot：连接 issue 跟踪系统和 staging 环境，把 bug 报告变成可靠的复现包
• 让 Bot 用全新测试账号在 staging 里逐步复现：确切步骤、预期与实际行为、截图、浏览器和系统信息，能提炼就附最小测试用例
• 测试凭据走安全交接（Vault 代填 / Take over 亲手输），全程不进聊天、不碰生产客户数据
• 把复现流程存成 skill 按名字复跑；新 bug 报告进来可配事件触发的 routine（可选）

为什么用 Grok Bot，而不是网页版 AI？

能力	网页版 AI	Grok Bot
读得到你的 issue 和 staging	❌ 截图加口述，环境全靠你转述	✅ issue 跟踪有连接器直连；staging 用云电脑浏览器自己登录
亲手复现而不是照抄报告	❌ 只能根据描述猜原因	✅ 在 staging 里逐步执行、截图取证，步骤是跑出来的
凭据不泄露	❌ 密码得贴进对话框	✅ Vault 代填看不到值；敏感步骤 Take over 你亲手输
记得住复现口径	❌ 每次对话重新交代一遍	✅ 复现流程存 skill，按名字复跑，口径一致
新 bug 自动开跑	❌ 每份报告手动贴一遍	✅ routine 事件触发（GitHub/Linear/Sentry/PagerDuty）

你现在的困境

• bug 报告写得糊：「点了没反应」，你得来回追问环境、账号、操作步骤
• 复现靠人肉：开测试环境、造测试数据、逐步点一遍，一个下午就没了
• 复现包质量参差：步骤漏一步、截图没存、环境信息忘了记，开发还得再来问一轮

什么时候用这一招

当你需要：

• 把糊成一团的 bug 报告变成开发能直接用的可复现包：确切步骤、预期与实际、截图、环境信息
• 让「读报告 → 进 staging → 逐步复现 → 写包」这条流水线跑起来，你只审包
• 复现过程不碰生产客户数据，测试凭据不进聊天

而且不想：

• 自己挨个开环境、点步骤、截截图
• 把测试账号密码贴给 AI
• 开发回一句「复现不了」，整个流程再重来一遍

🎒 开始前的准备

• 读完 3.2 Skills 与示教——本课第 5 步要把复现流程存成 skill，这也是多数场景页的通用前置
• 有一个能派活的 Bot：还没有就先去 1.5 创建你的第一个 Bot
• 一个能复现 bug 的 staging 环境，加一个全新测试账号（不是生产账号）
• issue 跟踪系统的访问权（Linear、GitHub 这类——连接器或网页版都行）
• 大约 12 分钟，外加第一份复现包出来后的一次人工反馈

跟我做

第 1 步：把 Bug 复现专员的职责和边界写进 Bot 的描述

为什么：官方六步法的第一步，就是把职责、源系统、输出格式和常设边界写进 Bot 的描述——这个角色的两条红线（只用 staging、不碰生产数据）也要写死在这里。

怎么做：新建或打开一个 Bot（侧栏 + → Create a Bot），把描述写成下面这样：

你是我的 Bug 复现专员，负责把 bug 报告变成可靠的复现包。
数据源：issue 跟踪系统、staging 环境。
输出格式：复现包——确切步骤、预期行为与实际行为、截图、浏览器和系统信息；
能提炼最小测试用例就附上，无法核实的内容单独列出。
常设边界：只用全新测试账号在 staging 复现；不使用任何生产客户数据；
issue 只读，复现包贴在对话里等我审。

你应该看到：描述保存在这个 Bot 的详情页里。边界写在这里，意味着以后每一份复现包都遵守同一条红线。

第 2 步：连接 issue 跟踪系统和 staging 环境

为什么：复现包里的事实只能来自你连接的系统——官方为这个角色点名的两类连接是：issue 跟踪系统、staging 环境。

怎么做：两类系统分别处理，5 步连接法的细节见 2.5 连接应用：

1. issue 跟踪系统：先在 Connect apps 里搜（官方文档里 Bot 代装应用的例子就是 Linear——直接说「Add the Linear app」也行）；搜不到的系统让 Bot 用云电脑浏览器登录网页版
2. staging 环境：你们自己的测试环境多半没有连接器——让 Bot 用它云电脑上的浏览器打开，登录凭据存进 Vault，Bot 代填但看不到值
3. 系统提供 MCP server 的，也可以让 Bot 按 URL 添加
4. 授权中断就点 Reconnect（应用上）或 Reopen（聊天里的连接卡上）找回登录页

你应该看到：两边 Bot 都能打开。注意 Added ≠ 已登录——显示 Needs auth 或 Disconnected 时要点 Authenticate 重新授权；staging 在 Bot 浏览器里登录一次后会话会保持（浏览器是共享的，一个 Bot 登录其他 Bot 也能用）。

第 3 步：测试凭据走安全交接，不进聊天

为什么：官方对这个角色的特别要求原话是「Provide test credentials through a secure handoff, not chat」——凭据进聊天记录，等于跟着对话到处跑。

怎么做：按登录方式选路：

1. 普通账号密码：测试账号存进 Vault——Bot 用 Vault 里存的登录代填，值不经过聊天、Bot 看不到
2. SSO、验证码这类表单搞不定的步骤：Bot 会把电脑交给你——在标着 Action needed 的 Computer 卡上点 Take over，亲手完成登录这一步，再点 I'm done 让它继续
3. API key 类密钥：Bot 要的时候填进 secure secret card，字段是遮罩的，值不写进聊天

官方原话：「Never paste passwords or one-time codes into ordinary chat」。另外注意：保存在你笔记本或手机上的指纹、Face ID、Windows Hello 和 passkey 在 Bot 的云电脑上不可用——staging 走公司 SSO 时直接用 Take over。

你应该看到：staging 登录完成、Bot 继续干活；翻遍聊天记录，从头到尾没出现过密码或验证码。

💡 这就是 Grok Bot 的独有价值

网页版 AI 要么没有凭据可用，要么密码必须贴进对话框。Grok Bot 的安全交接让凭据从 Vault 或你手里直接进页面，Bot 全程看不到值——复现包可以放心存档、转发给开发，不用担心凭据跟着包泄露。

第 4 步：用官方 starter prompt 跑第一次 AI Bug 复现

为什么：官方 starter prompt 刻意停在只读复现的 review point——先验证复现包质量，再谈自动化。

怎么做：把 bug 报告（issue 链接或全文）随消息发给 Bot，再发送这段官方 Bug reproduction starter prompt 的中文化版本：

读这份 bug 报告，用全新测试账号在 staging 里复现它。
返回：确切步骤、预期行为和实际行为、截图、浏览器和系统信息，
尽可能附上一个最小测试用例。不要使用生产客户数据。

你应该看到：Bot 在右侧 computer preview 里逐步执行——点开预览能看它的点击、输入和导航。最后回你一份复现包，截图和文件以卡片形式附在回复里，点开可预览。一份合格的复现包含：

• 确切步骤（逐步编号，别人照着能跑通）
• 预期行为与实际行为（分开写）
• 截图（相关状态可见）
• 浏览器和系统信息
• 最小测试用例（官方说 if possible——能提炼就附）
• 无法核实的内容（官方留证据清单的要求：明确列出，不硬编）

第 5 步：把复现包改到可审，存成「bug 复现」skill

为什么：官方六步法要求把结果改到「不用你盯也能审」，再把流程存成 skill，并用第二份输入测一遍。

怎么做：逐条检查 Bot 的产出——步骤确切吗？预期与实际分开了吗？截图带相关状态吗？无法核实的列出来了吗？不合格就打回重做，改到可审再把流程固化：

把刚才 bug 复现的完整流程存成 skill，名字叫「bug 复现」。
包括：源系统（issue 跟踪 + staging）、复现步骤、输出格式（复现包六项），
以及「不使用生产客户数据、凭据只走安全交接」这两条规则。

官方说一个有用的 skill 要说清六件事：何时用、需要什么输入和权限、工作顺序、怎么校验结果、返回什么、什么需要审批。存好之后在任何对话里按名字要它——直接说「运行 bug 复现 skill」就能调用（@ 是给 Bots、群组、routines 和应用的，不出技能）。

你应该看到：Bot 确认 skill 已保存。官方要求用第二份输入测一遍：换一份 bug 报告再跑，核对复现包还稳不稳。私有 skill 库全 Bot 共享，保存细节见 3.2 Skills 与示教。

第 6 步：定义好失败处理，再建 issue 事件触发的 routine

为什么：官方六步法第五步：重试和失败场景定义好之后，才建 routine。这个场景的 routine 不用定时——官方支持事件触发：Slack 消息、GitHub、Linear、Sentry、PagerDuty 事件、邮件、webhook。

怎么做：发送下面这段：

当 issue 跟踪系统里出现新的 bug 报告（GitHub/Linear 事件）时，
运行「bug 复现」skill，把复现包贴在这个对话里。
如果 staging 不可用或无法登录，报告失败，不要用生产环境替代。

发出后，跟 Bot 把官方确认清单的六项过一遍：归属哪个 Bot、时间和时区、输入源、期望结果、审批边界、数据缺失怎么办——对不上就纠正它。

你应该看到：routine 出现在这个 Bot 的 routines 里。新 routine 不立即跑，要等下一个触发——想马上验证就用 Test。routine 在云端执行，合上电脑也跑；每次 run 都消耗用量。

审批线在这步一起守住：把复现包贴回 issue、改 issue 状态是外部动作——留在审批后面。routine 触发的审批卡 30 分钟没人处理会过期，所以 routine 只贴对话，别配需要审批的动作。审批规则细节见 3.1 审批与 Auto Review。

📋 魔法 Prompt

📝 Bug 复现包（官方 starter prompt 结构版）

预期效果：Bot 回一份完整复现包——步骤是它亲手执行过的，预期与实际分开，证据齐全，开发直接能用。

## 角色
你是我的 Bug 复现专员，负责把 bug 报告变成可靠的复现包。
## 任务
读这份 bug 报告，用全新测试账号在 staging 里复现，产出复现包。
## 输入信息
### 必填项
- bug 报告：【issue 链接或报告全文】
- staging 入口：【staging 环境地址和登录方式】
### 选填项
- 重点怀疑范围：【优先检查的功能或最近变更?】
- 已知环境差异：【staging 与生产的已知差异?】
## 输出规范
复现包：确切步骤（逐步编号）、预期行为、实际行为、截图、浏览器和系统信息、
最小测试用例（能提炼的话）；外加一份「无法核实的内容」清单。
## 约束条件
- ✅ 步骤必须是你亲手执行过的，逐步编号
- ✅ 预期与实际行为分开写，事实和推断分开标注
- ❌ 不使用任何生产客户数据
- ❌ 不改 issue 状态、不往 issue 贴评论（贴回 issue 由我审批）

📝 无法复现报告（复现失败也要有产出）

预期效果：复现不了时，拿到一份结构化的「无法复现」报告——试了什么、卡在哪、和报告差在哪，而不是一句「复现不了」。

## 角色
你是我的 Bug 复现专员，刚才没能复现这份 bug 报告。
## 任务
产出一份无法复现报告，帮判断是环境差异、步骤缺失还是报告有误。
## 输入信息
### 必填项
- bug 报告：【原 issue 链接】
- 已尝试的步骤：【复述你实际执行过的每一步和每步的实际结果】
### 选填项
- 报告人环境：【报告里提到的浏览器/系统/账号类型?】
## 输出规范
无法复现报告：实际执行的完整步骤、staging 环境信息、与报告描述的差异点、
最可能的几种解释（标注哪些是事实、哪些是推断）。
## 约束条件
- ✅ 事实和推断分开标注
- ✅ 明确列出无法核实的部分
- ❌ 不为了「复现成功」而编造结果
- ❌ 不使用生产客户数据

🔧 复现包质量反馈（把口径写进 skill）

预期效果：你指出这份复现包缺什么，Bot 把要求写进「bug 复现」skill，下一份明显更稳。

## 角色
你是我的 Bug 复现专员，刚交出一份复现包。
## 任务
对照我的反馈，更新「bug 复现」skill 的复现口径。
## 输入信息
### 必填项
- 这份包的问题：【缺截图 / 步骤跳步 / 环境信息不全 / 预期实际没分开……】
- 正确的口径：【你希望以后每份复现包都做到的】
### 选填项
- 特定类型的额外要求：【比如支付类 bug 必须带时间戳和时区?】
## 输出规范
先复述你总结出的新口径，我确认后再更新 skill。
## 约束条件
- ✅ 口径写进 skill，下次复现开始生效
- ✅ 只补口径，不改审批边界
- ❌ 不为了省事砍掉证据项

检查点 ✅

• issue 跟踪系统和 staging Bot 都能打开：连接器显示 Installed（不是 Needs auth / Disconnected），staging 网页保持登录
• 第一份复现包齐全：确切步骤、预期与实际行为、截图、浏览器和系统信息、最小测试用例（可选）、无法核实清单
• 聊天记录里搜不到测试账号的密码或验证码——登录走的是 Vault 代填或 Take over 安全交接
• 复现流程存成 skill，换一份 bug 报告按名字能复跑
• 全程没碰生产客户数据；routine 只贴复现包，贴回 issue 的动作留在审批

踩坑提醒

❌ 把测试账号密码直接贴进聊天

官方明确要求测试凭据走安全交接，原话是「Never paste passwords or one-time codes into ordinary chat」。正确做法：测试账号存 Vault 让 Bot 代填；遇到 SSO 或验证码，在标 Action needed 的 Computer 卡上点 Take over 亲手输，输完点 I'm done。

❌ 让 Bot「顺手」用生产环境复现

官方 starter prompt 的边界原话：「Do not use production customer data」。复现包是要存档、转发给开发的——生产数据一旦进包，就跟着包到处跑。staging 加全新测试账号是官方要求；staging 不可用就让 Bot 报告失败，别拿生产顶上。

❌ Bot 说「复现了」，步骤却是照抄 bug 报告

复现包的价值在于步骤是 Bot 亲手执行过的。检查方式：每步带截图或实际结果、预期与实际分开写、附「无法核实的内容」清单。逐步都真跑过的复现包，开发才能直接拿来定位；照抄报告的「复现包」只是换了个格式的 bug 报告。

❌ 笔记本上的 passkey / 指纹在 Bot 电脑上失灵

官方排错页明确：保存在你笔记本或手机上的 Fingerprint、Face ID、Windows Hello 和 passkey 在 Bot 的云电脑上不可用。staging 走公司 SSO 时，直接在 Computer 卡上点 Take over，用公司允许的方式（密码加验证码、手机推送）登录，再点 I'm done 交还。

进阶技巧（可选）

• 新 bug 自动开跑：官方支持的事件触发源包括 GitHub、Linear、Sentry、PagerDuty——给「bug 复现」skill 配一个事件 routine，新 bug 报告一进来就自动产出复现包等你审。见 3.3 Routines。
• 复现包归档成 Pages：让 Bot 把复现包整理成 Pages 页面（官方定位：报告这类可读页面），存进 Bot 的 Library——回看某个 bug 当时的环境信息，比翻聊天记录快。见 2.2 文件与可审阅结果。
• 无法复现也是产出：结构化的无法复现报告直接帮报告人补信息——环境差异、步骤缺失、报告有误分开列，回贴到 issue 走审批即可。
• 接上性能调查：复现包如果指向「变慢了」这类性能问题，交给下一课 B2 性能调查——连可观测性工具看 traces，带证据定位热点。

本课小结

• ✅ 一个「Bug 复现专员」Bot + 两类数据源（issue 跟踪、staging），把 bug 报告变成可靠的 AI Bug 复现包
• ✅ 用官方 starter prompt 起步：全新测试账号在 staging 逐步复现——确切步骤、预期与实际、截图、环境信息，不碰生产客户数据
• ✅ 测试凭据走安全交接：Vault 代填或 Take over 亲手输，全程不进聊天
• ✅ 改到可审存 skill，失败处理定义好再建事件 routine；贴回 issue 永远留在审批后面

关键项	本课的值
Bot 角色	Bug reproduction（Bug 复现专员）——把报告变成可靠复现包
连接的应用	issue 跟踪系统（连接器或浏览器登录）、staging 环境（云电脑浏览器 + Vault）
起步 prompt	官方 Bug reproduction starter prompt（中文化版）
凭据交接	安全交接：Vault 代填 / Take over（Computer 卡 Action needed → I'm done），不进聊天
skill	「bug 复现」（官方六要素，按名字调用，全 Bot 共享）
routine	新 bug 事件触发（可选），只贴复现包，staging 不可用报告失败
审批线	不碰生产数据；贴回 issue / 改状态留审批；routine 不配审批动作

下一课预告

下一课 B2 性能调查：复现包指向性能问题时，还是同一套六步，把信息源换成可观测性、分析和事故工具。你会学到：

• 把「checkout 变慢了」变成带证据的定向调查：看仪表盘和 traces，定位置信度最高的热点
• 事实和假设分开写，短报告带截图和直达链接
• 不改警报、不动生产设置——调查只读，变更留在审批