我在早期 2025 发现了基准驱动开发，在构建我已经工作两年的翻译系统以及几个文档渲染引擎时. 翻译系统成为了这个方法论结晶的实验室. 我自 2023 年以来一直在使用 AI 系统，随着进步，我意识到 AI 模型发展得如此之快，以至于传统方法跟不上. 那时函数调用刚刚作为市场创新出现，自治代理真正成为事物之前. 我正在评估不同的语言对，构建复杂的管道，我意识到我需要一种方法让项目本身能够测量到底层能力。问题不只是测试某事是否有效——而是发现当环境每隔几周就会变化时，什么最有效.

从测试到仿真

我一直理解测试的价值，尤其是在为政府构建企业系统时，严格的要求和全额资助的合同需要证明. 但当 TDD 被强加到我参与的项目中时，我见证了一件重要的事：框架只有在团队真正接受它们时才有效. 强制完全采用往往没有意义. 我学到的最好的方法往往是混合的——只采用必要的部分. 我倾向于测试核心功能，而不是全面的单元覆盖. 为什么要维护成千上万的零散测试，而一段少于 1000 行的仿真脚本就能验证整个用户流程? 对于一个政治拉票应用，我构建了一个仿真，创建了模拟团队，模拟拉票者加入和离开，生成了真实的工作负载，并在大规模下对系统进行压力测试. 这揭示了一切：UI 行为、图表渲染、极限下的数据完整性. 一段脚本给了我比零散单元测试更大的信心. 在我 25 年的编码生涯中，我在过去 10-12 年里深刻意识到优秀评分卡的价值. 我在 GPT 出现之前就已经使用评分卡，过去三年用 AI 重新审视它们让我感到非常有趣. 那些仿真经验奠定了后来成为基准驱动开发的基础.

一切改变的那一刻

真正的发现发生在我意识到一件改变一切的事时：基准测试可以直接输出一个直接投入生产的配置. 它已经被测试，直接在那里，准备好与提示和其他一切一起插入. 那是关键洞察. 这源于面对翻译系统的根本问题. AI供应商声称支持数十种语言，但质量和程度如何? 这些信息记录不充分，我通过经验了解到我无法完全信任供应商的声明——我不应该. 于是我创建了一个存在于项目中的基准评估循环. 我可以给它一个服务和模型，它会评估它实际上擅长哪些语言——不是供应商声称的，而是经验数据所显示的. 该过程是幂等的：相同输入，相同输出，持续缓存以获得快速结果. 在更改提示时，我们进行A/B测试以发现最佳提示. 持续失败的模型被列入黑名单或在某些语言对中降级，使基准测试更具生产力. 使用AI构建AI集成被证明极其强大. 通过函数调用和早期将演变为代理的框架，我可以使用AI构建基准测试，配备评分卡和评估. 我发现的模型和语言能力与供应商的声明有显著差异. 我需要更接近底层，更接近实际证据.

graph TB Problem[供应商声明] Loop[评估循环] Cache[幂等缓存] ABTest[A/B 测试提示] Demote[黑名单失败] Discovery[推送到生产] Problem -->|创建| Loop Loop -->|启用| Cache Cache -->|快速| ABTest Cache -->|跟踪| Demote ABTest -->|突破| Discovery Demote -->|优化| Discovery style Problem fill:transparent,stroke:#666666,stroke-width:2px,stroke-dasharray:5 5 style Discovery fill:transparent,stroke:#3B82F6,stroke-width:2px

这并非理论。它源于无法信任供应商声明以及在新模型出现时不断更新生产系统的实际痛苦. 基准测试已从测量工具演变为配置生成器.

基准驱动开发到底是什么

基准驱动开发超越验证，成为一种生成式过程。. 测试验证正确性，基准测试比较多维度的性能。. 更重要的是，在 BDD 中，基准测试发出驱动生产系统的配置。. 我的真正意思是：不只是检查代码是否工作，系统会持续评估哪种方法最有效，然后自动配置自己使用最佳方法。. 采用有效的方法，构建真正服务于你上下文的东西。. 测试驱动开发：

graph TB Test[编写测试] Code[编写代码] Pass[测试通过] Test --> Code Code --> Pass style Pass fill:transparent,stroke:#10B981,stroke-width:2px

基准驱动开发：

graph TB Bench[运行基准测试] Compare[比较结果] Config[生成配置] Deploy[生产] Bench --> Compare Compare --> Config Config --> Deploy 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 的叠加功能捕获页面，然后将内容拆分为10-15页的块进行系统评估。 使用当时最先进的 Claude Opus 模型，我对每个块进行了全面评估. AI 不仅仅是翻译；它分析了 Google Translate 的机器翻译输出质量。 结果令人震惊：文化细微差别损失了 30%，具体示例准确指出了意义崩溃的地方. AI 会解释："根据机器翻译，这句话在英文中意味着 X，但中文实际上传达的是 Y——文化背景是 Z，这种误解根本改变了意义。" 这些并非细微差别. 它们是作者意图信息的重大损失. 使这项发现更令人担忧的是测试声称支持 50-80+ 语言的模型. 由于我对西班牙语有一定了解，我能发现类似的文化细微差别损失，而更简单的指标完全会忽略. 这让人质疑，当与更昂贵的替代方案相比，文化细微差别损失为 30% 时，"支持的语言"到底意味着什么. 这对夫妇被详细报告深深打动——他们没想到能如此精准地识别翻译失败的地方及其原因. 对我来说，这是关键时刻：我需要衡量真正重要的基准，而不仅仅是供应商所声称的. 这段经历直接激发了基准驱动的方法，这种方法将成为我构建系统的核心.

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

评估评估者

一个关键创新是实施我所称的 "先评估评估者 " 由于对西班牙语有一定了解，我能够轻松发现更简单评估指标所忽略的文化细微差别的损失. 解决方案是使用更昂贵、更高质量的模型专门评估得分卡本身，确保基准测试衡量真正重要的内容. 拥有评估循环并使用更智能的模型来评估评估者成为一种强大的技术. 为某事获得一个优秀的评估者是项目中的一次惊人创造——一次壮举、一项挑战和一次成就，全部一次完成. 这一元评估过程迭代地完善了得分卡，我能够创建一个稳健的评估框架，实际上可以被信任来做出自动化决策. 在我的经验中，这就是大多数团队失败的地方：他们在未先评估评估者的情况下就信任他们.

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 发展如此迅速，项目中保持基准测试是值得的. 当新模型以更好的经济性或速度发布时，得分卡保持不变，基准测试继续进行. 质量提升令人难以置信. 获胜组合——模型选择、提示工程、参数调优——已通过完整审计轨迹测试，直接发射到配置并直接投入生产. 借助翻译系统，这让我对模型在语言翻译方面的能力有了令人难以置信的认识. 获胜者自动成为生产配置，始终使用质量、价格和文化细微差别保留的最佳平衡. 这创建了一个审计轨迹，清晰展示每个技术决策的原因，并以实证数据为支持. 当有人问“为什么 Model X 用于西班牙语到法语，但 Model Y 用于中文到英语？” 答案存在于基准结果中.

通过数据进行提示工程

系统演进为不仅基准模型选择，还基准提示工程本身. 我能够构建基准测试，然后让不同部分甚至在 AI 提示上工作，系统地进行 A/B 测试不同提示. 基于既定指标，明显的赢家浮现. 这消除了提示工程中的猜测，用数据驱动的决策取代直觉.

持续发现的经济学

这种方法具有显著的成本节约方面. 评分卡旨在以良好的速度推广最佳质量和文化细微差别，同时以最佳成本实现. 除此之外，我通过不必手动评估任何东西而节省的成本——只需让一切在新模型或模型版本发布时自行展开. 当模型声称在某些语言对上表现非常好时，直接将其添加到配置并观察基准运行非常容易. 我知道无论什么赢得胜利都会被实施到生产中，并有硬性证据支持. 对我而言，基准驱动的开发就像在项目的一个特殊部分拥有一支小型代理团队，进行研究、发现和评估. 观看起来相当有趣. 这就像在项目中有一个小型研发工作室在工作. 翻译系统是我最喜欢的系统之一——我花了两年多的时间断断续续地构建它，终于达到了可以用它创建服务的阶段，尽管目前我私下使用它.

良性循环

基准驱动开发创造了一个良性循环：

  1. 通过测量实现清晰：抽象质量变为具体指标
  2. 通过比较学习：每个基准都能教会我们关于问题空间的新知识
  3. 通过数据获得信心：决策得到本地可验证证据的支持
  4. 通过自动化实现演进：系统持续自我改进

这种方法已被证明在推动创新方面极为有效. 它已成为我构建系统的首选方法，尤其是在 AI 领域，地面不断在我们脚下移动. 我也不是这个方面的纯粹主义者. 每个项目的背景揭示了哪种方法最有效.

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中记录了核心组件。. 这是我在网站上分享的第一篇文章，希望你在探索这一方法论的过程中获得价值。. 保重，祝你一路顺风。.