SCENARIO · 工程

预发环境复现缺陷包

阅读约 7 分钟核对日期 2026-10-20

事实来源

docs.x.ai/grok-bot/use-cases · docs.x.ai/grok-bot/computer-and-apps · docs.x.ai/grok-bot/approvals-security-and-privacy

官方 Bug Reproduction 角色：把报告变成可复核的复现包。连接 issue 跟踪、预发环境、浏览器与网络工具。它的价值不在「替你修 bug」，而在于把含糊的「不好用」变成别人能跟做的步骤、期望与实际、截图和环境字段。

官方起手示例（意译）是：阅读缺陷报告，在预发用全新测试账号复现；交付精确步骤、期望与实际、截图、浏览器与系统信息、相关控制台或网络笔记，可能的话给最小用例；不要使用生产客户数据。凭证走安全交接，不要贴进普通聊天。

适用

有预发 / 测试环境与测试账号，且账号权限与生产隔离。
需要步骤、期望/实际、截图与环境信息，而不是一句「我复现了」。
缺陷报告已经写在 issue 跟踪或文档里，Bot 能只读访问。
你愿意先人工验收一份复现包，再考虑「needs repro」类事件例程。

什么时候不该用

没有预发，只能进生产——本场景明确禁止用生产客户数据；没有隔离环境就先别上自动化。
报告本身只有「打不开」三个字、没有任何环境线索，而你又不肯补第一轮澄清——Bot 会在猜测里烧用量。
你其实要的是修复并开 PR——那是 Cloud Agent 或云电脑 CLI 的活；复现包先完成，再谈修。
凭证只能通过聊天明文交接——停下来，改用官方说的安全交接 / 接管登录。

准备

Bot：可用码初或自建「复现」职责 Bot。描述里写死：「只用预发与测试账号；不用生产客户数据；不改生产配置。」
连接器：issue 跟踪（GitHub Issues / 其它 tracker）、必要时浏览器。装好后每次任务用 @ 挂载。
测试凭证走安全交接，不要贴进普通聊天。需要登录时准备好 Take over。
Auto Review：对外同步 issue 评论、改生产看板之类动作保留 Ask first（若你的流程需要人工确认再回帖）。

步骤

官方风格首单（改写为中文）

阅读这份缺陷报告，在预发环境用全新测试账号复现。
交付：精确步骤、期望与实际行为、截图、浏览器与系统信息、相关控制台或网络笔记；可能的话给最小用例。
不要使用生产客户数据。不要改生产配置。

贴报告或 issue 链接（只读连接器优先）。用五要素补全：结果=复现包；来源=该 issue + 预发 URL；约束=不用生产数据、不改生产；交付=步骤/期望实际/截图/环境；停止点=回帖或改状态前先问你。
需要登录时用 Take over 或安全请求。 你自己完成登录与二次验证，确认已登录页加载后再让它继续。不要把密码或验证码发在普通聊天里。
检查复现包是否含证据与环境字段。 打开成果卡里的截图与笔记，按下方清单勾选；缺一项就让它补同一份产物，不要另起互不相干的副本。
跑稳后可存技能；事件触发示例见 Routines「needs repro」。宽匹配「每条新消息」不要用。

五要素版复现单

结果：把 ISSUE-1234 变成可复核的复现包。
来源：@GitHub 上的该 issue；预发环境 URL 见描述；只用我提供的测试账号。
约束：不用生产客户数据；不改生产配置；不在 issue 下自动评论。
交付物：编号步骤、期望 vs 实际、截图、浏览器/OS/预发标识、控制台或网络笔记、可能的最小用例。
停下来等我的节点：任何写回 issue、任何通知客户、任何生产变更。