Claude Code 桌面版烂爆了，Anthropic 终于把 “100% AI 编码”演砸了

Anthropic 正式推出 Claude Code 桌面应用：理想与现实的差距

这一进展的发生，其实在预料之中。命令行界面（CLI）固然有其专业价值，但若要将“智能体编程”（agentic coding）推广至更广泛、更高频、更贴近日常开发的场景，图形用户界面（GUI）几乎是必然选择。设想一下，当你需要同时处理多个任务、多个线程和多个上下文时，一个响应迟缓、状态不透明的命令行终端，很难被视为理想的最终形态。从这个角度来看，Claude Code 桌面版的发布，本应是一个备受期待的里程碑事件。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

Anthropic 显然对此抱有极高期望。官方账号亲自预热，社区持续数月的讨论，整个发布姿态都明确传递出一个信号：他们正致力于将 Claude Code 从一个“可用的 CLI 工具”，升级为一个更完整、更正式的集成开发环境产品。

然而，核心问题在于，一旦用户开始上手体验这个桌面版本，感受到的往往不是“产品终于成熟”，而是一种强烈的困惑——“用户体验为何会如此糟糕？”

新版桌面应用体验糟糕，基本无法正常使用

版本上线仅两天，开发者社区便涌现出大量密集的负面反馈。

用户报告指出，在 iOS 系统下，键盘会毫无征兆地卡顿失灵。甚至，最核心的代码输入框也会频繁消失，且几乎每次会话都会遇到此问题，用户不得不强制退出应用再重新启动才能暂时恢复。

Windows 版本的表现同样不尽如人意，频繁的界面卡顿和应用崩溃已成为常态。

界面设计问题也十分突出：按钮布局不符合用户直觉，聊天对话框频繁闪烁，整体交互体验极不稳定。

另一个关键问题是，一些本应最能体现 AI 编程效率优势的自动化功能，其自身稳定性就令人担忧。例如，有用户尝试使用 Routines 功能运行一个简单的数据库内容处理流程，结果无论如何配置，始终无法成功建立数据库连接。

许多用户的反馈非常直接：Bug 数量多到实际上已阻碍了任何有效的开发工作。

试用一小时，集中遭遇超过 40 个程序错误

很快，网络上便出现了一份详细的错误清单，其中列举了超过 40 个具体问题。更令人惊讶的是，这 40 多个问题，仅仅是用户 Theo 在一小时的集中试用过程中遇到的。

这些 Bug 大致可分为三类。第一类是快捷键与标签页逻辑混乱，许多快捷键仅在主标签页生效，切换标签时操作对象会莫名跳转；第二类是侧边栏与项目管理功能相互割裂，项目列表、最近项目、线程拖拽、菜单展开等方式互不协调，导致用户难以明确当前的操作目标；第三类则更为基础，属于功能本身未能实现，例如“打开文件”操作并未实际打开文件，创建分支（fork）时会连带生成工作树（worktree）却没有任何提示……

这些问题在清单中或许只是观感不佳，但一旦置于真实的开发任务中，便会立刻转化为一系列实际的使用障碍。

例如，在一个非常基础的场景中，让 Claude Code 分析一个应用可能存在的性能瓶颈。这原本只是一个入门级测试，尚未涉及真正的代码修改，系统就已表现出不稳定。任务启动后，首先会卡住近一分钟，随后智能体运行会随机停止，线程直接冻结，而界面上的状态图标却依然显示为运行中，造成一切正常的假象。

但实际上，进程已经停滞。用户界面没有任何错误提示、任务结束或失败通知。用户面对的是一个看似存活的线程，背后却是一个已经终止的流程。

这个问题的本质在于，其出错的“门槛”过低。并非在长链路、高复杂度的任务中失败，而是在一个本应最容易执行的基础场景里，将任务执行、线程状态和界面反馈这三件最基本的事情一并混淆了。这种状态错乱，即使在聊天应用中也是严重问题，放在开发工具中则更为致命。因为开发者最依赖的，恰恰是系统状态的清晰透明、反馈的准确无误以及操作结果的高度可预期性。

继续深入使用，在界面层面还会遇到更多问题。例如，在分屏模式下，当用户在右侧窗口进行操作时，打开的终端（terminal）却会出现在左侧分屏；而且终端一旦被激活，Tab 键会被当作输入键占用，导致用户无法便捷地切换回其他窗口。

同时，终端右上角的关闭按钮紧邻拖拽区域，使得那个“X”变得极难点中。这意味着，终端一旦被打开，不仅输入会受影响，想关闭它也异常困难。

此外，还存在一些极其荒谬、令人费解的程序错误：

• 在语音输入模式下，所有输入框都会自动接收文字，而不仅仅是当前被选中的那个。
• “查看更多（v more）”下拉菜单并非向下展开，而是向侧面展开（尽管箭头是指向下的）。
• “打开文件”操作会触发大约 15 种不同的行为，但没有一种行为是真正打开目标文件。
• 可以拖拽线程，但实际上永远无法改变它们的排列顺序。
• 可以在差异对比（diff）视图中，像套娃一样嵌套可折叠的侧边栏。
• 差异对比视图里的“x”按钮会关闭整个标签页，而不仅仅是关闭该视图。

……

Theo 在体验后评论道：“我很难相信那些声称已经使用这个应用好几周的人，真的用它进行过严肃的开发工作。我甚至还没开始用它修改代码，就已经连续遇到了五六个这样的 Bug，体验令人沮丧。”

“当前的问题是，许多用户似乎已经接受了这种质量水平。”即便市场上存在大量更稳定、功能更完整、甚至开源免费的 AI 编程工具替代方案，用户仍然在使用 Claude Code，很大程度上只是因为它绑定了强大的底层模型。“他们并非在为这个界面付费，而是为背后的模型能力付费，但结果却不得不忍受这个糟糕的客户端体验。”

100% AI 编写代码，落地产品质量堪忧

对此，另有网友尖锐评论：“一个整天宣称‘软件开发问题已经被解决了’的公司，做出这样的产品，确实颇具讽刺意味。”不过，这也从侧面说明，开发者的工作暂时还不会被完全取代。

毕竟，Anthropic 过去一年的对外叙事一直相当激进，其核心论点可以概括为：代码正越来越多地由 AI 生成，且这一比例持续攀升。从“80%到90%”，到“90%”，再到“100%”，数字一次比一次惊人。到了 2026 年初，“内部大多数产品基本已经是 100% AI 编码”的说法，已被他们反复提及多次。

• 2025年3月，CEO Dario Amodei 在美国外交关系委员会上表示：“再过3到6个月，AI 就会写出 90% 的代码。”
• 2025年5月，工程师 Boris Cherny 在播客《Latent Space》中透露：“整体来看，大概 80% 到 90% 的代码是 Claude 写的。”
• 2025年9月，Amodei 再次发声，但口径有所调整：“在 Anthropic，70%、80%、90% 的代码是 Claude 写的。”注意这个区间——70% 和 90% 是两回事，但媒体往往只抓住最高的 90% 进行报道。
• 2025年10月，Amodei 在 Dreamforce 大会上与 Marc Benioff 同台时称：“我之前预测过，六个月内 90% 的代码会由 AI 完成，现在已经实现了。”但在被追问后，他又补充道：“也不是所有情况都这样。”
• 2025年12月，Boris Cherny 在社交媒体上发文：100%。
• 2026年2月，首席产品官 Mike Krieger 在 Cisco AI Summit 上表示：“目前在 Anthropic，大多数产品基本可以说是 100%（由 AI 编写）。”
• 2026年3月7日，Boris Cherny 再次确认：“Claude Code 是 100% 由 Claude Code 编写的。”

问题在于，当这个“100%”真正落实到具体产品上时，情况就开始显得不对劲了。Claude Code 桌面版给人的感觉，不像一个经过精心打磨的正式产品，更像一个边开发边修补、仓促上线的半成品。关键不在于它偶尔出错，而在于它在最基础、最核心的使用路径上就已经摇摇欲坠，这才是最令人担忧的地方。

有人算了一笔账：这些工程师每天能获得一千万到一千五百万的 token 配额，最终产出的却是这样的代码质量。更令人困惑的是，从何时起，行业开始默认“能大规模生成高质量 token”就等于可以为了追求开发速度而完全牺牲软件工程的质量？

这种不满情绪，其实并非仅仅针对桌面版这一次的失败。回顾之前发生的代码泄露事件，问题早已暴露无遗。

其中一个反复被提及的文件是：print.ts。该文件仅包含一个函数，但这个函数足足有 3167 行代码，包含了 486 个分支判断，嵌套深度达到了惊人的 12 层。有人专门梳理了这个函数里塞进去的内容：智能体的运行循环、SIGINT 中断处理、限流逻辑、AWS 认证、MCP 生命周期管理、插件加载、通过 while(true) 轮询“团队领导”、模型切换、以及对中断的恢复机制……几乎所有核心逻辑，都被硬塞进了这一个函数里。而实际上，这些逻辑至少应该被拆分成 8 到 10 个独立的模块。

类似的情况不止这一处。QueryEngine.ts 文件达到了 4.6 万行，Tool.ts 接近 3 万行，commands.ts 也有 2.5 万行，入口文件 main.tsx 的单文件体积高达 785KB。问题并非出在某一段具体的代码上，而是整个代码库的结构本身，就已经处于失控状态。

在 userPromptKeywords.ts 文件中，这家公司用来判断用户是否“情绪崩溃”的方式，竟然是这样一段正则表达式：/\b(wtf|shit|fuck|horrible|awful|terrible)\b/i。也就是说，这家号称拥有最先进大语言模型的公司，在进行情绪识别时，采用的依然是最原始的关键词匹配。这就像一家现代化的卡车制造公司，却还在用马来运输零件。当然，也有解释认为，正则表达式更快、更廉价，不需要额外的推理调用，这在工程上是合理的选择。这话没错，但这恰恰说明这是一个“能跑就行”的工程决策。成本优先，速度优先，先上线再说。

工程文化是没有开关的。一个能写出 12 层嵌套、将所有逻辑塞进单一函数的团队，不会在编写模型训练代码或桌面应用时突然变得严谨起来。

这家公司一边销售 AI 编程工具，一边却无法用自己的 AI 编程工具打造出一个质量过关的产品。那些百分比数字，从一开始就更像是用于市场宣传的故事，而非产品交付的承诺。80、90、95、100——在源代码被公之于众之前，很少有人真正追问过，“100% AI 编写”究竟产出了什么样的代码质量。

AI 只是将原有的工程实践放大。原本拥有良好工程纪律，就会被放大为更优质的产出；原本缺乏纪律，则会以机器的速度被放大为沉重的技术债务。Anthropic 似乎选择了一条道路：追求更快，让 Claude 去检查 Claude 生成的代码。出了问题，那就再加快一点速度。

如果在一家致力于“构建未来”的公司里，“100% AI 编写”意味着一个包含 486 个分支、长达 3167 行的巨型函数，意味着一个充满无数 Bug 的桌面应用可以轻易上线，那么这个未来所需要的，或许不是更快的工程，而是更好的软件工程实践。

如果这就是一家正在引领 AI 编程行业方向的公司所代表的质量标准，那么这个方向本身，就值得整个行业进行深刻反思。

参考链接：https://x.com/theo/status/2044680030706663726