氛围编程 vs 真实软件开发：区别究竟在哪？

当"氛围编程"遇上真正的软件开发

2020 年我开始学编程时，ChatGPT 还没问世。写代码是件苦差事，但每次修好一个 bug、解决一道算法题，那种"天才般的闪光感"让人上瘾。到了 2022 年，ChatGPT 出现了，能解编程题但仍不够成熟。随后 Lovable 这类产品承诺"用 AI 交付完整应用"，如今 AI Agent 直接嵌入代码编辑器——我们只需要打字提示，AI 就能产出"能用"的东西。

但等一下。

问问自己：我到底在做软件开发，还是在做氛围编程？这两件事本质不同。一个的产出是可靠的产品，另一个只是精心包装的"漂亮垃圾"。

真正的软件开发包含什么？

根据 IBM 的定义，软件开发生命周期（SDLC）有 7 个阶段。逐一来看。

1. 规划

确定项目范围、目标和需求。用大白话说，就是搞清楚你到底在造什么。划定边界，列出想要的特性、暂时不要的特性，否则就会陷入"范围蔓延"——项目目标和特性的失控膨胀。

范围蔓延（Scope Creep） 是项目管理中的经典风险：项目启动后，需求不断被非计划地追加或修改，导致时间、成本与质量失控。它通常源于初期需求定义模糊、干系人不断提出新想法，或缺乏明确的变更控制流程。在软件开发中，范围蔓延的典型表现是：原型阶段不断加功能、UI反复推翻重做、上线日期一再推迟。对抗它的关键是：在规划阶段就明确「要做什么」和「不做什么」，把需求写成可验证的清单，任何新增项都必须经过评估并重新分配资源。氛围编程尤其容易触发范围蔓延——因为向 AI 加需求只需一句提示，成本感知被极度压低，项目边界随之瓦解。

2. 分析

数据收集阶段。整理用户故事、评估市场潜力、判断技术可行性。这一步决定了"这个项目值不值得做"。

3. 设计

定义项目架构，规划用户界面、数据库模式、软件导航、技术选型——用单体还是微服务。这一步是开发流程的心脏，也是区分初级和资深工程师的关键。

4. 编码

没错，这就是最让人兴奋的部分。编码只是开发的一部分，而 AI 在这件事上确实非常擅长。选一门语言——Java、C#、Python 或 JavaScript——然后写出应用的代码。这部分我不跟 AI 争。

5. 测试

另一个区分真工程师和"伪工程师"的关键环节。测试框架层出不穷：Cypress、Jest、Vite Test、Playwright、Pytest。测试方式也多种多样：单元测试、集成测试、端到端测试。未经过测试的应用不能发布给用户。当然你不可能测试所有场景，但覆盖率越高越好。

单元测试、集成测试与端到端测试 是三个不同粒度的验证层次。单元测试聚焦单个函数或模块，验证最小逻辑单元是否正确，运行快、定位准；集成测试关注多个模块协同工作时是否正常，例如数据库连接、API 调用是否按预期交互；端到端测试模拟真实用户流程，从界面到后端完整走一遍，验证系统整体行为。三者形成「测试金字塔」：底层单元测试数量最多，上层端到端测试数量最少但成本最高。氛围编程常常完全跳过这些层次，导致代码看似能跑，一旦用户量增加或边界条件出现，故障便集中爆发且无从定位。

6. 部署

好应用得有用户。部署方式可以是第三方 PaaS 平台（Render、Railway、Fly.io），也可以自建云基础设施（AWS、Azure、华为云、DigitalOcean），甚至本地部署。移动应用则发布到 App Store 或 Play Store。这一步可以很简单，也可以非常折腾。

7. 维护

应用维护是持续过程：更新、补丁、修复、安全检查、监控。软件会演化，技术会过时，你得跟上节奏。想象 Facebook 还停留在 2006 年发布时的样子——刷新才能看到新消息，谁还会用？软件需要持续维护和改进。

你可能会问：一个人怎么可能做完这些？答案是：一个人确实做不到。大多数软件由不同专业的团队协作完成——项目经理负责规划、系统分析师负责分析、UI/UX 设计师和软件架构师负责设计、程序员负责编码、QA 工程师负责测试、DevOps 工程师负责部署、维护工程师负责运维。软件工程师必须了解并遵循所有这些流程，与跨职能团队协作，同时写出干净、可维护的代码。

氛围编程的真实面貌

现在我叼着棒棒糖坐下来，告诉 AI Agent："给我做个约会应用。" AI 甚至不会追问任何澄清，直接翻炒出一堆东西说"给你"。你看到漂亮的界面，却完全不知道架构缺陷和安全漏洞。直到有了 10 个用户，开始注意到应用卡顿，你不断提示 AI 修复，但因为你不了解什么可行、什么可用，AI 一边修一边制造新 bug，没有测试用例，你持续折腾六个月，最终困惑地放弃整个项目。

这就是氛围编程的现实。有人花了六个月在提示 AI 中受挫，最后放弃他们制造的一堆烂摊子。侥幸上了生产环境的，开始遭遇宕机、API 失败和崩溃，却没有适当的监控，无法追踪故障根因。金钱和信任在这个过程中流失——这是企业最宝贵的两样东西。

更不用说用氛围编程来做关键任务软件——那些关乎生命的系统——后果不堪设想。

著名程序员 Brian Kernighan 说过一句话：

所有人都知道调试比写程序难一倍。所以如果你写代码时已经用尽了全部聪明才智，调试时你还能怎么办？

技术债（Technical Debt） 是 Ward Cunningham 提出的隐喻：为了快速交付而采取的捷径，会在未来以更高的维护成本「偿还」。氛围编程本质上是在无意识中大量举债——AI 生成的代码可能冗余、耦合混乱、缺乏文档，且没有测试作为安全网。当应用规模扩大、需求变化时，这些隐藏问题会集中显现，修复一个 bug 往往引入两个新 bug。与之相对，受过训练的工程师会有意识地管理技术债：知道何时可以走捷径、何时必须投入重构，并在架构层面预留演进空间。这正是「能生成代码」与「能交付可靠产品」之间的鸿沟。

AI 辅助编程 ≠ 氛围编程

那这是否意味着开发中不能用 AI？当然不是。AI 辅助开发是指：一位经验丰富、功底扎实的工程师使用 AI 快速编写代码、实现特性或构建应用，同时向 AI 提供指导——用什么工具、采取什么方法、做什么架构决策、写哪些测试。他把多年经验倾注到指挥 AI 构建杰作的过程中。这是可行且值得称赞的。这也证明了一个道理：要想用好 AI，你仍然需要学习编程、练习解决问题。

严肃地说，氛围编程适合简单应用，但任何中等规模到复杂的应用都需要受过训练的专业人士。

最让我痛心的是看到氛围编程者涌上 LinkedIn 自称"全栈开发者"——一个分不清 JSON 和 XML、不知道 GitHub 是什么的人，居然还能接到客户。再好的工具，在愚人手中也形同废物。这不是负能量，这就是现实。

未来我们仍然需要优秀的工程师来构建安全、可靠的应用。理解技术栈的人不会被取代。所以，端起你的咖啡，写下第一行代码吧——这将是一段狂野的旅程。