用户 f 在代码托管平台 GitHub（GitHub）上开设了 jev-leftpad 仓库，该项目旨在使用类型安全人工智能（TypeSafe AI）推出的杰夫（Jev）工具对字符串执行左填充处理，即在文本左侧增补字符直至满足设定长度。仓库描述仅以 For reasons 标注缘由而未详述。项目包含相关源代码与配置文件，供开发者获取后集成至自身系统实现字符串补齐功能。
正文
jev-leftpad
用 Jev 实现字符串左填充。
其实用 padStart() 一行就能搞定，也根本不需要调用模型，不过还是写一下：
安装：npm install jev-leftpad
使用：引入 leftPad 后执行 await leftPad('jev', 8)，输出大概率是 " jev"。
使用前需设置 TYPESAFE_API_KEY。该包通过 TypeSafe 原生的 @typesafe-ai/sdk 调用 jev-latest，要求 Node.js 20 或以上。
API
调用 await leftPad(value, targetLength)，targetLength 必须是非负安全整数。
Jev 会拿到一个 Choice，选项为 space_0 到 space_10。以上例来说它应选中 space_5，JavaScript 据此造出五个空格并把原值接在后面。所以这个包只能加 0 到 10 个空格，超过 10 个 Jev 就没有正确选项了，这也挺契合项目气质。
每次调用对应一次 TypeSafe API 请求，且禁用重试。请求可能失败、Jev 可能选错，而且比 padStart() 贵得多。请勿用在生产环境或任何重要地方。
开发
运行 npm install 和 npm test。测试会 mock 掉 Jev，不需要 API key 也不消耗 TypeSafe 额度。
许可证
MIT
关于
用 TypeSafe AI 的 Jev 来左填充字符串。没啥原因。
评论
社区普遍以讽刺和玩笑态度看待这个用 Jev 模型决定左填充空格数的项目，视其为 AI 依赖泛滥的荒谬缩影；少数人则认真探讨其技术缺陷、可靠性或提出更优雅实现。
认为这是 AI 过度依赖的荒谬象征
- 项目用 AI 模型决定简单填充空格数，被视作让他人更依赖 AI 的又一产物，并预言将如 leftpad 般在未来引发故障（较多人） > 又一个让他人更依赖 AI 的项目罢了（@serious_angel）
担忧代码进入生产环境后的隐患
- 提醒勿用于生产，若被供应商化后填充可能静默漂移，且需 SBOM 和质量门才达生产级，测试模拟 Jev 显得讽刺（较多人） > 更可怕的是有人把它供应商化且填充在运行中静默漂移（@sparrowidle）
指出项目技术缺陷或提出改进
- 遗漏 Jev 置信度分数可映射分数空格；建议直接用空格作标准名更优雅；超过 10 空格无方案，可让 Jev 检查范围（少数人） > 它没利用 Jev 置信度，本可用瘦空格表示分数空格以发挥全力（@sethaurus）
视其为有趣实验并探讨实际用途
- 好奇实际可靠性作为便宜基准；有人已实现类似功能用其他模型，愿测试省钱；认为 Jev-in-the-Loop 合理（少数人） > 我刚用 OpenAI Astra 实现相同功能，或许你的实现能帮我省钱（@hanspagel）
对 Jev 话题感到疲劳或狂热
- 称 HN 今天满是 Jev，已感疲劳，或认为单字母用户名比项目更令人印象深刻（较多人） > 我已经得了 Jev 疲劳（@larnon）
戏谑 AI 将接管基础编辑操作
- 有人讽刺期待 Jev 辅助退出 vim 或代做决策，反映对 AI 入侵基础操作的调侃（少数人，代表社区情绪） > 我在等 Jev 辅助我退出 vim，不，是决策是否退出 vim（@yitchelle）
有价值的补充
- 类比十年前用 TensorFlow 写 FizzBuzz 的玩笑，说明用重型模型做琐碎任务并非新鲜事（@ckastner）
- Jev 模型存在微小固有偏差，有专门分析页面（@freakynit）
- Jev 类似 BERT，可用于检查代码是否符合自定义规则的二分类（@jdw64）