VSDD：真正值得偷学的 AI 编码方法论
Source: Dev.to
Overview
今天在 Hacker News 上有一种方法论受到关注，叫做 Verified Spec‑Driven Development (VSDD)。它获得了 130 多分和数十条评论，而且这次讨论真的很有价值。我阅读了完整的规范。以下是它真正好的地方——以及快速构建者应该立即借鉴的一点。
VSDD 的核心组件
VSDD 融合了您已经熟悉的三件事：
- Spec‑Driven Development – 在编写任何代码之前先编写规范。规范是唯一的真相来源。
- Test‑Driven Development – 测试在实现之前。Red → Green → Refactor。
- Adversarial Verification – 一个独立的 AI “审阅者” 会拆解规范和代码，寻找漏洞。
顺序门
这些不是相互竞争的哲学，而是 顺序门：
- 在规范严密之前，不能进入测试阶段。
- 在测试存在之前，不能进入编码阶段。
- 在对抗性审稿人未能发现真实缺陷之前，不能发布。
Roles of Human and AI
- Human – The Architect: 提供战略愿景、领域专业知识和最终决策权。
- AI Builder: 根据规范和测试实现代码。
- AI Adversary: 作为一个高度挑剔的审稿人的第二个独立 AI 实例。
为什么先写规范很重要
先写规范的做法才是真正的洞见——它并不新鲜，只是 AI 让它变得可以强制执行。
- 当你自己写代码时，可以模糊不清，因为大脑会自行填补空白。
- 当你把任务交给 AI 代理时，模糊性是致命的：代理会自信、快速且常常错误地填补空白。
强迫自己先写一份 behavioral contract——前置条件、后置条件、边缘情况、失败模式——这不是额外负担，而是核心工作。实现过程随后几乎是机械化的。
这正是最优秀的 AI‑native 构建者实际采用的方式。他们不会输入“帮我构建一个支付系统”。他们会写三段文字，描述系统必须做什么、绝不能做什么，以及出现故障时的处理方式，然后把这些交给代理。输出质量的差异不是微小的，而是数量级的提升。
实际应用
我之前未见正式化的部分：使用一个拥有全新上下文的独立 AI 实例作为超挑剔的审稿人。
- Builder AI 了解决策背后的原因。
- Adversary AI 则没有这些信息——它只看到输出。这类似于真实的代码审查：同事只关心结果是否合理，而不在乎实现过程。
实际操作
-
使用 Claude（或其他模型）编写规范和实现。
-
将其粘贴到全新的 Gemini 会话中，并使用以下提示：
You are a hyper‑critical senior engineer. Find every flaw, ambiguity, and missing edge case. Do not be polite.
结果非常有用。对手能够捕捉到你遗漏的内容，正是因为你做出了有意但未加正当理由的选择。
完整的 VSDD 流程
完整的流程包括：
- 史诗 → 需求 → 子需求（“珠子”）
- 正式验证策略
- 属性的数学证明
它是为那些不能出现故障的生产系统交付团队而构建的。
独立创始人的建议
如果你是独立创始人正在验证一个想法，那些额外负担会致命。借鉴规范的纪律。跳过繁文缛节。
捕获大部分价值的具体步骤
- 在任何 AI 编码会话之前，写 5‑10 句，涵盖：
- 功能的作用
- 功能绝不做的事
- 三种最可能的失败模式
- 将其交给你的 AI 代理作为上下文。
- 当它生成代码时，将其粘贴到一个新的 AI 会话中，并请求最严厉的批评。
- 修复真实的问题；忽略纯理论的内容。
这些步骤大约能以 20 % 的努力 获得 80 % 的 VSDD 价值。
Closing Thoughts
VSDD 所指的——即使完整的方法论对大多数单独构建者来说过于繁重——是从“AI 能写代码吗”转向“我能否精确告诉 AI 要构建什么”。瓶颈不再是实现，而是规格说明。
在未来两年中获胜的构建者并不是提示（prompt）最好的那群人，而是对自己真正想要构建的东西思考最清晰、并能把它写得足够精确，以至于代理没有空间进行糟糕的即兴发挥的人。这种技能的价值超过任何框架。
- 为拉美的中小企业构建 AI 产品。规格优先方法： rooxai.com *