一份 Spec,七种语言:没有代码的软件库能走多远?

图：无代码软件库概念示意

Drew Breunig 最近发布了一个名为 whenwords 的开源库，用来把时间戳转换成人类可读的字符串，比如把 UNIX 时间戳转成“3 小时前”。这类库并不稀奇，稀奇的是：这个库里没有一行代码。

没错，零行代码。打开仓库，你只能看到规格文档、测试用例，以及一段安装说明——实际上就是一段提示词，让你复制粘贴给 Claude 或 Cursor，然后 AI 就能为你生成 Ruby、Python、Rust、Elixir、Swift、PHP、Bash 等任意语言的实现。Drew 甚至还用 Excel 公式实现了一版。

这个实验看似荒诞，却触碰到了一个严肃的问题：当 AI 写代码的能力越来越强，软件工程的底层逻辑会发生什么变化？

核心要点：

• Spec-Only 库用规格文档替代代码实现，依赖 AI 按需生成

• 这种模式适合简单工具库，但在性能、测试、维护等场景仍需传统代码

• AI 编码能力的跃升正在重新定义“什么值得写成代码”

一个思想实验：如果代码可以“按需生成”

传统的软件库是这样工作的：开发者写好代码，发布到包管理器，其他人通过 npm、pip、gem 这些工具安装，然后在项目里调用。这个模式已经运转了几十年，几乎没人质疑过它的合理性。

但 whenwords 提出了另一种可能性。它的仓库里只有两样东西：一份 500 行的规格文档（SPEC.md)，详细描述了五个函数应该如何工作；一套 125 个测试用例，用来验证实现是否正确。安装方式简单到可笑：复制一段提示词，粘贴给 AI，告诉它你用什么语言、什么时区，然后等几秒钟，代码就生成好了。

这种模式的核心假设是：如果规格足够清晰、测试足够完备，那么“实现”这件事就可以交给 AI 来做。你不需要维护七种语言的代码仓库，不需要处理不同语言的包管理器，不需要为每种语言单独修 bug。你只需要维护一份规格文档，剩下的事情让 AI 在用户的机器上完成。

图：从多语言实现到按需生成的演进

这听起来很美好，但问题也很明显：这种模式真的可行吗？什么场景下适用，什么场景下不适用？

为什么这个实验现在才出现

Drew 在文章里提到了一个关键背景：Claude Opus 4.5 在 2024 年第四季度跨过了某个阈值。所有用过它的人都能感觉到，这个模型在“实现严格定义的代码”这件事上已经达到了一种“不可思议”的程度。对于 whenwords 这样的小工具，Claude 能在一次对话里完成任意语言的实现，不需要反复调试。

这种能力的提升不是线性的，而是跨越式的。一年前，你可能需要跟 AI 来回对话五六轮才能得到一个勉强能用的实现；现在，只要规格写得清楚，一次就能搞定。这种变化让“Spec-Only 库”从理论上的可能变成了实践中的现实。

但这里有个微妙的地方：AI 的能力越强，我们就越需要重新思考“什么值得写成代码”。过去，我们把所有逻辑都写成代码，是因为没有别的选择；现在，当代码可以按需生成时，我们需要问自己：哪些东西应该固化为代码，哪些东西可以保持为规格？

五种情况下，你仍然需要“真正的代码”

Drew 在实验中总结了五个场景，在这些场景下，传统的代码库仍然不可替代。这五个场景值得仔细看看，因为它们勾勒出了“Spec-Only 模式”的边界。

图：五种仍需传统代码库的场景

性能是第一道门槛。 如果你要实现一个浏览器，规格文档当然存在——HTML、CSS、JavaScript 的标准都写得清清楚楚。理论上，你可以让 AI 按照这些标准生成一个浏览器。但问题是，浏览器需要极致的性能优化。你希望打开几百个标签页不会内存泄漏，希望渲染速度快到用户感觉不到延迟，希望有大量用户在真实场景中遇到各种奇怪的网站、有 bug 的 JavaScript、错误的导入，然后把这些问题修复并固化到代码里。这种级别的优化，不是一次性生成能解决的。

测试的复杂度会迅速失控。 假设你发现 whenwords 在 Elixir 实现里有个 bug，你修改了规格文档，加了一行说明来避免这个问题。你提交 PR, Drew 验证了 Claude 确实能生成正确的 Elixir 代码。但这个改动会不会影响 Ruby、Python、Bash、Excel 的实现？你需要测试所有语言吗？如果要测试，你是用 Claude 测试，还是用 Codex 测试，还是用 Qwen 测试？你最终会发现，为了保证一份规格文档在所有语言、所有 AI 模型上都能正确工作，你需要的 CI/CD 管道可能比维护多个代码仓库还要复杂。

Bug 修复变成了概率游戏。 当用户报告一个 bug 时，传统代码库的维护者可以直接看代码、复现问题、定位原因、提交修复。但在 Spec-Only 模式下，用户的代码是 AI 生成的，你的代码也是 AI 生成的，两者很可能不一样。你怎么复现用户的问题？你修改规格文档后，怎么保证用户重新生成的代码一定能解决问题？AI 模型是概率性的，规格越复杂，不同实现之间的差异就越大，bug 修复的难度就越高。

持续更新是另一个挑战。 有些库需要频繁更新，比如 LiteLLM 这样的 AI 网关，它需要快速支持新模型、修复不同平台的连接问题、响应用户的反馈。还有一些基础设施库，比如 nginx、Rails、Postgres，它们需要推送安全补丁。这些场景下，用户希望“拉取最新版本”就能获得修复，而不是“重新生成一遍代码，然后祈祷新版本能解决问题”。

社区是最被低估的价值。 开源项目的价值不仅仅在于代码本身，更在于围绕代码形成的社区。大量用户意味着更多 bug 被发现，更多贡献者意味着更多 bug 被修复，完善的测试意味着 PR 能更快被接受，活跃的社区意味着有人随时可以提供帮助。代码不只是规格的实例化，它是人和文化围绕一个目标结晶出来的产物。这是开源的魔力，也是为什么我们愿意依赖某些代码库。

对于 whenwords 这样的小工具，你不需要加入一个俱乐部。但对于那些你想要“构建在其上”的基础设施，社区是不可或缺的，因为社区能提供上面所有的东西。

这个实验真正的价值：重新定义边界

whenwords 本身并不重要，重要的是它提出的问题：当 AI 写代码的成本趋近于零，软件工程的哪些部分会被重新定义？

过去，我们把所有可复用的逻辑都打包成库，是因为“写一次，到处使用”比“每次都重写”要高效得多。但现在，如果 AI 能在几秒钟内根据规格生成代码，那么“到处使用”和“每次生成”的成本差距正在缩小。这意味着，我们需要重新思考什么值得固化为代码，什么可以保持为规格。

图：Spec-Only 工作流程示意

对于简单的工具函数，Spec-Only 模式可能是合理的。它让你避免维护多个语言的实现，让用户可以按照自己的项目规范生成代码，让整个生态更加灵活。但对于复杂的框架、需要极致性能的系统、需要持续维护的基础设施，传统的代码库仍然不可替代。

这个边界在哪里？现在还没有明确的答案。Drew 提到，whenwords 只有五个函数，不需要太多依赖，基于一个明确的标准（UNIX 时间），规格文档只有 500 行。如果规格变成 5000 行呢？如果函数之间有复杂的依赖关系呢？如果需要处理各种边界情况呢？这个模式还能工作吗？

我们不知道。但这正是这个实验有趣的地方：它不是在给出答案，而是在探索边界。

一个更大的问题：当编码变成“免费”

whenwords 背后隐藏着一个更大的问题：如果写代码的成本真的趋近于零，软件工程会变成什么样？

这个问题在 2024 年第四季度开始变得紧迫。Opus 4.5、Codex、Cursor 这些工具的能力跨过了某个阈值，所有用过它们的人都能感觉到。现在，工程师们开始问：“当编码是免费的，软件工程还剩下什么？”

一种可能的答案是：规格设计、架构决策、测试策略、性能优化、社区建设。换句话说，那些“不能被 AI 一次性生成”的部分，会变得更加重要。写代码可能会从“软件工程的核心技能”变成“软件工程的基础操作”，就像打字从“秘书的核心技能”变成“所有人的基础操作”一样。

但这只是一种可能性。另一种可能性是，我们会发现很多现在看起来“不能被 AI 生成”的东西，其实只是因为 AI 还不够强。性能优化需要人工吗？还是只是需要更好的性能测试框架和更强的优化模型？Bug 修复需要人工吗？还是只是需要更好的错误追踪和更强的调试模型？社区建设需要人工吗？还是只是需要更好的协作工具和更强的沟通模型？

我们不知道答案。但可以确定的是，这些问题在未来几年会变得越来越重要。

写在最后

whenwords 是一个玩具项目，Drew 自己也承认这一点。但好的玩具项目往往能提出好的问题。

这个项目让我们看到，当 AI 的能力达到某个阈值，一些我们习以为常的东西会开始松动。代码库、包管理器、多语言实现，这些在过去几十年里构成软件生态基础的东西，可能不再是唯一的选择。

但同时，这个项目也让我们看到，很多东西仍然不可替代。性能、测试、维护、更新、社区，这些东西不是“代码”本身，而是围绕代码形成的整个生态系统。AI 可以生成代码，但它还不能替代这个生态系统。

所以，当代码变成“空气”，软件工程会变成什么样？我们还不知道。但可以确定的是，这个问题值得认真思考。因为答案可能会在未来几年里逐渐浮现，而那时，我们需要准备好。

关键要点：

• Spec-Only 模式适合简单、明确、不需要频繁维护的工具库

• 性能、测试、维护、更新、社区这五个维度仍然需要传统代码库

• AI 编码能力的提升正在重新定义“什么值得固化为代码”

• 未来的软件工程可能更关注规格设计、架构决策和生态建设

下一步行动：
如果你正在维护一个工具库，不妨问问自己：这个库的核心价值是代码实现，还是规格定义？如果是后者，也许可以尝试 Spec-Only 模式。如果是前者，那就继续打磨代码，因为那才是真正的护城河。

讨论：
你在项目中遇到过“其实只需要规格，不需要代码”的场景吗？你觉得 Spec-Only 模式的边界在哪里？欢迎在评论区分享你的想法。

如果这篇文章让你重新思考了代码的本质，点个“在看”让更多人看到这个有趣的实验。