Vibe Coding与工程：我如何划定界限

Andrej Karpathy于2025年2月创造了”vibe coding”一词，描述了一种开发风格：程序员”完全沉浸在感觉中，拥抱指数级增长，忘记代码的存在。”¹

我读到这句话时想：这就是我一半的工作流程。另一半则恰恰相反。

TL;DR

我每天都用Claude Code构建项目。其中一部分是纯粹的vibe coding：描述我想要的，接受输出，继续前进。另一部分则经过86个hooks、一个git安全守护程序、一个递归防护机制，以及一个会拦截包含AI痕迹或被动语态提交的质量门禁系统。两者之间的界限并非随意划定。原型用感觉驱动，生产用工程驱动。难点在于判断原型何时跨越了那条线。

---

我的实际工作流程

感觉驱动的一面

当我探索一个想法时，我会毫不犹豫地进行vibe coding。我的Ace Citizenship iOS应用最初是一个周末实验：”构建一个用于USCIS公民知识问题的间隔重复测验。”Claude Code生成了最初的SwiftUI视图、题库和调度算法。我没有逐行阅读。我运行它，手动测试，然后通过描述哪里感觉不对来迭代。

这个博客上的交互组件（RAG决策树、复利计算器）也是以同样的方式开始的。”构建一个带有动画过渡的决策树，引导用户在RAG和微调之间做出选择。”接受、测试、调整。博客小组件中的bug影响范围仅限于单个页面。

工程驱动的一面

我的Claude Code hook架构与vibe coding截然相反。每个hook的存在都源于某次出错的经历。

git-safety-guardian.sh的存在是因为Claude在早期会话中对main分支执行了force push。该hook现在会拦截每个git命令，根据严重性表进行模式匹配（CRITICAL：对main的force push；HIGH：添加.env文件；MEDIUM：–no-verify），并在执行前注入警告。

recursion-guard.sh的存在是因为一个子代理生成了无限的子进程。该hook在JSON文件中跟踪代理谱系，强制执行深度限制，并管理一个生成预算模型，在允许合法并行工作的同时防止失控的代理链。

blog-quality-gate.sh的存在是因为AI生成的文章读起来就像AI生成的文章。该hook会在检测到破折号、被动语态或”delve”“crucial”“landscape”等词汇时，阻止对content/blog/的提交。

这些hook没有一个是通过vibe coding完成的。每一个都是逐行编写、针对真实故障场景测试，并在部署前经过审查的。这86个hooks共同代表了感觉驱动与工程驱动之间的界限。

---

界限实际在哪里

感觉驱动：一次性原型

我对任何可能丢弃的东西进行vibe coding。一个只运行一次的数据转换脚本。一个供个人使用的CLI工具。一个用于测试API是否如文档所述的概念验证。一次性代码中bug的代价只是我自己的时间，而速度收益超过了调试风险。

感觉驱动：创意探索

当我探索设计方向时，vibe coding让我能比Figma更快地测试交互模式。”构建一个带有键盘导航、结果高亮和Cmd+K激活的搜索模态框”能在几分钟内产出一个可用的原型。我评估的是感觉，而非代码。²

工程驱动：任何面向用户的内容

当代码服务于我以外的人时，它就跨越了那条线。我的博客经过一个12模块检查器，检查引用、标题层级、可读性等级、图片替代文本、内部链接密度和内容深度。检查器有77个测试。博客有29篇文章。检查器的测试数量比博客的内容还多。

工程驱动：任何持久化的内容

数据库模式、API契约、hook配置和部署清单都要接受完整的工程处理。这些决策会产生复合效应。一个在vibe会话中设计的模式，在三年数据累积之上，会变成迁移的噩梦。³

工程驱动：任何与安全相关的内容

AI生成的代码反映的是其训练数据的安全态势，而训练数据中包含大量为简洁性而省略认证、输入验证和错误处理的教程和Stack Overflow答案。⁴我的hooks能捕获其中一部分（git安全守护程序会标记.env文件添加、凭证文件和force push），但安全关键代码无论如何都要经过人工审查。

---

理解力差距问题

Vibe coding中最危险的模式不是糟糕的代码，而是在出问题之前一直正常运行的代码。

我为i18n翻译系统生成了一个缓存层。它在英文内容上运行完美。当我添加韩文和繁体中文时，缓存键生成对某些Unicode码点静默产生了碰撞。调试花了四个小时，因为我从未阅读过缓存键函数。代码对ASCII是正确的，而这正是训练数据所强调的。⁵

教训：vibe coding的系统会在训练数据低估的边缘情况下失败。如果您的用户在这些边缘运作（非拉丁文字、高并发、异常网络条件），vibe coding的实现就携带着隐藏风险。

---

审查门禁

在我的系统中，每一段面向生产的代码都要通过审查门禁，无论是我写的还是Claude Code生成的：

1. 逐行阅读。生成的代码是来自不受信任贡献者的pull request，请据此审查。
2. 验证错误处理。检查错误路径是否反映领域需求，而非通用的try-catch模式。
3. 审计依赖。AI在隔离状态下解决每个提示，导入任何能解决当前请求的库。经过50次提示后，您可能拥有三个日期库和两个HTTP客户端。
4. 添加测试。生成的代码很少覆盖特定于您领域的边缘情况。
5. 检查安全性。运行静态分析。验证认证、授权和输入验证。⁶

审查门禁不是可选项。它是将AI用作力量倍增器与将AI用作拐杖之间的区别。

---

行业分化

软件工程正在分化为两个层级。第一层将AI用作力量倍增器：生成样板代码、探索解决方案空间、加速实现已充分理解的模式，同时保持理解力和质量标准。第二层在不理解输出的情况下生成整个应用程序，以短期速度换取长期脆弱性。⁷

这种分化与早期Web开发如出一辙。像Squarespace这样的模板构建器使Web发布大众化，产生了数百万个功能性网站。专业Web开发依然存在，因为生产系统需要模板无法提供的质量、安全性和可维护性。

我有意在两个层级中运作。我的hook系统和质量门禁的存在，正是为了捕捉第二层工作需要提升到第一层标准的那个时刻。86个hooks不是官僚主义，它们是免疫系统，让我能够自由地进行vibe coding，同时防止vibe coding的产物未经审查就进入生产环境。

---

核心要点

给每天使用AI的工程师： - 在探索和生产之间划一条明确的线；自由地对一次性工作进行vibe coding，但在任何面向用户或持久化的内容之前执行审查门禁 - 构建自动化防护栏（hooks、检查器、质量门禁），而非仅依赖纪律；纪律在凌晨2点会失效，hooks不会

给工程管理者： - 在原型质量和生产质量代码之间建立清晰的界限；溜入生产环境的vibe coding原型会创造一种新类型的技术债务 - 通过结果（交付的功能、每个功能的bug数、用户满意度）而非速度指标来评估生产力；vibe coding会膨胀代码行数，却不成比例地改善结果

---

参考文献