超越氛围编码：与 Addy Osmani 一起

氛围编码（Vibe Coding）与人工智能辅助工程之间存在关键区别，这一点至关重要，因为不应贬低工程学科的价值。在利用这些新兴工具时，保持批判性思维和工程纪律是构建健壮、可投入生产的软件的基础。个人实践表明，规范驱动开发，即拥有清晰的构建计划，是有效使用大型语言模型的先决条件，并且对测试的开放态度能够有效降低使用LLM带来的风险。

氛围编码的本质在于完全沉浸于AI的创造性流程中，主要侧重于高层次的提示和快速的迭代实验，常常忽略代码本身的细节。这种方法非常适合原型制作、最小可行产品（MVP）的构建，以及快速探索想法的形状，但它倾向于将速度和探索置于正确性与可维护性等生产级标准之上。相比之下，AI辅助工程则将AI视为强大的协作者，它贯穿整个软件开发生命周期，协助处理样板代码、调试和部署，但核心在于人类工程师始终牢牢掌握控制权。

我们不希望贬低工程学的纪律性，并给行业新人带来不完整的关于构建健壮、可投入生产的软件所需的认识。

在AI辅助工程模型中，工程师对架构负有最终责任，必须审查模型生成的大部分内容，并理解其工作原理。虽然AI可以提高速度，但这绝不意味着可以推卸对最终质量的责任。此外，工程师的专业知识水平越高，使用LLM时获得的结果质量就越好，这对于初级工程师尤为重要，他们需要坚持生产质量编程的最佳实践，例如只提交自己能够完全解释的代码。

个人实践中，重点转向了规范驱动开发，即在开始构建之前制定非常明确的计划。尽管如此，在个人工具或一次性项目上，氛围编码仍然有其用武之地。如今，通过在拉取请求（PR）或聊天中展示一个可运行的原型，工程师可以用更高质量的方式来分享愿景，这使得氛围编码在快速传达想法方面变得非常强大。

氛围编码正在经历一个高光时刻，只需在提示中描述一个应用，即可立即获得运行中的结果，感觉如同魔法。然而，这种方法无法涵盖机构知识和积累的上下文。真实的产品开发依赖于历史记录、客户请求和团队路线图等上下文。像Linear这样的工具中的线性智能体则能深入了解开发系统中的实际工作环境，利用团队已有的上下文来起草PR或构建功能，实现更具意图性的AI驱动开发。

描述一个应用的需求，然后，您就得到了一个运行中的东西。感觉就像魔法一样。

一旦对组件或视图的愿景清晰化后，就不应直接将氛围编码的原型投入生产。此时必须明确定义实际需求和期望，以获得LLM的更高质量输出。否则，如果完全依赖“氛围”，就等于将架构和具体实现细节的责任都推给了AI，这对于生产级产品工程来说是远远不够的。

在像谷歌这样的大公司，长期且久经考验的软件工程方法论并未消失，对质量和尽职调查的关注依然存在。有趣的是，许多经验教训与初创公司观察到的趋势相似，例如掌握提示工程（Prompt Engineering）和上下文工程（Context Engineering）的重要性，以优化上下文窗口，确保LLM获得特定项目的详细信息。

团队投入大量时间思考如何构造正确的“咒语”以获得最佳LLM输出，并优化上下文窗口，纳入项目特有的描述、文件和示例。一个重要的自我反思是：在尝试自己解决问题之前，先思考如果将问题交给AI，它会如何处理，这有助于了解当前AI能力的边界。

维护人工监督的重要性一直是最大的经验教训之一。

持续的人工监督至关重要，因为过度依赖AI可能导致代码审查成为瓶颈。如果AI既编写代码又进行审查，那么代码的最终安全性将难以保证。研究表明，当AI加速代码交付速度时，人类审查环节的压力会显著增加，这促使团队必须演进工作流程来应对这种变化。

个人偏爱的工具包括VS Code中的Klein，以及Cursor和Co-pilot。关键在于深入研究工具在后台生成的思考过程和决策日志，即使这些过程发生得很快。只有在完全理解了AI生成的代码的决策逻辑和具体实现后，才应将其纳入拉取请求，因为未来维护和调试的责任仍在工程师本人。

如果工程师无法理解AI生成的代码，当出现问题时，调试将如同置身丛林之中，无法有效解决根本原因。这正是区分专业工程师与仅会提示的用户的关键所在。专业人士不仅能利用AI，还能在模型失败时卷起袖子进行手动调试，并能清晰地向他人解释系统的运作方式。

如果只会提示和提示，任何人都可以做到。但不是每个人都会花精力去理解其工作原理并能卷起袖子在模型失败时进行修复。

随着多智能体协作和异步编程代理的兴起，工程师需要警惕技术债务的累积。在抽象理论层面，让虚拟团队并行工作听起来很棒，但缺乏人工审查必然会导致技术债务的复合问题。因此，将任务分解成小的、可验证的块，类似于规划冲刺或编写伪代码，是管理复杂性、减少上下文丢失和累积错误的有效方法。

所谓的“70%问题”指出，大型语言模型（LLM）可以非常迅速地生成一个工作应用的大约70%的代码，但它们在处理最后30%的工作时会遇到困难。这最后的30%通常被称为“最后一英里”，它包含了许多模式，如“两步后退模式”，即模型可能突然重写UI或功能，或者出现隐藏的可维护性成本和安全漏洞，因为责任被委托给了LLM。

一个通过氛围编码产生的概念验证（PoC）或许适用于MVP阶段，但如果要在团队协作和面对真实用户群的代码库中落地，则很可能需要重写以满足生产质量要求。这凸显了安全性和质量方面需要人类持续参与的必要性。经验更丰富的工程师能更容易地完成最后30%的工作，而经验不足的工程师可能会陷入不断重新提示的循环，缺乏调试和理解问题的技能。

这强调了保持批判性思维和解决问题的能力的重要性。虽然现代工具能让几乎任何人生成看似有效的高级提示结果，但这种结果在生产环境中是不可信赖的。工程师必须承担起维护自己代码的责任，而不是完全依赖AI来解决后续出现的所有问题。

AI工具提供了惊人的速度，但缺乏精确性只会导致交付更多错误的东西。为了确保构建的功能确实有效，需要精确的度量和数据驱动的决策，例如使用Static这样的平台来匹配AI加速的速度。这种精确性体现在将功能分批推送给小部分用户，以实时监控关键指标的变化。

鉴于模型具有有限的上下文窗口，工程师应采纳项目经理的心态，将任务分解成小的、可验证的块。一次性向LLM抛出所有需求往往效果不佳。这种分解与传统软件工程中的冲刺规划相似，有助于减少上下文丢失和错误累积的风险。同时，模块化、可测试的代码和强制执行的代码审查等经典最佳实践仍然适用。

拥有对自己的工作任务有掌控感并且非常自信的工程师，在AI使用中看到了更多的成功。

工程师应保持控制感。如果完全依赖AI，当上下文窗口填满或模型表现不佳时，工程师将陷入困境。因此，保持对系统工作原理的理解，并对AI的输出进行细致的阅读和学习，是确保持续进步和专业性的关键所在。

AI不过是工具带中的又一件工具，它标志着工程和开发者体验又向前迈进了一步。回顾历史，从模板到命令行接口（CLI）的脚手架工具，每一步都简化了解决方案的启动过程。AI正在将这一趋势推向新的高度，使我们能够更快地启动一个可用的解决方案，但它仍然要求用户真正理解并对交付给用户的代码负责。

理解LLM的训练数据很可能来源于GitHub上许可宽松的代码，这些代码的模式往往反映了最低公分母的解决方案，可能并非最安全或性能最优。因此，设定较低的期望值是必要的。AI可能比手动复制粘贴代码片段要好，但仍需要一定程度的手动工作和尽职调查才能达到最佳输出。

这与多年前开发者在Stack Overflow上复制粘贴高分答案的做法类似。如果不对代码进行深入审查，就可能引入不安全或有缺陷的逻辑。如果工程师选择自己实现所有模式，那么他们就承担了维护这些模式、修复安全漏洞和边缘案例的全部责任，而不是依赖集中修复的第三方库。

最令人兴奋的演变之一是异步后台编码智能体（Autonomous Agents）。这些系统有潜力委托工程师待办列表中的部分任务，并在后台异步实现它们，前提是实现过程是易于人类验证的。目前，智能体在更新测试或进行依赖库迁移等较小、更明确的任务上表现良好。

对于工程师而言，如何作为“管弦乐队指挥”来管理这些并行智能体仍是未知数。由于人类注意力有限，如果工程师需要对所有AI生成的工作进行严格的尽职审查，那么同时能处理的任务数量是有限的。这回归到了多任务处理的最佳实践，即必须有重点地投入精力进行代码审查。

另一个有趣的领域是“氛围设计”（Vibe Designing），它正在演进产品开发的一部分，例如Figma设计稿可以被工具（如Cursor）直接转化为功能原型。Shopify团队的实践表明，设计师使用开发工具来快速创建可交互的原型，这极大地提升了与工程师协作的效率，将静态设计转化为更接近代码的形态。

随着AI的普及，产品经理（PM）可能需要将更多时间投入到问题框架构建、指标定义以及为智能体制定策略上。工程经理（EM）则需要专注于评估（Evals）和安全审查，以确保团队能够自信地与AI协作。尽管结果问责制不会改变，但产品工程中的“品味”将成为区分专业人士的关键要素。

AI提高了行业的基准线（Floor），同时也提升了上限（Ceiling）。初级工程师可以更快上手，但那些能够编写规范、分解工作、理解系统架构并有效进行审查的资深工程师将变得更具价值。他们能够处理AI难以解决的“最后30%”的工作，这实际上是一种杠杆作用，而非简单的忙碌工作。

可能会出现“前沿部署工程师”（Forward Deployed Engineers）等新角色，他们更深入地嵌入客户需求，利用AI快速构建功能，这模糊了开发人员、PM和设计师之间的界限。教育体系也需要相应演变，开始教授提示工程和上下文工程的最佳实践，同时确保人们继续以系统设计和工程思维进行思考。

在使用AI工具时，存在一种倾向是过度信任，导致批判性减弱，倾向于接受所有建议。这种“LGTM综合症”在代码审查中尤其危险。为了对抗这种趋势，工程师应该有意识地进行“反AI日”，即故意不依赖LLM来解决某些问题，从而不断测试和重申自身的批判性思维和问题解决能力。

对于新加入代码库的工程师而言，首要任务应该是利用LLM作为学习工具，深入理解代码库的结构、工作原理和组件间的连接方式，而不是立即提示新的功能。这种学习模式可以加速新成员的入职过程，因为AI可以充当24/7的“可信赖伙伴”，解答疑问，而无需过度打扰资深同事。

领导者应展现出终身学习的态度，并鼓励团队实验和分享最佳实践。通过定期的内部通讯分享最新的AI工程进展，领导者可以帮助团队筛选信息，专注于真正重要的领域。这种开放性为团队提供了尝试新工具和失败的许可，最终增强了他们对哪些方法有效、哪些无效的信心。

AI工具能够压缩工作量，这反过来可以凸显人类判断力的重要性——判断哪些想法值得推进，哪些应该忽略。企业团队不应因等待“企业友好版”工具而停滞不前；可以通过周末的侧边项目来尝试第三方工具和模型，以保持技能的敏锐度。

在快速问答环节中，Addy分享了他对几项关键技术的看法。他最喜欢的编程语言是JavaScript，原因在于它对全球开发者开放，无需看门人即可构建和发布Web应用。他推荐的工具之一是Bolt（源自Stack Blitz），它是一个氛围编码脚手架工具，近期加入了使用自定义智能体的能力，以减少设置摩擦。

在书籍推荐方面，他首先推荐了《软件工程师指南手册》（The Software Engineer Guidebook），认为它对软件工程师的职业路径和最佳实践进行了引人注目的阐述。此外，对于希望了解AI工程基础的读者，他强烈推荐Chip Huyen撰写的《AI工程》（AI Engineering），强调掌握这些基础概念对于在当前技术浪潮中保持竞争力至关重要。