AI 编程时代，为什么“懂计算机科学”依然是不可替代的护城河

一、一个跨越半个世纪的争论

1978 年，计算机科学奠基人之一 Edsger Dijkstra 写过一篇措辞尖锐的短文，标题直译过来大致是《论“自然语言编程”的愚蠢》。他的核心论点可以概括为三句话：

1. 形式化符号是人类文明进步的引擎，而不是负担。 从希腊数学因停留在口头描述而停滞，到代数符号系统的建立推动现代科学崛起，Dijkstra 认为，精确的符号系统让复杂推理成为可能。他曾写道，形式化文本的美德在于其操作只需满足少数简单规则，是排除“胡说八道”的极其有效的工具。
2. 自然语言的“自然”是一种危险的舒适。 他最犀利的一句是：所谓自然语言的“自然性”，归根结底不过是我们能轻松地用它说出那些荒谬性并不显而易见的话。换句话说，自然语言让你很容易说出自己都没意识到的模糊和矛盾，而且还觉得自己说清楚了。
3. 加宽接口不一定减轻负担，可能两边都更累。 让机器理解自然语言，不只是给机器加活——跨接口的沟通成本也会增加，最终可能双方都更疲惫。他因此主张“窄接口”：约束越明确，合作越高效。

近五十年后，大语言模型让自然语言编程真的部分成为现实。行业内已有不少开发者表示自己几乎不再手写代码，一些团队的产品经理开始直接产出可运行的原型，部分企业每周有大量自动化代码合并请求由智能体提交。

Dijkstra 错了吗？

我带团队深度使用 AI 编程工具一年多，从最初的抵触到全员采用，从“感觉式编程”的兴奋到“规划驱动”的回归。回头看，我认为 Dijkstra 对了一半——而且是更重要的那一半。

二、AI 编程工具改变了什么，没改变什么

2.1 真正被改变的部分

大语言模型确实在以下环节带来了质的飞跃：

• 样板代码生成：CRUD、序列化、配置解析等模式化代码几乎可以一键生成。
• API 记忆负担的转移：不再需要记住每个库的具体调用签名，用自然语言描述意图即可获得可用代码。
• 跨语言迁移成本降低：将一段逻辑从一种语言翻译到另一种语言，效率提升显著。
• 调试辅助：粘贴报错信息即可获得可能的原因分析和修复建议。

这些变化的本质是：AI 把“编码”这个动作的边际成本大幅降低了。

2.2 未被改变的部分

但以下环节，AI 至今未能替代，甚至因为代码产量的增加而变得更加关键：

• 问题定义与分解：把模糊的业务需求转化为精确的技术问题，这仍然是人的工作。
• 架构决策：模块边界怎么划、数据流怎么走、状态放在哪里，这些决策的代价远高于敲代码。
• 正确性判断：AI 生成的代码“看起来对”和“实际对”之间，隔着一整套计算机科学知识体系。
• 系统级思维：并发、一致性、容错、可观测性——这些不是单个函数能解决的问题。

一个残酷的现实是：当代码生成变得廉价，代码审查和架构判断的价值反而更高了。

三、为什么“不懂计算机科学”会成为瓶颈

3.1 你无法审查你看不懂的东西

假设一位开发者完全依赖 AI 生成代码，当 AI 输出如下片段时：

def process_items(items):
    results = []
    for item in items:
        if item.status == "active":
            results.append(transform(item))
    return results

这段代码看起来没问题。但如果 items 规模很大，或者 transform 涉及 I/O，或者 item.status 的访问可能抛出异常——这些判断都需要对算法复杂度、I/O 模型、错误处理有基本认知。

不懂这些的人，只能等线上出问题才知道代码有问题。

3.2 自然语言的模糊性在编程中被放大

Dijkstra 的警告在 AI 编程时代反而更加刺耳。当你对 AI 说“帮我写一个缓存”，你实际上没有说清楚：

• 缓存容量多大？
• 淘汰策略是什么？
• 是否需要持久化？
• 多线程环境下如何保证一致性？
• 缓存穿透、缓存雪崩怎么处理？

AI 会“猜”一个合理默认值，但猜错的代价由你承担。而你如果不知道这些问题的存在，你甚至不会意识到自己需要说清楚。

3.3 调试能力的天花板由基础知识决定

AI 可以帮你修 bug，但前提是你能准确描述 bug 的现象和复现路径。而准确描述的前提是：

• 你知道什么是“竞态条件”；
• 你知道什么是“空指针解引用”；
• 你知道什么是“内存泄漏”；
• 你知道什么是“N+1 查询”。

没有这些概念框架，你连问题都问不出来。

四、实践框架：规划驱动开发

基于一年多的团队实践，我总结出一套“规划驱动开发”的工作方法，核心思想是把 AI 放在执行层，把计算机科学素养放在决策层。

4.1 第一步：形式化问题

在让 AI 写任何代码之前，先用伪代码或结构化自然语言把问题写清楚：

输入：用户 ID 列表
输出：每个用户的最近一次订单摘要
约束：
  - 订单数据在远程服务，单次批量查询最多 100 个用户
  - 需要处理用户无订单的情况
  - 超时时间 3 秒，超时后返回部分结果
边界条件：
  - 空列表输入
  - 用户 ID 重复
  - 远程服务不可用

这一步的本质，就是 Dijkstra 所说的“形式化”——用精确的约束替代模糊的直觉。

4.2 第二步：分层生成与审查

不要让 AI 一次性生成整个模块。按以下顺序推进：

1. 接口层：先定义函数签名、数据结构、错误类型。
2. 逻辑层：生成核心业务逻辑，逐段审查。
3. 边界层：单独处理异常、超时、空值等边界情况。
4. 测试层：让 AI 生成单元测试，但测试用例的覆盖范围由你来定。

4.3 第三步：建立“不信任”机制

对 AI 生成的代码保持健康的怀疑：

• 关键路径代码必须有人工审查；
• 涉及并发、安全、数据一致性的代码必须有人能解释每一行的意图；
• 性能敏感场景必须做基准测试；
• 所有 AI 生成的代码必须通过静态分析和类型检查。

五、团队落地建议

1. 不要降低招聘标准：AI 工具放大的是能力，不是替代能力。一个不懂计算机科学的人 + AI，产出的是“看起来能跑的代码”；一个懂计算机科学的人 + AI，产出的是“可以维护的系统”。
2. 建立代码审查规范：明确哪些类型的 AI 生成代码需要额外审查，哪些可以快速通过。
3. 投资基础能力培训：算法、数据结构、操作系统、网络、数据库——这些不是“学校里的东西”，而是每天都要用的判断依据。
4. 度量真实效率：不要只看代码行数或提交次数，要看缺陷率、返工率、系统稳定性。

六、结论

Dijkstra 在 1978 年反对的是“用自然语言替代形式化思维”，而不是“用工具辅助编程”。AI 编程工具的真正价值，在于把开发者从机械性的编码劳动中解放出来，让你有更多精力去做定义问题、设计架构、判断正确性这些真正需要计算机科学素养的工作。

换句话说：AI 让编码变简单了，但让编程变难了。

编码是把想法翻译成代码，编程是让系统正确运行。前者可以外包给 AI，后者永远需要你自己扛。

所以，“不懂计算机科学的人用好 AI 编程是妄想”这句话，更精确的表述应该是：不懂计算机科学的人，可以用 AI 写出代码，但无法用 AI 构建可靠的系统。 而构建可靠的系统，才是编程这件事的真正含义。