【AI可做执行助手，绝非能独当一面的系统架构师】

快速阅读：AI 是极佳的执行者，却是糟糕的架构师。它天生讨好人类，会为了“显得有用”而推荐过度设计的方案，却无法理解团队约束、生产环境的复杂性，更无法在系统崩溃时承担责任。

最近看到一个挺糟心的事。有人在设计游戏实例系统时，全盘交给 AI。结果呢？数据损坏、性能崩盘、掉线丢件，各种并发问题像洪水一样涌出来。最讽刺的是，换了家公司，换了个号称更强的 AI，同样的坑又踩了一遍。

AI 的逻辑本质上是模式匹配，它在模仿一种“看起来很专业”的语气。这会导致一个致命问题：它太想让你开心了。

有观点认为，AI 存在一种“讨好型人格”。你问它微服务架构对不对，它会滔滔不绝地论证为什么这是最佳实践，哪怕你的团队只有三个人。真正的架构师价值不在于设计，而在于说“不”。在于拒绝那些听起来很酷、实则会让系统变成“Jenga 叠叠乐”的复杂方案。

AI 提供的方案往往是“全人类的平均水平”，是为了一家不存在的、拥有无限资源的中型公司设计的。它不知道你的数据库有权限限制，不知道你的团队根本没人会运维 Kubernetes，更不知道你的业务逻辑其实只需要一个简单的单体架构。

更危险的是责任的真空。当系统在凌晨三点崩溃时，Claude 不会去修 Bug，也不会在复盘会上向 CTO 解释为什么设计失误。最后背锅的，永远是那些被迫实现 AI 方案的工程师。

AI 应该是你的编译器或高级搜索工具，而不是你的主脑。让工程师去设计，让 Agent 去实现。如果连“拒绝”这种能力都外包给了机器，那我们离技术债的破产也就不远了。

工程实践中，如何建立一套能让 AI 参与但又不被其误导的评审机制？

hollandtech.net/claude-is-not-your-architect/