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

Claude Code 桌面版发布：一次令人失望的里程碑

Claude Code推出桌面应用，是Anthropic将AI编程工具推向主流开发者的必然一步。命令行界面（CLI）在特定场景下高效，但要实现高频、多任务并行的智能体编程（agentic coding），一个稳定、直观的图形用户界面（GUI）不可或缺。开发者需要同时管理多个线程、上下文切换和项目文件，一个响应迟缓、状态不透明的终端环境显然无法满足需求。因此，Claude Code桌面版的发布，本应是AI辅助开发领域一个关键的进化节点。

Anthropic对此次发布给予了高度重视。官方账号提前造势，社区期待数月，种种迹象表明，其目标是将Claude Code从一个功能性的命令行工具，重塑为一款成熟、完整的桌面产品。

然而，实际体验与预期形成了巨大落差。用户安装后产生的首要疑问并非功能是否强大，而是产品的完成度为何如此之低。

糟糕的初版体验：基础功能崩溃

应用上线仅两天，用户社区便被大量负面反馈淹没。

在iOS平台上，键盘输入会无故卡死。核心的对话输入框频繁消失，且该问题在几乎每次会话中都会复现，用户被迫反复重启应用以恢复基本功能。

Windows版本的表现同样不稳定，应用卡顿和意外崩溃是常态。

界面设计也存在明显缺陷：按钮布局反直觉，聊天窗口闪烁不定，整体交互缺乏稳定性。

更严重的是，一些核心的效率功能自身就不可靠。例如，有用户尝试使用Routines功能自动化一个简单的数据库处理流程，但该功能始终无法建立数据库连接。

用户的评价非常直接：Bug数量之多，已导致应用无法用于实际工作。

一小时内遭遇40余个缺陷

开发者Theo在社交媒体上分享了一份详细的缺陷清单，记录了他在短短一小时内遇到的40多个问题。

这些问题可归纳为三类。第一类是快捷键与标签页逻辑错乱，许多快捷键仅在主标签页生效，切换标签后操作对象会错误跳转。第二类是侧边栏与项目管理功能脱节，项目列表、最近文件、线程拖拽等交互逻辑不一致，导致用户无法明确当前的操作上下文。第三类则是功能实现失败，例如“打开文件”操作不执行，创建分支（fork）时静默生成工作树（worktree）等。

清单上的问题在真实编码任务中会立刻转化为障碍。例如，在一个简单的性能分析任务中，系统尚未开始修改代码，就已出现不稳定：任务启动后卡顿近一分钟，随后智能体运行随机停止，线程冻结，但界面图标却仍显示为运行状态。

进程实际上已经停滞。界面没有错误提示、没有结束状态，用户面对的是一个看似存活实则僵死的线程。问题的严重性在于其发生的“门槛”极低——并非在复杂任务链中出错，而是在最基础的执行、状态反馈和界面同步这三个核心环节上同时失败。这种状态不一致对任何开发工具而言都是致命缺陷，因为开发者依赖的是系统的确定性、透明性和可预测性。

进一步操作会暴露更多界面问题。例如，在分屏模式下，右侧窗口的操作会触发终端在左侧分屏打开；且终端一旦激活，Tab键会被占用，导致窗口切换困难。同时，终端右上角的关闭按钮与拖拽区域重叠，使得关闭操作异常繁琐。

此外，还存在一些令人费解的基础Bug：

• 语音输入模式下，所有输入框都会接收文字，而非仅当前焦点框。
• “查看更多（v more）”下拉菜单向侧面展开，而非向下。
• “打开文件”操作触发十余种行为，但无一真正打开目标文件。
• 线程拖拽功能形同虚设，顺序无法被改变。
• 差异对比（diff）视图中，侧边栏可以无限嵌套折叠。
• 差异对比视图的关闭按钮会关掉整个标签页，而非仅关闭视图。

……

Theo在体验后评论道：“很难相信那些声称已使用数周的用户真的用它完成了实质性工作。我甚至还没开始编码，就连续遭遇五六个此类Bug，体验令人沮丧。”

“现状是，许多用户似乎被迫接受了这种质量水平。”尽管市场上存在更稳定、功能更完善甚至开源免费的替代方案，用户仍因Claude强大的模型能力而选择忍受这个糟糕的界面。“他们支付的费用是为了模型能力，而非这个漏洞百出的客户端。”

100% AI编码背后的工程质量危机

有评论尖锐指出：“一家宣称‘软件开发问题已被解决’的公司，交付如此质量的产品，颇具讽刺意味。”但这恰恰证明，开发者的专业判断与工程经验远未被替代。

过去一年，Anthropic的对外叙事极为激进，核心论点是AI编写的代码比例持续攀升。从“80%-90%”到“90%”，再到“100%”，数字不断刷新。至2026年初，“内部大多数产品基本实现100% AI编码”已成为其反复强调的口号。

• 2025年3月，CEO Dario Amodei表示：“未来3到6个月，AI将编写90%的代码。”
• 2025年5月，工程师Boris Cherny透露：“整体上，约80%到90%的代码由Claude生成。”
• 2025年9月，Amodei调整口径：“在Anthropic，70%、80%、90%的代码由Claude编写。”媒体通常只报道最高的90%。
• 2025年10月，Amodei在Dreamforce大会上称：“我曾预测六个月内AI编写90%的代码，现已实现。”但补充说明并非所有情况均如此。
• 2025年12月，Boris Cherny在社交媒体发文：100%。
• 2026年2月，首席产品官Mike Krieger表示：“目前公司内大多数产品基本可视为100% AI编写。”
• 2026年3月7日，Boris Cherny再次确认：“Claude Code自身由Claude Code编写完成。”

然而，当“100%”落实到具体产品时，问题便暴露无遗。Claude Code桌面版给人的感觉并非精心打磨的成品，而是一个仓促交付、充满补丁的半成品。关键不在于偶发的错误，而在于其最核心的用户路径已然崩塌。

有分析指出，团队享有每日千万级token的配额，产出却是这样的代码质量。更值得深思的是，行业何时开始默认“大规模生成token的能力”可以成为牺牲代码质量、追求发布速度的理由？

这种不满情绪早有端倪。此前泄露的源代码已揭示了深层问题。

一个典型例子是`print.ts`文件。该文件仅包含一个函数，但长达3167行，内含486个条件分支，嵌套深度达12层。该函数被塞入了智能体运行循环、SIGINT处理、限流逻辑、AWS认证、MCP生命周期管理、插件加载、团队领导轮询、模型切换及中断恢复等几乎所有核心逻辑。这些逻辑本应被拆分为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编程工具，一边却无法用该工具构建出质量合格的自有产品。那些百分比数字，更像市场宣传的故事，而非质量承诺。在源代码公开前，很少有人追问“100% AI编写”背后的代码可维护性与架构合理性。

AI会放大原有的工程实践。良好的工程纪律会被放大为更高效的产出；而缺乏纪律，则会以机器速度积累成沉重的技术债务。Anthropic似乎选择了后者：追求更快，让Claude检查Claude。出现问题？那就再加快速度。

如果一家致力于定义未来的公司，“100% AI编写”的成果是一个486个分支、3167行的巨型函数，是一个充满基础Bug即可上线的桌面应用，那么未来需要的或许不是更快的工程，而是更好的工程。

如果这代表行业引领者的质量标准，那么这个方向本身就需要重新审视。

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