AI写出代码以后，程序员究竟还对什么负责？

Geoffrey Chen

《AI进入工作之后》· 第一季“从回答问题到参与工作”· 第七篇

一名程序员让AI为网站增加文件上传功能。AI阅读项目，创建接口、前端组件和测试，几分钟后显示任务完成。页面可以选择文件，测试也全部通过。

代码看起来没有问题。但上线前，另一名工程师问了几个问题：文件大小是否有限制？恶意文件怎样处理？上传对象是否隔离？失败时是否留下半完成记录？现有备份和隐私政策是否覆盖新数据？

这些问题没有写在最初指令里。AI完成了被描述的功能，却没有自动获得整个产品的安全边界、运维环境和法律要求。

如果程序员说“代码不是我写的，是AI生成的”，这并不能改变系统已经由团队部署的事实。用户不会因为漏洞来自生成模型就少受损失，组织也不能把维护责任交给一个无法接收事故通知、参加复盘或修复生产环境的模型。

AI写出代码以后，程序员负责的对象正在改变：不再只是每一行字符从哪里来，而是需求是否完整、生成结果是否适合这个系统，以及谁授权代码进入真实环境。

AI编码的生产率没有一个统一答案

关于AI是否让程序员更快，目前研究给出的不是简单的“是”或“否”，而是一幅随任务、经验、工具和时间变化的图景。

早期一项受控实验让开发者实现一个JavaScript HTTP服务器。可以使用GitHub Copilot的参与者平均更快完成任务。这个实验说明，AI辅助在边界清楚、规模较小的编码任务上可以带来显著速度收益。Microsoft Research：《The Impact of AI on Developer Productivity》

后来针对Microsoft、Accenture和一家大型企业开发者的三项现场实验，也观察到AI代码建议工具对部分开发工作的生产率提升。不过，这些研究的工具、指标和企业情境都有具体范围，不能直接推导出所有团队都获得相同比例的收益。Management Science：《The Effects of Generative AI on High-Skilled Work》

METR在2025年进行的一项随机实验则得到不同结果：16名熟悉成熟开源项目的资深开发者完成246项真实任务，在当时的工具条件下，允许使用AI的任务平均耗时反而更长。研究的重要意义不是证明AI编码无效，而是显示在复杂、既有代码库和高上下文任务中，生成建议、等待模型、纠正偏差和审查代码本身可能产生成本。METR：《Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity》

到了2026年，METR说明后续实验受到严重选择效应影响：越来越多开发者不愿接受“禁止使用AI”的任务，一些人也会避开不希望在无AI条件下完成的任务。该机构认为新工具很可能已经带来更大加速，但认为现有数据不足以给出可靠的统一数值。METR：《We are Changing our Developer Productivity Experiment Design》

这组变化本身就是重要结论：AI编码能力和使用方式正在快速变化，而“程序员是否更快”还取决于人是否改变了任务选择、是否并行使用代理，以及生产率究竟按完成时间、代码数量、功能价值还是长期维护成本计算。

写代码只是软件工作的一个环节

把软件开发等同于输入代码，会自然得出“AI写得越多，程序员越不重要”的结论。但一个软件功能从需要到上线，通常包含：

  • 理解用户和业务问题；
  • 识别隐含约束与例外；
  • 选择架构和数据结构；
  • 编写或生成实现；
  • 设计测试与安全控制；
  • 评审变更并与旧系统集成；
  • 部署、监控、回滚和维护；
  • 在事故发生后追踪原因并修复。

AI最先显著降低的是实现与搜索成本。它可以生成重复代码、解释陌生库、创建测试、寻找调用位置，并在多个文件中实施修改。随着代理能力增强，它也能执行测试、读取结果并反复修正。

但实现速度提高以后，其他环节不会自动消失。相反，代码数量增加会把压力推向评审、测试、集成和维护。过去程序员在亲手编写时逐渐形成对实现的理解；现在他可能直接收到数百行看似合理的变更，需要在较短时间内重建这种理解。

真正的问题不再是“AI能写多少代码”，而是团队能否理解、验证并长期拥有这些代码。

专业知识没有消失，而是转向引导与判断

Anthropic在2026年对约40万次交互式编码会话进行隐私保护分析，报告称领域专业知识会显著放大使用编码代理的效果。研究者发现，有效引导系统更依赖对问题领域的掌握，而不仅是输入代码的熟练程度。Anthropic：《How Claude Code is used in practice》

这并不意味着语法和编程知识不再重要。恰恰相反，程序员需要知道哪些建议不符合语言、框架和项目约定，才能及时纠正。只是能力重心开始上移：从逐行产生实现，转向描述目标、暴露必要上下文、判断方案、设计测试和控制变更范围。

一个不理解认证的人，可以让AI迅速生成登录系统，却很难发现会话管理和权限边界的漏洞。一个熟悉业务但不会手写全部前端的人，可能借助AI实现可用原型，但在正式上线前仍需要相应工程能力补足安全、性能和维护要求。

AI降低了把意图变成代码的门槛，没有自动降低把代码变成可靠软件的门槛。

程序员至少承担六类责任

第一是问题责任。确认实现的是真实需要，而不是把模糊要求直接扩展成大量代码。错误问题得到完美实现，仍然是失败。

第二是边界责任。告诉系统哪些文件可以改、哪些接口不能破坏、哪些数据不得访问。AI没有理由自动知道组织的全部隐含约束。

第三是证据责任。要求测试、静态分析、类型检查、安全扫描和可重复运行结果。代码“看起来正确”不是部署证据。

第四是集成责任。新代码是否符合架构、依赖政策、性能预算、可观测性和运维方式。局部功能正确不等于系统整体正确。

第五是来源与许可责任。生成内容是否引入不适当依赖、复制受限制材料，或泄露了不应进入外部服务的代码和数据。

第六是后果责任。谁批准合并、谁部署、谁在故障时回滚、谁向用户解释。模型可以建议操作，却不能代替组织建立值班和事故响应。

这些责任不一定都由单个程序员承担。大型团队会把它们分给产品、架构、安全、测试、运维和管理角色。但AI不会因为介入实现就自动接过其中任何一种制度责任。

测试必须验证要求，而不只是验证生成结果

AI能够同时生成代码和测试，这是效率来源，也是一项风险。如果测试只是根据同一份误解产生，它可能准确证明错误实现符合错误要求。

例如，需求是“只有账户所有者可以下载文件”，AI误解成“任何登录用户都可以下载自己的请求结果”。它生成的代码和测试完全一致，测试全部通过，却没有覆盖真正的授权规则。

所以，关键测试应尽量来自独立的需求理解。团队可以先由人确定验收条件，再让AI实现；或者让不同角色编写威胁模型、边界案例和失败条件。对于重要修改，还需要在隔离环境运行、比较行为差异并检查未预期变更。

代理评估实践强调，完成任务、没有破坏其他内容、实现质量良好是不同指标，需要结合静态检查、实际运行和人类评价。Anthropic：《Demystifying evals for AI agents》

这同样适用于日常AI编码：测试不是为AI生成的代码盖章，而是用独立标准挑战它。

代码所有权必须从“谁输入”转向“谁采用”

传统上，代码评审已经承认一个事实：合并者和团队要对不是自己逐字写出的代码负责。开源依赖、同事贡献和自动代码生成都可能进入产品，组织通过评审、许可、测试和维护把它们纳入自己的系统。

AI只是把这种情况推向更大规模。代码来源可以是模型，但采用者仍然是人和组织。

因此，合理的责任规则不应要求程序员假装自己手写了每一行，而应要求他能够说明：

  • 这项修改解决什么问题；
  • 关键设计为什么合适；
  • 使用了哪些自动工具；
  • 哪些测试和检查已经通过；
  • 仍有哪些已知限制；
  • 谁批准进入生产环境。

如果团队无法回答这些问题，就不应因为代码能运行而合并。

结论：程序员负责的不是击键，而是系统承诺

AI写代码的能力正在快速提高，关于生产率的研究也会随着工具和工作方式变化。对一些边界明确的任务，它已经能显著减少实现时间；在复杂既有系统中，上下文、评审和集成仍可能抵消部分收益。用一个固定百分比概括所有程序员，既不准确，也很快过时。

更稳定的判断是：代码生成成本下降以后，软件工作的价值会进一步集中到问题定义、架构、验证、集成和运行责任。

程序员不必证明每一行代码由自己敲出，但必须证明这项变更值得进入系统，并且组织有能力理解、测试、维护和撤回它。

AI可以提交一份候选修改。真正把它变成软件的，是人和组织作出的系统承诺：我们接受这段代码改变用户环境，也愿意在它失败时修复后果。

因此，AI写出代码以后，程序员的责任并没有随键盘劳动一起消失。它从“我写了什么”上移为“我们为什么采用，以及我们怎样知道它可以被采用”。

主要资料

继续阅读：浏览《AI进入工作之后》系列文章

了解 Geoffrey Chen 的更多信息

订阅后即可通过电子邮件收到最新文章。