代码里的“稀缺”：贫穷陷阱与余闲救赎
在穆来纳森（Sendhil Mullainathan）和沙菲尔（Eldar Shafir）合著的《稀缺》（Scarcity）一书中，有一个核心观点：稀缺心态（Scarcity Mindset）会导致管窥效应（Tunneling），进而吞噬人的认知带宽，使人不得不通过“借用”未来来应对当下，最终陷入恶性循环。
读到这里，我突然意识到：这不正是软件工程里“技术债”的心理学解释吗？为什么我们的代码会变成“屎山”？为什么组织里总是难以进行架构升级？答案或许就在“稀缺”二字。
一、 秩序的稀缺与“管窥”的代价
举个例子。最初我需要一个简单的功能：把图片上传到阿里云 OSS 作为图床。
在时间稀缺的压力下，我写了一个最简脚本，直接用 yyyyMMDD/filename 的格式存储。它能用，开发成本极低。但随着时间推移，秩序开始稀缺：文件夹泛滥、文件名冲突频发。
于是我陷入了“管窥效应”，只看见眼前的冲突问题，便引入了 cyber/yyyyMM/HASH 的命名策略。结果：
- 语义丢失： Hash 文件名让文件彻底失去了业务含义。
- 组织瘫痪： 想迁移某个模块的图片时，它们散落在哈希海中，根本无法捞取。
为了当下的安宁，我透支了未来的可维护性。这就是典型的“借用未来”的陷阱。
二、 只有“余闲”，才能构建“正交”
后来，我利用个人时间的余闲（Slack），进行了一次彻底的“反稀缺”重构。
我放弃了简单脚本，转而用 TypeScript、Mantine 和 Vite 构建了一个完整的 Web 管理界面。看似复杂，但它用架构的复杂度换取了操作的确定性。
我引入了 正交性（Orthogonality） 设计：
- 策略与执行解耦： 上传逻辑不再硬编码，而是支持多种策略（特定前缀、随机名、Hash）。
- 浏览与操作解耦： 可视化界面消除了信息不对称，让我能看到“管子”外面的全局视图。
最让我满意的是 “业务领域前缀 + 随机文件名” 的一键式策略。
- 前缀（如
Blog/Tech/）： 注入业务语义，确保未来的可迁移性。 - 随机名： 解决物理冲突，降低命名时的认知负担。
结果是：上传时几乎不消耗认知带宽，系统熵增被遏制。事实证明，只有拥有工具链的余闲，才能在源头上解决维护难题。
三、 从“拼接”到“资产”：心理量表系统的进化
同样的逻辑也发生在我的心理量表系统项目中。
- 阶段一（稀缺态）： 使用 ClojureScript 快速搭建 Web，由于 SEO 极差，只能通过 iframe 嵌入 Astro 站点。这是一种典型的“拼接”，维护极其痛苦。
- 阶段二（富足态）： 将核心的计分引擎重构为纯 TypeScript 的 ESM 包。
这是质变。它不再是一个封闭的网页，而是一个核心资产。这个包现在被 Astro（前端网站）、Node.js（后端计分）、Admin App（团体收集）同时消费。
从“应用拼接”到“领域内核复用”，这是在为系统制造未来的余闲。
四、 组织里的“重要但不紧急”
然而，在企业环境中，这种基于余闲的进化往往是奢望。
管理者被 KPI 追逐，陷入时间稀缺，只能关注“上线了什么功能”“修了多少 Bug”。 对于“重构 ESM 包”这种看不见的架构升级，他们往往视而不见，甚至认为是程序员的“炫技”。
结果是：大家都在疲于奔命地赶 Deadline（重要且紧急），或在无意义的会议中消耗生命（紧急但不重要）。没有余闲，就没有负熵运动，系统只能滑向不可维护的深渊。
五、 结语：构建个人的“数字外骨骼”
我很清楚，这种“洁癖”和“过度设计”，某种程度上是对其他场景中无法掌控局面的补偿。在很多时候，我不得不作为观察者，看着稀缺心态如何毁掉长期的技术积累；但在个人的数字花园里，有什么理由不做一个长期主义者呢？。
我利用 AI、自动化脚本和现代化的工具链，作为 “数字外骨骼” —— 在闲暇时提前布局（比如配置好 OSS 工具、重构核心库），人为地制造缓冲（Buffer）。这些预先支付的努力，会在未来需求爆发时，不至于跌入稀缺的管窥陷阱，依然能够淡定从容。
好代码不是写出来的，是用余闲“养”出来的。 如果环境不给你余闲，你就得学会用工具为自己通过“自动化”赎回它。
💡 开放性问题： 你在项目中有没有遇到过“稀缺心态”导致的技术债？你是如何应对的？