Claude Code 桌面版烂爆了，Anthropic 终于把 “100% AI 编码”演砸了
Anthropic 终于还是把 Claude Code 做成了桌面应用
这件事的发生，其实并不让人意外。命令行界面（CLI）自有其价值，但若要将“智能体编程”（agentic coding）推向更广泛、更高频、更贴近日常开发的场景，图形用户界面几乎是必经之路。想象一下，当你需要同时处理多个任务、多个线程和多个上下文时，一个缓慢、卡顿且状态不透明的命令行，很难被视作理想的“最终形态”。从这个角度看，Claude Code桌面版的发布，本应是一个备受期待的里程碑。
Anthropic显然也对此寄予厚望。官方账号亲自下场预热，社区的讨论持续了数月，整个发布姿态都在传递一个明确的信号：他们正致力于将Claude Code从一个“可用的CLI工具”，升级为一个更完整、更正式的产品。
然而，真正的问题在于，一旦你开始上手体验这个桌面版，感受到的并非“终于成熟了”，而是一种强烈的困惑——“怎么会做成这样？”
新桌面版烂到根本没法用
新桌面版烂到根本没法用
版本上线仅仅两天，社区里便迅速涌现出一波密集的吐槽。
用户反馈指出，在iOS系统下，键盘会毫无征兆地卡住。有时，连最核心的输入框都会频繁消失，而且几乎每次会话都会遇到这个问题，用户不得不退出应用再重新进入才能恢复。
Windows版本的表现同样糟糕，频繁的卡顿和崩溃是家常便饭。
界面层面的问题也十分明显：按钮位置不符合用户直觉，聊天框频繁闪烁，整体交互体验极不稳定。
另一个突出的问题是，一些本应最能体现效率价值的自动化功能，其自身稳定性就令人堪忧。例如，有用户尝试使用Routines功能运行一个简单的数据库内容处理流程，结果无论如何尝试，始终无法成功连接到数据库。
不少用户的反馈直截了当：Bug多到实际上根本无法正常使用。
上手一小时，直接撞出 40 多个 bug
很快，网上就有人晒出了一份详细的Bug清单，里面罗列了40多个问题。更令人惊讶的是，这40多个问题，仅仅是用户Theo在一个小时的试用过程中集中遇到的。
这40多个Bug大致可以归为三类。第一类是快捷键和标签页逻辑混乱，许多快捷键只在主标签页生效，切换标签时操作对象会莫名其妙地跳转；第二类是侧边栏与项目管理功能彼此割裂，项目列表、最近项目、线程拖拽、菜单展开方式互不协调，用户很难搞清楚当前的操作对象究竟是什么；第三类则更为基础，属于功能本身未能实现，例如“打开文件”操作并未真正打开文件，创建分支（fork）时会连带生成工作树（worktree）却没有任何提示……
这些问题列在清单里或许只是观感不佳，但一旦放入真实任务场景，立刻就会转化为一连串实实在在的使用障碍。
例如，在一个再普通不过的场景中，让Claude Code分析一个应用可能存在的性能问题。这原本只是一个入门级测试，尚未涉及真正的代码修改，系统就已经开始表现出不稳定。任务启动后，首先会卡住将近一分钟，随后智能体运行会随机停止，线程直接冻结，而界面上的图标却依然显示为运行状态，仿佛在暗示一切正常。
但实际上，进程已经停滞了。用户界面没有任何提示，没有报错，没有结束，也没有失败。用户眼前是一个看似存活的线程，面对的却是一个已经死掉的流程。
这个问题的本质在于，它出错的“门槛”太低了。并非在长链路、高复杂度的任务中失手，而是在一个本应最容易跑通的基础场景里，将任务执行、线程状态和界面反馈这三件最基本的事情一并搞乱了。这种状态错乱，即使在聊天产品中也算得上严重问题，放在开发工具里则更为致命。因为开发者最依赖的，恰恰是系统状态的清晰透明、反馈的准确无误，以及操作结果的高度可预期。
继续操作下去，在界面层面还会遇到更多问题。例如，在分屏模式下，当用户在右侧窗口进行操作时，打开的终端（terminal）却会出现在左侧分屏上；而且终端一旦打开，Tab键会被当作输入键占用，导致用户无法再便捷地切换回其他窗口。
与此同时，终端右上角的关闭按钮旁边紧贴着拖拽区域，使得那个“X”变得极难点中。这意味着，终端一旦被打开，不仅输入会受影响，想关闭它也变得异常困难。
此外，还存在一些极其荒谬、令人费解的Bug：
- 在语音输入模式下，所有输入框都会自动接收文字，而不仅仅是当前选中的那个。
- “查看更多（v more）”下拉菜单根本不是向下展开，而是向侧面展开（尽管箭头是指向下的）。
- “打开文件”操作会触发大约15种不同的行为，但没有一种行为是真正打开目标文件。
- 可以拖拽线程，但实际上永远无法改变它们的顺序，在任何情况下都不行。
- 可以在差异对比（diff）视图中，像套娃一样嵌套可折叠的侧边栏。
- 差异对比视图里的“x”按钮会关闭整个标签页，而不仅仅是关闭该视图。
……
Theo在体验后吐槽道：“我很难相信那些声称已经使用这个应用好几周的人，真的认真用它干过活。我甚至还没开始用它修改代码，就已经连续撞上了五六个这样的Bug，感觉都快被逼疯了。”
“现在的问题是，很多人似乎已经接受了这种质量水平。”即便市场上存在大量更稳定、功能更完整、甚至开源免费的替代方案，用户仍然在使用Claude Code，仅仅因为它绑定了强大的模型入口。“他们不是在为这个界面付费，他们是为背后的模型能力付费，但结果却不得不忍受这个糟糕的界面。”
100%AI 编写，落地质量堪忧
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文件中，这家公司用来判断用户是否“情绪崩溃”的方式，竟然是这样一段正则表达式：/(wtf|shit|fuck|horrible|awful|terrible)/i。也就是说，这家号称拥有最先进大语言模型的公司，在进行情绪识别时，采用的依然是最原始的关键词匹配。这就像一家现代化的卡车制造公司，却还在用马来运输零件。当然，也有解释认为，正则表达式更快、更廉价，不需要额外的推理调用，这在工程上是合理的选择。这话没错，但这恰恰说明这是一个“能跑就行”的工程决策。成本优先，速度优先，先上线再说。
工程文化是没有开关的。一个能写出12层嵌套、将所有逻辑塞进单一函数的团队，不会在编写模型训练代码或桌面应用时突然变得严谨起来。
这家公司一边销售AI编程工具，一边却无法用自己的AI编程工具打造出一个质量过关的产品。那些百分比数字，从一开始就更像是用于市场宣传的故事，而非产品交付的承诺。80、90、95、100——在源代码被公之于众之前，很少有人真正追问过，“100% AI编写”究竟产出了什么样的代码质量。
AI只是将原有的东西放大。原本拥有良好工程纪律，就会被放大为更优质的产出；原本缺乏纪律，则会以机器的速度被放大为沉重的技术债务。Anthropic似乎选择了一条道路：追求更快，让Claude去检查Claude。出了问题，那就再加快一点速度。
如果在一家致力于“构建未来”的公司里，“100% AI编写”意味着一个包含486个分支、长达3167行的巨型函数，意味着一个充满无数Bug的桌面应用可以轻易上线，那么这个未来所需要的，或许不是更快的工程，而是更好的工程。
如果这就是一家正在引领行业方向的公司所代表的质量标准，那么这个方向本身，就值得深刻反思。
