写Pull Request描述是我最头疼的事。花几小时写代码、解逻辑、调竞态，最后对着空白文本框发呆，试图用一句话让团队明白我做了什么。通常我只能写"修复bug"或"更新API"，技术负责人打回来要求补充上下文，来回拉扯浪费所有人时间。2026年1月，我决定不再手动写PR描述。
我搭建了一个自动化代理，使用GitHub Copilot Workspace API。目标是让AI读取diff、分析提交历史、起草PR描述，我只负责审阅和必要时修改。实验持续整整30天，我追踪了所有能想到的指标，结果和预期完全不同。
我没有直接打开通用聊天机器人——那种做法会失败，因为通用模型缺乏上下文，不懂我们的内部编码规范和单体仓库架构。我写了一个Python脚本，接入GitHub webhook事件。PR创建时触发本地LLM实例，通过Ollama运行Llama-3-405B。本地部署是为了避免把专有代码发到外部API，公司安全合规要求很严。
提示词工程花了三天调优。我得教模型忽略空格改动、聚焦逻辑变更，还要强制它遵循我们特定的markdown模板。核心提示词结构是：让AI扮演高级Staff工程师，审阅git diff和提交信息，按固定格式生成PR描述——包括一句话总结"为什么做"、变更列表、具体单元测试、以及潜在风险。脚本把草稿以评论形式发到PR，不自动填充描述字段，给我留了安全网。
30天内我追踪了三项核心指标，与之前三个月的平均表现对比。时间节省很明显，但"请求修改"次数下降才是意外收获。我的技术负责人指出，AI在列出测试步骤方面比我强——我经常忘记提跑了哪些集成测试，AI会自动扫描测试文件并列出，显著减少了代码评审中的来回沟通。
但并非一帆风顺。AI在diff之外的上下文上表现糟糕。第12天我重构了一个数据库迁移脚本，diff看起来很小，影响却很大。AI写的总结是"更新SQL脚本"，完全没提这会锁定生产表两小时。我手动重写了整个描述，那次差点酿成事故。第19天更奇怪，AI把两个无关的提交混成一个"修复认证流程"，实际上一个是认证修复，另一个是UI调整。这种错误如果漏过，会让回滚变得极其困难。
我还发现了一个微妙问题：AI的描述太"完美"了。它总是用规范的markdown、完整的测试列表、标准的风险提示。这反而让评审者产生虚假安全感——看到格式工整就快速通过，不再深究逻辑。我注意到自己的PR平均评审时间从47分钟降到19分钟，但这不是好事，意味着评审深度在下降。
第23天我做了调整：让AI生成初稿后，我强制自己必须添加至少一句人工注释，说明"为什么现在做这个变更"或"替代方案考虑过什么"。这恢复了必要的上下文，评审时间回升到35分钟左右，但"请求修改"次数保持在低位。
30天结束时的数据很清晰：纯写描述时间从平均23分钟降到4分钟，但审阅AI草稿需要12分钟，净节省7分钟。真正价值不在时间，而在一致性——每个PR都有完整的测试说明和风险提示，团队沟通摩擦大幅减少。技术负责人反馈说，他现在能更快判断哪些PR需要重点关注。
我最终保留了这套系统，但改了规则：AI生成草稿，我补充业务上下文，技术负责人负责验证风险描述是否准确。三方协作比任何单方都更可靠。这个实验让我意识到，AI最适合处理格式化和信息提取，而战略意图和潜在影响评估仍需人类判断。完全自动化很诱人，但混合模式才是目前的最优解。
热门跟贴