bingordinary

皎月连 + moonlight

@R0Nnn 我现在这个实践方式还是比较适合后端。前端和 UIUX 我最近也在思考怎么弄，我也没想好。我觉得可能的一个方式是对 UI 组件库进行建模和统一调度。但是这种实践就会对开发方式进行强耦合，感觉没有那么优雅。

@lozzow 以代码量减少作为标准，这点还蛮有意思的。学习了

感觉有点卡卡的，而且不大好瞄准

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

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

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

以前要分开，是因为：

PRD 给人看
spec 给工程师实现

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

不然很容易出现：

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

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

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

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

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

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

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

比如：

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

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

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

比如：

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

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

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

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

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