Tab 还是空格

今天读了一篇很有意思的文章：Tabs, Spaces, Hand Tools, and Seat Belts。标题看起来像是在聊程序员最无聊的争论：Tab 还是空格。 但文章真正想问的是：软件开发正在变得越来越高效，可程序员还会不会因此失去某些东西？ 先说 Bun 的迁移 文章从 Bun 讲起。

Bun 是一个 JavaScript 运行时。 它的创始人 Jarred Sumner 最近把项目从 Zig 迁移到了 Rust，而且大量使用了 Claude Code。这个过程很适合拿来观察 AI 编程：过去，一个大型项目换底层语言，可能意味着几个月的人工摸索；现在，Agent 可以阅读代码、改文件、跑测试，再根据错误继续修改。 但这并不等于“按一下按钮，项目就迁移完成了”。 迁移过程中真正值钱的部分，依然是判断：哪些模块先动，哪些接口不能动，什么错误可以接受，测试没有覆盖的地方怎么办，最后发布出现问题谁来负责。 AI 可以快速生产代码，却不会替你承担迁移失败的后果。

Tab 和空格，其实是一种旧时代的“个人风格” 我以前也参与过 Tab 和空格的争论。现在回头看，这件事之所以能吵起来，是因为那时候代码还很像一个人的作品。 不同程序员有不同的缩进方式、命名习惯、换行方式。你打开一个项目，通常能感觉到它是谁写的，甚至能从代码风格判断这个人做事是否仔细。 后来，gofmt、autopep8 以及各种编辑器插件把这些差异抹平了。保存一下，代码自动变成团队规定的样子。 这当然是好事。代码评审不用再浪费时间讨论括号和空格，跨团队协作也容易了。软件因此更像工业产品：标准化、可复制、可交接。 代价也很明显：代码越来越不像“某个人写的东西”。 这不是怀旧。 个人风格消失之后，程序员和代码之间那种直接的连接也会变弱。以前你亲手写下每一行，遇到 Bug 时，脑子里有一条从需求到实现再到错误的路径。现在很多代码是工具生成的，开发者更像是在检查一批半成品。 手工不是指每一行都手写 文章里提到一场 2013 年的演讲，名字叫《Programming with Hand Tools》。

它把程序员和木匠、工匠放在一起讨论：当机器工具越来越强，人的工作效率提高了，但人与作品之间的关系也变了。 这里我放下原文： 人类历史上很长一段时间，家具都是用少量简单手工具手工做成的。这种方式让你和作品之间有一种非常直接的连接。机器工具兴起后，生产更高效了，但也深刻改变了我们做出什么、以及我们如何思考“做东西”这件事。 这场演讲讨论自动化对我们工作的影响——这对软件和对家具同样成立。尤其现在，有了 Clojure，我们又一次在用少量简单工具来构建东西。 这件事放到今天的 AI 编程里，尤其明显。 我不认为程序员应该拒绝 AI，也不觉得手写代码本身有什么神圣性。自己敲三天贪吃蛇，并不一定比让 AI 五分钟生成更有价值。 但在学习阶段，亲自实现、报错、定位、重构，确实是一种训练。它让人知道一个系统为什么会坏，知道一个看似漂亮的方案哪里可能埋雷。 如果所有练习都直接交给 AI，最后留下的可能只有“会描述需求”和“会验收结果”。 但验收本身需要经验，这就形成了一个很麻烦的循环：没有做过，就很难判断 AI 做得对不对；AI 做得越多，新人亲自做的机会就越少。 AI 时代，真正的手艺是什么 我现在更愿意把“手艺”理解成下面几件事： 能把模糊需求拆成清晰的问题； 能提前看出一个方案会在哪些地方失败； 能读懂别人和 AI 写出来的代码； 能用测试、日志和真实用户反馈验证结果； 出现异常时，知道该回滚、修补，还是推倒重来。 手艺不等于拒绝工具。木匠会用电锯，程序员当然也应该用 Agent。 问题在于，不能因为工具变快，就把理解过程全部外包出去。

对我这种做一人公司产品的人来说，标准化和自动化非常重要。没有 gofmt、测试、脚本、版本控制和 AI，我不可能一个人维护这么多东西。 但我也越来越在意另一件事：关键模块不能只做到“能运行”，还要能解释、能修改、能在出问题时迅速接管。 这大概就是这篇文章给我的提醒：未来的程序员未必需要亲手写完所有代码，但必须保留亲手理解系统的能力。 代码可以交给机器生产，判断力和责任感暂时还不行。