Vibe Coding 与 AI 驱动开发：契约问题（以及 GS‑TDD）
Source: Dev.to
Vibe coding vs. AI‑driven development
大多数当前的 AI 辅助编码其实只是……vibe。
你提出一个功能需求，得到一个看似合理的 diff，代码能够编译，你的多巴胺飙升，结果两天后生产环境开始上演“解释性舞蹈”。
这种失败模式有个名字：vibe coding。
我想要的则是 AI‑driven development。无论你称之为 AI‑Assisted Engineering，还是（在我的母语丹麦语中）AI‑drevet udvikling，目标都是一样的：一种工作流，让 AI 每天帮助你设计和实现软件，而人类则对正确性、安全性和运维承担全部责任。
区别不在于“使用哪种模型”。关键在于 contracts（契约）。
Vibe coding 是信任问题
Vibe coding 发生在我们把生成的代码当作“可能没问题”时，原因是：
- 它 看起来 合理
- 它使用了熟悉的模式
- 它通过了快速的冒烟测试
- 已经很晚了，我们想回家
AI 善于生成看似合理的代码。但看似合理的代码并不等同于正确的代码。
如果你的工作流是 生成 → 部署，那你并没有在做 AI‑driven development，而是在进行概率性部署。
AI‑driven development 是契约问题
可靠的做法很简单，但需要纪律：
- 定义契约 (人类)
- 让 AI 在该契约范围内工作 (机器)
- 像成年人一样验证结果 (人类 + CI)
“契约”可以是接受测试、单元测试、不变式、模式、类型，或上述全部。测试是最通用的契约，因为它们既编码了行为，又能大声报错。
无聊的循环：Red → Gold → Refactor (GS‑TDD)
要将其付诸实践，我使用一种我称为 Gold Standard TDD (GS‑TDD) 的 TDD 变体。它将经典的 Red–Green–Refactor 循环演进为 Red–Gold–Refactor。
| 阶段 | 你要做的事 |
|---|---|
| Red | 编写（或生成）一个失败的测试套件，以定义行为。理想情况下采用 BDD 风格，使意图和边界情况明确。 |
| Gold | 指示 AI 在第一次提交时生成 Gold Standard 实现，该实现应 从设计上面向生产。这意味着： • 安全感知的默认设置 • 可维护的结构 • 可靠的错误处理和边界 • 乏味、标准的架构 • 不做 MVP，也不做原型 |
| Refactor | 在保持行为不变的前提下安全地改进内部实现。 |
关键转变： GS‑TDD 用 “Gold Standard” 取代了 “最小的 Green”，因为 AI 让我们可以跳过冗余的样板阶段。你的测试（契约）让 AI 保持诚实，而 “Gold” 提示则确保架构保持整洁。
想更深入了解该方法，请查阅我的研究笔记 GS‑TDD。
一个小示例（工作流）
说你正在添加一条规则：“用户不能创建超过 3 个 API 密钥。”
Red – 首先编写合约
it("limits API keys per user", async () => {
const user = await seedUser();
await createKey(user);
await createKey(user);
await createKey(user);
// This defines the contract: behavior AND error shape
await expect(createKey(user)).rejects.toThrow("API key limit reached");
});现在测试套件是老板。
Gold – 在约束条件下提示 AI 进行面向生产的首次实现
“实现此功能。事务性地强制限制以避免竞争条件，使用我们的标准领域错误类型，并在触发限制时添加结构化日志行。”
“Gold” 代码在首次运行时可能仍会有一两个测试失败——没关系。继续在合约内部调试，直到全部通过。
Refactor – 清理命名和文件结构
AI 可以帮助完成所有步骤——但 合约决定了允许的行为。
The Boring AI Checklist (8 rules I actually follow)
- Define the contract – Tests describe what must remain true.
- Verify, don’t trust – Run tests, lint, and build locally.
- Prefer small diffs – AI hallucinates more in large contexts; keep changes reviewable.
- Keep prompts in the diff – The “why” belongs in PRs/docs, not in your chat history.
- Review like it’s human code – Check naming, invariants, and boundaries.
- Guard risky edges – Auth, data loss, security headers, rate limits.
- Watch production – Logs/metrics/alerts confirm the change behaved.
- Rollback is a feature – Know how you undo the change before you ship.
That’s it. No mysticism. Just boring verification at high speed.
“但这不就是 TDD 吗？”
某种程度上——但动机有所不同。
经典的 TDD 帮助人们思考清晰、设计良好。将 AI 纳入其中后，测试也会成为 安全护栏，阻止看似合理的胡说八道进入主分支。
如果你的 AI 工作流没有契约，那么你的交付流水线基本上就是一台有时会中奖的老虎机。
阅读完整系列
我正在我的网站上记录整个方法论（以及“Ward”概念）。
编码的未来是乏味的：小的差异、明确的契约以及更少的生产意外。这正是值得发布的未来。