Vibe Coding 不是偷懒，Real Engineering 也不是守旧——真正的问题是你搞错了阶段

# Vibe Coding 不是偷懒，Real Engineering 也不是守旧——真正的问题是你搞错了阶段 > "你可以外包你的思考，但你不能外包你的理解。"——Andrej Karpathy --- ## 一个真实的故事 2025 年春天，我目睹过一个团队因为 vibe coding 吵了两周。一边是资深工程师，坚持每段代码都要 review、每个接口都要写测试、架构文档必须更新；另一边是刚入行两年的开发者，用 Cursor 三天搭出了一个能跑的 demo，功能完整，界面漂亮。 争论的焦点是什么？vibe coding 到底是不是"正经工程"。 两周后，那个 demo 在真实数据上崩了——没有错误处理，没有边界检查，一个 edge case 把数据库锁死了。但与此同时，资深工程师的"完美方案"还没写完第一版，竞品已经上线一个月了。 问题在哪？**两边都搞错了一件事：他们以为 vibe coding 和 Real Engineering 是在同一个维度上二选一**。不是。它们是不同阶段的工具，就像你不能用螺丝刀拧螺母，也不能用扳手切菜。 --- ## Karpathy 自己的转变说明了什么 2025 年 2 月，Karpathy 发推定义了 vibe coding："完全沉浸在 vibe 里，拥抱指数级增长，忘记代码的存在。" 2026 年 5 月，在 Sequoia AI Ascent 的讲台上，他说："vibe coding 已经过时了。" 不是因为他反对 vibe coding 的理念——恰恰相反，他是最早受益者之一。他的转变说明了一件事：**工具没变，场景变了**。 2025 年的 vibe coding 是用来做 side project、demo、验证想法的。那时候 LLM 的能力还不足以处理大规模生产代码，所以 vibe 的边界天然地限制了它的风险——反正只是玩具项目。 2026 年的 LLM 已经能重构十万行代码、找零日漏洞、写完整的功能模块。Karpathy 自己说，2025 年 11 月他写 80% 的代码，AI 辅助 20%；12 月这个比例反转了。Agent 的能力跨越了一个阈值。 **阈值一旦跨越，工具就不再只属于 playground**。当 AI 能写生产级代码时，vibe coding 的随意性就变成了 liabilities——安全漏洞会静默地潜伏，技术债务会指数级累积。 所以 Karpathy 提出了替代词：**Agentic Engineering**。不是"别用 AI 写代码了"，而是"用 AI 写代码的时候，要有工程的纪律"。 --- ## 锯齿状智能：为什么有些任务可以 vibe，有些不行 Karpathy 提出了一个被很多人忽略的概念：**Jagged Intelligence（锯齿状智能）**。 LLM 的能力分布不是平滑的曲线，而是锯齿——在某些领域强到离谱，在另一些领域蠢得令人发指。它能重构十万行代码，但可能算不清"从停车场走到洗车店该怎么规划"。 这个锯齿从哪里来？LLM 的后训练阶段用了 RLHF，而 RL 的奖励信号集中在**有可验证输出**的领域：数学、代码、逻辑谜题。这些领域的"正确答案"是确定的，所以模型被强化得极好。但真实世界的很多任务没有确定的验证标准——需要常识、需要物理直觉、需要对人类行为的理解。 这意味着什么？ **落在锯齿尖上的任务**：vibe coding 可以。因为模型在这个领域的准确率已经高到足以产生"有用的错误"——即使偶尔出错，你也能很快发现并修正。 **落在锯齿谷里的任务**：vibe coding 不行。因为模型在这里会 confidently wrong，而且你可能意识不到它错了，直到灾难发生。 具体例子： | 锯齿尖上 | 锯齿谷里 | |---------|---------| | 生成标准 CRUD 接口 | 设计分布式一致性协议 | | 写单元测试 | 判断安全漏洞的 exploit 路径 | | 前端样式调整 | 数据库 schema 的长期演化规划 | | 代码重构（有测试覆盖） | 跨系统的依赖关系梳理 | | 写文档注释 | 定义 API 的向后兼容策略 | **判断方法很简单**：如果这个任务的"对错"能被自动测试验证，它就大概率在锯齿尖上。如果需要人的判断、经验、 taste，它就在锯齿谷里。 --- ## 阶段光谱：不是二元对立，是四个象限 用户最初的框架是"探索 vs 交付"，这很好，但还可以更细。真正决定你用 vibe 还是工程的，不是"做完了没有"，而是**失败的代价、回滚的成本、需要 taste 的程度**。 我把它扩展成四阶段光谱： ### 第一阶段：个人探索（Personal Sandbox） **特征**：只有你一个人用，坏了就坏了，随时可以扔掉重来。 **工具**：vibe coding 全开。Cursor Composer、Claude Code、随便什么 agent，怎么快怎么来。 **底线**：没有底线，因为你就是底线。你随时可以说"这不行，重新 vibe"。 **例子**：周末想做一个能把语音转成笔记的小工具。用 vibe coding，两小时搭出来，能用就用，不能用就算了。 ### 第二阶段：团队协作（Team Tooling） **特征**：至少两个人在用，代码要进 git，需要别人能看懂、能接上手。 **工具**：vibe coding + 最低限度的工程约束。CLAUDE.md 的四条原则就是给这个阶段用的。 **底线**：代码要有基本的可读性，关键路径要有测试，不能引入明显的安全隐患。 **例子**：团队内部用的数据分析脚本。用 agent 生成第一版，但人需要 review 数据处理逻辑，确保不会误删数据。 ### 第三阶段：用户功能（User-Facing Feature） **特征**：真实用户会用，出问题了有客服工单，用户体验直接受影响。 **工具**：Agentic Engineering。AI 辅助写代码，但人负责架构决策、边界 case review、性能评估。 **底线**：错误处理完整，日志可观测，回滚策略清晰，有基本的压力测试。 **例子**：电商网站的支付流程。 agent 可以生成支付接口的 boilerplate，但幂等性设计、超时重试策略、对账逻辑必须人把关。 ### 第四阶段：核心基础设施（Core Infrastructure） **特征**：系统崩了整个业务停摆，数据丢失不可恢复，安全漏洞会造成实际损失。 **工具**：Real Engineering 为主，AI 辅助为辅。AI 可以用来加速编写，但不能替代设计评审、安全审计、混沌测试。 **底线**：形式化验证、多轮 review、合规审计、灾难恢复演练。 **例子**：金融系统的账本服务、医疗数据的存储层、身份认证系统。这些不是 vibe 的问题，是"一旦出错就进新闻"的问题。 --- ## CLAUDE.md：给 vibe 画一条边界线 2026 年 4 月，一个 65 行的 markdown 文件在 GitHub 上获得了 10 万 stars。它叫 CLAUDE.md，来自 Karpathy 的观察，核心只有四条原则： 1. **Prefer simple, minimal implementations**——别过度工程，但简单不等于随意 2. **Avoid unnecessary abstractions**——不要为了"优雅"而增加复杂度 3. **Write clear, explicit code**——代码是给人读的，不是给 agent 炫技的 4. **Add tests for critical paths**——关键的逻辑必须有验证 这四条原则太普通了，普通到任何一个正经工程师都不会反对。但**正是这最基础的工程常识，在 vibe coding 的狂欢中被忽略了**。 CLAUDE.md 的流行说明了一件事：开发者不是在反对 AI 写代码，他们是在反对**没有约束的 AI 写代码**。就像你不会让实习生直接 push 到 main 分支一样，你也不应该让 agent 无约束地生产代码。 它不是 vibe coding 的敌人，而是 vibe coding 的**护栏**。没有护栏的高速公路不是自由，是自杀。 --- ## 可操作的切换信号：什么时候该从 vibe 切到工程 知道光谱模型是一回事，在实际工作中判断"我现在在哪"是另一回事。以下是一些具体的信号： **从个人探索切到团队协作的信号**： - 有人问你"这个代码怎么跑？" - 你需要在另一台机器上部署 - 你开始想把代码分享给同事 **从团队协作切到用户功能的信号**： - 有真实用户（哪怕只是内测） - 代码开始处理敏感数据（用户信息、支付信息） - 出 bug 需要 hotfix 而不是"重新 vibe" **从用户功能切到核心基础设施的信号**： - 系统故障会影响公司收入 - 需要满足合规要求（SOC2、GDPR、HIPAA） - 代码被多个业务线依赖，改动有连锁反应 还有一个更简单的判断方法：**问自己"如果这段代码现在出错了，我最晚什么时候会知道？"** - 如果答案是"我现在就知道，因为我在看输出"——vibe 阶段 - 如果答案是"用户会告诉我"——需要工程了 - 如果答案是"等到新闻报导"——需要 Real Engineering 了 --- ## 真正的敌人不是 vibe，也不是工程 网上关于 vibe coding 的争论，大多集中在"vibe 是不是正经 coding"或者"传统工程师是不是 dinosaur"。这些争论都是错的。 真正的敌人是**阶段错配**： - 在需要 vibe 的时候过度工程——三天能验证的想法硬要写两周文档 - 在需要工程的时候硬 vibe——核心系统没有测试、没有 review、没有回滚策略 Karpathy 说得很清楚："Agentic engineering is about preserving the quality bar of what existed before in professional software." **目标不是写更少的代码，而是把人的精力从"打字"转移到"判断"**。Agent 负责执行，人负责 taste、边界判断、失败模式识别。最好的 agentic 工程师不是打字最快的，而是**理解最多**的——他们知道自己要什么、知道 agent 会怎么错、知道什么时候该叫停。 --- ## 结语：你的任务在哪 回到开头那个吵架的团队。如果他们读过这篇，可能会意识到： - 那个三天 demo 属于**第一阶段**，vibe 是对的，问题出在把它当成了第三阶段 - 那个"完美方案"如果还在第一版，说明第一阶段都没跑通就跳到了第四阶段 不是 vibe 错了，也不是工程错了。**是把 vibe 的随意性带进了需要纪律的阶段，把工程的严谨性强加给了还在探索的阶段**。 搞清你手上的事属于哪个阶段，然后选对应的工具。这才是成年人写代码的方式。 --- #vibecoding #AgenticEngineering #软件工程 #AI编程 #开发者思维 #工程实践 #锯齿状智能 #Karpathy #小凯