“稍后再说”是一个功能

# “也许以后”曾是一个功能 - arnorhs.dev 来源：https://arnorhs.dev/posts/2026-06-04/maybe-later-was-a-feature/ 我的仓库里最有价值的代码，是我没写的那部分。 你有没有过这样的时刻：曾对某件事感到兴奋——比如为技术栈的某个部分增加更多测试，或者把“老旧的旧东西”重写为“闪亮的新东西”？又或者把服务从 GCP 迁移到 AWS？ 或者，也许是你想构建的一个功能——比如在 CRM 之上加一个任务管理工具，或者在你的基础设施里搞一个酷炫的图片处理方案？ 你们团队的待办清单里是不是堆满了这些东西？反正我的是。那些任务和想法，业务方、你的老板、你的团队，甚至你自己，从来没有给过它们高优先级。你当时心想：以后再说吧。 那些真正值得优先考虑的想法，你会着手去做，或者雇人来完成。它们被实现了，因为够重要。 四年后回头看，那些 backlog 里的功能根本帮不上忙。幸好它们从没被构建出来。它们要么今天已经过时，要么你的产品早就彻底转型了。 它们只会变成你需要维护或删除的遗留包袱。 我经常想起这些事——**所有我从未构建过的东西。** 每一次你选择不构建某样东西，你都在加速团队、加速产品，也在为当下最重要的事情排定优先级。不构建是一个极其强大的功能。选择本身，就是产品和开发策略。 ## “模型越来越强了” 现在大家总在说 AI 会抢走我们的工作。我承认，有时我也会担心。这很难不担心。科技 CEO 们总在提醒我。 表面上，它们已经更强了，而且在某些局部场景下，它们能写出比我还好的代码。 但从更大层面看，我觉得它们还差得远。你有多少次试过完全凭感觉写代码，但过一会儿回头看，问自己为什么同一个东西在 15 个地方被定义？或者看到嵌套的 if 语句里出现了 4 种不同的 schema 校验实现？ 我个人觉得，LLM 输出的代码常常很难读。对我来说难读，对 AI 自己大概也难读。 但我们总会达到那个地步的。我确定。 ## 什么时候该构建 LLM 在进步，每个人都在用它们。拼命刷 token，仿佛没有明天（字面和比喻意义上都是）。 但我担心的是，人们正在、也将会把 token 花在构建那些你以前本不会构建的东西上——**那些 backlog 里的想法。** 他们不再做选择，而只是不停地构建。 那么长远来看，代码库只会越来越臃肿，充斥着更多功能、更多框架、更多从 A 到 B 的重写，而这些本来是不必做的。 我还担心代码最终会变得人类无法阅读，你只能靠 AI 来跟代码交互。 没错，你可以用 AI 帮你移除这些内容、重塑它们。但你真的会去做吗？难道不会有更多的系统、更多的事情、更多的人依赖于这个功能吗？ 而且很难说服别人你需要花时间、花 token 或其他资源来移除一些东西。非开发者常常无法理解，移除东西怎么会是净收益。 此外，**Hyrum 定律**（https://www.hyrumslaw.com/）也会影响你的 API。 我们没写出来的代码里藏着很多价值。很多时候，选择不写某些代码，就是你能做的最好决定。