AI的产出，该信任到什么程度？

一个技术负责人的crash

前一天和技术负责人吃饭，聊到AI编程。他说最近让AI写了一个比较复杂的功能，跑出来两个crash，让AI自己去修，反反复复好几轮修不好。

他只能自己去看代码，结果发现一个很有意思的事：AI写的代码能跑，但逻辑路径和人的思路不太一样。出了问题之后，他很难凭直觉判断问题在哪。最后他自己定位到具体问题，把非常精确的描述给AI，才把那个bug修了。

他的感慨是：现在还是没有办法完全信任AI，只能当工具用。

信任边界在哪

团队里用AI编程的同学有个非常一致的体感：简单的功能交给AI非常爽——你描述清楚需求，AI帮你写、帮你测，自己完成交付，整个过程丝滑，效率提升明显。

但复杂的、架构性的功能就不一样了。即使是资深程序，也不太敢完全放手让AI写核心架构。原因是：时间长了，你对自己项目的代码会有失控的风险——整个代码不是你写的，你不知道整体架构长什么样，哪天出了AI搞不定的bug，你会非常被动。

就像开头那个案例：你必须像读别人的代码一样从头理解，这个过程比debug自己写的代码慢得多。

现阶段比较成熟的协作方式是：让AI先写一版，人来review和修改。简单的模块直接用，复杂的模块人深度参与。 人的核心优势在于对业务的理解——AI提供原料，人提供配方。怎么分析需求、怎么拆解方案、怎么做决策，仍然是不可替代的价值。

一个底层认知

总结一下AI编程的信任边界：

• 简单的功能，放心交给AI做
• 复杂的架构，人必须深度参与
• 可以让AI帮你做事，但不能失去对它的判断力
• 使用AI不是会用就行，要持续优化你和AI的协作方式

更重要的是一个底层认知：AI降低了产出的成本，但没有降低决策的成本。 执行的门槛在降，判断的价值在升。你的竞争力，未来将越来越多地体现在判断力上，而不是执行速度上。

只要持续提升判断力和决策力，AI的进化对你就不是威胁，而是杠杆——它越强，你能撬动的产出就越大。

想把AI嵌入日常工作流，可以看《游戏PM的AI实战手册》。