给一个字符串前面补几个空格，需要几行代码？在现代前端环境里，只需要原生调用一行 padStart()。但在 GitHub 上，开发者 f 偏偏建了一个名为 jev-leftpad 的开源仓库，郑重其事地接入了名为 TypeSafe AI 的 Jev 运行时，把补空格这件事交给了大模型。
项目的公开描述只有短短一句：Left-pad strings with TypeSafe AI's Jev. For reasons.
没有冠冕堂皇的宏大叙事，也没有融资路演常用的商业黑话。截至目前，这个仓库在 GitHub 上仅有 15 个 Star、1 个 Fork 和 2 个 Issues。但它在极客社区引发的会心一笑，恰恰戳中了当下生成式 AI 泡沫里最荒唐的症结：当一个原本零成本、确定性的基础操作，被强行包上一层 AI 外衣后，我们究竟是在解决问题，还是在制造新的工程灾难？
荒诞的账本：把确定性算术做成概率抽奖
翻看 jev-leftpad 的具体实现，过程近乎一场精密的荒诞剧。
为了给字符串左侧填充空格，代码会向 TypeSafe 的 API 发起一次网络请求。模型拿到的不是通用的算法逻辑，而是一个预设的选项池：从 space_0 一路排到 space_10。如果要将一个 3 字符的单词补齐到 8 位，模型需要做出选择，命中 space_5，随后程序再读取数字并拼接出 5 个空格。
这意味着该项目一次最多只能补 10 个空格。如果目标长度超出范围，模型连正确选项都没有。作者在文档里写得相当坦白：请求可能失败，模型可能选错，而且每一次调用都在烧钱消耗额度。
任何具备基本常识的工程师都会看出其中的荒谬。一个原本由 CPU 寄存器和内存寻址在纳秒级搞定的逻辑，被硬生生套上了序列化、网络传输、显存推理和反序列化流程。
公网甚至检索不到这个所谓的 TypeSafe AI Jev 到底是一套未发布的商业系统，还是开发者信手捏造的恶搞外壳。但这并不妨碍它的讽刺力度：在当下的技术语境里，只要标榜自己是类型安全加上人工智能，哪怕做的是倒退十年的低效轮子，也总有人愿意为这种包装买单。
历史的回声：十年前的脆断与十年后的迷幻
这个项目之所以选择 left-pad 作为载体，是因为这个词在现代软件史上是一座抹不掉的耻辱柱。
时间倒回 2016 年。开发者 Azer Koçulu 因为与 npm 官方发生命名纠纷，一怒之下下架了自己名下的数百个开源模块。其中一个仅有 11 行代码、功能就是给字符串补齐空格的微包 left-pad 骤然消失，随即引发多米诺骨牌效应，导致包括 React、Babel 在内的全球主流开发工具链大面积停摆。
当年我们被 11 行代码卡死，今天我们用几千亿参数的集群去猜这 11 行代码的结果。
那场危机过后，整个行业开始反思过度模块化与无休止的微小依赖。各家语言标准委员会迅速跟进，把填充逻辑变成了底层的原生能力。天下熙熙，本以为吸取了教训的工程界会更加注重韧性，未曾想生成式技术的大潮一过，历史换了套衣裳卷土重来。
2016 年的病灶是开发者把极简任务外包给第三方 npm 包；当下的病灶则是创业者把确定性逻辑外包给云端大模型。前者因为人际纠纷断掉了代码链，后者正在因为网络抖动、模型幻觉和计费停机摧毁系统的确定性。
手段变先进了，技术堆栈变庞大了，但工程思维里的投机本能毫无长进。
撕开 AI 包装狂潮的遮羞布
我更在意的是，jev-leftpad 绝不是一个单纯的技术恶作剧，它是一把精准剖开行业虚荣心的手术刀。
过去两年里，我们在各类技术社区见过了太多类似的产品：给现有的记事本接一个聊天框就声称是下一代生产力中枢；给传统的 SQL 查询套一个翻译模型就敢按月订阅收费；把成熟的规则引擎替换为推理大模型，美其名曰智能化重塑。
很多团队心知肚明，大模型根本不擅长做高精度、低延迟的原子计算。但只要写上智能二字，就能在资本市场讲通故事，就能在汇报材料上博得眼球。
- 风险.将原本可预测的确定性系统替换为非确定性的概率模型，本质上是在用巨大的算力成本与架构脆断风险，换取毫无增量的概念包装。
古人讲大音希声，大象无形。真正成熟的工业化技术往往越走越轻，润物无声地沉淀进基础设施底座；而泡沫鼎沸时期的技术应用，却总是倾向于把简单的事情搞复杂。
jev-leftpad 仅有的 15 个 Star 就像是一声清脆的口哨。它提醒每一个技术从业者：不是所有的文本处理都配得上一次模型调用，也不是所有的科技叙事都经得起一双清醒眼睛的打量。