从GitHub Issue到Pull Request：用智能体完成流程

一个好的Issue本质上就是一个提示——有了上下文和验收标准，就能得到一个干净、可核查的Pull Request。

基本流程

一个典型的智能体工作流是这样的：一个GitHub Issue描述一项任务，一个智能体（例如通过评论中的@claude，或一条CI流水线）读取该Issue，在自己的分支上工作，生成代码改动，最后打开一个Pull Request——供人工审查，而不是自动合并。

好的Issue就是好的提示

好提示所遵循的规则，同样适用于好的Issue：清晰的上下文（哪个文件、什么行为、为什么）、具体的验收标准，以及在可能的情况下给出预期行为的示例。一个含糊的Issue会导致一个含糊、往往无法使用的PR——无论是人还是智能体来实现都是如此。

为什么独立分支很重要

智能体绝不会直接在主分支上工作，而是在自己的功能分支（Feature Branch）上工作。这样能让改动保持隔离、可核查，一旦出问题，也能在不触碰主分支的情况下无后果地撤销。

人工审查仍是把关的关口

Pull Request是关键的控制节点：在合并之前，需要有人检查diff、描述以及CI结果。CI检查（测试、代码规范检查、构建）会自动作为额外的安全网运行，但不能替代人对改动是否合理所做的判断。

示例

Issue： “Bug：/api/users 在搜索字段为空时返回500，而不是空列表。上下文：routes/users.js，第42行。验收标准：GET /api/users?q= 应返回状态码200和 []，现有测试 tests/users.test.js 保持通过。” Issue中的评论：@claude 请实现 → 智能体在分支 fix/empty-search 上工作，打开PR “Fix: empty search returns [] instead of 500 (Closes #123)”

🛠️ 练习——自己动手试试

为一个小的bug修复写一个完整、适合智能体处理的GitHub Issue，并让它被实现。

在自己的仓库中选一个范围明确、较小的bug或小改动。
撰写一个Issue，包含受影响的文件/函数、当前的错误行为、目标行为，以及至少一条具体的验收标准。
让一个智能体（例如Claude Code或GitHub集成）在自己的分支上提出实现方案，并打开一个Pull Request。
像审查者一样检查这个PR：标题、描述、diff、与Issue的关联。

✅ 自查清单

☐ 你的Issue是否包含全部四个要素（上下文、错误行为、目标行为、验收标准）？
☐ 智能体是否无需追问就能实现这个任务，还是缺少了某些信息？

小测验

是什么让一个GitHub Issue成为编程智能体的“好提示”？