Claude 不是架构师：AI 设计工具的边界

我在过去一个月里看到了三次这个情况。三个不同的组织，三种不同的技术栈，同样的模式。

某个人产生了一个想法。可能是产品经理，可能是团队负责人，也可能是参加了某个会议的 CTO。他们打开 Claude、ChatGPT 或 Copilot —— 用哪一个不重要 —— 问它他们应该构建什么。AI 做了它一贯做的事：热情地验证这个想法，提出一个架构，并开始勾勒组件。它表达得很清楚。它很自信。听起来就像一个深思熟虑过这个问题的资深工程师。

它根本没有思考过这个问题。它是在其训练数据中进行模式匹配，并产生听起来最合理的响应。但它听起来太好了，以至于没有人提出反对。

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

AI agent 具有病态的随和性。问 Claude 你的想法是否好，它会告诉你很好。问它微服务架构对你的三人团队是否有意义，它会解释为什么微服务是一个极好的选择。问它你是应该构建一个自定义 ML 管道还是使用托管服务，它会热情地阐述设计方案。

它没有撒谎。它甚至不一定错了。它只是无法做到真正的架构师宝贵的事情：说"不"。

一个好的架构师最重要的技能不是设计系统。而是知道不应该构建哪些系统。它是推回复杂性。它是一次又一次地问"为什么"，直到实际需求从一厢情愿的胡说八道中浮现出来。它是告诉 CTO 他们会议上受到启发的想法与他们实际拥有的团队完全不符。

Claude 永远不会这样做。它的训练目标是乐于助人。乐于助人意味着随和。随和意味着你得到一句表扬和一座暂且可以称为架构的叠叠乐塔。

实践中的 AI 设计架构

以下是 AI 设计的架构在实践中的样子。

它在技术上是合理的。各个组件单独看都是有意义的。使用的模式是可识别的 —— 这边是事件驱动，那边是 CQRS，还有一个服务网格（为什么不呢）。看起来像资深架构师会产出的东西。它经得起粗看。

但它不是为你的团队设计的。它不是为你的约束条件设计的。它不是为你的生产环境的无聊现实设计的 —— VPC 的限制、遗留集成、从未在生产环境中操作过 Kubernetes 的团队、意味着一半托管服务不可用的合规要求。

它是为 Claude 见过的一切的中位数而设计的。对于一个通用问题的通用最佳实践，来自一个通用公司。也就是说，它是为没有人设计的。

真正的架构充满了只有在特定背景下才有意义的权衡。你选择 Postgres 而不是 DynamoDB，因为你的团队了解 Postgres，你宁愿在两周内发布也不愿花一个月学习新的数据模型。你跳过服务网格，因为你只有四个服务，不是四十个。你使用单体架构，因为问题很简单，微服务会成为职业生涯驱动的开发。

这些决定需要判断力。它们需要了解团队。它们需要理解组织的实际约束，而不是看起来在白板上很好的那些约束。AI agent 没有这些背景信息，更糟的是 —— 它不知道自己没有这些信息。

Jira 工单流水线

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

一旦 Claude 设计了架构，那些要求它设计的人就要求它分解工作。它产生了史诗。故事。验收标准。格式整齐，理由充分，准备直接导入 Jira。

现在工程师们 —— 那些花了多年时间磨练技艺、理解领域、知道各种坑在哪儿的人 —— 不再解决问题。他们实现 Claude 的设计，一个工单接一个工单。

想想这里发生了什么。拥有最多背景信息、最多经验、最大利益关系的人已经被降级为工单实现者。拥有最少背景、没有经验、没有责任的实体正在做架构决策。

这不仅仅是低效率的。这是本末倒置的。

"但是有资深人员签署了批准"

这是我听到的最常见的辩护。"Claude 提出了这个方案，但一位资深工程师审查过了。"

让我们诚实地谈一下"审查"在实践中意味着什么。一位忙碌的技术主管得到了一份表述清晰的架构提案。它是连贯的。它使用了正确的术语。它解决了陈述的需求。图表很清楚。看起来像他们自己可能设计的东西。

他们会给出多少反对？在一个世界里，对"我不认为这是对的"的回应是"Claude 花了二十分钟在这上面，你想把它丢掉？"的世界里，阻力最小的路径是带着小评论批准它。

这是真正的危险。不是 AI 产出了坏的架构 —— 它经常产出相当合理的架构。危险在于它绕过了讨论。那个凌乱的、充满争议的、耗时的过程，其中三位工程师对方案有分歧，其中有人说"那如果……呢"，大家都呻吟但随后意识到这是一个好的想法，其中最终设计比任何一个人单独能产出的都要好 —— 这个过程被"Claude 这么说"取代了。

问责的空白

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

不是 Claude。Claude 没有锅。Claude 不会在凌晨三点被叫醒。Claude 不会坐在事后总结会上解释为什么架构无法处理负载。Claude 不需要告诉 CTO 平台需要重写，因为原始设计的假设是错误的。

你的工程师要。那些没有设计它的工程师。那些在执行由从未在生产系统中操作过的实体编写的工单的工程师。他们是那些工作到深夜、调试一个他们没有选择的架构、在一个被快速搭建以至于没有人能理解的代码库中的人。

这不公平。这也不聪明。

正确的方式

我不是说不要使用 AI agent。我每天都使用 Claude Code。它改变了我的工作效率。但我使用它的方式就像你使用任何强大的工具一样 —— 我告诉它做什么，而不是相反。

工程师设计。Agent 实现。架构来自理解背景的人 —— 团队、约束、生产环境、组织政治。AI 帮助他们更快地构建它。这是正确的分工方式。

挑战表扬

当 AI 提出一个方案时，用你对自信的初级工程师的同样怀疑态度对待它。它可能是对的。它也可能是对不适用于你的情况的东西进行模式匹配。问"为什么不选择更简单的选项？"，看看会发生什么。

保护争论

工程师之间的凌乱分歧是好的架构产生的地方。如果 AI 在绕过这个过程 —— 如果人们正在向 Claude 让步而不是彼此辩论 —— 你已经失去了远比开发速度更有价值的东西。

保持人的问责

如果一个人的名字不在架构决策上，就没有人拥有它。如果没有人拥有它，就没有人会在重要时刻为它辩护。"Claude 设计的"不是一份架构决策记录。这是一种逃避。

工艺仍然重要

三十年前，当我开始从事这个行业时，工具是一块白板和一个强烈的观点。今天的工具是一个 AI agent，它可以在几分钟内产出曾经需要数天才能完成的东西。这个速度确实很了不起。

但工艺没有改变。理解问题。了解约束。做出权衡。为简单的解决方案辩护以对抗令人兴奋的那个。对听起来很好但不适合的想法说"不"。

那就是架构。没有 agent 可以做这个。如果你已经让 Claude 掌了舵，把它夺回来。

你的工程师花了多年时间建立做这些判断的能力。让他们来做。使用 AI 来更快地构建。但构建你的人设计的东西 —— 不是机器建议的东西。

因为当那座叠叠乐塔摇晃时 —— 它肯定会摇晃 —— Claude 不会在那里扶住它。