软件的 Emacs 化：AI 正在让每个人都变成自己软件的作者

原文来源：sockpuppet.org — 当 AI 代理能让你在 30 分钟内构建一个比 App Store 上更好的原生应用时，软件开发就进入了一个全新的时代。

你比你想象中更需要一个好的 Markdown 阅读器。

我们所有人都在大量阅读 Markdown。早在 LLM 出现之前，Markdown 就已经是软件开发界的通用语言了。但现在，AI 代理把我们带入了一个 TUI（终端界面）工具的魔幻文艺复兴，阅读体验变得令人难以忍受。我敢肯定，至少 14% 对 AI 代码的焦虑，单纯是因为人们受够了在终端里无休止地滚动 Markdown。

其实已经有不错的 TUI Markdown 阅读器了。Charm 团队做了 glow，我用过也很喜欢。我朋友 Josh 做了 Markless，界面漂亮、功能丰富，尤其是有目录导航。这些工具都很棒。但它们的上限被终端本身锁死了——终端几乎永远是等宽字体，读起来极其累眼。

图形界面 Markdown 编辑器也不错。在 macOS 上，有 Obsidian、Typora，还有我个人每天在用的 Bear。原生 UI 的 Markdown 编辑器美观且清晰，阅读体验很好。但是，它们是编辑器。我的编辑器住在特定的虚拟桌面里，窗口排列得整整齐齐。当我点开一个随机 .md 文件却打乱了我的编辑环境时，真的让人抓狂。

于是我去了趟 App Store，上面确实有 Markdown 阅读器。只能说「还行」，没有一个真正好用。我想要的只是双击 .md 文件时发生一件合理的事情。App Store 上的阅读器乍看合理，但用久了问题就暴露了——好几个不支持文本搜索，有的竟然还有内购（？！），我选定了一个，结果几天后才发现它居然不支持复制文本到剪贴板。至此，我的耐心耗尽了。

突然间，我意识到：找一个好的 Markdown 阅读器是一件蠢事。现在是 2026 年了，我完全可以自己「挤」一个出来。

❦

生成一个比 App Store 上任何 Markdown 阅读器都好的东西，只花了我几个小时，其中真正需要我动手的只有大约 30 分钟。剩下的时间，我在 Facebook 上吐槽城市规划政策，让 Claude 自己在那里吭哧吭哧地干活。这个就是 MDV.app。

我得坦白一点：这个时间线我稍微做了点铺垫，因为几周前我就做了些准备工作。我找了一台旧 Macbook 来跑 Claude，装好了 Xcode 和 git，配置好 Claude，还搜罗了一些 Swift 和 macOS 设计技能。但真正构建阅读器本身，从一个能用的版本到比 App Store 上更好的版本：只用了 30 分钟。

MDV 不是什么有史以来最好的 macOS 应用，甚至不算一个特别称职的软件（虽然它很可能确实是目前最好的专用 macOS Markdown 阅读器）。但它极大地改善了我的生活质量。

它能做很多酷事。Claude 和我搞定了选中并复制文档中的文本，以及在文档中搜索固定字符串的功能。不仅如此——MDV 还维护了一个 SQLite FTS 索引，记录所有历史 Markdown 文件（支持编辑），加上快捷键书签和目录导航。它会在重启后记住我在哪个文档里的阅读位置，支持不同文档间的切换。还提供了讲究的色彩主题和不错的排版——这才是专用 Markdown 阅读器最重要的功能。现在，我每次点击 .md 文件，这一切都自动生效。太棒了。

❦

我知道这件事意义重大，还有一个证据：每次有人给我发 Signal 消息，我的屏幕就会闪烁。闪烁不会停止，直到我手动隐藏 Signal 应用。而我总是忘记这么做，直到被微妙的闪烁折磨到偏头痛的边缘。

为什么会这样？因为 Signal 是一个 Electron 应用。它看起来像原生 macOS 应用，但其实不是——它是一个完整的 Chromium 副本，渲染着一个秘密网页。过去 10 年里，几乎每个 UI 应用都是如此，每一个都带着一个闪来闪去的 Chromium 副本。

Electron 不好。但它一直「足够好」。构建真正的原生用户界面从来都是一件难事，首先你得找得到能干活的人。能干的 macOS 原生 UI 开发者凤毛麟角。

但 Claude 不只是「能干活」水平的 SwiftUI 开发者。Claude 是真的厉害。

❦

这篇文章不是要宣告 Electron 即将死亡（要是那样就好了）。也不是要让你用我的超棒 Markdown 阅读器（安装很简单，比 App Store 上任何阅读器都好，你真的应该试试）。

等等——别装。把我这个超棒的 Markdown 阅读器当成 Emacs 用户眼中一份特别漂亮的 .emacs 配置就好了：偷走这个想法，做出一个更好的。

对于不了解的人来说，Emacs 的文化是这样的：它的终身用户用 elisp（世上最伟大的语言之一）构建完整应用。这些「应用」总是始于与文本编辑有关的私人需求，然后不断膨胀，超出任何「文本编辑器该做的事」的合理边界。如果你去看 /r/emacs，那上面 0% 是 Product Hunt，100% 是「你看我做了什么」。

也有一些流行的 elisp 包很多人都在用。但除了 Magit，程序员们惊人地倾向于用自己写的小众版本来替代它们（然后炫耀出来，进入 elisp 生命周期的孢子形成阶段）。Emacs 里的一切都是可塑的。

在此之前，Emacs 文化的致命弱点一直是——除了 Magit——它的包大多是糟糕的用户体验。丑、慢，而且只有在你用 elisp 给自己造成了几年的大脑皮层损伤之后才能发现它们。

但 AI 代理已经「压裂」了 Emacs 文化，它正在泄漏到外面的世界。有了屏幕和输入，AI 代理就能可靠地构建原生用户界面。原生 UI 曾经是专业打包程序的专属领域。现在，它变得和你自己的编辑器配置一样个性化。当然，我相信这些界面（用当前前沿模型）的质量是有上限的，但这个上限比你在 TUI 里能做到的任何东西都高得多。

❦

软件的「Emacs 化」意味着什么？我们来仔细看看。

首先，它意味着个人软件。大部分这类软件只对其创作者有用，然后被遗忘——就像散落在我 .emacs 里几十个过时的小 elisp 程序一样。个人软件定义了 Emacs 的精神内核，它经过几十年的精心设计，就是为了滋养这类工具。「Emacs 化」意味着现在一切都按这个方式运行了，不只是那些怪异的文本编辑器。

当然，偶尔会有一些程序「出圈」。它足够有用，不止一个人会装。但即便如此，发布的成品也不是其中最重要的部分。源代码也不是。如果一个代理写了我项目中的所有 SwiftUI 代码，你仔细读它能得到什么？

我可能只猜对了一点点，但我认为新 Emacs 包的一个重要驱动力是——你本地的凌乱配置和其他人的 elisp 代码之间的「催化反应」。一旦你学会了用 elisp 做事，构建自己的解决方案有时比 package-install 现有的方案更容易。在这样的环境里，代码本身只是过客。真正重要的是想法，是「对，你可以做这个，而且效果不错」这个观察。

对于我说的这类软件，你更需要的是提示词（prompts），而不是源代码。

如果你是一个接受「自己动手写软件」这个想法的程序员，那么现在一切都可以编程了——不是在技术意义上，而是在实践意义上。这引出了很多人在用代理创建软件时会有的一种感觉：你说你在「构建」它，这到底意味着什么？「构建」暗示了你付出的努力比你实际花费的更多。你做的事情感觉更像是「配置」，在一个突然变得极其可配置的平台上。一个感觉更像 Emacs 的平台。

❦

一个被 AI 说服的开发者在深入之后第一件告诉你的事，就是他们终于完成了多年来积攒的那些零散项目。

这本身已经足够令人兴奋了。但更关键的是，现在这些高度定制的软件，用起来也可以很愉快。我没有忽视其中的讽刺意味：Emacs 化正在瓦解很多让你忍受 Emacs 本身的理由，以及它那丑陋的用户界面。Magit 仍然是最棒的工具。暂时还是。

我不想对「软件的未来」做什么宏大的宣言。但我很确定，程序员的软件会变得有趣得多。有多少笨重的终端应用，我们能极其简单地大幅改善？我终于能看懂 iostat 了！甚至能跨多台主机看。还有 bpftrace！你看过 Brendan Gregg 为了在终端里做 bpftrace 可视化付出了什么代价吗？你再也不必忍受这些了。事实上，我也不用再忍了。

我是一名漏洞研究员，2026 年上半年，AI 编程在漏洞利用开发上的突破让我像个进了糖果店的孩子。但我明白这让我看起来像个怪人，对大多数人来说，伴随这些进步而来的是恐惧。

所以我很高兴能有一些新的、真正的好事可以聊。构建原生 UI 现在变得有趣了——比构建 Web 界面有趣得多。去试试，做点特别傻、特别针对自己问题的东西，享受它一会儿，然后在某个地方分享出来——或者，更好的方式是，只发一张截图和你写下的那些提示词。