规范驱动开发：一种以规范为先导的 AI 原生工程方法
人工智能加快了软件交付速度，但速度本身并不能保证更好的结果。随着团队采用原生人工智能开发，真正的挑战在于如何保持需求、设计、实现和验证的一致性，从而确保最终结果仍然符合最初的意图。规范驱动开发 (SDD) 通过使结构化规范成为人类和人工智能的共享真理来源来解决这个问题。团队不再是先提出需求再进行协调，而是先进行协调，然后让人工智能根据清晰的规范加速执行。
为什么人工智能辅助开发仍然会失败
团队经常交付功能正常但却偏离最初意图的软件。问题不仅仅在于代码质量，更在于从利益相关者的需求到需求分析、架构设计、实现和验证等各个环节，概念本身的内涵逐渐流失。
翻译损失通常出现在以下四个方面：
利益相关者对产品的需求 建筑和设计要求 从设计到实施 从实施到验证和发布 如果没有能够保留意图的共享文档，每一次交接都会变成一次解读。人工智能可以加速这些步骤，但它无法纠正从未解决的歧义。
为什么提示优先的工作流程还不够
以提示为先的工作流程对于简单的任务可能效果很好，但随着范围和复杂性的增加，它们往往会遇到困难。
当需求、约束和边界情况仅存在于提示信息中时，团队虽然能够快速产出，却缺乏持久可靠的信息来源。这会导致架构偏差、代码偏差、实现不一致、代码审查难度加大，以及因人员或工具的假设差异而导致的返工。
以规范为先的工作流程改变了这种局面。团队不再依赖人工智能从零散的提示中推断意图，而是明确定义意图，并利用人工智能来执行相应的操作。最终实现更快的交付速度和更好的协同效果。
什么是规范驱动开发？
规范驱动开发（SDD）是一种以规范为先的方法。团队预先定义通用的指导原则、需求、约束、验收标准和边界情况，然后使用人工智能从这些共享的上下文中生成代码、测试和支持性工件。
在实践中，规范成为贯穿整个生命周期的连接纽带。它将业务意图与架构、实现、测试和验证联系起来，从而确保人工智能生成的输出始终基于相同的上下文。
为什么团队应该采用软件定义开发 (SDD)？
团队采用软件定义设计 (SDD) 是因为它能在实施前提高清晰度，并为人工智能 (AI) 提供更强大的基础。其最大的优势在于实际应用：
由于需求更早明确，因此歧义和返工更少。 通过共享的真实数据源，更好地协调产品、工程和测试部门的工作。 由于人工智能可以根据结构化上下文进行生成，因此实现速度更快。 由于验证与最初意图相关联，因此交付结果更可预测。 实践中发生了哪些变化 在实践中，软件定义开发（SDD）改变了团队投入精力的方向。更多的时间用于前期明确意图和规划，而后续返工所浪费的时间则减少。
产品经理帮助定义应用场景和约束条件，架构师构建规划模型，工程师利用人工智能加速产品实现，并且由于验收标准从一开始就很明确，测试环节也能更早地展开。最终形成了一个以共同目标为中心的工作流程，而非各自独立的组件。
软件定义设计（SDD）背后的理念只有在团队能够将其持续应用于日常工程工作中时才真正发挥作用。而工具包的重要性就在于此：它将共享意图、明确规范和早期验证的原则转化为团队可以采用和扩展的实用工作流程。
GitHub 规范工具包
GitHub Spec Kit 是一款帮助团队实践软件开发设计 (SDD) 的工具包。它是由微软开发的开源工具，提供结构化的工作流程，用于将需求转化为计划、实施任务和验证步骤，并且能够与 GitHub Copilot 等 AI 编码工具完美配合。
有关 github/spec-kit 的更多详细信息，请参阅链接：💫 帮助您开始使用规范驱动开发的工具包。
我们去年在博文《使用 GitHub Spec Kit 深入探索规范驱动开发——面向开发者的 Microsoft》中介绍了 Spec Kit 。您可以参考该博文快速入门，学习如何使用 Spec Kit。
GitHub 规范工具包工程生命周期
生命周期很简单：定义意图、消除歧义、在约束条件下进行规划、利用人工智能实现，并根据规范进行验证。
宪法——明确原则、标准和约束措施。
明确要求——记录需求、场景和验收标准。
澄清——解决歧义、依赖关系和特殊情况。
规划——将意图转化为架构、流程和约束。
任务——将工作分解成可实施的单元。
实施——利用人工智能生成和改进代码和测试。
验证——验证输出是否符合规范。
每一步都强化了下一步，这使得工作流程更加可预测，也更容易在团队之间扩展。
我们在实践中学到的东西
在各个团队和使用案例中，有一些实用的经验教训尤为突出：
目标一致是一种团队习惯，而不仅仅是工具选择。 好的规范不仅要体现结构，还要体现意图、约束和验收标准。 规划对实施质量有着巨大的影响。 早期更清晰的沟通通常可以缩短总交付时间。 并非每次变更都需要经历完整的生命周期，因此采用的规模应该适中。 最终结果的质量与规范的质量密切相关。简而言之，规范质量=最终结果质量。
例如：将重复的入职培训转化为可扩展的模式
在其中一个棕地项目中，团队发现，引入新的资产类型遵循相同的基本流程，但需要反复进行 UI、API 和测试更改。
通过在参数化规范中捕获可重用的模式，并仅记录每个新资产的偏差，他们转向了配置驱动模型，将入职时间从2-3周缩短到几天。
例如：协调一个复杂的多服务平台
在一个大型的全新项目中，SDD 帮助团队围绕共享词汇表协调项目经理、架构师和工程师，然后构建一个全球分布式平台，该平台涵盖与会者、设施、安全、供应商、物流和合规性等数千个移动部件。
通过将章程、规范和计划视为真理的来源，该团队提高了跨服务的一致性，明确了架构约束，并减少了随着实现扩展到各个组件而产生的执行变更。
例如：更快地从原型过渡到可用产品
在另一个棕地项目中，团队使用 SDD 将 React 和 TypeScript 原型转化为一个可运行的产品，该产品包含多个用于 DRI、配置和策略的代理，以及连接健康状况监控和管理仪表板。
结构化的工作流程使得验证 AI 生成的输出与可见的 UI 行为更加容易，团队通过自定义提示和质量门脚本加强了采用，使该过程在贡献者之间更具可重复性。
团队如何开始使用软件定义设计
团队无需一次性全面采用软件开发设计 (SDD) 生命周期；小规模、重点突出的试点项目通常是了解哪些方法在实践中行之有效的最佳途径。以下是一个简单的四步试点指南。
试点——从一项功能或工作流程入手，找出其中存在的对齐问题。 正式化——创建一个轻量级规范，其中包含场景、约束和验收标准。 迭代——利用人工智能从共享上下文中生成实现工件。 改进和扩展——根据规范审查输出结果，并在学习过程中改进工作流程。 一开始要保持流程简洁。将规范视为动态的文档，避免过早地过度规范，只有在能够带来明显价值的情况下才扩展工作流程。
为什么这件事现在很重要
软件工程正从人工智能辅助任务转向人工智能原生工作流程。随着这一转变的持续，限制因素不再是代码生成的速度，而是如何在整个生命周期中清晰地捕获、共享和验证意图。
SDD 为团队提供了一种切实可行的方法来减少翻译损失，围绕共同意图达成一致，并在整个生命周期中更可预测地使用 AI，从而实现更快的交付、更高的质量和更强的一致性。 原文
评论