现在很多测试开发同学都在用 AI 写代码。
写接口自动化脚本、写测试平台页面、写后端接口、写数据处理脚本、写测试用例生成工具，好像只要把需求丢给 AI，它就能马上给你一段代码。
刚开始确实很爽。
以前要写半天的东西，现在几分钟就能出来。
但真正用到项目里，你会发现一个问题：
AI 写代码很快，但它经常不知道自己到底该写什么。
你让它“加一个功能”，它可能顺手改了公共组件； 你让它“优化一段逻辑”，它可能把历史兼容逻辑删了； 你让它“补一批测试用例”，它可能生成一堆看起来完整、实际没覆盖风险点的用例。
这也是现在 AI 编程最容易踩的坑：
不是 AI 不会写代码，而是人没有把规格讲清楚。
所以最近在 AI 编程圈里，一个词开始被频繁提到：
SDD，Spec-Driven Development，规格驱动开发。
它的核心思想很简单：
不要一上来就让 AI 写代码，而是先把需求目标、系统行为、边界范围、设计约束、验收标准和任务拆分讲清楚，再让 AI 按照规格去开发。
对测试开发来说，这个方法特别值得关注。
因为测试开发本来就不只是“写脚本的人”，而是要负责需求理解、质量风险、测试设计、自动化验证和回归保障的人。
到了 AI 编程时代，谁能把需求变成清晰的规格，谁就更容易控制 AI 生成代码的质量。
目录
为什么直接让 AI 写代码容易翻车
SDD 到底是什么
SDD 为什么和测试开发关系很大
常见的 SDD 工具和实践有哪些
用 OpenSpec 看一个完整流程
一个“暗黑模式”需求，SDD 应该怎么做
SDD 和 TDD 到底有什么区别
测试开发怎么把 SDD 用起来
哪些场景适合 SDD，哪些场景没必要
面试中怎么回答 SDD
一、为什么直接让 AI 写代码容易翻车
很多人用 AI 编程，习惯直接这样提需求：
帮我实现暗黑模式。
或者：
帮我写一个接口自动化框架。
再或者：
帮我给这个接口补测试用例。
这些提示词看起来没问题，但放到真实项目里，风险很大。
因为真实项目里的需求，往往不是一句话能讲清楚的。
比如“实现暗黑模式”，表面看只是一个前端样式需求，但实际可能涉及：
主题状态存在哪里
是否支持跟随系统主题
用户手动选择是否优先
登录前和登录后是否一致
历史用户配置如何兼容
哪些页面必须支持
哪些老页面暂时不支持
自动化测试是否需要补充
回归范围覆盖哪些模块
如果这些内容一开始不说清楚，AI 就只能靠猜。
它可能会默认主题状态放在 localStorage； 也可能默认所有页面都要改； 还可能为了实现新功能，重构一堆公共样式； 甚至可能把原来稳定运行的逻辑改坏。
这就是 AI 编程最常见的问题：
需求越模糊，AI 越容易自由发挥。
而自由发挥，在真实项目里往往就是风险。
对测试开发来说，这类问题会直接变成后续的测试压力：
需求边界不清楚，测试范围就不清楚； 系统行为不清楚，测试预期就不清楚； 设计约束不清楚，回归风险就不清楚； 验收标准不清楚，测试结论就不清楚。
所以，AI 编程不是不能用。
真正的问题是：
不能把模糊需求直接丢给 AI，然后指望它写出稳定可靠的工程代码。
二、SDD 到底是什么
SDD，全称是 Spec-Driven Development，中文一般叫规格驱动开发。
它不是一个单纯的工具，也不是某一个平台的专属概念，而是一种开发方法。
简单来说就是：
在正式编码之前，先把需求规格写清楚，再基于规格进行设计、开发、测试和验收。
过去很多团队的开发流程是这样的：
这种方式在人写代码的时代已经有问题。
到了 AI 写代码的时代，问题会更明显。
因为 AI 不会天然理解你的业务历史，也不知道哪些逻辑不能动。它只能根据当前上下文和提示词做推断。
SDD 的流程更像这样：
它强调先回答几个问题：
这个需求为什么要做？ 这次要做什么？ 这次明确不做什么？ 系统行为会发生什么变化？ 哪些历史逻辑必须保持不变？ 有哪些边界条件？ 有哪些设计约束？ 如何验收？ 如何测试？ 如何回归？
这些内容确定以后，再让 AI 写代码，AI 就不再是“自由发挥”，而是在一个清晰的工程边界里执行任务。
所以 SDD 的本质不是“多写几份文档”。
它真正解决的是：
把模糊需求变成 AI 和人都能理解、能执行、能验证的工程上下文。
三、SDD 为什么和测试开发关系很大
很多测试开发同学可能会觉得：
SDD 听起来像开发流程，和测试有什么关系？
其实关系非常大。
因为测试开发本质上做的事情，就是把需求变成可验证的质量规则。
你写测试方案，本质上是在定义测试范围； 你写测试用例，本质上是在拆系统行为； 你做回归分析，本质上是在判断变更影响； 你做自动化测试，本质上是在把规格变成可执行验证； 你做测试平台，本质上是在沉淀团队的质量流程。
所以，测试开发天然就和 SDD 接近。
只不过以前规格更多由产品、开发、测试共同沟通。
现在 AI 加入以后，规格变得更重要。
因为 AI 编程有一个很大的特点：
它很会执行，但不一定会判断边界。
它能很快写出代码，但它不知道哪些历史逻辑不能破坏； 它能很快生成用例，但它不知道哪些风险场景才是重点； 它能很快改接口，但它不一定知道哪些调用方会被影响。
这时测试开发的价值就出来了。
未来测试开发不是简单问 AI：
帮我写测试用例。
而是要学会问：
请基于需求规格、设计方案、历史逻辑和代码变更，帮我分析测试范围、风险点、回归路径和自动化覆盖策略。
这两种能力差别很大。
前者只是把 AI 当成脚本生成器。
后者是把 AI 放进完整的软件质量流程里。
四、常见的 SDD 工具和实践有哪些
现在围绕 AI 编程，已经出现了一些 SDD 相关工具和实践。
这里不建议大家死记工具名，而是理解它们背后的思路。
- GitHub Spec Kit
GitHub Spec Kit 是比较典型的 SDD 工具包，核心思想是把规格放到 AI 辅助开发的中心位置。
它更适合新项目或者新功能开发。
它强调的不是“先写代码再补文档”，而是先围绕目标、需求、设计和任务形成规格，再推动 AI 编码。
对测试开发来说，可以重点关注它的一个思想：
规格不是附属品，而是开发入口。
也就是说，需求、验收标准、测试点和任务拆分，应该尽早成为 AI 的上下文，而不是等代码写完以后再补。
- Kiro Specs
Kiro Specs 更像是 AI IDE 里的规格工作流。
它通常围绕几类文件组织开发过程：
requirements.md
design.md
tasks.md
这几个文件很好理解：
requirements.md 讲需求是什么； design.md 讲技术方案怎么做； tasks.md 讲任务怎么拆。
这套结构对团队协作比较友好。
因为它把“需求、设计、任务”这些原来容易散在聊天记录里的内容，变成了 AI 可以持续引用的上下文。
- Tessl
Tessl 的方向更偏 AI-native 软件开发。
它强调结构化、版本化的上下文，帮助团队管理 AI Agent 在真实代码库里的协作。
它的思路比普通提示词更进一步：
不是每次都靠人临时解释需求，而是把规格、上下文、技能和治理机制沉淀下来。
这个方向未来很值得关注，但对普通团队来说，落地成本会更高一些。
- OpenSpec
OpenSpec 更适合用来理解“已有项目里的规格驱动变更”。
现实中，大多数团队不是每天从零写新系统，而是在已有系统上不断加需求、修问题、做优化。
已有项目最怕什么？
最怕新功能把老逻辑改坏。
OpenSpec 这类框架的价值，就是把每一次变更都变成可追踪的规格：
为什么改； 改哪里； 不改哪里； 系统行为怎么变； 设计方案是什么； 任务怎么拆； 测试怎么验证； 最后怎么归档。
这对测试开发特别重要。
因为测试开发最关心的，往往不是“代码有没有写出来”，而是：
这次变更会不会影响历史功能？
五、用 OpenSpec 看一个完整流程
以 OpenSpec 这类 SDD 工作流为例，它的核心过程可以理解为四步：
第一步：Explore，先探索，不急着写代码
这个阶段最重要的一点是：
不要马上让 AI 写代码。
而是先让 AI 理解当前系统。
比如一个需求来了，你可以先让 AI 看：
当前功能是怎么实现的； 涉及哪些模块； 有没有历史兼容逻辑； 有没有公共组件； 有没有已有测试； 有没有隐藏调用方； 有没有权限、缓存、配置、数据迁移等风险。
对测试开发来说，这一步其实就是需求评审加变更影响分析。
很多线上事故并不是因为开发不会写代码，而是因为一开始没有搞清楚影响范围。
第二步：Propose，把需求变成规格
探索完成后，进入 Propose 阶段。
这个阶段不是写代码，而是生成规格文档。
比较常见的规格产物包括：
proposal.md
specs/
design.md
tasks.md
proposal.md 主要回答：
为什么做这个需求； 本次改动目标是什么； 本次范围是什么； 哪些内容明确不做； 有哪些风险和假设。
specs/ 主要回答：
系统行为新增什么； 系统行为修改什么； 哪些行为必须保持不变； 用户在不同场景下应该看到什么结果。
design.md 主要回答：
技术方案怎么选； 状态怎么管理； 数据怎么兼容； 异常怎么处理； 是否需要灰度； 是否影响性能和安全。
tasks.md 主要回答：
任务怎么拆； 先做什么； 后做什么； 每一步怎么验收； 哪些测试必须补。
这里最关键的一点是：
规格文档生成后，不能直接跳到开发。
人必须 review。
因为 AI 生成规格也可能理解错。
测试开发在这个阶段要重点检查：
需求边界是否清楚； 验收标准是否可测试； 异常场景是否遗漏； 兼容逻辑是否考虑； 回归范围是否合理； 任务拆分是否可验证。
只有规格确认以后，再进入开发阶段。
第三步：Apply，按照规格实现
进入 Apply 阶段，AI 才开始真正写代码。
这个时候 AI 不再是凭一句话开发，而是根据规格文档执行。
遇到行为边界，看 specs； 遇到技术方案，看 design.md； 遇到任务步骤，看 tasks.md； 遇到范围争议，看 proposal.md。
这会明显降低 AI 跑偏概率。
对测试开发来说，这一步还可以要求 AI 同步补充测试：
单元测试； 接口测试； UI 自动化测试； 兼容性测试； 异常场景测试； 回归用例更新。
这才是比较健康的 AI 编程流程：
不是 AI 写完代码，测试最后兜底。
而是需求规格、开发任务、测试验证一起推进。
第四步：Archive，把规格沉淀下来
当功能完成、测试通过后，最后一步是 Archive。
这一步很容易被忽略，但非常重要。
因为它会把这次变更的背景、范围、行为、设计和任务沉淀下来。
以后再有人维护这个功能，就不用翻聊天记录，也不用靠猜。
比如半年后有人问：
为什么这里没有跟随系统主题？ 为什么这个配置存在本地而不是服务端？ 为什么这个旧页面没有适配暗黑模式？ 为什么这个接口没有改字段？
直接看归档规格就能知道当时的决策依据。
对团队来说，这是工程资产。
对测试开发来说，这是质量资产。
后续做回归、定位缺陷、分析影响范围，都会更有依据。
六、一个“暗黑模式”需求，SDD 应该怎么做
我们用一个具体例子来看。
需求是：
给系统实现暗黑模式。
如果直接让 AI 写代码，风险很大。
更好的做法是先让 AI 做 Explore。
可以这样问：
请不要直接写代码。
请先分析当前系统是否已有主题机制，包括：
- 当前样式方案是什么
- 是否使用 CSS 变量或组件库主题
- 用户配置保存在哪里
- 哪些页面会受影响
- 哪些公共组件需要适配
- 是否已有相关测试
- 可能影响哪些历史功能
- 需要产品或开发确认哪些问题
这一步完成后，再让 AI 生成规格。
比如 proposal.md 可以写清楚：
本次目标是支持用户在浅色模式和暗黑模式之间切换； 本次只覆盖主应用页面，不覆盖历史后台页面； 用户手动选择优先级高于系统主题； 主题配置需要持久化； 旧用户默认保持浅色模式； 不改变现有登录流程和权限逻辑。
specs/ 可以写清楚系统行为：
用户首次进入系统时，默认使用浅色模式； 用户切换暗黑模式后，刷新页面仍保持暗黑模式； 用户退出重新登录后，仍使用上次选择； 如果读取配置失败，默认回退浅色模式； 不支持的历史页面保持原样，不做强制适配。
design.md 可以写清楚方案：
主题状态统一放到全局状态管理； 样式变量采用 CSS variables； 用户配置优先使用服务端配置，本地缓存作为兜底； 公共组件先适配按钮、表单、弹窗、表格； 不重构现有路由和权限模块。
tasks.md 可以拆成：
一、梳理现有主题和样式结构 二、增加主题状态管理 三、增加主题切换入口 四、适配核心公共组件 五、适配核心页面 六、补充配置持久化逻辑 七、补充单元测试和 UI 自动化测试 八、执行回归测试并修复问题
然后测试开发可以基于规格生成测试点：
你会发现，SDD 不是让流程变复杂。
它真正的价值是：
把原来藏在脑子里、聊天里、临时沟通里的内容，提前变成可检查、可执行、可测试的规格。
七、SDD 和 TDD 到底有什么区别
很多同学会把 SDD 和 TDD 混在一起。
其实它们不是一回事。
TDD 是 Test-Driven Development，测试驱动开发。
它强调先写测试，再写实现，用测试结果驱动代码开发。
SDD 更靠前。
它强调先定义需求、行为、边界、设计约束和任务拆分。
可以这样理解：
SDD 解决的是：
到底要做什么。
TDD 解决的是：
代码有没有做到。
如果没有 SDD，TDD 可能会出现一个问题：
测试写得很完整，但测试的是错误需求。
如果没有 TDD 或自动化测试，SDD 也会出现一个问题：
规格写得很漂亮，但代码到底有没有满足规格，缺少反馈机制。
所以它们不是替代关系，而是互补关系。
更合理的方式是：
先用 SDD 明确规格； 再基于规格设计测试； 再用自动化测试、接口测试、单元测试验证实现。
这对测试开发非常重要。
因为测试开发不能只停留在“补用例”，而要前置到规格定义阶段。
八、测试开发怎么把 SDD 用起来
测试开发不一定要从工具开始。
最重要的是先把 SDD 的思路用起来。
- 需求评审时，用 SDD 问问题
拿到需求后，不要急着写用例。
可以先问这几类问题：
这个需求解决什么问题？ 本次明确做什么？ 本次明确不做什么？ 用户行为会发生什么变化？ 哪些历史逻辑必须保持不变？ 哪些数据需要兼容？ 哪些接口或页面可能受影响？ 验收标准是什么？ 失败或异常情况下怎么办？
这些问题问清楚，测试设计才会稳。
- 写测试方案时，用规格做依据
过去很多测试方案容易写成经验判断。
比如：
“需要测试登录、权限、数据展示、异常场景。”
但如果结合 SDD，测试方案可以更清楚地说明：
每个测试点来自哪条规格； 覆盖的是新增行为还是修改行为； 是否涉及历史兼容； 是否属于高风险路径； 是否适合自动化； 是否需要回归。
这样测试方案就不只是“测试列表”，而是和需求规格对应的质量验证方案。
- 做自动化测试时，用规格驱动用例生成
AI 很擅长生成测试用例，但前提是上下文要足够清楚。
不要只说：
帮我生成测试用例。
更好的方式是：
请基于以下规格文档生成测试用例。
要求：
- 按正常路径、异常路径、兼容路径、回归路径分类
- 每条用例标注对应的规格来源
- 标注优先级
- 标注是否适合自动化
- 标注需要准备的测试数据
- 标注预期结果
规格如下：
……
这样生成出来的用例会更像真实项目里的测试用例，而不是泛泛而谈。
- 做回归分析时，用规格和代码 diff 结合
已有项目里，回归范围经常最难判断。
这时可以让 AI 结合规格和代码变更来分析：
请基于本次规格变更和代码 diff，分析回归测试范围。
要求：
- 列出直接影响模块
- 列出间接影响模块
- 列出高风险历史功能
- 给出必须执行的回归用例
- 给出可以抽样执行的用例
- 说明每个判断的依据
这类能力，才是真正适合测试开发使用 AI 的方式。
不是简单让 AI 替你写几条用例，而是让 AI 帮你做质量分析。
- 管理 AI 生成代码时，用规格做质量门禁
团队如果大量使用 AI 写代码，建议至少建立一个简单规则：
复杂需求不能直接进入编码，必须先有规格。
最低要求包括：
需求目标； 变更范围； 不做范围； 系统行为变化； 兼容要求； 验收标准； 测试策略。
这些内容不清楚，就不要让 AI 大规模改代码。
否则 AI 写得越快，风险扩散得越快。
九、哪些场景适合 SDD，哪些场景没必要
SDD 很有价值，但不是所有任务都要用。
如果什么事情都套 SDD，反而会变成流程负担。
适合使用 SDD 的场景
一、已有项目里的功能迭代
尤其是系统已经比较复杂，有很多历史逻辑，不能随便改公共代码。
二、跨模块变更
比如一个需求同时涉及前端、后端、数据库、权限、缓存、消息、测试数据。
三、质量要求高的功能
比如支付、权限、订单、报表、风控、用户配置、测试平台核心能力。
四、需求容易变化
产品规则还在调整，业务边界需要多次确认，这时候规格可以沉淀决策过程。
五、团队协作场景
产品、开发、测试、AI Agent 都围绕同一份规格协作，沟通成本会低很多。
六、需要长期维护的系统
规格归档以后，后续新人接手、缺陷定位、回归分析都会更方便。
不适合使用 SDD 的场景
一、一次性脚本
比如临时处理日志、批量改文件名、简单数据清洗。
二、非常小的独立函数
输入输出明确，影响范围很小，直接让 AI 写即可。
三、低风险文案修改
比如改按钮文字、改提示语、改一个静态配置。
四、需求已经非常明确的小改动
没有太多讨论价值，也没有复杂依赖，就没必要上完整流程。
所以 SDD 的正确用法不是“所有事情都规格化”。
而是：
复杂需求、高风险需求、多人协作需求，用 SDD；简单任务、低风险任务，直接对话。
十、面试中怎么回答 SDD
如果面试官问：
“你了解 SDD 吗？”
可以这样回答：
SDD 是 Spec-Driven Development，规格驱动开发。它的核心是在正式编码之前，先把需求目标、业务范围、系统行为、边界条件、设计约束、验收标准和任务拆分沉淀成规格文档，再基于这些规格进行开发和测试。
在 AI 编程场景下，SDD 的价值会更明显。因为 AI 很容易根据模糊需求自行假设，如果没有规格约束，就可能出现需求理解错误、误改历史逻辑、实现范围失控、测试验收不清晰等问题。
所以我理解 SDD 不是为了多写文档，而是为了给 AI 编程增加一层稳定的工程上下文。它让需求、设计、实现、测试和验收之间形成可追踪闭环。
如果结合测试开发来看，SDD 可以帮助测试更早介入质量保障。比如在需求阶段明确验收标准和边界条件，在设计阶段识别风险点，在实现阶段让 AI 按任务拆分开发，在测试阶段基于规格生成测试设计、自动化用例和回归范围。
SDD 和 TDD 也不冲突。SDD 更靠前，解决“需求和系统行为是否定义清楚”；TDD 更靠后，解决“代码是否满足预期”。比较理想的方式是，先用 SDD 明确规格，再用 TDD、接口自动化、UI 自动化等方式验证规格。
如果是已有项目里的复杂功能迭代、跨模块变更、质量要求高的功能，我会优先考虑 SDD；如果只是简单脚本、独立函数或者低风险小改动，就没必要上完整流程。
这个回答的重点，不是背概念。
而是要让面试官看到你理解了：
AI 编程不是简单提效工具，而是需要工程化约束。 测试开发也不是最后补用例，而是要参与规格定义和质量闭环。
最后
AI 编程确实让写代码变快了。
但代码写得快，不等于软件交付质量更高。
未来很多代码都可以由 AI 生成，真正稀缺的能力会变成：
谁能把需求讲清楚； 谁能把边界定义清楚； 谁能把风险提前识别出来； 谁能把规格转成测试设计； 谁能让 AI 在正确的工程上下文里工作。
这对测试开发来说，不是坏事，反而是机会。
因为测试开发本来就关注需求、边界、风险、验证和回归。
以前这些能力经常被低估。
但到了 AI 编程时代，它们会变得越来越重要。
所以以后不要只问：
“怎么让 AI 帮我写代码？”
更应该问：
“怎么让 AI 按正确的规格写代码、按明确的标准交付、按可验证的方式通过测试？”
这才是 SDD 真正值得测试开发学习的原因。
