# 从“氛围编码”到AI辅助工程：构建生产级软件的新框架

## 摘要

Google工程负责人Addy Osmani的《Beyond Vibe Coding》指南，聚焦纠正“Vibe Coding”误区，提出严谨的AI辅助工程框架，涵盖规划、上下文管理、提示词策略等方法论，助力开发者构建生产级软件。

你有没有过这样的经历：用AI生成代码时，一开始觉得进展飞快，好像很快就能完成项目，但到了后期却问题不断？修复一个bug反而冒出两个新的，代码维护起来一团糟，甚至还可能藏着安全漏洞？其实，这可能是陷入了“Vibe Coding”的陷阱。今天，我们就来聊聊Google工程负责人Addy Osmani在新书中提出的“AI辅助工程”框架，看看如何跳出误区，用AI构建真正靠谱的生产级软件。

## 从“氛围编码”到AI辅助工程：为什么要转变？

### 什么是“Vibe Coding”？

可能你听过Andrej Karpathy描述的一种开发愿景：“我只管看、说、跑代码，主要靠复制粘贴，只要‘感觉Vibe’对了就行。”这就是“Vibe Coding”——一种依赖高层级提示词、追求快速出原型、不太在意底层实现细节的开发方式。

这种方式听起来是不是很吸引人？不用深究代码逻辑，靠着AI生成和复制粘贴，就能快速看到成果。但为什么说它有问题呢？

### 躲不开的“70%陷阱”

Addy Osmani在书中指出，“Vibe Coding”最大的问题就是“70%陷阱”：它能让你极速完成70%的工作，但剩下的30%——也就是把代码变成能真正上线的生产级产品——如果没有扎实的工程功底，几乎寸步难行。

这30%的难题具体体现在哪里呢？

• “进二退二”模式：你有没有遇到过这种情况？好不容易修复了一个bug，测试的时候却发现又冒出两个新的？这很可能就是因为你没真正理解AI生成的代码逻辑，改代码的时候牵一发而动全身，越改越乱。
• 隐形成本高：“Vibe Coding”生成的代码，往往缺乏可维护性。可能过了一个月，连你自己都看不懂当时的代码逻辑了。更麻烦的是，还可能藏着安全漏洞，比如不小心把数据库凭证泄露出去；或者有性能瓶颈，用户一多系统就卡得不行。
• 边际效应递减：对于新手来说，AI可能像个“拐杖”，帮着入门；但对于资深工程师，如果还只是盲目接受AI生成的代码，就很难再提升了。必须从“拿来就用”变成“严谨审查”，才能真正发挥AI的价值。

所以，Addy认为，我们必须从“玩票性质的编码”转向“AI辅助工程”。简单说，就是既要用AI的创造力，又不能丢了传统工程的严谨性——比如规范、测试、审查这些“老规矩”。

## AI辅助开发的“工程学”：一套系统化的方法

知道了要转变方向，那具体该怎么做呢？Addy在书中提出了一整套系统化的方法，帮我们弥合AI生成代码和生产级标准之间的差距。

### A. “先规划，后编码”：最关键的范式转变

很多人用AI写代码，都是直接丢一句“帮我写个登录功能”，然后就等着AI输出代码。但这其实是错的。“先规划，后编码”才是正确的打开方式，也就是“Spec-Driven Development（基于规格的开发）”。

为什么要先规划？因为90%的情况下，AI一开始给的方案都太复杂了，提前规划能帮我们把它简化，少走弯路。具体怎么做呢？

• 写一份Mini-PRD / SPEC.md：在让AI写代码前，先让它生成一份架构计划或者小型产品需求文档。比如你要做一个购物车功能，先让AI写清楚这个功能需要实现哪些核心操作（加商品、删商品、算总价）、和哪些模块交互（用户系统、支付系统）、有什么边界条件（库存不足怎么办）。有了这份文档，后面写代码才不会跑偏。
• 用好AI工具的“计划模式”：现在很多AI工具，比如Claude Code、Gemini CLI，都有专门的计划功能。别直接让它们写代码，先让它们帮你梳理架构路径：第一步做什么，第二步做什么，用什么技术方案更合适。确认路径对了，再开始写代码。
• 纠错前置：规划阶段其实是在提前“排雷”。比如AI可能建议用一个很复杂的框架，但其实你的需求很简单，用原生代码就能搞定。这时候在规划阶段提出来，就能避免后面写了一大堆代码再返工。

### B. 上下文工程：比提示词工程更重要

你可能听过“提示词工程”，觉得写好提示词就能让AI生成好代码。但Addy说，现在已经是“上下文工程”的时代了。怎么理解呢？可以把AI模型当成CPU，把它的上下文窗口当成内存，我们要做的就是通过动态加载信息，让这个“内存”里装的都是有用的东西，这样AI才能输出更精准的结果。

具体怎么做好上下文工程？

• 动态组装信息：别再把所有代码一股脑儿粘贴给AI了。比如你现在要修复一个支付模块的bug，就只需要给AI相关的支付代码片段、支付API的文档、这次bug的错误堆栈信息，还有数据库里和支付相关的表结构。信息越聚焦，AI的输出就越靠谱。
• 消除“上下文腐烂”：如果和AI的对话很长，前面聊过的很多无关信息会一直留在上下文里，干扰AI的判断。这就像你的桌子上堆了一堆没用的东西，找东西自然就慢了。所以要定期总结对话，把旧的、无关的信息清理掉，让上下文始终保持“清爽”。
• 善用视觉上下文：如果是做前端开发，直接把设计图（比如Figma文件）或者浏览器截图传给AI，往往比用文字描述“这个按钮要在页面右上角，红色，圆角”效果好得多。毕竟“一图胜千言”，能少走很多样式调试的弯路。

### C. 提示词的进阶策略：让AI更懂你的需求

虽然上下文工程更重要，但提示词的技巧也不能忽视。这里有几个进阶策略，能让AI的输出更符合你的预期。

• 思维链提示：别让AI直接给代码，先让它说说思路。比如你让AI优化一段查询数据库的代码，可以说“请先分析这段代码的性能瓶颈在哪里，然后说说你打算怎么优化，第一步做什么，第二步做什么，最后再写优化后的代码”。这样你能看到AI的推理过程，如果思路错了，能及时纠正，不用等到代码写完才发现问题。
• 基于约束的提示：明确告诉AI“不能做什么”。比如“写一个图片处理功能，不允许使用外部库，必须兼容IE11浏览器”，或者“这段代码要运行在内存小于1G的设备上，不能有内存泄漏”。约束越明确，AI就越不容易跑偏。
• 角色扮演：给AI指定一个身份，让它从特定角度思考。比如“作为一名资深安全审计员，请审查这段用户登录代码的SQL注入风险”，或者“作为有10年经验的前端性能优化专家，帮我看看这个页面加载慢的原因”。身份越具体，AI给出的建议就越专业。

## 技术栈演进：未来的开发环境是什么样的？

Addy在书中还探讨了开发环境的未来——不再只是IDE里的插件，而是终端智能体（CLI Agent）和多智能体系统。听起来有点玄乎？其实很好理解。

### CLI编码智能体：终端里的“全能助手”

你可能用过IDE里的AI代码补全工具，但CLI编码智能体更强大。像Claude Code、Gemini CLI、Aider这些工具，它们直接在终端里运行，不只是帮你补全代码，还能自己执行复杂任务：比如帮你提交Git代码、运行测试用例、读写文件。

举个例子，你可以对CLI智能体说“帮我把上周的代码提交到Git，分支名叫feature/pay，提交信息写‘完善支付回调逻辑’”，它就能直接执行Git命令；或者说“运行所有单元测试，把失败的用例列出来，然后尝试修复第一个失败的”，它会先运行测试，再根据错误信息改代码。是不是很像有个助手在旁边帮你处理琐事？

### 多智能体编排：像“流水线”一样工作

如果说CLI智能体是“单打独斗”，那多智能体编排就是“团队协作”。怎么协作呢？

• 分工明确的架构：一个“规划智能体”先把任务拆解开，比如“开发用户管理模块”可以拆成“设计数据库表”“写API接口”“做前端页面”；然后把这些子任务分给不同的“编码智能体”去做；做完之后，“测试智能体”会自动跑测试，看看有没有bug；最后，“文档智能体”会更新README，把新功能的用法写清楚。
• 流水线作业：就像工厂里的流水线，每个环节都由AI智能体负责，前一个环节完成了，自动传给下一个环节。比如编码智能体写完代码，自动触发测试智能体运行测试，测试通过后，自动让文档智能体更新文档。
• 沙盒与回滚机制：既然AI智能体有自主性，万一它“暴走”了怎么办？比如测试智能体误删了代码，或者编码智能体写了有问题的逻辑。这时候就需要“沙盒环境”——让智能体在一个隔离的环境里工作，不会影响到正式代码；还要有“检查点”，定期保存工作状态，出问题了能一键回滚到之前的状态。

## 生产现实：别让AI“帮倒忙”，质量门禁很重要

用AI辅助开发确实能提高效率，但如果盲目信任AI，很可能“帮倒忙”。Addy强调，必须建立严格的质量门禁，确保代码能真正达到生产级标准。

### 像审查初级工程师一样审查AI代码

AI生成的代码，哪怕看起来再完美，也不能直接用。为什么？因为AI有时候会“一本正经地胡说八道”——比如生成的代码有语法错误，或者逻辑有漏洞，但它自己意识不到。所以，审查AI代码要像审查初级工程师写的代码一样认真：一行一行看逻辑，检查是否符合编码规范，有没有安全隐患。

### 测试驱动：让AI先写测试，再写代码

这是确保AI代码逻辑正确的好办法。具体怎么做呢？

• 第一步，让AI先写测试用例（这时候测试是“红”的，因为代码还没写，肯定通不过）。比如要写一个“计算两个数相加”的函数，先让AI写测试：输入1和2，预期输出3；输入0和-5，预期输出-5。
• 第二步，让AI写代码，目标是让这些测试用例通过（变成“绿”的）。
• 第三步，测试通过后，再让AI重构代码，让它更简洁、易读。

这样一来，代码是否正确，有测试用例把关，心里就有数了。

### 安全第一：AI爱“偷懒”，但安全不能省

AI生成代码有个特点：喜欢生成“能跑通”但“不安全”的代码。比如为了图方便，把数据库密码直接写在代码里（硬编码密钥），或者不验证用户输入，导致SQL注入风险。所以，必须专门做安全扫描，比如用工具检查有没有硬编码的敏感信息，有没有常见的安全漏洞。

## 未来的开发者：你需要具备哪些新技能？

Addy在书中清晰地指出：AI让软件开发的门槛降低了，但卓越工程的标准并没有降低。未来的开发者，需要从心态到技能都做出转变。

### 从“编码者”到“决策人”

以前可能觉得，写代码厉害就是“大神”——能默写各种语法，快速写出复杂逻辑。但未来不一样了，核心技能变成了：能不能给AI提供高质量的上下文（比如清晰的需求、相关的代码片段），能不能准确验证AI输出的代码是否正确，能不能在多个技术方案中做出正确的架构决策。

### 从“实现”到“意图”

以前开发可能纠结“怎么写”，比如“这个循环用for还是while”“这个功能用哪个库实现”。但有了AI之后，更重要的是精准描述“想要什么”——比如“我需要一个能处理10万用户同时在线的聊天功能，延迟不能超过1秒”，而不是纠结“用什么框架写”。AI可以帮你实现，但“想要什么”必须由你明确。

### 从“单兵作战”到“人机结对”

未来的开发，可能不是你一个人对着电脑写代码，而是你指挥一个AI智能体团队：让规划智能体拆解任务，让编码智能体写代码，让测试智能体找bug……你需要学会管理这些AI助手，让它们协作完成复杂的系统开发。

## 常见问题解答（FAQ）

### 问：“Vibe Coding”完全不能用吗？

答：也不是。对于快速做原型验证，比如验证一个想法是否可行，“Vibe Coding”可能很高效。但如果是开发需要上线的生产级软件，就必须转向AI辅助工程，因为后期的维护、安全、性能问题会让你付出更大代价。

### 问：上下文工程和提示词工程有什么区别？

答：提示词工程更侧重“怎么问AI”，而上下文工程更侧重“给AI什么信息”。上下文工程把AI看作需要“内存”的系统，通过动态加载相关信息（代码片段、文档等）来优化输出，比单纯优化提示词更有效。

### 问：多智能体编排听起来很复杂，小团队也能用吗？

答：可以从简单的分工开始。比如先用一个CLI智能体写代码，再用另一个AI工具（比如专门的测试工具）跑测试，手动把代码传给测试工具，这其实就是简化版的多智能体协作。随着工具越来越成熟，小团队也能逐步用上更自动化的编排。

### 问：未来开发者不需要懂底层技术了吗？

答：不是。虽然AI能帮我们写代码，但理解底层技术（比如数据库原理、网络协议）才能判断AI生成的代码是否合理，才能做出正确的架构决策。AI降低的是“写代码”的门槛，但“懂技术”的门槛并没有降低。

通过这套AI辅助工程框架，我们既能享受AI带来的效率提升，又能守住生产级软件的质量底线。说到底，AI是强大的工具，但最终决定软件质量的，还是开发者的工程素养和对细节的把控。从“氛围编码”到“AI辅助工程”，不仅是开发方式的转变，更是开发者思维方式的升级。