制表符、空格、手工工具与安全带：编程如何走向工业化

Bun 借助 Claude Code 从 Zig 迁移到 Rust，引发了一场关于语言、管理与 AI 代码的激烈争论。作者没有停留在这场口水战，而是把它放进软件生产的长期历史：从制表符与空格、格式化工具、编译器和 Go，到 Clojure 手工艺、强类型与安全带，再到 coding agent。贯穿全文的问题是：软件应当由个人像匠人一样亲手雕琢，还是应当通过可重复、自动化、能扩大生产的工业流程制造？

1. Bun 迁移争议暴露了软件手工艺的根本分歧

• 2026 年，Bun 创始人 Jarred Sumner 大量使用 Claude Code，把 Bun 从 Zig 迁移到 Rust，并发布了一篇近似大型科技公司工程复盘的长文。Zig 创始人 Andrew Kelley 随后公开抨击双方长期失调的合作关系和 Jarred 的管理方式，称他是“臭经理”，还说“Jarred 在能用大模型之前就已经在写 slop（劣质产物）了”。前者展示了一种新而大胆的软件工程方法，后者则像一封最好烧掉、不要寄出的信；但正是这场闹剧，让作者重新追问困扰他职业生涯多年的问题。
• 作者的起点很明确：今天大多数软件生产事实上已经是工业流程。数千人的组织在标准硬件与系统上协作，岗位跨部门、公司乃至国家都高度同质化；在生成式 AI 出现前，最佳实践已经不断削减个人对生产方式的裁量。几十年前，程序员深夜亲手在卡片上打孔，软件或许更接近手艺；今天这种说法已很难成立。
• 真正仍有争议的是规范性问题：软件应该采用手工艺流程吗？优秀软件来自开发者把自己视作匠人、经年打磨代表作，还是来自可重复、自动化的工业规范，让工程师成为代码工厂里熟练但可替换的工人？个人应追求自己的工艺标准，还是冷静接受行业最佳实践？
• Bun 的迁移不是孤立的语言之争，而是软件生产权从个人判断继续转向组织流程与机器自动化的一次显影。

2. 制表符之争消失时，代码也失去了一部分人格

• 制表符与空格的争论至少从 1988 年就已存在。过去，开发者会为缩进、新行、花括号和单行循环争得面红耳赤；这些选择不只是审美偏好，还被赋予可读性、无障碍乃至人格判断。电视剧《硅谷》甚至让主角因为恋人用空格缩进而结束关系，说明这种“自行车棚之争”曾深深进入程序员文化。
• Zig 走向了强制统一：代码只要包含制表符或错误换行符就可能无法编译，zig fmt 也不允许把四空格缩进改成两空格。Andrew Kelley 在 2023 年关闭相关讨论时直言，所有观点都已说尽，作为项目的“仁慈独裁者”由他决定颜色。个人若不接受，只能让编辑器自动适配，或改用另一门语言。
• 作者回忆，2014 年左右团队引入 flake8，随后使用 autopep8。大家最后讨论一次制表符还是空格，选定统一风格，从此这个话题几乎消失。自动格式化释放了注意力，也让不同文件更容易阅读，但代价是代码库的个性被磨平。此前不看 git blame，仅凭古怪的换行或 and 写法就能认出谁动过文件；新人还会在模仿团队风格时发现 bug、练习脚本并理解代码库。
• 作者承认，站在负责落实最佳实践的高级工程师位置上，他绝不会允许初级工程师以“保留人格”为由关闭格式化器；但在下班后，他仍怀念那种“放开手写”的快感。这种矛盾说明，工业标准确实提高协作效率，却同时切断了部分人与代码、与其他作者之间的可见联系。

3. Go 把格式统一推进为去技能化与劳动强化

• Go 于 2009 年 11 月发布，背后有 Ken Thompson、Rob Pike 等 Unix 与 C 先驱。发布第二天，就有人质疑 gofmt 不允许配置风格；Russ Cox 的回答是，统一格式正是为了结束无休止的花括号争论，让大脑专注代码而不是排版。Rob Pike 后来更直接地解释，Go 服务的是 Google 大规模软件工程，而不是语言研究：它可以高效、可扩展、富有生产力，也可能显得无趣，这两点并不矛盾。
• Go 的设计目标之一，是让刚毕业、熟悉 Java、C/C++ 或 Python 的普通工程师，也能在 Google 规模下写出高性能代码，而无需“C++ 模板研究博士学位”。另一个重点是让庞大项目快速编译；Go 最初的构想，正是在 Rob Pike 等待大型 C++ 代码库编译时形成的。
• 作者用两个劳动经济学概念解释这组选择。去技能化，是用半熟练或非熟练劳动者可操作的技术，替代行业中的高技能劳动，从而降低人力资本投资与准入门槛，也削弱劳动者议价权；劳动强化，则提高工作日内身体或脑力投入的速度、强度、并行程度与连续性。Google 投入巨资创造 Go，既让成本更低、经验更少的人完成原先需要专家的任务，也通过更快编译从同一时间里提取更多产出。
• 这种技术对不同人产生相反效果。C++ 专家的稀缺知识与编译等待时间原本构成地位和缓冲，Go 会削弱这种优势；对原本无法承担大规模高性能开发的人，Go 却是赋权工具。作者自己并不喜欢 Go，却认为它经过十五年以上成功，显然已成为 Google 最正确的长期投资之一。

4. Clojure 展示了软件匠人的诱惑，也暴露了它的意识形态

• 与 Go 相反，Clojure 曾真正让作者“心在歌唱”。Rich Hickey 的演讲鼓励人们在编码前深入思考，用简单、可理解的工具驾驭复杂性；一个配备强大语言和娴熟技能的个人，可能比使用钝器、思考不深的团队走得更快。作者至今手写任何语言时，脑中仍常像在写 Clojure：偏爱函数、干净的数据结构和映射。
• 这种文化也会把人变成激进的手艺传教士。作者曾以某个“只有 Clojure 才方便”的库为理由，把微服务偷偷带进公司；他讽刺说，任何高级工程师只要在公司网络上观看 Hickey 的《Simple Made Easy》，CTO 办公室都该拉响警报，因为下一季度很快会塞满关于“可变状态恐怖”的会议。
• Clojure 手工艺观对不善融入社会的年轻作者尤其有吸引力：只要找到正确工具并把技艺练到极致，也许就无需处理其他人，只靠作品质量便能换取独处与自主。年龄增长、社交生活改善后，这种感受减弱，但问题仍在：Hickey 式生产是否真的最适合职业软件？

5. 木工早已把职业生产与业余手艺分开，软件业却迟迟不肯

• 对亲手用简单工具做出完美物件的向往并非 Clojure 独有。作者发现许多程序员业余喜欢木工，而木工爱好者也长期争论电动工具与手工工具：手工具派自称 Galoot、Neanderthal，把 Roy Underhill 称作“圣 Roy”；电动工具派有自己的称呼，中间还有大量混合派。每个人可以按乐趣划线，但工业界为了完成订单、赚取利润，早已按效率使用电动工具。
• 木工和编程都吸引从业者在闲暇继续练习，但差别在于：职业木工通常不会坚持把爱好中的手工具带到工厂完成商业任务；软件开发者却经常希望把 Clojure、Haskell、Elixir 等个人偏爱的函数式或小众语言带进公司，替代 TypeScript、Python、Java、Ruby 等“工业语言”。
• 作者反省，自己过去这样做，部分原因是工作并不振奋，甚至配不上他对自身水平的想象。偷偷引入 Clojure 是一个泄压阀：CRUD 应用的结果未必需要“杰作级”代码，他便至少从实现方式中获得工艺满足。当工作价值主要在于按时完成时，强调工具品位有时是在保护匠人的自我形象，而不是改善组织真正需要的结果。

6. 从 Emacs 到 VS Code：作者逐渐把“作品质量”换成了“系统可靠”

• 这场转变早在大学时期就开始。作者曾在笔记本上安装 Linux 与 Emacs，学习宏、快捷键和系统内部，每学期却至少把机器弄坏一次；有次尝试升级 Python，甚至让整个环境瘫痪一两天。他确实学会了版本与备份，但也发现自己还有别的事想做，于是“投降”，换成稳定省心的 MacBook Air。
• 后来，为了远程结对编程，他告诉自己只在共享会话时使用 VS Code，严肃工作仍回到 Emacs；结果他从此一直使用 VS Code，多年没有在 Emacs 中做过真正的项目。Clojure 也逐渐退出日常，取而代之的是 Rust、Python、TypeScript 和令人不快的 Terraform。
• 在跨团队与跨部门协作中，他越来越少问“怎样写出最高质量的代码”，更多问“怎样写一点代码，让流水线下一位同事不被阻塞”。追求完美太久，会让装配线和 Jira 看板堵在自己身后。后来他意外成为 DBA、再成为 DBRE，注意力转向可靠性、值班与变更安全。优美架构与可靠系统往往相伴，却不是一回事；不崩溃、不半夜叫醒值班人员，最终比架构图是否漂亮更重要。

7. 安全带的历史说明：成熟的约束常先被视为暴政

• 作者用汽车安全史解释自己为何越来越支持编程约束。汽车在 1886 年出现、1901 年开始大规模生产，1908 年福特 Model T 推动普及。美国交通死亡率在 1937 年达到每 10 万人约 30 人，1960 年前后约 20 人，1956 年《联邦援助公路法》推动高速公路扩张后，1960 年代末又升至约 26 人，随后才逐步降到今天约 12 人。
• 沃尔沃工程师 Nils Bohlin 于 1959 年发明现代三点式安全带，公司免费开放专利。美国联邦政府 1968 年要求新车安装安全带，但 1973 至 1974 年仍少有人使用。尼克松政府于是要求 1974 款新车加入点火联锁：驾驶员不系安全带，汽车就无法启动。装置经常故障，驾驶员猛烈投诉，国会一年内撤回命令，并禁止未来政府再做同类尝试。
• 到 1980 年代初，前排安全带使用率仍只有约 11%。里根政府推动各州制定强制佩戴法律，再次引发“大政府越权”抗议，甚至有人声称撞车时被甩出挡风玻璃更安全。马萨诸塞州选民在 1986 年 11 月公投废除了新法，直到 1994 年才重新立法。但随着公私部门一轮轮带有家长主义色彩的干预，安全带最终成为毫不起眼的常识，并在美国挽救了数十万生命。

8. 强类型与内存安全，是程序员不情愿系上的安全带

• 类型系统、自动内存管理和借用检查器与安全带相似：限制不一定舒服，却能阻止已知灾难。Heartbleed、Cloudbleed、Stagefright、EternalBlue 等重大事故不断提醒人们，许多 race condition（竞态条件）、缓冲区溢出和空指针错误，在安全语言中本来就不可能发生。作者不主张凡事使用 Rust；他的质问是，既然安全功能免费可用，为什么不尽量打开？
• 他也承认糟糕的安全系统会激起合理反抗。初学 Rust 时，他无数次被生命周期折磨；他不喜欢亲手写出能通过 borrow checker（借用检查器）的代码，却喜欢拥有已经通过检查的代码。换言之，他支持人人系上隐喻的安全带，也会亲手拆掉那个故障频发、让车无法启动的点火联锁。
• Bun 的具体问题正落在这里。Jarred 解释，Zig 中垃圾回收值与手工管理值的生命周期，是小型内存泄漏和偶发崩溃的主要来源；每次分配都要逐一检查何时释放、是否只释放一次、JavaScript 异常是否处理、指针能否被保守栈扫描器看到。Rust 的借用检查器把中央安全权威放进编译器，直接禁止一类竞态与内存管理错误。
• 作者没有断言 Rust 在所有方面优于 Zig。若业务确实需要极细粒度内存控制，Zig 可能体验更好；问题在于并不需要不安全能力的人，仍一再被它灼伤，却坚持自己每次都能手写安全代码。Bun 迁移真正令人惊讶的，不是想迁，而是借助 AI 以如此低的成本和速度完成；至今系统仍在正常运行，最终成败则还需时间验证。

9. 编译器、格式化器与 coding agent 属于同一条自动化斜坡

• 早期程序员也曾把高级语言和编译器视作会产出低质量代码的机器。1990 年代 Usenet 留下大量对 C 编译器、MASM 和高级语言的怒骂，有人坚持时间关键代码永远不能相信编译器。那时的抱怨并非全无依据：编译器确实远不如今天的 GCC 与 LLVM。但随着长期改进，许多问题消失，手写汇编从职业常态变成特殊需求或个人爱好。
• 2021 年，作者用 Rust 挑战 Advent of Code 的 25 道题。第 22 天“反应堆重启”要求处理三维空间中的立方体区域，他把整个星期六关在房间里，反复思考空间分解，最终想到解法并用半小时写完代码，兴奋得摇摇晃晃出门吃晚饭。他庆幸自己在 ChatGPT 出现前体验了这种纯手工解题的快乐，也意识到那可能是“编码机器”全面到来前的最后机会。
• 作者对大模型抱有真实恐惧：即使模型从今天起不再变聪明，只让现有能力扩散，也足以触发白领工作的重大消亡，企业不会因为幻觉和错误就放弃用 AI 替代昂贵人力。未来一二十年的政治与社会震荡因此令人悲观。
• 但他同时从未如此享受计算机：散步时在手机上与 Claude 交流，回来可能已有 20 个 PR 可供审阅。学习 Clojure 原本就是为了借高层语言走得更快；若速度和创造才是目标，亲手敲代码只是一种偶然手段。格式化器替人整理语法、编译器替人写汇编、强类型替人排除错误、coding agent 替人生成实现，并不是四次无关革命，而是同一场工业化的连续推进。

10. “Slop”无法成为阻止机器的客观边界

• Andrew 那句“Jarred 在大模型之前就在写 slop”触发了作者。Slop 在生成式 AI 之前就指低质量产物：2020 年有人把随手写下、再由保存时格式化器清理的代码称作 slop；1990 年《黑客词典》还用它表示编译器生成代码相对手写汇编多出的空间或时间成本。因此，slop 从来既可能由机器制造，也可能由人制造。
• 作者给出的定义是：slop 是一个贬义标签，指人或机器创造的、缺乏质量的东西。困难随即转向“哪些质量重要”。ChatGPT 初期，每个人都认为它什么都做得不错，唯独不懂自己的专业：程序员不信代码、律师不信合同、医生不信医疗建议、诗人不信诗。随着模型变强，这种反应减少；专家仍更容易看出自己领域的缺陷，外行则可能看不见。
• 若把高质量完全客观化，机器就能优化它：格式必须统一，agent 可以运行格式化器；圈复杂度必须低，agent 可以看到扫描器告警后重构；必须有注释，agent 尤其善于补注释。若继续要求“好注释”，就已经退回主观判断。两位都自称匠人的资深架构师，也可能为了 protobuf 还是带 schema 的 JSON 才算高质量而争到划分微服务领地。
• Slop 归根结底在观察者眼中。若我们能把它完全转成客观规则，就等于已经把检测与规避方法交给 agent；最后剩下的，只是个人经验和偏好构成的主观部分。这不证明高质量不存在，而是说明“只有手工才能拥有的质量”很难被清楚划界。

11. 程序员不能一边自动化所有人，一边宣称自己例外

• 作者给软件匠人设置了一个道德难题：优秀程序员往往相信，给足时间、团队和资源，计算机可以完成几乎任何人类任务；软件行业的大量工作，本来就是把人的任务交给机器，并让许多岗位不再被招聘。
• 那么，当自动化越过边界进入编程本身时，程序员若断言机器只能写垃圾、自己的工作天生无法也不该被自动化，就显得极度傲慢。我们能写出登月软件、每秒交易十亿股的系统、协调全球企业的平台，却声称代码一进入自己的专业范围便注定失败——程序员凭什么是唯一应受保护的职业？
• 这正是作者与“软件必须完全亲手制作”决裂的地方。他不再相信自己的劳动特殊到机器无法完成，也不愿接受程序员把自动化威胁指向所有人、唯独把自己排除在外。新的问题不再是“为什么机器可以写代码”，而是“为什么代码必须是唯一坚持手工完成的东西”。

12. 十三条预测：语言迁移、工具收敛与质量约束都会加速

• 作者先对 Bun、Zig 与 Rust 给出四条具体预测：
• 预测 1：人们会继续愉快使用 Bun；重写会带来一些奇怪 bug，但它们会在大量无果争论中被修复。
• 预测 2：企业级 Zig 新项目事实上已经死亡。商业决策者会因 Andrew Kelley 的公开表现，对重大项目或合作三思；爱好者仍会使用，直到另一门更有吸引力、包袱更少且稍有企业前景的语言出现。
• 预测 3：为博取关注或报复 Andrew，会有人尝试把 TigerBeetle、Ghostty，甚至 Zig 编译器重写成 Rust；但这些项目自行迁移，仍需 Zig 生态再犯几次重大错误。
• 预测 4：2026 年底前，会出现开源工具，以低成本协调十亿个 agent，把任何项目改写成 Rust，同时通过全部原测试；更炫耀的版本还会随原项目合并 PR 实时同步。
• 随后，他对软件手工艺的未来给出九条预测：
• 预测 5：模型会继续变得更聪明、更快、更便宜。
• 预测 6：Coding agent 会持续进步。
• 预测 7：AI 融资泡沫可能剧烈破裂，但 coding agent 已永久进入软件开发流程，不会消失。
• 预测 8：市场与高管会继续施压，要求开发者尽可能使用 agent，明确追求去技能化与劳动强化；甚至市场部门也会直接开 PR。
• 预测 9：中小项目的语言与框架锁定正在蒸发，并会在 2027 年底前死亡。
• 预测 10：一个“足够好”的全 Rust Linux 内核要到 2028 年才会出现。
• 预测 11：零利率时代为留住程序员而容忍的业余手工具将退出职场；没有充分理由使用 Zig、Clojure、Elixir、Haskell 的专业项目，会被自动改写为模型训练分布更丰富的 Python、Ruby、TypeScript 或 Rust。
• 预测 12：Agent 与仍手写代码的开发者都会被套上更强的“紧身衣”；全行业会集中量化质量，并尽可能自动生产这种质量。
• 预测 13：类型系统的扩散仍不确定。TypeScript 会胜过 JavaScript，但 Ruby、Python 是否普遍打开更强类型，还要看这些系统能否越过“故障点火联锁”阶段，像今天的安全带一样自然。

13. 工业化会提高代码质量，也会把手写编程推回业余生活

• 作者的总体判断是，软件会继续沿几十年来的方向变成工业流程。想亲手解决棘手编程题的人仍能在下班后把它当作爱好，但在工作中，组织会越来越要求 agent 尽可能多、尽可能频繁地完成代码生产。
• 他对开篇问题的最终回答也很鲜明：通过 coding agent 深化工业化，会把代码“质量”推到任何单个匠人无法达到的水平。模型会继续进步，格式化、静态分析、测试和其他质量工具会越来越便宜、越来越强。大多数软件不应由个人以手工艺流程制造；在全球竞争市场中，这种做法也会越来越缺乏经济可行性。
• 软件行业从诞生起就在不断吞噬自己的旧技能，大约每十年就被彻底翻转一次。人们反复误以为计算机工作方式已经抵达“历史终结”，不会再有工具或硬件一次性颠覆一切；可人类用了几千年木头，至今仍在发明新加工方式，甚至仍在改进木材生产，又怎能断言代码已经找到唯一正确的生产方法？
• 文章最后用一个微小而不安的动作收束：作者合并了一个自己根本没读的 PR。改动只有一个文件、一项配置，他与 Claude 讨论过，测试、lint 和 CI 全部通过；事后检查也确实没有问题。既然所有质量信号都正常，为什么还必须亲眼看代码？这个例子既支持自动化，也暴露信任滑坡。作者说自己仍会阅读重要代码，却已经闻到一种新手艺的气味：未来的工艺不一定是亲手写实现，而可能是定义、验证并赋予 agent 输出以质量。至少，他的手已经不像过去那样疼了。

思想框架

文章由 Bun 借 Claude Code 从 Zig 迁往 Rust 的争议切入，先用制表符、格式化器和 Go 说明软件如何从个人风格走向统一、去技能化和劳动强化；再借 Clojure、木工、Emacs 与 VS Code 追溯手工艺对个人身份的吸引力，以及作者为何把关注点转向团队吞吐与系统可靠。安全带史把强类型和内存安全解释为先遭抵抗、后成为常识的家长式约束，编译器与 Advent of Code 又把 coding agent 放回更长的自动化谱系。“Slop”及质量主观性的讨论拆掉了“机器只能制造低质代码”的最后防线，程序员自动化他人却要求自身例外的矛盾，则把技术问题推进为职业伦理问题。最终，十三条预测和那个未经阅读便合并的 PR 共同落到作者的答案：职业软件将继续工业化，手写代码会更像业余木工，而新的工艺将转向为 agent 输出定义并验证质量。