AI基于Spec开发是巨坑？

基于Spec的编程AI是非常容易跑偏的因为上下文腐烂是不可避免的腐烂前会很听话但越跑越“固执”最后浪费Tokens浪费时间将整个系统都基本搭建起来了才发现有设计错误可能是设计方法或结构上 - 代码写不下去可能就会显现出来可能是应用场景设计错误 - 只有最后做运行测试时才出现可能是对某些领域上的知识的理解上 - 经常出现在核心内容的实现时还有一点没有记录下来的好处由于上下文腐烂所以测试结果报告是让AI“回忆”自己干到哪里的最省Tokens的线索。缘起AI 结对编程的思考我们是一个“快鱼吃慢鱼”的行业一切都讲求“唯快不破”。与 AI结对开发写代码变成了从属工作这种繁重又耗时的事可以由 AI 接管。此时思考、架构与流程变得更加重要。如何让思路保持高速推进不在后期发现前期错误而大量返工正是因为开篇的这个小经历引发了我对这 与AI结对的工程化过程的深入思考。读过我之前文章的朋友可能会了解我正采用20年前的瀑布流的方式作为当下与AI协作的标准流程。瀑布流的好处是严谨文档丰富从理论是丰富的文档可以充当AI的“记忆”至少不要让AI跑偏。但要让AI完全写出符合我们要求又能符合AI要求的文档却不是一件容易的事简单的办法是用Qoder它有一个Wiki功能可以一键式生成文档文档之丰富是当下用过的AI编程IDE中最好的但问题是在你原有架构上生成没有的时候怎么办MindX2 的设计在v1.0上做了很大的改进几乎只是保留了少部分的内容绝大部分都进行了重新设计。在这个过程中我也算是幸运地找到了一个相对可用的还算是能达到“高速推进” 的开发方法 —— 基于AI的TDD。做法是这样的先将基本的概念与想法写下来不要写实现也就是概念设计目的是说明白你想要干什么不要说怎么干怎么干就留给AI去发挥可能会有惊喜。概念设计是一个重要的边界限制AI不要跑出这个边界。建立一份设计哲学说明将你要AI遵守的底层设计逻辑写到这文件中也可以将这份文件做成智能体放入IDE。保持每份文件的长度不要超过400行实测超过6种模型Opus和Gemini还能勉强可以在400以上的文档还保持理解力其它的基本就会胡思乱想而且超长文会导致Tokens疯狂焚烧多文件时要建立一个简单索引这个可以让AI做这个索引是为了防止AI的上下文窗口爆了以后给它重新“回忆”起自己做过啥而且能以最少Tokens的代价回归到你的压缩点上下文压缩上。用同样的方法做架构设计完成后让AI根据架构设计来编程尽量不要让AI回参概念设计否则AI会死得很快因为此时文件已经很多了。好了要进入整体了当你与AI设计出上述这堆文件之后要让AI正确执行可不是容易的事。不要相信开发商说Spec可以搞定一切AI会很聪明那是骗你入局的在不进行工程化的DEMO型小项目确实能跑。但在工程化开发的前提下没有方法用Spec自动编程会成为一个巨坑删项目的情况是一定会发生的。有了架构设计让AI跑如果架构不大AI是可以跑完但你ReView代码就会发现好多地方可能是会被注有 TODO 的。最查的情况下是如果AI思考时出现“我用更简单的方式来这现这个功能” 那就意味着它开始要写垃圾代码了这个可是一定要注意的。所以我在它的“设计哲学中”一定会补充以下的反向提示词- 禁止编造内容不懂或有疑惑就停下来问 - 禁止采用任何形式的所谓 “简单方法” 处理问题虽然如此但是你的AI仍然是会【说谎】的不要相信它说它完美地做完了所有的工作它的自动编程充其量也就是完成了40~50%。经过了多番摸索我用TDD真的让它能完美工作至少完成率与准确率可以达到90%以上1. 场景测试 → 早期纠错当AI编写完架构设计后马上让它的开发场景测试这个过程你不能懒必须深度参与因为场景测试就是可以跑的【需求】也就是你对AI的【验收标准】有了这份文件你可以大程度上去检验架构与需求之间的适配程度。而不是在所有代码完成后人手去跑才发现不能用那个时候你只能重来所有耗费的Tokens就是白烧 。同样的 AI 写完初期代码就要让它直接编写场景测试代码只有场景测试全绿才进入下一步。2. Mock → 跳过实现模拟完整运作Mock 是我以前又爱又恨的一个做法爱是它真能模拟出不少问题恨是要写好多的东西但在AI结对时代Mock变成一个绝对的杀手锏不是在后期测试时用而是在开发期用你要场景测试全绿核心代码怎么做核心代码中肯定有大量机制性的内容有些内容可能是写着写着你都要去找资料看找思路开拓认知才可能将核心做得更加健壮。写核心是最容易出现思路打岔钻牛角尖的也是最耗时的最可怕的是想着想着就会与的整体架构出现巨大偏差。Mock先行可以很好地防止这种情况的发生Mock在不实现时是什么它就是一个实现的【边界】这个边界是由场景直接界定的所有的核心类需要你仔细思考的地方你都可以写成Mock先让场景跑通相信我这样做真的会少走弯路加速前行的。Mock → 模拟程序已能正常投入运作 → 观察整体完整性与可用性不需要等待核心代码实现就能验证整个系统是否跑得通。3. 聚焦核心 → 保持思路一致性当场景全通后就集中经历用TDD的方式让AI为每个 Mock 的方法写单元测试最后根据测试来一个一个方法地实现让Mock【升级】成为真实类。这样AI跑偏的机率是很低的因为让测试通过几乎就是AI的本能跟本都不用我们讲在测通方法的过程中它也会建立相应的上下文保持后续工作的一至性。周边代码完成 → 场景全绿 → 集中精力攻克核心难点不会因为某些技术需要研究或学习而打断思路的一致性。核心技术挑战可以集中攻克而其他部分已经验证完毕。本质将思考验证与代码实现解耦让思考的错误在思考阶段就被发现。方法论流程第四阶段精雕细琢性能优化边界情况处理代码重构与清理第三阶段渐进式实现重复选择一个 Mock 对象验证全绿用红绿 TDD 实现真实核心对象替换 Mock → Real第二阶段骨架搭建建立项目基本框架编写周边代码配置、工具类、基础设施编写场景测试使用 Mock 替代核心对象 目标所有场景测试全绿 Pass第一阶段架构设计与技术验证架构设计实验性测试项目验证关键技术可行性小结1. 架构验证前置在投入大量开发资源之前先验证技术方案是否可行架构设计是否满足需求模块边界是否清晰问题暴露在成本最低的阶段。2. 需求正确性验证场景测试全绿意味着所有业务场景已被理解接口契约已被定义预期行为已被确认开发过程中不再有需求理解偏差。3. Mock 阻力作为设计反馈当 Mock 难以编写时暴露的设计问题Mock 困难设计问题解决方向静态方法无法 Mock违反依赖倒置改为实例方法 依赖注入构造函数做了太多事职责不清分离关注点接口方法太多违反接口隔离拆分接口需要准备大量测试数据耦合过紧解耦或引入 BuilderMock 的难度 设计的坏味道程度4. 渐进式替换风险可控Mock A → Real A → 全绿验证 → Mock B → Real B → 全绿验证 → ...每次改动范围明确单个 Mock验证即时场景测试 单元测试回归可控不会改一处坏一片5. AI 协作友好传统开发Mock-First ArchitectureAI 容易跑偏上下文丢失任务边界清晰替换某个 Mock改动影响难以预测每次改动有全绿验证需要大量上下文聚焦单个模块上下文精简将大任务拆解为小任务每个任务都有明确的完成标准。与传统 TDD 的对比维度传统 TDDMock-First Architecture验证层级单元/函数级别架构 需求级别开发顺序逐功能迭代骨架先行渐进填充Mock 角色隔离依赖架构占位符设计反馈代码细节设计整体架构设计风险控制单元测试保障场景测试 单元测试双重保障