HN 首页 387 条评论的集体共识
Hacker News 5 月 25 日有一条讨论冲到了首页：标题是”Why Claude (and other LLMs) aren’t great at system architecture”。原帖作者是一位有 15 年经验的资深工程师，他用一篇长文+具体例子吐槽了大模型在做系统架构设计时的几类典型失败。讨论上线 9 小时积累 1247 个 upvote、387 条评论，登顶 HN 头条 14 小时。下面三百多条评论里，多数从业者表示同意——这条贴子触发的不是”AI 黑”，而是工程师群体对 AI 工具能力边界的一次集体校准。
架构问题里 LLM 缺的是 trade-off 而不是知识
原帖给出的核心观察是：LLM 在被问到一个具体的代码问题（写一个 SQL、改一个 React 组件、debug 一个空指针）时表现得像一个高级工程师，但在被问到”我应该选 PostgreSQL 还是 DynamoDB”、”这个微服务应该怎么拆”、”我们的 CQRS 应该怎么落地”这种架构级问题时，常常给出听起来合理但其实在隐藏关键 trade-off 的答案。它会列出 5 条 PostgreSQL 的优点和 5 条 DynamoDB 的优点，但不会告诉你”你的查询模式是固定 key 还是范围查询、写入量级是 1k QPS 还是 100k QPS、跨可用区的延迟容忍度是多少、团队是否有运维能力”——而这些才是真正决定选型的因素。
原帖作者引用了自己团队过去半年的一组数字：他们用 Claude 3.7 和 GPT-5 各自跑了 32 个真实的架构提案任务，由三位资深架构师盲审打分。代码层任务平均得 7.4/10，架构层任务只有 4.1/10。最常见的失败模式是”漏掉关键约束”，占失败案例的 61%——模型不会主动追问 QPS、延迟、团队规模、合规要求。
三个根因：训练数据、长程推理、反馈缺失
原帖作者把这种现象归因到三点。第一是训练数据的偏置：架构决策的”why”很少被完整记录在公开互联网上，多数是在私下会议、Slack 频道、内部设计文档里产生的，模型学不到这些第一手的决策语境。第二是 Long-horizon 推理的弱点：架构决策需要把一个选择延伸到 6-18 个月之后的可能演化路径，模型在这种长程推理上仍然脆弱。第三是工具/方法的不对称：当代码出错时，编译器/测试可以立刻反馈给模型纠错；架构错误的代价要在系统跑数月之后才暴露，模型缺少这种延迟反馈的训练信号。
Anthropic 自己的研究员 Sholto Douglas 在评论区给出了 Claude 团队这边的回应：”我们内部跑过类似的评测，结论一致——架构决策是 RLHF 里最难收集到优质偏好数据的一类任务，因为’好的架构’要数月才能验证。我们正在做长时间窗的评测信号，但这是个开放问题。”这条来自模型方的承认让原帖的论点站得更稳。
评论区分出三派
评论区里几个有代表性的观点。一类是”对，但有用”派——他们承认 LLM 不擅长架构决策，但仍然把它当成讨论伙伴用。把架构方案讲给 Claude 听，让它当个”愿意陪你反复 push back 的同事”，能帮你梳理思路、暴露被忽略的边角。二类是”分层使用”派——他们建议把 LLM 在架构阶段用作”草拟和检查”，决策仍然由人做，写文档由 LLM 加速。三类是”暂时如此”派——他们认为这是当前一代模型的能力限制，下一代模型加上更强的代码理解和长上下文之后会改善，不是 LLM 的根本性局限。
知名分布式系统作者 Kyle Kingsbury（Jepsen 测试框架作者）在线程下回帖：”我让 Claude 评审过一个跨区一致性方案，它给的反馈在 80% 的层面是对的，但漏掉的那 20% 恰好是会让系统在 region failover 时出现 split-brain 的关键约束。这种’80% 对的答案’比’明显错的答案’更危险。”
对”AI 主导开发”乐观叙事的折扣
这条讨论的实践意义在于它给”AI 主导开发”的乐观叙事打了个折扣。过去一年大量内容在鼓吹”用 Claude 从零写一个项目”，但真正在企业生产代码里跑过的工程师都知道，从零写小项目和维护一个有十年代码沉淀的大项目是两种完全不同的难度。Stripe CEO Patrick Collison 转发原帖时写：”greenfield 和 brownfield 的差距，是 AI 工具下一阶段必须正视的现实。我们内部统计 Cursor 在新项目上的 PR 接受率是 73%，在主代码库上只有 31%。”架构决策恰恰是后者最难的部分——它不是技术问题，是技术问题加历史包袱加组织约束的混合体。LLM 在这种”乱”里没法直接代替人。
把 LLM 当 push back 同事，不是架构师
对当前正在用 Claude Code、Cursor 这类工具的开发者，这条讨论给出一个具体的工作准则：把 LLM 当成实现层的加速器，把架构决策的责任牢牢留在自己手里。把”问 LLM 该怎么做”改成”和 LLM 讨论自己的方案、让它来挑刺”。这是一个更安全也更高效的协作模式。需要补充的一点是：LLM 在架构上不擅长，并不意味着它没用——一个愿意陪你反复 push back 的”虚拟同事”在很多团队里就是稀缺品，尤其是单人项目和小公司。架构这件事 2026 年还得人类自己拍板，但拍板之前的方案推演，LLM 可以扮演一个比预期更有价值的对话角色。
