"Vibe Coding"这个词火了有一阵子了。Andrej Karpathy说他写代码时更像是给AI指个方向，然后让AI去实现，自己更像是在"vibing"——感受代码的走向，而不是一行行敲出来。这说法一出，无数开发者深有共鸣。毕竟谁不想当那个只管提需求、不用写实现的人呢？

这体验确实爽。你告诉AI"帮我写一个用户认证模块"，唰唰唰生成了一个看起来像模像样的实现。你甚至不用读完每一行代码，直接点运行，测试通过，感觉自己效率起飞。

但我观察到一个现象：Vibe Coding在Demo里无所不能，在生产环境里处处掣肘。那些靠AI快速拼出来的代码，一旦进入有历史包袱的真实业务系统，就开始不断露馅。而且问题往往不是代码本身有Bug，是这些代码跟现有系统格格不入。

这不是AI不够聪明。这是Vibe Coding这个工作方式本身的前提就不成立。

你以为在写代码，其实在丢上下文

Vibe Coding的核心体验是什么？你只需要表达意图，代码自动出来。这个体验让人上瘾，因为它跳过了编程中最痛苦的部分——把模糊的想法翻译成精确的逻辑。

但有一个被忽略的前提：你跳过的那些部分，恰恰是你建立代码上下文的过程。

手写一个函数时，你会考虑它放在哪个模块里、依赖哪些状态、异常路径有哪些、在什么条件下被调用。这些思考不是"打字的成本"，是"理解的成本"。Vibe Coding帮你省掉了打字，但同时也省掉了理解。

从零开始的项目里，这个问题不大——一切全新，上下文可以重建。但在一个运行了三年、几十万行代码的理财系统里呢？你让AI"给持仓页加一个收益展示功能"，它生成了一段看起来完全正确的React组件代码。但这段代码不知道：

- 持仓金额在不同理财产品类型下精度不同，货币基金两位小数，定期产品精确到分
- 收益展示有合规要求，七日年化必须带"过往业绩不代表未来"的免责声明
- 这个组件在低端机型上需要懒加载，否则首页FCP指标会直接回退
- 收益数据来自两个不同的BFF接口，一致性窗口是5分钟

AI不知道这些，因为它从未参与过这个系统的需求评审、合规讨论、性能优化。这些"隐性知识"不存在于代码里，不存在于文档里，存在于经历过这些讨论的人脑子里。

Vibe Coding让人觉得"写代码"就是"生成代码"。但在生产环境里，"写代码"的真正成本不是生成，是理解上下文并把代码正确地嵌入上下文。

调试的黑洞：你改不了你看不懂的代码

Vibe Coding还有一个更隐蔽的问题：当AI生成的代码出Bug时，调试效率会断崖式下降。

听起来有点反直觉——AI不是也能帮你调试吗？确实可以。但调试有一个前提：你至少要能判断AI给你的修复方案对不对。而如果你一开始就没有逐行理解这段代码的逻辑，拿什么来判断？

我见过一个典型的场景：一位同事用AI生成了一个复杂的数据聚合函数，用于合并不同来源的持仓数据。代码跑起来了，测试也通过了。上线两周后，部分用户反馈持仓金额偶尔出现不一致。这位同事把错误日志喂给AI，AI给出了三个可能的修复方案。但他无法判断哪个是对的——因为他不完全理解这段代码的数据流。

最后是一位从这个系统第一天就参与的老同事，扫描了一眼就指出问题所在：聚合函数没做时间窗口对齐，T+1和T+0的数据混在了一起。

AI生成的代码给你一种"我理解这段代码"的幻觉——能跑、测试通过、看起来规整。但运行通过和理解是两码事。尤其是边界条件和隐性约束，AI大概率不会在生成代码的时候就帮你考虑进去。

这里就产生了一个悖论：Vibe Coding越成功——AI替你写的代码越多——你对自己系统的理解就越浅。理解浅到一定程度，就失去了独立调试的能力。你变得完全依赖AI来修复AI自己生成的代码。这不叫提效，叫技术债的加速度。

能跑的代码不等于能集成的代码

Vibe Coding最擅长的场景是什么？新项目、新模块、从零开始。在这些场景里，AI不需要理解现有系统的约束，因为它在创造新的东西。

但生产环境的大多数工作不是从零开始。是在一个已经运行几年的系统上做增量开发。核心挑战不是"写出能跑的代码"，而是"写出能和现有系统和平共处的代码"。

举个具体例子。假设要在现有理财系统里加一个"智能推荐"模块。Vibe Coding的方式是：描述需求，AI生成推荐组件，包含推荐算法调用、UI展示、用户交互逻辑。代码看起来很完美。

但这个组件要上生产，至少要解决这些问题：

推荐接口的调用要走BFF层的统一鉴权，不能直接从前端调后端。推荐位的展示要接入AB实验平台，按用户分组决定展示哪种策略。推荐数据的预加载要和现有的性能策略协调，不能让首页LCP指标回退。推荐模块的错误处理要和全局的错误边界统一，不能一个模块白屏影响整个页面。

这些不是"代码生成"问题，是"系统集成"问题。AI可以帮你生成一个完美的推荐组件，但它不知道你的BFF鉴权怎么走、AB平台怎么接、性能预算是多少、错误边界怎么设计。

Vibe Coding解决的是代码"从0到1"的问题。但生产环境的工作，大量是"从1到N"的集成问题。这个鸿沟，现在的AI还帮不了你跨过去。

在金融场景里，Vibe Coding不是效率问题，是合规问题

在消费级应用里，Vibe Coding出点问题可能是UI错位、功能异常。在金融场景里，风险是实实在在的合规和资金问题。

金融系统有几个AI很难自动处理的特性。

精度不是约等于。 理财产品的收益计算有严格的精度要求。AI在生成计算代码时，经常出现浮点数精度丢失的问题。0.01元的差异在消费级应用里无所谓，在金融系统里就是账不平，就是客户投诉，就是合规审查项。

合规不是可选项。 AI生成的代码不会自动考虑反洗钱规则、客户身份识别要求、投资者适当性评估。这些不是"好习惯"级别的东西，是法律要求。一段没有合规考量的代码，即使功能完美，上线就是违规。

可审计性不是锦上添花。 金融系统的每一笔操作都要可追溯。AI生成的代码如果绕过了审计日志机制——或者更常见的情况，日志格式和现有系统不兼容——那就是合规层面的灾难。

不是金融系统不能用AI辅助编码。单元测试生成、文档编写、代码审查辅助，这些场景AI都有实实在在的价值。但Vibe Coding那种"我只管意图，AI管实现"的模式，在金融场景里本质上是不负责任的。你必须逐行审查、逐行理解、逐行确认每一段上线代码的行为。

Vibe Coding的本质是一种"信任前移"——你在还没理解代码的情况下就信任了它。金融场景里，信任需要成本，这个成本叫审计。

AI真正该用的地方

说了这么多Vibe Coding的问题，我得澄清一点：我不是反AI编程。恰恰相反，我觉得AI编程工具是这些年最实在的生产力提升之一。但工具好用和用对工具是两码事。

我观察到的是，AI在编程中最有价值的部分，恰恰和Vibe Coding相反——不是"生成你不懂的代码"，而是"帮你更快理解你已经知道的领域"。

几个AI真正提效的场景：

代码导航和上下文理解。 在一个几十万行的项目里，用AI快速定位"这个状态在哪被修改的"、"这个接口的调用方有哪些"，比你自己grep快十倍。不是让AI替你写代码，是让AI替你找代码。理解上下文这件事AI比你快，但理解之后的判断必须你自己做。

测试用例生成。 你写了核心逻辑，让AI帮你生成各种边界测试。你对逻辑的理解保证了测试方向的正确性，AI保证覆盖的全面性。这是人机协作最自然的模式——人定方向，AI补细节。

代码审查辅助。 AI在审查中的价值不是替代人，是帮人快速过滤掉格式问题、命名问题、明显的不安全调用，让你把注意力集中在架构和逻辑层面。

文档和注释生成。 给AI一段你写的代码，让它生成文档。你对代码行为的理解保证文档的准确性，AI保证表达的规范性。

注意这些场景的共同特点：人是理解者，AI是加速器。人的理解在前，AI的生成在后。这和Vibe Coding的"意图先于理解"正好反过来。

Vibe Coding不会消失，但它必须退回该待的位置

我不觉得Vibe Coding会消失。就像快速原型不会消失一样。但它需要从一个"工作方式"退回到一个"工作阶段"。

Vibe Coding最适合的阶段是探索期——需要快速验证一个想法、搭一个原型、写一个一次性脚本时，让AI替你生成代码完全没问题。这个阶段的核心目标是"看看这东西能不能跑起来"，代码质量和系统兼容性都不重要。

当代码要从原型走向生产时，Vibe Coding必须让位给更审慎的工作方式。你需要逐行审查AI生成的代码，理解每一行的意图和副作用，确认它和现有系统的兼容性。这个过程不快，但可靠。

说到底，Vibe Coding的根本问题不是AI不够强，是很多人对"编程"这件事的理解太窄了。编程不只是写代码，更不只是生成代码。编程是在一个复杂的、有历史的、有约束的系统里，精确地放置你的意图。这个过程需要理解，需要判断，需要对系统的尊重。

AI可以帮你写代码。但理解系统这件事，现在以及可预见的未来，只能靠你自己。Vibe Coding可以作为起跑的助力，但如果把助力当成了全程的动力，那跑不了多远。