开发者
对开发者来说,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 可见,尽量用权限受限的令牌。
- 过度宽泛的自动允许规则:只对明确的只读命令(如查看状态)设自动允许。
- 测试运行真的会推代码:带写操作的例程,测试时用分支或测试仓库。