ask-opus

name	ask-opus
description	让 Opus 子线程处理最复杂的分析和执行任务。触发词："问一下opus"、"让opus去做"。主线程（L1）制包，Opus（L3）深度推理。
disable-model-invocation	true

Opus 子线程

从主线程（L1 / Haiku）发起调用，让 Opus（L3）承担最高复杂度的推理、架构设计、复杂代码生成。

设计哲学：人保留分工权和最终决策权。AI 不做自动路由——用户不说触发词，主线程自己处理。用户说触发词，主线程严格按触发词对应模式执行。

---

0. 架构设计初衷与你的角色

你（主线程）是 L1——信息收集者，不是问题解答者。

这个架构的核心设计是分层协作：

• 主线程（你）= L1：大量读文件、摄取上下文、整理事实。这一层 token 消耗多，但不需要深度推理——只需要"找到什么、整理成什么格式"。
• 子线程（Opus）= L3：接收你精炼好的包，在干净的上下文里做最高深度的推理、架构设计、复杂代码生成。

为什么这样分工，而不是直接把所有上下文扔给强模型：

1. Token 效率：读文件的成本用 Haiku 承担，深度推理的成本才用强模型，总体费用大幅降低。
2. 避免注意力稀释：强模型拿到的包越精炼，注意力越集中。如果把几百行原始代码直接传给 Opus，它的注意力会被无关内容分散；只传"最小必要信息"，Opus 才能把全部推理能力用在真正需要判断的地方。

何时选 Opus 而非 Sonnet：

• 需要多轮推理、复杂权衡（如架构决策、涉及多个子系统的方案设计）
• 代码生成量大且逻辑复杂
• 需要最高质量输出，成本不是首要考量
• Sonnet 已经给出答案但用户认为结论不够可信，需要第二意见

你的核心职责：

• 读文件、定位信息、提取事实——做得越精准，子线程的判断越可靠
• 制作"最小充分包"——只装子线程真正需要的，不装"可能有用"的
• 声明来源——子线程不知道你读了什么、没读什么，你必须显式告诉它（见 §3.3 的 L1 信息来源声明）

你不是在替子线程思考，你是在替子线程收集弹药。 结论是子线程的职责，原文是你的职责。把约束条件写成"代码符合规范"是越俎代庖；把规则原文传进去，让 Opus 自己验证，才是正确的分工。

给清单，不设路障。 子线程用的是比你更强的模型，它清楚自己该读什么。你给的文件清单是「最小必读」（保证它不漏关键信息），不是「只准读这些」——它若判断需要更多上下文，放手让它自己去读。注意：放开的只是「读」；「能写哪些文件」仍由派模式的授权边界严格限定。

---

1. 模型与触发词

模式	触发词	调用模型
问模式	问一下opus	opus
派模式	让opus去做	opus

• 用户不说触发词 → 不调子线程，主线程自己处理
• 触发词模糊时 → 直接问用户："你想问模式还是派模式？"

---

2. 模式路由

用户消息
  │
  ├─ 不含触发词 → 主线程直接处理
  │
  └─ 含触发词
        │
        ├─ "问一下" / "怎么看" / "审查" / "评审"
        │   → 问模式（§3）
        │
        └─ "让XX去做" / "让XX直接" / "派XX"
            → 派模式（§4）

---

3. 问模式

用途：让 Opus 回答一个问题（复杂设计审查、技术架构分析、高难度方案评估等）。Opus 只读不改，输出分析结论，主线程消化后回答用户。

3.1 上下文打包指南

不同问题类型需要不同的上下文。主线程根据问题类型，从以下槽位中选择相关的填入：

[具体问题] — 一句话，可被独立回答，不依赖隐含上下文

[文件引用] — 需要读的代码/文档文件，精确到方法/行范围
  适用：代码审查、架构分析、技术问题
  格式：文件路径（只读：方法名/行范围）
  每个文件引用附带最小必读清单："以下文件务必读取；如你判断需要更多上下文，可自行阅读其他文件"

[背景事实] — 回答此问题必须知道的关键事实
  格式：用自然语言描述，写清楚"当前是什么状态"
  如果是代码相关：先浓缩再写入（代码→关键事实，禁止贴超过5行的原始代码）

[约束条件] — 回答此问题必须遵守的边界
  来源：CLAUDE.md 红线、技术约束、资源约束、已排除的选项及原因
  格式：内嵌原文条款，不要写"参考 CLAUDE.md"

[判断标准] — 什么算好答案
  例："方案必须兼容现有的游标分页机制"、"优先选择侵入性最小的方案"

[外部信息] — 非代码的参考信息
  适用：产品设计、商业策略、竞品分析
  例：竞品数据、用户反馈、市场数据、故事设定、人物档案

填槽原则：

1. 先浓缩再装包。读到的原始代码/文档不能直接贴进去，要压缩成关键事实描述。200 行代码 → 3 行"这个方法做了什么"。
2. 每项内容过 RAM 检验句。「Opus 需要 [这项内容]，才能 [回答这个问题]，否则会卡在 [具体卡点]。」填不完整 → 不加入。
3. 空槽检查。发包前对每个留空的槽位问一句："Opus 没有这个信息会怎么处理？会基于什么假设？"如果答案是有风险的假设 → 必须补上。
4. 不设数字上限。任务需要多少信息就传多少。不因"太多"而截断关键信息——信息截断 → 质量下降 → 白干 → 最大浪费。
5. 约束条件只写原文，不写结论。"for/stream 中不得调 Dao/Service，必须批量查询 + Map 关联"是原文 ✅；"代码符合 N+1 规范"是结论 ❌——结论让子线程无法独立验证约束是否真的满足。

3.2 常见问题类型的槽位组合

问题类型	通常需要的槽位
代码审查	具体问题 + 文件引用 + 约束条件
架构设计	具体问题 + 文件引用 + 背景事实 + 约束条件 + 判断标准
产品/交互设计	具体问题 + 背景事实 + 判断标准 + 外部信息
商业策略	具体问题 + 背景事实 + 外部信息 + 约束条件
技术选型	具体问题 + 背景事实 + 约束条件 + 判断标准
创作/写作	具体问题 + 背景事实（设定/大纲/人物）+ 外部信息
人生/决策	具体问题 + 背景事实 + 约束条件 + 判断标准

这只是参考，实际填哪些槽位由 RAM 检验句决定。

3.3 Prompt 模板

[具体问题]

L1 信息来源声明（必填）：
- 交付形式：直接回复，不写文件，不创建文件
- 已读文件清单（最小必读，子线程可自行补读）：
  - [文件路径]（读取范围：方法名 / 行号）
  - （代码题必填；非代码题若无文件引用可写"无文件引用"）
- 未纳入本包的已知信息：
  - [内容] — 原因：[为什么排除]

[文件引用 / 背景事实 / 约束条件 / 判断标准 / 外部信息]
（按需填入，无关槽位留空。每项内容必须能通过 RAM 检验句。）

输出要求：
- 直接输出结论。不要改任何文件，不要创建文件。
- 如果现有信息不足以给出可靠结论，不要硬答。先声明缺失的关键信息，再给出基于明确假设的条件性结论。
  格式：⚠️ 信息不足：缺少 [X]。以下结论基于假设 [Y]。

3.4 示例

下面这个粉丝列表分表方案，在 100 万粉丝的极端场景下，会不会有性能问题？

L1 信息来源声明：
- 交付形式：直接回复，不写文件，不创建文件
- 已读文件清单（最小必读，子线程可自行补读）：
  - core/.../UserFollowBiz.java（只读：getFollowerListWithUserInfo）
  - core/.../UserFollowService.java（只读：filterFollowing）
- 未纳入本包的已知信息：无

背景事实：
- 分表策略：user_following_{hash(uid) % 32}
- 互关判定用 IN 查询，一次最多 50 个 userId
- 当前 DAU 约 5000，粉丝最多的用户约 3 万粉丝，暂无性能问题

约束条件：
- 禁止 N+1 查询：for/stream 中不允许调用 Dao/Service，必须批量查询 + Map 关联
- 列表接口必须游标翻页，禁止 page/pageSize

判断标准：
- 100 万粉丝场景下，单次请求响应时间不超过 500ms

输出要求：
- 直接输出结论。不要改任何文件，不要创建文件。
- 如果现有信息不足以给出可靠结论，不要硬答。先声明缺失的关键信息，再给出基于明确假设的条件性结论。

---

4. 派模式

用途：让 Opus 在授权范围内直接执行任务。Opus 自己判断需要改哪些文件（包括新建文件），执行前先汇报改动范围，主线程确认后放行。

核心原则：主线程给"意图 + 护栏"，强模型决定"执行路径"。主线程不替强模型预设文件清单。

4.1 派模式流程

主线程 → 发任务 + 验收标准 + 禁入区 + 约束
Opus  → 探索代码 → 汇报改动范围计划
主线程 → 确认/调整范围
Opus  → 执行改动
主线程 → git diff 验收 → 报告用户

4.2 Prompt 模板

[任务描述] — 要做什么
[验收标准] — 做到什么程度算完成

▸ 禁止区（绝对不能碰的文件/目录/模块）
  - [明确排除的范围]

▸ 约束（必须遵守的规则，从 CLAUDE.md 内嵌原文）
  - [适用条款]

▸ 范围探索
  先探索代码，确定需要改动哪些文件（包括是否需要新建文件）。
  在开始写代码之前，先输出改动范围计划：
  
  ## 改动范围计划
  计划修改：
    - [文件路径]：原因
  计划新建：
    - [文件路径]：原因
  需确认：
    - [文件路径]：主线程提示里没提到但逻辑上需要，请确认
  预计改动量：[大/中/小]
  
  主线程回复"确认"后开始施工。

▸ 完成后
  输出改动摘要（每个文件改了什么）。

4.3 主线程验收

Opus 完成后，主线程执行验收：

□ 范围检查：git diff --name-only，是否都在授权范围内？
□ 编译检查：改动是否引入编译错误？
□ 约束检查：每条约束都遵守了吗？（N+1、游标分页、@Resource 等）
□ 验收标准：每一项都完成了吗？
□ 越界检查：有没有改动禁止区的文件？

全部通过 → 向用户报告改动摘要。不通过 → 主线程修正，或告知用户具体问题。

---

5. 调用方式

使用 Agent 工具直接调子线程，无需 bash 命令：

问模式（只读分析）：

Agent(
  description: "一句话描述任务",
  model: "opus",
  prompt: [制好的 prompt]
)

派模式（执行任务，需要读写文件）：

Agent(
  description: "一句话描述任务",
  model: "opus",
  isolation: "worktree",   # 需要文件隔离时加；不隔离则省略
  prompt: [制好的 prompt]
)

不需要临时文件，不需要 unset，不需要 bash。

---

6. 异常处理

异常	处理
Opus 不可用 / 配额耗尽	告知用户："Opus 不可用，是否需要降级为 /ask-sonnet？"
Agent 超时（>180s 无响应）	重试一次；仍超时报告用户
输出明显不对 / 空响应	检查 prompt 是否有歧义或信息缺口，修正后重试
输出被截断	在 prompt 末尾加"如输出过长，优先输出结论部分"
派模式：改动超出授权范围	撤销超出部分的改动，告知用户

---

7. 主线程职责

7.1 问模式

• 消化 Opus 结论，用自己的话告诉用户，附加独立判断
• 不要把 Opus 输出当作最终答案——你是决策者，Opus 是顾问
• 如果 Opus 答案有矛盾或涉嫌事实错误，明确提醒用户
• 如果 Opus 输出了"⚠️ 信息不足"声明，必须向用户说明 Opus 基于什么假设得出了结论，让用户判断假设是否成立

7.2 派模式

• 验收 Opus 的改动（按 §4.3 清单）
• 向用户报告：改了什么、发现了什么问题、做了什么修正

7.3 成本意识

• 信息收集（读文件、搜索、整理）→ 主线程自己做，不调子线程
• 深度推理、代码生成、方案判断 → 调子线程
• Opus 费用显著高于 Sonnet——一般任务优先用 /ask-sonnet，Opus 留给真正需要最高质量的场景

7.4 禁止

• 不要在问模式下让 Opus 改文件
• 不要在派模式下让 Opus 超出授权范围
• 不要用一次 Agent 调用反复追问（每次追问开新调用）
• 用户没触发就不要调

---

8. 参考文档

本 skill 的模板和方法论源自 证据包制作规范（references/dispatch.md，与本 skill 同目录）。

• 日常 80% 场景：直接用本 skill 的 §3/§4 模板
• 复杂场景（多文件、多层约束、待决策点）：先读 references/dispatch.md，用 RAM 框架深度制包，再通过本 skill 调用