让 AI 替人写代码这件事，人类已经尝试了 70 年

AI 编程席卷的取代论不绝于耳，但如果把时间线拉长却会发现让 AI 替人写代码这件事，人类已经尝试了七十年。1952 年霍珀想让程序员“回归为数学家”；1980 年代 MIT 的“程序员学徒”精准预言了今天的 AI 结对编程；1990 年代微软的“意图编程”甚至试图消灭源代码文本文件——每一次先驱们都觉得“这次要成了”，每一次现实都给出了更复杂的答案。

邹欣老师在《构建之法》第四版（第 11.3 节）中，逐一拆解了五种 AI 辅助编程范式的兴衰逻辑。读完这条七十年的线索，你会获得比“该不该焦虑”更有价值的东西：判断力。看清当下这颗子弹的真实射程，以及作为工程师，你的位置究竟在哪里。

以下内容节选自邹欣 第 11 章第 3 节，CSDN 经授权刊发。

要理解 AI 编程的“今天”和“明天”，我们必须了解它的“昨天”。本文将深入回顾几个关键历史节点，分析各项技术突破的经验教训，揭示当前技术浪潮的本质。让工具来辅助甚至自动化编程的各个环节，始终是软件工程师与计算机科学家的核心愿望。每个时代都涌现出被寄予厚望的新技术，但也伴随着大量的泡沫。

为了帮助读者构建一个清晰的知识框架，表 1 概述了 5 种主要的 AI 辅助编程范式，从核心目标、关键技术、代码表示方式、人类角色的演变以及主要局限性等维度进行了对比。

表 1：5 种主要的 AI 辅助编程范式

01

自动化的创世纪——符号主义之梦

会推理的机器

在计算机软件发展初期，科学家们普遍认为，既然程序本质上是对数据进行一系列逻辑运算，那么这一过程理应可以被数学证明并且自动化。这一思想在 1956 年的达特茅斯会议上得到了集中体现，这次会议不仅正式确立了“人工智能”这一学科，更明确了其核心愿景。会议提案大胆猜想：“学习的每一个方面或智能的任何其他特征，原则上都可以被精确地描述，从而可以用一台机器来模拟。”

在这一宏伟蓝图下，“自动编程”并非一个孤立的技术问题，而是整个愿景的必然推论。当时先驱们的设想远超今日的编译器，他们希望模拟的是人类程序员从理解问题到产出代码的整个思维过程。这一愿景将自动编程定义为一个关于知识、抽象和形式化的核心 AI 问题，而解决它的主流范式，便是符号主义 AI（Symbolic AI）。其核心信条是：智能源于对符号的逻辑操作，而这些操作基于一套明确编码的知识和规则。

愿景虽然宏伟，但是当时的硬件太原始了。20 世纪五六十年代的编程工作极为艰苦：程序员需要通过在卡片上打孔来编写代码，然后将成叠的穿孔卡片加载到计算机中。计算机内存极为稀缺且昂贵，并且没有交互式计算环境。当时能落地的“自动编程”愿景是指“用比机器语言更接近自然语言或人类数学表达的方式进行编程”。这是人类程序员向机器指令的更高层次抽象迈出的第一步。这个挑战被 COBOL（Common Business-Oriented Language）和 FORTRAN 分别实现了。

格蕾丝·霍珀是这一领域的关键先驱。她在 UNIVAC I 计算机上的工作，为“自动编程”奠定了实践基础。

• 霍珀在《计算机的教育》（1952）这篇具有里程碑意义的论文中，阐述了其对编程自动化的宏大愿景。她提出了分层操作的理念，旨在逐步将人类从烦琐的编程劳动中解放出来。她设想计算机的“教育”过程，是从执行基本的机器指令，发展到能够理解和调用子程序库，最终甚至能进行符号操作，如自动求导。这篇论文的核心哲学是，通过不断提高抽象层次，让程序员能够“回归为数学家”，专注于问题本身而非机器的细节。
• COBOL：霍珀的工作并不仅限于科学计算。她坚信计算机程序可以用英语来编写，从而让非数学背景的人也能使用计算机，特别是用于商业应用。在众多开发者的持续努力下，COBOL 诞生了，它在接下来的几十年里主导了商业软件开发领域。

约翰·巴克斯与 FORTRAN

如果说霍珀的工作开启了商业计算的自动化之门，那么约翰·巴克斯及其在IBM的团队则通过 FORTRAN 定义了科学计算的未来。

• 巴克斯曾坦言，他开发FORTRAN 的动机源于“懒惰”，因为他厌倦了为 IBM各种大型机编写汇编语言的烦琐和易错过程。
• FORTRAN（1957）：作为世界上首个优化编译器，FORTRAN（公式翻译）打破了当时“机器代码效率不如手写汇编”的偏见。它成功生成了媲美专家手写的高效程序，将编写指令的工作量骤减为原来的 1/20，由此迅速赢得科学与工程界的广泛认可。

时代背景与局限

高级语言和编译器的出现，无疑是一场革命。然而，这场革命也从一开始就揭示了软件工程中两个根本性的、至今仍在影响我们的矛盾。

首先，抽象与性能之间的权衡关系就此诞生。高级语言的核心目标都是抽象—隐藏机器的复杂细节，让程序员能用更接近人类思维的方式工作。但这种抽象并非没有代价，早期的程序员对其性能表现深表怀疑。FORTRAN 用其优化能力证明了高层次的抽象可以与高性能并存。这确立了编程语言与软件工具被应用的一个基本法则：开发者渴望更高层次的抽象，但只有在性能可接受的前提下才会采纳。这一法则在后来的 CASE 工具、4GL（第四代语言）乃至早期解释型语言的兴衰中被反复验证。

其次，两种截然不同的编程文化开始形成。FORTRAN 采用代数符号，专为科学与工程计算设计，其目标用户是科学家和工程师。而 COBOL 则采用类英语语法，旨在处理商业数据，其目标用户是商业分析师。这两种语言体现了两种哲学的分野，它们针对不同的市场，运行在不同的硬件上，并催生了各自独立的工具、专家和文化生态系统— “科学计算”与“数据处理”。这种分野持续了十多年，直到像 C 语言这样的通用编程语言兴起才逐渐弥合。

02

软件的工业化：CASE 的兴衰

“软件危机”与工程纪律的呼唤：软件工程

随着计算机应用的普及和软件系统规模的急剧膨胀，软件开发在 20 世纪 60 年代末和70 年代遭遇严重的“成长的烦恼”。项目普遍面临进度延迟、预算超支和质量低劣的问题，这一现象被称为“软件危机”。为了应对这一挑战，1968 年，“软件工程”这一术语正式出现在学术界，其核心思想是借鉴传统工程学科的原则，为软件开发引入更严格、可预测和系统化的管理方法。这种对工程纪律的追求，为一类新型工具的诞生奠定了思想基础。

CASE 的承诺：计算机辅助软件工程

CASE（Computer-Aided Software Engineering）的核心愿景是利用计算机来自动化和集成软件开发的整个生命周期—从最初的需求分析到最终的系统维护。 其目标是通过自动化来缩短开发时间、降低成本，并提升软件质量。这个想法深受用于硬件设计的 CAD（Computer-Aided Design）工具的启发。

一个典型的集成 CASE 环境由以下几个关键部分组成。

• 上层 CASE 与下层 CASE：这一分类反映了工具在软件开发生命周期中的不同定位。上层CASE 工具专注于早期、抽象的阶段， 如需求分析和系统设计。它们提供图形化建模工具，支持数据流图（DFD）、实体-关系图（ERD）和结构图等方法。下层 CASE 工具则关注后期的具体实现阶段，如代码自动生成、调试、测试和逆向工程。
• 中央存储库：这是 CASE 环境的技术核心。它是一个中央数据库或数据字典，用于存储项目开发过程中的所有制品（artifact），包括图表、数据定义、屏幕布局、业务逻辑等。这个存储库旨在确保所有开发活动的一致性，并提供“单一事实来源 ”。

20 世纪 80 年代末到 90 年代初是 CASE 工具的鼎盛时期。市场上涌现出众多产品，各大软件公司都想从 CASE 工具出发，建立覆盖完整生命周期的、统一的开发环境。

微软的 Visual Studio 的代码生成向导（见下图）也是这一 “自动化代码生成”思想为数不多的成功案例。它成功搭建了大部分 Windows 应用的基本框架，极大降低了开发者上手复杂框架（如多窗口文档处理应用）的门槛。

MFC AppWizard 可以让程序员方便地配置各种桌面应用，并自动生成可运行的基本框架代码

未竟的承诺：对 CASE 的批判性反思

尽管 CASE 愿景宏大，但其在实践中并未取得预期的成功，并在 20 世纪 90 年代中期开始衰落。其失败的原因是多方面的，具体如下。

• 技术与经济壁垒：CASE 工具本身极其复杂，学习曲线陡峭。同时，其价格非常昂贵，并且常常需要专有硬件的支持，这使得只有大型企业才能负担得起。
• 方法论与标准之争：CASE 工具通常与特定的开发方法论（如结构化分析与设计）紧密绑定。这种“方法论锁定”使得不同厂商的工具难以兼容和集成。当面向对象编程（OOP）兴起时，传统 CASE 工具显得格格不入。各种不兼容问题直到 1997 年统一建模语言（ UML ）正式确立为行业标准后才得以缓解。
• 与新兴范式的冲突：CASE 工具强制推行的自顶向下、集中控制的“瀑布式”开发流程，与当时兴起的敏捷开发思想背道而驰。敏捷方法强调“个体和互动高于流程和工具”，而 CASE工具则显得过于笨重和死板。此外，个人计算机的普及、开源运动的兴起以及分布式开发模式的出现，都使得人们更青睐轻量级、可组合的工具，而非 CASE 这样的大一统环境。

CASE 的本质是一套以管理主义愿景为导向，而非以开发者为中心的工具。它试图从管理和成本控制的角度解决软件危机。因此，CASE 工具的核心价值主张是为项目管理者提供控制力、可预测性和自动化的文档。中央存储库、图表一致性检查等功能，设计初衷就是为了强制执行自顶向下的设计，防止开发人员偏离预设轨道。

然而，对于许多一线开发者而言，这些工具被视为僵化、烦琐且扼杀创造力的枷锁，许多程序员对这类工具并无好感。这暴露了一个根本性的问题：CASE 工具是为购买它们的管理者设计的，却未必是为必须使用它们的开发者设计的，更不是为各种创新的应用开发设计的。

一鲸落，万物生。尽管 CASE 的宏大集成愿景破灭了，但其很多思想和功能却以独立工具的形式留存下来，并成为现代开发环境不可或缺的部分。在后 CASE 时代，这些功能演化为各自领域的佼佼者：UML 建模工具（如 Rational Rose ）、版本控制系统（如 SVN 、Git ）、集成调试功能的 IDE，以及持续集成/持续部署（CI/CD）系统。现代开发者的工具箱，在很大程度上就是这些被解绑的 CASE 组件的重新组合， 只不过这种组合方式更加灵活、可定制，并且由开发者自己掌控。

03

智能协作者：“程序员学徒”

一个新愿景：AI 助手

在 CASE 工具试图用工业化流程规范软件开发的同时，麻省理工学院人工智能实验室提出了一个截然不同的愿景。他们并未试图用一个全能系统取代或严格控制程序员，而是旨在创造一个智能助手—程序员学徒（ The Programmer’s Apprentice），与人类专家程序员并肩工作。这个学徒的工作是处理那些重复性、模式化的编程任务，从而解放人类程序员，使其能专注于更具挑战性的架构设计和算法创新。这一构想在 30 多年前就精准预言了今天“AI 结对程序员”的核心理念。该项目领头人（Charles Rich 和 Richard C. Waters）的规划是：

程序员学徒的目标是建立一套关于专家程序员如何分析、综合、修改、解释、规范、验证和文档化程序的理论。这一研究目标横跨人工智能（AI）与软件工程（SE）两大领域（见下图）。

从人工智能的角度看，我们选择编程这个领域作为研究知识表示与推理基础问题的开始。从软件工程的角度看，我们致力于通过应用人工智能技术来实现编程过程的自动化。

1987 年的设想（结合 AI 和 SE）：程序员学徒是软件过程中的一个新型智能体

核心技术：程序知识的表示

“程序员学徒”项目的核心技术挑战在于让计算机“理解”程序。其解决方案基于两个关键概念。

• 知识库与计划：该项目的研究者认为，专家程序员编程时并非从零开始思考，而是在脑海中调用一个庞大的、由常见算法和数据结构模式组成的“知识库”。例如， “在一个列表中进行线性搜索”“生成一份报告”或“更新主文件”都可以视为独立的计划。
• 计划演算（Plan Calculus）：为了形式化表示这些计划，研究人员开发了一种名为“计划演算”的知识表示语言。它是一种独立于任何具体编程语言（如 Lisp）的图形化表示法，本质上是一个层次化的图结构，融合了抽象语法树（AST）、数据流图和控制流图的特性。通过计划演算，系统能够捕捉程序的底层逻辑和算法意图，而非仅仅停留在表面的语法结构上。

“阿喀琉斯之踵”：计算复杂性

“程序员学徒”的愿景极具前瞻性，但其技术路径却“撞墙”了。正如笔者自己在研究生阶段的编程实验中所验证的那样，该项目的致命弱点在于其核心任务的计算复杂性。为了成为一个有用的助手，学徒系统必须能够在程序员编写的代码中识别出这些预定义的计划。这个识别过程，在计算理论上等价于子图同构问题（subgraph isomorphism problem）—在一个大的图（程序的计划演算表示）中寻找一个小的、特定的子图（计划的表示）。这是一个著名的 NP 完全问题，意味着其计算成本会随着程序规模的增长而呈指数级爆炸。对于小型的“玩具程序”，这个方法尚可应付；但对于真实世界的、庞大的软件项目，在当时的硬件条件下，这完全是不可行的。

对“程序员学徒”项目的回顾，不仅是技术史的考证，更是对人工智能发展路线的一次深刻反思。该项目代表了基于知识的“老式人工智能”（Good Old-Fashioned Artificial Intelligence，GOFAI ）范式（即符号主义）在编程领域的巅峰尝试。“程序员学徒”项目完美地体现了这一思想：它拥有一个明确的知识库（计划库）和一个形式化的推理系统（计划演算）。它的目标是像人类专家一样，通过识别和操纵已知的模式来推理程序。然而，它最终因组合爆炸问题而失败，这正是许多大规模 GOFAI 项目普遍遭遇的脆弱性和可扩展性问题的典型案例。

然而，这次失败也揭示了另一个更深远的结论：项目的愿景是正确的，但实现它的技术路径是错误的。项目的失败是实现层面的，而非构想层面的。它准确预见了软件开发领域对智能助手的核心需求，但试图通过手工构建知识库和形式化推理的路径被证明是死胡同。项目所设定的目标—一个能够帮助程序员“分析、综合、修改、解释、规范、验证和文档化程序”的 AI 助手，几乎就是对今天 GitHub Copilot 和 ChatGPT 等 LLM 工具能力的完美描述。识别“语义模式”、与 AI 结对编程等核心理念，在 30 年后终于得以实现。关键区别在于技术手段的根本转变：“程序员学徒”试图从第一性原理和手工知识库中演绎出程序的语义；而现代 AI 工具则从海量代码数据中统计推断出语义。“程序员学徒”项目正确地指出了目的地，但科学家和工程师最终走了一条截然不同的路（统计机器学习）才到达那里。

这次失败也深刻印证了人工智能先驱理查德 · 萨顿在 2019 年提出的苦涩的教训（The Bitter Lesson ）。萨顿指出，在六十余年的 AI 研究历史中，那些试图将人类知识、启发式规则和复杂逻辑“硬编码”进系统的方法，长期来看都失败了；最终取得最大成功的，是那些拥抱海量计算、采用简单且可扩展的通用学习算法的方法。 “程序员学徒”项目正是这一教训的早期缩影：一个基于人类专家知识构建的精巧系统，最终被无法逾越的计算复杂性击败，这预示着 AI 辅助编程未来需要走一条截然不同的道路。

表 2 对 GOFAI 与现代 AI 作了比较。

表 2：GOFAI vs. 现代 AI

04

对纯粹意图的追求：意图编程

一个激进的提议：代码不是文本

20 世纪 90 年代，微软杰出工程师西蒙尼提出了一项颠覆性的编程范式—意图编程（Intentional Programming，IP）。其核心思想是对编程这一行为的媒介进行根本性变革。IP 方法论认为，将源代码存储为纯文本文件是一种历史局限，它主张将代码的本质—程序员的“意图”，以 一种结构化的树状形式存储在一个数据库中，而非文本文件里。

分离意图与实现

IP 范式的工作机制将软件设计师的抽象意图与具体的代码实现彻底分离，使软件的价值核心（意图）能够超越具体技术的变迁而长久存在。

• “意图”（ Intention）：在 IP 范式中，程序员的首要任务是表达其高层次的“意图”。例如，当程序员想遍历一个集合时，无须编写 for（int i=0;…） 、while（i< n…）等具体的循环语句，而只需表达抽象的“遍历集合”意图。这个意图会被捕获并存储为源码树中的一个节点。
• 投影（Projection）与转换（Transformation ）：IP 系统能够将这个抽象的意图“投影”成多种具体的代码形式。同一个“遍历集合”意图，可渲染成 C++ 的 while 循环、Python的 for 循环，甚至图形模型（如流程图）。而“转换”则是一系列规则，用于将这些高层意图翻译成针对特定平台和语言的、可执行的低层代码。

为何这场革命未能主流化

尽管意图编程的思想极为深刻和强大，但它最终未能成为微软的商业产品，也未能在业界普及。其原因复杂而深刻。

（1）生态系统与工具链的惯性：整个软件开发世界都建立在纯文本文件的基础之上。像 grep、diff 这样的命令行工具，Git 等版本控制系统，以及所有的文本编辑器，都是开发者不可或缺的基础设施。IP 范式要求开发者放弃整个熟悉的、开放的文本生态系统， 转而使用一个专有的、以数据库为中心的封闭环境，这种迁移成本和阻力是巨大的。

（2）高昂的认知开销：IP 范式要求开发者以一种元编程的思维方式工作，不仅要思考业务逻辑，还要定义新的“意图”及其转换规则。这是一种远比传统编码要求更高的抽象思维能力，对普通程序员来说认知负荷过重。

（3）微软内部的战略冲突：IP 项目本质上是一个前沿研究项目。在 21 世纪初，微软的核心战略是全力推出 .NET 框架和 C# 语言，以应对来自Java 的激烈竞争。在这一关键的商业战役中，推广一个颠覆性的、与现有生态不兼容的新编程范式，会干扰核心战略。最终，西蒙尼带着 IP 方法论离开了微软，创立了自己的公司以继续探索这一理念。

意图编程在软件工程思想史上有独特定位，是对“偶然复杂性”而非“本质复杂性”的一次猛烈攻击。著名计算机科学家布鲁克斯在其经典著作《人月神话》中区分了两种软件开发的困难：

• 一是源于问题本身的“本质复杂性”（essential complexity）；
• 二是源于我们所用工具和技术的“偶然复杂性”（accidental complexity）。

西蒙尼的 IP 理论的独特之处在于，它直指一个被其他所有范式都视为理所当然的东西—基于文本的编程语言本身，并认为它就是“偶然复杂性”的主要来源。西蒙尼认为， 语言只是意图的载体，而编程语言的演进之所以缓慢，是因为采纳一种新语言的成本太高。文本表示法迫使程序员手动处理语法、格式化、命名解析等与核心逻辑无关的细节。意图编程试图通过直接存储程序的抽象结构来自动化所有这些偶然任务。纯文本文件本身就是一种技术局限，我们应该超越它。

尽管 IP 项目作为一个整体性产品失败了，但其核心哲学以“语言导向编程”和“领域特定语言”（DSL）的形式得以传承。IP 范式的核心机制是允许开发者创造新的、针对特定领域的“意图”。这恰恰是“语言导向编程”（Language-Oriented Programming）的定义，也是创建 DSL 的根本动机。现代语言工作台（如 JetBrains MPS）和一些广泛使用 DSL 的框架（如 Ruby on Rails），都可以视为 IP 思想的“精神继承者”。它们没有要求开发者彻底抛弃文本生态系统，而是在现有语言框架内，允许开发者为特定问题域创建“迷你语言”，从而更直接地表达意图。因此，IP 项目的失败并未阻止其核心哲学以一种更务实、兼容性更强的方式获得局部成功。

05

现代纪元：从大数据代码到智能涌现

范式转移：拥抱统计学习

随着生成式 AI 在编程领域的深度应用，AI 驱动编程的范式发生了根本性的转变。所有之前的尝试，无论是编译优化、CASE 工具、程序员学徒还是意图编程，都基于人类设计的明确逻辑、规则或结构。而新范式的核心思想则完全不同：它将 GitHub 等平台上数以亿行的开源代码视为一个庞大的数据集，并试图通过统计学习的方法，从中自动学习出编程的内在模式和规律。

从词元到向量：将代码视为数据

这一转变始于将自然语言处理领域的成熟技术应用于源代码。

• 代码的词嵌入：word2vec 等词嵌入（Word Embedding）技术的核心思想是将词表示为高维向量，使得语义上相似的词在向量空间中的位置也相近。早期研究者将这一技术应用于代码，并将代码视为一种特殊的“语言”，通过分析代码中词元（token）的共现关系来学习它们的向量表示。
• code2vec（2018）：很快，研究者意识到简单地将代码视为线性文本序列会丢失其丰富的结构信息。code2vec 是一项关键的创新，它不再依赖线性的文本窗口，而是利用代码的抽象语法树（AST）来捕捉其结构语义。code2vec 将代码片段表示为从其 AST 中提取的大量“路径上下文”（path-context）的集合。一个路径上下文捕捉了 AST 中任意两个叶节点之间的结构化路径。这种方法在捕捉代码语义方面远比将代码视为纯文本更有效。

Transformer 革命：实现智能涌现的关键

code2vec 展示了结构化表示的潜力，但真正引爆 AI 编程革命的是 Transformer 架构的出现。正是这一技术突破，为当今几乎所有 AI 编程助手提供了动力。

• Transformer 架构：Google 研究人员发表的论文 Attention Is All You Need（2017）是现代 AI 的基石之一。其核心贡献在于提出完全基于“注意力机制”的新型神经网络架构，摒弃了以往处理序列数据所依赖的循环神经网络（RNN）和卷积神经网络（CNN）架构。
• 预训练与微调范式（BERT，2018）：Transformer 提供了强大的模型，而 BERT 则提供了释放其潜能的训练方法。BERT 的核心思想是“预训练+微调”。首先在一个巨大的、无标签的文本语料库上对基于 Transformer 的模型进行“预训练”，任务是“遮蔽语言模型”—随机遮盖输入文本中的一些词，让模型去预测这些被遮盖的词。通过这个过程，模型被迫学习通用的、深度的、双向的语言理解能力。这个预训练好的模型就像一个知识渊博的“通才”，可以快速“微调”以适应各种具体的下游任务。
• CodeBERT（2020）：CodeBERT 是将 BERT 范式成功应用于编程领域的“里程碑”。研究人员在一个包含 6 种编程语言的大规模双模态（bimodal）数据集上对基于 Transformer的模型进行了预训练，该数据集中包含源代码及其对应的自然语言描述（如函数文档）。通过同时学习这两类内容，CodeBERT 掌握了编程语言和自然语言描述之间的语义映射关系，使其能够出色地完成诸如自然语言代码搜索、代码文档生成等任务。这正是 GitHub Copilot 等现代 AI 编程工具的直接技术基础。

大语言模型的成功并非单一技术突破的结果，而是架构、数据和硬件三者协同演进的产物。首先， Transformer 提供了一种可高度并行化、能有效捕捉长距离依赖关系的模型。其次，GitHub 等大型代码平台的兴起，为训练这些模型提供了前所未有的海量、高质量的数据集。最后，GPU 硬件的成熟为训练这些庞大的并行模型提供了必需的算力。这三者缺一不可，它们的汇合点燃了这场技术革命。这深刻揭示了技术进步的本质：往往需要多个独立领域的创新在恰当的时机交汇。

更重要的是，这一时代标志着统计方法对形式化方法的决定性胜利（亦即前面提到的“苦涩的教训”）。过去的努力，都基于人类设计的、形式化的知识表示：

• “程序员学徒”项目试图明确编码“线性搜索”的“计划”。
• 意图编程要求开发者定义“迭代”的“意图”。
• CASE 工具则需要绘制形式化的数据流图。

相比之下，大模型内部并没有明确的、符号化的“for 循环”或“二分查找”表示。它所知道的，是在 GitHub 上见过数百万个二分查找的例子后，学到的构成二分查找的词元序列的统计概率分布。它的知识是内隐的、分布式的、统计的，而非外显的、局部的、逻辑性的。这既解释了它的强大之处（能够生成未被明确教过的代码模式），也揭示了其致命弱点（会因“幻觉”而生成看似合理但完全错误的代码，因为缺乏底层的逻辑正确性模型）。这是我们理解 AI 编程能力本质与局限的关键。

纵观 AI 自动编程的历史，我们看到：

• 技术会变，问题永恒。从 FORTRAN 到 LLM，我们始终在与“抽象”和“偶然复杂性”抗争；
• 范式会转移，智慧永存。符号主义失败了，但“程序员学徒”的愿景是正确的。工程师需要有判断何时使用何种工具的智慧；
• AI 是新的“元方法”。它并没有取代其他方法，而是增强了我们实践所有老方法的能力。

正如温伯格所言：

• 无论技术如何变革，软件开发的根本问题，始终是人的思维与复杂性的对抗。

本文至此结束，附邹欣老师言：

我们正身处一个 AI 迅猛发展的时代。每一周、每一个月，都有令人惊叹的新技术与新应用涌现。与此同时，软件工程师也普遍感受到前所未有的挑战与焦虑：我们的职业还有多少保障？我们是否会被 AI 全面替代？第四版《构建之法 – 现代软件工程》以及“做中学”（Learning by Doing）的教学实践，正是对这些问题的回答。我坚信：AI 可以平替我们作为软件工程师大约 90% 的常规能力，但它同时能将我们剩下那 10% 的独特能力放大 1000 倍。因此，在 AI 时代，软件工程师依然大有可为。关键在于，我们如何主动培养和打磨那 10% 的独特能力。