编者按：在 AI 技术席卷软件工程的今天，我们是否真的可以仅凭“氛围”和直觉，就构建出可靠、安全且可维护的生产级系统？

我们今天为大家带来的这篇文章，作者的核心观点是：“氛围编程（vibe coding）”与“AI 辅助的工程实践”存在本质区别，前者虽在创意激发和快速原型中具有价值，但绝不能替代结构化的工程方法。

文章通过多个维度深入探讨了这一观点：从 FAANG 团队的实际工作流程切入，指出真正的 AI 辅助的工程实践是在严格的设计、审查和测试框架内使用 AI 作为“效能倍增器”。继而以维恩图形象对比了“氛围编程者”、“竞技牛仔”和“困局囚徒”三类开发者原型，警示过度自由或过度约束都将阻碍可持续开发。最后还结合 CTO 调研和社区讨论，指出盲目依赖 AI 生成的代码可能导致安全漏洞、性能崩溃与可维护性灾难，并提出了“规范驱动开发”和“Agentic AI”等更负责任的工作流程建议。

作者 | Addy Osmani

编译 | 岳扬

氛围编程（vibe coding）并不等同于 AI 辅助的工程实践。近期一则 Reddit 帖子[1]描述了某 FAANG 团队如何使用 AI，由此引发了一场重要讨论：“氛围编程”与专业化的“AI 辅助的工程实践”。

虽然该帖子被包装成前者的范例，但它详细描述的流程 —— 包含技术设计文档、严格的代码审查和测试驱动开发 —— 在我看来恰恰是后者的一个清晰例证。将它们区分非常重要，因为将二者混为一谈既会贬低工程学科的专业性，也可能让新人误以为构建健壮的生产级软件无需严谨流程，这种认知极其危险。

氛围编程（vibe coding）能很好地推动开发进程、保持势头，但一旦缺乏结构化的工程方法，它在生产环境的严苛要求下就会不堪重负，最终崩溃。

需要明确的是：“氛围编程”是指完全沉浸于与 AI 合作协同的创造性流程（通过高层级的提示词），本质上不再过多关注代码本身的细节。这种方式不经深入审查就直接采纳 AI 提供的建议，并专注于快速、迭代式的实验。这使得它非常适合用于构建产品原型、最小可行产品（MVP），学习研究以及进行 Karpathy 所说的“周末练手项目”。这种方法（氛围编程）是开发者建立编程直觉、初学者降低编程学习难度的有效途径。它优先追求速度和探索性，而非专业应用所要求的正确性和可维护性。

在完全随性的氛围编程与稍加规划、遵循规范驱动开发、提供充分上下文等做法之间存在过渡的区间，而贯穿整个软件开发生命周期的“AI 辅助的工程实践”则属于另一维度。

与那篇帖子的观点相反，Reddit 帖子中描述的流程实际上是将 AI 系统化集成到成熟的软件开发生命周期的方法。这才是真正的“AI 辅助的工程实践” —— 人工智能在这里扮演的是强力协作伙伴的角色，而并非要取代基本的工程原则。在这种模式中，开发者将 AI 作为“效能倍增器”，用以处理诸如生成模板代码或编写初始测试用例等任务，但这些操作始终被约束在一个结构化的框架之内。最根本的区别在于人类工程师始终牢牢掌握控制权。他们负责系统架构设计，审查并理解 AI 生成的每一行代码，并确保最终产品具备安全性、可扩展性和可维护性。帖子中提到的开发速度提升 30%，是强化和优化了原有扎实流程的结果，而不是抛弃了这个流程。

对于工程师而言，将这种纪律严明的、使用 AI 增强的工作流称为“氛围编程”，是对其中所涉及技能和严谨性的错误描述。对于刚入行的新人来说，这会造成一种危险且错误的印象，让人以为不需要理解底层代码或工程基础，仅靠写提示词就能做出可用的产品。若想正确运用 AI 进行开发，请从扎实的工程设计开始，让所有产出物都经过严格的人工审查，并只将 AI 视为工程工具箱中一种无比强大的工具，而非取代工程所需专业知识和经验的魔法棒。

01 氛围编程者、竞技牛仔与困局中的囚徒

目前技术社区中各派的立场分裂：乐观主义者试“氛围编程”为革命，怀疑论者则认为这是换汤不换药的牛仔式编程（译者注：指的是一种无组织、无纪律、不受约束的软件开发方式。）。乐观主义者将“氛围编程”称为下一个抽象层 —— 这就像从汇编语言跃升到 Python 的变革。外部力量将不断推动其发展直至成熟。

务实派将其用于“技术探针”（用于快速验证），但事后必定施加规范约束。使用 AI 应如对待初级开发者：善用其助力，但绝不放任自流。怀疑论者则将其斥为营销话术 —— “若我能一眼识破是氛围编码的产物，这代码便不合格”。优秀软件的核心标准从未改变。社区中理性的声音认为：氛围编程（vibe coding）是激发创造力的“沙盒”，但要想实现规模化扩展，则必须依靠严谨的工程方法。

福雷斯特·布雷泽尔（Forrest Brazeal[2]）用一张有趣的维恩图，以“绳索”（比喻自由与约束）为隐喻，对比了 AI 辅助时代的三种工程师人格 —— “氛围编码者”、“竞技牛仔”和“困局中的囚徒”。每种原型都代表了一种极端的工作方式，而这些方式都难以产出生产级的软件。

02 开发工作中的自主权和自由度、相伴而生的技术风险与不同开发者如何看待这二者

在软件开发中，“绳索”这个比喻象征着开发者在构建软件时被授予（或自我赋予）的自由度和风险承受水平。

“竞技牛仔” 在极少的限制中如鱼得水，他们崇尚西部荒野式的编程风格，具有极高的风险承受力且极少接受监督。他们会欣然即兴地“套索”出新功能或修复方案（有时真就全靠肾上腺素驱动）。“困局中的囚徒” 则在严格的规则下运作，被僵化的约束、沉重的治理或对错误的恐惧所捆绑 —— 他们行动缓慢而谨慎，甚至几乎不动。而介于二者之间的，是现代 AI 赋能的开发者：“氛围编程者” 被给予的自由度刚好足以让他们产出不可靠、不安全、难以维护的代码。

他们通过自然语言的“氛围提示词”快速生成代码，并盲目信任输出结果，往往既没有充分理解也不测试其可靠性。

不同风格的开发者，用 AI 的方法和敢冒的风险也都不一样：

氛围编程者 —— 这类开发者以自由流动的对话方式与大语言模型（LLM）协作，他们用自然语言描述自己想要实现的功能，然后让 AI 来填充具体的实现代码。这种自由程度令人振奋 —— “只需告诉 AI 添加登录页或修复这个 bug”。其优势在于速度与创造力。氛围编程者更像指挥家而非手动编码者，他们关注创意胜过语法。他们的劣势是缺乏控制力。他们通常在没有安全保护的情况下运作：极少的代码审查、稀疏的测试、以及对 AI 输出的盲目信任。换言之，充足的自由却缺乏引导，最终可能导致代码库变得脆弱而晦涩。有工程师指出，不做代码审查的“氛围编程”就像电工把一堆电线胡乱塞进墙里，而不是进行规范布线[3]。刚开始可能能用，但墙体背后早已埋下无数隐患。
竞技牛仔 —— 经典的“牛仔程序员”在软件工程领域并非新事物，在 AI 时代这类人格依然存在（有时会被 AI 增强，有时则不会）。竞技牛仔是指那些以惊人速度、几乎无视流程就将代码推送到生产环境的开发者 —— 他们会在生产环境直接进行原型开发、凌晨两点热修复线上系统，通常为了追求速度而甘冒风险。他们（竞技牛仔）具备高风险承受能力（与氛围编码者相同），但相比 AI 更依赖自身的直觉和经验。如果说氛围编码者是被 AI 的“声音”引导，那么竞技牛仔则是追随自己的直觉。他们确实会被一些绳索约束（就像牛仔竞技也发生在有围栏的场地内），但往往获得的自由空间刚好足以让他们险些自缢。这两种风格的交叉点显而易见：当氛围编码者开始将 AI 生成的代码直接部署到生产环境，试图大显身手时，他们就变成了竞技牛仔。其结果可能是惊人的成功……也可能是灾难性的失败。
困局中的囚徒 —— 在另一个极端，存在着被流程、官僚主义或自我强加的过度谨慎所束缚，以至于几乎无法动弹的工程师。这些“囚徒”可能工作在受到严格监管的行业或遗留系统中，在那里每一行代码的修改都像是一场艰苦的战斗。他们（囚徒型开发者）几乎没有任何自由度 —— 他们受到严格的限制、强制性的审批流程，或许还对 AI 辅助持怀疑态度甚至明令禁止。这种思维模式虽然确保了安全性和可预测性，但也扼杀了创新。囚徒型开发者可能只能在场边旁观 AI 革命，由于组织规则或对未知的恐惧而无法参与其中。他们不会因为“绳索”而自缚手脚（因为他们从未被给予过任何松动的余地），但他们也可能无法交付任何新颖的或令人兴奋的成果。有趣的是，“困局囚徒”和“氛围编程者”有一个共同特质：都被无形之声所支配。对囚徒而言，这些声音是流程清单、工单系统或官僚政策 —— 它们指挥着每一个动作。而对氛围编程者来说，这个声音则是 AI 的建议。两者实际上都未能真正掌控全局。

现实中的工程师并非二元标签 —— 同一个人可能因项目与压力差异，同时具备三种人格的特质。该维恩图的精髓在于：三种极端路径都终将失效，过度自由与过度约束都会阻碍可持续的工程实践。

关键在于找到平衡点 —— 给予开发者足以创新的自由度，但又不至于让其（或代码库）被缺陷与技术债扼住咽喉。本报告后续将探讨为何放任的“氛围编程”会引发行业领袖与网络社区的尖锐批评，以及团队如何更负责任地驾驭 AI 辅助开发。

社区共识很明确：氛围编程能够加速探索进程，却埋下在生产环境引爆的隐患。近期的社区讨论也凸显出以下这些重复出现的问题：

安全漏洞[4]：将高度敏感的 API 密钥直接以明文形式硬编码在源代码里；对用户输入的数据没有进行任何验证、过滤或转义处理，就直接使用或存入数据库；实现了脆弱、不健全、容易被绕过的身份验证或授权检查逻辑
调试工作极其脆弱[3]：当即使微小的改动也会引发连锁故障时，非专业工程师（或缺乏工程背景的人）就会陷入困境、寸步难行。

03 你难道打算仅凭这种“氛围编程”，来构建最终要上线运行的生产级软件吗？

整个软件行业的资深工程领导者们正发出明确警告：AI 辅助的“氛围编程”在生产代码库中引发问题的速度可能远快于其解决问题的速度。Canva 首席技术官 Brendan Humphreys[4] 直言不讳地表达了这一观点：

“不，你不可能靠氛围编程来构建最终要上线运行的生产级软件 —— 除非你放弃对质量、安全性、安全防护与长期可维护性的要求。”

这些工具需要由资深工程师严密监督，尤其在处理关键任务代码时。换言之， AI 能够加速开发进程，但永远无法替代软件工程所需的严格规范。一旦跳过这些规范，往往会导致系统脆弱不堪和大量隐性问题的堆积。

最新的调查结果印证了这些警告。在 Final Round AI[5] 于 2025 年 8 月的调研中，18 位 CTO 被问及氛围编程时，16 位报告称遭遇过由 AI 生成代码直接导致的生产事故。这些技术领导者没有炒作趋势的动机 —— 他们的观点来自实战中的惨痛教训。正如某位总结者所言[4]：

“AI 曾承诺让我们都成为拥有 10 倍效能的开发者，现实却把新人变成提示词工程师，让资深开发者沦为清理 AI 烂摊子的代码保洁员。”

当交付的功能漏洞百出以至于需要凌晨两点紧急抢修时，所谓快速交付的能力就失去了意义。

他们谈论的是哪些类型的故障？CTO 们列举了性能崩溃、安全漏洞和可维护性噩梦等案例：

某位 CTO 讲述的性能灾难：他目睹 AI 生成的数据库查询在测试中完美运行，却在生产环境中拖垮系统。该查询语法正确（无显性错误），开发者便认为一切正常。但它在规模化场景下效率极低 —— 这本该由经验丰富的工程师或规范的代码审查发现。“它适用于小数据集，但一旦遭遇真实流量，系统就陷入瘫痪。”团队耗费了一周的时间来调试这个应用卡顿问题 —— 若代码经过周密设计，本可避免这种浪费。这揭示了一个关键风险：除非你明确引导 AI，否则它无法理解你的系统架构和非功能性需求。它生成的代码可能表面良好并通过了基础测试，却可能在真实场景下崩溃。正如另一位技术领导者所说，氛围编程会制造一种成功的假象，直到“系统在工作负载下开始摇晃” —— 然后毫无预警地彻底崩溃。
某架构师发现 AI 编写的认证模块存在致命漏洞：初级开发者通过复制粘贴 AI 建议和 Stack Overflow 上的代码片段“氛围编码”出用户权限系统。它通过了初始测试甚至 QA 审核。但上线两周后，他们发现一个致命的缺陷：已停用账户的用户仍能访问某些管理工具。AI 错误地颠倒了真值检查（例如误用否定逻辑），这一细微漏洞被遗漏。由于没有人深入理解自动生成的代码，问题未被察觉。“当时看起来一切正常，”开发者曾这样解释。这是典型的 AI 生成错误 —— 人类自行编写时可能发现的逻辑颠倒，但 AI 写出来被当作黑箱处理，最终导致严重的安全漏洞。一名资深工程师花费了两天的时间在浩如烟海的 AI 代码中排查这个单行 bug。该架构师称之为“信任债[5]” —— “它迫使资深工程师成为一名永久的代码侦探，为了发布稳定的版本更新而反向解读“氛围”驱动的代码逻辑。”换言之，每次未经验证就信任 AI 输出，都是在累积债务，终需有人梳理代码来真正理解和修复代码。
一个关于可维护性与复杂性的噩梦，源自某个AI生成功能的真实案例：该功能最初运行良好……直到需求发生变化。某团队允许开发者用 AI 氛围编码整套用户认证流程，短短几分钟内缝合了随机 npm 包和 Firebase 规则。起初“表面一切顺利——客户满意，团队庆功，”某位工程经理说。但当团队后续需要对现有的用户认证/授权功能进行修改和增强时，“它彻底崩溃了。没有人能理清组件间的关联关系。中间件散落在六个文件中。没有心智模型，只有氛围。”最终他们不得不彻底重写，因为调试 AI 产生的意大利面条式代码“如同进行考古工作[5]”。这说明 AI 的输出内容结构散乱、缺乏统一规范，只会留下一团乱麻，根本无法维护。
错误的安全感是另一个隐蔽的危险。 AI 生成的代码通常看起来非常整洁甚至符合语言规范。它可能通过你编写的单元测试，于是开发者便会放松警惕。某 CTO 指出氛围编程最危险的特征是代码“看似能够完美运行，直到出现灾难性崩溃[5]”。AI 生成代码让团队笑着放入生产环境，然后狠狠反噬。甚至代码审查也可能失效：审查 1000 行 AI 编写的 PR 并不比从头编写容易多少 —— 尤其当审查者假设代码基本正确时。若 AI 还辅助代码审查（确实存在这种情况），就成了盲人引导盲人 —— 正如某位评论者所言“这就是用机器验证机器[6]”。可维护性因此受损，因为无人真正掌握代码的逻辑内核。

行业领袖的共识是：氛围编程会危及软件的质量属性 —— 安全性、代码清晰度、可维护性及团队知识传承。

这些行业领袖并非抗拒新技术的勒德主义者 —— 他们才是对系统稳定运行负责的人。他们传递的信息虽然尖锐但具有建设性：利用 AI 作为辅助工具，而非放弃职责。代码依然需要人类判断力，尤其是将要部署到线上生产环境的代码。正如一位资深开发者所言："AI 工具是副驾驶，而非自动驾驶系统。"它们能协助驾驶飞机，但必须由人类飞行员规划航线，并在遭遇湍流时随时准备接管操控。

04 “这算不上工程实践，只是在赌运气。”

不仅是 CTO 和思想领袖在敲响警钟 —— 2025 年以来，一线开发者社区（那些日常与 AI 工具打交道的实战派）也在就氛围编程展开激烈辩论。在 Reddit[7] 和 Hacker News[8] 上，相关话题获得了数百次点赞，资深开发者们分享着血泪教训与对其的尖锐批评，间或夹杂少数成功案例。整体舆论氛围倾向于对在重要项目中使用未经审查的 AI 代码保持高度怀疑，但氛围编程对特定场景内的应用持有限乐观态度。

批评声中，开发者们讲述氛围编程如何负面影响其工作流程与团队协作。某 Reddit 热帖[9]的最高赞评论慨叹：

“我只希望人们别再在 PR 里 @ 我 —— 他们自己明显都没读过代码，却指望我审查上千行完全陌生的氛围编程出来的功能，这玩意甚至连 CI 都没通过。”

这种挫败感显而易见：如果代码作者自己都不理解 AI 生成的代码或懒得运行测试，代码审查就成了闹剧。它将责任转嫁给毫不知情的同事。另一位评论者回应[9]称此举“远低于专业素养的最低标准”，就像工人草率施工让他人收拾残局。当开发者未尽应尽的职责就将 AI 的输出丢给他人时，同行评审机制与团队信任便土崩瓦解。

没有人愿意与这样的“工程师”共事，其贡献只是从 ChatGPT 复制粘贴，并在出问题时耸肩推诿。

“这算不上工程实践，只是在赌运气”[6]的表述（源自 ShiftMag 文章观点的转述）在这些讨论中被反复引用。它精准传递了这样的观点：未经适当的审查/测试的氛围编程无异于指望软件靠魔法运行。许多开发者指出编程应是工程学科，而非许愿仪式。

然而在批评声浪中，技术社区也涌现出相反的观点和稍微不一样的观点。并非所有人全盘否定氛围编程。部分实践者发现其在某些场景中优势显著。某 Hacker News 高赞评论[8]借用经典的“创新者窘境”[8]理论框架：今天有专家视氛围编程为玩具，明天它就可能进化并颠覆旧有的方法。虽多数回应不认同这种必然性，但该讨论开启了一个乐观的视角：或许我们正处于 AI 编码的早期阶段，未来 AI 或方法论的改进将解决现有缺陷。

某 HN 用户分享了一个成功案例[11]：他用氛围编程极速地开发了一款定制的内部工具。

“上周我将一堆 Docker Compose 配置转换为 Terraform（Opentofu） —— 边看电视边用 Claude 操作，花了一两小时。若采用阅读文档和 Stack Overflow 的传统方式，随便都得耗上一周。”

该开发者构建的并非面向客户的产品，而是在自动化一项繁琐的基础设施任务。在此场景下，氛围编程大获全胜：既节省时间，而且生成的代码对于他控制的内部工具来说也“足够好用”。许多人纷纷附和，认为对于小规模或一次性的脚本和胶水代码，氛围编程可以极大提升生产效率。这是经典的 80/20 权衡 —— 若需快速实现且唯一利益相关者是自己时，AI 可在数分钟内产出解决方案。

关键在于，这个案例中的开发者清楚边界：他将 AI 视为加速自身工作的助手（甚至边编码边娱乐），并大概率也验证了 AI 的输出。这符合行业内多次讨论中的共识：“若你清楚自己在做什么，它就是绝佳的时间节省器。”言下之意是：经验丰富的开发者可以像使用动力工具那样运用氛围编程加速繁琐工作的进行，但仍需架构设计、过程引导与结果复核。若缺乏经验，同样的动力工具会造成严重破坏。

讨论中还出现了一些有趣的类比：“ 与 agentic LLMs 协作编程本质就是项目管理[8]。”你的工作不再是编写代码，而是为 AI 分解任务、验证每个模块并整合结果。本质上如同管理一位非常初级（但极快）的开发者的项目经理。有人认为这样会更轻松，故称“氛围编程”，另一些人则认为仍需扎实的开发能力，只是应用方式不同。成功者会完成一系列系统化的处理步骤，将问题拆解为可验证的小型提示词，通过拆分、验证、迭代保持控制力。失败者则向 GPT 抛出一个模糊的提示词后直接粘贴输出。

社区的基本共识是：氛围编程并非银弹。资深开发者大多将其视作原型设计和自动化完成琐碎任务的有趣工具，而非复杂系统[8]中严谨工程实践的替代品。“LLMs 将编写所有软件”的炒作正在遭受质疑。与此同时，大家也承认 AI 编码助手将长期存在，若审慎使用[4]，可带来巨大的效率提升。目前的讨论焦点正转向如何将 AI 融入工作流程，同时还不丧失软件工程的严谨性 —— 这将是本文接下来要探讨的方向。

05 氛围编程适用于哪些应用场景？

若纯粹的氛围编程对生产环境有风险，它是否仍有价值？行业领袖与实践者的答案都是肯定的：氛围编程在某些特定场景下表现卓越，尤其在快速原型设计、探索性项目及作为创意辅助工具时，但必须知晓何时停止“氛围营造”并开始工程化实践。

FinalRound 调查[5]中多位 CTO 承认他们并不“完全否定氛围编程”，而是通过划分使用场景来实现最大效益。LittleHelp 创始人 Matt Cumming 分享道[5]，他可以“在一天内无故障创建并部署一个功能性的微型 SaaS 网络应用，这堪称疯狂”。他利用一个周末时间，借助 AI 来完成繁重的工作，将创意转化为一款可以上线的产品。这种速度前所未有，将可能需要 2-3 周完成的 MVP 构建压缩至 48 小时。对于黑客松、演示项目、内部工具及快速验证产品与市场的匹配度而言，氛围编程可能改变游戏规则。它让小团队（甚至独立开发者）在功能输出上实现远超团队规模的表现。

然而，每位称赞这类成功案例的领导者都附加了重大限制条件。Matt Cumming 曾付出代价才认识到：没有约束地释放 AI 可能适得其反。他描述了自己的一个早期项目在历经一个月的开发后，因某些 AI 生成的代码损坏或错误，在“几分钟内被 AI 彻底摧毁”[5]。这次经历令他痛定思痛，从而建立了一套严谨的工作方法：

“我们使用 AI 辅助编码时，首先要与 AI 协作撰写功能规格说明和项目文档中的实施步骤。我吸取的另一个教训是：需要要求智能体对所有新增功能进行安全检查。”

换言之，需要利用 AI 协助规划与审查，而非仅仅将其作为代码生成器。通过让 AI 先勾勒设计框架，他确保了自己对系统架构有自己的思考。通过要求 AI 对输出进行安全分析，他为漏洞防范增设了自动化的基础检查。他的团队还将氛围编程严格限定在“一次性的项目与产品原型，而非需要扩展的生产系统”上。通过氛围编码构建的应用仅作为概念验证（Proof of Concept）存在，后续可能需要重写或强化才能投入实际使用。

另一位领导者 Featured 公司 CEO Brett Farmiloe 对此表示赞同：

“一切从零开始时，氛围编程确实非常高效……我们使用 v0（某个 AI 工具）快速构建并部署了网页站点。但对于已定型的生产环境中的代码库，我们仅将氛围编程组件作为起点 —— 随后由技术团队成员接手完成后续工作。”

他与 Cumming 都将 AI 生成的代码视作脚手架。快速搭建框架并验证构想，这种方法非常高效，但绝不会将摇晃的脚手架留作最终建筑，需用坚固材料替换或加固它。用软件术语来表述：AI 生成的项目原型必须经过人类工程师的重构、测试并全面掌控后，才能成为永久的解决方案。

另一获认可的应用场景是遗留代码重构[4]。某分析指出，部分公司允许 AI 将旧代码片段用新框架或新编程语言重写，以此作为“起步助力”。由于这些代码最终需要经过全面审查与测试，所以使用 AI 完成暴力翻译或机械性工作可以节省时间。类似地，AI 能协助修复已知的代码缺陷：例如“解决代码中的这 5 个特定缺陷” —— 这是给 AI 一个非常具体、明确的任务，而非全权委托 AI 生成。此类场景中，范围受限且输出经过验证，更贴近 AI 辅助编程而非盲目的氛围编程。

在此可以总结 2025 年氛围编程最具价值的应用场景：

快速原型设计与黑客松：需要在明天之前演示一个项目想法？使用 AI 生成代码能极其快速地实现一个可运行的产品原型。即使代码杂乱也无妨，只要它能展示核心概念。在此阶段，编码速度与迭代次数比代码健壮性更重要。氛围编程让你能在一天内尝试三种不同方案，而这是传统编码方式永远无法实现的。
一次性的脚本代码与内部工具：若代码无需长期维护且仅作者本人使用，风险相对较低。编写快速数据分析脚本、转换文件格式、自动化编写服务器配置文件 —— 此类任务通常可安全采用氛围编程，因为若出现故障，编写者（借 AI 之力）可自行修复，且外部影响有限。个人项目或自动化脚本是氛围编程的沃土，能将工程师从琐碎的工作中解放。
从头开始新项目（需谨慎）：从零启动新项目比将 AI 集成到复杂的旧系统中更易采用氛围编程。当项目尚处于空白阶段时，约束条件更少且无需遵循既定的代码风格。团队可能会采用氛围编程方式快速实现新微服务或前端应用的初版以赶超紧迫的截止日期，后续再对其进行优化完善。

然而在所有场景中，都默认有一个前提：经验丰富的开发者参与决策循环、处于核心流程之内。那些通过氛围编程取得成功的人，依然会运用自己的判断力来有效引导 AI 并验证其输出。他们将其视为与一位不知疲倦但容易出错的初级开发者进行结对编程。与此形成鲜明对比的是，新手可能认为 AI 是跳过学习过程的魔法捷径 —— 这种方式往往以挫折和失败告终。如果初学者过度使用氛围编程，可能会绕过必要的学习阶段，培养出简历上有亮眼项目但缺乏基础技能的毕业生 —— 这是教育工作者指出的另一个长期风险。最终，当 AI 与人类经验结合时，它能显著减少琐碎工作所耗时间，但你很可能无法完全跳过人工审查与改进环节：

氛围编程作为一项创意的激发与加速工具还是十分有价值的，但氛围编程出来的代码如果真的要用于正式项目，绝不能直接使用。它必须只是一个初稿或原型，需要经过后续的工程化处理。用它实现从零到项目演示阶段的突破，或生成样板代码，或探索多种方案。随后迎来最关键的阶段：将 AI 生成的代码或原型转化为符合生产要求的、健壮的代码。如何有效实现这一过渡将是我们接下来的焦点。

06 规范驱动的开发方法，是否能成为解决 AI 编程中“提示词混乱”问题的有效方案？

针对氛围编程的缺陷，一个充满前景的发展方向是规范驱动和“agentic” AI 编码方法[12]的兴起。这些方法旨在保留 AI 代码生成的生产力优势，同时引入更多明确的开发流程和代码规范、设计与架构思考，以及代码审查、测试、安全检查等质量保障措施 —— 本质上是为自由散漫的氛围编程过程添加护栏。

使用开发规范驱动 AI 开发意味着在编写代码前，首先要明确开发规范或项目设计文档（通常与 AI 协作创建）。工程师不会直接发送给 AI 一句“帮我构建个功能”，而是告诉 AI “协助我规划该功能的需求与模块设计”。通过制定明确规范（无论是一段文字、一份正式的设计文档，还是一个简单的步骤列表和函数列表），开发者能确保自己与 AI 对目标达成共识。这就像先编写伪代码或用户故事（译者注：是敏捷开发中的需求描述方式，格式通常为“作为[某角色]，我想要[完成某事]，以便[实现某价值]”。它从用户视角定义功能价值。）。此举解决了氛围编程的一大缺陷：缺乏方向性。与 AI 共同撰写功能规范能使团队保持不脱离正轨，约束其输出必须严格符合预设的目标，从而避免产生“聪明但无用”的复杂代码。

在实践中，开发规范驱动的工作流可以包含：首先引导 AI 生成高层级规划、接口定义甚至测试用例，并持续迭代这些内容，直至人类认可该方案的合理性，随后才要求 AI 实施具体计划。这类似于优秀工程师指导初级开发者的方式 —— 你不会让初级开发者第一天就独立编写整个子系统，而是会先共同商定项目设计。面对 AI，我们要学会采用相同的方式：将它视为需要详细蓝图的初级伙伴。早期证据表明，这种方法比临时性的提示词能产生更好的结果。

Agentic AI 方法更进一步，使 AI 不仅能遵循规范，还能执行部分自主行动（例如运行代码、进行测试和持续优化。）。此处的“Agentic”指 AI 智能体可接受高层级目标，并在限定范围内以自主迭代的方式实现目标。例如，部分工具允许 AI 执行所编写的代码、观察结果并修复错误 —— 全程无需用户在每一步骤都发出明确指令。

规范驱动的开发方法与 Agentic 方法从以下几个主要方面区别于初级的氛围编程：

前瞻性规划 vs. 事后补救：与先写代码再试图去理解（或单纯指望其侥幸工作）不同，规范优先的开发方法从一开始就明确编码意图。AI 的输出结果会依照明确的目标进行评判，从而减少“技术层面实现了要求，但实际效果不符合预期”的意外（这在提示词不够具体时尤为常见）。
小步迭代 vs. 大包大揽：Agentic 工作流程鼓励小而可测试的增量开发。不同于一次性要求生成千行程序，而是先要求一个函数，看到它通过测试后再继续。这本质上模仿了测试驱动开发（TDD），只不过是由 AI 根据你的测试描述来编写代码实现。如果说氛围编程像是用一句提示词写一整本小说，规范驱动则像是与 AI 合著，逐章推进并持续进行审校。
人机协同 vs. 人类单干：有趣的是，Agentic 方法在某些方面反而能减轻人类负担 —— 例如将繁琐的验证工作交给 AI 处理。举个例子，如果每个由 AI 生成的拉取请求（PR）都必须附带修改说明，那么就可以让 AI 智能体先草拟说明初稿，再由开发者编辑来确保准确性，从而确保任何代码合并时都带有上下文。实际上，这类方法试图将 AI 融入软件开发最佳实践的体系中，而非取代它们。它们不是忽略测试与审查（如氛围编程常做的那样），而是将部分测试、审查工作自动化。

实践中，探索这些方法的团队常采用如下策略：

为所有由 AI 生成的主要组件编写设计文档（哪怕只有一页，也可借助 AI 完成），以确保充分考虑该组件如何融入系统。
使用 AI 为自己生成的代码生成单元测试或基于属性的测试（property-based tests），及时捕捉明显的错误。
锁定依赖库、注重安全：例如要求 AI 只使用已批准使用的库，并严格执行安全扫描。值得一提的是，有个团队甚至以受控的方式故意用氛围编程生成不安全的代码，借此研究和改进安全扫描器 —— 让 AI 充当渗透测试工具而非生产代码编写者。
优先选用集成式 AI 工具（如 Cursor 或 VS Code Copilot），而非从 ChatGPT 复制粘贴。集成环境让开发者能在完整上下文中查看代码差异、即时运行，降低无意引入隐蔽问题的概率。
保持人类在决策环节的主导权：例如，AI 可提议代码变更，但必须经人工批准方可合并。这类似于持续集成（CI）系统中自动化工具运行测试和检查，但最终仍由开发者审核 PR。此时 AI 扮演的是 CI 助手，而非能自行部署到生产环境的自动机器人。

这些措施都是试图以实际的工程严谨性削弱“直觉式编程”的风险。它们承认大语言模型非常有用，确实能理解用户意图并为各种任务生成可行代码，但只有在清晰的指引和明确的边界下才能发挥最佳效果。若放任自流，它们很容易偏离正轨，或生成表面可用却在边界场景失效的解决方案。

本质上，规范驱动方法与 Agentic 方法都旨在融合 AI 与人类的优势：人类擅长定义问题、理解语境和做出判断。AI 擅长快速探索解决方案、编写样板代码，甚至在经过适当配置后能协调任务执行。AI 辅助工程的未来很可能在于这种中间路线 —— 既非纯靠提示词与祈祷的氛围编程，亦非完全自动化，而是通过增强型工作流实现用 AI 放大人类设计能力，同时以人类约束 AI 的过度发挥。

最佳方案是采用混合模式。在沙盒阶段：自由地进行氛围编码，测试项目创意，构建项目原型。在生产阶段：则需运用工程规范 —— 通过运行程序或代码片段，来验证其行为是否符合预期、是否没有 Bugs；在不改变代码外部行为的前提下，对代码内部结构进行修改和优化，使其变得更清晰、更易于理解和维护；在编写具体代码之前，对软件的系统结构、模块组成、它们之间的关系以及技术选型等进行规划和设计；在软件开发过程中，主动采取措施防止安全漏洞（如代码注入、数据泄露、未授权访问等）出现。