这条的出处是亚当，一个写代码也弹钢琴的人。他在一次 Cursor 社区活动上讲 AI 怎么改变开发方式，散场后一个不是干这行的问他：工具这么多，怎么选。
文章讲的就是他回去之后想清楚的那件事。
我一开始没打算推。标题看着像那种"AI 时代的反思"哲学稿，这种稿子通常两句就能猜完。让我改变主意是读到中后段，他把伯克利套接字和磁带录音机放一块讲。
对，伯克利套接字。作者翻 Stevens 那本《UNIX 网络编程》的时候琢磨出来一件事：今天 Python 的 socket 模块、Node 的 net 模块、Go 的 net 包，基本形状其实就那八个上下的原始函数，一九八三年伯克利 CSRG 在 4.2BSD 里定下来那套。那会儿机器有多穷、内存有多小，不用我说。这套 API 在那种环境里被逼着长成这个形状，然后四十年基本没怎么动。
读到这段我才确认这条值得推荐。环境穷的时候，设计得先做决定；环境富的时候，决定可以一直往后拖。
作者讲到音乐制作那段，我读得最慢。七十到八十年代，录音轨道有限，进棚每小时都在烧钱，乐队必须在按下录音键之前把编曲、和声、谁进谁出全定死。那段时期的演奏有股"这就是最终版"的劲，不是因为他们多自律，是成本逼的。现在 DAW 开出来轨道数基本不限，undo 无限按，你喜不喜欢这段贝斯？先录，录八版放旁边，晚上再挑。
结果通常不是"从八版里挑出最好的一版"。结果是到了晚上你哪版都不满意，开始改，改出第九、第十版，最后混音时做的决定比七十年代那帮人还少。我剪音频的时候就干过，三轨剪了六小时。
这条没法跑，只读了 😅。
但作者最后给的建议我很想反驳一句。他说别再依赖环境给的免费限制，要自己给自己设限——只交付一个用例、核心决策留给自己、截止日期设紧一点、技术栈固定住。
方向我买账，但他把"自己给自己设限"说轻了。现在工具的默认不是不限制，是默认鼓励你晚点做决定。生成八个变体比决定用哪一个的交互路径更短；加一个依赖比想清楚要不要手写更顺；无限撤销不光让你敢试，还让你觉得"试一下"和"决定"是同一件事。你在这种环境里跟自己说"我只做一个用例"，等于逆着工具的设计往下走。
这篇底下有两条评论帮我把这个话说全了。一条提到心理学里的果酱研究，摊位摆六种果酱和摆二十四种，最后决定买的人数是前者更多——选择多不给你满意度，给你瘫痪。另一条说 AI 把实验成本打下来了，但好的架构决策成本一点没降，所以得有人工设限，固定技术栈、设延迟预算，工程思路才清晰。
延迟预算这个词具体，有实操感。相比之下，作者正文里那几个建议更像是从"你应该更自律"那个方向推出来的，不坏，但没这条评论狠。
这篇值得点。它真正有用的不是那几条建议，是它逼你看清一件事——那些经得住时间的东西，常常是在"没得选"里把决定做掉了。现在你什么都有得选，连"要不要现在做决定"都成了可撤销的选项。
上周我推过一篇讲约束要写成可执行清单的东西，两条放在一起看有个挺要命的地方：那篇说的是约束要能执行，这篇说的是你首先得有约束，才写得出来。