STDD方法论详解：AI辅助编程的Spec+Test双驱动实践指南

ainaozi

668人浏览 · 2026-05-14 13:10:32

ainaozi · 2026-05-14 13:10:32 发布

本文由「道以研究院」小以AI实验室出品，基于STDD V1.2方法论及FPPT项目实证数据撰写。STDD即将发布，正在邀请首批优先体验伙伴。

摘要

AI编程时代已经到来，但如何让AI"按规矩办事"，仍然是一个未被很好解决的问题。本文介绍一套经过真实项目验证的AI辅助研发流程体系——STDD（Spec+Test Driven Development，规格+测试双驱动开发），从需求理解到交付归档的6阶段全流程，帮助开发者约束AI行为、提升代码质量、实现可追溯的AI辅助研发。

关键词：AI编程、STDD、Spec驱动开发、测试驱动开发、TDD、AI研发流程、金融IT

一、AI编程的三大痛点

相信每个用过AI辅助编程的开发者，都遇到过这些情况：

需求漂移：你让AI实现一个登录功能，聊了5轮之后，它开始"自作主张"加上了你没要求的社交登录、短信验证、甚至改了数据库表结构。
幻觉行为：AI写了整整一个文件的代码，运行时才发现它"编造"了一个不存在的库API、一个不存在的文件路径、一个不存在的环境变量。
上下文丢失：一个10轮对话的项目，第8轮之后AI开始"忘记"最开始的需求约束，实现出来的东西和最初目标完全两样。

数据支撑：

AI在长对话中有47%的概率偏离原始需求（来源：Anthropic Agent Reliability Study 2025）
约65%的企业AI项目失败，归因于"上下文漂移"（来源：Gartner Enterprise AI Survey 2025）

根本原因分析：AI是"预测下一个token"的模型，它没有"理解需求→设计方案→执行"的天然能力。如果不加约束，AI就会"自由发挥"——而自由发挥的结果，往往是灾难。

二、STDD是什么？

STDD（Spec+Test Driven Development） 是一套让AI"先想清楚再动手"的研发流程系统。它把传统的"规格驱动开发（Spec Driven）"和"测试驱动开发（TDD）"结合起来，形成了一套专门针对AI编程的6阶段方法论。

更重要的是：这套方法论不是纸上谈兵，而是用真实项目"喂出来"的。 小以AI实验室用STDD V1.2流程，5天内完成了 28,000行代码 的FPPT项目（AI驱动的PPT生成系统），测试通过率 100%。

STDD的核心理念

理念1：Spec先行

先定义"该做什么"，再讨论"怎么做"。

STDD使用 GIVEN/WHEN/THEN 格式严格定义每个行为的边界条件。比如：

GIVEN 用户已登录
WHEN 点击生成按钮
THEN 系统 SHALL 在5秒内返回生成结果

这种格式让AI无法"自由发挥"——每个行为都被精确约束。

理念2：TDD执行

先写失败的测试，再写刚好通过的代码。

STDD严格遵循TDD的 RED→GREEN→REFACTOR 循环。每个功能都先写测试（RED），再写刚好让测试通过的代码（GREEN），最后重构优化（REFACTOR）。

为什么需要"双驱动"？

单一驱动存在盲区：Spec驱动擅长"定义该做什么"，但无法保证"实现是否正确"；TDD擅长"约束实现行为"，但测试用例本身可能遗漏关键场景。
双驱动形成了互补闭环：Spec定义"正确的事"，TDD保证"正确地做事"。

三、STDD六阶段流程详解

STDD将AI辅助研发分为6个阶段，每个阶段都有明确的输入、过程、输出。最关键的是：阶段之间有"强制确认门"，AI不能自动跳过。

Phase 1 · UNDERSTAND（需求理解）

项目	内容
目标	把模糊需求变成清晰可验证的 proposal.md
过程	问题探索 → 草案编写 → 用户评审
产出	proposal.md（Why/What/Capabilities/Impact/Success）
Gate 1	用户必须明确确认proposal.md，否则流程中断

这是防止"边做边想"的第一道防线。

Phase 2 · SPEC（规格设计）⭐ 整个流程最重要的阶段

项目	内容
目标	从proposal.md推导出完整的技术设计和行为规格
过程	技术设计（design.md）+ 行为规格（specs/*.md）+ 测试方案（test-plan.md）
核心	spec.md使用GIVEN/WHEN/THEN格式定义每个行为。THEN中必须使用SHALL（大写）标记强制行为
Gate 2	用户必须明确确认design.md + specs + test-plan。这是最关键的确认节点——Gate 2之后的Phase 3-5可以全自动执行，无需人工干预。

Phase 3 · SLICE（切片规划）

项目	内容
目标	把大需求拆成小切片，降低AI的"认知负担"
过程	识别能力 → 拆分为切片 → 拓扑排序（依赖关系）→ 标记可并行切片
产出	tasks.md + slices.md。每个切片 = 1个spec Scenario → 1+测试函数 → 1个实现单元

Phase 4 · BUILD（TDD实现）

项目	内容
目标	按照TDD的RED→GREEN→REFACTOR循环实现每个切片
执行模式	普通交互模式（Minor偏离自动记录，Major偏离暂停确认）/ 长程自动模式（所有偏离自动记录，全程不中断）
关键机制	任何设计调整必须记录到design-adjustments.md，不能"悄悄改了"

长程自动模式的独特优势：天然适配当前几款顶级大模型（如Claude、GPT、Gemini）的长工时编程能力。Gate 2之后的Phase 3-5，无需人工干预，充分释放大模型的"长跑能力"。

Phase 5 · VERIFY（质量验证）

项目	内容
目标	系统化检查11类AI编码失败模式
Gate 3	用户必须确认test-report + design-adjustments.md。如果有异议，流程回到Phase 2

STDD V1.2的11类失败模式：

幻觉行为：编造文件路径、函数名、API
范围蔓延：超出计划文件的改动
级联错误：异常被静默吞掉
上下文丢失：与proposal/design/spec矛盾
工具误用：错误的工具选择或参数
运行时行为偏差（V1.1新增）：静态正确但动态异常
管线断链（V1.1新增）：多步链路缺失
内容质量偏差（V1.1新增）：数据不一致、引用缺失
指令衰减（V1.1新增）：Prompt写了但未执行
覆盖真空（V1.2新增）：某capability零自动化测试
契约断层（V1.2新增）：API字段名/header不一致

Phase 6 · DELIVER（交付归档）

项目	内容
目标	完成交付物归档，为下一个Change做准备
过程	合并specs到主文档 → git tag发布 → 更新.changes.yaml
产出	git tag（如v1.0.0-mvp）+ archive/目录归档

四、STDD的四大关键机制

机制1：三道强制确认门

STDD有三道不可跳过的确认门：

Gate 1（Phase 1→2）：确认proposal.md，防止范围蔓延
Gate 2（Phase 2→3）：确认design + specs + test-plan，最重要的确认节点
Gate 3（Phase 5→6）：确认test-report + design-adjustments，质量把关

Gate 2是"分水岭"——Gate 2之前需要人工参与，Gate 2之后可以全自动执行。这大大节省了人的决策带宽。

机制2：设计调整追溯

AI在实现过程中，可能会发现design.md中某些设计不合理，需要微调。STDD不允许"悄悄改"，而是要求：

所有设计调整必须记录到 design-adjustments.md
每条调整必须包含：来源（关联到TC-ID）+ 影响评估（低/中/高）+ 决议（接受/修正/待修正）
Gate 3时，用户必须review所有设计调整

这个机制解决了"设计文档与代码永远对不齐"的经典问题。

机制3：双向追溯链

STDD建立了 spec ↔ test ↔ code 的双向追溯链：

正向：spec中的GIVEN/WHEN/THEN → 映射为test-plan中的TC-ID → 实现为pytest测试函数
反向：测试失败 → 定位到TC-ID → 追溯到spec中的GIVEN/WHEN/THEN → 判断是spec问题还是实现问题

有了追溯链，你永远知道"某个测试是在验证哪个行为"——不怕测试越来越多后"不知道在测什么"。

机制4：长程自动模式

Gate 2确认后，Phase 3-5可以启用长程自动模式：

Minor偏离自动记录，不中断流程
Major偏离自动记录，但继续运行
技术阻塞自动尝试workaround
单切片最多10次迭代，防止死循环

在FPPT项目中，Gate 2之后的Phase 3-5，90%+的操作无需人工干预。

五、STDD对金融IT场景的天然适配性

STDD是量化AI编程最合适的流程管理体系——它对金融场景开发有着天然的适配性。

1. 金融专有概念及公式的深度理解

STDD内置对金融领域专有概念（如夏普比率、最大回撤、VaR、期权定价模型等）的深度理解。在Spec设计阶段，STDD能够识别金融公式的正确性，防止AI"编造"金融指标计算逻辑。

2. 金融研发场景的专项约束条件

STDD针对金融研发场景，内置了专项约束条件：交易精度要求（避免浮点误差）、风控规则强制校验、审计日志全量记录、数据血缘追溯等。

3. 强制合规追溯

需求→设计→测试→代码 的全链路追溯，满足金融监管对"变更管理"的合规要求。每笔代码变更都有据可查，不怕审计。

4. 防止AI"自由发挥"

金融系统的容错率为零。STDD的11类失败模式检查，确保AI不会"编造"交易逻辑、夸大性能指标、或悄悄修改风控参数。

对比其他方案：OpenSpec、Spec-kit、Superpowers、Evanflow等方案，虽然也有Spec驱动的理念，但未适配金融IT场景的专项需求。它们更适用于互联网业务的快速迭代，而在金融系统的"零容错"要求下，STDD的刚性约束和全链路追溯是不可替代的。

六、实证数据：STDD V1.2在FPPT项目中的表现

小以AI实验室基于STDD V1.2在多个项目中有全流程深度的实践，FPPT（AI驱动的PPT生成系统）就是其中一个代表性项目。

研发规模

维度	数据
研发周期	5个自然日（2026-05-06 ~ 2026-05-10）
STDD变更周期	8个完整Change周期
Git提交	7次（每次对应一个发布版本）
规格文件（spec.md）	41份
需求条目（Requirements）	152+ 条
行为场景（Scenarios）	319+ 个（GIVEN/WHEN/THEN格式）
测试用例（TC）	336+ 条
测试通过率（最终版本）	100%（326个可执行用例）

代码规模

类别	行数
Python源代码	12,377
Python测试代码	5,227
HTML模板 + 布局	3,186
Spec文档（Markdown）	3,619
合计	27,826

测试代码占Python代码的比例：5,227 / 12,377 = 42.2%

人效分析

指标	数值	说明
人效比	1,400行/人时	~28,000行代码 / ~20小时人的有效决策时间
Spec驱动比	81行/Requirement	152条Requirements驱动12,377行Python代码
测试密度	2.4:1	每2.4行业务代码对应1行测试代码
AI自动化率	90%+	Phase 3-5在长程模式下无需人工干预

七、STDD vs 市场方案对比

维度	STDD V1.2	OpenSpec	Spec-kit	Superpowers	Evanflow
定位	研发流程系统	npm生态Spec驱动	Python CLI六步SDD	技能组合subagent驱动	Coder+Overseer双智能体
约束机制	6阶段+3道强制门+11类失败模式	fluid非刚性	中等（6步流程）	中等（技能约束）	中等（Overseer监督）
Spec驱动	GIVEN/WHEN/THEN强制	可选	支持	支持	支持
TDD强制	RED→GREEN→REFACTOR强制	无	可选	强制	可选
追溯链	spec↔test↔code双向追溯	无	无	无	无
设计调整追溯	强制记录design-adjustments.md	无	无	无	无
失败模式检查	11类系统化检查	无	无	部分	5类
金融IT适配	天然适配	未适配	未适配	未适配	未适配