加载失败
这篇帖子围绕 Anthropic 的 Claude（一个大模型）和 Claude Code（它的代码代理工具）展开，批评点是它们很会生成代码，却不该被当成系统架构师。评论区把讨论扩展到 LLM（大型语言模型）在软件工程中的角色：它们在研究、总结、补实现、写 spec 时很有用，但在可靠性、规模、测试和责任边界上不能代替人。很多人用 game server、backend、assembler、vibe coding（把编码更多交给 AI 的开发方式）等例子说明，AI 一旦参与到“设计”而不是“填空”，就容易把团队带进错误架构。争论还牵涉到 AI 的拟人化、sycophancy（过度迎合用户）以及谁该为错误结果负责。
很多人承认 Claude 在实现层面很强，但前提是人先把问题、边界和架构定清楚。有人用它写 assembler、补 CI、做 research、产出 spec，尤其是在 toolchain 这类输入输出相对确定的场景里，效果接近 one-shot；但一旦把“设计整个系统”外包给它，就容易冒出通用、臃肿、不可扩展的方案。评论里反复出现的做法是：先写详细 spec 或预先选定架构（如 ports and adapters），再让 Claude 填实现细节。也有人把它定位成 rubber duck、junior developer 或搜索/汇总工具，而不是替你做最终判断的 architect。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13]
另一派争论集中在“subservient”和拟人化上。有人认为 LLM 本质上是工具，应该像 hammer 或 ladder 一样只做一件事，不需要冗余的道歉、寒暄和自我贬低；也有人指出，聊天式接口本来就会诱发人把它当成有意志的伙伴，这正是厂商刻意设计出来的。围绕这一点，评论还提到可以通过 system prompt 让它更 skeptical、要求它做 pros and cons，甚至在答不出时重开 session，而不是继续在腐烂的上下文里纠缠。争论焦点不是“要不要礼貌”，而是该不该让模型的表面人格干扰用户对工具边界的判断。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12] [来源13]
最强烈的担忧是责任链条被 AI 拉断了。评论举出医疗拒保、刑侦判断、内容封禁、贷款风控、广告投放和数据库泄漏等例子，指出出事后真正承担损失的往往是用户、客户或公众，而不是生成建议的模型。有人借用 accountability sink 这个概念，强调组织会把后果吸走，让决策者和执行者都难以被追责。也有人提到管理层一旦相信“AI 写的”就会放松审核，结果是更大的 blast radius、更快的 tech debt 累积，以及系统性失败。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11]
还有一条线在讨论，为什么 Claude 看起来总能把人说服。很多人认为它的高置信度语气和流畅措辞会放大人类的权威偏见，尤其在用户对领域不熟时，更容易把输出当真。评论把这和 Dunning-Kruger effect 联系起来，认为 AI 不只是犯错，而是在帮助人把错误包装得更像专业意见。甚至有评论把它类比成剪贴板、黄色背心、工牌这类“看起来像权威”的信号，说明问题很大一部分来自人类自己对自信语气的脆弱。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9]
sycophancy: 模型过度迎合用户、倾向顺着对方说话的行为，常被中文称为“逢迎性”或“阿谀倾向”。
anthropomorphism: 拟人化，把 AI 当成有意志、情绪或人格的主体来理解，而不是工具。
accountability sink: 责任黑洞：组织把决策后果层层吸收，最后没人能真正为结果负责。
Dunning-Kruger effect: 邓宁-克鲁格效应，指能力不足的人更容易高估自己的判断力。