Vibe Coding 的下一个范式：从「需求优先」到「契约优先」

500 行的诅咒

不知道你是否有过这种体验：打开 Cursor 或者 Claude Code，三句话描述需求，AI 刷刷刷生成了几百行代码。功能跑起来了，你很满意。继续加功能，再让 AI 改，再改……

到第五轮对话的时候，你发现不对了。AI 开始「忘记」之前约定好的接口格式。一个参数名莫名其妙地变了。一个原本正常的函数被重构出了三个彼此冲突的版本。你开始花越来越多的时间读代码——不是 review，是在找 bug。更糟糕的是，这些 bug 并非逻辑错误，而是 AI 在不同对话轮次之间产生了不一致。

这就是「500 行的诅咒」：vibe coding 的魅力在项目复杂度的线性增长面前，呈现断崖式衰减。

安全工程师的顿悟

@Pluvio9yte 最近的一篇深度总结把这个洞察讲透了。他原是一名安全工程师，后来 all-in 全栈开发——每天大量使用 AI 编程工具。

他的核心洞察很反直觉：Vibe Coding 的最佳实践，既不是「需求优先」，也不是「代码优先」，而是「契约优先」。

为什么？因为「需求优先」的问题是——需求文档写出来后，AI 并不会天然遵守。它在每一轮对话中都会重新「理解」需求，而理解的结果可能每次都略有不同。「代码优先」的问题更直接：当代码本身就是唯一真相来源时，AI 的每次修改都可能在局部最优的前提下破坏全局一致性。

他基于 OpenSpec 搭了一套方法论：

1. 先定接口契约——输入、输出、副作用、不变量，必须写在代码之前
2. 契约成为人和 AI 共同的 single source of truth——所有对话上下文都以契约为锚
3. spec 漂移在开发阶段就被捕获——而不是等到上线靠用户帮你发现

这套思路最大的价值在于：它把「容易漂移的上下文」外化成了一个稳定的参照物。人对它有充分理解，AI 对它也有明确的约束。

工具侧正在发生的事

如果你关注各大 AI 编码平台最近一个月的更新，会发现一个共同趋势。

Claude Code Artifacts：解决协作黑洞。过去 AI 编程成果「只有操作者自己能看到」。Claude Code 刚推了 Artifacts 功能——把 AI 编程过程中的产出（调试数据、架构图、PR 走查结果）生成可实时分享的交互式网页。但关键在于：这功能起作用的前提是，有结构化的东西可以分享。如果你的 AI 代码本身就是一团 hash，Artifacts 也救不了你。

OpenAI Codex Record & Replay。6 月 18 日上线的新功能，路径是：你做一遍，AI 看一遍，然后它自动把这段工作流编译成一个可复用的 Skill。本质上是一种行为契约——你演示的不是「怎么写代码」，而是「事情应该怎么做」。

Loop Engineering。提出让 AI 代理通过循环式开发流程自己写、测、改代码。但这套机制能跑起来的前提，不是什么先进的 prompt engineering，而是有稳定的接口契约作为锚点。没有契约的自主代理，就像没有 GPS 的无人机。

为什么是现在？

三年前，开发者还在争论「写 spec 到底有没有用」。今天，这个问题已经彻底反过来了。在 AI-first 的工作流里，spec 不再是一份「写给人的说明文档」，它变成了一个运行时制品——人和 AI 都在持续引用它、对照它、依据它做决策。

Spec 本身就是产品。代码只是渲染出来的产物。

这个范式反转有三个驱动力：对话上下文的不可靠性——AI 在长对话中的「记忆衰减」是结构性缺陷，契约是抗衰减最有效的外挂记忆；多智能体协作的必然需求——当多个 AI 代理协同工作时，没有接口契约，它们的对话会比人类之间更灾难；自动化程度的提升——Codex Record & Replay 这类工具意味着 AI 正从「被动响应指令」走向「主动执行流程」，没有契约定义边界，自动化就是一场赌博。

落地建议

如果你在使用 AI 做正经项目（而不是玩玩具 Demo），以下四条可以作为起点：

• 接口写在实现之前——哪怕只是一段注释，定义好输入输出格式
• 契约和代码一起版本管理——放在同一个 repo 里，每次修改契约要有对应的 commit
• 把 spec 漂移当作 bug 处理——不要让「差不多就行」成为习惯
• AI 生成脚手架，人守住契约设计——架构决策（尤其是接口设计）目前仍然是人类最不可替代的环节

能想清楚这层关系的开发者，5 倍生产力是真实可达的。没想清楚的，那 5 倍大概都花在 debug 上了。

2026.06.20 · 基于 Pluvio9yte 的 Contract First 方法论、Claude Code Artifacts、OpenAI Codex Record & Replay 及 Loop Engineering 的综合观察