一、作者画像：David Crawshaw 是谁？
David Crawshaw 是一位资深的系统程序员和创业者。他曾在 Google 工作多年，参与了 Fuchsia 操作系统、Google+ 等项目的开发，也是 Tailscale 的联合创始人之一（VPN/网络安全领域非常成功的产品）。2026年，他又创办了 exe.dev，致力于打造"真正好用的云"。
Crawshaw 的写作风格极为鲜明：技术深度 + 哲学思考 + 个人叙事。他不写"10个Go最佳实践"这类快餐文章，而是分享自己多年来在技术前沿的真实实践、失败教训和深层观察。他的文章往往从一个具体的技术问题出发，最终抵达对软件行业、甚至社会趋势的深刻判断。
Crawshaw 的技术背景：
- Google 资深工程师（Fuchsia OS、Google+）
- Tailscale 联合创始人（网络安全/虚拟组网）
- exe.dev 创始人（为 Agent 时代重新设计云基础设施）
- Go 语言深度用户和贡献者（sqlite 绑定、CGO 优化等）
- 从底层系统到前端产品的全栈能力
二、博客文章全景图
crawshaw.io 从 2014 年到 2026 年，累计发表了约 50 篇文章。这些文章可以按照主题划分为六大板块：
2.1 六大主题板块
- AI / LLM / Agent 革命（2025–2026，4篇核心长文）—— 最前沿的实践复盘
- 云计算与基础设施（2026，2018）—— exe.dev 的理念、单进程编程哲学
- Go 与 SQLite 工程（2016–2019，约10篇）—— 编译器、运行时、数据库接口设计
- 软件工程哲学（2018–2021）—— 兼容性、实验文化、Finalizer、日志
- 互联网与社会观察（2018–2020）—— 创意互联网、LAN怀旧、身份不对称
- 个人成长与选择（2015–2018）—— 离开Google、遗憾推理、写作
2.2 最值得精读的 10 篇文章
- 2026-04I am building a cloud —— 为什么今天的云是"错误形状"的
- 2026-02Eight more months of agents —— Agent 编程八个月深度复盘
- 2025-06How I program with Agents —— Agent 定义、实践与容器化未来
- 2025-01How I program with LLMs —— 自动补全、搜索、对话式编程
- 2020-01Remembering the LAN —— 90年代 LAN 的魔法与 Tailscale 的起源
- 2018-07One process programming notes —— 单进程哲学：1 VM + 1 Zone + Go + SQLite
- 2018-07Reasoning with Regret —— 用"80岁的自己会后悔什么"来做决策
- 2018-05Searching the Creative Internet —— 创意互联网被商业搜索淹没了
- 2018-04The Tragedy of Finalizers —— 为什么 Finalizer 几乎不可能用好
- 2018-03Experimentation Adrift —— Google+ 的 A/B 测试为什么失败了
三、主题一：AI / LLM / Agent 革命（2025–2026）
这是 Crawshaw 博客最近、最密集、也是最有价值的部分。作为一个每天真正用 Agent 写代码的创始人，他的观察比任何评论员都更有说服力。四篇文章构成了一个完整的认知框架。
3.1 Agent 的进展：模型能力是一切
核心数据点：
| 时间点 | 模型 | Crawshaw 代码占比 |
|---|---|---|
| 2025年2月 | Claude Code（早期） | 约 25% |
| 2026年2月 | Opus（最新） | 约 90% |
工作模式转变：大公司 80:20（读:写）→ 创业 50:50 → Agent 时代 95:5
Crawshaw 的判断非常犀利：Agent harness（框架）没有太大进步，他自己六个月前的 Sketch 能做的事情，今天最流行的 Agent 也做不到。他将框架创新比作"1990年代兆赫兹爆发时期的编译器优化"——重要，但不是最激动人心的。真正改变一切的是模型本身。
可学习之处：
- 忽略公共 benchmark——它们都被刷爆了。关注定性的、来自真实使用的感受。
- Agent = 9 行代码——一个包含 LLM 调用的 for 循环，让模型能执行命令并看到输出。简单得令人震惊，但效果惊人。
- Agent 是"有环境反馈的 LLM"——bash、patch、web_search、codereview 等工具让 LLM 从"白板编程"变成了"有编译器、有 grep、有测试的编程"。
3.2 IDE 正在衰落
Crawshaw 对 IDE 的历史做了一个精辟回顾。他认为 VS6.0 + Windows 2000 是他用过的最棒的 IDE，完美、完整、一致。但后来编程环境变成了"一团糟"（a hot mess）。
2021年 Copilot 发布后，IDE 似乎不可战胜——LLM 辅助的自动补全太强大了，让人不得不忍受 IDE。Crawshaw 说 Copilot 让他的"打字效率提升 50%"，编程很大程度上是打字受限的。
仅仅四年后，他回到了 Vi——而 Vi 今年正好 50 岁。他现在唯一用的"IDE 功能"是 go-to-def，neovim 稍加配置就能实现。
核心洞见：Agent 不是让 IDE 变得更好，而是让 IDE 变得不必要。当 AI 可以直接理解整个代码库、执行命令、修改文件时，IDE 提供的语法高亮、自动补全、项目管理等功能已经微不足道。轻量级编辑器 + 强大 Agent > 最复杂的 IDE。
3.3 非前沿模型是"主动有害"的
Crawshaw 的措辞非常严厉：用便宜模型（如 Sonnet）或二流本地模型，不仅浪费时间，还会学到错误的经验教训。因为 Agent 工作很大一部分是"发现模型的能力边界"，如果用弱模型探索边界，你会形成错误的认知——这会严重拖累你使用前沿模型时的效率。
但他也相信本地模型终将胜利——当前沿模型面临收益递减时，本地模型会迎头赶上。那一天会很美好，但在到来之前，你必须用最好的模型才能知道模型真正能做到什么。
3.4 内置沙盒不起作用，Fresh VM 才是答案
Claude Code 不断请求"may I run cat foo.txt?"的许可，Codex 说"无法在我的复杂沙盒中执行 go build"。这种内置沙盒的设计本意是安全，但实际体验是灾难性的——不断打断工作流。
解决方案：Fresh VM
- 完整的环境控制权——Agent 可以执行任何需要的命令
- 真正的隔离——不会影响主机系统
- 可抛弃性——用完即弃，保持环境纯净
- 这正是 exe.dev 的核心设计动机之一
3.5 编程乐趣回来了：从 TODO 到真实程序
Crawshaw 说他现在拥有的程序和服务比以前多得多。他需要一个 VM，里面运行着一个不受约束的 Agent，可以随手启动，然后把原本会写在 Apple Notes TODO 里、然后遗忘的一句话，变成一个真实可用的程序。
3.6 反 LLM 论点如同"禁止电动工具"
Crawshaw 承认恐惧本身——他对"智能即服务"在社会中的终极走向也有担忧。但在"编写计算机程序"这个有限领域内，这些工具带来了前所未有的探索和乐趣。
3.7 软件的形状需要彻底改变
Crawshaw 的核心判断：大多数软件的形状是错误的，大多数解决问题的方式也是错误的。
Stripe Sigma 案例：三句话打败一个产品
- Stripe Sigma 是为 Stripe DB 提供的 SQL 查询系统，内置 LLM 辅助写查询
- 但这个 LLM 不太好，而且 Sigma 先推出了 UI，API 还在 private alpha
- Crawshaw 让 Agent 从零开始做 ETL：用标准 Stripe API 查询账户所有数据，构建本地 SQLite DB
- 投入：三句话的描述。产出：比商业产品更好地解决了他问题的方案。
3.8 核心哲学：最好的 Agent 软件 = 最好的程序员软件
传统逻辑：产品经理必须温和地告诉工程师——你不是客户。产品需要为真实客户设计。
Agent 时代逻辑：每个客户都有一个 Agent，会为TA写代码来对接你的产品。如果你建造的是程序员喜欢的东西，那么每个人的 Agent 都能轻松使用它——于是所有人都跟来了。"开发者体验（DX）"不再只是吸引开发者的策略，而是通向所有终端用户的门户。
3.9 LLM 辅助编程的三种用法
在"How I program with LLMs"中，Crawshaw 系统性地总结了三种用法：
- Autocomplete（自动补全）——最基础但最有效。Crawshaw 尝试放弃一周后无法忍受，因为"太多 mundane typing"。
- Search（搜索替代）——"如何在 CSS 中让按钮透明"这类问题，问 LLM 比用传统搜索引擎好得多。
- Chat-driven programming（对话式编程）——最难但最有价值。当你知道需要写什么、能描述它，但没有精力创建文件、查找库时，LLM 给你第一稿。
3.10 写好 Prompt 的艺术："考试式问题"
Crawshaw 发现 LLM 最擅长"考试式问题"：给出明确目标和所有背景材料，让它能构造一个良好封装的代码审查包。
两个核心原则：
- 避免过度复杂和模糊——不要在 messy workspace 里用 LLM，给它们一个空白 slate
- 要求易于验证的工作——你可以要求 LLM 做你绝不会要求人类做的事，比如"重写所有测试，引入一个中间概念让测试更易读"。重做工作极其便宜。
3.11 代码结构的新权衡：更小的包、更多的专门化代码
LLM 改变了代码组织的权衡。因为 LLM 更擅长处理封装的、独立的问题，更小、更多的包变得更有利。Crawshaw 举例：以前他会把多个统计算法放在一个包里，现在他会为每个算法创建独立的包。
他还预见了一个趋势：更少通用包、更多专门化代码。对于 REST API wrapper，他宁愿自己写 200 行的简单 wrapper，也不愿用官方 1155 行的复杂包。"我只想要 cURL 和解析 JSON"。
3.12 更好的测试：LLM 改变 DRY 的权衡
"不要重复自己"（DRY）在过去被过度推崇。现在 LLM 让写测试更便宜，你可以要求它写 fuzz test、写可读性更好的测试。专门化的实现 + 全面的测试将成为新常态。
四、主题二：云计算与基础设施
4.1 "我在建一朵云"——为什么今天的云是错误形状
2026年4月，Crawshaw 宣布融资并阐述了 exe.dev 的愿景。开头出人意料地简单："I like computers." 他喜欢所有计算机——微控制器、桌面、手机、服务器。但有一个例外：
4.2 云的四大根本问题
1. VM 是错误形状
- VM 被绑定到 CPU/内存资源，但你应该能买 CPU、内存、磁盘，然后运行任意数量的 VM
- Linux VM 只是另一个 Linux cgroup 里的进程，应该能随意运行
- 今天唯一的解决方式是嵌套虚拟化，支付性能惩罚，然后自己管理反向代理
2. PaaS 是更糟糕的抽象
- 每个供应商的 PaaS 都是比计算机更弱的专有抽象
- 学到一半才发现某个简单需求因为平台深层限制而无法实现
3. 磁盘是错误形状
- 云厂商想要你使用远程块设备（或更慢的 S3）
- 远程块设备在 HDD 时代合理（10ms seek vs 1ms RTT）
- SSD 时代：seek 从 10ms 降到 20μs，远程 IOPS 开销从 10% 变成 10 倍以上
- MacBook 有 500k IOPS，配置 EC2 到 200k IOPS 要花 $10k/月
4. 网络被敲诈
- egress 费用是正常数据中心的 10 倍
- 中等体量时倍数更糟。只有每月花 $XXm 时价格才变好
- 如果网络容易互通，你会从邻近开放 DC private link 几个系统，从云账单上砍掉一个零
4.3 Kubernetes：在猪身上涂口红
Crawshaw 认为 K8s 试图解决一个不可能的问题：让云变得可移植和可用。但你无法通过在错误抽象之上构建新抽象来解决根本问题。
4.4 为什么现在是修复云的时机？因为 Agent 来了
Agent 让写代码变得更容易，这意味着会有更多软件（经济学上的杰文斯悖论）。每个人会为乐趣和工作写更多程序。我们需要私密的地方来运行它们，需要轻松与朋友同事分享，需要最小开销。
Agent 时代的云需求：
- 更多计算、更易管理
- Agent 也能驱动 AWS API，但会消耗更多 token、得到更差结果
- Agent 花在"如何让经典云工作"上的每一 percent 上下文窗口，都不是花在解决你的问题上
- 所以云抽象本身需要变得对 Agent 友好
4.5 单进程编程哲学（2018）
2018年的"One process programming notes"是 Crawshaw 离开 Google 后的独立开发实践总结。核心思想极其简单：
单进程栈：
- 1 VM，1 Zone，1 process
- Go + SQLite + WAL + 共享缓存
- EBS 卷定期快照到 S3
- 部署脚本 10 行长
- 中型 VM 可处理 5-6k 并发请求
- 最大 AWS 机器可处理数万个并发请求
Crawshaw 承认这有明确的扩展限制，但他声称典型服务不会触及这个限制。如果你的业务能在单机上运行数年并盈利，你就有收入来雇佣更多工程师，在需求真正变化时重写服务。早期在扩展上花费的每一小时，都应该是与客户交谈的一小时。
给公司程序员的建议：即使你在资本充裕的公司，也用这个 indie mini stack 来测试你的设计——"如果我用一台计算机解决这个问题，能走多远？能支持多少客户？在什么规模下需要重写？"如果 indie stack 能支撑你的业务数年，也许应该推迟采用现代云软件。
五、主题三：Go 与 SQLite 工程
5.1 Go 和 SQLite：当 database/sql 不合适时
Crawshaw 写了自己的 Go SQLite 绑定 crawshaw.io/sqlite，因为他发现 database/sql 对 SQLite 来说有太多不合适的地方。
database/sql 的问题：
- 隐式连接池——SQLite 是进程内数据库，连接池让事务和特殊功能难以使用
- 语句缓存复杂——需要跟踪 *sql.Stmt 对象，而 Crawshaw 更喜欢用查询字符串本身作为 key
- 参数绑定——问号位置参数对复杂查询不友好，SQLite 支持命名参数
- 错误处理——database/sql 所有操作都返回 error，但 SQL 语法错误是程序 bug，应该 panic
- Context 过度——每个函数都要传 context，但 SQLite 没有网络
- 并发默认配置差——默认不用共享缓存、WAL、unlock_notify
5.2 Savepoint：比 Tx 更好的事务模型
Crawshaw 推崇用 SQL SAVEPOINT 替代 BEGIN/COMMIT。因为 SAVEPOINT 可以嵌套，天然支持 Go 的 defer 模式：
func doWork(conn *sqlite.Conn) (err error) {
defer sqlitex.Save(conn)(&err)
// ... 自动 RELEASE 或 ROLLBACK
}
这种模式下，事务函数可以安全组合——一个事务函数调用另一个事务函数，嵌套的 savepoint 会正确处理。
5.3 SQLite Session 扩展：极简同步
SQLite 的 session 扩展让客户端-服务器同步变得极其简单：在连接上启动 session，所有修改被打包成 patchset blob，上传服务器应用即可。Crawshaw 用它来构建客户端数据同步系统。
5.4 JSON 文件作为原型数据库
2024年的"jsonfile"文章展示了 Crawshaw 的务实主义。一个简单的 JSON 文件数据库，带 RWMutex、写时复制、rename(2) 原子写入，85 行 Go 代码。适用条件：数据量小、无索引需求、写入不频繁。
他的核心观点是：愿意妥协几乎所有东西来开始。当 n 很小、全表扫描足够快时，JSON 文件完全够用。直到你需要索引的那一刻，再迁移到 SQL。明确的退出策略比完美起步更重要。
5.5 Finalizer 的悲剧
两篇关于 Finalizer 的文章展示了 Crawshaw 对底层机制的深刻理解。他指出 Go 的 runtime.SetFinalizer 几乎不可能用好，因为 GC 不保证何时运行。他甚至用代码证明：在一个循环创建 2000 个文件的程序中，finalizer 在第 252 个文件时就因为"too many open files"而崩溃了。
Finalizer 的唯一合理用途：作为"锋利边缘的 Finalizer"（Sharp-Edged Finalizer）——在 finalizer 中 panic，把资源泄漏变成立刻崩溃的 bug。这比默默泄漏要好得多。
六、主题四：软件工程哲学
6.1 向后兼容性：我们误解了它
在 log4j 事件后，Crawshaw 写了一篇关于向后兼容的深刻文章。他认为 log4j 的 JNDI/LDAP URL 功能本应该被移除，但被向后兼容的承诺束缚住了。
Crawshaw 对向后兼容的三层理解：
- 升级不费时间——运行升级命令、执行测试、提交，不用思考
- 问题尽早暴露——不在生产环境才发现行为变化
- 长期积累知识——工具稳定，20年前的 awk 单行代码今天还能工作；Swift 代码每过几个月就要重学
6.2 实验文化的漂移
Crawshaw 在 Google+ 工作时尝试引入实验文化，但失败了。他发现硅谷的 A/B 测试往往不是真正的科学：
- 有效的科学家假设→实验→用学到的知识形成下一个假设
- 但产品团队的 A/B 测试：设计师/管理层喜欢 A 和 B，测试选 winner，下一个功能再来一次
- 没有整合之前实验的教训，没有设计实验来最大化学习
- 长期结果是"某种抽搐的山丘攀爬"，甚至是一种长期的 P-hacking
他的结论：科学文化与硅谷文化很大程度上是不兼容的。科学训练需要数年，做科学也需要数年。初创模式的" rushed feature release"与严谨实验背道而驰。
6.3 依赖恐惧
Crawshaw 对依赖的态度越来越谨慎。他要求自己"在把任何库加入项目之前，阅读其中的很大一部分"。log4j 事件强化了这一立场：一个日志库为什么需要网络查找功能？核心库应该保守。
七、主题五：互联网与社会观察
7.1 怀念 LAN（Tailscale 的起源故事）
这篇充满感情的文章解释了为什么 Crawshaw 要创建 Tailscale。他回忆了 90 年代在澳大利亚北部小镇的 LAN 经历：
- 15 台 PC，MS-DOS，IPX over coax 到 Novell Netware
- 可以在网络上安全地做"不可想象"的事：无权限文件共享、无安全实验服务器
- 即使搞崩了网络，影响也只在楼内，"我知道该向谁道歉"
- 200MHz Pentium Pro 感觉飞快，32MB 内存无所不能
- 他父亲（全科医生）用 Clipper 写了医疗记录软件，让诊所效率远超同行
他问了一个深刻的问题：今天的父亲还能写出这样的小商业软件吗？答案是：几乎不可能。HIPAA、OAuth2、XSS 防御、密码存储——今天的激活能量太高了。
Tailscale 的愿景：用 WireGuard + 身份 + 加密授权，重建 90 年代 LAN 的安全小型空间，同时保留 21 世纪互联网最好的部分。让互联网做"笨管道"，让端点根据另一端的人来决定与谁通信。
7.2 寻找创意互联网
Crawshaw lamenting 90 年代互联网的消失——那个一切都 obscure 或 new 的地方。今天搜索"disney"，结果全是迪士尼公司或主流媒体。但他发现：创意互联网还在，只是被搜索引擎埋在了后面。
- 搜索 [disney]，前 14 页全是企业网站和新闻
- 搜索 [disney blog]，第 7 页开始出现 Rejected Princesses 这样的原创内容
- 搜索 [modern nuclear propulsion research]，第一页是 Gizmodo 和 NASA 新闻稿
- 第 2 页出现了 Beyond NERVA 博客——真正的研究和思考
他的愿望：为创意互联网设计独立的工具——一个惩罚媒体出口、推广博客和播客的搜索引擎；一个让 West Virginia 三兄弟和爸爸的 D&D 播客与 NPR $2亿/年的机器一样容易找到的平台。
八、主题六：个人成长与选择
8.1 用遗憾做决策
Crawshaw 分享了他最喜欢的决策工具——来自 Jeff Bezos 的 Princeton 演讲：
Crawshaw 的用法：投射自己到遥远的未来，问自己：我会后悔没做这件事吗？这帮助他离开 Google、创办公司、选择艰难但有意义的道路。
8.2 离开 Google
2018年3月，Crawshaw 简短宣布离开 Google。他说会 sad to leave Fuchsia（"作为操作系统它做对了很多事"），接下来要做 childcare 和 start a software business。他也提到内部 Google+ 是他过去五年的主要社交媒体，现在它要关闭了，他需要看看还有什么别的选择——于是开始写博客。
九、跨主题的深层模式
9.1 "错误形状"的反复主题
"错误形状"（wrong shape）是 Crawshaw 博客中最有力的概念之一。它出现在多个领域：
- 软件形状错误——大多数软件为 Agent 时代设计错了，API-first 和 DX 是新的核心竞争力
- 云的形状错误——VM、磁盘、网络、PaaS 的抽象都是为过去时代的硬件和商业模式设计的
- 工具形状错误——IDE 假设人类需要语法高亮和项目管理，但 Agent 需要的是直接操作文件系统的能力
- 容器形状错误——内置 Agent 沙盒限制太多，fresh VM 才是正确形状
9.2 简单化作为力量
从单进程编程到 JSON 文件数据库，从 9 行代码的 Agent 到 85 行的 jsonfile，Crawshaw 始终展现一种"简单即力量"的哲学。他不是不知道复杂系统的存在价值，而是坚持：先证明你需要复杂性，再引入它。
9.3 对"中间层"的怀疑
Crawshaw 对中间层/抽象层有一种天生的怀疑：
- database/sql 是通用 SQL 的中间层，对 SQLite 来说过于臃肿
- Kubernetes 是云抽象的中间层，试图让不可移植的东西变得可移植
- PaaS 是计算机的中间层，比计算机更弱
- IDE 是编程的中间层，Agent 让它变得不必要
他的模式是：当抽象层比底层更弱时，这个抽象层就是可疑的。
9.4 第一性原理思维
Crawshaw 的写作处处体现第一性原理：
- Agent 是什么？一个 for 循环 + LLM 调用。不是魔法。
- 云是什么？Linux VM。API 驱动的 Linux VM。应该 heaven，实际是 hell。
- SQLite 是什么？一个 C 库，进程内，不需要网络协议。
- 编程环境需要什么？反馈。编译器错误、测试失败、grep 结果。
9.5 长期主义 vs 短期优化
从"向后兼容性"到"本地模型终将胜利"，从"单进程能支撑多年"到"80岁时的反思"，Crawshaw 展现出罕见的长期主义。他愿意为几年的"付高价用前沿模型"买单，因为他知道这只是暂时的。他愿意用一台计算机运行服务，因为扩展限制是"好问题"。
十、我们可以从 Crawshaw 学到什么？
10.1 对程序员的技术启示
- Agent 不是未来，是现在。如果你还没每天用 Agent，你已经落后了。从自动补全开始，逐步探索对话式编程。
- 只用前沿模型。便宜模型不仅浪费时间和金钱，还会让你形成错误的能力边界认知。
- 为 Agent 设计你的代码。更小的包、更好的注释、清晰的接口、可读性优先——这些本来就是好代码的特征，现在有了更强的理由。
- Fresh VM 是 Agent 的最佳环境。放弃内置沙盒，给 Agent 完整的环境控制权和真正的隔离。
- 重新考虑你的工具链。IDE 可能不是未来。一个轻量编辑器 + Agent 可能更高效。
- 不要过早引入复杂性。JSON 文件、单进程、一台 VM——证明你需要更多之前，保持简单。
- SQLite 被低估了。对于绝大多数应用，SQLite + WAL + 共享缓存的性能远超你的需求。
10.2 对创业者的产品启示
- "最好的 Agent 软件 = 最好的程序员软件"——如果你的产品能被 Agent 调用，DX 就是 UX。
- API 优先于 UI。Stripe Sigma 的故事告诉我们：没有 API 的产品在 Agent 时代是脆弱的形状。
- 考虑 Jevons 悖论。Agent 让写代码更便宜→更多代码→更多运行需求→基础设施的痛点被放大。
- 简单栈能走多远？在引入微服务/K8s/分布式之前，问自己：一台机器能支撑多久？
10.3 对思考者的认知启示
- 用遗憾做决策。"80岁的我会后悔没做这件事吗？"——这是一个强大的长期决策工具。
- 关注定性信号。当所有 benchmark 都被刷爆时，来自一线实践者的定性观察可能更有价值。
- 警惕"中间层"。当抽象比底层更弱时，它可能在制造问题而非解决问题。
- 第一性原理。把复杂概念还原到最基本的事实，再重建理解。
- 好奇心和谦逊。LLM/Agent 时代一切都在变，"甚至更多于往常，远离那些绕圈子讨论技术的互联网论坛——那是 Agent 的工作。"
10.4 对社会的观察启示
- 技术变革有代价。农业就业从 40% 降到 1% 是净收益，但过程中有大量痛苦和心碎。承认这一点，不要无脑乐观，也不要恐惧到反对电动工具。
- 创意互联网需要独立工具。为数十亿人设计的搜索引擎不适合探索 obscure 话题。我们需要为"周末漫游"设计的工具。
- 小空间的价值。90 年代 LAN 的"安全小型空间"不是怀旧，而是一种可重建的产品愿景。