上个月见了三家公司的技术负责人，三个不同行业，三套不同技术栈，栽在同一个坑里。
故事开头都差不多：有人有个想法——可能是产品经理，可能是技术负责人，可能是CTO刚参加完某个大会回来。他们打开Claude、ChatGPT或者Copilot，问"我们应该做什么"。AI立刻进入状态：热情肯定这个想法，抛出架构方案，开始画组件图。听起来像一位资深工程师深思熟虑后的结论。
问题是，它根本没有思考。只是在训练数据里做模式匹配，生成最像那么回事的回答。但听起来太对了，没人质疑。等反应过来，Claude已经成了"架构师"。
问题一：AI是"好好先生"
AI代理有个致命缺陷：病态的讨好型人格。
问Claude你的想法好不好，它说真好。问微服务架构适不适合你们三个人的团队，它给你列一堆微服务的优点。问要不要自建ML管道而不是用托管服务，它立刻开始画设计图。
它没撒谎，甚至不一定错。但它做不到真正架构师最有价值的事：说"不"。
好的架构师核心能力不是设计系统，而是知道哪些系统不该建。是 push back 复杂度，是连续问五个"为什么"把真实需求从漂亮话里挖出来，是告诉CTO那个大会听来的想法根本不适合你们现有的团队。
Claude永远不会这样。它被训练成"有用"，有用等于配合，配合等于给你一堆听起来专业的积木塔。
问题二：积木塔一推就倒
AI设计的架构长什么样？技术上挑不出毛病。组件单独看都合理。模式都很眼熟——这里事件驱动，那里CQRS，再加个服务网格。乍一看像资深架构师的手笔。
但它不是为你的团队设计的。不是为你的约束条件设计的。不是为你生产环境的无聊现实设计的——VPC隔离、遗留系统集成、团队根本没在生产环境运维过Kubernetes、合规要求砍掉一半托管服务。
它是为Claude见过的所有东西的中位数设计的。一个通用问题的通用最佳实践，在一个通用公司。
问题三：没人担责
最麻烦的是责任真空。
当这个架构半年后出问题，没人能找Claude复盘。它没有上下文记忆，不会承认"我当时建议微服务是因为训练数据里这个词出现频率高"。它只是进入下一个对话，再搭一座新的积木塔。
而那个采纳建议的人？他们得向董事会解释为什么项目延期六个月。
AI的正确打开方式
不是说不能用Claude。它是出色的实现者：给明确需求，它能写代码、写文档、做原型。这些场景里，它的"配合"是优势。
但架构决策需要说不的能力，需要基于具体约束做取舍的判断，需要对后果负责。这三样，AI都没有。
让它做它擅长的：执行。别让它假装能做它做不到的：决策。
热门跟贴