想写这个话题有很长一些时间了。AI 大跃进仍然如火如荼，AI 的优势这次不多提，聊一聊 AI 在生产环境中遇到的一些陷阱，以及如何对减少 AI 犯错的思考。

AI 陷阱

接下来，是我在生产环境中，因为 AI 看到的一些问题。

对新人的双刃剑

AI 对文本的处理效果经常让人感到惊艳，对于新人这是一个强大的武器。把代码克隆下来，AI 可以很快生成阅读友好的服务说明、代码地图、系统架构，并且大模型本身就有强大的背景知识，这相对于过去人肉看代码并跳来跳去、问来问去好太多了，也快太多了。

但是，人有他的惰性，人的大脑有它工作的模式。过去在和代码斗智斗勇的过程中，大脑也在创建代码细节相关的连接，对细节了如指掌。有了 AI，即便第一天来的新人，就可以上手干活。人的惰性，让新人降低对现有代码阅读的强度、粒度。

身临其境地，新人用 AI 写完代码，正确性靠老人 Review，出问题再去问 AI。

生成代码对现有框架的冲击

有了 AI 之后，对于很多长时间没写过代码的人，一部分是人力短缺被迫开始完成需求，一部分觉得自己强的可怕，开始介入代码修改工作。这里就出现了一个问题，AI 写的代码是 “正确” 的，但是组织方式是有问题的，实现的方式也不那么规范。在 Review 文化没那么完善的团队，或限于人力只能妥协的团队，会对现有代码架构带了很大冲击。

一个案例，同事用 AI 写了个需求，基础库代码不适配，于是 AI 把基础库的代码拷贝了一份，并做了部分修改，放在了业务服务代码。知道这是不对的，但是又只能看着他发生。

AI 投毒

AI 的代码里面是有大雷的，我们也因此踩了很多坑。悄悄合并代码并上线，即便走一遍 Review 流程，面对 AI 的代码量很难理清细节，尤其是在我们目前人力短缺的情况下，大量有问题的代码被带到线上。某个时刻，某个人发现线上有问题，抛出问题后，陷入到排查陷阱。制造问题的人并不清楚自己的代码细节，也不确定是否是自己的代码导致的，最终由熟悉系统的人从黑盒开始对系统进行排查。

AI 银弹

团队来了一个经验丰富的新人，在入职的第三天，团队负责人沟通说，在新人的建议下，考虑把系统的 Go 服务逐步迁移到 Rust，并先在新系统的某个模块开始使用。我抛了两个问题，收益是什么？代价呢？

一遍遍强调耳熟能详的，Rust 相比于 Go 有很大的性能提升，没有 GC 带来的长尾耗时优化；相比于 C++ 有更好的内存安全保障。

但是代价呢，就说有没有优势就完了？

就引入 Rust 来说，有他的一体两面。现实是，Rust 语言本身的生态完善度、团队的知识储备、和现有架构的契合程度，这些不是考虑的因素吗？现在已经有了基于 Go 和 C++ 比较完善的基础架构和丰富的经验，引入 Rust 之后，短时间内又难以完整替换 Go 或 C++，同时维护三套技术体系及基础架构的复杂度不应该考虑下吗，尤其是在一个生死未知的 “创业团队”？

另外，算上新人满打满算 4 个研发，接管原本一百多号人维护的完整在线程序化广告交易引擎。

AI 太强大了，有了 AI，一切问题都迎刃而解，是这样的吗？只能期望是吧，我知道，会引入，自己也改变不了。

思考

在真正的 AGI 实现之前，要面对人和 AI 共存的局面。如何充分发挥人的决策力，AI 的执行力，稳定地大幅提升工作效率，会是需要持续思考的课题。在这里，我也给出一些自己的阶段性方案。

对代码有足够的连接

脚踏实地，深入代码，对于复杂的生产系统，还不能完全基于 Vibe Coding 的方式迭代。

提升稳定性稳定性、降低故障处理的 MTTR 需要非常熟悉业务系统，在看到故障现象后，能最快找到大脑和业务代码的连接，分析出原因。过度依赖 AI Coding，缺少业务背景知识，没有足够的代码连接，遇到故障先问 AI，目前看还是行不通的。

业务执行引擎的底层优化

在过往的经历中，大家在迭代在线系统中的复杂服务时，习惯在接收请求后创建一个贯穿始终的 Context，并传来传去，改来改去，最后演进到最熟悉这个模块的人看到这个 Context 都是头疼的，这种模式对 AI 来说也非常不友好。

我在这里抛出的一个方案是 DAG 执行引擎，也许会有更好的。AI Coding 后，大家自然而然地想到，如果功能、模块都是内聚的，改动局限在很小的范围，那对 AI 来说就太好了。借着这个思路，DAG 自然而然成了一个很好的选择，它天然地按节点划分，节点间通过数据驱动，每个模块依赖的数据又是已知且最小范围化的，和 AI 仿佛是天作之合。

AI 严格域与 AI 宽松域

AI 代码的 Review 问题会持续困扰大家，我要从架构上做好隔离。在一些系统里面，系统框架和业务代码深度耦合，AI 在迭代的过程中很容易破坏原有架构，往屎山的方向大跨步前进。

我这里抛出一个方案，从架构上区分 AI 严格域、AI 宽松域。AI 严格域包括统一的 Data Layer 接口、DAG 执行引擎、核心业务逻辑封装等，AI 宽松域则是基于 AI 严格域底座构建的业务代码，包含大量的临时需求、实验逻辑、各种硬编码等。这个方案的原则是把稳定、核心逻辑和经常变动的代码物理分开，严格域代码需要最严格的审查。这样安排，会得到两个好处，一是大模型不容易搞坏整个业务框架，二是整体风险可控。

人 + AI SYSTEM + BUSINESS SYSTEM

对于原本基于人 + 业务系统的形态来说，有了大模型之后，会演进为 人 + AI 系统 + 业务系统 的形态。人作为决策的核心，AI 逐步作为执行的核心。针对这一变化，我也在尝试构建一套 人 + AI SYSTEM + AD SYSTEM 的架构，逐步使用 AI 释放人力，提效增速。

关于这个方面，有好的经验之后，再继续分享。

最后

大家还处在 AI Coding 这波海啸带来的震荡中，有的团队可能因此陷入泥潭，有的已获得质的提升。不管怎样，积极拥抱先进生产力是唯一出路。