{
  "title": "Vibe Coding 的下一个范式：从「需求优先」到「契约优先」",
  "url": "https://miaok.ong/posts/contract-first-vibe-coding-paradigm/",
  "date": "2026-06-20T00:00:00Z",
  "lastmod": "2026-06-20T00:00:00Z",
  "type": "posts",
  "kind": "page",
  "language": "zh",
  "description": "\u003ch3\u003e500 行的诅咒\u003c/h3\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e不知道你是否有过这种体验：打开 Cursor 或者 Claude Code，三句话描述需求，AI 刷刷刷生成了几百行代码。功能跑起来了，你很满意。继续加功能，再让 AI 改，再改……\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e到第五轮对话的时候，你发现不对了。AI 开始「忘记」之前约定好的接口格式。一个参数名莫名其妙地变了。一个原本正常的函数被重构出了三个彼此冲突的版本。你开始花越来越多的时间\u003cstrong\u003e读代码\u003c/strong\u003e——不是 review，是在找 bug。更糟糕的是，这些 bug 并非逻辑错误，而是 \u003cstrong\u003eAI 在不同对话轮次之间产生了不一致\u003c/strong\u003e。\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e这就是「500 行的诅咒」：vibe coding 的魅力在项目复杂度的\u003cstrong\u003e线性增长\u003c/strong\u003e面前，呈现\u003cstrong\u003e断崖式衰减\u003c/strong\u003e。\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003ch3\u003e安全工程师的顿悟\u003c/h3\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e@Pluvio9yte 最近的一篇深度总结把这个洞察讲透了。他原是一名安全工程师，后来 all-in 全栈开发——每天大量使用 AI 编程工具。\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e他的核心洞察很反直觉：\u003cstrong\u003eVibe Coding 的最佳实践，既不是「需求优先」，也不是「代码优先」，而是「契约优先」。\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e为什么？因为「需求优先」的问题是——需求文档写出来后，AI 并不会天然遵守。它在每一轮对话中都会重新「理解」需求，而理解的结果可能每次都略有不同。「代码优先」的问题更直接：当代码本身就是唯一真相来源时，AI 的每次修改都可能在局部最优的前提下破坏全局一致性。\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e他基于 OpenSpec 搭了一套方法论：\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cblockquote\u003e1. \u003cstrong\u003e先定接口契约\u003c/strong\u003e——输入、输出、副作用、不变量，必须写在代码之前\u003cbr\u003e2. \u003cstrong\u003e契约成为人和 AI 共同的 single source of truth\u003c/strong\u003e——所有对话上下文都以契约为锚\u003cbr\u003e3. \u003cstrong\u003espec 漂移在开发阶段就被捕获\u003c/strong\u003e——而不是等到上线靠用户帮你发现\u003c/blockquote\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e这套思路最大的价值在于：它把「容易漂移的上下文」外化成了一个稳定的参照物。人对它有充分理解，AI 对它也有明确的约束。\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003ch3\u003e工具侧正在发生的事\u003c/h3\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e如果你关注各大 AI 编码平台最近一个月的更新，会发现一个共同趋势。\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eClaude Code Artifacts：解决协作黑洞。\u003c/strong\u003e过去 AI 编程成果「只有操作者自己能看到」。Claude Code 刚推了 Artifacts 功能——把 AI 编程过程中的产出（调试数据、架构图、PR 走查结果）生成可实时分享的交互式网页。但关键在于：这功能起作用的前提是，有结构化的东西可以分享。如果你的 AI 代码本身就是一团 hash，Artifacts 也救不了你。\u003c/p\u003e",
  "keywords": null,
  "tags": ["Vibe Coding","AI Development","Software Engineering","Contract First","OpenSpec","Claude Code","Codex"],
  "categories": ["Engineering"],
  "author": "孔淼",
  "image": "https://miaok.ong/images/avatar.jpg",
  "content": "\u003ch3\u003e500 行的诅咒\u003c/h3\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e不知道你是否有过这种体验：打开 Cursor 或者 Claude Code，三句话描述需求，AI 刷刷刷生成了几百行代码。功能跑起来了，你很满意。继续加功能，再让 AI 改，再改……\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e到第五轮对话的时候，你发现不对了。AI 开始「忘记」之前约定好的接口格式。一个参数名莫名其妙地变了。一个原本正常的函数被重构出了三个彼此冲突的版本。你开始花越来越多的时间\u003cstrong\u003e读代码\u003c/strong\u003e——不是 review，是在找 bug。更糟糕的是，这些 bug 并非逻辑错误，而是 \u003cstrong\u003eAI 在不同对话轮次之间产生了不一致\u003c/strong\u003e。\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e这就是「500 行的诅咒」：vibe coding 的魅力在项目复杂度的\u003cstrong\u003e线性增长\u003c/strong\u003e面前，呈现\u003cstrong\u003e断崖式衰减\u003c/strong\u003e。\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003ch3\u003e安全工程师的顿悟\u003c/h3\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e@Pluvio9yte 最近的一篇深度总结把这个洞察讲透了。他原是一名安全工程师，后来 all-in 全栈开发——每天大量使用 AI 编程工具。\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e他的核心洞察很反直觉：\u003cstrong\u003eVibe Coding 的最佳实践，既不是「需求优先」，也不是「代码优先」，而是「契约优先」。\u003c/strong\u003e\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e为什么？因为「需求优先」的问题是——需求文档写出来后，AI 并不会天然遵守。它在每一轮对话中都会重新「理解」需求，而理解的结果可能每次都略有不同。「代码优先」的问题更直接：当代码本身就是唯一真相来源时，AI 的每次修改都可能在局部最优的前提下破坏全局一致性。\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e他基于 OpenSpec 搭了一套方法论：\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cblockquote\u003e1. \u003cstrong\u003e先定接口契约\u003c/strong\u003e——输入、输出、副作用、不变量，必须写在代码之前\u003cbr\u003e2. \u003cstrong\u003e契约成为人和 AI 共同的 single source of truth\u003c/strong\u003e——所有对话上下文都以契约为锚\u003cbr\u003e3. \u003cstrong\u003espec 漂移在开发阶段就被捕获\u003c/strong\u003e——而不是等到上线靠用户帮你发现\u003c/blockquote\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e这套思路最大的价值在于：它把「容易漂移的上下文」外化成了一个稳定的参照物。人对它有充分理解，AI 对它也有明确的约束。\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003ch3\u003e工具侧正在发生的事\u003c/h3\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e如果你关注各大 AI 编码平台最近一个月的更新，会发现一个共同趋势。\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eClaude Code Artifacts：解决协作黑洞。\u003c/strong\u003e过去 AI 编程成果「只有操作者自己能看到」。Claude Code 刚推了 Artifacts 功能——把 AI 编程过程中的产出（调试数据、架构图、PR 走查结果）生成可实时分享的交互式网页。但关键在于：这功能起作用的前提是，有结构化的东西可以分享。如果你的 AI 代码本身就是一团 hash，Artifacts 也救不了你。\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eOpenAI Codex Record \u0026 Replay。\u003c/strong\u003e6 月 18 日上线的新功能，路径是：你做一遍，AI 看一遍，然后它自动把这段工作流编译成一个可复用的 Skill。本质上是一种\u003cstrong\u003e行为契约\u003c/strong\u003e——你演示的不是「怎么写代码」，而是「事情应该怎么做」。\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e\u003cstrong\u003eLoop Engineering。\u003c/strong\u003e提出让 AI 代理通过循环式开发流程自己写、测、改代码。但这套机制能跑起来的前提，不是什么先进的 prompt engineering，而是\u003cstrong\u003e有稳定的接口契约作为锚点\u003c/strong\u003e。没有契约的自主代理，就像没有 GPS 的无人机。\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003ch3\u003e为什么是现在？\u003c/h3\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e三年前，开发者还在争论「写 spec 到底有没有用」。今天，这个问题已经彻底反过来了。在 AI-first 的工作流里，spec 不再是一份「写给人的说明文档」，它变成了一个\u003cstrong\u003e运行时制品\u003c/strong\u003e——人和 AI 都在持续引用它、对照它、依据它做决策。\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cblockquote\u003e\u003cstrong\u003eSpec 本身就是产品。代码只是渲染出来的产物。\u003c/strong\u003e\u003c/blockquote\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e这个范式反转有三个驱动力：\u003cstrong\u003e对话上下文的不可靠性\u003c/strong\u003e——AI 在长对话中的「记忆衰减」是结构性缺陷，契约是抗衰减最有效的外挂记忆；\u003cstrong\u003e多智能体协作的必然需求\u003c/strong\u003e——当多个 AI 代理协同工作时，没有接口契约，它们的对话会比人类之间更灾难；\u003cstrong\u003e自动化程度的提升\u003c/strong\u003e——Codex Record \u0026 Replay 这类工具意味着 AI 正从「被动响应指令」走向「主动执行流程」，没有契约定义边界，自动化就是一场赌博。\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003ch3\u003e落地建议\u003c/h3\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e如果你在使用 AI 做正经项目（而不是玩玩具 Demo），以下四条可以作为起点：\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cblockquote\u003e• \u003cstrong\u003e接口写在实现之前\u003c/strong\u003e——哪怕只是一段注释，定义好输入输出格式\u003cbr\u003e• \u003cstrong\u003e契约和代码一起版本管理\u003c/strong\u003e——放在同一个 repo 里，每次修改契约要有对应的 commit\u003cbr\u003e• \u003cstrong\u003e把 spec 漂移当作 bug 处理\u003c/strong\u003e——不要让「差不多就行」成为习惯\u003cbr\u003e• \u003cstrong\u003eAI 生成脚手架，人守住契约设计\u003c/strong\u003e——架构决策（尤其是接口设计）目前仍然是人类最不可替代的环节\u003c/blockquote\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp\u003e能想清楚这层关系的开发者，5 倍生产力是真实可达的。没想清楚的，那 5 倍大概都花在 debug 上了。\u003c/p\u003e\u003cp\u003e\n\u003c/p\u003e\u003cp style=\"color: #999; font-size: 0.85rem; margin-top: 2rem;\"\u003e2026.06.20 · 基于 Pluvio9yte 的 Contract First 方法论、Claude Code Artifacts、OpenAI Codex Record \u0026 Replay 及 Loop Engineering 的综合观察\u003c/p\u003e\n",
  "wordCount": 157,
  "readingTime": 1,
  "tableOfContents": "\u003cnav id=\"TableOfContents\"\u003e\u003c/nav\u003e",
  "isDraft": false
}