Boris Cherny 谈尝试让 Claude Code 重写 Claude 应用

Anthropic 的 Claude Code 负责人 Boris Cherny 上周在 Y Combinator 的 Startup School 2026 舞台上接受了 Diana Hu 的采访。从视频约 20:30 处开始，他简要谈到了如何指挥 Claude 执行困难任务：

Cherny： 我认为，如今所需的技能已经不太是提示词工程，而更多是弄清楚：如何给 Claude 一个看起来有点超出它能力范围的困难任务？然后，如何让 Claude 能够在过程中验证自己的工作？在很大程度上，验证可能是人们最没有做对、却又最重要的一件事。

有一个例子是：我们有一款 Claude 桌面应用，它是用 Electron 构建的。我们已经让它变得相当快了。现在它的体验非常棒。六个月前，它很卡，也不太可靠。现在已经相当棒了，这是团队中大多数人都在使用的东西。作为一个实验，我想看看如果它是原生应用，体验会是什么样。因此，我启动了一个 Claude Tag 会话。Claude Tag 是我们的一款新产品，本质上就是运行在 Slack 中的 Claude。我的第一个问题是：“嘿，Tag，你是否可以访问 GitHub 上的 macOS runner？”它说不能。随后我接入了一个 runner。这样，它就能够通过 GitHub 启动一台 Mac 虚拟机。我的第二个问题是：我创建了一个空代码库，它是用 Swift 重写的 Claude 桌面应用。

我问：“你能访问这个代码库吗？”它说不能。随后我给了它访问权限，它说：“好的，很好，现在我可以访问了。”然后我说：“好的，现在我希望你做的是：把 Electron 应用重写成 Swift。我希望你在 Mac 虚拟机中运行 Electron 应用，对它截图，然后逐像素查看。把它与 Swift 版本进行比较。在完成之前不要停止。”

Hu： 这基本上就是你的提示词？

Cherny： 那就是我的提示词。

Hu： 这个任务运行了多久？

Cherny： 它还在运行。

Hu： 你是什么时候启动它的？

Cherny： 已经超过两周了，大概 14 天、15 天。

我想这件事确实有趣，但我不认为它的有趣之处，是一些向我发送这次采访链接的人所认为的那种有趣。我不认为这是一次认真打造真正原生 Claude Mac 客户端的尝试。如果确实是，Cherny 的做法也完全错了。

当前 Claude Mac 客户端的问题，并不只是它使用了臃肿的非原生框架这一技术细节。真正的问题在于：这是一款设计很差、又使用臃肿非原生框架编写的应用。它的设计本身就是非原生的。除了无视大多数 Mac UI 规范以外，它在抽象意义上也只是一个糟糕的设计。它在网页端很糟糕，在 Windows 上很糟糕，因此当然在 Mac 上也很糟糕。因此，让 Claude Code 对着当前 Electron 应用，并要求它用 Swift 逐像素重建，充其量只能解决当前应用的技术问题，而无法解决设计问题。如果 Claude 经过良好设计、但仍使用 Electron 编写，我会比它移植到 AppKit 和/或 SwiftUI、却保留完全相同的现有设计时更愿意使用它。当前 Claude 应用就像一道用劣质食材做出的糟糕菜谱；Cherny 要 Claude Code 做的，是用更好的食材遵循这道糟糕菜谱。它吃起来依然会很糟糕。

而且，这项任务失败大概也不足为奇。AppKit 和 SwiftUI 是用来创建 Mac 风格应用的。试图用它们复刻完全不像 Mac 的 Claude UI，就像逆着头发生长方向梳头一样。这不是事物应有的运行方式。

我也不能略过 Cherny 对当前 Claude Mac 应用的那句附带评价： “六个月前，它很卡，也不太可靠。现在已经相当棒了。”我刚刚在 Mac 上启动 Claude 应用，它花了 30 秒才达到可用状态。其中最后 15 秒，它显示的是旋转的彩虹球光标。它终于完成后，向我显示了一个 dickover。也许它六个月前确实更糟，但这绝不是“相当棒”。

★ 2026 年 8 月 2 日，星期日

Boris Cherny, head of Claude Code at Anthropic, was interviewed by Diana Hu on stage at Y Combinator’s Startup School 2026 last week. Starting around 20:30 in the video, he briefly discussed directing Claude to perform difficult tasks:

Cherny: I think the skill nowadays is less about prompt engineering and more about figuring out how do you give Claude a hard task that seems a little bit too hard. Then how do you make it possible for Claude to verify its work along the way? The verification is probably the single most important thing that people do not get right, largely.

One example of this is people were — we have this desktop app for Claude and it’s built using Electron. We’ve made it quite fast. Now it’s a pretty awesome experience. Six months ago it was sluggish and it wasn’t very reliable. Now it’s pretty awesome. It’s the thing that most of the team uses. As an experiment, I wanted to see what it would feel like if it was native. So what I did is I started a Claude Tag session. Claude Tag is a new product we have. It’s just Claude running in Slack. My first question was, “Hey Tag, do you have access to a Mac OS runner on GitHub?” It said no. Then I hooked up a runner. So it was able to start a Mac virtual machine using GitHub. My second question was, I created this empty code base that was a Claude desktop app rewritten in Swift.

I asked, “Can you access this code base?” It said no. Then I gave it access and it was like, “Okay, great. Now I have access.” Then I said, “Okay, now what I want you to do is I want you to rewrite the Electron app in Swift. I want you to run the Electron app in the Mac virtual machine, screenshot it, and then look pixel by pixel. Compare it to the Swift version. Don’t stop until you’re done.”

Hu: And that was your prompt basically?

Cherny: That was my prompt.

Hu: And how long did this take to run?

Cherny: It’s still running.

Hu: When did you start it?

Cherny: It’s been a little over two weeks. So it’s like 14 days, 15 days.

I suppose this is interesting, but I don’t think it’s interesting in the way some people sending me links to this interview think it is. I don’t think this is a serious effort to create a truly native Mac client for Claude. And if it is, Cherny is going about it all wrong.

It’s not like the problem with the current Claude Mac client is merely the technical detail that it’s written with a bloated non-native framework. The actual problem is that it’s a poorly designed app written with a bloated non-native framework. The design itself is non-native. And aside from ignoring most Mac UI idioms, it’s just a bad design in the abstract. It’s bad on the web, bad on Windows, and thus of course it’s also bad on the Mac. So pointing Claude Code at the current Electron app and directing it to recreate it in Swift — pixel-by-pixel — could at best solve only the technical problems with the current app, not the design problems. I’d be more likely to use Claude if it were well designed but still written using Electron, than if it were ported to AppKit and/or SwiftUI but with exactly the current design. The current Claude app is like a shitty recipe made with shitty ingredients; what Cherny asked Claude Code to do is to follow the shitty recipe using better ingredients. It’s still going to taste like shit.

And it’s probably no wonder the task failed. AppKit and SwiftUI are made to create Mac-style apps. Trying to use them to recreate the utterly un-Mac-like Claude UI is like trying to brush your hair the wrong way. It’s not the way things are meant to go.

I also can’t let pass Cherny’s aside, re: the current Claude Mac app, that “Six months ago it was sluggish and it wasn’t very reliable. Now it’s pretty awesome.” I just launched the Claude app on my Mac, and it took 30 seconds before it was ready to use. The last 15 seconds of which, it showed the spinning beach ball cursor. When it finally finished it showed me a dickover. Maybe it was worse six months ago but this is not “pretty awesome”.

★ Sunday, 2 August 2026