@
ohoh 这个问题挺关键的,我一开始其实也用过 bmad 、spec-kit 这类工具。
后来决定自己做一套,主要是因为我遇到的不是“流程不够好”的问题,而是另外一类问题:
当 AI 参与之后,仓库里到底什么才算“真”。
比如:
spec 还在,但实现已经变了
代码是对的,但设计已经过期
agent 按旧理解在执行
人又在用新的描述去改
这时候其实没有一个稳定的“真相”,系统是会慢慢漂的。
所以我在做 SpecFlow 的时候,重点不在“让 AI 更好地执行”,而是在尝试解决另一件事:如何在持续修改中,维护一个一致的设计真相。
比如:
谁有权修改
修改后哪些结论自动失效
spec / 代码 / 行为不一致时以谁为准
如果一定要对比的话,我的理解是:
这些项目更多是在优化 “怎么让 AI 把事情做完”
SpecFlow 更关注 “做完之后,什么才算是系统的真实状态”
另外它确实不太像一个 framework 。framework 更像是在既定流程里提供工具和角色( planner / executor / agent 这些),而 SpecFlow 更像是在调整一个更前面的问题:开发应该从哪里开始,以及什么东西才是整个过程的锚点。
在 AI 参与之前,这个锚点通常是代码;
但在 AI 参与之后,我觉得这个锚点需要变成“设计本身”