笔者在近期的AI辅助开发实践中，调研并落地了一套名为STDD（Spec+Test Driven Development）的方法论。本文记录其核心设计思路与实战数据，供同样被AI编程质量困扰的开发者参考。

---

背景：AI编程的质量共识正在形成

2025年2月，Andrej Karpathy（OpenAI联合创始人）创造了"Vibe Coding"这个词，描述那种"靠感觉给AI发指令，代码能跑就行"的编程方式。这个词迅速引爆全球讨论——因为它戳中了一个普遍痛点：

AI写代码太快了，快到我们来不及判断它写得对不对。

此后一年多，全球AI编程社区独立趋同于同一个判断，整理成时间线如下：

时间	人物/组织	核心观点
2025.02	Andrej Karpathy（OpenAI联合创始人）	提出"Vibe Coding"概念，揭示AI编程"靠感觉、缺验证"的困境
2025.06	Kent Beck（TDD之父）	AI智能体会"删除失败测试而非修复代码"，强调TDD在AI时代是"超能力"
2025.09	GitHub	开源Spec Kit，内置SDD+TDD流水线
2025	Thoughtworks	将SDD列入Technology Radar
2026.03	Augment Code	发表《Spec + TDD: The Combination That Actually Produces Shippable AI Code》
2026.04	Safe Intelligence	在AI Engineer Europe大会发布/Spec27

共识已经很清晰：单独的Spec驱动"只管方向不管验证"，单独的TDD"只管验证不管方向"——只有两者融合，才能构成完整的质量闭环。

但共识归共识，从"知道应该做什么"到"有可操作的方法论"，中间隔着巨大的鸿沟。

---

STDD是什么：四层质量架构

STDD（Spec+Test Driven Development）是一套试图填补上述鸿沟的工程中实践方案。其核心不是"又一个理论框架"，而是把Spec定义→TDD执行→质量验证→全链追溯整合成一套可操作的流程。

理解STDD的关键不在于记住6个阶段，而在于理解它的四层架构：

层级	内容	解决的问题
第一层：流程	6阶段 + 3道强制确认门	“什么时候做什么、谁来做决定”
第二层：约束	Spec+Test双驱动 + GIVEN/WHEN/THEN	“AI不能做什么、必须做到什么”
第三层：检查	11类失败模式 + 覆盖率诊断 + E2E	“怎么知道AI写出的是对的”
第四层：追溯	Spec↔Test↔Code双向追溯 + 设计调整记录	“出了问题怎么快速定位”

四个层级环环相扣。任何一个层级缺失，整套系统都会出现漏洞。

---

11类AI编程失败模式（STDD的第三层核心）

STDD系统化地定义了11类AI编程中常见的失败模式。笔者认为这部分对任何做AI辅助开发的团队都有参考价值：

编号	失败模式	AI的典型表现	STDD的应对方式
(a)	幻觉行为	编造不存在的API、文件路径、函数名	Spec强制引用具体API，test立即执行验证
(b)	范围蔓延	超出proposal范围的代码改动	Gate 1严格锁定范围，diff审查变化量
©	级联错误	异常被静默吞掉，错误向上传播	TDD覆盖边界条件，E2E验证链路
(d)	上下文丢失	实现与proposal/design/spec矛盾	Gate 3逐项对比spec vs实现
(e)	工具误用	错误的工具选择或参数配置	design.md约束技术栈，Review检查
(f)	运行时行为偏差	静态代码正确，但动态行为异常	E2E测试 + 多版本兼容性测试
(g)	管线断链	多步链路中某一步缺失或断开	Spec Scenario覆盖完整链路
(h)	内容质量偏差	数据不一致、引用缺失、逻辑矛盾	spec中THEN SHALL精确约束输出格式
(i)	指令衰减	Prompt中的约束写了但未被执行	Gate 2确认spec即指令，Gate 3核查
(j)	覆盖真空	某capability零自动化测试	diff输出覆盖缺口，覆盖率诊断
(k)	契约断层	API字段名/header/类型不一致	Spec中定义接口契约，test验证契约

---

实战数据：FPPT项目

笔者用一个实际项目验证了这套方法的可行性。FPPT是一个AI驱动的PPT生成系统，使用STDD V1.2完成开发：

指标	数值
研发周期	5个自然日
代码规模	27,826行（Python 12,377 + 测试5,227）
规格产出	41份spec.md，152+条Requirements，319+个Scenarios
测试数量	336+条TC，通过率100%
人效比	~1,400行/人时
AI自动化率	90%+

5天、28,000行代码、100%测试通过率。

这个成绩不是靠"AI厉害"，而是靠流程约束。41份spec文件定义了319个精确的行为场景，每个场景都有对应的测试用例，AI的每一步行动都被约束在spec定义的边界内。

同样的方法也适用于小型项目。笔者用STDD流程完成了一个Claude Code Skill（Visio Flowchart），1小时以内完成全部开发：7个spec、29个TC、11类检查全通，单日完成完整闭环。

---

STDD V2.3的新变化

最近接触到STDD V2.3版本，相较早期版本有几个值得关注的更新：

1. 多语言支持扩展至5门

语言	测试框架	代码规范
Python	pytest	PEP 8 + 类型注解
Java	JUnit 5 + Mockito	Google Java Style
Go	testing + testify	Effective Go
Rust	cargo test	clippy + rustfmt
TypeScript	Jest	ESLint + Prettier

2. 平台适配扩展至6个

Claude Code（斜杠命令）、Cursor（.cursor/rules/）、GitHub Copilot（copilot-instructions.md）、Aider（.aider.conf.yml）、WorkBuddy、Trae，均可通过同一套Skill定义自动适配。

3. 配置模块化

项目配置拆分为project.yaml（元信息）、gates.yaml（确认门行为）、long_range.yaml（长程参数）、quality.yaml（质量门禁），可按场景组合，不必改动代码。

---

对金融/量化场景的特殊适配

这部分是笔者认为STDD最有价值的地方。量化系统的容错率为零——一个算错了夏普比率的回测系统，可能导致完全错误的投资决策。

STDD从设计上内置了几项金融研发专属能力：

• 金融概念理解：夏普比率、最大回撤、VaR、ATR止损等概念在Spec设计阶段可被校验
• 交易精度约束：自动识别浮点精度风险，强制Decimal类型
• 风控规则植入：日亏损限制、连亏降仓等规则在Spec阶段即被植入为SHALL约束
• 审计追溯：API密钥管理、订单全链路追溯，满足合规审计要求

笔者所在的团队正在用类似思路改造量化策略的研发流程，有兴趣的读者可以交流。

---

小结与参考

AI编程的质量问题，不是靠"更好的模型"能解决的，而是需要方法论层面的约束系统。

STDD的思路是：从"让AI帮你写代码"，转向"你用流程约束AI写出正确的代码"。

两者之间的区别是：前者靠运气，后者靠系统。

参考资源：

• STDD开源项目（MIT License）：github.com/leonai42/stdd
• 官网文档：hzddyy.com/stdd/
• 背景章节提到的各机构公开资料可自行检索

---

作者：小以AI实验室研究员 | 2026年5月 | 转载请注明出处

声明：本文为技术实践分享，不涉及任何商业推广。文中数据来自公开开源项目与笔者团队的实战记录。