超过四成PR从AI初稿开始，程序员的工作重心变了吗？

一份代码改动交给同事审查之前，谁先写下了第一版？GitHub 的答案正在快速变化。

2026年10月28日发布的 Octoverse 报告显示，9月 GitHub 上超过40%的拉取请求（PR，即提交给团队审查和合并的代码改动）从可识别的 AI 智能体初稿开始；3月这一比例还是17%。9月此类 PR 达到1.1亿个。GitHub Octoverse 2026

这组数字把一个问题推到团队面前：当提交候选代码越来越容易，研发流程能否同样快地判断哪些改动值得接纳？它关系到程序员如何分配时间，也关系到公司该怎样衡量软件生产率。

一 初稿成为可以委派的任务

代码补全帮助开发者写完下一行，智能体则能接手一段工作。以 GitHub 的产品机制为例，开发者可以交付任务，让智能体检索仓库、修改文件、运行测试，再根据失败结果继续调整；异步模式允许人先去做别的事，之后回来审查结果。GitHub 智能体说明

这使 PR 多了一层意义：它成为人与智能体之间的交付界面。过去，程序员通过亲手实现逐步理解问题；现在，一部分理解工作需要提前完成，变成清楚的目标、允许修改的范围和验收条件。

例如，把“修复订单重复提交”交出去，仍要有人说明重复订单如何识别、网络重试是否允许、哪些旧接口必须兼容。这是一个典型的任务拆解场景。若边界没有说清，智能体即使交出能运行的代码，也可能解决了另一个问题。省下的打字时间，会在需求澄清或返工环节重新出现。

二 提交量增长不能直接换算成人效

Octoverse 还发现，在报告观察的新建仓库中，带智能体配置文件的仓库，平均提交量是未带此类文件仓库的8倍。这个差距足够醒目，却不能直接翻译成“程序员效率提升8倍”。配置文件是使用信号，团队构成、项目类型和任务规模都可能不同；更活跃的团队也可能更早采用智能体。Octoverse 数据与方法说明

还需要守住统计口径。报告年度为2025年10月1日至2026年9月30日，多数指标覆盖公有和私有仓库；“智能体初稿”限于平台能识别的参与。没有被识别到，不代表完全没用 AI；PR 数量也不是代码行数，更不是全部软件行业的劳动投入。

对企业而言，真正有用的问题是：同样复杂的需求，从提出到稳定上线用了多久？审查者花了多少时间？上线后增加了多少返工？若只把 PR 数量列入绩效，团队容易奖励“拆得更多、交得更快”，却看不见维护成本。活动数据可以说明采用速度，经营判断还需要质量和成本这半张账。

三 审查能力开始决定吞吐量

初稿供给增加后，审查很可能成为新的排队点。解决办法也不只是再加一个 AI 审查者：生成和检查如果都没有明确标准，就可能把同一个误解来回确认。

GitHub 自己提示，Copilot 审查既可能漏掉问题，也可能报告并不存在的问题，需要人工复核；生成代码在关键或敏感场景下仍须审查和测试。GitHub 责任使用说明

一个更扎实的方向，是让“完成”具有可以运行的证据。Claude Code 官方实践把提示词、项目说明等交给模型理解的要求，与测试、权限规则、钩子和分支保护等强制控制区分开来。告诉模型“不要越权”，与在环境里真正限制权限，并非同一种保障。Claude Code 实践指南

由此看，测试设计、故障复现、系统边界和回滚能力的价值会更突出。开发者需要能指出一个实现为什么错，也要能设计出让错误暴露的检查。对已有复杂系统的团队，补齐这些基础设施，可能比单纯增加智能体并发更有用。

四 平台竞争延伸到交付流程

产品之间当然还在竞争编码能力，但团队购买的是一套可以嵌入现有研发流程的工作方式。三类产品的官方文档，展示了不同的接入侧面，并不意味着能力互斥。

一个值得注意的交叉是，GitHub 也接入了 Anthropic Claude 和 OpenAI Codex，相关第三方编码智能体功能仍处于公开预览，需付费 Copilot 方案并启用相应策略。GitHub 第三方智能体文档

这意味着模型和协作平台未必由同一家提供。对 GitHub 而言，即使用户更换智能体，任务、权限和合并决策仍可能留在平台上；对团队而言，选择标准也应包括迁移成本、审计能力以及能否复用已有流程。

成本同样值得算清。GitHub 文档将这些编码智能体的用量计入 Actions 分钟和 AI credits，后者受所选模型与处理的 token 数量影响。若任务反复尝试，审查后又大幅返工，初稿变便宜未必意味着交付也变便宜。GitHub 用量说明

五 程序员的价值要回到可交付结果

工作重心确实出现了移动的迹象，但无法从这份报告推出岗位数量将如何变化。它记录了开发活动，没有直接测量企业需要多少工程师。

更现实的调整，是按任务风险配置人的注意力。边界清楚、容易验证的改动，可以更充分地委派；涉及账务规则、权限模型或跨系统变更的任务，需要更深入的设计与复核。团队可以先比较同类任务的交付周期、审查耗时和上线返工，再决定扩大委派范围。

人才培养也会遇到一个新问题：如果新人很少亲手经历实现和调试，如何形成判断初稿的能力？让他们解释设计取舍、复现故障、补足测试，比只检查提交数量更接近真实成长。

超过四成 PR 从智能体起步，说明“第一版由谁来写”已经改变。接下来更值得观察的，是团队能否把节省下来的实现时间，变成更可靠的交付。判断力不会自动随着代码产量一起增长，它需要被放进流程，也需要持续训练。