AI 很少或者不会质疑我给出的前提

在 MemoBridge 的开发过程中，我发现和 AI 协作时，它往往不会出错。这里说的不是代码层面的错，而是：只要我给出一个想法，它基本都能帮我实现。但它似乎不会主动质疑我的想法，也不会质疑这个任务本身。

于是就会出现一种现象：如果我提出的设计本身就有问题，AI 仍然会非常顺利地把它做出来。

比如，当我发现 Subject 里的 Thread 越来越多时，我很自然地冒出一个想法：是不是该加一个 ThreadGroup？

我把这个想法告诉 AI，它通常马上就能进入实现模式：ThreadGroup 可以降低组织复杂度，可以加数据库关系，可以做一个分组页面，还可以让 AI 自动建议怎么分组……很快，一套完整方案就摆在我面前了。从逻辑上看，一切都很成立。

但真正应该先问的问题其实是：

为什么 Thread 会越来越多？这些 Thread 本来就应该存在吗？用户真的需要去组织它们吗？还是说，这个问题根本就是上一个设计自己制造出来的？是不是原本的设计就已经出了问题，从而引出了额外的不相关的问题？

所以，AI 很擅长解决我当前指给它看的那个问题，但当前问题不一定就是根问题。

当我告诉 AI Thread 太多，它会自然地解决怎么管理很多 Thread。但它不会天然知道，我真正需要的也许不是更好地管理 Thread，而是重新质疑为什么系统允许甚至鼓励产生这么多 Thread。

AI 很擅长给错误方向自圆其说

AI 写方案的能力太强，而且短时间内生成的数量极多。查看 AI 写的文档本身也是一件费精力的事情，读起来感觉没什么问题。心理上可能会出现：既然这么完整，甚至有些地方就不会仔细思考、查看是否有问题。当实现成本下降以后，感觉自己变得更加顺从了。

AI 会非常擅长给错误方向打补丁。原始设计产生问题，AI 增加补丁，补丁产生新问题，再增加一层机制，越来越复杂。

什么开始真正占用时间

以前我认为，与 AI 协作最重要的是如何准确表达需求，让 AI 更好地执行。现在我越来越觉得，更重要的问题可能发生在执行之前。

当一个想法进入 AI 之前，它应该被当成一个需要验证的假设，而不是一个等待实现的需求。AI 可以帮助我寻找方案，但不能替代我判断问题是否真实；可以帮助我完善逻辑，但不能因为逻辑完整，就证明这个方向值得存在。

当代码生成变得越来越廉价之后，软件开发中真正稀缺的东西可能正在发生变化：过去昂贵的是怎么实现。以后更昂贵的可能是：做什么，为什么做，以及什么时候应该什么都不做。而把地基打好才是我应该更注重的

总结

回头看 MemoBridge，我现在并不认为之前几个月都是无用功。那些被不断推翻的 Subject、Repository、Phase、Thread、CognitiveUnit 和 Agent，反而让我第一次真正意识到一个问题：软件的复杂度并不总来自真实世界，有时候它来自我们自己对真实世界错误的抽象。

以及当系统跟着自己每一个突发奇想的想法设计后，后期面临的问题所需要处理的复杂度也会越来越多。 而 AI 会让这种抽象以前所未有的速度变成代码。

感觉从0到1变得越来越重要是我们人类能够决定的，而从1到100是AI更擅长的。 如何把一个项目的从0到1搭建好才是项目后期稳步开发的重要根基