superpower openspec 和 matta grill

superpowers 应该可以指定流程不强制的，agent-skills 轻量点 token 可能少点，我研究了好几个开源的 sdd

自己精简下 superpowers ，主要是把 brainstorming 后面那段写文档、走 subagent 之类的全干掉。

@shm7 你现在用的什么开源 sdd

这些都是花架子，也就提供一点情绪价值，然后疯狂烧 token 。

最佳实践就是根据项目写好 CLAUDE.md 或 AGENTS.md ，然后将流程性的内容提炼成 Skill 。

试试 bmad method ，然后写一个你的感受，发出来

@zhanggang807 哥们这是再给我提示词嘛

只用过 superpowers 上周刚卸载了，除了疯狂烧 token ，没有任何用
上周一个小的不能再小的需求，洋洋洒洒花了一个半小时，写了 60 多个文档，改了 300 行代码，花了一个完整的 20x 5 小时额度，关键是代码还有 bug
卸载后直接 5.6 sol 5 分钟改完

@deplives 小需求我都是直接 plan 模式做，有些大需求，我自己也考虑不周到，感觉需要个 sdd skill 辅助一下

@yujianfei #8 大的需求也不需要，先整体说诉求，然后脑暴细节，讨论完让他整理一下要做的事情，然后 plan 执行计划，比 superpower 这种效率高不知道多少

openspec 没用过就不评价了。

主要区别：

1. matta grill 比 superpowers 的 brainstorming 会更详细一些，但也容易走偏问一大堆很极限的边界问题，稍微大点的项目问你 上百道问题不在话下。

2. superpowers 的 write-plan 比 matta 的 issue 详细，matta 的 issue 更多是语义化的实现方案和验收标准，对模型的自由度比较大

3. matta 的其他 skill ，例如 handoff 、teach 用起来很顺手。


我的个人结论是：
1. 如果你是 GPT Plus + 其他模型（例如 GLM ），那么 superpowers 其实更有优势。因为 superpowers 的实施计划非常的详细和机械，你可以在 Codex 中 使用 matta 或者 sp 完成方案和实施计划后，在 Claude Code 或者 opencode 使用 GLM 单独使用子代理来实现代码，基本没什么大问题。
2. 如果你是 GPT Pro 的话，用什么都无所谓，额度够。
3. superpowers 消耗 Token 的其中一个问题就是无论什么问题，他都会使用 brainstorming 或者其他技能，自主调用频率非常高。我建议在全局 AGENTS.md 限制 sp 的自动调用

```
## Superpowers 硬性禁用规则

默认禁止主动调用任何 `superpowers:*` Skill ，除非用户显式触发，或当前已经在 Superpowers 流程中。
```

4. 我自己有写一篇专门针对 superpower +codex 的额度优化，但此方案暂时在 GPT5.6 中不适用，因为 5.6 的子 agent 的模型指定有 bug ，会自动继承主代理模型，所以额度消耗会很高，我自己也提了 issue 等待官方支持。

博客文章（目前默认是隐藏，等官方修复后展示）： https://blog.1874.cool/codex-superpowers

一直用 openspec 很好用，有时候会结合 superpower 使用。 openspec 当前我认为是最好的。

公司一般都会使用 openspec speckit 这种

今年初的时候直接从 openspec （那时候还不是 skill ），做了一套自己的 skill 出来，根据自己的开发流程调整，现在基本和 openspec 也没什么关系了。
我觉得用别人的只是过度，最终还是得根据自己的需求和流程做自己的 flow

以现在最新的模型的智力 gpt5.6 sol max, fable max 这些 sdd 的 skill 都是鸡肋了吧。除了浪费 token 基本没啥用了，之前还用现在基本都不用了。还容易左右脑互博。自己归档项目级别的 md 就好了 到一个阶段让 ai 自己总结就行

@maolon 确实，使用社区比较火的 SDD SKILL 的其中一个目的就是沉淀一套自己的 SDD SKILL 。

毕竟社区的经验是可以借用的，社区的 这些 SKILl 对于新手和老手都有一定的参考意义，可以使用和踩坑，才知道自己最合适什么，借鉴好用的然后沉淀为自己专属的 SDD skill 我觉得很不错

@calvinHxx 确认，不光烧 token 还贼慢，模型自己的能力已经很强了

@1874w matta grill 这个深有同感，issue 确实详细，也更能理解我的需求，但是就是有很多一大堆很极限的边界问题，导致最后很难收敛，不过我觉得这也无可厚非确认也需要考虑，只是优先级而已

我个人目前还是更倾向于 grill 这一套

grill 我觉得在所难免，尤其是 codex ，经常容易写一大堆我不想要的东西。5.5 和 5.6 都一样，不在于做不出来我想要的东西，而是做太多我不想要的东西。所以可能拷问确实痛苦，但是这是必要的，明确好边界，比什么都重要。

@Bluecoda grill 我深度体验了之后，感觉是这个边界最难掌控，我这种 allow 工程师，很多都领域完全不知道

superpowers:6.1.1 版本比之前的 5.+ 的好用很多，简化了很多，速度整体上也提升了挺多（但是总体上还是非常久）。matt：今天用下来的感觉是一般，虽然问了很多问题，但是整个项目的文档组织比较分散，问的问题很烦，因为实际上自己也没有想清楚。openspec:去年年底的时候用过，那时候模型能力还不够强，帮助挺大，现在直接用内置：feature-dev 基本上就完成了

@yujianfei 我想有些边界你自己都不清楚，那就很难办了。不如你让 AI 帮你决定好了，就像不做 grilling 一样，但是 AI 会帮你胡乱扩展边界，后果自己承担就好，无论哪个模型，不确定好边界都会这样。

@yujianfei 我之前用 codex 做个新功能，蛮大的模块，大概 2w 行 py 代码打底。那时候还不知道 grilling ，就开始做，5.5 会自己扯犊子，做一大堆根本不符合我要求的代码，然而功能确实可以工作，改得我焦头烂额，工期还赶。
现在用了 grilling ，做大功能的时候，确定死边界，大方向上不会有任何问题，不过小方向细节的地方还是得修一修。

一直在用 WAZA Skill ，感觉很轻，差不多都能满足

我之前用了 superpower openspec 结合的工具 comet 但是现在觉得都太臃肿了 想要把这些都拆掉 感觉 gpt 早晚（甚至已经）内化掉这些功能

之前一直使用 openspec ，后面发现用 claude 自带的 plan 挺好的，讨论完需求，写好文档，让 ai 自己仔细审核文档 2 遍，看看哪里有分歧或者写错误的地方，就很好使了。

自己在 CLAUDE.MD 里面写好写文档的要求就行了。

@Sundayz 如果是环境固定,项目类型单一可以自己总结经验写 md, 甚至开发出自己的 skills, 但是对于跨 4,5 种语言, 混合各种项目, 整合不同运行环境, md 写不过来. 所以,讨论的前提不同,都是对的.

@yujianfei 没尝试过组合使用吗? LLM 端并无状态记忆, 本质上各种工具就是一起完成一篇大作文而已

@deplives #7 这恐怕不是 superpowers 的问题吧，20X 的额度也能烧完，可能上下文有问题。
5x 的额度 改 1100+代码都不超过 50%

@jinsongzhaocn 你说的应用场景并不复杂，现在的大模型已经很强了，对于稍微复杂一点的应用，重 SSD 纯属增加负担，增加 token 成本，说白了就是给领导看的、写 ppt 汇报的情绪价值产物。

@zhanggang807 这个不行，我有一个项目用的这个，到最后全烂了，不如 gsd

我现在在实践通过这几个文档来和 AGENT 协作，感觉还可以，对项目的掌控度可控很多了：
- 我们要干啥 VISION （随时对齐）
- 要做成什么样的 SPEC （只讲 WHAT 不讲 HOW ）
- 所有中间的决策取舍 REASONS
- 当前的状态 NOW
- 源码和 git log 反应了怎么做的

目前在用 trellis ，可以看看

我全部删光了，自己用 obsidian 文档控制流程，依赖模型自己能力。
只定制了极少需要特定输出格式的以及 SOP 的 skill

@zhanggang807 #5 给 agent 做拟人化角色提示词已经是错误做法，反而限制了 llm 的发挥

@Goalonez #32 这个每次都带一大堆上下文，组件更新也不方便

感觉没有用，现在模型的能力已经很强了，不需要这种浪费 token 的上下文来约束