← All Articles

A Desktop Made for One — 用 Claude Code 重写整个桌面环境的 BYOS 实践 + HN 讨论精读

Geir Isene · Original

挪威工程师 Geir Isene 用几周时间，配合 Claude Code 重写了自己几乎整个桌面环境——窗口管理器、状态栏、屏锁、终端、Shell、文件查看器、文本编辑器、文件管理器、邮件 / RSS / 聊天客户端、日历、天文面板、影视索引——全部换成自己写的。用 25 年的 vim 在 72 小时内被替换。文章 5 月 4 日上 HN 拿 371 分 + 201 条评论。

核心论断：以前”写自己的编辑器 / 文件管理器 / 窗口管理器”是几年的工程；现在 LLM + Rust + 文档充足让这件事压缩到 “一个周末”。这不是关于 AI 的故事，是关于”我希望我的工具做 X”和”好，这就是一个做 X 的工具”之间的 gap 缩到能在几个晚上覆盖。

文章在讲什么 — 一个具体的 BYOS 案例

作者用两层架构：

CHasm 层（汇编 x86_64，无 libc，画像素 + 读键盘）：

角色 原来 现在（自己写的）
窗口管理器 i3-wm tile
状态栏 / tray i3bar + conky strip + asmites
屏锁 i3lock bolt
终端模拟器 kitty glass
登录 Shell zsh → rsh bare
文件查看器 less show

Fe₂O₃ 层（Rust + 自己的 TUI 库 crust）：

角色 原来 现在
文本编辑器 VIM（25 年） scribe
文件管理器 ranger → RTFM pointer
邮件 / RSS / 聊天 mutt + newsbeuter + 各种 web 客户端 kastrup
日历 Google + MS web tock
天文面板 astropanel astro
影视索引 IMDB-terminal watchit

剩下没换的：WeeChat（IRC 和聊天）+ Firefox（唯一还在用的 GUI 程序）。其他全是自己的。

“vim 之线”——25 年肌肉记忆 72 小时被替换

这是文章最有冲击力的一段。

“vim 是我以为永远不会替换的那个。我从 2001 年开始用——25 年里每一封 email、每一篇文章、每一行代码、每一本书都过 vim。肌肉记忆深到我会在浏览器里随便一个文本框最后打 :w。”

“然后三天里我有了 scribe，停止使用 vim。 第一次 commit 是 5 月 1 日 00:09。到 5 月 3 日下午，vim 被替换。25 年的肌肉记忆 72 小时改道。”

为什么 scribe 能赢——它不是更好，是更自己。

为什么这件事现在可能 — 三件事的合力

作者拒绝把这归功于 AI 单一原因。真正的 enabler 是三件事一起到位：

  1. Rust — 系统级编程语言但带现代 ergonomics
  2. Claude Code 作为 workhorse — 主 session 给方向，CC 在后台跑
  3. TUI 编程的硬问题已经被记录到死 — 文档充足，不需要从零学

“我不认为这是个 AI 故事，也不是个 Rust 故事。两者都帮忙。但更深的点是：‘我希望我的编辑器做 X’ 和 ‘好，这是一个做 X 的编辑器’ 之间的 gap 现在小到能装进几个晚上的专注工作”

“Audience of One” 的快乐 — 不用 care 的解放

作者的核心论断不是”我做了酷炫的东西”，是”做给一个人用的解放感”：

“软件复杂度的巨量来源是配合那些不是你的用户。把这层剥掉，剩下的东西就小、快、形状精确、用着是种安静的愉悦”

作者明说不卖任何东西：

“请别用我的软件。它不是为你建的——是为我建的，为我握手的方式、思考邮件的方式、想要日历渲染的方式。”

HN 201 评论的几条主线

主线 1：BYOS 概念的”重新发明”质疑

最早顶帖 utopiah 怼：“我管它叫’软件’。从 1960 年代 BASIC 开始，包括 Logo（Feurzeig/Papert/Solomon），就一直在帮新手写软件——目的不是培养未来的开发者，是让 personal computer 的 personal 真有意义。我们一直在重新发现基础”。

作者立场：personal computer 上的 personal software 不是新概念。新的不是”能做”，是”做得动的成本”。

主线 2：怀疑派——为什么不是 OSS / Linux？

Ygg2: “这就是 OSS / Linux 啊。问题是没人会为你的 PC / 手搭 OS 发软件。你不可能不浪费大量时间就把 OS 每个零件都写一遍”。

反驳（utopiah）：OSS 是”我们的”软件（made by us for us），audience-of-one 软件是”你的”软件（made by you for you）——精神不同。

主线 3：怀疑派——LLM 之前人们也在写个人软件

nz（25 年从业者）：“人们已经为个人用途写定制软件几十年了。我从 2009 年起就在做。我难以相信存在一个’渴望写代码但缺 LLM 就写不了’的群体。是因为价格？人们太抠不愿买书？还是已经忘了怎么耐心阅读？”

最锋利的反驳（dpark / JodieBenitez / Agingcoder / cwnyth / theshrike79）：

“Yes, because the price is measured in time. 用 LLM 工具我快速搞出适合自己用例的怪工具——一天而不是一周；一周而不是几个月。快速周转改变了为自己写工具的经济学”

“我们不缺 LLM, 我们缺时间和精力。 … 用 LLM 我得到更好结果，更快，付出更少努力——这是’另一个躺在我未完成软件清单里、消耗了太多周末’ 和 ‘一个酷工具/玩具/有用的东西，几个有趣的对话 session 就出来了’ 的差别”（25 年从业者 JodieBenitez）

“我有个工作和家庭和音乐爱好和 yadda yadda yadda。AI is a game changer for actually accomplishing big dreams I just didn’t have the time to bring about to fruition”（cwnyth）

“我可以以 5-15 分钟的爆发干一天几次 make meaningful progress on personal projects——以前根本做不到从日常工作 context shift 出来”（taude）

主线 4：LLM 作为”反向词典”（reverse dictionary）的真正价值

mrob 提了个被 prplxd_nihilist 称为 “LLM 最好用例” 的方向：

“我还记得初学时 man pages 多难懂。最大障碍是大部分文档是为已经懂标准 CS 术语的人写的。LLM 一个真正擅长的事情是当’反向词典’——你可以输入对某事物的特异描述，得到标准术语。这是一个新的、有价值的能力”

主线 5：这是”不写更多代码”，是”想要工具按特定方式工作”

SmirkingRevenge：“对我来说不是渴望写更多代码，是渴望按特定方式工作的工具。我工作里写够了代码，业余不想写更多，除非情绪真的强烈”。

vessenes：“我们要进入一个能 shape 自己工具的时代——artisanal 而不是 factory-created 工坊”。

主线 6：习俗 vs 革命的辩论

blks 怼 vessenes：“过去 50 年我们处于什么时代？”

vessenes 给了个清晰的历史分层回答： - 1995 年开始：由约 1000 个开发者（多为开源）提供 quality tooling——GNU / Xorg / Apache / emacs / nginx 等。或者你可以加入 Microsoft 生态 - 1995 之前 20 年：选 Microsoft / IBM / 专属 Unix 厂商 - 现在新的是：你可以让一个按你自己规格写的窗口管理器在一周内出来，不只是从几个主要选项里挑然后用大开发团队提供的配置

主线 7：skydhash 的反对——“我的用例已经被解决了”

“我不太写代码因为我的用例已经被解决了。如果没解决我会调整最合适的候选。我的原则之一是保持工作量小。为什么要 replicate 别人已经做过的？”

theshrike79 的精彩反驳：

“如果别人盖了整栋房子但我只偶尔需要厨房桌子，我得忍受拥有整栋房子的麻烦只为了用那张桌子。而且桌子形状还不对——我能凑合用。要别人改桌子让它可调要走 PR 和邮件列表的麻烦。

现在我能在一两个晚上做一张精确符合我需求的桌子。

我以前也能做，但太久不值得，所以将就用了房子带桌子。”

拧巴的地方 / 我的怀疑

  1. 作者 25 年的 vim 经验是个隐藏前提 — 文章的”72 小时替换”叙事有戏剧性，但 Geir Isene 不是普通用户：他自己写过 RTFM（一个文件管理器），有汇编 + Rust 经验。对于不会编程的普通人，BYOS 的”几个晚上”门槛仍然不存在。文章把自己的能力当 baseline，没说清这点
  2. “工作流稳定”是隐藏前提 — 作者能 72 小时替换 vim 是因为他精确知道自己想要什么（25 年使用习惯）。如果你的需求还在演化，自己写工具反而是负债，因为你随时要重写。文章没讨论这点
  3. 维护 / 升级 / 安全性问题完全没碰 — 自己写的窗口管理器有 bug 怎么办？操作系统升级 break 了 syscall 怎么办？被 0day 攻击怎么办？你成了 single point of failure
  4. 可移植性 / 多设备问题 — 作者的整套工具能不能在另一台机器（不同发行版、ARM Mac 等）上跑？文章没碰
  5. HN 顶帖说的”interoperability”是真问题 — 自己写的工具如果不能跟外部生态对接（导出标准格式、被脚本调用），价值会缩水。作者说他用 plain text + sqlite，但具体的标准合规性没说
  6. “Audience of one”作为产品哲学是真的，但作为商业模型是死的 — 文章自己说”please don’t use my software”。问题是这种 BYOS 浪潮如果普及，会不会瓦解很多商业软件的市场？
  7. HN 几条精彩反驳被埋在评论流里 — Ygg2 的 OSS 论 + skydhash 的”已经被解决”论 + utopiah 的”重新发现基础”论。作者文章给读者的是 cherry-picked 视角，没真正回应这些质疑

跟 Justin 已有笔记的连接

最强连接（你自己就是这文章的活案例）：

你的 CC harness 本身就是 BYOS 的实践——

作者的”vim 72 小时被替换”对应你自己的什么场景？

这篇文章对你的真实意义不是”原来还能这样”——而是”原来还有这么多人在做同样的事”。HN 371 分 201 评论说明这是个已经在普及的潮流，不只是个体经验。

弱连接：

  1. mental-models.md “Harness 双轴” entry —— BYOS 浪潮直接对应”个人化层 harness”（encoded preference）。作者的 audience-of-one 软件就是 encoded preference 的极致形态——所有决策都是”我要什么”。模型升级不会让这层失效，反而让 BYOS 变得更便宜
  2. 拾象月更时代笔记 Insight 05（Bottleneck 在人） —— 文章里”time and energy”的反复强调直接呼应。LLM 解决了”想做但没时间做” 这个 bottleneck——不是替代人，是放大人能做的范围
  3. DS4 精读”高压水枪浇花”段 —— 作者文中不需要专门讨论 token 浪费，因为 BYOS 软件特点是”刚好够用”。这跟 DS4 反思”被 infra 优化惯坏了”是一个意思的两面——一边在浪费 token，一边在精确生产
  4. Karpathy Skill Issue 第 12 节”机器人：sensor / actuator 是中间机会” —— BYOS 是”软件 actuator”层的中间机会。机器人的 actuator 是物理执行器，软件 BYOS 是数字执行器。两者都是 LLM 之上的 lubrication 层

最值得记住的几条原话

作者： > “Decisions take seconds” —— 受众是一个人时，决策按秒计算 > “An enormous amount of software complexity comes from accommodating users who aren’t you” —— 软件复杂度的巨量来源是配合那些不是你的用户 > “The gap between ‘I wish my editor did X’ and ‘okay, here’s an editor that does X’ is now small enough to fit inside a few evenings” —— “我希望”和”好这是一个做 X 的编辑器”之间的 gap 现在能装进几个晚上

HN 评论： > “Yes, because the price is measured in time” —— dpark > “We didn’t lack LLMs, we lacked time and energy” —— JodieBenitez > “AI is a game changer for actually accomplishing big dreams I just didn’t have the time to bring about to fruition” —— cwnyth > “Now I can build a bespoke table in an evening or two” —— theshrike79（vs 之前是用别人房子带的桌子）

投资视角的 takeaway

  1. BYOS 浪潮是真的，但商业模型有限 —— 作者说”please don’t use my software”。这种浪潮可能瓦解中端 commodity 软件市场（笔记应用 / 个人 dashboard / 待办工具等），但不创造新公司
  2. 真正赚钱的可能是”BYOS 的 enabler”层 —— 让普通人能搞 BYOS 的工具：
    • Cloudflare / Vercel 这种部署 infra（作者就提了 Tailscale + Cloudflare）
    • Anthropic / OpenAI 这种底层 LLM
    • Cursor / Claude Code / Codex 这种 agentic coding 入口
    • 小型本地 host 工具（让 BYOS 更易跑在自己机器上）
  3. “作家工具”垂直机会还在 —— 作者花 3 天就替换了 vim，但他用的是自己 25 年累积的偏好。普通作家不会写代码，所以”AI 帮你做你的私有 vim”这个角度的产品有空间——比如让用户描述偏好 + 一键生成 Electron 编辑器
  4. 企业版 BYOS 是大机会 —— 公司里的”shadow IT”（员工用自己 Excel 工具完成工作）是 BYOS 的雏形。让公司内每个团队 / 个人能快速 BYOS 内部工具，但保持治理 / 合规 / 备份——这是真大市场

17 条 BYOS 实操经验（按主题分组）

A. 工程架构 / 工具开发法

  1. 两层架构分离 — 底层 + 应用层：作者用 CHasm（汇编层）+ Fe₂O₃（Rust 应用层 + 共享 TUI 库 crust）。底层是稳定 substrate，应用层快速迭代
  2. 共享库是关键：crust 是所有 Fe₂O₃ 应用的共享 TUI 库——先抽公用部分做成库，再写各个具体应用
  3. 一次替换一个工具，别整体重写：“One tool at a time”——从最不依赖的工具开始（状态栏 / 屏锁 / 文件查看器），最后才碰 vim（25 年最依赖）

B. 设计哲学 — Audience-of-One 实操

  1. 砍掉 90% 你从来不用的功能：scribe vs vim。开始替换前列出”我实际用了哪些 feature”，只这些进入 v1
  2. 加 vim 永远没加的几个小调整：作者列了 4 个——默认软换行 / Limelight 风格专注阅读模式 / prompt 内嵌 AI 不离开 buffer / 持久化寄存器跨 session 共享。每个工具问自己”我用 X 多年里有哪 3-5 个’要是有这功能就好了’的小调整”——这些才是 BYOS 的真价值
  3. 默认就是设计，别做 configurable：“Decisions take seconds”——受众是一人时决策按秒计算。BYOS 工具默认值就是终值，不要预留 config 选项
  4. 不写为不存在用户的文档：不要 README / user guide / issue tracker。记不住的功能 = 不必要的功能（要么删，要么 cheatsheet 挂在工具里）

C. LLM 协作工作流

  1. 主 session 给方向，CC 在后台跑：“I direct CC, it works while I do other stuff. I get a second or few in between tasks, and I respond. Then off it goes adding features or hunting bugs”
  2. 时间碎片化的真实数字：HN 评论 taude——5-15 分钟爆发，一天几次，能在 personal projects 上 make meaningful progress。BYOS 不需要整块 4 小时，把任务切到 15 分钟级 5-10 个碎片就够一个 feature
  3. 反向词典用法（HN 高赞）：mrob/prplxd_nihilist——输入对某事物的特异描述 → 得到标准 CS 术语。你不知道某机制的标准名时，描述给 LLM → 拿到术语再去查官方文档

D. 工程上的具体决策

  1. 选 Rust 而不是 Python / JS：作者用 Rust 是因为 TUI 性能 + 长期维护成本低 + Claude Code 跟 Rust 配合好。BYOS 工具如果是命令行/TUI/系统级，Rust 是 sweet spot；web/GUI 用 Tauri 或 Electron + TS
  2. plain text + sqlite + 开放标准（HN 评论 redfloatplane 强建议）：“typically, use sqlite, use plaintext, use open standards”——作为 standing instruction 给 CC。理由：未来工具死了 / 自己想换 / 跟其他工具对接，数据还能拿出来
  3. ops / observability 不能省（HN 评论 redfloatplane）：很多人想要 personal software 但不想 care for maintenance。BYOS 工具至少要做：errors 写到 log、关键操作有 audit trail、能 backup 自己状态、出 bug 能查
  4. 接受一些工具不替换：作者明说”What’s left? WeeChat for IRC and Firefox” 还在用。列一个”明确不 BYOS”的清单——浏览器 / 邮件传输协议 / 操作系统内核 等

E. 心理模型 / 失败避免

  1. 不要把”重写”变成”完美主义陷阱”：作者”3 天替换 vim”不是因为 scribe 完美，是因为 scribe 把作者最常用的 80% 做对了，剩下 20% 边写边补。BYOS 是 ship and iterate
  2. 替换 vs 增强 — 优先增强：HN 评论 skydhash——“为什么要 replicate 别人已经做过的？我会调整最合适的候选”。先尝试改现有工具的 plugin / config，改不动再 BYOS
  3. theshrike79 的”桌子”测试：“整栋房子带一张形状不对的桌子 vs 一两个晚上做一张精确符合需求的桌子”。判断要不要 BYOS——核心问题是”这工具的 90% 你只想要其中 10%（一张桌子）吗？“是 → BYOS 划算

Justin 已在做的 vs 还可加强

已在做（你的 CC harness）： - 共享库（_shared/research-primitives）✓ - 一次扩一个 skill ✓ - 默认即设计（硬编码触发词）✓ - plain text + sqlite + 开放标准 ✓ - 主 session 给方向 + agent 后台跑 ✓ - 不为不存在的用户写文档 ✓

可能值得加强： - ops / observability：CC harness 出问题你能多快查到？skill 之间调用链有 audit trail 吗？vec-search 失败有 alert 吗？ - standing instructions for interoperability：你给 CC 的全局 prompt 里有没有强制”数据必须 plain text / open standard / 可导出”这条？ - 明确不 BYOS 的清单：哪些工具明确不会自己造（不会自己写浏览器 / 不会自己写编辑器）？ - 15 分钟爆发的工作流：有没有清单”这些任务可以 5-15 分钟做完”vs”这些必须 1 小时整块”？

一句话总结

A desktop made for one 不是关于 AI 替代程序员的故事，是关于”我希望我的工具做 X” 和 “好，这就是一个做 X 的工具” 之间的 gap 缩到能装进几个晚上的故事——LLM + Rust + 文档充足三件合力让 BYOS 从”几年的英雄工程”变成”几个周末的乐趣”，受众是一个人时决策按秒计算，软件复杂度的大头是配合不是你的用户。