随着AI编程能力的不断提升，SDD(Spec Driven Development)成为时下最炙手可热的话题之一，于是就着手头的工作亲身实践了一下，特以此文复盘、回顾此次实践过程，并总结、整理其中的一些心得与体会。其中的观点不一定对，仅作为对当前认知与思考的记录，也许未来某天翻看这篇文章，会羞愤于此时的浅薄与荒谬，但那又何妨？人类对事物的理解与认知，总是有一个循序渐进的过程，以下为正文。

实验环境

本次SDD实践基于Spec Kit完成，Agent采用腾讯的code buddy，你问我为什么选它？

1. 注册方便，不用科学上网，不用国外手机号
2. 多款模型免费使用，不用担心token太贵导致中途放弃
3. 不仅提供CLI，还有原生IDE，满足不同使用场景需要
   对于首次实践SDD的小白，还能有更好的选择吗？

在模型方面，本次主要薅国内LLM的羊毛，包括glm-4.7、 deepseek-v3.2、Kimi-K2-Thinking等，当然code buddy也提供了薅国外模型羊毛的机会，包括了GPT-5.2、Gemini-3等，只是Credit数量有限，没两把就薅秃噜毛了。

项目目标

本次是需要开发一款针对金融市场历史行情的ETL工具，用于从多个不同类型的历史行情源抽取数据，清洗、转换后，灌入到某时序数据库，用于策略的开发与回测。
由于是首次尝试SDD，最终效果怎样不得而知，因此为保险起见，选择使用Java + Maven，一旦失败方便兜底。

投入与产出

本次项目整体耗时为1.5+4.5=6天，其中包括了一个周末，周末两天除了睡觉，基本都在干活（当然主要是AI在干，我在监工），所以换算到8小时的话，应该是1.5+6.5=8天，至于为什么会是两个时间相加？因为做了两轮，这个稍后细说。
本次的最终交付物包括了约17,500行的Java代码+15,000行Markdown文档，还有一些杂七杂八的配置文件，测试覆盖率约为50%，如果以代码行数作为产出的衡量标准，AI的绩效排名应该很高；同时交付物经多轮修改、调试后，最终满足需求目标。

回头来看，这次实践是一个不断学习、不断思考、不断尝试、不断调整的过程，有一些新的认知。

SDD是什么

大致浏览了一下Spec-Kit的源码，发现这其实是一个将SDLC落地的提示词工程，或者说是一套标准的话术“模板”，用户通过命令，如/speckit.constitution，/speckit.specify等，将自己的要求、目标等填充进这些模板，形成一套完整的“剧本”，然后让AI按剧本进行表演。所以经常开玩笑说，最近琢磨和干的事，跟缅北园区是一样的，都是按话术“忽悠”，区别是缅北园区忽悠人骗钱，我是忽悠AI好好干活。

SDD的价值在哪？

传统开发过程是以代码为核心交付，需求、逻辑都体现在代码中，而文档仅仅是代码的附属，当文档与代码不符时，以代码为准，因为所有人都信奉一点：能Work的代码，千万别去动它。
但代码所能体现的仅仅是结果，无法体现形成结果的过程，这个过程往往存在开发者的脑子里，随着时间推移，人员更迭，这些信息会逐渐丢失，最终成了《往事只能回味》。
SDD将规范文档作为软件开发的驱动力，将其至于核心地位，而将代码作为规范文档的生成结果，使得在交付结果的同时，更能保留过程；事实上留存过程远比留存结果重要，有了过程可以轻松推断出结果，反之则不然。
程序本质上是人与计算机之间沟通的语言，开发者通过编写程序，让计算机理解并执行开发者的意图，而SDD借助了AI对于自然语言的处理能力，使开发人员有机会摆脱那些精炼，但表达力有限的编程语言的束缚，以更加丰富的语言表达、传递自己的意图。
从这个角度看，传统开发向SDD的迁移，与开发者从汇编语言转向使用Java、C++这些高级语言进行开发，没有本质区别，AI在其中充当了编译器的角色。

过程复盘

I. 为什么做了两轮？

第一轮失败了呗！！！
最近刷到很多文章、短视频，在宣扬一个观点：“只需要清楚的描述需求和验收标准，不要做过多的干预，因为你干预后得到的，只是你脑海中的，而不是最好的产品，要相信AI，不要让你成为束缚AI能力的瓶颈…”。
我决定相信AI的能力，于是花了大半天写出了一个我自认为非常清晰、明确的需求文档让AI执行，一天后我看到了一个包含70~80个代码文件，架构清晰、编码规范的项目，只是无法使用(甚至无法编译通过)，那bug改不完，真的改不完…往往是改了一个，新出来俩，按下葫芦浮起瓢…只好放弃
我一度怀疑是自己的姿势有问题，为什么Cursor可以让GPT-5.2连续肝七天，写出来一个浏览器，还能Demo，而我却只得到了一个编译都不通过的ETL？好在后来听说，有好事者扒了Cursor提交到Github上的源码，发现就从来没编译成功过，涉嫌虚假宣传了这是。
关于失败的原因，个人分析是因为Scope太大，想一口吃成个胖子；想想也是，就是做个杀猪盘，也得一步一步来，哪有上来就要人家全部家当的？
此处响起背景音乐“怎么忍心怪你犯了错，是我给你自由过了火…”

II. 第二轮做了什么调整？

第二轮最重要的调整，是对Scope进行了拆分，分解为多个小目标，包括：定义接口、Data Model，实现主流程 --> 实现基于文件的Extractor --> 实现基于MySql的Extractor --> 实现基于时序数据库的Loader --> 实现不同行情数据的Transformer
这些小目标依次执行，持续迭代，每一步稳定后，再进行下一步，将每次改动的代码文件数量控制在20个以内，AI的表现相对比较稳定，能够Hold住。
当然，代价就是更长的耗时与更多的Token消耗（这里再次感谢腾讯送的免费羊毛！！！）

III. 模型的影响有多大？

这中间也薅了GPT-5.2和Gemini-3的羊毛，但因为是在第二轮分拆任务后尝试的，并没有展示出比国产模型更强，它们完成的任务，国产模型也完成了，因此不敢妄加判断。

IV. 除了Scope拆分，还有什么经验？

但是在使用过程中，逐渐总结了以下经验：

1. 支持的上下文长度，与产出质量并不成正比，而是与注意力相关。上下文长度只决定了一次交互所能携带的信息量，并不是模型一次性处理的信息量。
   曾看到有文章提出，在一次交互中，模型的注意力会主要集中在上下文的头尾两端，这在实践中的表现就是，即使我在Constitution中明确规定每轮代码修改后，必须确保编译与测试用例全部成功，但模型经常“忘记”，但只要你一问，它立马就"Apologize"。
   所以在后来SDD开发过程中，一个办法是经常性的清理一下Context，AI在后续迭代中会自己找到需要的信息，这样一方面让模型更容易聚焦，另一方面也能省点Token(这毕竟是钱啊！！！)
2. LLM更适合写通用功能性代码，但对特殊场景的处理并不擅长。
   从LLM模型的本质看，它并不理解你的需求，只是根据上下文生成下一个最可能的Token，这个概率是由训练所使用的数据决定的；在“阅读”了成千上万优秀的代码后，在通用功能性代码的实现方面，是超越很多开发者的，老实说这方面代码的规范化、严谨度比我高，毕竟我没有阅读过那么多的代码。
   但是对于特殊的业务逻辑，由于缺少训练数据，只能凭经验猜，质量相对较差，特别容易加戏。举个例子，由于ETL需要处理的是时序数据，在插入数据前会根据时间戳对多个行情源数据一起先排序，再依次串行插入，虽然在specify和plan阶段专门进行了强调，但AI依然选择了性能更好的并行插入。
   因此对于这类处理特殊业务逻辑的代码，还是需要人工来把关，至少需要Vibe Coding一下。
3. AI不是永远比人高效，不要盲目迷信。
   对于Java这种强类型语言，经常碰到的问题是，生成的代码中遗漏了import某个Class导致编译失败，LLM在处理这类问题是效率很低，这种情况下自己动手来的更快一些。
   究其原因应该是LLM是从文本的角度在进行分析，并没有借助编译器或是IDE的能力（当然如果把Maven构建失败的输出给到它，它也能分析出来，但是通常需要很多轮才能把所有的错误找出来），后续尝试看看能不能做个MCP调用IDE解决；同样的问题还出现在refactor方法签名这里需求上。
4. TDD对于AI辅助编程非常重要
   AI在分析业务逻辑问题时，效率远高于我，毕竟代码是它写的嘛，但这里有个问题，AI不会Debug，或者说目前的LLM只能局限于代码的文本状态，无法感知到代码在真实世界的运行状态，这应该就是杨立坤诟病LLM，提出世界模型的原因吧。
   因此在现阶段，人不得不作为LLM接触真实世界的触手，代替LLM来感知，并将真实的结果反馈给AI。，运行出bug后如何反馈呢？TDD是一个很好的选择，告诉AI你输入了什么，看到了什么，而应该是什么，让AI写一个Unit Test，让它自己重现、修复这个问题。
5. 人类学习的手段与途径仍然多于AI，对于一些冷门的技术，AI需要你来教他如何使用
   在实践中发现，对于我们使用的某款时序数据库，由于其官网提供的文字资料有限，AI始终无法import正确的package，这种情况下，开发者通过反编译jar包的方式，找到了正确的答案，并反馈给AI进行修复。
6. 永远不要奢望能完整、准确的描述需求，不完美才是常态
   看到那些说“只要清晰、准确的描述需求和验收标准…”，我想这种人不是蠢就是坏，这是一个在现实世界中不可能存在的完美假设，什么叫清晰？什么又叫准确？标准是什么？连法律这种事关人命的文字表述，也做不到清晰、准确，保证所有人理解一致，否则为什么还有司法解释权一说？
   这世界，不完美才是常态，SDD也是一个不断迭代，不断调整的过程，不要因为一次不匹配而否定AI的能力。
7. 学会双向提问
   Spec-Kit的流程中有两个特别的步骤，clarify和analyze，分别在specify和tasks之后，在这两个步骤中，AI会向你提问，就需求以及整个执行任务规划中，需要澄清的，或者是存在矛盾的地方，要求用户做补充说明，这是一个非常好的机制，用于提升Spec的质量。
   但仅是这样单方面提问并不够，用户其实也需要向Spec-Kit提问，确认下AI的理解是否与用户的真实意图一致，没有理解偏差，是否抓住了重点，回答错误可以要求Spec-Kit修正，并记录到Spec中去，就像老师的课堂提问。
   Spec-Kit并没有为这类提问提供专门的命令，但是放心，相关信息都在上下文中存着呢，LLM知道你在说什么，只管问便是了。
8. 慢即是快
   如果仅从功能角度看，我自己写大概2~3天就能搞定，但SDD多花了将近一倍时间，这是否意味着SDD不如我呢？我可以很负责任的SAY NO。
   因为从交付上，我自己2~3天一定可以交付一个能用的版本，但对于边缘场景的处理、架构的合理性上肯定不如SDD的交付，这倒不是技术水平的差异，而是工作习惯。
   传统的开发模式下，以当前目标为导向，差不多了就赶紧动手写代码，边写边改，缺少全局思考的时间和耐心，尤其是对于这种大概率使用一次的工具；而AI更像是开了天眼，从一开始就帮把这些问题都想清楚了，并且有现成的解决方案。
   从时间消耗上看，大部分时间是花在Token生成上，相信未来随着模型的进一步优化和算力的增长，Token生成效率会进一步提升，秒出代码不是梦，另外通过MCP、Skills等Agent功能的运用，模型与Agent能够更好的协作，对于代码的控制与修改效率还有很大的提升空间。

最后总结一句话，对于SDD，不要迷信，更不要不信。