code is cheap， show me your design ——分享一个我的 AI 时代的软件开发范式

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

爱意满满的作品展示区。

最近一年，我自己项目里的代码，从 AI 生成 70% 到现在基本接近 100%。但一个有点反直觉的变化是：写代码反而不再是瓶颈，真正变难的是设计。

我自己以前的软件开发流程其实很典型——先写代码，再补设计，最后再修 bug 。
在没有 AI 的时候，这套方式是成立的，因为实现本身就是最耗时、最稀缺的部分。但当 AI 开始参与之后，这个前提消失了：代码可以很快生成，甚至几乎没有成本，可系统却开始变得越来越混乱。你会发现，问题不再是“怎么写”，而变成了一个更根本的问题——你到底想让这个系统长成什么样？

当实现不再构成约束，设计就从“附属品”变成了真正的核心。也正是因为这个变化，我开始刻意反过来做一件事：不再从代码出发，而是从设计出发，把“spec”放在最前面，让它成为整个开发过程的起点。SpecFlow 就是在这样的背景下慢慢形成的一个实践方式（ https://github.com/Bingordinary/SpecFlow ）。

它本质上不是一个框架，而更像是一种组织开发过程的方式：先定义设计（ spec ），再让 AI 按照设计去实现，然后通过持续的 Q&A 去修正系统行为，让结构逐步收敛。你可以把它理解为一种“设计驱动”的开发范式，只不过这里的执行者不再是纯粹的人，而是人和 AI 的协作系统。

这个项目现在还很早期，也谈不上成熟，但我越来越确定一个方向：当实现变得廉价之后，真正决定系统质量的，不再是代码本身，而是你如何描述、约束和组织这个系统的结构。

这个不是一个框架，只是一个范式的探索，你可以在这个基础上按照自己的开发习惯进行改造。

如果你也在用 AI 写代码，或者已经开始觉得“代码不是问题，结构才是问题”，或许我们在面对的是同一个拐点。欢迎一起讨论。Btw ，希望路过的老哥能赏个 Star

设计

范式

4 条回复 • 2026-04-20 17:47:17 +08:00

ohoh

2 小时 17 分钟前

spec-kit
open-spec
superpower
gsd
gstack

对比优势是？

bingordinary

1 小时 49 分钟前

@ohoh 这个问题挺关键的，我一开始其实也用过 bmad 、spec-kit 这类工具。

后来决定自己做一套，主要是因为我遇到的不是“流程不够好”的问题，而是另外一类问题：

当 AI 参与之后，仓库里到底什么才算“真”。

比如：

spec 还在，但实现已经变了
代码是对的，但设计已经过期
agent 按旧理解在执行
人又在用新的描述去改

这时候其实没有一个稳定的“真相”，系统是会慢慢漂的。

所以我在做 SpecFlow 的时候，重点不在“让 AI 更好地执行”，而是在尝试解决另一件事：如何在持续修改中，维护一个一致的设计真相。

比如：

谁有权修改
修改后哪些结论自动失效
spec / 代码 / 行为不一致时以谁为准

如果一定要对比的话，我的理解是：

这些项目更多是在优化 “怎么让 AI 把事情做完”
SpecFlow 更关注 “做完之后，什么才算是系统的真实状态”

另外它确实不太像一个 framework 。framework 更像是在既定流程里提供工具和角色（ planner / executor / agent 这些），而 SpecFlow 更像是在调整一个更前面的问题：开发应该从哪里开始，以及什么东西才是整个过程的锚点。

在 AI 参与之前，这个锚点通常是代码；
但在 AI 参与之后，我觉得这个锚点需要变成“设计本身”

ohoh

1 小时 37 分钟前

也就是每个公司都有自己的一些流程上的差异。
一个常见的流程：需求 -> 设计 -> 开发 -> 测试。
实际后面 3 个流程任何一个都可能回归到需求这里的变更，也就是原定的 spec 需要更新，这时候的 spec 不是后续开发的 spec ，更像是你说的对齐标准的，假设我们定义为 PRD.md ，spec 才再是基于 PRD.md 的分解，但是这个 PRD 如何维护，相当于是 PRD -> spec -> plan -> task -> build/implement 。
对齐的是 PRD ，目前我看到的一些插件，更多的是任务完成后对行为或经验的沉淀，而不是需求的沉淀。

bingordinary

1 小时 25 分钟前

@ohoh 我大概理解你的意思，是把 PRD 作为最终的对齐锚点，这个在传统流程里是成立的。

但我自己在用 AI 的过程中有个感觉：

PRD 和 spec 这两层开始没那么分得清了。

以前要分开，是因为：

PRD 给人看
spec 给工程师实现

但现在实现很多是直接交给 AI ，其实更需要的是一份：既表达需求，又能约束实现的东西

不然很容易出现：

PRD 是一版
实现已经是另一版
中间改动又是第三版

最后其实很难说哪个才是“现在的真实状态”。

所以我现在用 spec 这个词可能不太准确，更像是在指一个把需求和设计揉在一起的描述。

大概是这个方向，还在摸索。当然，我这么设计的另外一个主要原因是我是个人开发者，所以在我的开发过程中，分工不会像公司那么明确。