一、那个让人为难的下午

两个人在梳理一个技术方案，遇到一个死结：按当前方案处理，会引出另一个问题；优先解决另一个问题，又会破坏当前方案。作者用 AI 推演了好几个方向——每个方向看起来都有道理，可放回整个系统里，始终没形成闭环。有的改法甚至会让之前修好的旧 bug 再次复现。

讨论中，同事倾向于按 AI 的建议往下做。作者的不安在于：如果因为方案是 AI 给出的，就默认它没问题，我们就跳过了最关键的一步判断——它能不能在当前系统里成立，会不会让旧 bug 回来。

AI 很快就能给出一份有条理的回答，甚至连代码一起生成。但"看起来完整"和"已经验证"是两件事。

二、为什么每一步都对，整体却错

作者用搭积木打比方：一块积木没问题，另一块也没问题，但它们之间没有咬合，只是简单往上堆，堆得再高，稍微有点变化就会垮。

技术方案同理：

AI 能提出方向、能检查容易遗漏的场景，但建议是否适配当前系统，取决于你有没有把服务接口、历史问题和各种约束交代清楚，以及最终有没有做验证。这次讨论里，作者推演的几个方向都没满足这些条件。

三、换个问法，讨论才回到正轨

作者没有直接批评同事，而是提了几个建议：先把需求和依赖的服务接口理清，再把完整方案写下来。把讨论从"AI 给了什么答案"，转到"这个答案能否解决我们的问题、怎么验证"。

一份可执行的方案至少要回答五个问题：

1. 问题边界在哪里？
2. 准备怎么处理？
3. 处理完成后，整个流程如何闭环？
4. 原来修过的问题会不会再次出现？
5. 不同场景下会发生什么？

还要结合实际情况提前考虑风险：内存泄漏、内存溢出、多线程竞争。这些不一定每次都出现，但如果改动涉及相关部分，就该在方案里说清楚，而不是等代码生成后再碰运气。

四、正确的顺序：先方案，后代码，再评审

作者主张的工作方式是：

• 先把方案讨论清楚；
• 再让 AI 帮忙生成代码；
• 然后一起评审方案和代码；
• 评审时既看新问题有没有解决，也回头看旧问题有没有复现。

注意第三步——评审要覆盖"回看"。大多数人只检查"我改的地方对不对"，很少有人检查"我改的地方有没有弄坏别的"。而后者才是线上事故的主要来源。

五、人机分工：不是先后，是边界

作者特别澄清了一点：说"人先理清思路"，不等于每次都要独自想出完美方案才配打开 AI。问题模糊时，让 AI 列方向、指出遗漏场景，反而能帮人开始思考。

真正必须留在人手里的，是四件事：

最后一段话值得记住：写方案的过程也是理解系统的过程。梳理接口和依赖时会重新认识系统，考虑旧问题和边界场景时会发现自己忽略的地方。这个过程花时间，但能让你对要改的东西更有把握。

AI 是能力放大器。但它给出结论之后，责任不会随之转移。