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

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

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

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

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

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

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

上周组里一个产品上线前的合规评审会上，合规专员盯着一段前端代码问了一个问题："这个收益率计算逻辑，用户在购买前看到的结果和购买后持仓页显示的结果，走的是不是同一条计算链路？"

在场的两个前端工程师面面相觑。答案是"不是"。购买前用的是推荐接口的预计算数据，持仓页用的是资产接口的实时结算数据。两条链路，两套精度处理，两组四舍五入规则。在普通业务里这根本不算事——数据来源不同，展示逻辑不同，非常自然。但在金融业务里，这意味着用户可能看到购买前年化3.52%，购买后变成3.51%。

0.01%的偏差，万亿规模下就是上亿的资金差异预期。合规专员当场拍了桌子，上线延期两周。

这个场景在互联网公司几乎不会发生。但在金融科技团队，它是日常。

金融业务的代码有两套读者

大部分工程师写代码时心里只有一个读者：运行时环境。代码能不能跑，跑得快不快，内存占不占得住——所有的优化方向都指向机器。

金融业务的代码不一样。它有两套读者：机器和审计。而且讽刺的是，审计这个读者往往比机器更难伺候。机器只要逻辑正确就行，审计要的是"逻辑正确且可追溯且可解释且可复现"。多出来的这三个"且"，才是金融科技工程真正的成本。

打开任何一个前端项目的代码，搜索 `catch`，你大概率会看到这样的画面：

```javascript
try {
await fetchData();
} catch (e) {
console.error(e);
message.error('操作失败，请稍后重试');
}
```

后端也好不到哪去：

```javascript
try {
await processOrder(orderId);
} catch (err) {
logger.error('订单处理失败', { orderId, error: err.message });
throw new BusinessException('系统异常，请重试');
}
```

这两段代码有一个共同的特质——它们让你觉得错误被"处理"了。日志打了，提示也弹了，异常也抛了，一切看起来都很体面。

但你仔细想想：用户看到"操作失败，请稍后重试"之后能做什么？重试？然后呢——再失败一次？运维看到一条"订单处理失败"的日志，能定位到什么？是库存扣减超时，还是支付回调丢失，还是风控拦截？

前后端分离之后，我们发明了一个安慰自己的概念——"接口契约"。Swagger 文档一摆，TypeScript 类型一生成，团队觉得天上地下都對齐了：字段名对齐了，类型对齐了，必填选填对齐了。然后上线第一天就出了 bug——status 为 3 的情况前端压根没处理，amount 的单位后端返回的是分前端当成了元，createTime 在后端是 UTC 前端按本地时间解析了。

没错，类型是对上了。但类型对上和意思对上之间，隔的不是一行代码，是一个认知深渊。

接口文档给了我们一种虚假的安全感

我做过很多次前后端协作的接口评审，也主持过不少次。每次的流程都差不多：后端同事打开 Swagger 或 YApi，一个字段一个字段地过，前端同事点头说"收到"。大家都很认真，评审记录也写了，看起来协作很顺畅。

但评审过程有个微妙的问题——我们在确认的是"形状"，不是"语义"。

什么叫形状？`{ orderId: string, status: number, amount: number }` 这就是形状。字段名有了，类型有了，看起来很完整。但这句话里藏了多少没说清楚的东西？