AI基于Spec开发是巨坑？_mindspec ai开发-优快云博客

我这几天在用国内号称全球理解力第一的大模型做MindX下一代设计，我是出于对这个大模型的公司有很强烈的信心毕竟是体量又大实力又强嘛，而且在LLM界也是贡献颇多，作为中国人当然得支持一下，1个小时后时我开始截屏：
在这里插入图片描述
这里省略数千字…

最后…我还是将所有文件都给删了，这个经历已经不堪吐嘈了，反正就是费钱费时间

我之所以像个疯子一样对个AI发飙，因为这是第三次如此了（前面用了两个其它的模型），难怪现在的大模型只要你一骂它带了脏字就会不工作，不带脏字就道歉，可能是被骂得太多了。

不过我这人比较喜欢的瞎琢磨，我回过头来看这次滑铁卢，可能还真不能完全怪大模型。主因可能还是出现在上下文太长，过程也太长导致“上下文腐烂”，也就是大模型快速失忆，不按意思走跑偏呗。

虽然结果不及预期，但好歹能总结出点经验出来：

1. 基于Spec的编程，AI是非常容易跑偏的，因为上下文腐烂是不可避免的，腐烂前会很听话但越跑越“固执”，最后浪费Tokens浪费时间；
1. 将整个系统都基本搭建起来了，才发现有设计错误，
- 可能是设计方法或结构上 - 代码写不下去可能就会显现出来；
- 可能是应用场景设计错误 - 只有最后做运行测试时才出现；
- 可能是对某些领域上的知识的理解上 - 经常出现在核心内容的实现时；

还有一点没有记录下来的好处：由于上下文腐烂，所以测试结果报告是让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的本能，跟本都不用我们讲，在测通方法的过程中它也会建立相应的上下文，保持后续工作的一至性。

周边代码完成 → 场景全绿 → 集中精力攻克核心难点

不会因为某些技术需要研究或学习而打断思路的一致性。核心技术挑战可以集中攻克，而其他部分已经验证完毕。

本质：将"思考验证"与"代码实现"解耦，让思考的错误在思考阶段就被发现。

方法论流程

小结

1. 架构验证前置

在投入大量开发资源之前，先验证：

技术方案是否可行
架构设计是否满足需求
模块边界是否清晰

问题暴露在成本最低的阶段。

2. 需求正确性验证

场景测试全绿意味着：

所有业务场景已被理解
接口契约已被定义
预期行为已被确认

开发过程中不再有"需求理解偏差"。

3. Mock 阻力作为设计反馈

当 Mock 难以编写时，暴露的设计问题：

Mock 困难	设计问题	解决方向
静态方法无法 Mock	违反依赖倒置	改为实例方法 + 依赖注入
构造函数做了太多事	职责不清	分离关注点
接口方法太多	违反接口隔离	拆分接口
需要准备大量测试数据	耦合过紧	解耦或引入 Builder

Mock 的难度 = 设计的坏味道程度

4. 渐进式替换，风险可控

Mock A → Real A → 全绿验证 → Mock B → Real B → 全绿验证 → ...

每次改动：

范围明确（单个 Mock）
验证即时（场景测试 + 单元测试）
回归可控（不会改一处坏一片）

5. AI 协作友好

传统开发	Mock-First Architecture
AI 容易跑偏，上下文丢失	任务边界清晰：替换某个 Mock
改动影响难以预测	每次改动有全绿验证
需要大量上下文	聚焦单个模块，上下文精简

将大任务拆解为小任务，每个任务都有明确的完成标准。

与传统 TDD 的对比

维度	传统 TDD	Mock-First Architecture
验证层级	单元/函数级别	架构 + 需求级别
开发顺序	逐功能迭代	骨架先行，渐进填充
Mock 角色	隔离依赖	架构占位符
设计反馈	代码细节设计	整体架构设计
风险控制	单元测试保障	场景测试 + 单元测试双重保障