今天上午，我和同事一起梳理一个技术方案，遇到了一个让人有点为难的问题。
按照当前方案处理，会引出另一个问题；如果优先解决另一个问题，又会破坏当前方案。我借助 AI 推演了好几个方向，看起来每个方向都有自己的道理，可放回整个系统里，却始终没能形成闭环。有的改法还会让之前已经修好的旧 bug 再次复现。
讨论过程中，我感觉同事比较相信 AI 给出的结论，倾向于按照它的建议往下做。我对这种做法有顾虑：如果因为方案是 AI 给出的，就默认它没有问题，我们可能跳过最关键的判断------它能不能在当前系统里成立，会不会让旧 bug 再次出现。
AI 很快就能给出一份有条理的回答，甚至连代码都能一起生成。但回答看起来完整，并不等于方案已经经过验证。尤其在这次讨论中，我尝试的几个方向都还没跑通；如果这时只挑一个看起来最合理的答案继续往下做，我认为风险很大。
更让我不舒服的是，讨论中方案和流程似乎都在依靠 AI 生成。我有一种感觉：同事对 AI 太依赖了，可能没有真正静下心来梳理问题。至于他实际投入了多少思考，我并不能确定；但当一个建议的边界、依赖和旧问题都还没有说清楚时，我很难放心地把它当成可以执行的方案。
方案不能只看每一步是否有道理
这次遇到的问题，让我想到了搭积木。
一块积木看起来没有问题，另一块也没有问题，但如果它们之间没有咬合，只是简单地往上堆，堆得再高，稍微有一点变化也容易垮掉。
技术方案也是这样。某个局部修改可能解决眼前的问题，却影响另一条流程；某个新分支看似把异常处理好了，却可能让旧问题重新出现。单独看每一步，都能找到理由；连起来看，问题的输入、处理和结果未必能形成闭环。
AI 可以帮我们提出不同方向，也可以帮我们检查一些容易遗漏的场景。但它给出的建议是否适合当前系统，还取决于我们有没有把服务接口、历史问题和各种约束交代清楚，以及最终是否做过验证。就这次讨论而言，我推演过的几个方向都没能满足这些条件。
我更希望先把方案摆到桌面上
当时我没有直接说出对同事做法的批评，而是友善地提了几个建议：我们先把需求和依赖的服务接口理清，再把完整方案写下来。我希望讨论能从"AI 给了什么答案"，转到"这个答案能否解决我们的问题，以及怎么验证"。
这份方案至少要回答几个问题：问题边界在哪里？准备怎么处理？处理完成后，整个流程如何闭环？原来修过的问题会不会再次出现？不同场景下又会发生什么？
另外，也要结合实际情况提前考虑内存泄漏、内存溢出、多线程竞争等风险。这些风险不一定每次都会出现，但如果当前改动涉及相关部分，就值得在方案里说清楚，而不是等代码生成之后再碰运气。
我的想法是，等方案讨论得比较清楚，再让 AI 帮忙生成代码，然后一起评审方案和代码。评审时不仅看新问题是否得到处理，也要回头看旧问题有没有复现。这一次我们还没有找到能让所有问题都闭环的方向，所以这些建议也只是我希望接下来采用的工作方式，并不意味着方案已经解决。
人和 AI 的分工，可以比"谁先谁后"更灵活
我说"人先理清思路"，并不意味着每次都要独自想出一份完美方案，才有资格打开 AI。有时问题本身就很模糊，让 AI 帮忙列出可能的方向、指出遗漏的场景，反而能帮助我们开始思考。
真正需要留在我们手里的，是对问题和结果的判断：哪些约束确实存在，哪些建议可以尝试，方案之间有什么冲突，以及怎样验证修改没有带来新的问题。
AI 可以帮忙整理思路、补充细节、生成代码，也可以参与基础验证。但它给出结论之后，我们仍要结合实际环境检查。尤其是那些曾经出现过的 bug，如果没有重新验证，仅凭方案看起来合理，并不能说明问题已经解决。
写方案的过程，也是理解系统的过程
我越来越觉得，整理方案不只是为了交付一份文档。梳理接口和依赖时，我们会重新认识系统；考虑旧问题和边界场景时，也会发现自己之前忽略的地方。这个过程可能花时间，却能让我们对自己要修改的东西更有把握。
我愿意把 AI 当作能力放大器。它能帮我更快地探索和完成一些重复工作，但输入一句话之后，责任并不会随之转移。
这次我还没有拿到一个满意的答案。不过，在继续让 AI 生成下一个方案之前，我想先和同事把那些积木之间的连接看清楚。