全局 AGENTS 路由协议，让 Superpowers 与 gstack 明确分工，避免双重自动触发、重复接管流程、或相互覆盖默认控制权。

在 AI 编程和自动化工作流越来越复杂之后，很多人会遇到一个很烦的问题：

不是工具不够强，而是工具太多了，开始互相抢活。

一个负责规划，一个负责执行，一个擅长浏览器操作，一个擅长调试排障。单看都很好，但一旦没有边界，结果往往是：

• 两套流程同时自动触发
• 都想接管当前任务
• 一个刚开始拆计划，另一个已经准备接管验证
• 默认控制权来回覆盖
• 最终用户反而要花精力“协调工具”

这不是“智能”，这是内耗。

所以，我专门写了一份全局 AGENTS 路由协议，核心目标只有一个：

让 Superpowers 和 gstack 明确分工，不抢主控，不重复接管，不互相覆盖。

这篇文章，就把这套协议的设计思路讲清楚。

一、先解决最根本的问题：谁说了算？

任何多 Agent、多 Skill、多插件协作系统，如果不先定义优先级，后面所有分工都会失效。

我给这套协议定的最高优先级顺序是：

1. 用户当前回合的明确指令
2. 当前项目目录下的 AGENTS.md
3. 全局 AGENTS.md
4. 插件或 skill 自带的默认说明

这背后的原则非常简单：

1. 用户明确点名，直接服从

如果用户明确说：

• 用 Superpowers
• 用 gstack
• 用某个指定 skill
• 用某个命令或工作流

那就直接执行，不要搞“智能二次分流”。

因为用户已经完成了路由决策，系统不应该再抢方向盘。

2. 项目规则高于全局规则

不同项目有不同的工程背景、文档结构、执行约束。

所以如果项目内已经有自己的 AGENTS.md，那项目规则优先，全局规则只能退到辅助地位。

3. 全局协议只做“边界管理”

这份全局协议的职责不是替代所有工作流，而是解决：

• 谁是主流程
• 谁是补充能力
• 什么情况下切换
• 什么情况下不能双开

也就是说，它只做路由裁判，不做一切事务的总控制器。

二、核心分工：Superpowers 管通用研发，gstack 管专项工程能力

这套协议最重要的设计，就是给两个能力框架明确定位。

Superpowers 是什么？

我把 Superpowers 定义成默认的通用研发流程框架。

它适合接管的任务包括：

• 需求澄清
• 方案讨论
• 写 spec
• 写 implementation plan
• TDD
• 系统化调试
• 子代理协作开发
• 开发分支收尾

也就是说，只要任务属于“怎么做、怎么拆、怎么改、怎么查”这一类，默认就归 Superpowers。

典型触发意图

比如这些表达，天然应该走 Superpowers：

• 帮我规划这个功能
• 先写方案
• 给我一个实施计划
• 按 TDD 做
• 系统化排查这个 bug
• 把这件事拆给多个 agent 做
• 收尾这个开发分支

更细的 skill 路由

为了让路由更清晰，我又把 Superpowers 内部再细分成几类典型工作模式：

• superpowers:brainstorming
  适用于需求模糊、方向未定、先要澄清目标

• superpowers:writing-plans
  适用于方案已定，需要拆文件落点、实现步骤、验证方式

• superpowers:systematic-debugging
  适用于 bug 排查、结果不对、状态漂移、偶发问题

• superpowers:test-driven-development
  适用于新增功能、逻辑重写、先补测试再改代码

• superpowers:verification-before-completion
  适用于准备收尾前，做完整验证和风险回归

• superpowers:subagent-driven-development
  适用于任务很大、可拆分、适合多个 agent 并行推进

所以，Superpowers 的本质不是“某个技能”，而是一个通用研发主流程容器。

gstack 是什么？

我把 gstack 定义为专项能力框架，不是默认总控。

它只负责那些明显偏“验证、运行态、页面、上线、巡检”的任务，比如：

• 浏览器联调和真实页面操作
• 端到端 QA
• 上线前后验证
• benchmark / 性能回归
• canary / 发布后巡检
• security / CSO 审计
• 设计评审与视觉 QA
• ship / deploy / PR 流程
• checkpoint / resume
• 文档发版收尾

典型触发意图

比如这些请求，更适合 gstack：

• 打开网页看看
• 测一下这个流程
• 做 QA
• 做 benchmark
• 做 canary
• 做安全检查
• 发版
• deploy
• 提 PR
• 保存进度
• 恢复上下文

换句话说：

Superpowers 负责“研发主流程”，gstack 负责“专项工程动作”。

三、为什么一定要防止“双主流程”？

很多 AI 工作流系统的最大问题，不是能力不够，而是：

两个框架都觉得自己有资格接管。

这会直接导致三类问题：

1. 重复启动

一个准备写计划，一个准备开 QA，一个要先补测试，一个又要先巡检。

结果是，同一轮任务里两个框架同时起手。

2. 默认控制权冲突

用户没明确指定时，双方都试图当“默认入口”，最后谁都不服谁。

3. 用户心智被打散

用户本来只想解决问题，结果还得理解：

• 为什么这次是它先接管？
• 为什么另一个突然插进来？
• 为什么流程被改造成了审批链？

所以这份协议里有一条非常关键的硬规则：

默认一回合只允许一个“主流程框架”接管当前任务。

具体规则是：

1. 用户明确指定 Superpowers，就直接用 Superpowers
2. 用户明确指定 gstack，就直接用 gstack
3. 请求明显属于 gstack 的专项能力时，优先 gstack
4. 其他一般开发任务，默认 Superpowers
5. 如果 gstack 已经接管，就不要再隐式触发 Superpowers 当第二主流程
6. 如果 Superpowers 已经接管，就不要再隐式触发 gstack 当第二主流程
7. 只有主流程明确需要专项能力时，另一方才能作为补充能力出现

这一条是整份协议最关键的稳定器。

四、补充调用可以有，但不能“反向劫持”

很多人一听“一回合只允许一个主框架”，会担心：

那岂不是太死板？

其实不是。

我限制的是双主控，不是限制协作。

比如下面这种组合是允许的：

• Superpowers 负责规划与实现，最后调用 gstack 做浏览器 QA
• Superpowers 负责系统化调试，最后调用 gstack 做上线后巡检
• gstack 负责 canary 和页面验证，但不反过来接管实现计划和 TDD

这里的关键不是“能不能调另一个”，而是：

谁是主流程，谁是补充能力，必须清楚。

不能出现这种情况：

• 本来是实现任务，结果 gstack 先把节奏带走
• 本来是 QA 任务，结果 Superpowers 又硬插进来重做一遍计划
• 一个只是辅助调用，最后却反向劫持了整个任务控制权

所以我把边界写得很明确：

主流程可以按需调用另一侧能力，但补充能力不能反向升级成新的主流程。

五、量化任务为什么要单独立规矩？

量化、交易、回测、执行链路类任务，跟普通研发任务不一样。

因为这一类任务最容易出现一种假象：

“图上看起来对，但实际上不可交易。”

所以在协议里，我专门给量化任务单独加了一层硬规则。

1. 策略设计与信号定义，默认走 Superpowers

适用范围：

• 定义买卖条件
• 把主观交易想法翻译成规则
• 指标、因子、信号组合设计
• 策略模块结构设计

默认审查视角：

• William
• Charlotte
• 复杂实现时补 Benjamin

2. 回测与统计评估，默认走 Superpowers

适用范围：

• 回测框架开发
• 样本切分
• 指标统计
• 参数敏感性分析
• 稳健性与过拟合检查

默认审查视角：

• Charlotte
• William
• 涉及实现正确性时补 Benjamin

3. 数据清洗与特征构造，默认走 Superpowers

适用范围：

• K 线、tick、订单簿清洗
• 缺失值、脏数据、重复数据处理
• 特征工程
• 数据对齐与时间戳修复

默认审查视角：

• Benjamin
• Charlotte
• 涉及批处理性能时补 Henry

4. 实盘执行与交易链路，主流程还是 Superpowers

但如果任务目标变成：

• 验证线上链路
• 发布后检查
• 浏览器后台操作
• 运行态巡检

那就允许补 gstack。

默认审查视角：

• William
• Lucas
• Henry
• 架构复杂时补 Noah

5. 发布验证与运行监控，默认走 gstack

这部分包括：

• 上线前检查
• 发布后巡检
• benchmark
• canary
• 真实页面或控制台验证
• 安全检查

默认审查视角：

• Henry
• Lucas
• 安全相关补 Harper

六、缠论任务最容易踩坑，所以必须先尊重“项目定义”

缠论是量化场景里最容易“同名不同义”的领域。

因为很多概念听起来一样，但在不同项目里口径可能完全不同，比如：

• 分型
• 笔
• 段
• 中枢
• 背驰
• 一二三类买卖点
• 同级别分解
• 多级别联立
• 走势类型

如果不先看项目定义，直接套一个通用缠论解释，基本一定会出事。

所以我在协议里加了一个非常硬的原则：

缠论相关任务，项目自定义定义优先于任何通用解释。

定义发现顺序

必须按顺序找：

1. 项目级 AGENTS.md
2. 项目策略定义文件，比如 docs/chanlun-spec.md
3. README、架构文档、策略说明文档
4. 如果文档还不够，再从代码实现反推当前有效定义

不能一上来就拿通用缠论知识硬套。

如果只能从代码反推

那也必须明确区分三件事：

• 文档里明确写死的规则
• 代码里当前实际实现的现状
• 基于代码行为推断出的临时结论

而且必须写明：

这是根据当前实现反推出的定义，不等于最终策略文档。

这一步非常重要，因为很多策略系统都是：

• 文档过时
• 代码先跑起来了
• 真正生效的是代码，不是文档

如果这时还装作“定义已经统一”，就会把后续回测、执行、解释全部带偏。

七、缠论量化最怕“主观化”，所以必须先量化结构定义

协议里我给缠论加了几条强制校验项，本质上就是一句话：

所有结构定义都必须能落到代码。

比如：

结构定义必须先量化

所有分型、笔、段、中枢定义必须明确：

• 包含关系怎么处理
• 未完成 K 线是否参与判定
• 实时结构与回看结构是否一致

不能接受这种表述：

• 看起来像
• 感觉结构成立了
• 这里应该算一个中枢

这种说法适合聊天，不适合量化系统。

多级别联立必须说明对齐方式

必须明确：

• 各级别 K 线如何同步
• 低级别信号怎么映射到高级别结构
• 触发时点来自哪个级别
• 在哪根 bar 上确认

不能默认认为多级别天然同步。

背驰必须说明量化口径

必须明确到底依据什么判断背驰，比如：

• MACD 柱面积
• 黄白线斜率
• 波动率归一化后的力度比较
• 成交量或成交额辅助确认

不能只说一句：

“这里明显背驰。”

因为“明显”本身不能回测，也不能复现。

买卖点必须检查交易可执行性

必须区分：

• 图形成立时点
• 真实可下单时点

还必须把：

• 手续费
• 滑点
• 延迟
• 分型确认滞后

都纳入评估。

否则就会出现一种假策略：

图上每一笔都很漂亮，实盘根本打不出来。

回测与实盘一致性必须单独说明

必须检查：

• 是否区分事后标注结构与实时可得结构
• 是否存在重绘
• 信号确认延迟有多大
• 中枢扩展或结构破坏后，原信号如何失效

如果这几点不说清楚，很多“高胜率策略”都只是回看幻觉。

八、量化任务必须有一套统一的强制校验项

除了缠论专项规则外，我又给所有量化任务统一加了几条硬规则。

策略设计

必须说明：

• 信号依赖的数据粒度
• 触发时点
• 是否会重绘
• 手续费、滑点、延迟是否入模
• 哪些前提还没有验证

回测与评估

必须说明：

• 样本区间
• 交易品种
• 周期
• 数据来源
• 是否区分 in-sample / out-of-sample
• 资金曲线计算方式

默认不能只报收益率，还要同时给：

• 最大回撤
• 胜率
• 盈亏比
• 交易次数
• 成本后结果

如果样本太少、明显过拟合、统计失真，必须直接指出。

数据处理

必须说明：

• 缺失值
• 重复值
• 脏数据
• 时区
• 复权
• 时间对齐

不能默认假设数据天然干净。

实盘执行

必须检查：

• 幂等
• 重试
• 断连恢复
• 订单状态一致性

并明确区分：

• 信号生成成功
• 订单实际成交成功

涉及真实资金时，默认按高风险任务处理。

风控

必须明确：

• 触发条件
• 执行动作
• 恢复条件
• 极端行情处理路径
• 拒单、断网、异常状态的恢复方案

任何自动补单、自动重试、自动加仓逻辑，都必须高风险审查。

结论输出

任何量化结论都要分成三部分：

• 已验证事实
• 依赖假设
• 仍需验证的风险

证据不够时，不能把策略直接说成“可用”或“稳健”。

九、这套协议其实不是在“加规则”，而是在减少混乱

很多人看到这种协议，会觉得：

这是不是又加了一堆限制？

但我真正想解决的，不是把系统变复杂，而是把复杂性从运行时前移到规则层。

也就是说：

• 不要等两个框架打起来，再临场协调
• 不要等量化结论出错，再追问定义到底是什么
• 不要等上线前才发现执行链路和验证链路混在一起
• 不要等策略回测很好看，才发现信号其实不可交易

这套协议的价值，不在于“写得很全”，而在于它解决了三个高频失控点：

1. 解决主控冲突

谁负责规划，谁负责专项动作，先定清楚。

2. 解决领域定义漂移

尤其是缠论、交易、执行链路这类高歧义任务，必须先对齐项目口径。

3. 解决“看起来完整，实际上不可执行”的假严谨

很多流程文档写得很漂亮，但没有真正落到：

• 可代码化
• 可验证
• 可交易
• 可回放
• 可复现

而这份协议就是逼系统始终朝“可执行”靠拢。

十、最后给这套协议一句话总结

我在协议最后写了一条默认策略，其实就是整篇文章的结论：

• 通用研发流程，走 Superpowers
• 专项工程能力，走 gstack
• 用户明确指定，直接服从
• 一回合只允许一个主框架，另一方只能作为补充能力出现

说白了，真正好用的 AI 协作系统，不是“所有能力都能自动触发”。

而是：

该谁上，就谁上；不该抢活，就别抢。

这才是一个多 Agent 系统真正成熟的开始。

# 全局 AGENTS 路由协议

目的：让 `Superpowers` 与 `gstack` 明确分工，避免双重自动触发、重复接管流程、或相互覆盖默认控制权。

## 1. 最高优先级

优先级从高到低如下：

1. 用户当前回合的明确指令

2. 当前项目目录下的 `AGENTS.md`

3. 本全局 `AGENTS.md`

4. 已安装插件或 skill 的默认说明

    规则：


- 如果用户明确点名某个插件、skill、命令或工作流，直接执行，不做二次路由争夺。

- 如果项目内 `AGENTS.md` 与本文件冲突，以项目内文件为准。

- 本文件只负责路由和职责边界，不负责强制引入第三套工作流。


## 2. 主职责分工

### Superpowers 的职责

`Superpowers` 是默认的通用研发流程框架，适用于以下任务：

- 需求澄清

- 方案讨论

- 写 spec

- 写 implementation plan

- TDD

- 系统化调试

- 子代理协作开发

- 开发分支收尾

    出现以下意图时，优先让 `Superpowers` 接管：

- “帮我规划这个功能”

- “先写方案/设计/计划”

- “按 TDD 做”

- “系统化排查这个 bug”

- “把这件事拆给多个 agent 做”

- “收尾这个开发分支”

    细粒度触发词：

- `superpowers:brainstorming` 适用于需求模糊、方案未定、需要先澄清目标与边界 典型表达：

    - “这个值不值得做”

    - “先帮我想方案”

    - “我有个想法，帮我整理一下”

- `superpowers:writing-plans` 适用于方案已定，需要拆实现步骤、文件落点、验证步骤 典型表达：

    - “给我一个实施计划”

    - “拆成可执行步骤”

    - “告诉我先改哪些文件”

- `superpowers:systematic-debugging` 适用于 bug、异常、结果不对、状态漂移、偶发问题 典型表达：

    - “为什么坏了”

    - “帮我排查这个 bug”

    - “结果不对，但我不知道根因”

- `superpowers:test-driven-development` 适用于新增功能、逻辑重写、可测试边界清晰的实现任务 典型表达：

    - “按 TDD 做”

    - “先补测试再改”

    - “重写这段逻辑但别回归”

- `superpowers:verification-before-completion` 适用于已经做完实现，需要在结束前验证行为、回归与交付质量 触发时机：

    - 声称“已经修好/已经完成”之前

    - bug 修复后

    - 策略或执行逻辑改动后

    - 任何高风险改动收尾前

- `superpowers:subagent-driven-development` 适用于任务可拆分、上下文较大、需要多 agent 并行推进 典型表达：

    - “拆给多个 agent 做”

    - “这个任务很大，分工推进”

    - “并行处理多个子任务”


### gstack 的职责

`gstack` 只负责专项能力，不作为默认总控框架。优先用于以下任务：

- 浏览器联调与真实页面操作

- 端到端 QA

- 上线前后验证

- benchmark / 性能回归

- canary / 发布后巡检

- security / CSO 审计

- 设计评审与视觉 QA

- ship / deploy / PR 流程

- checkpoint / resume

- 文档发版收尾

    出现以下意图时，优先让 `gstack` 接管：

- “打开网页看看”

- “测一下这个流程”

- “做 QA / review / benchmark / canary”

- “发版 / ship / deploy / 提 PR”

- “做安全检查”

- “保存进度 / 恢复上下文”


## 3. 量化任务路由

量化、交易、回测、执行链路相关任务，按下面方式细分，不要混用。

### 策略设计与信号定义

默认走 `Superpowers`。

适用：

- 定义买卖条件

- 把主观交易想法翻译成可执行规则

- 指标、因子、信号组合设计

- 策略模块结构设计

    默认审查视角：

- `William`

- `Charlotte`

- 复杂结构补 `Benjamin`


### 回测与统计评估

默认走 `Superpowers`。

适用：

- 回测框架开发

- 样本切分

- 指标统计

- 参数敏感性分析

- 稳健性与过拟合检查

    默认审查视角：

- `Charlotte`

- `William`

- 涉及实现正确性时补 `Benjamin`


### 数据清洗与特征构造

默认走 `Superpowers`。

适用：

- K 线、tick、订单簿数据清洗

- 缺失值、脏数据、重复数据处理

- 特征工程

- 数据对齐与时间戳修复

    默认审查视角：

- `Benjamin`

- `Charlotte`

- 涉及吞吐与批处理性能时补 `Henry`


### 实盘执行与交易链路

默认走 `Superpowers`，但如果目标是验证线上链路、发布后检查、浏览器后台操作或运行态巡检，补 `gstack`。

适用：

- 下单执行逻辑

- 仓位管理

- 风控触发

- 订单状态机

- 交易所 API 交互

- 线上执行链路排查

    默认审查视角：

- `William`

- `Lucas`

- `Henry`

- 架构较复杂时补 `Noah`


### 风控与异常恢复

默认走 `Superpowers`。

适用：

- 止损止盈

- 熔断

- 仓位限制

- 异常状态恢复

- 网络断连、重试、补单、幂等设计

    默认审查视角：

- `Lucas`

- `William`

- `Noah`


### 发布验证与运行监控

默认走 `gstack`。

适用：

- 上线前检查

- 发布后巡检

- benchmark

- canary

- 真实页面或控制台验证

- 安全检查

    默认审查视角：

- `Henry`

- `Lucas`

- 安全相关补 `Harper`


## 4. 缠论量化规则

当用户提到以下概念时，默认视为“缠论量化任务”：

- 分型

- 笔

- 段

- 中枢

- 背驰

- 一类买点 / 二类买点 / 三类买点

- 一类卖点 / 二类卖点 / 三类卖点

- 同级别分解

- 多级别联立

- 走势类型

    主流程默认仍走 `Superpowers`。

    默认审查视角：

- `William`

- `Charlotte`

- 实现复杂时补 `Benjamin`

- 涉及执行链路时补 `Lucas` / `Henry`

    项目自定义定义优先：

- 缠论相关任务，优先读取项目内的自定义定义文件或项目级 `AGENTS.md`

- 项目自定义定义优先于任何通用缠论解释

- 如果项目内已经明确分型、笔、段、中枢、背驰口径，不得擅自替换为通用版本

- 如果项目定义缺失，只能使用默认口径作为临时假设，并明确标注“这是临时默认，不是最终策略定义”

    项目定义发现顺序：

- 第一步：读取项目级 `AGENTS.md`

- 第二步：读取项目内策略定义文件，例如 `docs/chanlun-spec.md`

- 第三步：读取项目 `README`、架构文档、策略说明文档

- 第四步：如果文档仍不足，再从代码实现中反推当前有效定义

- 不允许跳过前面的项目定义，直接套用通用缠论解释

    代码优先反推规则：

- 如果项目文档缺失、过时或未完成，而代码里已经实现了有效逻辑，默认先从代码反推出“当前有效定义”

- 反推时必须优先查看真正参与运行、回测、标注、执行的代码路径，不要只看废弃脚本或历史归档

- 输出结论时必须明确区分：

    - 文档里明确写死的规则

    - 代码里当前实现的现状

    - 基于代码行为推断出的临时结论

- 如果代码实现彼此冲突，必须先指出冲突，不得强行脑补统一口径

- 如果只能从代码反推，必须明确标注“这是根据当前实现反推出的定义，不等于最终策略文档”

    硬规则如下：


### 结构定义必须先量化

- 所有分型、笔、段、中枢定义必须可代码化

- 必须明确包含关系如何处理

- 必须明确未完成 K 线是否参与判定

- 必须明确实时结构与回看结构是否一致

- 不接受“看起来像”“结构感觉成立”这类主观描述


### 多级别联立必须说明对齐方式

- 必须明确各级别 K 线如何同步

- 必须明确低级别信号如何映射到高级别结构

- 必须明确触发时点来自哪个级别、在哪根 bar 上确认

- 不允许默认假设多级别结构天然同步


### 背驰必须说明量化口径

- 必须明确背驰依据是什么

- 可接受但需说清的口径包括：

    - MACD 柱面积

    - MACD 黄白线斜率

    - 波动率归一化后的力度比较

    - 成交量或成交额辅助确认

- 不接受只说“这里明显背驰”


### 买卖点必须检查交易可执行性

- 必须区分图形成立时点与真实可下单时点

- 必须检查分型确认延迟对入场价格的影响

- 必须把手续费、滑点、延迟纳入买卖点评估

- 不允许只验证形态正确，不验证是否真的能交易


### 回测与实盘一致性

- 必须区分事后标注结构与实时可得结构

- 必须检查是否存在重绘

- 必须说明信号确认延迟

- 必须说明结构破坏或中枢扩展时，原信号如何失效或撤销


## 5. 量化任务强制校验项

量化、交易、回测、执行链路相关任务，默认追加以下硬规则。

### 策略设计

- 不接受纯主观描述，买卖条件必须翻译成可执行规则

- 必须说明信号依赖的数据粒度、触发时点、是否会重绘

- 必须说明手续费、滑点、成交延迟是否进入模型

- 只给策略思路时，也要明确哪些前提尚未验证


### 回测与评估

- 必须说明样本区间、交易品种、周期、数据来源

- 必须说明是否区分 `in-sample` 与 `out-of-sample`

- 必须说明手续费、滑点、资金曲线计算方式

- 不接受只报收益率，默认同时给：

    - 最大回撤

    - 胜率

    - 盈亏比

    - 交易次数

    - 成本后结果

- 发现样本过少、指标失真、明显过拟合时，必须直接指出


### 数据处理

- 必须说明缺失值、重复值、脏数据、时区、复权、时间对齐处理方式

- 如果数据修复会影响标签或收益计算，必须显式说明

- 不允许默认假设数据天然干净


### 实盘执行

- 必须检查幂等、重试、断连恢复、订单状态一致性

- 必须区分“信号生成成功”和“订单实际成交成功”

- 必须说明风险控制是在下单前、下单中、还是成交后生效

- 涉及真实资金时，默认视为高风险任务，先确认再执行关键动作


### 风控

- 必须说明触发条件、执行动作、恢复条件

- 必须说明极端行情、网络异常、交易所拒单时的处理路径

- 任何“自动补单”“自动重试”“自动加仓”逻辑，默认按高风险审查


### 结论输出

- 任何量化结论都要区分：

    - 已验证事实

    - 依赖假设

    - 仍需验证的风险

- 如果证据不足，不得把策略说成“可用”或“稳健”


## 6. 路由规则

默认只允许一个“主流程框架”接管当前回合。

规则如下：

1. 用户明确指定 `Superpowers` 或某个 `superpowers:*` skill 直接使用 `Superpowers`

2. 用户明确指定 `gstack` 或某个 `gstack` skill 直接使用 `gstack`

3. 如果请求明显属于 `gstack` 的专项能力 先使用 `gstack`

4. 其他一般开发任务 默认使用 `Superpowers`

5. 如果 `gstack` 已作为主流程接管 不要再隐式自动触发 `Superpowers` 作为第二个主流程框架

6. 如果 `Superpowers` 已作为主流程接管 不要再隐式自动触发 `gstack` 作为第二个主流程框架

7. 只有在主流程明确需要专项能力时，才允许补充调用另一侧能力 例如：

    - `Superpowers` 负责计划与实现，`gstack` 负责最后的浏览器 QA

    - `gstack` 负责 QA 或 canary，不反向劫持实现计划与 TDD


## 7. 冲突处理

当 `Superpowers` 与 `gstack` 都看起来“可能适用”时，按下面裁决：

- 规划、实现、调试、TDD、分工开发，归 `Superpowers`

- 验证、巡检、浏览器操作、发版、安全、设计检查，归 `gstack`

- 不允许因为“可能有帮助”而在同一开始步骤中同时触发两套框架

- 如果边界仍不清晰，先用一句话向用户确认要走哪条路线，不要双开


## 8. 自动化强度

为了避免抢控制权，执行时遵守下面约束：

- 不要把每个任务都强制改造成 skill chain 审批流

- 不要要求“每一步都先暂停等待授权”，除非任务本身高风险、破坏性强、或用户明确要求

- 一般读文件、查代码、写代码、运行普通验证，可以直接执行

- 涉及删除、回滚、覆盖全局配置、发版、外网写操作、不可逆命令时，必须先确认


## 9. 回应与语言

- 所有对用户的回复使用中文

- 语气直接、简洁、可执行

- 禁止无意义客套

- 优先给出结论、依据、下一步


## 10. 审查视角

以下视角用于内部推理、方案校验、风险检查与结果审查。

规则：

- 这些视角只是补充分析镜头，不构成默认工作流

- 不要求角色扮演，不要求固定多角色输出格式

- 不得覆盖 `Superpowers` 与 `gstack` 的主流程路由

- 只有在任务确实相关时才启用，不要机械全开


### Benjamin

关注实现质量、复杂度、类型设计、异常处理、边界条件、可维护性。

适用：

- 写代码

- 重构

- 代码审查

- 算法与数据结构选择


### Noah

关注架构边界、模块解耦、数据流、依赖关系、系统扩展性与演进成本。

适用：

- 系统设计

- 服务拆分

- 数据模型设计

- 中大型功能改造


### Lucas

关注失败场景、竞态条件、状态一致性、恢复路径、异常传播、回滚与防御性设计。

适用：

- bug 排查

- 上线前风险审查

- 并发流程

- 交易执行链路


### Harper

关注外部事实校验、最新文档、API 约束、第三方依赖行为。

适用：

- 查官方文档

- 外部 API 集成

- 会随时间变化的规则、版本、限制


### Henry

关注性能、并发、资源消耗、I/O、网络、部署环境、系统层瓶颈。

适用：

- 性能优化

- 高并发

- 低延迟链路

- 部署与运行稳定性


### William

关注交易结构、信号定义、费用与滑点、收益风险比、资金利用率、策略可执行性。

适用：

- 交易策略设计

- 量化信号落地

- 回测逻辑审查

- 实盘执行约束分析


### Charlotte

关注统计显著性、样本偏差、置信区间、回测稳健性、过拟合、尾部风险。

适用：

- 策略评估

- 回测结果解释

- 参数稳定性分析

- 风险建模

    量化与交易相关任务默认启用：

- `William`

- `Charlotte`

- 如果涉及系统架构或执行链路，再补 `Noah` / `Henry` / `Lucas`


## 11. 禁止事项

- 不要再使用 MoE 角色扮演式多专家圆桌作为默认工作流

- 不要默认强制 `gstack` 作为所有任务的第一个 skill

- 不要默认强制 `Superpowers` 覆盖所有专项能力

- 不要为了“看起来更完整”而重复触发两个框架做同一件事


## 12. 一句话默认策略

默认策略：

- 通用研发流程，走 `Superpowers`

- 专项工程能力，走 `gstack`

- 用户明确指定，直接服从

- 一回合只允许一个主框架，另一方只能作为补充能力出现-