Vibe Coding虽然爽，但代码总得有个"窝"吧

写代码快、懂代码慢

说实话，vibe coding 真的太爽了。你说想要什么，代码就冒出来了。Pipeline 跑起来，功能跑通了。这种速度以前想都不敢想，确实让人激动。

但是conference上演示的时候，没人会告诉你：半年之后 pipeline 挂了、需求变了、新工程师来了——那时候这些理解都去哪儿了？

答案通常是：哪儿都没有。

为什么上下文这么脆弱

vibe coding 的时候，你会往 prompt 里塞一大堆上下文。业务规则、假设条件、边界情况、下游依赖、为什么选 A 方案而不是 B 方案……全塞进对话里，生成代码，然后就……像早上的雾一样散了。

代码还在。推理过程没了。

这不是简单的文档问题，是 AI 辅助开发模式下的系统性问题。我们以前所未有的速度生成系统，同时却在丢失那些让系统可以维护、可以调试、可以迭代的集体知识。

做数据平台的，这个问题更严重。现代化的数据架构不是单个应用，是一整个生态。 ingestion 层、transformation 逻辑、orchestration 框架、semantic 层、serving API、ML pipeline，每个组件只知道通过脆弱的隐式契约和其他组件打交道。

数据工程师的痛，为啥格外深

如果你在做一个 CRUD 应用，vibe coding 的记忆问题顶多算烦人。但如果你在维护企业级数据平台，这可能就成了生死攸关的问题。

数据工程本质就是协调。业务逻辑在各个 transformation 之间要保持一致。Schema 变了，下游的影响有好有坏。Validation 规则保护着数据质量。Orchestration 的依赖关系决定着成功还是失败。

当 AI 从 prompt 里生成这些逻辑时，所有这些协调知识都还是人的。它活在资深工程师的脑子里。藏在 2023 年的 Slack 聊天记录里。埋在一些没人更新的 Notion 文档里。

平台本身根本不记得自己为什么长成这样。

另一种思路

如果规范本身就能成为系统的一部分呢？

Spec-driven development 把剧本给翻过来了。与其 prompt 生成代码、然后再往上堆文档、推理过程和集体记忆，不如让规范成为真相的唯一来源——可执行、可版本化、可持久化。

你的业务规则不只是"代码做了什么"，它们是明确的、可测试的契约，可以跨越任何一次对话而存在。你的 orchestration 逻辑不只是"什么时候跑什么"，它是版本化的定义，人和 AI agent 都能一致地理解。

这不是要替换 AI 生成，而是要给 AI 生成的系统补上一直缺的东西：一个稳定可持久运营知识的基础。

说点实在的

得说清楚：spec-driven development 不是银弹。它增加了前期投入。它要求团队在生成之前就明确思考需求。它需要纪律，而这有时候和 vibe coding 的速度优势冲突。

但关键是——如果你在做的系统是要长期运行的、要迭代的、要被换了一茬又一茬的团队维护的，那前期这点投入绝对值。

最好的时机是六个月前。其次是现在。

最后

Vibe coding 是实现的强力倍增器。但实现只是软件生命周期的其中一环。维护、迭代、调试、知识传递——系统大部分时间都耗在这些地方。

如果我们越来越依赖 AI 来生成越来越复杂的系统，我们也得同样认真地思考：这些系统怎么保留自己的理解能力。

AI 辅助开发的未来，不只是生成得更快。是生成出来的系统能解释自己。