AI会写代码后开发者还要不要学代码

这两天，一组围绕 AI 编程的讨论又把一个老问题推到台前：既然模型已经能写出大段功能，开发者还要不要学写代码、读代码？

这组讨论里，有人主张直接用 AI 造产品，认为从零补技术栈的速度永远赶不上模型进化；也有人提醒，不再逐行手写，并不等于不再理解、不再审查，更不等于不再负责。

我的判断是：AI 正在把“写出代码”从核心门槛变成低成本能力，但它同时把“能否验证这段代码、并为结果承担责任”推成更高的门槛。

这不是一句“工程师不会被替代”的安慰话。恰恰相反，AI 把实现速度推高以后，团队原来靠经验、流程和协作勉强遮住的问题，会更快暴露出来。

Google DORA 在《2025 State of AI-assisted Software Development》中把 AI 定义为组织能力的“放大器”：它会放大既有的优势，也会放大既有的薄弱环节。报告页（https://dora.dev/research/2025/dora-report/）

先把问题拆开：生产、验证、负责，不是一回事

过去，“会写代码”往往把三件事捆在一起：把需求翻译成实现、检查实现是否正确、上线后为结果兜底。AI 把第一件事的成本大幅压低了，于是很容易产生错觉：既然功能能跑，人就可以退出。

但一个能跑的 demo，离一个可长期运行的系统，中间至少还隔着几道题：需求有没有被误解？边界条件是否漏掉？数据迁移会不会伤到历史记录？权限有没有被放大？这个改动和既有模块、依赖、监控、回滚策略是否相容？

模型可以给出答案候选，但它不会天然知道哪一个约束在你的业务里最重要。更不会自动接过上线后的责任。这也是那组讨论中“人仍要参与开源”的要点：人不只是代码生产者，还是意图的说明者、取舍的做出者和责任的承担者。

不是每行都要读，而是要知道什么必须审

“必须逐行审查 AI 代码”和“以后完全不用看代码”，其实是同一个错误的两端。

框架、库、脚手架早就让工程师不再阅读绝大多数底层实现。真正的工程能力，从来不是读得越多越好，而是建立一张风险地图：哪些改动只影响局部展示，哪些会触碰数据、资金、身份、权限和生产稳定性；哪些可以用测试证明，哪些必须回到业务规则和设计取舍。

所以，AI 编程时代的审查对象也在变化。它不只是一段段实现，还包括：

• 变更意图：这次改动解决的是什么问题，不做什么？
• diff 与依赖面：它改了哪些接口、配置、数据结构和第三方依赖？
• 验证证据：测试是否覆盖关键路径，失败时输出了什么，结果能否复现？
• 运行边界：权限、密钥、数据写入、外部调用和发布范围是否被控制？
• 可恢复性：出问题时怎样定位、回滚和止损？

当这些证据齐全时，工程师可以少读很多样板代码；当这些证据缺失时，即使代码看起来很漂亮，也不应轻易放行。把“看代码”升级为“看证据”，才是对 AI 最有效的使用方式。

信任应该分级，而不是一次性放权

社区讨论里有一个特别务实的词：渐进式信任。它比“全自动”更值得团队追求。

可以把 AI 的工作按风险分成三层：

1. 低风险任务，例如文档整理、测试样例草稿、局部样式、独立脚本，可以让 AI 快速完成，再用结果检查确认。
2. 中风险任务，例如业务逻辑改动、接口调整、依赖升级，需要把验收标准、测试、diff 和运行结果一起交给人审核。
3. 高风险任务，例如权限系统、支付、数据迁移、生产发布和安全配置，AI 可以参与分析与实现，但授权、关键决策和最终放行必须保留明确的人类责任人。

这里的关键不是给 AI 贴“能”或“不能”的标签，而是让授权随着证据增加而扩大。先让它在可逆、可测、隔离的范围内成功；再逐步提升任务复杂度和自主性。一个成熟团队追求的不是“终于不用看了”，而是“为什么这次可以放心少看”。

学代码的目标变了：从复写语法，转向建立判断模型

这会不会让初学者不用再学编程？答案取决于你把“学编程”理解成什么。

如果它等于背语法、手敲重复的 CRUD，那么它的重要性确实在下降。AI 会比人更快地检索模式、补全样板和生成初稿。

但如果“学编程”意味着理解程序如何组织状态、数据如何流动、接口如何约束、错误如何出现、测试如何证明、系统如何在真实环境中失效，那么它反而更重要。没有这些心智模型，使用 AI 就容易停在“能跑就算完成”的阶段：一旦出错，不知道该问什么、查哪里、信哪份证据。

对初学者，最有效的路径不是先把所有底层知识学完再碰 AI，也不是只靠 prompt 逃离代码。更好的路径是：用 AI 做出一个小东西，然后顺着它生成的代码追问——输入从哪里来？状态在哪里变？为什么这个测试能证明结果？如果删掉这一层会发生什么？

对资深工程师，工作的重心则会继续上移：把模糊需求变成可验证约束，把隐性的经验变成质量门，把一次性的人工判断沉淀为团队可以复用的评测、测试和发布流程。

真正稀缺的不是“会让 AI 干活”，而是能设计好它的工作环境

Google DORA 的配套能力模型基于近 5,000 名技术从业者的调研，页面提到近九成受访者已在使用 AI；它给出的重点却不是“换一个更强的工具”，而是健康的数据生态、清晰的 AI 使用立场、以用户为中心的能力，以及能把个体提效变成系统提效的平台条件。DORA AI Capabilities Model（https://cloud.google.com/resources/content/2025-dora-ai-capabilities-model-report）

这恰好解释了为什么同一个 AI 工具，在不同团队里会产生完全不同的结果。一个团队有清楚的代码边界、测试、CI、发布门禁和可观测性，AI 会成为高速的新成员；另一个团队靠口头同步、没有验收标准、出了问题也找不到证据，AI 只会更快地产生更多难以确认的改动。

所以，AI 时代最有价值的能力不只是“给出一个好提示词”。而是搭建一个让 AI 的产出可被约束、检查、追溯和恢复的工作环境：任务有边界，权限有门槛，验证有证据，失败有回路。

结语：代码不会消失，但代码的地位会变

AI 会继续吞掉大量重复性的实现工作，这一点没有必要否认。未来，优秀开发者花在“从空白文件写出第一版”的时间会更少。

但代码并不会因此失去价值。它会更像一份需要被理解、验证和签字的工程交付物。人类的角色也不会停留在“手工生产代码”：我们要决定系统该做什么、哪些风险可以接受、什么证据足以信任，以及出问题时谁来承担后果。

因此，问题不该是“还要不要学代码”。更准确的问题是：当 AI 替你写出代码后，你有没有能力判断它是否值得被信任？

如果答案是否定的，自动化带来的不是自由，而是把未知风险更快地推向生产环境。