第1章 编程范式的转变
编程作为人类与计算机沟通的方式，在过去半个多世纪里经历了多次重大变革。从打孔卡片到高级语言，从命令行到图形界面，每一次变革都降低了编程的门槛，使更多的人能够参与到软件创造中来。2025年以来，以大语言模型（Large Language Model, LLM）为核心的AI编程工具，再一次从根本上改变了编程的方式。这种变化不仅仅是工具的升级，而是编程活动本身的范式转变——从"编写代码"转向"表达意图"。
本章将阐述这一转变的本质，梳理从"氛围编程"（Vibe Coding）到"代理工程"（Agentic Engineering）的演变历程，并归纳AI编程的四项核心原则。无论读者是否具备编程经验，这些原则都构成了后续章节的方法论基础。在深入讨论之前需要说明的是，本章侧重于建立认知框架，帮助读者理解"为什么"要这样做。如果读者更希望直接动手实践，可以在了解基本概念后进入后续章节，待有了实践经验再回过头来阅读本章。
1 编程的本质
1.1 传统编程的三个层次
编程活动可以划分为三个递进的层次：意图层、逻辑层和表达层。这三个层次的关系如表1-1所示。
表1-1 编程的三个层次
| 层次 | 描述 | 类比 |
|---|---|---|
| 意图层 | 确定需要解决的问题 | 确定想做一道红烧肉 |
| 逻辑层 | 设计解决问题的步骤 | 确定先焯水、再炒糖色、然后炖煮 |
| 表达层 | 用编程语言将步骤写成代码 | 按菜谱一步步操作 |
意图层是编程活动的起点。在这一层，开发者需要明确"要解决什么问题"以及"解决之后应该达到什么效果"。例如，一家电商公司需要开发一个商品推荐功能，意图层的思考就包括：推荐的目标是什么——是提高销售额，还是提升用户满意度？推荐的结果以什么形式呈现——是商品列表、轮播图，还是侧边栏？
逻辑层将意图转化为具体的执行步骤。继续上面的例子，逻辑层的设计包括：采用什么推荐算法——是基于用户历史行为的协同过滤，还是基于商品属性的相似度匹配？数据从哪里获取？推荐结果如何排序？
表达层是将逻辑层的设计转化为计算机可以执行的代码。这一层涉及编程语言的语法、框架的API、开发环境的配置等具体技术细节。
在过去数十年中，学习编程的人将绝大多数精力投入到表达层。以Web开发为例，一个初学者需要掌握的内容包括：编程语言的语法（Python的缩进规则、JavaScript的异步处理、Java的类型系统），框架和库的使用方法（React、Vue、Django、Spring），开发工具的操作（Git版本管理、Docker容器化、Webpack构建工具），以及程序调试的方法（阅读错误信息、设置断点、排查逻辑错误）。每一个知识点都需要大量时间练习和记忆。
表达层的门槛之高，使得"程序员"成为一项高度专业化的职业，而非像写作、计算一样的通用技能。许多对软件开发有想法的人，正是因为表达层的障碍而无法将想法变为现实。这种现象不仅限制了个人的创造力，也造成了行业对技术人才的过度依赖——大量原本可以由领域专家直接解决的需求，必须经过需求传递、技术翻译、开发实现等漫长的链条才能落地。
1.2 AI时代的编程定义
2025年以来，大语言模型展现出了强大的代码生成能力。开发者只需用自然语言描述需求，AI便能生成对应的代码。这意味着表达层的工作可以部分甚至完全由AI承担，人类只需要关注意图层和逻辑层——而这两个层次的思考，恰恰是产品经理、设计师、创业者等非技术人员每天都在从事的工作。
图1-1展示了这一范式转变：传统编程以"编写代码"为核心，AI时代的编程以"表达意图"为核心。
图1-1 编程本质的变迁
基于上述变化，可以对编程给出一个新的定义：编程是精确地描述期望的计算结果，并借助计算机或AI加以实现的过程。在这个定义中，"编写代码"只是最后的一小步，更重要的是前面的部分——厘清目标，然后将目标用AI能够理解的方式描述出来。这种定义的调整并非文字游戏，而是反映了编程活动中价值创造的核心环节发生了转移：从"如何实现"转移到"要实现什么"。
为了更直观地理解这一变化，下面以开发一个待办事项（Todo List）应用为例进行对比。该应用需要实现三项基本功能：添加任务、标记任务完成、删除任务。
1.3 传统编程与AI编程的对比
传统编程方式的流程如下：
- 选定编程语言和技术栈。例如选择JavaScript语言及React框架，或者选择Python语言及Django框架。不同的选择会影响后续所有步骤。
- 搭建开发环境。安装Node.js运行时环境或Python解释器，配置包管理器（npm或pip），设置开发服务器。这一步骤对于完全没有技术背景的新手而言，往往是最容易放弃的环节。
- 设计数据结构。确定每个待办事项包含的字段：编号（id）、标题（title）、完成状态（completed）和创建时间（createdAt）。
- 编写后端RESTful API。分别实现增、删、改、查四个接口，处理数据的持久化存储。
- 编写前端界面。包括HTML结构、CSS样式和JavaScript交互逻辑，确保用户操作流畅。
- 联调测试。验证前后端数据流通畅，功能正确无误。
- 部署上线。配置服务器、域名和SSL证书，将应用发布到互联网。
上述七个步骤环环相扣，任何一步出现问题都可能导致整个项目停滞。对于有经验的开发者，完成一个简单的待办事项应用大约需要半天时间；而对于零基础的新手，仅第2步"搭建开发环境"就可能耗费数天甚至直接导致放弃。很多初学者在第2步遇到"环境变量未配置""依赖版本冲突""端口被占用"等报错时，找不到有效的解决方案，最终选择放弃。
而使用AI编程工具的流程截然不同。用户在AI编程工具（如bolt.new）的对话框中输入以下内容：
"我想要一个待办事项应用。可以添加任务、标记任务完成、删除任务。数据要保存在本地，这样刷新页面不会丢失。"
等待若干秒后，AI生成一个可运行的初始版本。该版本已经包含了基本的功能——用户可以添加任务、标记完成、删除任务，且数据保存在浏览器的本地存储中。随后用户通过对话逐步改进：
"标记为完成的任务加上删除线效果。" "添加任务时按回车键即可提交，无需点击按钮。" "已完成的任务自动移到列表底部。"
经过几轮迭代，一个功能完整的待办事项应用便完成了。整个过程无需编写任何代码，所需时间通常在十分钟左右。
需要指出的是，上述对比并非否定传统编程方式的价值。在处理复杂项目、大型系统和需要高度定制化的场景下，传统编程方式仍然是必要的。但对于大多数个人项目、原型验证和内部工具而言，AI编程方式已经能够满足需求。更重要的是，在AI编程过程中获得的核心能力——"如何清晰地描述需求"——是一种可迁移的底层能力，不依赖于任何具体的编程语言或框架，也不受AI工具迭代的影响。
2 AI编程的演变历程
2.1 Vibe Coding的兴起与流行
2025年2月，人工智能领域知名研究者Andrej Karpathy提出了"Vibe Coding"（氛围编程）一词[1]。Karpathy是OpenAI的创始成员之一，曾任Tesla AI负责人、斯坦福大学计算机科学讲师。他将Vibe Coding描述为一种完全依赖AI感觉来生成代码的编程方式——开发者不需要关心代码的具体实现，只需要凭借直觉与AI交互，让AI来处理所有技术细节。
这一概念在开发者社区中迅速流行开来，其背后的驱动力是AI编程工具在2024年底至2025年初的爆发式增长。2024年下半年，一批以AI为核心的编程工具集中上线：Cursor推出了深度集成AI的代码编辑器，bolt.new实现了浏览器内的零代码AI编程，Claude Code提供了终端环境下的AI编程助手。这些工具降低了一度高不可攀的编程门槛，使得不具备编程背景的人也能快速做出可用的软件产品。
到2025年底，Vibe Coding的影响已经渗透到整个软件行业。Collins英语词典将"Vibe Coding"选为年度词汇[2]。行业调查显示，92%的美国开发者正在使用某种形式的AI编程工具[3]。美国知名创业加速器Y Combinator报告称，其2025年冬季批次中25%的创业公司，代码库中95%的代码由AI生成[4]。这意味着在这些公司中，AI承担了绝大部分的编码工作，人类开发者的角色从"写代码"转变为"审代码"和"提需求"。
图1-2展示了从Vibe Coding到Agentic Engineering的完整演变时间线。
图1-2 从Vibe Coding到Agentic Engineering的演变时间线
2.2 问题暴露与行业反思
随着AI编程工具的广泛使用，一系列问题逐渐暴露出来。这些问题并非个别现象，而是Vibe Coding这种"凭感觉"的编程方式所固有的系统性缺陷。
首先是需求理解的偏差。AI编程工具根据用户的自然语言描述生成代码，但自然语言本身具有模糊性和多义性。用户说"做一个好看的界面"，AI无法准确判断"好看"的标准是什么——是极简风格还是丰富布局？是深色主题还是浅色主题？配色偏好是冷色调还是暖色调？这种理解偏差在小项目中可能只是导致多改几轮，但在大项目中可能造成严重的方向性错误，而且往往要等到问题显现时才被发现。当项目代码量达到一定规模后，纠正早期理解偏差的成本会急剧上升，甚至需要推翻重来。
其次是安全隐患。Google的研究团队发现，高达45%的AI生成代码包含安全漏洞[5]。这些漏洞的类型涵盖SQL注入（一种通过构造恶意输入来操控数据库的攻击方式）、跨站脚本攻击（XSS，一种在网页中注入恶意脚本的攻击方式）、敏感信息泄露等常见安全问题。缺乏编程背景的用户通常无法识别这些隐患，而AI在生成代码时也不会主动提示潜在的安全风险。
再次是可维护性不足。AI生成的代码往往缺乏清晰的架构和注释，有时只有AI自身能够理解其逻辑。当项目规模增大、需要多人协作时，这种难以理解的代码会成为严重的维护负担。更有甚者，由于AI每次生成的代码风格和结构可能不同，即使是同一个人用同一个工具做同一个项目，前后两次生成的代码也可能无法兼容。一位开发者这样描述这种困境："AI帮我快速建起了一座房子，但后来我发现这座房子没有图纸，只有AI知道每根管道通向哪里。当AI'忘记'了之前的设计时，维护就成了一场噩梦。"
METR（Machine Intelligence Research Institute）开展的一项研究从效率角度揭示了另一个反直觉的发现：使用AI工具的开发者实际上比传统方式慢了19%，尽管他们主观感觉速度提升了20%[6]。速度变慢的原因在于，开发者需要花费大量时间修复AI生成代码中的问题，这些时间甚至超过了AI节省的时间。这种"感觉快、实际慢"的现象，在心理学上被称为"能力错觉"（Illusion of Competence）——工具让编码过程变得流畅，给人以高效的错觉，但纠错环节被低估或忽略了。
上述问题的集中爆发，促使整个行业开始思考一个关键问题：如何在保留AI编程效率的同时，确保代码质量和安全性？
2.3 Agentic Engineering的提出
2026年2月，Karpathy正式提出"Agentic Engineering"（代理工程）的概念[7]，标志着AI编程从"凭感觉"走向"工程化"。
Agentic Engineering的核心思想是：用系统化的工程方法来管理和协调AI，而非不加约束地让AI自由发挥。表1-2对两种方法进行了对比。
表1-2 Vibe Coding与Agentic Engineering的对比
| 维度 | Vibe Coding | Agentic Engineering |
|---|---|---|
| 需求表达 | 随口描述需求，观察结果 | 先撰写规格文档，再交由AI实现 |
| AI约束 | 不设限制，让AI自由发挥 | 为AI设定明确的约束和规则 |
| 信任方式 | 直接采用AI的输出 | 建立系统的验证流程 |
| 协作模式 | 单一AI完成所有任务 | 多个AI分工协作，各司其职 |
从表1-2可以看出，Agentic Engineering在需求表达、AI约束、信任方式和协作模式四个维度上都与Vibe Coding有本质区别。这些区别不是表面上的方法论调整，而是对AI编程认知的深化——AI是一个需要被管理的强大工具，而非一个可以完全信任的代码生成器。
这种转变可以用一个类比来理解：想象一家公司招募了一位能力极强的新员工。一开始，管理者被这位员工的高效率所折服，几乎所有工作都直接交给他处理，不做任何审核。这就是Vibe Coding的逻辑。但随着时间推移，管理者发现这位员工偶尔会理解错指令、有时会用不合规的方式做事、产出的文档别人看不懂。于是管理者开始建立制度：事前写清楚工作要求，事中设定审核节点，事后进行质量检查。这就是Agentic Engineering的逻辑。
从Vibe Coding到Agentic Engineering的转变，构成了本书的叙事主线。全书各章节按照这一演进脉络展开：前四章通过快速实践帮助读者体验AI编程的效率；中间四章学习如何清晰、准确地表达需求；后八章掌握结构化的AI管理方法。
3 AI编程的核心原则
无论AI编程工具如何迭代更新，以下四项原则始终适用，如表1-3所示。
表1-3 AI编程的四项核心原则
| 原则 | 含义 | 重要性 |
|---|---|---|
| 意图优先 | 先明确目标，再让AI执行 | AI只能实现人类的意图，无法替代人类思考 |
| 上下文工程 | 为AI提供充分的背景信息 | 缺乏上下文时，AI只能猜测用户的真实需求 |
| 验证机制 | 对AI的输出进行系统检查 | AI不可避免地会犯错，验证是保证质量的必要环节 |
| 结构化协作 | 以管理团队的方式管理AI | 高效的协作依赖清晰的规则和分工 |
3.1 意图优先
在编写任何代码之前，必须先明确"要解决什么问题"。这一步骤看似简单，实际上是最容易被忽略的环节。许多人在使用AI编程工具时，习惯于直接让AI开始工作，而没有花时间厘清自己的真实需求。
一个常见的误区是认为"AI足够聪明，它会理解我的意思"。事实上，AI只能基于用户提供的信息进行推理。如果用户自身的意图模糊，AI的输出必然偏离目标。例如，如果用户对AI说"做一个网站"，AI无法判断这个网站是用于电子商务、博客展示还是项目管理，因为"做一个网站"这个描述没有传达足够的信息。
正确的做法是：在使用AI编程工具之前，先用自然语言写下清晰的需求描述。描述中应至少包含三个要素：目标用户是谁、核心功能有哪些、预期的使用场景是什么。例如，"我想做一个团队内部的周报管理工具。目标用户是5至10人的小团队，核心功能包括提交周报、查看他人周报、汇总统计，使用场景是每周五下午团队成员提交本周工作总结"。
3.2 上下文工程
上下文（Context）是指AI在生成代码时能够获取的背景信息。上下文工程的核心在于：为AI提供足够多的相关信息，使其能够做出符合项目实际的判断。
上下文信息通常包括以下几类：项目的整体架构和技术选型（例如前端使用React框架、后端使用Node.js运行时）；已有的代码规范（例如变量命名采用驼峰式、缩进使用两个空格）；目标用户的使用场景和习惯；技术栈选择的理由和约束条件。
缺乏上下文信息时，AI只能基于通用知识进行推理，而通用知识不一定适用于特定项目。例如，当AI不知道项目已经采用了Vue框架时，它可能会生成React风格的代码，导致与现有代码不兼容。
上下文工程的重要性可以用一个生活中的例子来类比：请一位厨师做一道菜，如果只告诉他"做一道家常菜"，结果可能完全不符合预期；但如果告诉他"做一道不辣的、适合老人食用的、口感偏软的家常菜"，结果就会精准得多。AI也是如此——提供的信息越具体，输出的质量越高。
本书第6章将详细讲解上下文工程的方法和技巧。
3.3 验证机制
AI生成的代码并非总是正确的。即使代码能够正常运行，也可能存在逻辑错误、安全漏洞或不符合需求的情况。建立系统的验证机制，是保证AI编程质量的必要环节。
对于不具备编程背景的用户，验证并不意味着需要阅读和理解代码。验证可以通过以下三种方式进行：
-
功能测试。逐项检查每个功能是否按照预期工作。例如，对于待办事项应用，分别测试添加任务、标记完成、删除任务三个核心功能，确认每个功能都能正确执行。
-
边界测试。输入极端值或异常数据，观察系统的反应。例如，在待办事项应用中，尝试输入一个超长的任务名称（如1000个字符），或者在没有输入任何内容时点击添加按钮，看系统是否能正确处理这些异常情况。
-
对比检查。将AI的输出与最初的需求描述逐条对照，确认没有功能遗漏或偏差。这是一种简单但有效的验证方式，可以在不阅读代码的情况下发现大部分需求偏差。
本书第7章将详细讲解在不具备编程背景的情况下如何检查AI的输出。
3.4 结构化协作
当项目规模增大时，单一AI往往难以同时胜任所有工作。结构化协作是指将项目拆分为多个子任务，分别由不同的AI或AI的不同角色来承担，类似于团队中的分工合作。
例如，一个Web应用项目可以拆分为以下几个环节：需求分析（明确功能范围和用户场景）、架构设计（确定技术方案和模块划分）、前端开发（实现用户界面和交互）、后端开发（实现数据处理和存储）、测试（验证功能正确性和安全性）。每个环节由专注于该领域的AI角色负责，各环节之间通过明确的接口文档进行衔接。
这种分工方式的优势在于：每个AI角色只需要处理特定领域的任务，减少了上下文切换带来的错误；同时，不同AI角色的输出可以交叉验证，进一步提高质量。
本书第9章至第11章将逐步讲解如何实现这种结构化的协作方式。
4 本章小结
本章阐述了编程范式从"编写代码"到"表达意图"的根本性转变。编程活动可以划分为意图层、逻辑层和表达层三个层次。AI编程工具承担了表达层的工作，使得不具备编程背景的人也能参与软件开发，而需要重点培养的能力是"清晰、准确地描述需求"。
本章还梳理了从Vibe Coding到Agentic Engineering的演变历程。Vibe Coding在2025年初兴起，带来了前所未有的编程效率，但随着使用深入，需求理解偏差、安全隐患和可维护性不足等问题逐渐暴露。2026年初，Agentic Engineering的提出标志着AI编程从"凭感觉"走向"工程化"。这一转变不是简单的术语更替，而是对"如何有效利用AI编程"这一问题的认识深化。
最后，本章归纳了AI编程的四项核心原则：意图优先、上下文工程、验证机制和结构化协作。这四项原则不依赖于任何具体的AI工具或编程语言，具有较强的普适性和可迁移性，构成了全书后续章节的方法论基础。
[1] Karpathy A. Vibe Coding[EB/OL]. (2025-02)[2026-03-15]. https://x.com/karpathy.
[2] Collins Dictionary. Collins Word of the Year 2025[EB/OL]. (2025-11)[2026-03-15]. https://www.collinsdictionary.com.
[3] Stack Overflow. Developer Survey 2025[EB/OL]. (2025-06)[2026-03-15]. https://survey.stackoverflow.co/2025.
[4] Y Combinator. YC Winter 2025 Batch Statistics[EB/OL]. (2025-04)[2026-03-15]. https://www.ycombinator.com.
[5] Perry N, Srivastava S, Kumar D, et al. Do Users Write More Insecure Code with AI Assistants?[C]//Proceedings of the IEEE Symposium on Security and Privacy. San Francisco: IEEE, 2025: 1-18.
[6] METR. Measuring the Impact of AI on Developer Productivity[EB/OL]. (2025-09)[2026-03-15]. https://metr.org.
[7] Karpathy A. From Vibe Coding to Agentic Engineering[EB/OL]. (2026-02)[2026-03-15]. https://x.com/karpathy.