只给 Spec, 不给代码: 也许这会成为一种新的软件发布方式

最近看到 openai/symphony 这个项目, 我第一反应不是”这个实现我想试试”, 而是”这个发布方式有点意思”.

因为它在 README 里给出的第一个选项, 不是先教你怎么安装官方实现, 而是先让你根据 SPEC.md 自己做一个. 官方当然也附了一个实验性的 Elixir 参考实现, 但那个被放在了第二个选项. 这个顺序本身就很说明问题: openai 真正想先传递出去的, 可能不是某一份具体代码, 而是这套系统的设计.

我感觉这件事情挺值得记一下. 随着 code agent 越来越强, 以后有些软件的”发布”, 也许真的不一定非得先附带一份完整源码, 而是可以先给出一份足够明确的 spec, 让大家各自用自己熟悉的语言和运行环境去实现. 代码还是会有, 但它开始更像是 spec 的一个实例, 而不是唯一的交付物.

为什么我会觉得这件事很有意思

以前我们看到一个开源项目, 默认的理解通常是: 仓库里的源码就是产品本体, 文档只是帮助你理解和使用它. 就算一个项目有协议, 语言标准或者设计文档, 大多数时候也是配角.

但 Symphony 这次给我的感觉不太一样. 它的 README 直接把 “Option 1. Make your own” 放在前面, 然后指向那份很长的 SPEC.md. 这就不是”如果你有兴趣, 也可以看看设计文档”了, 而是很明确地把”按照这个 spec 自己实现”当成一个正式的入口.

这个姿态变化挺有意思的. 因为它隐含着一个新前提: 对一部分软件来说, “实现” 这件事情本身正在变便宜, 便宜到作者已经可以默认读者不一定非得使用官方代码, 也可以直接把作者的思想搬到自己熟悉的技术栈里.

虽然吧, openai 还能通过这种方式让你消耗多一点的 Token, 一举两得.

为什么这件事在今天开始成立

我觉得最核心的变量, 还是 code agent 变强了.

如果放在前些年, “你自己照着 spec 实现一个” 这句话听起来更像玩笑. 因为哪怕 spec 写得再清楚, 从文档到工程代码之间, 还是隔着大量机械而繁琐的实现劳动. 很多人不是不理解设计, 而是没有精力把它完整落出来.

但现在情况已经开始不一样了. 尤其像 Symphony 这种项目, 它的核心价值其实并不在某个特别难复现的底层算法, 而是在一套系统边界划分和工作流设计上: 问题是什么, 目标是什么, 有哪些核心组件, 域模型是什么, WORKFLOW.md 这种仓库内契约怎么组织, 配置怎么解析, agent runner 和 issue tracker 怎么配合. 这些东西一旦写进 spec, 就已经把最重要的”思想骨架”交代得差不多了.

剩下的代码, 很多时候更像是把这份骨架翻译成某一种语言和工程风格. 而”翻译” 这件事情, 恰恰是 code agent 现在越来越擅长做的.

这和以前的”标准”还不太一样

当然, “先有规范, 后有实现” 并不是什么新鲜事. 协议, 语言标准, 文件格式标准, 以前一直都有. 但我觉得这次不太一样的地方在于, 它不是某个成熟生态经过多年沉淀以后, 再慢慢整理出一份标准文档.

它更像是一开始就在把 spec 当成第一交付物.

而且这里还多了一个以前没有那么强的前提: 发布者已经可以合理假设, 读者身边有一个足够能干的 coding agent, 可以把 spec 迅速翻成一个能跑的版本. 也就是说, 这份 spec 面向的, 并不只是耐心读文档的人类工程师, 还面向一个随时可以开工的实现代理.

这就让 “spec” 从过去那种偏静态, 偏归档的文档, 变成了一种可以被直接执行的发布介质.

我觉得以后可能会出现什么

我现在越来越觉得, 以后有一类软件项目, 可能真的会逐渐走向这种 “spec-first” 的发布方式.

也就是作者发布的核心内容会变成:

• 一份足够明确的 spec
• 一份说明系统边界和约束的工作流/提示词
• 一组可以验证行为的测试或者样例
• 也许再附一个参考实现, 但它不一定是唯一实现

然后使用者这边, 就不再只是 “git clone 然后跑起来”, 而是”把 spec 交给我自己的 agent, 让它按我熟悉的语言, 框架, 部署方式生成一个版本”.

这件事的好处其实不少.

第一, 不同团队可以更自然地贴合自己的技术栈. 有人想用 Elixir, 有人想用 Go, 有人想用 Rust, 有人甚至只想把核心思想吸收到自己现有系统里, 都不必被官方实现绑定得太死.

第二, 作者传播的重点会从”这一份代码”转向”这一套设计”. 这样的话, 项目的影响力有时候反而可能更大, 因为别人采纳的不只是仓库, 而是背后的方法论.

第三, 对很多 agent 时代的新工具来说, 参考实现的寿命未必像以前那么重要. 真正持久的, 可能是 spec, 测试和工作流约束; 具体代码则可以不断被本地化, 重写, 替换.

当然, 这也不是所有软件都适合

不过我觉得这条路也不是哪里都能用.

如果一个项目的核心价值在于非常细致的性能优化, 极重的工程积累, 某种很难被文字完全描述的交互体验, 那么光有 spec 显然不够. 还有一些东西, 比如模型权重, 特定训练结果, 特定数据集加工产物, 也不是”给个 spec 就能自己做一个”的.

所以更可能先变成 spec-first 的, 我猜会是这几类东西:

• orchestration / workflow 类工具
• 协议和服务胶水层
• 很多企业内部其实只想落地思想, 不一定执着于官方实现的系统
• 本来就很强调 contract 的基础设施组件

另外, 如果真的要让 spec 变成主要交付物, 我觉得以后还得配套更多东西, 比如 conformance test, 标准样例输入输出, 甚至针对 agent 的实现提示. 不然 spec 写得再长, 不同实现之间还是很容易漂.

一个我觉得很新鲜的变化

以前 Linus Torvalds 说 “talk is cheap, show me the code”. 这句话放到今天可能就不太对了. 因为, “code is cheap”. 在 code agent 逐渐成熟以后, 也许会开始出现另一种情况: 真正稳定的部分不一定是某一份源码, 而是源码背后的 spec.

源码变成了 spec 的一个瞬时投影, 可以用这个语言实现, 也可以用那个语言再实现一次; 可以今天这样组织, 明天换一套框架重写. 只要 spec 和行为约束还在, 作者真正想表达的东西就还在.

如果真往这个方向发展, 那以后”发布一个软件”这件事情本身, 可能都会和今天不太一样. 发布的不只是代码, 而是设计, 是约束, 是一份足够清晰到可以让 agent 去继续生产代码的说明书.

我觉得这件事挺有意思的. Symphony 当然还远远不是这个趋势的终点, 甚至它自己也仍然带着参考实现. 但至少它已经把一种以前不太像”正式发布方式”的东西, 很自然地摆到了台前.

分类:  随笔 
标签:  OpenAI  code agent  软件工程  开源软件  spec