① 赌骰子的日子

我做量化的，Claude Code 用了快一年了。

坦白说，这一年的体验挺分裂的。有时候打开一个新 session，随手说"帮我给情绪融合模块加个自适应权重"，它噼里啪啦写出来一版，优雅、有测试、甚至考虑了边界条件，我看完觉得这玩意儿比我强。

然后第二天，另一个 session，同一类任务，它给我扔出来一坨没有测试、命名混乱、跟已有代码风格完全不搭的代码。气到我不得不从头改。

就像在赌骰子。

同一个工具，同一个我，产出质量的方差大得离谱。我以为是 prompt 的问题，花了不少时间研究怎么写更好的 prompt，改善了一点，但方差还是在。后来以为是模型的问题，换了好几个版本测试，结论是模型不是根本原因。慢慢意识到问题不在 AI，在工作流——我根本没有可复用的、结构化的 AI 协作方法论，每次都是临时发挥，当然每次质量都不一样。

这就像雇了一个高智商的实习生，给他布置任务全靠临时口头说，没有标准化的工作流、没有验收标准、没有复盘机制。实习生再聪明，产出质量也靠运气。

这两天翻 GitHub，发现了 Superpowers 这个项目。Jesse Vincent 搞的，一套专门给 AI 编程代理用的可组合技能框架，支持 Claude Code、Cursor、Gemini CLI 等一条龙。

我读完 README 之后沉默了一下。

然后意识到——哦，原来有人早就把这件事想清楚了，系统化了，而且开源了。我自己在那摸索了一年。

考虑到国内用户订阅claude确实比较困难，建议选择一个靠谱的网站：claudemax.shop

② 结论先行

强推。9 / 10 分。

Superpowers 不是一个工具，是一套方法论。它把"让 AI 写代码"这件事拆成了七个有序步骤，用可组合的 Skill（技能）文件来锁定每一步的行为。装上之后，Claude Code 从一个时而天才时而翻车的随机生成器，变成了一个执行方式可预期、可追溯、可复用的系统。

对量化开发来说，这个差距是质的。策略代码不容许随机——你需要的是每次都有测试覆盖、每次都有明确设计再开始写、每次遇到 bug 都走系统性排查流程，而不是靠运气。

扣掉的 1 分，后面说。

③ 怎么装

Claude Code 插件市场里可以直接搜到，一行命令：

claude mcp add superpowers

或者 CLI 手动安装：

npx -y @smithery/cli install @obra/superpowers --client claude

装完之后，它会把一套 Skill 文件注入到你的 Claude Code 工作区。下次启动 Claude Code，输入 /brainstorming 或者 /tdd 之类的斜杠命令，对应的 Skill 就会激活，AI 的行为就被这个 Skill 的指令约束住了。

Cursor 和 Gemini CLI 的安装方式官方文档里都有，几分钟的事。

不需要 API key，不需要额外的服务，纯本地运行。这是我喜欢它的原因之一——它不依赖任何云服务，数据不出你的机器。量化场景下策略逻辑是敏感资产，本地运行这一点对很多人来说是硬需求，不是加分项。

④ 核心功能实测：量化场景下验了什么

4.1 Brainstorming Skill：把"想法乱炖"变成结构化设计

这是我用得最多的一个 Skill，在量化策略设计上帮了我很大的忙。

以前我给 Claude Code 出一个需求，通常就是直接说"帮我做 XX"。它收到之后就开始写，不问为什么，不确认边界，不探讨替代方案。写完的东西往往在技术上能跑，但跟我心里想的有 30% 的偏差，而这 30% 的偏差往往需要事后大改。

Brainstorming Skill 激活之后，行为完全变了。

我说"我想给情绪因子加一个市场状态识别模块，在高波动率环境下自动切换参数"，它没有立刻开始写代码，而是先问了我四个问题：

• 你用什么指标判断"高波动率"？VIX 分位数还是历史波动率？
• 参数切换是离散的（两套参数互切）还是连续的（插值过渡）？
• 切换触发频率要控制吗？避免在震荡行情里反复切换？
• 这个模块跟现有的 VIX 宏观锚有没有概念重叠，要合并还是并行？

好家伙。这四个问题，前三个我没想过，第四个我想了但没想清楚。

然后它把我们的讨论结果整理成了一份设计 Summary，要我逐条确认，有争议的地方继续讨论，没争议的锁死。确认完了，再开始拆任务。

整个过程大概花了 20 分钟。

最终写出来的代码，我事后只改了两行——一个变量名和一个边界条件的判断方向。比以前那种"先让它写，写完发现不对再大改"省了大概一个半小时。

量化策略的每一次重构，成本不只是时间。每次改了信号层的逻辑，回测结果就要全部重跑，参数也得重新验证。减少一轮重构，省的是好几天的反复确认。Brainstorming Skill 的价值，在量化场景下被放大了。

4.2 TDD Skill：RED-GREEN-REFACTOR，不是说说而已

这个 Skill 是整个框架里最硬核的一个，也是最让我惊喜的。

说白了就是强制 AI 按测试驱动开发的节奏走——先写失败的测试（RED），再写最小实现让测试通过（GREEN），再重构（REFACTOR）。

听起来是常识，但大多数时候你让 AI "写带测试的代码"，它给你的是先写实现、再补测试，测试和实现是同一个人写的，测试自然全绿，但质量等于零。

TDD Skill 不允许这样。它的指令强制把三个阶段分开执行，每个阶段结束都要验证状态。

我拿情绪分析模块的 compute_weighted_score() 函数试了一下。

激活 TDD Skill 之后，它的工作流是这样的：

RED 阶段——先让我确认函数签名和边界条件，然后它写出 8 个测试用例（包括空输入、权重和不为1、负值情绪分等边界），运行之后全部失败。这一步很重要，因为失败的测试才是有效的测试，证明测试在检测真实行为而不是在配合实现走形式。

GREEN 阶段——写最小化的实现，只让这 8 个测试通过，不做任何"提前优化"。代码丑不要紧，先绿再说。

REFACTOR 阶段——在测试全绿的保护下，重构代码，改命名、提取辅助函数、加类型注解，每次重构后重跑测试确认没有回退。

对量化代码来说，这套流程的价值是双倍的。量化策略里有太多数值计算，差一个符号、差一个边界条件，回测结果就差了十万八千里。强制走 TDD，边界条件在测试里写死，比你自己 review 代码可靠多了。

而且有一个隐性好处我用了才发现：TDD 逼着你在写实现之前想清楚函数的语义。

以前我会边写边想，写到一半发现函数的输入类型不对，或者返回值的含义模糊，只能推倒重来。TDD 的写测试阶段，你必须先把函数签名、输入范围、异常情况全部想清楚，写进测试用例里。这个"先想清楚再动手"的节奏，对量化代码来说非常对——信号的定义必须在实现前精确，模糊的信号定义是回测结果不稳定的根源。

看到这里你可能觉得"就这？TDD 我早会了"。

也许。但我问你：你让 Claude Code 写代码的时候，它走的是不是真 TDD？还是先写实现、再补测试、测试全绿、皆大欢喜？

Superpowers 的 TDD Skill 解决的就是这个——让 AI 真的走 TDD，而不是走 TDD 的形状。

4.3 Subagent Dispatch：一个主 Agent 指挥一群干活的

这个功能我觉得是 Superpowers 最具前瞻性的设计，没有之一。

说白了就是并行 Agent——主 Agent 把一个大任务拆成多个独立子任务，分别 dispatch 给不同的子 Agent 执行，子 Agent 完成后把结果汇报给主 Agent 整合。

翻译成量化开发场景：

我要做一个新策略的完整开发，包括数据层、信号层、仓位管理层、回测框架接入，这四块是独立的，完全可以并行开发。

以前我只能串行——一块一块跑，每块都要一个新 session，手动管理依赖关系，进度无法并行。

Subagent Dispatch 激活之后，主 Agent 会先做任务分析，确认哪些块可以并行、哪些有依赖需要串行，然后自动 dispatch 多个子 Agent 分头执行。

实测下来，四层架构的开发时间从我以前需要两三天，压缩到大概半天——主要是消除了等待时间和上下文切换成本。

要说这块的门槛：子 Agent 之间的依赖关系需要你在规划时说清楚，不然主 Agent 并行了本来应该串行的任务，会出错。这是使用者的责任，不是工具的问题——但确实需要你有一定的系统设计意识。

有个实操细节值得说：并行子 Agent 的接口契约要在 Writing-Plans 阶段锁定。

就是说，数据层 Agent 和信号层 Agent 并行跑的时候，信号层需要知道数据层会返回什么格式的 DataFrame——列名、数据类型、索引格式、缺失值处理方式。这些东西如果没写清楚，两个 Agent 各自写完，接口接不上，又得返工。

Superpowers 的解法是在任务分解时，主 Agent 明确输出每对子 Agent 之间的接口契约文档，双方都看这份契约来实现。这个机制本质上就是软件工程里的"契约设计"，只不过现在是 AI 在执行。

思路对了，执行起来就顺。

4.4 Writing-Plans + Executing-Plans：把大需求变成可执行的精确任务

这两个 Skill 通常配合用，是 Superpowers 工作流的核心节奏。

Writing-Plans 做的是把一个模糊需求拆成 2-5 分钟可完成的精确任务清单。注意是每个任务 2-5 分钟，粒度极细——不是"实现情绪融合模块"，而是"实现 merge_signals(vader_score, vix_anchor, weights) 函数，接受 float 输入，返回加权平均值，边界条件：weights 为空时 raise ValueError，weights 之和不为 1 时 raise ValueError"。这种粒度，你一看任务描述就知道该写什么测试。

Executing-Plans 负责一个任务一个任务地执行这个清单，每个任务完成后有明确的验收标准（通常是对应的测试通过），通过才进下一个。

这两个 Skill 组合之后，Claude Code 变成了一个项目经理 + 执行者的双角色——它会先跟你对齐目标，把计划拆细到不可歧义的程度，然后按部就班地做完。

翻车率比以前低了很多。原来那种"做了一半发现理解错需求了只能重来"的情况，在 Writing-Plans 阶段就能提前暴露。

还有一个我意外发现的好处：任务清单本身就是一份进度文档。

Executing-Plans 执行过程中，每完成一个任务，它会在清单里标记完成状态。我开一个新 session 的时候直接把这个清单粘贴进去，Claude Code 就知道做到哪了、下一步是什么，不需要重新解释项目背景。这跟 agentmemory 的记忆功能形成了互补——一个管"历史决策"，一个管"当前进度"。

两个工具叠起来用，效果比单独用任何一个都好。

⑤ 诚实说缺点

说完优点，该说让我不舒服的地方了。

缺点一：有学习曲线，不是插上就能用。

Superpowers 的每个 Skill 都有明确的使用规范和激活时机——你需要知道什么时候用 Brainstorming、什么时候用 TDD、什么时候 dispatch 子 Agent。文档是有的，英文的，还有社区翻译的中文版（就是你看到截图里的那个"超级大国"）。但你需要真的读完，理解这套方法论的逻辑，再用到实际项目里。

这不是一键魔法，是一套方法论，需要你主动内化。我估计需要一到两周才能把七个 Skill 都用顺。

缺点二：TDD Skill 对纯探索性工作不友好。

量化策略开发有时候不是"实现一个明确定义的功能"，而是"我也不知道这个信号有没有 alpha，先跑跑看"。这种探索性的脏活，强制走 RED-GREEN-REFACTOR 会让你很难受——你不知道该写什么测试，因为你连目标都没定义清楚。

这时候需要手动跳过 TDD，直接写原型，探索完了再补测试。Superpowers 是工具，不是规矩，你有权不用某个 Skill。但如果你习惯了所有任务都走 TDD，遇到探索性场景会有摩擦感。

缺点三：子 Agent 协调目前还有点不稳定。

Subagent Dispatch 在复杂任务上偶尔会出现子 Agent 之间的上下文同步问题——一个子 Agent 做了一个设计决策，另一个子 Agent 不知道，两边写出来的东西接不上。

这个问题跟 agentmemory 的跨 Agent 记忆共享是同一个维度的挑战，目前的解法是在 Planning 阶段把接口契约写得非常详细。有用，但增加了准备工作的成本。这块随着工具链的成熟会改善，现阶段需要使用者多花心思在前期规划上。

⑥ 对量化 AI 程序员意味着什么

Superpowers 这套框架解决的根本问题，不是"让 AI 更聪明"，而是"让 AI 更可靠"。

这个区别对量化开发者来说特别重要。

量化策略的开发，可靠性比聪明更值钱。一个偶尔天才、偶尔翻车的 AI 协作方式，在策略研发里的风险是不对称的——天才那次多赚了 10%，翻车那次可能直接引入了一个 bug 到回测里，让你相信了一个不存在的 alpha，然后真金白银地下注。

Superpowers 把 AI 的行为框在一个可预期的流程里，每个步骤都有明确的 输入-输出-验收标准。不是因为 AI 不够聪明，而是因为可预期的系统比随机的天才更值得依赖。

三个对量化场景特别有价值的用法：

策略代码开发：Brainstorming 做设计对齐 → Writing-Plans 拆任务 → TDD 逐个实现 → Code Review 验收。这条流水线跑通之后，你的策略代码质量会稳定在一个高线上，而不是随机波动。

因子研究的代码化：把因子逻辑从 Jupyter Notebook 搬到生产代码时，TDD Skill 能帮你把隐含的假设都显式地写进测试。这是从研究代码到生产代码最容易出错的一步。研究阶段的代码往往充满了"我知道这里有个边界条件但懒得处理"的临时假设，TDD 会逼着你把这些假设全部显式化，要么处理，要么在测试里标注 skip 并说明原因。

多模块并行开发：数据层、信号层、风控层可以用 Subagent Dispatch 并行，主 Agent 管理接口契约，把原本串行的开发时间大幅压缩。这个对多人协作团队也有价值——AI Subagent 的接口契约文档，可以直接作为人工代码 review 的参考。

还有一点：Superpowers 是方法论层面的框架，跟 agentmemory（记忆层）、Claude Code（执行层）不冲突，可以同时跑。实际上三层叠加——记忆保持上下文连贯、Superpowers 保持工作流可靠、Claude Code 做具体执行——是我现在的标准工作方式。

⑦ 不同阶段怎么用

刚开始用 Claude Code 不久的：先把 Superpowers 的文档从头到尾读一遍，不要急着用。把七个工作步骤的逻辑搞清楚了，再从 Brainstorming + TDD 这两个最基础的 Skill 开始用，其他的逐步叠加。别想着一下子全部用上，那会让你觉得这东西很复杂。

已经是 Claude Code 重度用户，但产出质量时好时坏的：这个框架直接解决你的问题。从你最痛的那个环节切入——如果是需求对不齐，先用 Brainstorming；如果是代码质量不稳定，先用 TDD；如果是大任务效率低，先用 Subagent Dispatch。不要一开始就把七个 Skill 全部激活，会把自己弄乱。

在做量化或金融 AI 应用，团队开发的：把 Writing-Plans 的产出（任务清单）变成团队的交接文档。AI 写的精确任务描述，人读起来也是清晰的。这样 AI 协作和人工 review 能接得上，不会形成信息孤岛。而且任务清单天然就是 PR 描述的素材，写 PR 的时候不用再从头想。

单兵量化开发者（比如我）：从 Brainstorming + TDD 这两个 Skill 开始，把策略设计和代码实现的质量先稳住，再逐步引入 Subagent Dispatch 来提速。稳了再快，快了再扩。

老实话：Superpowers 是一套需要你投入时间理解的框架。如果你只是偶尔用 Claude Code 写写脚本，安装它可能比不安装更麻烦。它的价值在高频、复杂、长期的项目上才能充分显现。低频用户拉倒，真的用不上。

⑧ 收尾

工具够强不够，还得有配套的方法论。

Claude Code 本来就很强。Superpowers 做的事，是把"强"变成"稳"——从概率上的优秀，变成系统上的可靠。我以前形容它是"随机的天才"，装了 Superpowers 之后，它变成了一个有纪律的工程师。天才偶尔很爽，但你不会把有纪律的工程师换掉。

对做量化的人来说，稳比强重要得多。策略回测结果告诉你的是期望，但落地执行靠的是方差。AI 协作的方差，Superpowers 帮你管。

如果你也在用 Claude Code 做量化策略、金融 AI 应用，或者只是被产出质量的随机性烦过，推荐认真看一下这个项目。上手需要时间，但值得。

评论区聊。做量化的朋友，我们都懂赌骰子的感觉——现在可以不用赌了。