Vibe Coding 的蜜月期结束了：AI 开发正在从"写代码"进化到"写契约"

自然语言描述需求 → 等 AI 吐代码 → 跑一下，居然能用。这种体验太爽了。但当你把这种模式带入超过 3 天、超过 3 个文件的真实项目时，爽感会在某个深夜崩溃：这个数为什么是 0？这个页面数据是哪来的？为什么 mock 数据被当成了生产结果？

一、Vibe Coding 的临界点 链接到标题

2026 年 6 月，73% 的开发团队在日常工作中使用 AI 编码代理¹。Codex 推出了跨设备任务迁移（Handoff）和操作复刻（Record & Replay），Claude Code 上线了可视化协作的 Artifacts 功能，GLM-5.2 在编程基准上逼近顶级闭源模型。

工具栈在飞速成熟，但一个更根本的问题浮出水面：开发范式没有跟上。

Vibe Coding 这个从 2025 年流行起来的词，描述的是一种"凭感觉"的 AI 辅助开发方式：用自然语言描述你想做什么，让 AI 写代码，跑通就算完。它的核心体验是快感驱动——省去了查文档、设计接口、写测试的"枯燥"环节，直达"看到效果"的多巴胺。

问题也在这里。Vibe Coding 的验证终点是"页面能跑"。但在 AI 的加持下，一个数据全部伪造的页面也能跑得很快。

X 上开发者 @dotey 系统性地回应了这个问题：“需求分析、系统设计、代码审查和灰度发布在 AI 时代非但不能省，反而更重要。“另一位从安全从业者转向全栈开发的 @Pluvio9yte 则提出了一个更精准的主张——Contract First。不是需求文档驱动，也不是纯粹代码驱动，而是先定义接口、数据模型和验收标准这些"契约”，再把它们作为人和 AI 之间稳定的参照物。

这个话题今天在技术社区爆发，不是偶然的。它标志着 AI 辅助开发正在经历从"能用"到"可靠"的范式迁移。

二、一个真实翻车案例：Demo 惊艳、生产致命 链接到标题

我们内部有一个 AI 辅助开发项目。目标是用 AI Agent 完成一个投资看板 Web App：自选股管理、日报查看、研究库搜索、方法论浏览，最终做成 PWA，手机可用。

Phase 2.5 的技术 Spike 结束后，团队看到了：

• 一个漂亮的首页
• 能登录的用户系统
• 能展示自选股列表的页面
• 日报详情页
• PWA 可安装，手机端打开流畅

按照直觉判断，这应该是"完成了 Spike 阶段”。代码提交了，页面能跑，视觉方向也确定了。

但当我们进行独立 QA 审查时，从代码层面发现了 7 个问题：

1. 盈亏永远显示 --：WatchlistView.vue 中盈亏字段硬编码，没有接 cost_price 和实时行情
2. 首页"最近文章"是固定卡片：HomeView.vue 的最近文章写死了 3 篇样例，代码注释写着"下一阶段接入 knowledge_base"
3. 日报摘要是固定文案：ReportView.vue 的 summary-card 不来自 API 真实数据
4. API 失败时静默展示 mock 行情：portfolio.ts 内置了 fallbackWatchlist 和 fallbackQuotes，一旦后端不可用，前端就展示假数据——和真实数据一模一样
5. 自选股只能看不能改：后端只实现了 3 个 GET 接口，没有 POST/PATCH/DELETE
6. 研究库和方法论页面完全不存在
7. 部署方案零落地：Nginx/systemd 在文档里写了，但实际只有裸跑 uvicorn

这 7 个问题没有一个是隐蔽的 Bug。它们就在代码里，打开文件就能看到。但它们在过程中全部被标记为"已完成"。

为什么？

三、不是 AI 不够强，是契约缺位 链接到标题

复盘结论很清楚：问题不出在 LLM 的能力上，而出在人和 AI 之间的契约层。

在 Vibe Coding 模式下，开发者和 AI 的交互只有两层：

• 输入层：自然语言需求描述
• 输出层：跑通即确认

两者的中间地带是真空的。没有接口契约，没有数据契约，没有验收契约。结果就是：AI 按照"让页面看起来能用"的目标优化，而那个目标和"让项目真正可交付"是两回事。

更可怕的是，在没有明确定义 DoD（Definition of Done）的场景中，mock、硬编码和假数据会通过图灵测试——它们看起来和真实数据一样，甚至在 Demo 中表现完美。直到用户真正使用，或者被另一个 reviewer 从代码层审查，才会露馅。

这就是为什么 Contract First 需要成为 AI 开发的新基座。

Contract First 的三个维度 链接到标题

1. 接口契约：API 先于实现

在让 AI 写代码之前，先定义好 API 的入参、出参、错误态。不是"做一个自选股页面"，而是：

GET /api/watchlist → { tickers: [{symbol, name, shares, cost_price, current_price, pnl}] }
POST /api/watchlist → body: {symbol, shares, cost_price} → 201
PATCH /api/watchlist/{ticker} → body: {shares?, cost_price?} → 200
DELETE /api/watchlist/{ticker} → 204
错误态: 401 | 404 | 422

有了这层契约，AI 生成代码时就有了硬边界。前端和后端不会各自漂移，reviewer 也有明确的对照标准。

2. 数据契约：每个 UI 字段必须追溯数据源

这是反 mock 的核心武器。为每个页面字段建立数据源映射：

reviewer 拿着这张表审查，mock 和硬编码无处遁形。

3. 验收契约：DoD + 证据包 + 反 mock 规则

每个阶段必须有独立 DoD，不能只靠"看起来完成了"。

Spike 阶段可以是轻量的：允许占位、允许 dev-only mock。但必须满足两条硬性规则：

• 所有 mock/placeholder 必须集中登记为技术债
• 不允许静默 fallback mock 冒充真实数据

进入 MVP 阶段后，规则升级为 P0 阻断：

• 生产路径代码不得使用未标注的 fallback mock
• API 失败时必须显示错误态，不自动展示 mock
• 所有页面业务内容必须来自真实数据源

加上阶段 Evidence Pack（需求覆盖矩阵、API 覆盖表、数据源映射、mock 扫描结果、reviewer PASS/REVISE/BLOCK 结论），final-gate 就不再是"看报告文案"，而是"审证据厚度"。

四、Contract 落地的操作指南 链接到标题

如果你已经开始在日常开发中使用 AI 代理，以下是可以立即套用的操作清单：

Step 1：在每个任务启动前，先写需求矩阵 链接到标题

不要直接跟 AI 说"做个用户管理页面"。先画表：

这张表就是你和 AI 之间的稳定契约。无论 AI 怎么自由发挥，review 时只需要逐行对照这张表。

Step 2：建立反 mock 清单 链接到标题

在代码 review 环节固定执行 grep 扫描：

• fallback
• mock
• sample
• placeholder
• 固定中文业务文案（如"今日组合观察"“市场整体回暖”）

每一条出现都必须有合理解释，且登记为技术债或由独立 QA 标记 BLOCK。

Step 3：区分 Spike 和真实交付的阶段口径 链接到标题

Spike 的价值是快，但快必须换来可见风险，不是隐藏风险。每次 Spike 结束强制输出欠债登记：

Step 4：Reviewer 必须读代码，不能只看页面 链接到标题

AI 时代的验收如果只停留在"打开页面看一眼"，那等于没有验收。因为 AI 生成的页面可能在视觉上完美无缺，而数据完全来自一个 3 行 mock 函数。

QA reviewer 的最低审查深度应该是：

• 抽查关键前端组件代码
• 对照 API 覆盖率表
• 执行 mock/hardcode grep
• 测试错误态和空态

五、同一案例，Contract First 会拦住什么？ 链接到标题

回到上述项目。如果 Phase 2.5 Spike 按照 Contract First 执行，哪些问题会在提交前被拦住？

核心差异在于：Vibe Coding 下，开发者的自检标准是"它看起来对吗"，而 AI 在视觉上几乎不会出错。Contract First 下，自检标准是"它符合契约吗"，mock 和硬编码在对照矩阵的那一刻就暴露了。

六、AI 时代的软件工程常识在回归 链接到标题

这一波讨论中，我最受触动的是 @dotey 的一句话：“需求分析、系统设计、代码审查和灰度发布在 AI 时代非但不能省，反而更重要。”

这句话的逆直觉之处在于：AI 让写代码变快了，于是我们天然想省掉"不是写代码"的环节。但恰恰是这些环节在 AI 加持下变成了最短的短板——因为你可能一天产出 3000 行代码，而 2000 行是基于 mock 数据的假页面。

Contract First 不是让开发变慢。它是在 AI 的速度之上，加了一层防撞栏。没有防撞栏，越快的车越危险。

更有趣的是，在同一天的技术讨论中，几位开发者不约而同地提到了类似的观察：@AI_Jasonyu 发现 PP-OCRv6 这种 1.5MB 的极小模型在特定垂直任务上反超了 GPT-5.5，因为"边界清晰的契约让精巧的小模型找到了决定性优势"；@zhixianio 在端侧模型测试中反复强调"定义好问题边界"比"用更强的模型"更重要。

这些看似不相关的讨论指向同一个方向：在系统复杂度面前，契约比能力更重要。不是一个更强的 AI 就能解决 mock 问题——只有定义好什么是"真正的完成"，问题才开始被解决。

如果你正在用 AI 辅助开发，今天的建议很简单：下一次打开 Codex 或 Cursor 之前，先花 10 分钟画一张需求矩阵。那 10 分钟会在 review 时帮你省下 10 小时。

2026-06-21 · 公开发布版