【开源推广】Comet: 强模型时代，我们还需要Superpowers吗？

本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

• 我的帖子已经打上 开源推广 标签： 是


• 我的开源项目完整开源，无未开源部分： 是


• 我的开源项目已链接认可 LINUX DO 社区： 是


• 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是


• 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

之前我的开源项目Comet受到了特别多用户的喜爱 ^-^，核心将Spec Coding，Skill Creator，Skill Eval连接成了闭环

Github地址 Comet: agent skill harness for turning ideas into evaluated workflows

历史L站帖子热度也还不错

Comet: 如何组合高Star Spec项目(OpenSpec+Superpowers)做出更好用的Spec Skills

但随着fable5和GPT5.6这类神话级模型的出现，我发现模型已经足够强大了，而根据社区小伙伴的反馈，大家越来越多的人开始卸载Superpowers的Skill，这个老牌Skill工程化的规则铁律开始变成了强模型时代的负担

在Comet之前的识别中我很早就分享了一个观点：如果一个Skill的执行轨迹是稳定可靠的，我们再加上Eval进行评估量化，是可以得到一个训练集的，如果模型把这部分数据加入到训练过程中，那么模型必然会学会Skill所能够做的事情

5.6发布之后，我们明显的观察到了即使在不开启Skill的情况下，5.6仍然展现出来了类似Superpowers的思维链。这也印证了我们最开始的判断 ^-^

类似思维链的产生和Skill产生了强烈的冲突，造成了加持Superpowers类的Skill的模型执行得越来越慢了，所以大家选择了卸载

我们不禁思考，什么是属于真正应该留下来的Skill

答案是：垂直类的Skill，而非通用Skill

因为越是通用的Skill也会被良好的保留下来轨迹，按照科学评测进行评估，变成可训练的数据

但模型无法知道你团队平时的工作流程是什么，你公司的文档在哪里，你的项目规范是怎么样的，这些数据敏感，但是覆盖了我们工作的方方面面。这部分内容很重要，但模型无法训练，所以真正应该沉淀的是SOP，是某些垂直业务上的流程，Skill不是没用了，而是会逐渐回到他原本该属于的位置

---------------------------------以上是当前现状下的题外话--------------------------------

就目前而言通用Skill仍然存在价值，但对于强模型，我们应该放开以往Superpowers的工程束缚，让模型进行自由的探索和实现，到底要不要用TDD，要不要用Subagent，要不要编译测试，都应该交给模型自己去思考，因为他们已经足够强大了。

将执行放开之后Skill要做的就是做一些模型无法感知的事情，比如怎么写Spec文档，验收标准是什么，怎么管理多个功能change，怎么自动推进阶段，怎么做状态机，怎么进行跨设备的断点恢复，这些外置的功能仍然需要工程化解决，但他们会变成很薄、很轻的约束

我们应该最大程度的利用模型性能

于是有了Comet Native Skill的产生，专门适配Fable5、GPT5.6级的模型，我们只进行高强度澄清，记录Spec文档，定义验收标准，用很轻的runtime维持原本经典Spec模式的外置状态

这也是Comet的0.4.0-beta.7版本，在这个版本中我们剔除了所有外部依赖的Skill

用200行的Skill完成了以往Comet需要5个Skill才能完成的工作

核心数据如下：

我们在保持任务完成率的情况下，在Eval的Benchmark中实测砍掉了75%的token消耗量和47%的时间消耗

详细报告可见Comet Native 与 0.4.0 Classic 真实评估 - Comet Docs

可以说在评估测试上非常乐观，极大的克服了之前版本在强模型上过于工程化导致的慢速问题，现在Comet Native Skill已成为了我的日常工作Skill~

欢迎各位佬一起交流，使用Comet Native Skill开发自己的项目~ ^-^