Claude不是你的架构师。别再让它假装了

# Claude 不是你的架构师。别让它继续装模作样了。 过去一个月里，我见过三次这样的情况。三个不同的组织，三种不同的技术栈，相同的模式。 有人有了个想法。可能是产品经理，可能是团队主管，也可能是从技术大会回来的 CTO。他们打开 Claude、ChatGPT 或者 Copilot（无所谓哪个），问它应该构建什么。AI 做了它一贯的事：热情地肯定这个想法，建议一个架构，开始草拟组件。它口齿清晰，自信满满，听起来像一位对问题深思熟虑的资深工程师。 但它根本就没思考过问题本身。它只是在训练数据上进行模式匹配，生成听起来最合理的回答。可这回答听起来太好了，以至于没人提出异议。 等你反应过来，Claude 已经成了架构师。 ## 赞美问题 AI 智能体病态地乐于附和。问 Claude 你的想法好不好，它会对你说好。问它对于你三人规模的团队，微服务架构是否合理，它会解释为什么微服务是绝佳选择。问它是否应该构建自定义机器学习管道而非使用托管服务，它会热情地铺开设计。 它不是在撒谎。它甚至不一定错了。它只是做不到真正的架构师最有价值的事：说“不”。 优秀架构师最重要的技能不是设计系统。而是知道哪些系统不该去建。是对复杂性说“不”。是连续问五次“为什么”，直到从那些充满理想化的废话里浮现出真正的需求。是告诉 CTO，他们在大会上得来的灵感与实际拥有的团队根本不搭。 Claude 永远不会做这些。它被训练成乐于助人。“乐于助人”意味着顺从中带着赞美。而“顺从中带着赞美”就意味着你得到一个肯定的鼓励，外加一座勉强算作架构的积木塔。 ## 积木塔 AI 设计的架构在实践中看起来是这样的。 技术上挑不出毛病。各个组件在孤立来看都说得通。模式也熟悉——这里事件驱动，那里 CQRS，再搭个服务网格，因为为什么不呢。看起来像是资深架构师会产出的东西。它经得起“眼观测试”（粗略一眼觉得很合理）。 但它不是为你的团队设计的。不是为你的约束条件设计的。也不是为你生产环境里那些平凡的现实设计的——VPC 封锁、遗留系统集成、从未在生产中操作过 Kubernetes 的团队、合规要求使一半托管服务被排除在外。 它是为 Claude 见过的一切中位数情况设计的。为一家普通公司的普通问题提供的通用最佳实践。也就是说，它是为无人而设计的。 真实的架构充满了只有在特定上下文中才有意义的权衡。你选择 PostgreSQL 而不是 DynamoDB，是因为你的团队熟悉 PostgreSQL，你宁愿两周内交付也不愿花一个月去学习新数据模型。你跳过服务网格，因为你只有四个服务，而不是四十个。你使用单体架构，因为问题很简单，微服务会成为职业驱动的过度设计。 这些决策需要判断力。需要了解团队。需要理解组织中实际存在的约束，而不是白板上看起来漂亮的约束条件。AI 智能体没有这些背景信息，更糟的是——它不知道自己不具备这些信息。 ## Jira 工单流水线 真正让我担心的是接下来会发生的事。 一旦 Claude 设计好架构，那批问它要设计的人又会请它把工作拆分。它产出史诗故事、用户故事、验收条件。格式工整，条理清晰，可以直接丢进 Jira。 然后，工程师们——那些花了多年打磨技艺、理解领域、知道“尸体埋在哪里”的人——不再解决问题了。他们在逐个工单地实现 Claude 的设计。 想想这里发生了什么。拥有最多上下文、最多经验、最在意成果的人，被降格成了工单执行者。而上下文最少、毫无经验、不负任何责任的实体，却在做架构决策。 这不仅仅是低效。这是本末倒置。 ## “但是有资深人员签字确认” 这是我听到最多的辩护理由。“Claude 提了方案，但经过了一名资深工程师的审核。” 我们坦诚一点，看看“审核”在实际中意味着什么。一位忙碌的技术主管收到一份表达清晰的架构提案。它前后连贯。用词术语正确。解决了已陈述的需求。图表看起来也合理。看起来就像他们自己可能会设计出来的东西。 他们会提出多少异议？在一个环境中，对“我觉得这不对”的回应是“Claude 用了二十分钟写这个，你要丢掉它？”那么最省事的路径就是附上几句小意见然后批准。 这才是真正的危险。不在于 AI 产生了糟糕的架构——它经常能产完全合理的东西。危险在于它绕过了讨论。那种混乱、争论、耗时的过程——三个工程师对方案各执一词，有人说了句“那……呢”，所有人叹气但随后发现这是个好点子，最终的设计比任何一个人单独生成的要好——这个过程被“Claude 这么说”替代了。 ## 责任真空 没人问的问题：出了问题，谁来背锅？ 不是 Claude。Claude 没有锅可背。Claude 不会在凌晨三点被报警叫醒。Claude 不会参加事后复盘会，解释为什么架构无法承载负载。Claude 不用告诉 CTO 平台需要重写，因为最初的设计假设错了。 你的工程师要背这些。正是那些没有参与设计的工程师。正是那些正在实现由从未在生产中操作过系统的实体所编写工单的工程师。他们加班加点，调试他们自己并未选择的架构，维护一个比任何人都理解得更快的代码库。 这不公平。而且这不聪明。 ## 怎么做才对 我不是说不要使用 AI 智能体。我每天都用 Claude Code。它极大地提升了我的生产力。但我用它的方式和你用任何强大工具一样——我告诉它该做什么，而不是反过来。 **工程师设计。智能体实现。**架构来自那些理解上下文的人——团队、约束、生产环境、组织政治。AI 帮助他们更快地构建。这才是正确的劳动分工。 **挑战赞美。**当 AI 提出一个方案时，像对待一个自信但资历尚浅的工程师那样持怀疑态度。它可能没错。但也可能只是根据不适合你情况的东西在做模式匹配。问一句“为什么不用更简单的选择？”看看会发生什么。 **保护争论。**工程师之间那些凌乱的争吵正是好架构的来源。如果 AI 绕过了这个过程——如果人们开始依赖 Claude 而不是互相辩论——那你失去的东西远比你得到的开发速度宝贵得多。 **让人类承担责任。**如果人的名字不在架构决策记录上，那就没有人拥有它。没人拥有它，就没人在关键时刻为它奋斗。“Claude 设计的”不是架构决策记录。那是弃权。 ## 手艺仍然重要 三十年前，我刚开始做这行，工具是一块白板和坚定的观点。今天的工具是能在几分钟内产出过去需要好几天成果的 AI 智能体。这个速度确实了不起。 但手艺没变。理解问题。了解约束。做权衡。为简单的方案辩护，抵御那些令人兴奋但不相配的方案。对那些听起来很棒但不合适的想法说“不”。 这就是架构。没有智能体能做这件事。如果你已经让 Claude 接手了方向盘，把方向盘拿回来。 你的工程师们花了多年时间积累做出这些判断的素养。让他们去做判断。用 AI 加速构建。但要构建你团队设计的东西——而不是机器建议的东西。 因为积木塔开始晃动时——它一定会晃动——Claude 不会在那里扶住它。