基准驱动开发：超越 AI 系统的 TDD
基准驱动开发如何从 TDD 进化，以通过数据驱动的配置生成和经验优化应对 AI 的指数级增长速度.
discoveryAI基准测试软件架构测试创新TypeScript开发方法论经验式的洞察
我在早期的 2025 年间，发现了基准驱动开发，期间我正在构建一个我已经工作了两年的翻译系统和几个文档渲染引擎.
翻译系统成为这个方法论结晶的实验室.
我自 2023 年代以来一直在使用 AI 系统，随着进步，我意识到 AI 模型的演进速度如此之快，以至于传统方法无法跟上.
那时，函数调用刚刚成为市场上的创新，而自主代理还未成为现实.
我正在评估不同的语言对，构建复杂的管道，意识到项目本身需要一种方式来测量到最底层的能力。问题不只是测试某件事是否工作——而是在每隔数周景观变化时，发现最优方案.
## 从测试到模拟
我一直理解测试的价值，尤其是在为政府构建企业系统时，严格的要求和全额资助的合同要求证明.
但当 TDD 被强加到我参与的项目中时，我见证了一件重要的事情：框架只有在团队真正
强制完全采用往往没有意义.
我了解到，最好的方法往往是混合的——只采用必要的部分。.
我倾向于测试核心功能，而不是全面的单元覆盖率。.
为什么要维护成千上万的分散测试，当一份不到1000行的模拟脚本就能验证整个用户流程。?
对于政治宣传应用，我构建了一个模拟，生成虚拟团队，模拟宣传员加入和离开，生成逼真的工作负载，并在大规模下测试系统。.
这揭示了一切：UI 行为、图表渲染、在极限条件下的数据完整性。.
一段脚本比零散的单元测试给了我更大的信心。.
在我 25 年的编码经验中，我在过去 10-12 年里深刻意识到优秀评分卡的价值。.
我在 GPT 出现之前就使用评分卡，过去三年用 AI 重新审视它们，十分有趣。.
这些模拟经验奠定了后来成为基准驱动开发的基础。.
## 一切改变的那一刻
真正的发现发生在我意识到一件改变一切的事时：**基准测试可以直接生成投入生产的配置**。.
它已经测试完成，随时可以直接与提示和其他内容一起使用。.
那是最大的洞见。.
这源于面对翻译系统的一个根本问题。.
AI 提供商声称支持数十种语言，但程度和质量如何？?
这些信息没有得到很好的记录，我通过经验学到我无法完全信任供应商的声明——而我不应该信任。.
于是我创建了一个基准评估循环，内置于项目中。.
我可以给它一个服务和模型，它会评估它真正擅长哪些语言——不是供应商所宣称的，而是基于经验证据的。.
该过程是幂等的：相同输入，得到相同输出，持续缓存以快速获取结果。.
在更改提示时，我们进行 A/B 测试来发现最佳提示。.
持续失败的模型被列入黑名单或在特定语言对中被降级，从而使基准测试更具成效。.
使用 AI 构建 AI 集成的做法证明非常强大。.
借助函数调用和早期框架，这些框架后来发展为代理，我可以用 AI 构建基准测试，配有评分卡和评估。.
我对模型和语言能力的发现与供应商的声明有显著差异。.
我需要更接近底层，更接近实际证据。.
```mermaid
graph TB
Problem[供应商声明]
Loop[评估循环]
Cache[幂等缓存]
ABTest[A/B 测试提示]
Demote[黑名单失败]
Discovery[推送到生产]
BDD[BDD 框架]
Problem -->|创建| Loop
Loop -->|启用| Cache
Cache -->|快速| ABTest
Cache -->|跟踪| Demote
ABTest -->|突破| Discovery
Demote -->|优化| Discovery
Discovery --> BDD
style Problem fill:transparent,stroke:#666666,stroke-width:2px,stroke-dasharray:5 5
style Discovery fill:transparent,stroke:#3B82F6,stroke-width:2px
style BDD fill:transparent,stroke:#10B981,stroke-width:2px
```
这并非理论性。它源于无法信任供应商声明以及随着新模型出现而不断更新生产系统的实际痛点。.
基准测试从测量工具演变为配置生成器。.
## 基准驱动开发到底是什么
基准驱动开发超越验证，成为一种生成性过程。.
在测试验证正确性的同时，基准测试比较多维度性能。.
更重要的是，在BDD中，基准测试发出驱动生产系统的配置。.
我的意思是：不只是检查代码是否能运行，系统会持续评估哪种方法最优，然后自动配置自己使用最佳方案。.
采用有效方案，构建真正服务于你上下文的东西。.
```mermaid
graph LR
subgraph "测试驱动开发"
Test[编写测试]
Code[编写代码]
Pass[测试通过]
Test --> Code
Code --> Pass
end
subgraph "基准驱动开发"
Bench[运行基准测试]
Compare[比较结果]
Config[生成配置]
Deploy[生产]
Bench --> Compare
Compare --> Config
Config --> Deploy
end
style Pass fill:transparent,stroke:#10B981,stroke-width:2px
style Deploy fill:transparent,stroke:#10B981,stroke-width:2px
style Config fill:transparent,stroke:#3B82F6,stroke-width:2px
```
## 在翻译系统内部
在翻译系统中，我并不是只挑选单一 AI 模型并期望它在所有语言对上表现良好，而是创建了一个全面的基准测试系统，对多种模型在三个关键指标上进行评估：
1. **质量** - 翻译准确性与文化细微差别保留
2. **速度** - 不同文本长度的响应时间
3. **成本** - 每个令牌或每次请求的定价
基准测试本身已说明问题，并揭示出令人惊讶的洞见，彻底改变了我对 AI 语言能力的看法.
明晰的时刻来自于为一位客户完成的中文手稿翻译项目.
他们的妻子写了一本 175+ 页的中文手稿，我在帮助数字化和翻译它.
我使用 Google Translate's overlay feature 捕捉了页面，然后将内容分成 10-15 页的块进行系统评估。
使用 Claude Opus——当时最先进的模型——我对每一块进行全面评估.
AI 不仅仅是翻译；它分析了 Google Translate's 机器翻译输出的质量。
结果令人惊讶：文化细微差别损失了 30%%，并有具体例子精准指出意义崩溃的确切位置.
AI 会解释：“根据机器翻译，这个短语在英文中的意思是 X，但中文实际上传达的是 Y——文化背景是 Z，这种误解根本改变了意义。”这些差异并非细微差别.
这些差异在作者原意中造成了显著损失.
让这项发现更令人担忧的是测试那些声称支持 50-80+ 语言的模型.
由于我对西班牙语有一定了解，我能够发现类似的文化细微差别损失，而简单的指标完全无法捕捉到.
这让人质疑，当与更昂贵的替代方案相比，文化细微差别损失了 30%% 时，“受支持语言”到底意味着什么.
夫妻对详细报告深受感动——他们并未预料到如此精准地定位
对我而言，这一刻是关键的转折点：我需要衡量真正重要的基准，而不仅仅是供应商所声称的.
这段经历直接激发了以基准为驱动的方法，这种方法最终成为我构建系统的核心.
```mermaid
graph TB
Input[测试语料库]
Models[AI 模型]
Bench[基准测试套件]
Metrics[分数：Q/S/C]
Winner[最佳配置]
ProdConfig[生产]
Input --> Bench
Models --> Bench
Bench -->|质量| Metrics
Bench -->|速度| Metrics
Bench -->|成本| Metrics
Metrics --> Winner
Winner -->|自动生成| ProdConfig
style Winner fill:transparent,stroke:#3B82F6,stroke-width:2px
style ProdConfig fill:transparent,stroke:#10B981,stroke-width:2px
```
## 评估评估者
一个关键的创新是实施我所称的“先评估评估者”。由于我对西班牙语略有了解，我能轻易发现更简易评估指标遗漏的文化细微差异。.
专门使用更昂贵、更高质量的模型来评估评分卡本身，确保基准测试测量真正重要的内容。.
使用评估循环并采用更智能的模型来评估评估者成为了一种强大的技术。.
为某个事物找到一个优秀的评估者是项目中的一次惊人创造——一次壮举，一次挑战，也是一次成就。.
这一步进阶评估过程迭代地完善了评分卡，我能够创建一个可靠的评估框架，真正值得信赖用于做自动决策。.
在我的经验中，这就是大多数团队失败的地方：他们在未先评估评估者的情况下就信任它们。.
```mermaid
graph TB
Basic[基本指标]
Human[人工审核]
Premium[高级模型]
Refined[细化评分卡]
Trust[可信评估者]
Basic -->|发现的缺口| Human
Human -->|洞察| Premium
Premium -->|评估| Basic
Premium --> Refined
Refined -->|迭代| Trust
style Human fill:transparent,stroke:#333333,stroke-width:2px
style Premium fill:transparent,stroke:#3B82F6,stroke-width:2px
style Trust fill:transparent,stroke:#10B981,stroke-width:2px
```
## 当基准成为配置
一旦我意识到基准可以生成生产配置，一切都明朗了.
基准与代码一起存在，并可以专注于引擎中管道或组件的任何层级.
它可以创建模拟组件、测试变体，并在分数提升时直接将配置输出到源代码.
那种连接变得至关重要。AI 发展如此迅速，在项目中保持基准化是值得的.
当有新模型以更好的经济性或速度发布时，分数卡保持不变，基准化继续进行.
质量提升是不可思议的.
获胜组合——模型选择、提示工程、参数调优——已通过完整审计轨迹测试，直接输出到配置并投入生产.
通过翻译系统，我对模型在语言翻译方面的能力有了不可思议的了解.
获胜者自动成为生产配置，始终使用质量、价格与文化细微差别保留的最佳平衡.
这创建了一个审计轨迹，精确展示每项技术决策为何做出，且有经验数据支持.
当有人问“为什么使用模型 X 进行西班牙语到法语，而使用模型 Y 进行中文到英语？”答案存在于基准结果中.
## 通过数据的提示工程
系统进化为不仅基准模型选择，还基准提示工程本身.
我能够构建基准，并让不同部分甚至在 AI 提示上工作，系统地 A/B 测试不同提示.
基于既定指标，清晰的赢家浮现.
这消除了提示工程中的猜测，用数据驱动的决策取代直觉.
## 持续发现的经济学
这种方法具有显著的成本节约方面.
分数卡旨在在保持良好速度的同时，促进最佳质量和文化细微差别，并以最佳成本实现.
此外，我通过不必手动评估任何东西而节省的成本——只需让一切在新模型或模型版本发布时自行展开.
当模型声称在某些语言对上表现出色时，只需将其添加到配置并观察基准运行，实在太简单了.
我知道无论何者获胜，都会以硬证据支持的方式实施到生产中.
对我而言，基准驱动的发展就像在项目的一个专门部分拥有一支小团队的代理人，负责研究、发现和评估.
观看起来相当有趣.
就像在项目中有一个小型研发店正在工作.
翻译系统是我最喜欢的系统之一——我花了两年以上的时间间断地开发它，现在终于达到了可以用它创建服务的程度，虽然目前我只私下使用它.
## 良性循环
基准驱动开发创造了一个良性循环：
1. **通过测量获得清晰**: 抽象质量变成具体指标
2. **通过比较学习**: 每个基准都能让我们对问题空间学习到新的东西
3. **通过数据获得信心**: 决策得到本地可验证证据的支持
4. **通过自动化实现演进**: 系统持续自我改进
这种方法在推动创新方面已被证明极为有效.
它已成为我构建系统的首选方法，尤其是在AI领域，地面随时在我们脚下变动.
我也不是这方面的极端主义者.
每个项目的上下文揭示了最适合的方法.
```mermaid
graph TB
Define[定义指标]
Implement[构建基准]
Cache[缓存结果]
Evaluate[执行 A/B 测试]
Select[选择赢家]
Generate[发布配置]
Deploy[部署到生产环境]
Monitor[监控性能]
Define --> Implement
Implement --> Cache
Cache --> Evaluate
Evaluate --> Select
Select --> Generate
Generate --> Deploy
Deploy --> Monitor
Monitor -.->|持续的| Evaluate
style Cache fill:transparent,stroke:#333333,stroke-width:2px
style Select fill:transparent,stroke:#3B82F6,stroke-width:2px
style Deploy fill:transparent,stroke:#10B981,stroke-width:2px
```
## 实践中出现的内容
通过实施基准驱动开发，这些模式被认定为关键：
- **明确的指标被证明至关重要**: 当性能、成本和质量与正确性一起跟踪时，成功在多个维度上变得可衡量.
- **全面基准测试揭示隐藏问题**: 测试覆盖了所有预期输入和边缘情况，暴露了部分测试所忽略的问题.
- **缓存实现了快速迭代**: 幂等性和积极的缓存使成千上万种基准变体在无冗余计算的情况下变得可行.
- **自动化配置减少了错误**: 当基准结果直接生成生产配置时，手工转录错误消失.
- **审计轨迹提供了清晰度**: 每个配置决策可追溯至基准数据，使调试和问责变得直接.
## 此方法的适用场景
我在软件开发方面的理念是，方法应始终根据上下文和需求不断演进.
基准驱动开发对于许多项目并不适用，尤其是那些没有实验性质或未直接集成到快速演变的 AI 系统中的项目.
对我而言，空间中演化速度的张力与 AI 能力的范围——从温度为零的完全确定性输出到更高温度的创造性输出——共同产生了必要性.
利用翻译系统，基准驱动的方法是有意义的，因为我可以用硬证据和书面记录来衡量质量、速度和成本.
BDD 在以下场景中已被证明最有效：
- 多个有效实现选项（不同的 AI 模型、算法或方法）
- 快速演变的技术环境
- 多维优化需求（质量、速度、成本）
- 需要可解释的技术决策
- 复杂的配置空间
- 需要持续适应新能力的系统
它在 AI 系统、渲染引擎、优化问题以及任何“最佳”取决于上下文和权衡的领域中特别强大.
每个项目的上下文揭示了最适合的方法.
## 前进之路
随着 AI 越来越多地集成到我们的系统中，静态测试已不够充分.
证据表明，随着底层技术迅速演进而快速适应的方法会产生更好的结果.
基准驱动开发为我们提供了一条前进之路，使我们的系统能够基于经验数据持续自我优化.
从 TDD 向 BDD 的转变是一种向更强大的方向演进，既保留测试又超越它们.
在最佳解决方案每日变化的世界中，我们的开发方法论必须同样具备动态性.
## 结论
基准驱动开发代表了我们构建和优化系统方式的进化.
通过让基准变为生成式而非仅仅评估式，我们创建了带有内置审计跟踪的自我改进系统.
核心洞见：不要仅仅测试某件事是否有效，而是持续测量最佳方案，然后自动配置系统使用该最优解决方案.
在指数级技术变革的时代，这种适应性和透明度成为构建创新系统的关键.
这非常有价值，因为我从中自己学习.
我有更清晰的认识，决策得到了实际本地数据的支持.
观看基准运行非常有趣——就像在项目中拥有一个小型研发实验室，发现什么有效，而我专注于构建.
对于在快速演变领域构建系统的任何人，这提供了一种通过经验优化实现卓越的务实方法.
只采用真正符合目标的.
质疑一切以揭示真正重要的.
当团队了解他们为何如此做时，结果自会说明一切.
为了对框架及实现模式进行系统拆解，我已在 [Benchmark-Driven Development: A Framework](/articles/benchmark-driven-development-framework) 文档中记录核心组件.
这是我在网站上分享的第一篇文章，我希望你在探索这种方法的过程中发现了价值.
保重，祝你一路顺风.