那个深夜的崩溃
凌晨两点，开发工程师小李终于通过了最后一个单元测试。他长舒一口气，提交了PR。三天后，产品经理在群里@他：“功能开发没问题，但用户根本不使用这个入口，点击率低于0.3%。”
这并非个例。在研发圈子里，类似的悲剧每天都在上演——代码逻辑正确，产品却无人问津。而进入2025年之后，另一个更隐秘的危机正在扩散：AI生成的代码看似完美无瑕，实际运行却漏洞百出。ICSE 2026的一篇综述研究揭示了一个值得警惕的数据：45%的AI生成代码包含安全漏洞，且AI引入的漏洞数量是人类编写代码的2.74倍。2025年初Karpathy提出的“Vibe Coding”概念，让大量开发者在追求速度的同时，不自觉地滑向质量失控的深渊。
传统开发流程就像一条精心铺设的轨道：需求文档→技术方案→编码→测试→上线。一切按规格执行，但没人能保证终点是用户真正需要的地方，更无法确保AI生成的代码不会在深夜带来麻烦。
于是，一群工程师开始反思：如果“按规格交付”不再是唯一真理，那什么才是真正的成功？答案之一，就是近年逐渐进入视野的EDD——一种以“验证”和“反馈”为核心的工程哲学。
EDD的“三副面孔”
EDD并非某个标准化组织的注册商标，而更像一个“理念家族”。目前业界讨论最多的，主要有三种含义：
1. 评估驱动开发（Eval-Driven Development）
这是AI时代最热门的EDD分支之一。其核心思想是：你不应该写完代码再考虑测试，而应该先定义“什么算对”，再让代码去“应试”。
想象一下，一个AI模型就像聪明但有些“飘”的学生。它读了很多书，口若悬河，但偶尔胡说八道。传统开发方式好比家长盯着孩子写作业，写一行看一行，既累又慢。评估驱动开发则像建立了一条全自动的质检流水线：首先把所有可能考到的题型和验收标准输入进去，学生每产出一个结果就立即检测、打分、反馈。AI写代码也是同理——先编写评估集（eval set），再让模型反复迭代，直到稳定“达标”为止。
这里有一个更深层的转变。2026年业界逐渐形成共识：评估集本身就是规格（Evals as Specifications）。在LLM开发中，评估集不仅是测试工具，更是产品意图的可执行表达、回归防护的基线以及模型迭代的度量衡。你的核心资产不再是prompts或模型参数，而是一套可执行、可量化、可演化的评估体系。代码是否正确，不再依赖人眼审查，只需运行一次eval即可知晓。
2. 试验驱动开发（Experiment-Driven Development）
如果说评估驱动开发关心的是“代码是否正确”，那么试验驱动开发关注的是“产品是否值得”。
它把软件工程变成了一门实验科学。你不再先写一份详尽的需求规格书，而是先提出一个假设：“如果我把按钮从蓝色改成橙色，转化率会提升5%。”然后快速搭建最小可行实验，上线A/B测试，用真实用户数据验证假设。对了就扩大，错了就放弃。
这很像现代医学的临床试验。你不会因为“理论上这个药有效”就大规模生产，而是先做小规模双盲实验，用数据说话。
当然，试验驱动开发也有其“暗面”。样本量不足的A/B测试可能把噪声当作信号；同时测试10个指标，至少有一个会“显著”，这是典型的p-hacking；提升短期点击率的改动可能损害长期留存。试验驱动不是“跑个测试就完事”，它要求严谨的实验设计、预设的停止规则，以及对统计陷阱的清醒认知。
3. 事件驱动开发（Event-Driven Development）
这个EDD与前两个不在同一维度。它不是方法论，而是一种架构风格：系统通过“事件”来解耦各个模块，比如用户下单后触发库存扣减、物流通知、积分发放等一系列连锁反应。
如果说前两个EDD解决的是“怎么做出正确的东西”，那么事件驱动开发解决的是“系统如何灵活地响应世界”。它是工程实现层面的基础设施，而非产品决策层面的指南针。
SDD是谁？EDD又“进化”了什么？
要理解EDD的价值，得先认识它的“老对手”——SDD（Specification-Driven Development，规格驱动开发）。
SDD是工业时代软件工程的基石。其逻辑很朴素：先把需求写成无歧义的规格文档，再按图施工，最后验收。就好比盖楼前先画好施工图，工人按图砌砖。在需求稳定、技术成熟的场景里，SDD极其高效——它保证了可预测性、可审计性和大规模协作的可行性。
但SDD有一个致命前提：你必须在开工前就知道“对”的答案是什么。在AI时代，这个前提正在崩塌。
有趣的是，SDD本身也在进化。2025-2026年，GitHub Spec Kit、Thoughtworks技术雷达和Martin Fowler等人推动了一场SDD的“复兴”——新SDD不再是死板的瀑布式蓝图，而是“规范即代码”（Spec as Code）的AI原生工作流。规格变成了人机协作的界面、可演化的活文档、直接驱动代码生成的指令集。
EDD vs SDD：从“对立”到“三层治理”
与其把EDD看作SDD的“进化替代品”，不如把它们理解为AI时代软件工程的三层治理结构：
规范层（SDD）解决“AI生成代码的可控性”——通过结构化规范约束AI的行为边界；
验证层（Eval-DD）解决“AI生成代码的可验证性”——通过评估集量化质量；
价值层（Exp-DD）解决“产品决策的可证伪性”——通过实验验证用户价值。
具体来说，EDD在以下几个方面对SDD进行了补充甚至“进化”：
- 从“证明合规”到“证明有效”：SDD问你“是否按规格实现了功能”，EDD问你“这个功能是否真正解决了用户问题”。
- 从“一次性设计”到“持续迭代”：SDD假设需求在开工前可以被冻结，EDD承认需求是模糊的、演进的，必须通过反馈来澄清。
- 从“人眼审查”到“自动评估”：评估驱动开发把“质量判断”从主观评审变成了可自动执行的测试集，尤其适合AI生成代码的场景。
- 从“规避风险”到“管理不确定性”：试验驱动开发不否认失败，而是将失败转化为可控的、低成本的学习过程。
当然，这不是说SDD已经过时。盖摩天大楼仍然需要施工图，但在迷雾中探索新大陆时，你更需要的是指南针和救生艇。而当规格本身可以被AI执行、验证、迭代时，SDD与EDD的边界正融合为一种新的范式。
两个生活化的比喻
评估驱动开发 = AI的考官和错题本
想象一个AI模型是聪明但有点“飘”的学生。它读了很多书，口若悬河，但时不时胡说八道。传统开发方式像家长盯着孩子写作业，写一行看一行，既累且慢。评估驱动开发则像建立了一个全自动的考试院：先把所有可能考到的题型和答案输入进去，学生每学一章就机考一次，错题自动归档、自动重练。家长只需查看最终的“通过率报表”，而不是逐字逐句批改作文。
对开发者而言，这意味着你可以将精力从“盯着AI写代码”转移到“设计更好的考题”——也就是那套评估集。
试验驱动开发 = 产品的科学实验
再想象你是一位厨师，要研发一道新菜。SDD的做法是：先写一份详细的菜谱，规定每克盐、每毫升酱油，然后按菜谱做一次，端给顾客。EDD的做法是：先做一小份试吃装，随机给十位顾客，A组多放盐，B组少放盐，看哪组光盘。数据告诉你答案，而不是你的直觉或老板的偏好。
软件产品也是如此。用户的真实行为，永远比会议室里的需求评审更可靠。
普通开发者如何开始尝试？
EDD听起来很“高大上”，但其入门门槛其实很低。以下是几个可以立即落地的建议：
如果你做AI应用开发
- 为你的核心功能建立一套自动评估集（eval set）。不需要很复杂，哪怕只有20组输入输出对，也比“我目测没问题”强一百倍。
- 将评估跑通作为CI流水线的一环，每次修改prompts或更换模型时自动出分。
- 关注“评估即资产”——你的eval集比prompts更值钱，因为它定义了“对”的标准。
如果你做产品功能开发
- 在编写详细PRD之前，先问自己：“我最不确定的假设是什么？能不能用一周时间做个实验验证？”
- 学会使用灰度发布、A/B测试、功能开关（feature flag）等工具，把“上线”从一次豪赌变成一系列可控试验。
- 建立“实验日志”文化：每个实验无论成败，都记录假设、数据、结论，让团队从失败中系统性地学习。
如果你带技术团队
- 不要把“按规格交付”作为唯一的成功标准。加入“用户价值验证”或“评估通过率”作为并行的考核维度。
- 允许“快速失败”——如果一个实验两周内没有正向信号，要有机制让它优雅地退出，而不是硬着头皮继续。
写在最后
EDD不是SDD的替代品，而是AI时代软件工程新三层治理结构中的一环。在需求清晰、领域成熟的场景里，SDD依然是工程稳健性的基石；但在AI生成代码日益普及、产品不确定性越来越高的今天，“先定义对错，再快速验证”的EDD思维，正成为开发者的新标配。
说到底，无论是评估驱动还是试验驱动，EDD的核心只有一句话：让反馈来得更快一点，让假设死得更早一些。
但EDD的意义不止于此。2026年的软件开发正在经历深刻的角色重构：开发者的核心竞争力，正从“写代码的能力”转向“定义问题和验证答案的能力”。我们不再只是编码者，而是规范设计者、评估架构师和实验科学家。
从这个意义上说，EDD确实是一次驾驭工程的进化——不是因为我们更聪明了，而是因为我们终于学会承认自己的无知，并为此设计了一套高效的纠错机制。而这，或许正是工程思维最成熟的模样。
参考与延伸阅读
- Fawzy, A., Tahir, A., & Blincoe, K. (2026). Vibe Coding in Practice: Motivations, Challenges, and a Future Outlook – a Grey Literature Review. ICSE-SEIP '26. 揭示了AI生成代码的质量危机：45%包含安全漏洞，漏洞率是人类代码的2.74倍。
- Barla, N. (2026, Feb 24). What Is Eval-Driven Development? How to Ship AI Features Without Guessing. Adaline Blog. 提出“Evals as Specifications”理念，阐述EDD四大支柱。
- 折腾派程序员 (2026, Jun 4). AI Coding 方法论与实战指南（2026 增强版）. 稀土掘金. 系统梳理从Vibe Coding到Agentic Engineering的演进路径。
- Microsoft Learn. Get started with spec-driven development and GitHub Spec Kit. 介绍SDD在AI辅助开发中的新定义与工作流。
- Martin Fowler / Birgitta Böckeler (Thoughtworks, 2025). 关于Spec-Driven Development作为AI辅助编码工作流的定义与讨论。
- Experiment-Driven Development 的理念与精益创业（Lean Startup）中的“构建-测量-学习”循环一脉相承。
- Event-Driven Architecture 可参考 Martin Fowler 关于事件驱动架构的经典论述。
