Skills-Safe适合谁
- 每天处理大量 Issue 和 PR 的开发者或项目维护者
- 需要让 AI 帮忙写 PR 描述、总结变更内容的人
- 想用自然语言查询仓库状态（"最近合并了什么"、"有哪些 open 的 bug"）的人
- 熟悉 Git 工作流、能快速判断 AI 操作是否正确的中高级开发者
不适合谁
- Git 操作不熟练、看不懂 diff 的新手开发者
- 打算让 AI 直接推送代码到 main 分支的任何人
- 团队协作仓库中还没跟团队讲清楚 AI 使用规范的人
- 对仓库有 Admin 权限但没有备份机制的情况下使用
3 分钟上手
安装
npx clawhub@latest install github
配置
需要创建 GitHub Personal Access Token：
- GitHub 设置 → Developer settings → Personal access tokens → Fine-grained tokens
- 权限建议从最小开始：只给
Issues: Read and write和Pull requests: Read and write - 不要给
Administration权限，除非你明确知道为什么需要
第一次正确使用
先从只读操作开始：
- "列出仓库最近 5 个 open 的 Issue" — 确认连接正常
- "帮我总结这个 PR 的主要变更" — 测试它的理解能力
- 然后才考虑写操作
典型使用场景
场景 1：Issue 分类与响应
每天早上让 AI 扫描新 Issue，自动打标签（bug / feature / documentation）、生成初步回复草稿——你审核后再发送。节省大量重复劳动。
场景 2：PR 描述自动生成
提交代码后让 AI 根据 diff 自动生成规范的 PR 描述（问题背景 + 解决方案 + 测试说明 + Breaking Changes 提示）。
场景 3：仓库健康巡检
定期让 AI 检查：有哪些 stale Issue、哪些 PR 等待超过 7 天没有 review、哪些 milestone 进度落后——生成周报给项目负责人。
常见翻车点
- 误操作关闭了重要 Issue：AI 误判 Issue 状态，把一个还在讨论中的 Issue 关掉
- PR 合并时机不对：让 AI "处理 ready 的 PR" 结果它合并了一个你其实还想再改的分支
- 权限范围不清导致意外写入：给了 repo 权限后，AI 可能修改你没预料到的文件
- 把 AI 生成的 Issue 内容当最终版本：它写的 bug 描述可能遗漏关键复现步骤
风险提示
权限风险
- 仓库写权限：可创建/关闭 Issue，合并 PR，推送代码
- 对真实代码库的影响：一旦操作无法简单撤销（merge 后回滚有成本）
使用风险
- 仓库结构误读：AI 对你的项目约定不了解，可能做出不符合团队规范的操作
- 团队协作冲突：你的 AI 操作记录会出现在仓库历史中，需要与团队透明沟通
建议
- 先在个人测试仓库练习，再应用到正式项目
- Token 权限从 Read-only 开始，按需逐步开放写权限
- 所有写操作前加确认步骤："操作前先告诉我你要做什么"