spec-driven 需要想明白的几个问题

使用 openspec 开发了一段时间随着时间河水的参杂使用 spec 最初的惊艳感消失回归冷静有几个问题便浮在脑中了。窃以为这几个问题是相信并使用 spec 驱动开发的人必须要想明白的几个问题。『spec 是给人看的还是给模型看的』spec 驱动开发的核心就在于 spec 文档但我们费劲千辛万苦生成的这个文档到底是给模型看的还是给人看的呢。当然是给模型看的。那么这个 spec 的正确性是否要人来保证呢如果这路有人力的参与这个 spec 不最终还是要人来看吗但spec 始终是个 markdown markdown再强大也不如图片架构图ppt 更适合人阅读。那么阅读这个 spec 反而变成一个很痛苦的事情了。我的解决方案是生成 spec 的时候尽量生成流程图人阅读的时候只阅读流程图而不需要阅读文字。『spec 是不是越多越好』有人喜欢每个需求的 spec 都进入 git 仓库。但实话说这些繁琐的 changelist 就和天津的包子一样狗都不理。我们一个接口可能被 100 个需求改过我需要存储 100 个需求的 spec 吗不需要。我们只要存储这个接口的最终描述。所以spec 不是越多越好。『spec 驱动的迭代周期和真实需求的迭代周期一样吗』所有 spec 驱动都会告诉你一个需求在 spec 驱动开发流程中先计划拆分任务然后实现最后测试。但是真实的情况是怎么样的呢需求出现技术方案出现技术实现开始需求变更。需求变更完技术方案变更变更实现后需求还有可能变化。好不容易到了测试测试发现一个关键 bugbug 发现不可解于是需求继续变更。上面流程很真实。那么比如 openspec有需求规划需求实现需求归档。我们要等到最后要上线前spec 再归档其实是猴年马月的事情了。在这漫长的岁月长河之中我们维护着这些 spec就像维护一颗定时炸弹一样知道它一定会被变更会爆炸但又害怕它变更爆炸。所以spec 驱动的流程和真实的一个需求的流程一定是不要一一对应起来的。就是说一个真实需求来的时候你想到了一个实现实现一个版本就走一遍 spec 的开发实现归档流程。当有额外变更的时候继续走一遍 spec 的开发实现归档流程。一个真实需求需要多个 spec 驱动流程来实现。『你真的相信模型加 spec 的组合优于模型本身吗』最重要的就是这点你还相信光吗我们之所以选择 spec 驱动开发就是相信有了 spec 沉淀模型能更懂我们的项目会比没有 spec 的模型更强大。即模型 spec 代码 模型 代码但这是真的吗这里一方面有 spec 和代码一致性问题cap 三角原理告诉我们不能既要又要我们要了 spec那么一致性就不可能是实时一致的。一旦 spec 和代码不一致是否会成为一个负号。让模型的能力降低呢反观你的代码是不是就是一个最好的 spec代码的注释单词的含义。在 context 越来越无限的情况下这个不等式是否能继续成立呢或者换个问法如果我写够足够多的 spec是否有规模效应让模型更得我心呢关于这点我也没有答案。