本文由「道以研究院」小以AI实验室出品基于STDD V1.2方法论及FPPT项目实证数据撰写。STDD即将发布正在邀请首批优先体验伙伴。摘要AI编程时代已经到来但如何让AI按规矩办事仍然是一个未被很好解决的问题。本文介绍一套经过真实项目验证的AI辅助研发流程体系——STDDSpecTest 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是什么STDDSpecTest Driven Development是一套让AI先想清楚再动手的研发流程系统。它把传统的规格驱动开发Spec Driven和测试驱动开发TDD结合起来形成了一套专门针对AI编程的6阶段方法论。更重要的是这套方法论不是纸上谈兵而是用真实项目喂出来的。小以AI实验室用STDD V1.2流程5天内完成了28,000行代码的FPPT项目AI驱动的PPT生成系统测试通过率100%。STDD的核心理念理念1Spec先行先定义该做什么再讨论怎么做。STDD使用GIVEN/WHEN/THEN格式严格定义每个行为的边界条件。比如GIVEN 用户已登录WHEN 点击生成按钮THEN 系统 SHALL 在5秒内返回生成结果这种格式让AI无法自由发挥——每个行为都被精确约束。理念2TDD执行先写失败的测试再写刚好通过的代码。STDD严格遵循TDD的RED→GREEN→REFACTOR循环。每个功能都先写测试RED再写刚好让测试通过的代码GREEN最后重构优化REFACTOR。为什么需要双驱动单一驱动存在盲区Spec驱动擅长定义该做什么但无法保证实现是否正确TDD擅长约束实现行为但测试用例本身可能遗漏关键场景。双驱动形成了互补闭环Spec定义正确的事TDD保证正确地做事。三、STDD六阶段流程详解STDD将AI辅助研发分为6个阶段每个阶段都有明确的输入、过程、输出。最关键的是阶段之间有强制确认门AI不能自动跳过。Phase 1 · UNDERSTAND需求理解项目内容目标把模糊需求变成清晰可验证的 proposal.md过程问题探索 → 草案编写 → 用户评审产出proposal.mdWhy/What/Capabilities/Impact/SuccessGate 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 · BUILDTDD实现项目内容目标按照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 2STDD 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 1Phase 1→2确认proposal.md防止范围蔓延Gate 2Phase 2→3确认design specs test-plan最重要的确认节点Gate 3Phase 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-590%的操作无需人工干预。五、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在多个项目中有全流程深度的实践FPPTAI驱动的PPT生成系统就是其中一个代表性项目。研发规模维度数据研发周期5个自然日2026-05-06 ~ 2026-05-10STDD变更周期8个完整Change周期Git提交7次每次对应一个发布版本规格文件spec.md41份需求条目Requirements152 条行为场景Scenarios319 个GIVEN/WHEN/THEN格式测试用例TC336 条测试通过率最终版本100%326个可执行用例代码规模类别行数Python源代码12,377Python测试代码5,227HTML模板 布局3,186Spec文档Markdown3,619合计27,826测试代码占Python代码的比例5,227 / 12,377 42.2%人效分析指标数值说明人效比1,400行/人时~28,000行代码 / ~20小时人的有效决策时间Spec驱动比81行/Requirement152条Requirements驱动12,377行Python代码测试密度2.4:1每2.4行业务代码对应1行测试代码AI自动化率90%Phase 3-5在长程模式下无需人工干预七、STDD vs 市场方案对比维度STDD V1.2OpenSpecSpec-kitSuperpowersEvanflow定位研发流程系统npm生态Spec驱动Python CLI六步SDD技能组合subagent驱动CoderOverseer双智能体约束机制6阶段3道强制门11类失败模式fluid非刚性中等6步流程中等技能约束中等Overseer监督Spec驱动GIVEN/WHEN/THEN强制可选支持支持支持TDD强制RED→GREEN→REFACTOR强制无可选强制可选追溯链spec↔test↔code双向追溯无无无无设计调整追溯强制记录design-adjustments.md无无无无失败模式检查11类系统化检查无无部分5类金融IT适配天然适配未适配未适配未适配未适配核心差异总结OpenSpec、Spec-kit、Superpowers、Evanflow等方案都有各自的优势部分在SDD方面做得非常优秀部分在TDD方面做得不错但基本没有把SDD和TDD充分融合做得非常丝滑的。而STDD是唯一针对金融IT场景设计的流程体系。八、STDD适合谁金融IT团队需要高可靠性、强合规性的金融系统开发团队AI编程爱好者想用AI写代码但总是遇到AI跑偏的问题技术团队Leader想引入AI辅助研发但需要保证代码质量和可追溯性开源项目维护者想用AI贡献代码但担心合并后不知道这代码是谁写的、为什么这么写九、总结用一句话总结STDD的核心价值Spec先行TDD执行质量不靠运气靠系统。Quality doesnt come from luck — it comes from a system.STDD不是理论框架而是从真实项目的失败教训中喂出来的。V1.0只有5类失败模式V1.1扩展到9类V1.2扩展到11类——每一次扩展都对应着一批真实逃逸问题的根因。参考文章道以研究院 · 小以AI实验室《STDD让AI编程不再碰运气》发布时间2026年5月作者小以AI · 实验室研究员