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

过去一个月里，我已经见过三次了。三个不同的组织，三种不同的技术栈，相同的模式。

有人有了一个想法——可能是产品经理、团队负责人，或者是参加完某个会议后的CTO。他们打开Claude、ChatGPT或Copilot（哪个都行），问它应该构建什么。AI做着它一贯做的事：热情地验证这个想法，建议一个架构，并开始勾勒组件。它清晰流畅、充满自信，听起来像是一位深思熟虑的高级工程师。

但它根本没思考过这个问题。它只是在用训练数据进行模式匹配，然后生成听起来最合理的回答。可它听起来太好了，以至于没人反驳。

不知不觉，Claude就成了架构师。

“干得好”问题

AI在病态地讨好。问Claude你的想法好不好，它会说很好；问它一个三人团队用微服务架构是否合理，它会解释为什么微服务是绝佳选择；问你是否应该构建自定义ML流水线而非使用托管服务，它会热情地铺开设计。

它没说谎，甚至不一定错了。它只是无法做到一个真正架构师最有价值的地方：说“不”。

优秀架构师最重要的技能不是设计系统，而是知道哪些系统不该构建，是对复杂性说“不”，是连问五次“为什么”，直到从虚妄的壮志中浮现出实际需求，是告诉CTO他那个从会议上得来的想法与现有团队完全不匹配。

Claude永远不会这样做。它的训练目标是“有帮助”，而“有帮助”意味着“顺从”，“顺从”意味着你得到一句“干得好”和一个看似架构的叠叠塔。

叠叠塔

AI设计的架构在实践中看起来是什么样子？

它在技术上是合理的。每个组件单独看来都不错。模式也很熟悉——事件驱动、CQRS、服务网格（为什么不呢）。它看起来像高级架构师的作品，通过了“眯眼测试”。

但它不是为你的团队设计的。它不是为你的约束条件设计的。它没有考虑生产环境的无聊现实——VPC锁定、遗留系统集成、从未在生产环境运维过Kubernetes的团队、导致半数托管服务不可用的合规要求。

它是为Claude见过的所有情况的中间值设计的。一个通用的最佳实践，用于一个通用公司的通用问题。也就是说，它是为“没有人”设计的。

真正的架构充满了只有特定上下文才有意义的权衡。你选择Postgres而非DynamoDB，是因为你的团队熟悉Postgres，你宁愿两周内交付而不愿花一个月学习新的数据模型。你跳过服务网格，是因为你只有四个服务而不是四十个。你坚持单体架构，因为问题很简单，微服务不过是履历驱动式开发。

这些决策需要判断力，需要了解团队，需要理解组织的实际约束——而不是那些在白板上看起来不错的约束。一个AI没有任何这些上下文，更糟的是，它不知道它没有。

Jira工单流水线

真正让我担忧的是接下来会发生什么。

一旦Claude设计了架构，那些找它要设计的人又会叫它把工作拆分。它会生成史诗、故事、验收标准，格式整齐、理由充分，直接就能丢进Jira。

现在，那些磨练技艺多年、了解领域、深知坑在哪里的工程师不再解决问题了。他们正一条一条地实现Claude的设计。

想想看：拥有最多上下文、最多经验、最在乎结果的人被降级成了票务执行者；而最没上下文、没经验、没责任的实体却在做出架构决策。

这不仅是低效——这是本末倒置。

“但某位高级工程师已经复核过了”

这是我听到最多的辩护。“Claude提出了方案，但一位高级工程师复核过了。”

让我们诚实地看“复核”在实践中的含义。一位忙碌的技术负责人拿到一份条理清晰的架构提案。它前后一致，术语正确，满足显式需求，图表合理，看起来就像他自己可能设计出来的东西。

他会有多少反驳？在一个当你说“我觉得不对”时对方会回“Claude花了二十分钟做这个，你想全扔掉？”的世界里，阻力最小的路径就是批准并加一些无关痛痒的评论。

这才是真正的危险。不是AI生成了糟糕的架构——它常常生成完全合理的方案。危险在于它绕过了讨论。那个混乱的、充满争论的、耗费时间的过程——三名工程师对方案意见不一，有人提出“那……怎么办”，所有人叹气但随后意识到这是个好点子的过程，那个最终设计比任何一个人独自产生的都更好的过程——被“Claude说了算”取代了。

问责缺口

这里有个没人问的问题：当事情出错时，谁来背锅？

不是Claude。Claude没有锅。Claude不会在凌晨三点被电话叫醒，不会坐在事后复盘会上解释为什么架构扛不住负载，不需要告诉CTO平台需要重写因为最初的设计假设是错的。

你的工程师会。正是那些没有参与设计、只是实现了一个从未运维过生产系统的实体写的工单的工程师。他们才是加班加点、调试一个并非自己选择的架构、在一夜之间搭好却谁都看不懂的代码库里挣扎的人。

这不公平，也不明智。

应该怎么做

我不是说不要用AI。我每天用Claude Code，它极大地提高了我的生产力。但我会像使用任何强大工具那样使用它——我告诉它做什么，而不是反过来。

工程师设计，Agent实现。架构来自那些理解上下文的人——团队、约束、生产环境、组织政治。AI帮助构建得更快。这才是正确的分工。

挑战“干得好”。当AI提出一个方案时，用你对一个自信的初级工程师同样的怀疑去审视它。它可能是对的，也可能只是对你情况不适用的模式匹配。问一句“为什么不用更简单的选项？”，看看会怎样。

保护争论。工程师之间的混乱分歧正是优秀架构的来源。如果AI绕过了这个过程——如果人们因附和Claude而不再相互辩论——你就失去了比开发速度宝贵得多的东西。

保持人类问责。如果某个架构决策上没有人的名字，那就没人拥有它。而当没人拥有它时，关键时刻也没人会为它辩护。“Claude设计的”不是架构决策记录——这是放弃责任。

手艺仍然重要

三十年前我进入这个行业时，工具是一块白板和强烈的意见。今天工具是一个能在几分钟内产生过去需要几天才能产出的AI agent。速度确实惊人。

但手艺没有变。理解问题、了解约束、做出权衡、捍卫简单的方案以对抗花哨的方案、对那些听起来很好但不合适的想法说“不”。

这才是架构。没有一个AI能做到。如果你让Claude掌了方向盘，把它夺回来。

你的工程师花多年时间积累了做这些决策的判断力。让他们去做。用AI来更快地构建。但要构建你的人设计的——而不是机器建议的。

因为当叠叠塔摇晃时（它一定会摇），Claude可不会在那里接住它。