最近一年，我自己项目里的代码，从 AI 生成 70% 到现在基本接近 100%。但一个有点反直觉的变化是：写代码反而不再是瓶颈，真正变难的是设计。
我自己以前的软件开发流程其实很典型——先写代码，再补设计，最后再修 bug 。
在没有 AI 的时候，这套方式是成立的，因为实现本身就是最耗时、最稀缺的部分。但当 AI 开始参与之后，这个前提消失了：代码可以很快生成，甚至几乎没有成本，可系统却开始变得越来越混乱。你会发现，问题不再是“怎么写”，而变成了一个更根本的问题——你到底想让这个系统长成什么样？
当实现不再构成约束，设计就从“附属品”变成了真正的核心。也正是因为这个变化，我开始刻意反过来做一件事：不再从代码出发，而是从设计出发，把“spec”放在最前面，让它成为整个开发过程的起点。SpecFlow 就是在这样的背景下慢慢形成的一个实践方式（ https://github.com/Bingordinary/SpecFlow ）。
它本质上不是一个框架，而更像是一种组织开发过程的方式：先定义设计（ spec ），再让 AI 按照设计去实现，然后通过持续的 Q&A 去修正系统行为，让结构逐步收敛。你可以把它理解为一种“设计驱动”的开发范式，只不过这里的执行者不再是纯粹的人，而是人和 AI 的协作系统。
这个项目现在还很早期，也谈不上成熟，但我越来越确定一个方向：当实现变得廉价之后，真正决定系统质量的，不再是代码本身，而是你如何描述、约束和组织这个系统的结构。
这个不是一个框架，只是一个范式的探索，你可以在这个基础上按照自己的开发习惯进行改造。
如果你也在用 AI 写代码，或者已经开始觉得“代码不是问题，结构才是问题”，或许我们在面对的是同一个拐点。欢迎一起讨论。Btw ，希望路过的老哥能赏个 Star