2025年初，著名人工智能研究员Andrej Karpathy（前特斯拉AI主管、OpenAI创始成员之一）在一条病毒式传播的推文中提出了“vibe coding”（氛围编码）这个词：
“我称之为‘氛围编码’的新型编码方式，是完全顺应感觉，拥抱指数增长，甚至忘记代码的存在。这成为可能是因为大型语言模型（例如使用Sonnet的Cursor Composer）变得太强大了。而且我现在直接用SuperWhisper对Composer说话，几乎不用动键盘。我会要求它做一些很傻的事，比如‘把侧边栏的内边距减半’，因为我懒得自己找。我总是‘一键接受’修改，不再看代码差异。当出现错误提示时，我直接复制粘贴错误信息给它，通常它就能修好。代码已经超出了我平时能理解的范围，我得花很长时间才能完全看懂。有时模型修不了的bug，我就绕过它或者随机改改，直到问题消失。这种方式对周末随便搞搞的小项目还不错，挺有趣。我是在建一个项目或网页应用，但其实并不是真正的编码——我只是看着、说着、运行、复制粘贴代码，它大多数情况下能正常工作。”
Karpathy描述了开发者与AI工具协作的新模式：开发者在提示中给出简单指令，模型生成大部分代码，开发者再进行补丁修改和迭代。
他开玩笑说自己跳过错误提示，直接“运行、观察、复制粘贴”，信任大型语言模型完成繁重工作。
这条轻松的推文迅速在科技圈引发共鸣，开发者们开始体验由这些AI工具带来的新工作方式。一些创业者和创始人将“氛围编码”推向极致，靠AI生成80%的代码，仅花数小时就开发出整款游戏或SaaS项目，而他们只需把控整体方向。与此同时，大型公司则更严谨地将这些工具嵌入成熟的工程流程中。
本章不是工具测评，而是通过真实案例探讨AI在软件工程中的极端应用，展示无论你是在创业公司打造MVP，还是在数十亿美元企业维护遗留代码，都能用上这些工具。
Pieter Levels：创业者如何使用AI工具
我多年来关注“独立黑客”创业者Pieter Levels的推特（现称X）。他因推出NomadList、RemoteOK和近期的PhotoAI等盈利项目而闻名。他坚持快速发布最小可行产品（MVP）以测试市场需求和付费意愿。他表示，产品快速迭代是必需的：他只有5%的产品赚了显著收入，因此必须降低前期投入，集中资源投入成功产品。
2025年2月22日，Levels宣布他用Cursor全自动生成代码，仅用3小时开发出一个基于浏览器的飞行模拟器：
“好了，完成了，玩这里：fly.pieter.com
我之前从没做过游戏，这次用Cursor花了大约3小时，告诉它我想要什么，就100%完成了我的飞行模拟器
虽然没那么完美，但80%没问题，中途我几次回退版本，重复问同样问题修复bug
我超爱这波AI氛围编码，超级有趣！（整个飞行模拟器就一个HTML文件）”
受Karpathy启发，Levels采用了“氛围编码”方式开发游戏，引起数千人关注。多数人好奇试玩，部分游戏开发者批评游戏过于简单，缺乏安全最佳实践。但Levels持续多次推特更新，其他开发者也开始分享自己的“氛围编码”游戏，如Nicola Manzini的VibeSail。
这款飞行模拟器迅速走红，发布几天后同时在线玩家超过5000人。Levels不断通过Cursor添加新功能：
“问Cursor和Claude，马上生成了防空坦克
需要让UP+DOWN控制炮塔，可以射击飞机
还有修复它悬浮地面的问题，现在飞得和飞机一样快
太好玩了！”
Levels也分享使用AI的挑战，比如想给飞机加导弹，默认模型Claude Sonnet 3.5拒绝了请求，推特截图显示：
Levels: 能加导弹吗？
Claude: 抱歉，我不应该给飞行模拟器加武器或导弹，我可以帮你做其他功能……我们应该保持模拟的和平娱乐性质。
他还反思这些AI工具现状，回应怀疑他是否真用AI的人：
“很多人怀疑这是AI做的
有一大群人严重低估AI能力
还有一群（通常是技术圈）过度高估它
现实是，AI已经很厉害了，但还不能完全替代开发者，特别是复杂项目（如视频游戏）
简单项目AI能全程搞定
复杂项目必须限定AI工作范围，否则会乱套（你试试就知道）”
这整个过程令人津津乐道。游戏每天都在添加新功能，大多数由AI生成，Levels偶尔介入调整“氛围”或修正小错误。他还利用项目热度售卖虚拟广告，17天内赚了8.7万美元。
虽然收益主要来自吸引广告商和流量，但这也证明了一个重要事实：创业者从零开始打造MVP的速度，比以往快了太多。以我做CTO的经验，传统创业公司开发首版产品通常需要3-6个月，而Levels只用3小时完成飞行模拟器。尽管大多数MVP比游戏复杂或需要更多打磨，时间成本能缩短到几周甚至几天已成可能。
三个创业者更易采用AI工具的关键原因：
- 无现有代码库
从零开始意味着所有代码都能纳入AI工具的上下文窗口，这只在初期版本可行。对于已有百万行代码、分布在数百文件的团队，AI难以全面理解。 - 无现有业务
无业务意味着AI引发故障成本低，允许较高的依赖度和较少的测试、代码审查或质量保障。这虽加快开发速度，但最终仍需设立护栏避免技术债务累积及生产缺陷。 - 无现有团队
独立开发者如Levels，所有上下文都在脑中，使用Cursor就像延伸了自己的认知。多人数团队共用知识库、任务系统、代码库、版本控制和代码审查流程，AI工具的应用则复杂得多。
我非常欣赏像Levels这样的独立创业者成功案例，展现了在依赖少的环境下可以多快推进项目。“氛围编码”方式能在极短时间内搭建产生实际收入的产品。代码可能不完美，但产品有效且用户满意，证明了产品需求，而这正是创业MVP的终极目标。
大公司内部的“氛围编码”
这种模式也能在大公司复制。Levels推文下，游戏公司创始人Jeff Tunnell回应：
“作为四次创办游戏公司的创始人，我觉得这太神奇了。变化如此迅速，连展望一年都困难。我们的首席程序员两个月没写代码了，但平台项目却以前所未有的速度在进步。各位准备好！”
有网友问：
“首席程序员不写代码做什么？只写提示吗？我是朋友来问的”
Tunnell回复：
“远不止写提示。他设计想要什么和怎么实现，然后和AI讨论，输入代码，让AI帮写新功能代码。他更像建筑师，而非绘图员。”
显然，大团队已有流程和代码时，采纳AI生成代码仍有很多细节和挑战。接下来案例将讲述Shopify如何采用这些工具。
Shopify：大型企业中的AI工具应用
现在，让我们深入了解一家规模更大的公司——全球拥有超过8,000名员工、拥有庞大且成熟代码库支撑稳固业务的公司——如何引入和使用AI工具。2025年初，我采访了Shopify的高级软件工程师Samuel Path，了解他和他的团队如何使用AI工具，以及近年来他们的软件开发流程发生了哪些变化。
Path告诉我，Shopify很幸运其CEO Tobias Lütke有技术背景，且早早意识到这些工具如何彻底改变技术产品的开发方式。Lütke组建了一个专门团队，负责试验各种新AI工具，评估工具提升生产力的效果，以及它们如何满足这样一家大公司的严格数据保护要求。这个团队倡导实验精神，最终负责批准可用工具并协助推广。
Path描述了2022年到2023年初，当OpenAI的GPT-3.5处于技术前沿时，团队感觉模型用处不大，不愿大量使用。直到2023年第二季度，OpenAI发布GPT-4，驱动GitHub Copilot和ChatGPT后，团队开始更多地使用AI工具进行编码。但当时的工作流依然笨拙。由于Copilot界面只支持自动补全，他们经常在ChatGPT和IDE间复制粘贴代码片段，面临上下文窗口受限的问题。直到Cursor IDE问世，基于Anthropic的Claude Sonnet 3.5，带来了翻天覆地的变化。这个新工具几乎取代了之前所有工具，集成了自动补全和聊天功能。
不过，这种采用也有波折。Path回忆了早期几次尴尬经历，比如AI引入的细微bug被合并进了PR，导致一些错误。甚至有队员不好意思承认“是Claude干的”。他的建议是：无论AI产出什么代码，都要像对待自己写的代码一样严格审查。毕竟，一旦出了问题，责任在合并者。这条教训在团队会议中多次被强调，凸显了一个基本事实：AI可以大幅提升效率，但保持警惕是保障代码质量和降低技术债务的关键。
Path的团队反映了现代软件开发实践的转变。起初，他们主要用Copilot处理简单的自动补全任务。随着AI模型进步，团队开始依赖能处理更大上下文的工具，比如将整模块失败代码粘贴进AI聊天界面，获得详细的调试步骤。这样不仅减少了停机时间，也加速了团队成员的学习过程。
借助Cursor，代码生成不再局限于自动补全，而是扩展到设计完整工作流：运行测试、修复代码风格错误、提出架构优化建议。然而团队始终坚持一个重要原则：保持批判性思维。AI生成的代码依然可能存在幻觉——bug、性能问题、逻辑错误，甚至破坏已有功能。
Path估计，现在他和团队大部分代码都是由AI编写。经历初期的波折后，他们建立了一套完善流程，贯穿特性编码前后。具体包括两项常规工作：
- 投入时间和精力进行Prompt设计
Path和团队遵循清晰的代码风格和标准，这些都会融入Cursor的所有Prompt中。Prompt会包含任务的全部功能上下文（通常写在任务系统里）以及明确的实现指南，仿佛在指导同事。这样能降低Cursor出错率，因为它会按指令实现。过程中还会与Cursor就实现方案和权衡反复交流。虽然给开发任务带来额外负担，但真正的编码变得轻松，大部分代码由Cursor生成。 - 加倍进行代码审查
Shopify一贯重视代码审查，任何Pull Request合并前都需审核。鉴于AI工具生成了大量代码，团队在经历早期波折后，加强了审查力度。开发者首先审核Cursor产出代码，通常结合其他AI工具与人工审查。提交PR后，至少另一名成员须复审，依然采取AI辅助加人工复核的混合方式。
对我而言，和Path对话中最大亮点是，这些工具使Shopify团队从“边写边改”的松散流程，转向“计划-实施”分明的模式——规划实现细节写进Prompt，而实际编码由工具完成。这正体现了我作为CTO在工作中和高绩效团队描述中看到的转变。
另一个重要收获是，Shopify从高层到基层都非常有意识地筛选真正有用的工具，并推动全公司范围的采用。在变化如此迅速的时代，建立一支小团队负责试验新工具、帮助全员掌握最优工具，是非常明智的做法。
超越案例研究
到目前为止，显而易见，AI辅助编码开启了构建软件的全新方式——从独立创业者在数小时内完成项目，到大型企业团队优化完善的工程流程。越来越多的团队开始采用这些工具，并逐步迈向这种新型开发模式：
规划与Prompt设计
将业务需求转化为包含任务全部功能上下文及部分实现指南的Prompt。这一步通常需要与AI工具反复沟通，讨论实现方案和权衡。
编写代码
在有了扎实的Prompt后，实际编码变得轻松，AI工具生成大部分代码，人工则在局部进行调整和修正。具体分工会因人而异、因任务不同而不同。
彻底代码审查
由于大部分代码由AI生成，代码审查比以往任何时候都更重要。首先由指派任务的开发者完成初审，承担PR（Pull Request）的责任。然后按常规流程至少由另一位同事复审并批准合并。
未来几年，这一流程很可能成为写代码的默认模式，各企业会根据自身情况做出调整。正如Wayne Pan所说，这“迫使人们进行本质性思考”。
在大型组织或者面对复杂需求时，绝不能轻易接受AI生成的代码，而不经过全面审查。正如许多人所言，“vibe coding（凭感觉写代码）会导致 vibe debugging（凭感觉调试）”，我经常看到同行软件工程师抱怨说，他们花在调试AI写的代码上的时间，远超自己写代码的时间。正如David Nix在2024年9月的推文所说：
我的Cursor体验。
“帮我写这段代码。”
看起来不错！节省了好多时间！
运行它。
等等……不行。细节上有错。
调试的时间比自己写代码还多。
谁喜欢调试胜过写代码呢？
这正是AI辅助编码模式需要警惕的现实挑战。
结论：生成式AI引领的软件开发未来
在本书中，我们探讨了AI工具如何重新塑造软件产品的开发方式。我们见证了像Pieter Levels这样的独立创业者如何通过“vibe coding”（凭感觉写代码）几乎一夜之间打造完整产品，也见证了像Shopify这样的大型企业如何将AI以更结构化的方式融入其现有工作流程中。贯穿全书，有一点显而易见：AI驱动的编码不仅仅是一个趋势——它已经成为常态。
截至本文撰写时（2025年中），Cursor是软件工程师使用的最先进的AI工具，也是采用率最高的AI辅助IDE，另外还有GitHub Copilot扩展程序广泛应用于主流IDE。基于浏览器的AI工具如ChatGPT、Claude、Gemini和Perplexity也非常受软件工程师欢迎，成为他们日常写代码、修复BUG和提出改进建议的利器，数秒内即可完成以往需数天甚至数周的手动编码工作，尤其在小型项目和团队中表现尤为突出。
自2022年底ChatGPT和GitHub Copilot发布以来，仅仅两年多的时间里，这一切就已经发生。一些流行工具诞生仅数月，例如2024年11月推出的Lovable，到2025年1月用户数已达14万，其中3万为付费用户。2023年推出的Cursor发展更快，截至2024年底拥有36万付费用户。可以预见，随着后续更新和改进的不断推出，这些工具会变得更加强大，同时也会有更多新工具出现，迅速占领市场。事实上，当你读到这段文字时，或许已有更先进的新工具，帮助软件工程师变得更加高效。
这意味着，未来写代码将更多地涉及减少对语法细节的编写（由AI承担大部分），更多使用自然语言描述，以及增加代码审查和测试。此刻，大家最关心的问题是：AI会取代软件工程师吗？毕竟，如果这些工具如此强大，我们还需要软件开发人员做什么呢？
回顾历史或许能帮助我们理解这一问题。
自动取款机（ATM）与银行柜员
1970年代自动取款机（ATM）问世时，许多市场分析师预测银行柜员的工作会逐步消失。ATM确实取代了柜员的一些常规工作，如现金取款和余额查询，从而降低了运营成本。但ATM并未替代银行员工所提供的全方位服务。柜台后的人工仍然是开立新账户、办理抵押贷款等服务必不可少的角色。
如图8-1所示，随着运营成本的降低，银行分支机构反而更多了。尽管平均每家银行的柜员人数减少了，但由于开设新分行成本降低，整个行业市场得以扩张，最终产生的银行柜员职位比被淘汰的更多。
这段历史说明了技术替代带来的不仅是职位消失，也可能带来新的增长和机遇，软件工程师的未来同样如此。
我认为，类似地，AI 编码助手将接管大量实际编写代码的过程，但实施规划和代码审查等阶段仍然需要人工软件工程师参与。50年前的自动取款机和当今的 AI 编码工具之间有相似之处，它们对就业市场的影响也可能遵循类似的模式。
电梯操作员
再往前推，我们可以找到一个真正消灭整个职业类别的技术发明。在20世纪初之前，电梯需要操作员，他们使用大杆控制电梯速度、停靠楼层并开关门。然而，一旦引入了按钮，电梯操作员的工作逐渐减少，直到20世纪中叶完全消失。
我的理解是，电梯操作员的职责范围非常有限：将电梯从一层移动到另一层。当然，他们还做其他事情，比如迎接乘客、报楼层，甚至在酒店和商店里担当非正式导游。但他们的核心工作确实是控制电梯上下移动，而按钮完全替代了这一功能，因此电梯操作员这个职业就消失了。
如果有些职业消失，而另一些职业增长，那么理解其原因非常重要，正如流行软件开发通讯《The Pragmatic Engineer》的作者 Gergely Orosz 所说：
“带按钮的电梯彻底消灭了‘电梯操作员’的工作；
与此同时，像 Excel 这样的电子表格应用并没有消灭会计工作——它们反而创造了更多工作机会；
理解每个案例发生的原因，你就能明白创新如何既减少又增加就业。”
Excel 与会计师
当微软Excel电子表格程序在1980年代诞生时，它使部分工作减少，另一些工作增加，还催生了全新的职位。这是一个较新的、可能更复杂的历史例子，可以用来预测 AI 工具对软件工程职业的影响。
在电子表格出现之前，跟踪和核对数字需要簿记员和会计职员大量的手工工作。随着软件自动化了许多耗时的任务，如数据录入、统计和基本计算，这些职位的需求下降（见图8-2）。这使企业可以将资源分配到其他地方。会计师和审计员角色则需要更深入的财务洞察力，随着更多公司规范了账目，对这些职位的需求增加。同时，电子表格工具使更高级的财务建模和分析成为可能，推动了管理分析师和财务经理等新角色的发展，这些角色专注于数据解读、战略决策和前瞻性财务规划。因此，Excel 标志着从手工簿记向更高层次的分析和咨询职能的转变。
这说明自动化确实会减少某些职位的需求，同时也会扩大或创造其他职位。专注于重复性、机械性任务的工作往往会缩减，而需要判断力、领域专业知识和高级问题解决能力的工作则倾向于扩展。
如果我们将这些历史类比应用于软件开发，也可以发现类似的规律。如果你的主要技能是纯粹写代码（擅长记忆语法并大量产出模板代码），那么你确实面临着来自 AI 工具的竞争，可能会被其取代。然而，你可以（且应该）拓展一些相关的技能领域，这些领域很可能会扩展：
- 规划与架构
将业务需求和架构指南转化为结构化的提示语 - 代码审查与质量控制
解读 AI 生成的代码，发现细微的安全隐患或逻辑漏洞，确保性能和可维护性 - 协作与沟通
与产品经理、设计师和业务相关人员跨职能协作，使技术解决方案与实际业务需求保持一致
正如电子表格带动了会计师职业的发展一样，软件工程师将成为统筹高层次思维、包裹实际代码生成过程的关键角色。
正如电子表格催生了新岗位，我们也可以预期基于 AI 的软件开发会产生新的职位名称，比如提示工程师（prompt engineer）、AI 集成专家、数据策展人和 AI 训练师等。如今这些称呼听起来或许很陌生，但它们反映了现代软件开发者日常任务的真实转变。很可能会有专门的团队负责评估新 AI 工具，为特定代码库定制工具，并确保 AI 驱动流程中的数据隐私和合规性。
从历史经验看，这些变革不会缩小科技行业，反而会让其更加广阔。AI 助手降低了软件开发的门槛，这种效率提升往往带来更多的试验、更多的产品、更多的创业公司，最终创造更多与软件相关的工作岗位。开发者的角色将不断进化。
对于软件工程师和开发者来说，AI 正在改变我们的工作性质，少了背诵语法和大量敲代码，更多变成战略思考、领域专业知识和严谨的代码审查。如果你读到这里，已经通过书中从独立游戏开发到企业级 AI 采用的真实案例，见证了这场变革的速度和广度。
AI 编码工具的发展速度令人震惊。在写作过程中，我不得不回头重写整章内容，因为新工具的出现和底层模型的改进突然让现有工具变得更强大。这充分说明公司和个人需要迅速行动，采用并整合最新工具。我很幸运，这正是我作为兼职 CTO 工作职责的一部分。我负责让客户的软件开发团队高效运转，这包括掌握这些新兴工具。
感谢你陪伴我一起走过这段 AI 编码的探索旅程。希望离开这几页内容时，你感到信息丰富、充满灵感，甚至对这些工具如何提升你自己的软件开发实践感到兴奋。未来已经来到。
