第1章 颠覆传统的氛围编程

第1章

颠覆传统的氛围编程

氛围编程（vibe coding，也称氛围式编程或Vibe编程）是2025年2月出现的热门概念，迅速在科技圈引发了热议。由于这一概念非常新，因此许多人还不太了解它。

本章将帮助你了解氛围编程的概念，氛围编程对非IT背景的人、有IT经验的人和IT 新人的价值，以及氛围编程的11条指导原则。

1.1 用氛围编程快捷解决实际问题

在介绍氛围编程之前，我先通过一些真实案例展示一下它是如何帮助我解决实际问题的，由此帮你更直观地理解氛围编程。

先以批量修改文件名的问题为例，看一下氛围编程是如何帮助我写好这本书的。

1.1.1 用豆包批量改文件名

“写书不怕改稿，就怕插入一章”——为何害怕？因为修改插图文件编号实在麻烦。我最初计划全书写8章，先着手写了第5章（关于用GitHub Copilot实现前后端

分离的Web应用），因为这部分内容我最感兴趣。但这一章写完后我发现太长了，竟然有3万字，于是打算把后半部分关于自动化测试的内容拆分到第6章。此时，一

位试读读者提出建议，希望加入一章介绍用氛围编程开发微信小程序的内容。我觉得很有道理，考虑到微信小程序的开发量比前后端分离的Web应用要小，决定将其

插入原第5章之前。后来又决定在原第5章前插入“用bolt和Trae等4款工具快速实现Web产品原型”那一章。

这样一插入带来了连锁反应是：原第5章变成了第7章，后续章节序号依次顺延。这意味着原第5章中的插图编号也要从“图5-x”改为“图7-x”。虽然用查找、替换

功能修改正文中的图号很简单，但要修改插图文件名就没那么容易了。这一章有6 个插图文件，都存放在与Markdown格式书稿相同的原第5章目录下。如果不用终端

命令批量改名，就只能手动修改这6个文件名。更麻烦的是，原第6章中的17个插图文件名也需要更新。这种用鼠标逐个点击修改文件名的工作虽然不难，却非常烦

琐。那么，该如何写一个终端命令来批量改名呢？

在2022年11月ChatGPT爆火之前，如果我想写这样的终端命令，只能在各大搜索引擎或编程问答网站Stack Overflow上搜索关键词，或是临时找本终端脚本编程的书

DeepSeek爆火之后，直接用自然语言向AI聊天应用（如豆包、夸克、天工、智谱清言、通义、Kimi、元宝、文小言等）提问似乎更顺理成章了。下面是我向豆包提问

时使用的提示词（已开启“深度思考”模式）：

我在macOS的iTerm2里运行“ll”命令后，发现所有插图文件名都以“图5-”开头。我想把所有以“图 5-”开头的文件名批量改为以“图7-”开头，有什么最简单的方法？另外，在实际修改之前，希望能先用

命令预览一下修改后的文件名是否正确。

下面是运行“ll”命令后的结果：

total 67224

-rw-r--r--@ 1 binwu staff 362K Apr 23 09:50 图5-1.png

-rw-r--r--@ 1 binwu staff 390K Apr 24 10:44 图5-10.png

-rw-r--r--@ 1 binwu staff 231K Apr 24 17:36 图5-11.png

（略）

豆包提供了两个解决方案：一个是使用mmv命令批量改名，另一个是使用for循环配合mv命令。由于mmv需要额外安装，我选择了后一种方案。按照豆包的建议，我首

先在终端中进入原第5章的目录，然后输入以下命令（注意插图都是按章分别存放在不同的目录下，所以原第5章目录下只有原第5章的插图，运行下面的命令不会影

响其他章的插图文件）：

for f in 图5-*; do echo "mv '$f' '${f/图5-/图7-}'"; done

这行命令并没有真改文件名，而是让我能预览批量改文件名的命令：

mv '图5-1.png' '图7-1.png'

mv '图5-10.png' '图7-10.png'

mv '图5-11.png' '图7-11.png'

（略）

确认预览结果无误后，我按照豆包的指示执行了批量修改文件名的命令：

运行列出文件的命令后，第5章目录下的所有文件名都已成功修改：

ll

total 67224

-rw-r--r--@ 1 binwu staff 362K Apr 23 09:50 图7-1.png

-rw-r--r--@ 1 binwu staff 390K Apr 24 10:44 图7-10.png

-rw-r--r--@ 1 binwu staff 231K Apr 24 17:36 图7-11.png

（略）

乘胜追击，我进入原第7章的目录，仿照前面的两行命令，很快成功批量修改了第7 章的插图文件。随后将两个目录的名称一并更正，这项原本烦琐的工作就轻松完成

了。

这种让AI聊天应用帮你编写一行终端脚本的过程就是最基础的氛围编程。如果你觉得这个例子还不够精彩，接下来看一个我遇到的更复杂的问题。

1.1.2 用Cursor将Markdown文档转换为Word文档

我喜欢使用Notion撰写文档，因为它可以通过AI随时选择文字并对其进行润色，使表达更加清晰流畅，所以我一直用Notion撰写本书初稿。但将Notion导出的

Markdown文档转换成符合编辑要求的具有规定样式的Word文档成了一个难题。

起初，我采用手工转换的方式，计划每写完一章，就将Markdown文档中的正文以 “正文”样式复制到编辑提供的Word模板中，再逐一调整标题、代码清单、图题和

提示的样式。完成一章后我评估了一下工作量，这项工作耗去了我半天时间。虽然处理一章的工作量尚可忍受，但要手动调整全书9章的样式，恐怕得花上好几天。

显然需要寻找更好的解决方案。

我不是正在写一本关于氛围编程的书吗，还在书中倡导“氛围编程谁都行，解决问题变轻松”的理念，如果自己在文档转换这样的问题上还在依赖手工操作，未免有

些说不过去。于是，我决定尝试用氛围编程生成Python代码来解决这个问题。

定首先尝试使用氛围编程领域较强大的（这符合1.7节中的氛围编程大模型升级指导原则）Claude智能聊天应用（后文简称Claude）。

在写提示词前，我需要厘清思路。我手上目前有3个文件：ch04-from.md（我刚写完的第4章文稿的Markdown文件）、ch04-to-manual.docx（我将第4章的Markdown

格式的文稿内容以正文样式复制并粘贴到编辑提供的Word交稿模板并手工调整好样式后的Word文件）和ch04-to-template.docx（编辑提供的Word交稿模板文件）。

我想让Claude生成Python代码，将ch04-from.md转为ch04-to.docx。

转换的实现方式有很多种，或许我可以把已经手工转换好的ch04-to-manual.docx 文件提供给Claude，让它“以终为始”地参考这个文件来编写Python（读到后文就

能看出，沿着这个思路实现会踩进坑里。不过氛围编程本身就是探索的过程，经验都是踩坑后才得到的）。另外，因为我要使用编辑提供的Word交稿模板中的样式，

所以我需要让Claude将ch04-to-template.docx复制一份，作为保存转换后内容的目标Word文件，这样就能让Python代码使用其中编辑已经定义好的样式了。

这个大模型的版本号曾是Claude 3.7 Sonnet，与它上一个版本Claude 3.5 Sonnet风格一致。但在Anthropic公司推出Claude Sonnet 4之后，这个大模

型的前两个版本号也随之调整为新风格。为风格统一起见，本书后文对于 Claude这3个版本号都统一使用新风格。

厘清思路后，我打开Claude桌面应用，搭配当时编程能力最强大的Claude Sonnet

3.7大模型，并提交了以下提示词：

这个提示词存在语义模糊问题，未能明确说明“分析格式差异”的具体用途。该提示词实际想表达的是比较两种不同格式文档中相同内容的样式差

异，并据此进行格式转换。这正是后文所述问题的根源——即使使用Claude 这类顶尖工具和配套大模型，反复修复基于这段模糊提示词生成的代码仍无

法解决问题。同时，这也反映了氛围编程新手的典型问题——由于没有深入理解需求而导致提示词表述不清。后文将介绍我如何改进这段提示词并最终

成功实现文档格式转换。

这个模板文件起了关键作用。由于模板文件的副本中已包含编辑提供的样式，我设想可以让AI自动分析ch04-from.md文件与相应ch04-to-manual.docx

之间的样式对应关系，然后将内容按照这些样式写入副本中。当然，这想法过于理想化了——AI无法自动发现Markdown文档与Word文档之间的样式对应

关系，这正是导致后来踩坑的原因。

一个名为converter的Python程序来分析这两个文件的格式差异。当运行“python3 converter ch04-

from.md”时，程序应执行以下操作：读取ch04-from.md 的内容，复制ch04-to-template.docx文件并重命名为ch04-to.docx，然后将ch04-from.md中的内容按照ch04-to-manual.docx的样式写入ch04-

to.docx中。转换完成后，用Word打开ch04-to.docx时应与ch04-to-manual.docx的样式完全一致。由于没有上传Markdown文件中的图片，转换后的ch04-to.docx可以不包含图片，但所有文字内容和样式必须与

ch04-to-manual.docx保持一致，不能增减。如遇到“【避坑指南】”这样的特殊样式无法确定如何转换，请告知并尽力保留这些内容。

Claude很快生成了Python代码。运行后发现代码报错，我把错误消息发给Claude请求修复。修复后再次运行又出现新的错误。经过多轮修复，代码终于能运行了。但

查看转换后的docx文件，发现还有许多样式问题——章节标题、避坑指南和代码清单标题的样式都与编辑提供的模板不符。我继续让Claude修复这些问题。经过十几

轮反复对话，代码清单标题的样式还是不对，代码量却随着修复次数的增加而不断膨胀，最终达到700行。这让我感到十分沮丧。

几天后，我偶然在查看模板文件时发现，代码清单标题其实有专门的样式名，可以直接从Word的样式列表中选用。这让我意识到：之前给Claude的提示词中“将

ch04-from.md中的内容按照ch04-to-manual.docx的格式写入ch04-to.docx中”这样的转换要求是否过于模糊了？我是不是太相信Claude能有“读心术”的能力，猜

出我的想法并像变魔术一样地生成“首次对话即成功”的代码（没有经过反复迭代，在与大模型的第一次对话中即生成运行不报错且实现提示词中描述的80%左右

的功能的代码，往往因为运气好）？如果在提示词中明确指出Markdown语法与Word 样式名称的对应关系，也许氛围编程工具所搭配的大模型能更好地完成文档格式转

换？

于是，我放弃了那700行的Python代码，转而在Cursor（搭配Claude Sonnet 3.7大模型，选用Agent模式）中用更明确的提示词重新生成代码：

#file:template-from.md #file:template.docx 是你需要阅读的两个文件。两者内容相同但格式不同。

请你帮我开发一个名为converter-v2的Python程序，用于将 #file:template-from.md 转换成与 #file:template.docx 样式完全一致的新文件template-to-converted.docx。

当运行“python3 converter-v2 template-from.md”时，程序应：

1）读取 #file:template-from.md 的内容；

2）将 #file:template.docx 复制并重命名为template-to-converted.docx，然后根据Markdown标签与 #file:template.docx 的样式对应关系（见后文），将内容写入template-to-converted.docx中。

全一致。Markdown文件中的图片也需要正确插入template-to-converted.docx中。要求 #file:templatefrom.md 中所有文字、插图和表格及其他内容和样式都必须以与 #file:template.docx 一致的样式进行

转换，内容不得增减。

在按照后面提供的Markdown标签与Word样式之间的对应关系进行格式转换（即.md格式转换为.docx格式）

之前，需要进行一个插图文件名转换预处理，这个预处理逻辑只做一件事：扫描要转换的Markdown文档，只要遇到“(attachment:xxx:图x-xx.png)”，就将从“attachment”到“图”之间的内容删除，即转换

为“(图x-xx.png)”，例如将“(attachment:ec94c27f-923d-4ae8-886e-930bd7c3f8e6:图6-17.png)”转换为“(图6-17.png)”。之后再执行所有下述转换逻辑。

以下是 #file:template-from.md 中的Markdown标签与 #file:template.docx 中的Word样式之间的对应关系：

“#”对应“Heading 1”。

一般正文对应“Normal”。

“##”对应“Heading 2”。

“###”对应“Heading 3”。

“```”对应“代码无行号”。

以“代码清单”开头的行对应“超强提示标签”。

“- ”对应“第1级无序列表”。

以“表”开头的行对应“表题”。

以“|”开头的表格内容对应“表格单元格”。

以“【避坑指南】”开头的行对应“强提示标签”。

以“提示”开头的行对应“提示标签”。

以“【避坑指南】”开头的“<aside>”内的内容对应“强提示”。

以“提示”开头的“<aside>”内的内容对应“提示”。

以像“1. ”这样的数字开头的行对应“Heading 4”。

以``包围的行内代码对应“行内代码”。

“<aside>”内的行内代码两侧的“`”符号在转换后的docx里都要去掉。

这次效果出奇地好，与Cursor首次对话它就生成了能正常运行的代码。转换后的 Word文档中，代码清单标题样式完全正确。查看Python代码发现只有300多行。经

过让Cursor修复几处bug后，文档样式已与编辑提供的模板完全一致。最终的 Python代码为385行，不仅代码量比之前的方案精简了一半，而且解决了那些反复

修复却仍无法解决的问题。这不仅表明给大模型提供精准的提示词才能快速获得解决实际问题的代码，还促成我总结出1.7节中的氛围编程高配组合优化提示词指导

原则。

需要说明的是，虽然第二次代码生成效果出奇地好，但所使用的氛围编程工具是 Cursor，并非第一次使用的Claude。为了科学验证氛围编程高配组合优化提示词指

导原则，我需要进行更严谨的实验。因此，我专门用Claude搭配Claude Sonnet 3.7（开启“Extended thinking”和“Web search”模式）进行了实验（实验所用

的提示词和相关文件参见本书配套代码中的ch01/lab-converter-prompt-old-vsnew目录），这次实验在提示词优化前和优化后得到了不同的结果。实验结果支持

了氛围编程高配组合优化提示词指导原则：提示词优化前首次对话生成的代码在运行时报错“KeyError: no style with name “Title””（关键错误：没有名为

“Title”的样式）而导致运行中断，而提示词优化后首次对话生成的代码能够正常运行，并成功实现格式转换（尽管存在一些小bug）。

Cursor是一款基于Visual Studio Code开源代码的闭源AI原生IDE（integrated development environment，集成开发环境，即将代码的编辑、编译和调试等功能

集成在一个应用中），于2023年3月推出。它以“对话式编程”为核心理念，可以搭配Claude等大模型，让开发者能通过自然语言与AI聊天应用交互，完成代码编

写、调试和重构等任务。

2024年11月24日，Cursor 0.43版紧随Windsurf之后引入了Agent（智能体）模式，能自主使用工具探索、规划和执行复杂代码项目。例如，打开Auto-fix errors开

关后，每当Cursor所搭配的大模型根据你的提示词生成了代码，Cursor就会自动在聊天框中运行命令验证代码改动，遇到复杂运行错误时会自动添加调试语句并运行

测试，根据结果修改代码，确认无误后再删除这些临时插入的调试代码。这就像有一位经验丰富的程序员在为你编程（1.2.4节将详细介绍这一过程）。

对Python新手来说，385行代码已经是相当可观的规模。这次成功让我深刻体会到了氛围编程的强大。值得一提的是，这个工具已迎来第一位用户——本书的责任编

稿，正为如何转换成Word文档发愁。我将这个工具及详细的使用说明README文档上传到Gitee代码库（在Gitee里搜索用户“wubin28”，然后找到convert-book-

from-md-to-word- for-epubit-converter-v2代码库）供她试用。不过，她在使用时遇到了问题，因为使用说明是针对macOS系统编写的，在她的Windows 11系统上

无法正常使用。于是，我让Claude将针对macOS 系统的使用说明转换成针对 Windows 11系统的，它很快就完成了转换。我在自己的Windows 11系统上验证了一

下，顺利完成了文档格式的转换。

有了这两次氛围编程的实践经历，我们可以讨论一下什么是氛围编程了。

1.2 什么是氛围编程

“一千个人眼中有一千个哈姆雷特”，每个人对氛围编程的理解可能都不同。要全面认识这个新词，要先了解它的起源。

1.2.1 颠覆传统的氛围编程极简史

2025年2月3日，一条看似随意的推文在硅谷引发了编程界的地震。曾任OpenAI联合创始人和特斯拉公司人工智能部门总监的计算机科学家安德烈·卡帕西（Andrej

Karpathy）发布推文：

Cursor的Composer模式最初于2024年7月13日作为实验性功能（beta版本）发布，它将氛围编程的能力从仅支持编辑单行代码和单个页面，扩展到能够同

时编辑和创建多个源代码文件。这些功能与2025年3月24日Cursor 0.48版发布时推出的Manual模式（只能修改用户明确指定的那些文件）十分相似。在

本书撰写时，Cursor推荐氛围编程者优先使用更加方便的Agent模式，因为在 Agent模式下Cursor具备理解和编辑整个项目所有代码的能力，无须指定具体

要修改哪些文件，Cursor就能自行选择需要修改的文件。

一种在macOS系统个人计算机上运行的语音识别软件，让用户能通过语音而非键盘与AI工具协作。

有一种新的编程方式，我称之为氛围编程。在这种编程过程中，你完全沉浸于编程氛围中，拥抱编程世界指数级的发展，甚至忘记了代码的存在。这一切归功于大模

型（如Cursor在Composer模式中搭配的Claude Sonnet 3.5）的强大能力。我现在使用SuperWhisper在Cursor的Composer模式中对话，几乎不用触碰键盘。因为

不想在代码中逐行查找，我会直接提出简单的要求，例如“将侧边栏的内边距减半”。我总是直接点击“Accept all”按钮，不再比对差异。遇到错误消息时，我

修复错误。现在的代码量已超出我日常的理解范围，要完全读懂需要很长时间。当大模型修复不了bug时，我就绕过去或随机提出修改要求，直到问题消失。这种方

式对周末开发一次性项目非常合适，而且很有趣。虽然我确实在构建项目和网页应用，但这已经不能算是传统意义上的编程了——我只需要看看屏幕、说说话、运行

一下、复制并粘贴一下，生成的代码就基本可用了。

这条随手写就的推文不仅创造了一个全新的编程概念，开启了软件开发史上最具争议的革命，还破圈至没有IT技术背景的“泛程序员”群体。为什么会出现这种现

象？这要从零基础入门编程的传统方式说起。

在2022年11月OpenAI公司推出搭配GPT 3.5大模型、具备代码生成能力的ChatGPT之前，新手大多以传统方式入门编程：先发现实际问题并选择编程语言，然后通过读

书、看视频、编写并运行样例代码学习该语言，接着照着书上或视频里的例子写一个小项目，然后把例子中的需求稍作修改后独立重写一遍，最后再尝试用所学知识

解决问题。但麻烦的是，例子中的小项目往往与要解决的实际问题差异较大，让新手十分抓狂。

以我在前面提到的经历为例，在写本书时需要将书稿从Markdown格式转换为Word格式，而Python程序可以完成这项工作。作为Python新手，按照传统学习方式，我需

要先通过读书、看视频和动手实践来掌握Python的基础语法，从编写简单程序开始练习，顶多再把练习中的需求稍作修改后独立重做一遍。即使完成这些基础学习，

我还是不会写格式转换的代码，因为编程书里一般不会教这类实用工具的开发。我不得不运用有限的Python知识去网上搜索类似的文档格式转换示例。好不容易找到

相关代码后，还需要将其修改成适合我特定需求的版本。遇到困难时，我只能在搜索引擎或Stack Overflow等编程问答网站上寻找解决方案。这种传统的学习过程通

常需要花费几天甚至几周时间。

然而，ChatGPT问世后，借助它催生的AI聊天应用（如Claude、豆包和 DeepSeek），我这个Python新手仅用两天就完成了同样的文档转换任务。

我用AI聊天应用生成代码完成文档格式转换，就是在做氛围编程。要讲氛围编程的起源，要从2023年1月的一条推文说起。当时，卡帕西在推特（现已更名为X）上发

出了一条看似玩笑却极具预见性的推文：“The hottest new programming language is English”（最热门的新编程语言是英语）。这句话背后蕴含着深刻

的洞察——大模型已经强大到足以让人们直接用自然语言控制计算机，而无须掌握专门的编程语言。这一观点在两年后成了氛围编程概念的思想源头。

进入2025年，这一理念开始从理论走向实践。2月，《纽约时报》记者凯文·鲁斯

人需求而设计的AI生成代码工具。其中最有代表性的是一个名为LunchBox Buddy （午餐饭盒伙伴）的应用，它能够根据冰箱中的食材提供第二天的午餐食谱建议。

鲁斯的实验很快引起了广泛关注。2月13日，科技博客Business Insider将氛围编程描述为“硅谷的新流行词”，标志着这一概念开始进入主流话语体系。然而，并

非所有人都对此持乐观态度。认知科学家加里·马库斯（Gary Marcus）对鲁斯的实验提出了尖锐批评，他指出生成LunchBox Buddy应用的算法很可能是在类似任务

的现有代码上训练的，因此鲁斯的氛围编程成果更多源于复制而非真正的原创。

尽管存在争议，氛围编程在硅谷的实际应用却在加速推进。3月5日，两个重要的实证数据同时公布。美国硅谷知名创业孵化器Y Combinator公司的管理合伙人贾里德

·弗里德曼（Jared Friedman）在发布于YouTube的一段对话中透露了一个惊人的数字：在2025年初创公司冬季训练营中，约有四分之一的初创公司有95%的代码是

由AI生成的。弗里德曼特别强调，这些创始人并非不懂技术的门外汉，而是“个个技术精湛，完全有能力从零开始打造产品”的专业人士，但他们现在选择让AI来完

成绝大部分编程工作。

同一天，创业者丹尼尔·本特斯（Daniel Bentes）公布了他为期27天的氛围编程实验结果。通过1700多次代码提交（其中99.9%为AI生成），本特斯发现了氛围编

程的发展规律：从最初的“蜜月期”——AI工具表现出色，自然语言描述能在几分钟内转化为能运行的功能，到“上下文崩溃期”——代码的复杂性增大，当代码超

过约5000行时，AI工具开始失去对系统整体脉络的把握（这启发我总结出1.7节的氛围编程简单性指导原则）；最终进入“维护困难期”——代码变得难以维护和调

试。

这一概念的影响力在3月继续扩大。韦氏词典将“vibe coding”正式收录为“俚语和趋势”名词，表明其在语言学层面获得了认可。与此同时，《纽约时报》、Ars

Technica、《卫报》等主流媒体纷纷对此现象进行深度报道。

3月19日，程序员西蒙·威利森（Simon Willison）发表了一篇具有里程碑意义的博客文章，首次系统地定义了氛围编程与传统AI辅助编程的根本区别。威利森明确

指出，氛围编程的核心在于“用户接受代码而不完全理解”和“不评审AI生成的代码”，这与需要详细评审、全面测试并能向他人解释代码的传统AI辅助编程形成了

鲜明对比。他的这一定义为这个新兴概念提供了清晰的理论框架。

3月26日，《财富》杂志报道了Y Combinator公司的CEO加里·谭（Garry Tan）对氛围编程效率的惊人评价：“氛围编程让10名工程师能够完成100名工程师的工

作。”这一说法进一步推高了业界对这一新编程方式的期待。

将氛围编程定义为“一种全新的编程方法，用户用自然语言表达意图，AI将这种思维转化为可执行代码”。至此，从卡帕西的预言性推文到IBM的官方定义，氛围编

程完成了从概念萌芽到主流认可的完整历程。

从安德烈·卡帕西的一条推文开始，氛围编程已从一个编程概念演变为一种文化现象、一场关于AI与人类协作的全球对话，以及对软件开发未来的预言。

无论是赞成者还是批评者都承认，这种编程方式代表了一个根本性的转变：从手写代码到与AI对话生成代码，从必须理解每一行代码到“先拥抱不确定性”。

正如卡帕西本人所说，氛围编程可能“不太适合严肃的项目，但仍然相当有趣”。

然而，随着AI能力的不断提升和工具的日益完善，氛围编程可能不仅“有趣”，而且正在重新定义编程的本质、软件开发的方式，以及AI时代中人类程序员的角色。

1.2.2 氛围编程的定义

氛围编程是一种颠覆传统的新型编程方式。通过这种方式，编程者（包括不具备传统编程语言知识的人）可以使用中文、英文等自然语言，借助氛围编程工具与搭配

的大模型进行对话来生成实用代码（包括传统编程语言、计算机终端脚本、架构图等示意图脚本或用作AI聊天提示词的自然语言），而无须完全理解大模型生成的代

码。与传统编程最大的区别在于，氛围编程者往往因时间精力所限不会详细评审大模型生成的代码变更，即使不完全理解这些变更也会全盘接受（但这并不妨碍后期

仔细阅读、理解和测试）。当代码运行出现错误时，编程者只需将错误消息反馈给大模型，由大模型负责修复。

上述定义中的大模型，指的是在氛围编程场景下经常搭配的以下3种大模型（为行文方便，以后当与氛围编程工具搭配时统称大模型，而不再具体指明是哪类大模

型，各种大模型的对比参见9.5节）。

・大语言模型（large language model，LLM）：专门处理和生成文本的大规模神经网络模型，擅长理解和生成自然语言内容。如Claude Sonnet 4、GPT-4.1、

DeepSeek-v3-0324和Qwen-3。

・多模态大模型（large multimodal model，LMM）：能够同时处理多种数据类型（如文本、图像、音频）的大模型，实现跨模态理解和生成。如GPT-4o、Gemini

2.5 Pro、Doubao-seed-1.6和Kimi k1.5。

・专门化大模型（specialized model）：针对特定任务或领域进行深度优化的大

理解、完全接受。其中“不完全理解”这一特征意味着即使是不具备传统编程语言知识的非IT背景的人，也能在大模型的帮助下进行氛围编程。这就让“氛围编程谁

都行，解决问题变轻松”成为可能。

此外，这个氛围编程的定义还扩展了大模型所生成“代码”的范围，将可用作AI聊天提示词的自然语言也纳入其中。这呼应了卡帕西那条“最热门的新编程语言是英

语”的推文。

如果你对此仍有疑虑，不妨跟随我一起用手机进行一次氛围编程实战。

1.2.3 在手机上用Kimi生成第一段代码

因为Kimi比较热门且在手机端提供HTML代码预览功能，所以在此以Kimi为例进行说明。在手机上安装智谱清言或阶跃AI也可以实现同样的预览效果。此

外，也可以使用夸克、天工、DeepSeek、豆包、通义、文小言、MiniMax、秘塔AI搜索或讯飞星火，但这些应用大多无法在手机端预览HTML图形，只能在

计算机网页端预览，或将代码复制到codepen.io在线HTML工具查看。注意，如果选择元宝或纳米AI搜索，它们无法完成第4步中的图形绘制任务。

这个氛围编程实战将用手机上的AI聊天应用生成一个“Hello world音乐专辑封面”。Hello world程序通常是程序员入门时的第一个程序，它能在计算机终端显

示“Hello world”文字。既然氛围编程已经颠覆传统，不妨按下面的步骤让手机

上的Kimi应用搭配Kimi k1.5大模型生成一个独特的“Hello world音乐专辑封面”来纪念这个时刻。

（1）准备AI聊天应用Kimi手机应用。如果手机上尚未安装Kimi，可以在手机应用商店搜索“Kimi”并安装。如果手机上已经安装了Kimi，请确保更新到2.1.6或以

上版本。

（2）开启新聊天。如果Kimi正处于一个聊天中，那么可以点击屏幕右上角的 “+”，开启新聊天。

在其他应用中，类似的模式可能名为“推理”“深度思考”“深度”或“深度推理”，建议开启。

（3）开启“长思考（k1.5）”模式。如果提示词输入框底部显示“联网搜索”

功能，将其关闭，因为不需要搜索最新信息。

的输出：

请生成一个“Hello world”字样的动感浪漫专辑封面。要求使用浅色调，并以可运行的HTML格式输出。

将HTML代码单独放在一个代码块中，不要添加任何说明文字。

（5）查看HTML代码。点击大模型输出内容中HTML代码界面上方的“代码”选项卡，查看以<!DOCTYPE html>开头的代码，如图1-1所示。

这表明AI聊天应用已成功根据提示词生成了HTML代码。那么，这段代码是否能正常运行呢？

（6）预览HTML代码所画的动感浪漫专辑封面。点击代码界面上方的“预览”选项卡即可查看成品。封面中的“Hello world”文字、小红心和蓝色圆点都在缓慢移

动，表明生成的HTML代码运行正常，成功实现了预期的动态效果，如图1-2所示。

Kimi在首次对话中就根据提示词成功地生成了可运行的HTML代码，并呈现出一个动感的专辑封面效果。这个结果令人惊叹。那么，Kimi究竟是如何在背后运作，实现

这一功能的呢？

1.2.4 氛围编程中各个角色及其关系

在1.2.3节的氛围编程案例中，生成HTML版专辑封面涉及3个角色：氛围编程者、 Kimi手机应用和Kimi k1.5大模型。这三者之间的关系如图1-3所示。

图1-3其实是一张用C4模型（C4 model，一种新兴的架构可视化方法）风格绘制的架构图，围绕着3个关键角色及其互动展开。在这个氛围编程过程中，移动端氛围

编程者作为用户，通过语音或文字向系统描述创意需求，能生成个性化代码作品，并在手机上实时预览和分享这些作品。Kimi手机应用充当用户交互的前端界面，提

供语音和文字输入功能，管理多轮对话流程，支持代码的展示、编辑和实时预览，同时具备分享和导出功能。而在系统核心，Kimi k1.5大模型是由月之暗面开发的

AI引擎，它深度理解用户意图，支持长思考推理模式，针对创意代码生成和视觉设计进行了专门优化，并为移动端使用场景做了适配。

在交互关系方面，用户首先通过语音或文字向Kimi应用输入创意需求，包括设计风格偏好和技术要求。随后Kimi应用将这些需求发送给大模型进行内容分析和长思考

推理。整个系统的设计理念是让普通用户能通过自然语言描述，在移动设备上轻松创建专业的HTML专辑封面，实现氛围编程的创作体验。

从图1-3可以看出，Kimi k1.5大模型是完全独立于Kimi手机应用的系统。Kimi手机应用充当中间人角色，它接收用户的提示词，经过处理（可能保持原样，也可能添

加额外提示词）后，将其发送给后端的Kimi k1.5大模型。

若将图1-3改编为本书的氛围编程主题，呈现的结构如图1-4所示。

图1-4也展示了3个关键角色及其关系。第一，氛围编程者作为用户，通过自然语言表达自己的编程需求，无须深入掌握复杂的编程语法。用户只需描述想要实现的功

能，然后让AI为其生成可直接运行的代码，并在需要时通过对话方式进行迭代优化。

第二，氛围编程工具扮演着用户与AI之间的桥梁角色，形式多样且功能丰富。这些工具可能是AI聊天应用（如Claude或ChatGPT），也可能是基于浏览器的云AI

IDE，或是专为AI编程设计的AI原生IDE，甚至是传统IDE中的AI插件和命令行界面的终端AI应用。不论形式如何，它们都提供了人机交互界面，管理对话上下文，搭

配大模型，协调各子系统运作，处理多轮对话逻辑，并展示生成的代码和运行结果。

第三，关键角色是大模型，作为整个系统的核心AI引擎，它具备深度理解自然语言编程需求的能力，可以生成高质量代码和相关文档，进行逻辑推理和任务规划，智

能决策何时调用外部工具，并能分析错误提供修复方案。

在交互流程中，用户首先通过自然语言向氛围编程工具描述需求和技术约束，工具接收并处理这些输入；随后，氛围编程工具将用户需求连同上下文信息和历史对话

记录发送给大模型进行处理。这种架构设计的核心价值在于大幅降低了编程门槛，让用户能够通过自然语言交流方式实现编程意图，而无须深入掌握特定编程语言的

语法和技术细节。

需要特别强调图1-4中的一个关键点：大模型是完全独立于氛围编程工具的外部系统，但很多人误认为这两者是一体的，以至于错误地认为氛围编程工具代表着AI生

成代码的能力，而实际上起作用的是大模型。此外，虽然“AI生成代码”这种说法已经流行起来，但需要明确这个表述实际上指的是“大模型生成代码”，而氛围编

程工具主要起中间人的作用。

【避坑指南】大模型独立于氛围编程工具会导致什么令人困惑的现象？

会导致这样的怪事：分别在Cursor和Trae国际版中搭配相同的Claude Sonnet 4大模型，并提交相同的提示词，Cursor可能在首次对话时生成良好的代码，而Trae国

际版可能会运行出错（此处仅用Cursor和Trae国际版举例，并不意味着实际情况确实如此）。

出现这种情况通常有两个原因。首先是1.2.9节提到的大模型“概率性生成机制”

——Trae国际版访问大模型时可能恰好遇到大模型产生“幻觉”。其次是氛围编程工具作为“中间人”对提示词的处理和大模型参数的配置可能不当。以温度

输出的随机性和创造性，取值通常在0到1之间（某些系统可能支持更高值）。设置较低的温度值会让大模型倾向于选择概率最高的词，设置较高的值则增加其他词的

选择可能性。这就像从同一个海鲜摊位买来相同的食材，不同厨师却能做出不同风味的菜品。因此，如果发现Trae国际版即使使用同版本Claude大模型也总是生成质

量不佳的代码，很可能是因为第二个原因。遇到这种情况，建议改用Cursor。

如果你对氛围编程背后更完整的运作机制感兴趣，可以将图1-3绘制得更详细，这样使用Kimi生成HTML版专辑封面的氛围编程完整版概念图如图1-5所示（如果不感

兴趣，可以放心地跳到下一节）。

图1-5 使用Kimi生成HTML版专辑封面的氛围编程概念图（只包含框架的完整版）

图1-5之所以展示“只包含框架的完整版”，是因为包含职责描述的完整版概念图文字过多，无法在一页纸中展现全貌，因此图1-5删去了职责描述，仅保留各子系

统的标题及相互之间的关系。要全面理解这张图，建议在计算机上打开完整版（可

纯文本脚本），边预览图边阅读后续解释文字。如果你不知如何预览SVG格式的完整版，可通过浏览器访问免费在线SVG图预览工具svgviewer.dev，然后用Trae国际

版（如未安装可参见附录A.1进行安装）打开“图1-5-full.svg”文件，将文件中的所有SVG脚本复制并粘贴到svgviewer.dev页面左侧输入框，即可在右侧预览此

图。或者，你也可以向你喜欢的AI聊天应用提问：“你是互联网信息搜索专家，请搜索互联网，找出3款能在浏览器中预览SVG图的在线免费工具”，然后从AI聊天应

用推荐的工具中选择合适的工具预览SVG图。

图1-5所示的概念图（只展示概念，并非实现Kimi手机应用的架构图）全面展示了 Kimi如何生成HTML版专辑封面的完整工作流程。整个系统由8个相互关联的核心组

件组成，共同打造出一个复杂而高效的创作环境。

除了图1-3中包含的氛围编程者、Kimi手机应用和Kimi k1.5大模型，系统还包含了移动端渲染引擎、代码编辑器、媒体管理器、云端存储和分享系统，以支持完整的

创作体验。移动端渲染引擎基于WebView技术提供HTML/CSS/JavaScript的渲染能力，以方便用户预览HTML代码绘制的专辑封面图；代码编辑器为移动端优化了代码

处理功能；媒体管理器负责各类设计资源的管理；云端存储提供作品同步和历史记录；分享系统则实现了多平台的分享能力。

整个创作流程包含8个主要步骤：用户输入创意需求，应用将其发送给k1.5大模型；大模型从媒体管理器获取设计资源，然后返回生成的代码；应用将代码送至编

辑器处理，再发送渲染请求给渲染引擎；渲染引擎返回结果后，应用最终向用户展示完成的作品。

此外，系统还支持优化流程，让用户提供反馈建议，应用将这些优化请求发送给大模型进行迭代改进。系统也支持将作品保存到云端存储，并允许用户通过分享系统

发布作品。

在系统协作机制方面，各组件之间形成了紧密的互动关系：代码编辑器与渲染引擎实现实时代码同步和预览刷新；媒体管理器与云端存储协同进行素材库更新和云端

备份；渲染引擎与媒体管理器合作实现动态加载素材和缓存管理；而在k1.5大模型内部，长思考模式所具备的推理能力支持深度需求分析和创意构思。

这个完整架构展现了现代AI辅助创作工具的复杂性和精巧设计，通过多个专业化组件的协同工作，为用户提供从创意描述到最终作品发布的完整氛围编程体验。

与图1-5类似，图1-6展示了氛围编程相对完整的运作机制概念图（与图1-5一样，这里展示的也是“只包含框架的完整版”，完整版可查看本书配套代码中的

ch01/c4-model-diagrams/图1-6-full.svg文件）。

图1-6 氛围编程运作机制概念图（只包含框架的完整版）

在这个生态系统中，除了氛围编程者、氛围编程工具和大模型，氛围编程工具所使用的代码运行环境不仅能隔离个人计算机上的底层操作系统以确保安全性，还支持

多种编程语言的实时运行，捕获运行结果并检测错误，同时监控代码性能和资源使用情况。工具调用系统则提供丰富的扩展功能模块，包括文件系统操作、网络请求

处理、数据库访问、第三方API集成和外部服务调用。

并提供分支管理和多人协作支持。知识库则存储编程知识和最佳实践，包含代码模板、设计模式、技术文档，并提供常见问题的解决方案库。

在完整工作流程中，核心生成流程包括9个步骤：首先，用户用自然语言描述功能需求和技术约束；然后，氛围编程工具将需求发送给大模型；接着，大模型从知识

库获取相关模板和最佳实践；根据需要调用工具进行文件操作、API调用等；之后，大模型返回生成的代码、文档和解释说明；氛围编程工具在安全环境中运行生

成的代码；运行环境返回运行输出、错误消息和性能数据；用户看到代码内容、运行结果和改进建议；最后，氛围编程工具将代码保存到仓库进行版本管理。此外，

还有持续优化流程，即用户提供反馈和修改需求，系统进入新一轮优化循环。

在系统协作机制方面，工具调用系统与运行环境之间的协作确保工具在安全沙箱环境中运行，保证系统安全；而知识库与代码仓库之间的协作则使知识库能从代码仓

库学习新的编程模式，持续更新知识储备。

这个完整架构实现了“描述即编程”的愿景：降低了使用门槛，让用户只需描述想法，无须掌握编程技能就能生成可运行的代码；提高了效率，由大模型自动处理复

杂的代码生成和优化工作；提升了质量，通过知识库和最佳实践提升代码质量；确保了安全可靠，在隔离环境中运行代码，保证系统安全；并且能够持续改进，通过

反馈循环不断优化生成结果。这种架构代表了氛围编程工具的未来发展方向，让编程变得更加直观、高效和易用。

使用Kimi手机应用生成HTML版专辑封面的例子展示了AI聊天应用作为氛围编程工具的应用。那么，除了AI聊天应用外，还有哪些其他类型的氛围编程工具呢？

1.2.5 氛围编程工具

撰写本书时，氛围编程工具可分为以下6类。

（1）AI聊天应用。这类工具一般提供手机应用和网页端应用，少数还提供计算机桌面应用。其界面类似微信的一对一聊天：用户输入提示词后，AI聊天应用将其发

送给搭配的大模型处理，并在聊天区显示回复内容。目前国内常见的AI聊天应用包括DeepSeek、豆包、Kimi、通义、元宝、文小言、智谱清言、阶跃AI、夸克、天

工、秘塔AI搜索、纳米AI搜索、讯飞星火和MiniMax。

（2）智能体构建平台。这类工具主要用于创建、配置和部署定制化的AI智能体，通常提供网页端服务和部分移动端应用。其界面一般包含智能体配置区、知识库管

理区、工作流编辑区和预览测试区等模块。用户可以通过可视化界面设定智能体的

体构建平台有扣子、百度的AppBuilder和腾讯的元器。

（3）云AI IDE。这类工具主要用于生成带前端界面的Web应用和移动端应用，主要提供网页端服务，即主要在计算机浏览器中使用。其界面分为两部分：左侧类似AI

聊天应用，可输入提示词、查看AI回复，并进行代码解释、代码生成和工具调用；

右侧显示代码文件树、文件预览、应用运行预览和运行日志终端等界面。目前常见的云AI IDE包括Bolt.new、v0、Lovable和Replit。

（4）AI原生IDE。这类工具在本地计算机上运行，一般基于开源的Visual Studio Code（MIT协议，允许商用）开发，增加了代码解释、代码生成、调用工具等大模

型相关功能。使用这些功能需要搭配相应的大模型。这类工具也提供AI聊天界面，用于输入提示词和查看AI回复。目前常见的本地AI原生IDE包括Windsurf IDE、

Cursor［从2025年7月16日开始，在国内使用Cursor搭配Claude系列大模型时会遇到“This model provider doesn’t serve your region”（该大模型厂商未向你

所在的地区提供服务）的错误提示，用户需要在Cursor的网络设置中将“HTTP Compatibility Mode”从默认的“HTTP/2”改为“HTTP/1.1”才能临时解决这一问

题。若介意这个问题，可用Windsurf搭配Claude Sonnet 4替代，因为恰好在7月中旬，Windsurf的CEO与核心团队投奔谷歌且Windsurf剩余团队及资产被Cognition公

司收购后，Windsurf又重新获得Claud系列大模型的完全使用权］、Trae（分为可连接Claude等国外大模型的国际版和仅能连接DeepSeek等国内大模型的国内版）和

Lingma IDE。

（5）传统IDE中的AI插件。这类工具作为Visual Studio Code或JetBrains IDE等传统IDE的插件存在。在Visual Studio Code的插件管理界面中激活AI插件并搭配

大模型后，插件会提供AI聊天界面，用于输入提示词、查看AI回复，还可进行代码解释、代码生成和调用工具等操作。虽然可以在同一IDE中安装多个AI插件，但通

常只激活一个使用。目前常见的本地传统IDE中的AI插件包括GitHub Copilot、 Cline、Augment Code、Roo Code、腾讯云代码助手CodeBuddy等。

（6）终端AI应用。这类工具在本地计算机终端中运行，表面上看像是在执行终端命令，实际上是以命令的形式调用所搭配的大模型来生成代码。目前常见的终端AI

应用包括Claude Code、Aider和OpenAI Codex CLI。

【避坑指南】没有编程经验的人，是不是只适合用AI聊天应用，而不适合用IDE 进行氛围编程？

恰恰相反。缺乏编程经验的人也可以通过书、视频和AI聊天应用的辅助快速掌握 IDE的使用。用IDE进行氛围编程有一个突出优势：如果AI生成的代码包含几十个源

围提交给大模型，无须每次都复制并粘贴。这种方式不仅让提示词简洁高效，还能帮助大模型更准确地理解你的需求。

这6类氛围编程工具都需要搭配大模型才能生成代码。那么，大模型是如何生成代码的呢？

1.2.6 大模型生成文本类内容的技术简介

大模型生成文本类内容（包括代码）的能力源于其深度学习架构和精心设计的训练流程。这个看似神奇的过程实际上遵循着清晰的技术路径：从构建强大的神经网络

“大脑”，到通过海量数据学习编程知识，再到指令微调让模型“听懂人话”，进而通过推理能力训练获得深度思考能力，并运用测试时缩放优化进行多轮验证，最

终在实际推理生成阶段实现真正的智能代码生成。

2025年标志着代码生成技术的重大转折点。传统的“下一个token预测”模式正在被推理大模型和混合推理技术所革新。现代代码生成不再只是简单的模式匹配，而

是具备了类似人类程序员的深度思考和推理能力。整个技术体系现在包含架构设计、预训练、指令微调、推理能力训练、测试时缩放优化和实际推理生成6个核心

阶段。

1.架构设计

现在，用于生成代码的大模型主要采用基于2017年谷歌提出的Transformer架构。

与原始Transformer的编码器-解码器结构不同，当前主流的代码生成大模型（如 GPT系列和Code Llama）采用decoder-only架构，这种设计更适合自回归的代码生

成任务。Transformer的核心创新是自注意力（self-attention）机制，它让大模型能够全局地理解代码上下文，同时关注代码中的所有部分，“理解”变量定义、

函数调用、类继承等复杂关系；根据当前生成位置的需要，动态调整对不同代码片段的关注程度；相比传统循环神经网络（recurrent neural network，RNN）架

构，能够并行处理整个序列，大幅提升训练效率。

大模型通常包含多个并行的注意力头，数量因大模型而异，从8头到数十头不等。

每个头专注于理解代码的不同方面：有的关注语法结构和括号匹配，有的理解变量作用域和函数逻辑，有的学习代码格式和命名规范，还有的跟踪模块导入和函数调

用关系。

2.预训练

码（涵盖主流编程语言和框架）、技术文档和API说明（学习函数用法和最佳实践）、代码注释和README文件（理解代码意图和项目结构）及编程问答数据（学习

问题解决思路）。预训练的核心任务是“预测下一个token”，这类似于高级的完形填空。例如，当输入def fibonacci(n): if n <= 1: return时，大模型需要预

测下一个最可能的token，在这个例子中应该是n。

通过这个过程，大模型学会了各种编程语言的语法结构和规范，常见算法的实现方式和优化技巧，面向对象设计、函数式编程等编程范式，以及代码组织、错误处

理、性能优化等工程实践经验。

3.指令微调

为了让大模型“听懂人话”，研究者使用精心制作的指令-代码配对数据进行微调。例如，给出指令“用Python实现一个二分查找算法，要求处理边界情况”，然

后提供标准答案代码。指令微调覆盖了代码生成的各种场景：根据需求描述生成完整函数、根据上下文补全代码片段、识别并修正代码中的bug，以及为现有代码添

加注释和说明。

4.推理能力训练

2025年最重要的技术突破是推理大模型的兴起。现代大模型普遍采用人类反馈强化学习（reinforcement learning from human feedback，RLHF）技术进一步优化：

首先收集人类偏好数据，让程序员对不同代码方案进行评分；然后训练奖励大模型，学习人类对代码质量的判断标准；最后通过强化学习优化，使用近端策略优化

（proximal policy optimization，PPO，一种强化学习算法，用于优化大模型的生成策略，让大模型学会生成更符合人类偏好的内容）等算法让大模型生成更符合

人类偏好的代码。不同于传统的直接回答模式，推理大模型具备了深度思考能力。

核心推理技术包括思维链（chain-of-thought，CoT）推理（能够逐步分解问题，模拟人类思考过程）、扩展思考（extended thinking）（可以花费更多计算资源

进行深度推理）及混合推理模式（既能快速响应，也能进行深度思考）。

5.测试时缩放优化

测试时缩放（test-time scaling，TTS）是现代大模型的一项重要创新。它通过在推理阶段投入更多计算资源来显著提升输出质量。与传统的固定推理模式不同，测

试时缩放使模型能够根据问题复杂度动态调整计算投入：对复杂问题进行多轮深度思考，实时自我验证和纠错，并行探索多种解决方案以选择最优方案。这种技术让

AI系统在面对挑战性任务时表现出更接近人类专家的思维过程。

实际推理生成是训练成果转化为实用代码的关键环节。当开发者输入需求后，大模型会像真正的程序员一样开始思考。它首先进入上下文理解阶段，仔细分析整个编

程环境，包括项目结构、现有代码、使用的框架和依赖，同时深入理解开发者的具体需求，从而全面把握整个编程场景。接着在推理思考阶段（这是2025年推理大模

型的最大特色），大模型会在内部进行深度“思考”，分析问题复杂度，制定解决策略，并权衡多种可能的实现方案。在这个过程中，大模型会不断自问：“我需要

考虑哪些边界条件？”“哪种算法最适合当前的性能要求？”“如何确保代码的可维护性？”随后，大模型进入方案验证阶段，对已生成的代码进行全面自检，验证

其语法正确性、逻辑一致性，以及是否遵循最佳实践。一旦发现问题，就会自动进行修正和优化。最后在代码输出阶段，大模型呈现经过深思熟虑和严格验证的代

码，并附带相关解释、使用建议或未来可能的改进方向。这样的流程体现了AI编程从简单的“预测下一个token”到“思考下一步”的“智能编程助手”的根本性转

变，是所有技术阶段综合作用的成果。

1.2.7 推理大模型的兴起

2025年是人工智能发展的重要转折点：从传统的模式匹配和统计生成转向具备真正 “推理思考”能力的大模型时代。推理大模型的核心特征在于其能够进行多步骤逻

辑推理，将复杂问题分解为可处理的子问题，通过扩展思考验证推理过程的正确性，并在推理过程中动态调用外部工具和知识。

2025年1月20日发布的DeepSeek-R1作为开源推理大模型产生了巨大影响：采用6710 亿参数的混合专家模型（mixture of experts，MoE）架构；通过纯强化学习获得

推理能力，无须监督微调；完全开放大模型权重，降低了技术门槛；使用MIT许可证，允许商用；在保持性能的同时大幅降低使用成本，促进了大模型推理技术的普

及。

模型权重

“模型权重”是大模型通过算法训练过程自动优化得到的参数数据，即大模型的 “大脑记忆”，决定了大模型如何处理信息并生成回应。传统上，OpenAI和

Anthropic等公司仅提供付费API服务，用户无法获取模型内部参数。而“完全开放大模型权重”意味着参数文件公开发布，用户可免费下载完整模型，在本地设备运

行，无须依赖第三方服务，且大模型结构完全透明。这种开放模式影响深远：实现了技术全民化，打破大公司对AI技术的垄断；引发了成本革命，消除持续API费

用；加速了创新，促进二次开发和定制；提高了研究透明度，助力AI安全和可解释

转变，可能重塑整个AI产业格局。

DeepSeek-R1的一个重要创新是向用户完全展示其推理过程，通过<think> </think>标签将模型的逐步思考过程暴露给用户。这种透明度与OpenAI的o1系列形

成鲜明对比——后者在后台进行链式思考推理，但只向用户提供高级总结，不展示详细的推理步骤。

推理透明化的意义在于大幅提升人机协作的效果。通过允许用户实时观察模型如何分析问题和测试不同方案，可解释性得到显著增强。当模型出错时，用户能够精确

定位推理过程中的具体问题点，从而更高效地进行错误诊断。此外，这种透明化还具有重要的教育价值，推理过程的展示为用户提供了宝贵的学习资源，帮助他们理

解AI的思考方式。最重要的是，透明的思考过程能够建立用户对AI决策的信任基础，让人们更加愿意接受和采纳AI的建议。

2025年5月23日发布的Claude 4系列代表了本书撰写时推理大模型在代码生成方面的领先水平：Claude Opus 4在SWE-bench测试中达到72.5%的准确率，超越所有竞

争对手；Claude Sonnet 4的编程和推理能力显著提升，指令遵循更精准，支持即时响应和扩展思考两种模式，并且可以在推理过程中调用外部工具。

推理大模型带来的不仅是代码生成质量的提升，更是开发模式的根本改变：AI从简单的代码补全发展为能够独立思考的编程伙伴，能够处理需要数小时的复杂重构和

开发任务，并通过与开发者的互动不断优化。

随着2025年推理大模型的兴起，大模型已能在多种编程场景下提供接近人类专家水平的代码生成服务，正在根本性地改变软件开发的模式和效率。这标志着我们进入

了一个AI能够进行“思考”和“推理”的编程时代。

1.2.8 大模型发展趋势与未来展望

2025年大模型发展正经历一场双重转型，从大参数向小参数、从稠密向稀疏结构演进。混合专家模型已成为主流架构选择，它在通过条件计算实现参数扩展的同时，

显著降低了计算成本。专业化趋势日益明显，针对特定编程语言和领域的大模型优化不断深化，代码生成的速度和准确率持续提升。其中，CodeT5在需要双向理解的

复杂代码智能任务上表现出色，而StarCoder则在大规模、多语言的代码生成和实时辅助编程方面展现优势，这些专门的编程大模型在各自擅长的领域都超越了通用

大模型的表现。

当前，大模型正经历从单模态的大语言模型向多模态模型的关键转型。多模态代码

码，极大降低了编程门槛；系统甚至可以从演示视频或操作序列自动生成脚本，实现从知识到执行的无缝转换。

2025年是大模型从强概率生成向强推理能力的重要转折点。新一代推理大模型，如 OpenAI的o系列、Anthropic的Claude 4 Extended Thinking、Google的Gemini 2.5

Pro Deep Think等，在数学、逻辑推理和复杂问题解决方面实现了显著突破，为科学研究、金融分析和法律咨询等专业领域的应用奠定了坚实基础。

未来的编程大模型将更加智能化和情境化。它们能够学习并适应个人的编程习惯、命名约定和架构偏好；自动适应团队的代码规范、工作流程和最佳实践；并深度融

合企业内部的工具链、知识库和业务流程。这种个性化与协作化的演进使AI成为真正意义上的编程伙伴。

与此同时，移动端和边缘端AI智能体已成为新的增长点。通过大模型压缩和知识蒸馏等技术，大模型能够在资源受限的环境下高效运行，这一趋势正推动AI技术在物

联网、智能家居和工业机器人等领域的广泛应用。

尽管技术进步迅速，大模型仍面临着计算资源消耗、部署成本、数据安全和伦理合规等诸多方面的挑战。未来的发展将更加注重效率与性能的平衡、大模型的可解释

性，以及与人类价值观的对齐，推动AI技术向更加可信、可控和普惠的方向发展。

大模型展现出强大的代码生成能力，但在使用氛围编程工具搭配大模型进行氛围编程时，有必要关注其中潜藏的风险。

1.2.9 氛围编程的潜在风险

氛围编程虽然降低了编程门槛，但其“完全接受AI生成代码”的核心特征在2025年推理大模型时代带来了更加复杂和隐蔽的系统性风险。这些风险主要来自下面3个

层面。

1.传统大模型的固有限制导致了“幻觉”问题

大模型在生成代码时出现“幻觉”主要有以下5个原因。

（1）训练数据有局限性。大模型只能基于已有的训练数据学习。如果训练数据中存在错误，大模型就可能学习并重现这些错误。同时，训练数据可能存在偏见或不

完整的问题。

容。在遇到不确定情况时，它会选择看似“合理”的答案，可能生成表面正确但实际有误的内容。

（3）上下文长度有限制。大模型的对话上下文长度有限，因此对大型代码项目的理解可能不够全面。

（4）提示词有歧义。用户提供的提示词可能含糊不清，导致大模型产生理解偏差。

如果搭配大模型的氛围编程工具能够连接计算机上的代码执行环境（如图1-6 所示）来执行命令、捕获结果、检测错误，并能在随后让大模型进行修复，

那么就能缓解这个风险。若在Cursor中开启“Auto-fix errors”，就能实现这一点。

（5）缺乏真实性验证。大模型没有内置的事实检查机制，无法实时验证生成内容的准确性，只能依靠模式匹配而非真正理解。

2.推理大模型带来新风险

2025年推理大模型的兴起带来了前所未有的4类风险。

（1）推理过程不透明风险。推理大模型的“扩展思考”和“多轮推理”过程在很多商业大模型中为黑盒，仅在部分大模型（如DeepSeek-R1）中可见，且即使可见

也往往超出普通用户的理解和验证能力，导致推理过程验证困难；当代码出现问题时，难以回溯大模型的推理过程进行问题定位；企业合规审计难以验证大模型的决

策逻辑是否符合内部规范。

（2）伪理性和过度自信风险。推理大模型能够生成看似合理的推理过程，但可能基于错误的前提或逻辑漏洞；大模型的“自我验证和纠错”能力可能给用户错误的

安全感，实际上验证过程本身可能存在盲点；深度推理可能将初始的小偏差通过逻辑链条无限放大。

（3）计算资源和成本风险。推理大模型的“测试时缩放优化”可能导致计算成本急剧增加且难以预估；对复杂问题的深度推理可能需要大量计算资源，影响系统稳

定性；推理过程的计算密集性可能导致服务响应延迟或中断。

（4）混合推理模式风险。快速响应和深度思考模式之间的切换可能导致代码质量不一致；大模型可能在简单问题上过度推理，在复杂问题上推理不足；推理过程中

产生的多种解决方案可能导致最终的选择不是最优方案。

氛围编程的特有风险主要体现在3个方面。

（1）氛围编程的“不完全理解代码”的本质所带来的内在风险。由于氛围编程者往往不会评审和深入理解大模型生成的代码，这种做法会放大传统风险，如大模型

可能生成存在安全漏洞的代码（如SQL注入、XSS攻击、权限设置不当等），而编程者可能忽视这些潜在威胁；大模型生成的代码可能侵犯版权、违反开源协议，或不

符合行业法规要求，为企业带来法律隐患；未经充分理解和测试的代码若直接部署到生产环境，可能导致系统崩溃、数据丢失或性能问题；过度依赖大模型会导致编

程者失去独立解决问题的能力，无法进行有效的代码调试、优化和维护。

（2）推理大模型时代还为氛围编程带来了新的风险。推理大模型生成的代码带有详细解释和看似专业的分析，可能让编程者误以为代码质量很高；推理大模型可能

生成表面简洁但内在逻辑复杂的代码，增加了后期维护的难度；深度推理可能导致大模型生成过度复杂的解决方案，偏离实际需求；从理解代码逻辑转向理解大模型

推理过程，可能导致新的认知盲区。

（3）氛围编程的系统性风险也不容忽视。代码质量难以把控，可能影响产品的稳定性和用户体验，同时积累大量技术债务，导致后期维护成本激增；对代码逻辑和

大模型推理过程都缺乏深入理解，会导致编程者在遇到复杂问题时无法进行有效的故障排查和系统优化；不同团队成员使用不同的推理模式可能导致代码风格和质量

不一致。

面对氛围编程的诸多风险，我们应该如何有效应对？

1.2.10 氛围编程的风险应对

为了应对这些风险，需要制定和实施有效的风险控制措施。

针对传统大模型固有限制导致的“幻觉”问题可以采取以下应对措施。氛围编程者可使用“减少AI幻觉”的智能体优化提示词，如加入“为每个主要观点提供3个不

同来源的相关出处的网页链接”和“如果你不知道或查不到，就实说，不要编造”

等“减幻”辅助提示词；搭建个人RAG（retrieval-augmented generation，检索增强生成，一种将检索和生成相结合的技术方法）知识库，弥补传统大模型知识固

化、无法获取实时信息的局限性，通过动态检索让AI系统能够“现学现用”，生成更准确、更符合当前需求的内容；使用LangChain、Chroma等工具将个人代码库、

技术文档构建成向量数据库；建立个人代码模板库，维护经过验证的代码片段作为参考；使用多轮对话验证，通过追问方式检验大模型输出的合理性。企业可建立企

建立交叉验证机制和错误模式学习机制。

针对推理大模型带来的风险可以采取以下应对措施。氛围编程者可以启用思维链提示，要求大模型展示详细推理过程；实施“双推理大模型交叉验证”，使用不同推

理大模型生成解决方案并比较差异；建立个人推理检查清单，系统地评估推理的逻辑性和合理性；使用“魔鬼代言人”提示技巧，让大模型扮演批评者角色，质疑和

挑战自己的输出，以发现潜在问题，主动发现推理漏洞。企业可以要求大模型提供推理过程的关键步骤和决策依据；建立推理过程评审流程和可视化工具；设置计算

资源使用上限和成本预警机制；实施“红队测试”，故意设置陷阱问题或对抗性场景，来检验大模型推理能力的稳健性和可靠性；建立推理过程记录和审计机制。

针对氛围编程的特有风险可以采取以下应对措施。氛围编程者可以采用“氛围编程先行，‘理测评解’跟进”模式（参见9.3.3节），确保能解释生成代码的功能、

原理和影响；建立个人代码评审流程，包含功能验证、性能检查、安全扫描；使用渐进式测试策略，先在隔离环境验证再部署；维护“AI生成代码日志”，记录使用

情况便于回顾改进；设置“理解度门槛”，根据代码重要性确定不同的理解要求。

企业可以实施分级使用策略，非关键系统可适度使用氛围编程，关键系统采用“氛围编程先行，‘理测评解’跟进”模式，核心安全系统禁止氛围编程；建立“理解

优先”原则和代码理解度评估机制；确保多层验证机制，包括80%以上的自动化测试覆盖率和专业人士代码评审制度。

企业为了防范安全与合规风险，需要建立代码安全扫描机制、知识产权合规检查、法规符合性审查流程和代码安全责任制。同时提升程序员编程能力，定期进行无AI

辅助的编程练习，建立技能退化预警机制。企业还需制定大模型代码生成规范、设立质量监管岗位，并构建实时风险监测系统。

通过这些综合性的风险控制措施，就可以在享受大模型带来的编程效率提升的同时，有效降低氛围编程在新技术环境下的各类风险。

氛围编程的核心价值在于让不同技术背景的人都能通过自然语言在氛围编程工具的帮助下与大模型对话，快速解决实际问题。下面将针对本书的3类目标读者，详细

介绍他们在日常工作和学习中最常见的氛围编程应用场景，并展示氛围编程的价值。

1.3 非IT背景的人的氛围编程应用场景

非IT背景的人的典型氛围编程应用场景主要包括办公自动化、数据分析与可视化、应用原型快速实现，以及个人事务提效。

氛围编程在办公自动化方面的应用可以有以下两个典型场景。

（1）文档批量处理。行政助理小王每月需要处理数百份员工报销单据。传统方式下，他需要逐一打开文档、提取信息并录入Excel表格，既耗时又容易出错。使用

氛围编程时，小王只需对氛围编程工具说：“帮我写一个脚本，批量读取文件夹中所有PDF报销单，提取报销人姓名、金额、日期和类别，然后生成一个Excel的汇总

表。”有了大模型生成的代码，小王无须理解技术细节，便能在几分钟内完成原本需要几小时的工作。

（2）数据清理与格式转换。财务专员李姐经常收到各部门提交的不同格式的数据表格，需要统一格式才能进行分析。她在氛围编程工具中输入描述：“我有很多

Excel文件，格式都不一样，有些日期是文本格式，有些金额包含货币符号，请帮我写代码统一处理成标准格式。”大模型生成的代码能自动识别并转换各种格式，

让李姐摆脱了烦琐的手工整理。

1.3.2 数据分析与可视化

氛围编程在数据分析与可视化方面的应用可以有以下两个典型场景。

（1）销售数据分析。市场部的张总监需要分析季度销售数据，但不熟悉复杂的 Excel函数。他告诉氛围编程工具：“分析这个销售数据表，按地区和产品分类计

算销售额，找出增长最快的产品线，并生成图表显示趋势。”大模型不仅生成了数据透视表和图表，还提供了分析报告模板，使张总监能轻松完成专业分析。

（2）客户满意度调研。客服主管需要分析大量客户反馈问卷。她对氛围编程工具说：“这里有1000份客户反馈，请帮我分析情感倾向，统计主要问题类别，并生成

可视化报告。”大模型生成的代码自动完成文本分析和情感分析，快速生成专业报告。

要确保大模型生成的数据分析与可视化结果的准确性，可以参考3.8节，掌握用氛围编程辅助验证数据准确性的方法。

1.3.3 应用原型快速实现

氛围编程在应用原型快速实现方面的应用可以有以下两个典型场景。

作不仅耗时费力，而且最终效果往往难以让用户完全理解产品愿景。他尝试使用氛围编程，只通过一段自然语言描述，就快速生成了一个功能完整的在线教育平台

Web应用原型。这样操作不仅缩短了产品验证周期，还能让用户通过可交互的原型直观体验产品功能，有效解决了传统原型制作周期长、用户体验有限的痛点。通过

这种方式，老陈显著提升了产品需求验证的效率和准确性。

（2）创业想法快速呈现。创业者小刘使用自然语言描述让氛围编程工具及所搭配大模型的组合，成功实现了一个功能完整的邻里互助平台Web应用。这不仅展示了

氛围编程对非技术背景创业者的赋能作用，还彻底解决了传统创业过程中的一大痛点——过去这类创业者往往只能通过静态的概念图和简单的原型来向投资人展示产

品愿景，难以真实呈现产品的实际体验和完整功能。通过氛围编程，小刘不仅快速将创意转化为可用产品，还大大提升了与投资人沟通时的说服力和可信度。

1.3.4 个人事务提效

氛围编程在个人事务提效方面的应用可以有以下两个典型场景。

（1）个人财务管理。上班族小李想要更好地管理个人财务，但现有软件要么过于复杂，要么不够个性化。他向氛围编程工具描述：“帮我做一个简单的记账工具，

能录入收支、按类别统计，显示月度趋势图。”大模型生成了一个简洁的Web应用，小李不仅可以直接使用，还能根据需要随时调整功能。

（2）学习进度跟踪。在职考证的小王需要跟踪学习进度。她对氛围编程工具说：

“做一个学习计划管理工具，能设置学习目标、记录每日学习时间、显示完成进度，并提醒复习时间。”大模型生成了个性化的学习管理应用，帮助她更好地规划

和执行学习计划。

1.4 有IT经验的人的氛围编程应用场景

有IT经验的人的典型氛围编程应用场景包括快速原型开发、开发效率提升以及跨技术栈探索。

1.4.1 快速原型开发

氛围编程在快速原型开发方面的应用可以有以下两个典型场景。

（1）新技术验证。资深工程师老赵需要验证新的API集成方案。传统方式需要搭建完整开发环境，编写大量样板代码。使用氛围编程，他告诉氛围编程工具：“帮我

接口。”大模型在几分钟内就生成了完整的可运行原型，让他能快速验证技术方案的可行性。

（2）实现难度估算。产品经理提出新需求后，技术总监需要快速评估实现难度。

他向氛围编程工具描述：“做一个智能客服聊天应用原型，能理解用户问题、查询知识库、返回答案，并记录对话历史。”大模型生成的原型让团队能在几小时内看

到应用的具体效果，显著加快了需求评估和方案讨论。

1.4.2 开发效率提升

氛围编程在开发效率提升方面的应用可以有以下两个典型场景。

（1）自动化测试代码生成。测试工程师小周面临紧急项目，需要编写大量测试用例。她对氛围编程工具说：“根据这个API文档，生成完整的自动化测试套件，包

括正常场景、异常场景和边界值测试。”大模型生成了全面的测试代码，既节省时间又确保了测试完整性。

（2）代码重构方案生成。高级工程师面临一个遗留系统的重构任务，代码复杂且缺乏文档。他告诉氛围编程工具：“分析这个老项目的代码结构，帮我生成现代化

的微服务架构方案和迁移脚本。”大模型不仅分析了代码结构和依赖关系，还生成了详细的重构方案和自动化工具的代码。

1.4.3 跨技术栈探索

氛围编程在跨技术栈探索方面的应用可以有以下两个典型场景。

（1）新框架学习。全栈工程师需要快速掌握最新前端框架。他对氛围编程工具说：“用Vue 3和TypeScript帮我做一个完整的任务管理应用，包含用户认证、数

据持久化和响应式设计。”大模型生成的完整项目成了最佳学习材料，让他能在实践中快速掌握新技术。

（2）技术栈整合。架构师需要评估不同技术栈的整合方案。他向氛围编程工具描述：“设计一个基于微服务的电商系统，前端用React，后端用Node.js和Python，

数据库用MongoDB和Redis，包含完整部署方案。”大模型生成的架构方案和示例代码为技术选型提供了有力支撑。

1.5 IT新人的氛围编程应用场景

1.5.1 基础技能学习

氛围编程在基础技能学习方面的应用可以有以下两个典型场景。

（1）编程概念理解。新入行的程序员小新对很多编程概念还不太理解。他对氛围编程工具说：“帮我做一个演示程序，用具体例子展示面向对象编程的继承、封装

和多态的概念。”大模型生成了生动的示例代码和交互式演示，让抽象概念变得具体可感。

（2）算法学习实践。计算机专业应届生小颖正在准备技术面试。她向氛围编程工具请求：“实现常见排序算法，包含可视化演示，能看到排序过程，并比较不同算

法的性能。”大模型生成的可视化学习工具帮助她深入理解算法原理。

1.5.2 项目实战练习

氛围编程在项目实战练习方面的应用可以有以下两个典型场景。

（1）完整项目开发。新人开发者想要积累项目经验。他对氛围编程工具说：“帮我做一个完整的博客系统，包含前后端分离架构、用户管理、文章发布、评论和搜

索功能。”大模型生成的项目不仅功能完整，还包含了详细的开发文档和部署指南，成了宝贵的学习资源。

（2）开源项目贡献。想参与开源项目的新人不知从何入手。她告诉氛围编程工具：“分析这个开源项目的代码结构，找出我可以贡献的部分，并帮我准备贡献代

码。”大模型帮助她理解项目架构，识别改进点，并生成规范的贡献代码。

1.5.3 开发工具使用

氛围编程在开发工具使用方面的应用可以有以下两个典型场景。

（1）开发环境配置。实习生对复杂的开发环境配置感到困惑，他向氛围编程工具求助：“帮我配置完整的Web开发环境，包含编辑器设置、Git配置、数据库安装和

项目脚手架搭建。”大模型生成了详细的配置脚本和说明文档，让环境搭建变得简单明了。

（2）部署及运维过程学习。新人需要学习项目部署，她对氛围编程工具说：“教我如何将Web应用部署到云服务器，包含域名配置、HTTPS证书、数据库备份和监控

1.6 氛围编程的核心价值

讨论完3类人群常见的氛围编程应用场景后，现在可以总结一下氛围编程对于他们的核心价值。

氛围编程为3类不同人群带来了独特的价值。

对于非IT背景的人，它最大的价值在于降低技术门槛，让他们能够用自然语言解决专业问题。普通办公人员可以通过氛围编程将原本需要几小时的报销单据处理缩短

至几分钟，无须掌握复杂技术；业务人员能够进行专业级数据分析和可视化；产品经理和创业者可快速将创意转化为可交互原型；个人用户则能创建定制化的管理工

具来提升效率。

对于有IT经验的人，氛围编程的核心价值体现在提升开发效率和加速技术创新方面。它能将传统需要数天的技术方案验证缩短至几小时甚至几分钟；通过自动生成

测试代码和重构方案，让开发者从烦琐的工作中解放出来；帮助工程师快速掌握新框架、整合不同技术栈；并为架构决策提供有力支持。

IT新人则能从氛围编程中加速学习和积累实战经验。抽象的编程概念（如面向对象）和算法原理可以通过可视化示例变得更容易理解；新人能够快速获得完整的项

目开发经验；轻松掌握各种开发工具和最佳实践；甚至降低参与开源项目的门槛，加速融入开发者社区。

总体而言，氛围编程的核心价值可以概括为“氛围编程谁都行，解决问题变轻松”。它通过自然语言交互的方式，让不同技术背景的人都能利用AI的能力快速解

决实际问题，实现了编程的全民化。无论是办公自动化、数据分析、原型开发，还是代码生成、技术探索、学习辅助，氛围编程都能显著提升各类人群的工作效率和

创新能力。

探讨完氛围编程的核心价值后，就可以开始思考如何实际运用氛围编程。为了实现 “首次对话即成功”，需要合理搭配氛围编程工具与大模型。那么，应当如何进行

这种搭配呢？

1.7 氛围编程指导原则与工具及大模型的搭配

对于某些需求（如第4章中的Excel数据分析），使用AI聊天应用、AI原生IDE和传统IDE中的AI插件搭配大模型都能实现，那该如何选择呢？在氛围编程过程中要注

原则及其相关实例，做出合理的决策。

氛围编程简单性指导原则：氛围编程因其“即使不完全理解也会完全接受AI生成的代码”的本质，适用于解决简单需求或生成“一次性”代码的场景，而不适合处

理复杂需求的场景。

当项目的代码规模在几百行且用完就可丢弃时，氛围编程最为适用。若项目需求过于复杂，总代码行数达到5000行（参见1.2.1节后半部分）以上，且还想尝试本节

后面介绍的“理测评解”跟进指导原则，那么需要首先考虑按照软件架构设计最佳实践拆分出一小块“高内聚低耦合”且代码总行数在几百到2000（随着大模型技术

的发展可以合理调整）行之间的组件，然后在其上进行尝试。

氛围编程生成内容不完美指导原则：在氛围编程中，编程者与大模型的每次对话所生成的代码出现运行错误或虽然运行不出错但功能未达到预期是常态，期望氛围

编程“每次对话即完美”是不切实际的。

氛围编程因其所依赖的大模型在生成内容时存在幻觉，或在推理时过度自信（参见 1.2.9节），生成的代码有时会出现运行错误，或者虽然运行不出错但功能未达到

预期的情况。这些情况需要反馈给大模型进行修复。因此，如果氛围编程的每次对话所生成的代码能满足提示词要求的70%～80%，就已经相当不错了。需要降低对氛

围编程不切实际的期望（参见3.6节结尾和3.7节结尾）。

氛围编程多工具组合指导原则：如果用氛围编程完成一个需求相对复杂的项目，那么针对需求拆分后的不同子需求，往往需要根据各个子需求的特点选用不同但适

用的氛围编程工具与大模型的搭配组合来完成。

例如在做Excel数据可视化时，前期可以选用Trae国际版搭配Claude Sonnet 4大模型来生成视觉效果精美且数据分析维度合理的综合数据看板作为原型；之后可以用

Windsurf搭配o3大模型针对这个原型看板中的数据维度重新生成较为准确的数据并填入，形成待验证的看板；最后再用Claude搭配Claude Sonnet 4大模型验证看板

中的数据准确性，并最终形成成果看板（参见3.8节结尾）。

氛围编程提示词不完美指导原则：在氛围编程中，编程者可以使用存在少量语病的口语化提示词与大模型沟通，这通常并不妨碍大模型对编程者意图的理解。

例如，在提示词输入框中输入的“提供至少3个不同来源的出处网页链接以便我查验”这句提示词中的“出处”后面少了一个“的”，又如“查不到请直说”中的

“请”前面少了一个逗号，这些语病通常不会影响大模型对这句话意图的理解。这

标点符号无误的提示词（参见5.1节）。

氛围编程“理测评解”跟进指导原则：当希望在复杂需求场景下运用氛围编程时，可以先从小处入手。例如，从复杂软件系统中拆分出一个“高内聚低耦合”且

代码总行数在几百到2000（随着大模型技术的发展可以合理调整）行之间的组件，并在组件内尝试“氛围编程先行，‘理测评解’跟进”（参见9.3.3节）的方式。

其中“理测评解”指理解、测试、评审和解释大模型所生成的代码。

当希望在需求复杂且需要长期稳定运行的软件系统中试点氛围编程时，应按照软件架构设计最佳实践将试点组件拆分出来，并务必在使用氛围编程方法生成代码后，

理解、测试（参见8.3节前半部分）、评审和解释大模型生成的每一行代码，才能将其提交到代码库。

氛围编程大模型升级指导原则：当你对任务的意义、概念和实现方法理解不够深入，难以在提示词中清晰表达时，你需要选择能力和口碑更强的氛围编程工具与能

力和口碑更强的大模型搭配组合，并尽量开启推理模式。

当你对任务的理解不够深入，难以在提示词中清晰表达时，应选择能力和口碑更强的大模型（参见6.3.2节靠近结尾处），如Claude智能聊天应用搭配Claude Sonnet

4大模型（开启“Extended thinking”模式）或Windsurf搭配Claude Sonnet 4大模型。

氛围编程大模型降级指导原则：当你完全理解任务的意义、概念和实现方法，并能在提示词中清晰表达这些要素时，即使在氛围编程工具中搭配能力较弱但口碑良

好的大模型，也能获得与搭配顶尖大模型相当的效果。

如果你既是编程专家又是业务专家，那么使用通义AI聊天应用搭配Qwen3大模型有可能生成与Windsurf搭配Claude Sonnet 4同等质量的代码（参见6.3.2节靠近结尾

处）。

氛围编程较弱大模型优化提示词指导原则：如果预算有限，只能搭配能力较弱但口碑良好的大模型，你需要更深入地理解任务的意义、概念和实现方法，且要根据

较弱大模型的回复观察其局限性，并在提示词中做有针对性的优化，以获得高质量回复。

如果预算有限，只能使用免费的通义AI聊天应用搭配Qwen3大模型，要获得高质量回复，你需要更透彻地理解任务的意义、概念和实现方法，且能识别通义回复内容

中的缺陷，并在提示词中做相应优化（参见6.3.2节的避坑指南）后再试。

编程工具搭配能力和口碑更强的大模型的高配组合，却仍发现代码生成质量较差，且让大模型多次修复也无法解决时，应优先考虑深化对任务的理解，并在提示词中

更清晰地表达这些理解内容后重新尝试。

即使你已选择当下顶级氛围编程工具与顶级大模型组合（如Claude搭配Claude Sonnet 4，开启“Extended thinking”模式），但生成的代码仍出现运行错误且

大模型多次修复失败时，应优先检查自己对问题的理解是否充分，提示词中表达的解决方案是否足够清晰明确，然后再次尝试（参见1.1.2节后半部分）。

氛围编程高配组合放松要求指导原则：当遵循氛围编程高配组合优化提示词指导原则尝试后仍然无效，可考虑在提示词中适当放松对大模型的要求，令其自由发挥

后重新尝试。

即使已遵循氛围编程高配组合优化提示词指导原则，已在提示词中表达得足够清晰，但效果仍然不好，那么可以尝试在提示词中去除一些对大模型的要求，让大模

型能够有自我发挥的余地后再尝试（参见6.2节结尾）。

氛围编程原厂优先指导原则：使用特定大模型时，优先选择该大模型开发商自己提供的成熟且口碑良好的氛围编程工具。

值得注意的是，通义开发商阿里于2025年5月29日推出的Lingma IDE在本书撰写时尚未完全成熟，如在提示词输入框中无法通过#或+按钮插入以中文命名

的文件。

使用特定大模型时，优先选择该大模型开发商提供的成熟且口碑良好的工具——使用DeepSeek-R1大模型时，选择DeepSeek网页端或手机应用；使用Qwen3大模型时，

选择通义网页端；使用Claude Sonnet 4大模型时，选择Claude网页端、手机应用或桌面应用（参见3.9节开头）。

讨论完氛围编程的基础概念，不妨回到氛围编程最打动人的亮点：“AI编程像聊天一样简单”。对于一个从未学过传统编程语言的人，真的能用自然语言编写应用并

将其部署上线，供自己和亲友使用吗？第2章将通过一个实战项目来探讨这个问题。