Skip to content
按角色看

开发者

开发者如何用 Grok Bot 复现 Bug、整理 Issue、审查 PR、盯 CI,以及设置安全边界。

约 1 分钟读完391 字最近更新 2026-10-20#角色#开发者#GitHub#代码

开发者 ​

对开发者来说,Grok Bot 的云电脑就是一台随时待命的开发机:能克隆仓库、跑测试、开浏览器复现问题。官方介绍中提到的一个内部用法是:工程 Bot 在产品界面里复现 Bug、提交工单,再把修复交给另一个调试 Bot。

典型工作 ​

  • 按 Issue 描述复现 Bug,整理复现步骤和截图。
  • 整理和分类新 Issue,补全缺失信息。
  • 审查 Pull Request,列出问题和建议。
  • 盯 CI 失败,定位原因并给出修复思路。
  • 写脚本、做小工具、更新文档。

示例提示词 ​

复现 Bug

text
看一下 GitHub 上 my-org/web-app 的 Issue #482。在云电脑上拉取代码、本地启动,
按描述复现问题。整理一份复现包:环境、步骤、实际结果、期望结果、截图和相关日志。
先不要改代码,也不要在 Issue 下评论。

Issue 分拣

text
列出 my-org/web-app 过去 7 天新开的 Issue,按"Bug / 需求 / 提问 / 重复"分类,
重复的指出原 Issue 编号,信息不全的写出需要追问什么。给我一张表即可。

PR 审查

text
审查 PR #317:关注逻辑错误、边界情况、缺失的测试和安全隐患。
只列出值得修改的问题,按严重程度排序。审查意见先给我看,不要直接提交评论。

CI 失败排查

text
main 分支最近一次 CI 失败了。看看是哪个任务、哪个测试挂的,
判断是代码问题还是环境不稳定,给出修复建议。

推荐例程 ​

text
当 GitHub 上 my-org/web-app 出现带"needs-repro"标签的新 Issue 时,
自动尝试复现,把复现包发到这个对话里。不要在 GitHub 上评论或修改标签。

事件触发需要相应的账号集成,支持范围以官方最新说明为准。

本地开发环境

如果项目只能在你本机跑,可以授权 Bot 在你注册的本地电脑上执行命令,默认每条都要你确认。详见在自己电脑上干活。

常见坑

  • 给 Bot 生产环境的权限:合并到主分支、部署、改线上配置,都应放在审批之后。
  • 命令行凭证共享:云电脑上的 Git 凭证、云服务密钥对所有 Bot 可见,尽量用权限受限的令牌。
  • 过度宽泛的自动允许规则:只对明确的只读命令(如查看状态)设自动允许。
  • 测试运行真的会推代码:带写操作的例程,测试时用分支或测试仓库。