用编码智能体自动修 Issue 并提 PR：从工单到合并请求的流水线

团队里总有这样一批工单：报错文案改一改、空指针补个判断、文档和代码对不上的小修小补。它们不复杂，却占掉不少切换上下文的时间。编码智能体 + gh CLI 能把"看 Issue、改代码、跑测试、开 PR"串成一条流水线：人只负责写清任务卡和最后点合并。本教程给一套可复制的脚本。

🧩 本教程适合：有 GitHub 仓库、想自动化处理小修小补的团队或独立开发者。你需要 gh 已登录、一个编码智能体（Claude Code 或 Codex 均可）和本地能跑的测试命令。

先搞懂：什么样的 Issue 适合交给 Agent 修

不是所有 Issue 都该自动化。适合的交给 Agent，能省时间；不适合的硬塞，反而要花更多时间擦屁股。

永远不要让 Agent 自动合并。它的产出是"待审 PR"，合并开关必须握在人手里。下面整条流水线都遵守这条红线。

1 两条登录先打通

gh 负责和 GitHub 交互，编码智能体负责改代码。先确认两者都已鉴权：

gh auth login
claude  # 打开一次确认登录，或用对应产品的登录命令

💡 在 CI 里用 gh 的令牌替代交互登录；编码智能体的令牌也走机密变量，别写死在脚本里。

2 让 Agent 拿到上下文而非裸链接

不要只丢一个链接给 Agent。先把 Issue 的标题和正文取出来，连同"验收标准"一起写进任务描述：

ISSUE=123
gh issue view $ISSUE --json title,body,comments   --jq '"标题: " + .title + "
内容: " + .body'

Issue 里的外部链接、复现步骤要核实。Agent 会照着做，过时的复现步骤可能把它带偏。把验收标准（怎样算修好）明确写进任务卡。

3 分支隔离，绝不脏主分支

先切出专属分支，再用无头模式让 Agent 修复，并明确告诉它"不要自己开 PR"：

BRANCH="fix/issue-$ISSUE"
git checkout -b $BRANCH
claude -p "修复 GitHub issue #$ISSUE。
复现问题、实现修复、运行测试，但先不要创建 Pull Request。"
git push -u origin $BRANCH

🔑 分支名带 Issue 号，后续 PR、提交、回查都能一眼对应。让 Agent 只负责改代码，开 PR 这一步由你或脚本显式执行。

4 没过门槛就不允许开 PR

Agent 改完不等于改对。在开 PR 前，由脚本（不是 Agent）跑测试，失败就停：

npm test
npm run typecheck

测试命令由人的脚本执行，不要委托 Agent 自己"说过了"。让 Agent 跑测试容易被它一句"已通过"糊弄；由外部命令的真实退出码决定能不能继续。

5 用 gh 生成 PR，人再来审

测试和类型检查都过了，再用 gh 开 PR。--fill 会按分支提交自动生成标题与正文：

gh pr create --fill   --title "fix: 修复 issue #$ISSUE"   --body "由编码智能体在 fix/issue-$ISSUE 上完成，已通过测试与类型检查，请人工复核。"

💡 PR 描述里写清"谁做的、过了什么门槛、还需人审什么"，reviewer 一眼就知道该看哪里。

6 封装脚本，合并仍由人点

把上面 Step 3-5 封成一个脚本，配到定时任务或 Issue 评论触发器上；CI 负责二次验证，合并仍由人点。几条硬红线：

# 红线清单（写成脚本里的断言）
# 1. 只在 fix/issue-* 分支上操作
# 2. 测试/类型检查退出码非 0 立即中止
# 3. 不得自动 merge，只创建 PR
# 4. 涉及密钥/迁移的 Issue 直接转人工

分支、测试、合并三件事各自独立。Agent 只能在分支里改；测试由外部命令把门；合并权永远不在流水线里。任一环节被突破，自动化就从"省力"变"闯祸"。

现象	原因与处理
Agent 改了不相关的文件	任务卡范围没写清；显式要求"只改与 issue 相关的文件"
测试说通过其实没跑	让外部脚本跑测试并读退出码，别信 Agent 自述
PR 描述太笼统	用 --fill 并补一句"已通过 X 与 Y，请复核 Z"

← 返回教程中心