大项目中大家真的会用 Spec-Driven Development 吗？

试试 superpowers 加个记忆定时提取知识库，基于 skill 比基于固定 command 组织工作流更灵活。基于记忆提取比基于 spec 维护知识库更简洁。个人感觉大模型工具用起来要符合直觉。强行用工程化手段约束模型是工程师的一厢情愿。不懂工程的人往往 vibe coding 反而有更灵光的情况

巧了，我的选择是把交易策略 SPEC 化，在 strategy studio 编辑定义 SPEC ，然后发布到策略服务中运行。

AI 主力编程的场景下，人类可能更适合去做 SPEC 定义的工作。

我的建议是，自行定义 SPEC 规范，反正都是丢给 AI 实现，这样 AI 会有更全面的理解和支持。

@lanbos 加个记忆定时提取知识库，这个怎么理解呢？

最近在研究和尝试 sdd ，我觉得 plan mode 和 superpowers 算是轻量单次的 sdd ，这种思想是对的。在生成代码前先通过跟 ai 多次交换意见并最终对规格达成一致，让 ai 对任务内容有全面理解后再开工。可以很大程度避免 vibe 的漂移和幻觉问题。

想更深入地在整个项目贯彻 sdd 的话就会面临维护全局 spec 的挑战。仅仅将每次任务的 spec 存放在那里不仅很难作为一个体系化的知识来参考，还有可能前后矛盾。所以 openspec 用 delta 机制来更新 spec ，并用 Delta 来驱动代码变更。理论上没错，但这不是一个很强的约束能保证代码忠实反映 spec 。

复杂度只会转移不会消失，只是从维护代码转移到维护 spec 了。随着 ai 的上下文窗口增长，未来可能仓库里只有 spec ，想要 code 的时候就一股脑扔给 ai 瞬间 code 就完成了，或者直接让 ai 将 spec 当 system prompt 来模拟业务系统。

虽然我们会定义项目的 rules ，但很少会严格地搞 spec---太烦了

只要保证代码是符合项目规范的，设计是健全的，测试是充分的

那就行了

用了 SPEC 之后的最大感受是 SPEC 也是需要维护的，每次调整都要同步维护 SPEC 文档。

@lanbos superpowers 或者 skill 就是工程化的最佳证明。"更灵光"这个词更不会出现在一个合格的工程系统里面。

@7kg0b 我觉得从 AI 对人的替代程度看，不应该简单定义为“工程系统”，而更像一个“项目团队”

体感上，Red / Green TDD or BDD 开发会更加可控一些，Spec 腐烂漂移问题很严重

我们团队在全员推用 superpowers ，还不错。
TDD 开发。

@7kg0b 类似 openclaw 或 Claude code 的做梦机制，或者用外挂的记忆库，通过 hooks 定时从对话的 session 中提取记忆，spec 会腐化的，总需要维护，记忆更容易配合模型能力

We tried spec-kit but it's not suitable for us. it produce so much md to review but we don't wish human in the loop to much.

so now we prefer to use more lightweight options like plan mode or use superpower skills to write and execute plan.

@7kg0b 以现在的模型迭代速度，除了模型 infra 外其他工程会越来越薄（后面 infra 可能模型也会自己迭代）。灵光的说法确更产品化，的确不是工程化的描述

spec 阅读起来太难受了, 要修改也很难改, 还不如 superpowers

我更倾向于强化 test driven, 即使 spec ，ai 在未来还是有幻觉，但 test 是死的，你代码不符合预期就是不符合

不测试是不可能的，SDD 出来的 spec 都是看起来很美，实际上的代码跟 spec 还是有一定的差距，必须要 TDD 不让项目跑偏

用过 openspec ，感觉太唆太麻烦了，而且就不是给人读的。

我现在是先手写文档说明基本行为和预期，然后几轮 llm 讨论来完善和丰富文档。我对文档的要求是人类优先，简明扼要，信息密度高。

因为人能看懂的 llm 看不懂那只能是 llm 能力不行，废话连篇的那种只有 ai 读得下去的 spec 本质上和古法编程里混淆过的 js 代码一样，除了用来给 llm 复现外没有任何意义，且使得人类开发者进一步丧失掌控力。

然后再让 llm 写测试约束行为，最后用一个新对话最好再换个模型写实现并要求确保测试通过。

结合 openspec + tdd 在探索中

用起来还好，维护真的爽，认知卸载

@artiga033 你这么可以解决文档的可读性问题。多次迭代的 CR 你的考虑是怎么做呢

跨团队时候丢个 spec 文档挺省事的，不耽误两头时间，联调时候谁和文档对不齐谁去修。好久没见过正经 PRD 之类的东西了

就是不太喜欢折腾 openspec 或者 speckit ，基本 superpowers 一路点点点，最后生成个文档

昨天装了 cc 自带的 feature-dev 技能，似乎也能做到差不多的事

@rocmax 如何保证 ai 对任务内容有全面理解呢？以及如何保证实施过程中不遗忘 context 导致飞掉呢？关键是依赖 ai 生成 testsuite 也可能飞掉或覆盖不完全

@moudy spec 就是为了让 ai 全面理解任务内容，spec 后面还有 plan 和 task 两个环节，切 task 就是为了不爆 context 。superpowers 会启动多个 subagent 处理 task 。spec 中有 Acceptance Criteria （验收条件），testcase 对应 ac 条目生成。

摸索中

实际用下来觉得 TDD 比 SDD 更可落地，AI 生成的 spec 腐化太快，但 test 是死的，跑不过就是跑不过。复杂项目我的做法是先让 AI 根据需求写好 test suite ，再让另一个 session 实现，相互约束效果比维护一堆 md 文档好多了。

@teaguexiao 这也是我的担忧。文字性的东西不能执行，还是担心最后落实的跟文字对不上。实际上现在的趋势就是慢慢不看生成的代码，担心下一步可能就是不看测试代码，最后连 spec 都不看了。

会这个思路，但不是用那些库的，就自己和 ai 进行产品讨论/方案架构讨论/具体开发讨论等，和人讨论的流程差不多

个人项目使用 openspec 的 workflow （感觉治理太重了）：
1. OpenSpec 适合做 spec 基座，相当于项目开发过程的记忆层，但记忆是片面的、有时效性的，只能说明当时为何产生那样的决策。

2. 工作流从`opsx-explore`起手，多轮探索收敛需求后通过自定义命令给出`结构化 contract`并 handoff 给 opsx-ff/opsx-continue 产生工件
- 如果需求不明确，先大致描述需求方向，让 AI 出草案，多轮探索收敛需求边界、实现骨架。
- 如果需求过大，使用自定义命令切分成多个原子化需求（小步前进，加速收敛边界），避免探索认知负担过大 以及 引申而来的更多未定边界。
- 如果需求明确，把需求描述中未定边界和潜在的实现漂移点找出来，收口边界，风险点加上护栏。

3. 工件（ proposal/design/tasks/specs ）是 change-local apply 的主要执行上下文（还有 codebase ），apply 的质量锚定于 change-local 工件的质量，利用 `openspec/config.yaml` 对工件的生成形成硬约束，例如：design.md 中不应该包含具体的代码（影子代码风险），而是给出一定粒度的实现骨架（按照骨架执行减少实现漂移）

4. 如何在产生 change-local 工件时把`archived changes`（记忆层）利用起来？我的做法是按需提取 ADR （架构决策记录）形成稳定判例（就像人睡觉时 REM 期会整理压缩记忆），再通过 AGENTS.md 增加文档治理的认知路由，让 openspec 产生工件时可以参考 ADR ，避免相似的问题重复决策。

5. apply 成后，如果 review 发现问题需要在当前 change 收口，再跑 opsx-explore -> opsx-continue -> opsx-apply 进行修正。

6. review 无问题后，执行 opsx-sync 将 change-local spec 合并到 main specs 时需要筛选掉 临时护栏 或者 非业务 spec 。 （ openspec 合并 main spec 确实容易越堆越多，形成治理债务）

https://www.infoq.cn/article/C2fWkH2EgBlDPNUNlcZX
两个月过去了，OpenAI 自己都不再搞那么多 Spec 了
顶多写几条核心要点，然后多做 Plan 就行

@icyalala 我让 AI 总结了这篇文章，它的核心意思是“写完整的规范文档不再是最有价值的活动，而是用更高层次的意图表达和模型协同来实现规范的收敛。”我认为它强调的重点是：spec 的粒度可以更粗而不是 spec 的重要性下降了

感觉不如 Type driven ，我对 spec 的态度是不信任。

因为代码和项目复杂后，spec 基本上没人遵守。

@acmookey 不要把自己的脑子交给 AI 了。。。原文关于 Spec 的内容很少：

Codex 团队现在需要 spec 的地方已经非常少了
只有多人协调或者复杂决策时，才可能去写个 spec
而且即使真的写，spec 也会很短，比如 10 个要点就完了

有个更轻量的工具 cc-sdd ，不将 spec 看作唯一真相来源，而是看作模块间的契约，它的 spec 粒度比较大，但里面搞了很多审核节点。

@icyalala oai 不用 spec 是有前提的……整个项目已经处于完整的 ai 接管开发模式下，例如文档齐全，模块边界清晰，测试覆盖率达到 100%，各种静态校验检查充分，还配套一系列系统测试，监控等基础设施，这种完整情况下那当然能够不以需求为粒度维护 spec （这整个配套环境和流程太复杂了所以搞了个 harness 的概念）

当然我对 spec 的有效性是存疑的，对比裸写简单提示词虽然信息量更大了，但并没有解决根本问题

chat Driven human 免费