别跟风叫它"氛围编程"——我使用 AI 编程半年后的一些思考

声明：本文观点来自我自己，但文章是在 AI 辅助下生成的。我对内容负责。

写在前面

用 AI 辅助编程半年多了，一直想写点什么。最近看到各种关于”氛围编程”(Vibe Coding) 的讨论，有人说编程已死，有人说 AI 只是玩具——在我看来，这两种观点都失之偏颇。

实际情况是：这个世界很混沌。一部分人已经用 AI 撬动了巨大的生产力红利，另一部分人还没想过怎么把 AI 纳入工作流。这种分化正在形成一道新的数字鸿沟。

我的心路历程

回顾过去几年，我和 AI 的关系经历了几个阶段。

最早是 ChatGPT 出现，它某种程度上替代了 StackOverflow。遇到问题不用再翻帖子了，直接问就行。

然后是 Copilot。它让 AI 进入了 IDE，开始在代码仓库里协助我。但那时候还比较初级，主要是文件内的补全和生成——像一个聪明的自动补全工具。

真正的转折点是我开始用 Claude Code。

一开始我只是让它帮我完成一些相对独立的功能。慢慢地，我发现它能在复杂的现有项目里工作——理解上下文，遵循已有的代码风格，找到正确的切入点。我开始在细节上信任它，之后又开始和它讨论架构、设计方案。

当我察觉到这些变化后，有一瞬间，我觉得自己十年的代码经验在 AI 面前变得很脆弱。这种感觉让我陷入了 FOMO——害怕错过、害怕被淘汰。于是有一段时间，我几乎什么都想用 Claude Code 来做。

直到我 burnout 了。

短暂休息之后，我才意识到：过去的经验并非毫无价值。恰恰相反，正是这些经验让我能更好地使用 AI——知道什么问题值得问，知道怎么验证答案是否靠谱，知道在哪些地方需要保持警惕。AI 让我可以把更多精力放在架构和设计上，而不是陷在实现细节里。

想通这一点后，我开始做一些过去一直想做、但没有时间和精力去做的事情。比如，我构建了一个开源的 ADHD 药物数据库 adhddb.org，希望能为 ADHD 患者提供一些帮助。这个项目可能不会有多大影响，但 Claude Code 帮助我真正把这个想法变成了现实。

我为什么不喜欢”氛围编程”这个词

说完我的经历，再来聊聊让我有点不吐不快的事——“氛围编程”这个词。

这个词是 Andrej Karpathy 在 2025 年初说的，原意是描述一种状态：完全沉浸其中，拥抱指数级增长，甚至忘了自己在写代码。

听起来很酷，但在实际工程中，这个词极具误导性。

真正严肃地使用 AI 编程，绝对不是什么”氛围”可以形容的。你需要考虑在什么时候、以什么方式让 AI 介入；你需要和它交互，纠正它，反复调试，才可能得到想要的结果。

把这个过程叫”氛围”，就好像在说这是一件随性的事。但实际上，它需要的思考一点都不比手写代码少，只是思考的层面变了——从”怎么实现”变成了”怎么描述需求、怎么验证结果、怎么发现 AI 的逻辑漏洞”。

Simon Willison 说得好：“如果我无法向别人解释清楚这段代码在做什么，我就不会把它提交到仓库里。“——不管这代码是谁写的。

“信任，但要验证”

既然”氛围编程”不可取，那正确的姿势是什么？Anthropic 博客提出了一个原则叫 “Trust, but Verify”（信任，但要验证）——我觉得这个说法非常精准。

有意思的是，据报道，Anthropic 内部超过一半的工程师表示，他们只能”完全委托”不到 20% 的工作给 Claude，因为他们”仍然觉得需要检查和验证 Claude 的输出”。换句话说，最了解 AI 能力边界的人，往往是对 AI 最不盲目信任的人。

Anthropic 的博客还提供了一个很好的类比——用 AI 编程就像用 Google Maps 导航：

初期：你会盯着每个路口，确认导航没把你带沟里去。类似地，在 AI 编程的初期，你会逐行审查生成的代码。
成熟期：随着信任建立，你开始依赖导航做宏观路线规划，只在关键节点确认。
但永远不盲从：如果导航让你”把车开进湖里”，你必须有覆盖指令的判断力。

AI 生成的代码有个特点：它往往”看起来”非常正确——变量命名规范，缩进完美，甚至有注释。但内部逻辑可能完全是错的。这就是所谓的”幻觉”在代码领域的表现。

所以验证不是可选项，是核心环节。具体怎么验证？我总结了几个实用的方法：

1. 双重代理验证

让一个 AI 写代码，另一个 AI 审查代码。比如写完之后，换个对话窗口，让 AI 扮演”资深安全审计员”来挑刺。AI 在”挑错”方面往往比”生成”更敏锐。

2. 测试先行

在生成实现代码之前，先让 AI 生成测试用例。你审查测试逻辑，确认测试是合理的，然后再让 AI 生成实现。如果测试不过，代码就没价值。

3. 静态检查兜底

配置好 TypeScript、ESLint 这些工具。如果 AI 生成的代码连类型检查都过不了，直接打回重写。

4. 人工审查收尾

即使代码跑通了，也要审查可读性和可维护性。机器能保证”能跑”，但”好维护”还得靠人来把关。

怎么”严肃地”使用 AI

验证是最后一道防线，但更好的做法是从源头提高 AI 输出的质量。这需要在交互和纠正两个环节下功夫。

交互：上下文工程

别直接问”怎么写一个登录页面”。

严谨的做法是：

收集上下文：把相关的 schema、组件库文档、API 定义喂给 AI
设定角色：“你是一个资深的前端架构师，专注于安全性和无障碍访问”
明确约束：“必须使用 React Hook Form，必须用 Zod 验证”
分步指令：“首先解释设计思路，其次列出文件结构，最后生成核心代码”

纠正：迭代式反馈

AI 输出不对的时候，别急着手动改，也别简单地重新生成。

直接把编译错误或运行时错误的堆栈信息喂给 AI
追问原因：“为什么选这个库？和 XX 库比有什么优缺点？”
引导式修复：“代码在处理空数组时会报错，请增加边界检查”

这种迭代式的反馈，既能修复当前问题，也能帮助你理解 AI 的思考方式，为下一次交互积累经验。

DHH 可以拒绝，你可能不行

聊了这么多”怎么用好 AI”，可能有人会问：我就是不想用 AI，行不行？

DHH 最近说，即便 AI 很强大，他仍然想保留手写代码的权利，因为这是一种享受。

我尊重这个选择。但我也认为，能够拒绝一件事，是因为你有拒绝的自由和权利。

DHH 有巨大的行业声望和财富积累，他写代码不是为了生存或赶工期，而是为了艺术表达和个人满足。他有资本选择效率更低但体验更好的方式。

但对于大多数普通开发者来说，情况不一样：

就业市场竞争加剧，对开发效率的要求越来越高
大量初级工作正在被自动化
对于独立开发者来说，AI 是生存的杠杆——它让一个人能完成过去需要一个团队才能完成的工作

DHH 的观点代表了一种”手工艺人”的浪漫主义，这很美好。但普通人面对的是”工业化”的现实。学会用 AI，不是要放弃编程的乐趣，而是为了在这个时代站稳脚跟。

AI 是普通人很好的杠杆。它能放大个人能力，让一个人成为一支队伍。

别省那点订阅费

既然决定用 AI，就别在工具上省钱。

很多人试图用免费模型体验 AI 编程，结果失望了，得出结论说”AI 没用”。这是典型的因工具选择不当导致的认知偏差。

免费或轻量级模型的问题：

复杂逻辑推理弱，生成的代码充满细微的逻辑错误
上下文窗口小，无法理解整个项目结构
幻觉率高，容易编造不存在的 API

用劣质模型会产生巨大的”纠错成本”。你花大量时间调试 AI 的错误，最后觉得还不如自己写。

投资一些钱在 AI 上，使用你能找到的表现最好的模型。对于专业开发者来说，每月几十美元的订阅费只是时薪的一小部分，但换来的是一个全天候在线、拥有海量知识库、能秒级生成代码的高级结对编程伙伴。

这不仅是购买工具，而是购买时间和认知带宽。

我日常使用 Claude Code，并且永远优先使用当下最强大的模型（现在是 Opus 4.5）。即使要为此付出不少额外成本，我觉得值得。因为只有用上最先进的模型，你才能真正去实践”信任并验证”——如果模型本身不够强，你连信任的基础都没有，只剩下无尽的纠错。

最后

世界是混沌的，旧秩序在崩塌，新秩序还没建立。

在这个过渡期，既不盲目高呼”编程已死”，也不固步自封拒绝改变，而是以务实、严谨、批判性的态度使用 AI——这大概是普通人在 AI 时代最好的生存策略。

真正的未来属于那些能够驾驭 AI 的人，而不是依赖 AI 的人。

所以别叫它”氛围编程”了。叫它什么都行，但这件事，一点都不随性。