本文档从 CC-Viewer 项目中提取全部 Prompt 系统的设计模式， 覆盖 Preset Shortcuts（3 个内置预置）和 UltraPlan（2 个专家模板）， 共 12 个可复用设计模式（A-L），供其他 Claude Code 项目参考。
CC-Viewer 包含 两套独立的 Prompt 注入系统，面向不同复杂度的任务：
| 系统 | Prompt 数量 | 可自定义 | Agent 机制 | 典型耗时 |
|---|---|---|---|---|
| Preset Shortcuts | 3 内置 + 用户自定义 | 是（编辑/删除/排序） | /team |
分钟级 |
| UltraPlan | 2 角色模板 | 否（模板固定） | Agent 工具 + ExitPlanMode + TeamCreate |
30+ 分钟 |
Preset Shortcuts 的核心思想是 Prompt as Data——模式定义是纯数据（i18n key + 描述文本），用户可自由编辑，内置与自定义完全平等。
UltraPlan 是 Claude Code 原生 /ultraplan 命令的本地化实现，通过结构化的多阶段流水线（探索→规划→评审→执行→复审）驱动复杂任务。
┌─ Track A: Preset Shortcuts ─────────────────────────────────────────────┐
│ │
│ builtinPresets.js ─► i18n.js ─► TerminalPanel / ChatView │
│ (builtinId + key) (18语言) │ │
│ ├─ 终端模式: bracketed paste → PTY │
│ └─ Chat模式: 填入 textarea → 用户发送 │
├─ Track B: UltraPlan ───────────────────────────────────────────────────┤
│ │
│ ultraplanTemplates.js ─► UltraPlanModal.jsx ─► buildLocalUltraplan() │
│ (2 variant templates) (角色选择+文件上传) │ │
│ ├─ 终端: paste + \r │
│ └─ Chat: 自动发送 │
├─ 共享基础设施 ──────────────────────────────────────────────────────────┤
│ Bracketed paste 协议 (\x1b[200~...\x1b[201~) │
│ Agent Team 检测 (/api/claude-settings → CLAUDE_CODE_EXPERIMENTAL_...) │
│ 系统标签解析 (systemTags.js) │
│ 请求身份识别 (contentFilter.js → requestType.js) │
└─────────────────────────────────────────────────────────────────────────┘
关键设计决策：
- 内置项软删除 —
dismissedBuiltinPresets记录被删除的 builtinId，新版内置项自动出现 - UltraPlan 模板不做 i18n — prompt 工程高度精确，翻译会降低效果。Claude 无论用户界面语言如何都能理解英文指令
- UltraPlan 需要 Agent Team — 组件层面检查
agentTeamEnabled，未启用时按钮置灰 - 上下文窗口警告 — <1M token 模型显示警告 badge，建议
/clear后再使用
定位：通用型复杂问题深度分析——先侦察，后行动。
完整 Prompt：
ultrathink
<system-reminder>
先假设Prompt足够复杂，然后判断这个Prompt的复杂度，你可能启动一个/team；
需要一个2-5位teammate（系统非常复杂的情况下最大扩充到10位）；
从不同角色、视角来帮助你搜索、分析、阶段总结等；
你需要一个完整的规划来让这些teammate有明确的分工和良好的协同；
团队完成任务以后解散；
你需要汇总后分析可行性并完善你自己的Plan，非必要，不要急于执行。
如果Prompt足够简单，你可以忽略这段描述。
</system-reminder>
逐句设计意图：
| # | 原文 | 设计意图 |
|---|---|---|
| 1 | ultrathink |
强制深度思考模式，不走捷径 |
| 2 | <system-reminder> 包裹 |
提权——系统级指令优先级 |
| 3 | "先假设Prompt足够复杂" | 悲观估计策略：宁可高估不低估 |
| 4 | "然后判断复杂度" | 给 Claude 判断权，不是无脑启动 |
| 5 | "你可能启动一个/team" | "可能"而非"必须"——建议不是强制 |
| 6 | "2-5位teammate" | 弹性区间锚点 |
| 7 | "最大扩充到10位" | 硬性上限，防无限扩张 |
| 8 | "不同角色、视角" | 强制多元视角 |
| 9 | "搜索、分析、阶段总结" | 任务类型分类参考 |
| 10 | "完整的规划" | 规划先行 |
| 11 | "明确的分工和良好的协同" | 防止重复劳动 |
| 12 | "完成任务以后解散" | 资源回收 |
| 13 | "汇总后分析可行性" | 综合判断，不盲信报告 |
| 14 | "完善你自己的Plan" | 团队产出是输入，决策权在 lead |
| 15 | "非必要，不要急于执行" | 防护栏——防止直接改代码 |
| 16 | "如果Prompt足够简单，你可以忽略" | 降级出口——避免杀鸡用牛刀 |
与 UltraPlan 的关系：调查兵团是 UltraPlan Code Expert 的哲学前身——都是"先想后做"，但 UltraPlan 通过结构化流水线将这一理念从建议升级为强制。
定位：重量级 Code Review——多人多视角审查当前 git 变更。
完整 Prompt：
启动一个/team 有5个teammate；
如果判断任务较轻，可以适当缩小teammate数量，如果足够复杂可以扩大teammate数量；
任务是从不同视角和角色对当前git变更做Code Review；
根据当前的git变更记录，确认需求和目标是否实现，审查新增代码是否存在副作用：对已经功能破坏，以及自身编码是否有疏漏；
获得报告以后要审视报告，审视完报告总结出修改建议；
不要立即执行，要询问我；
三层审查框架（核心设计）：
┌─────────────────────────────┐
│ Layer 1: 功能完整性 │ ← 需求和目标是否实现？
│ "做了该做的吗？" │
├─────────────────────────────┤
│ Layer 2: 回归安全性 │ ← 是否破坏已有功能？
│ "做了不该做的吗？" │
├─────────────────────────────┤
│ Layer 3: 代码质量 │ ← 实现本身有没有疏漏？
│ "做的方式对吗？" │
└─────────────────────────────┘
定位：轻量级 Code Review——小改动快速审查。
完整 Prompt：
启动一个/team 有2个teammate；
如果判断任务很轻，可以是1个teammate；
任务是从不同视角和角色对当前git变更做Code Review；
根据当前的git变更记录，确认需求和目标是否实现，审查新增代码是否存在副作用：对已经功能破坏，以及自身编码是否有疏漏；
获得报告以后要审视报告，审视完报告总结出修改建议；
不要立即执行，要询问我；
与 Pro 版唯一区别：默认 2 人，可降至 1 人。审查逻辑（三层框架）完全一致——有意为之，审查质量标准不因团队规模而降低。
UltraPlan 是 CC-Viewer 对 Claude Code 原生 /ultraplan 命令的本地化实现，通过 <system-reminder> + [SCOPED INSTRUCTION] 注入结构化的多 agent 规划流水线。
与 Preset Shortcuts 的核心区别：
- Preset 是建议（"你可能启动一个 /team"）；UltraPlan 是结构化流水线
- Preset 把执行权交给 Claude 判断；UltraPlan 规定了 6 阶段闭环
- Preset 用
/team；UltraPlan 用Agent工具直接控制
定位：编程项目的多 agent 协作规划与实现。
完整 Prompt：
<system-reminder>
[SCOPED INSTRUCTION] The following instructions are intended for the next 1–3 interactions.
Once the task is complete, these instructions should be gradually deprioritized
and no longer influence subsequent interactions.
Leverage a multi-agent exploration mechanism to formulate a highly detailed implementation plan.
Instructions:
1. Use the Agent tool to spawn parallel agents to simultaneously explore different aspects
of the codebase:
- If necessary, designate a preliminary investigator to use `webSearch` to first research
advanced solutions within the relevant industry domain;
- One agent responsible for understanding the relevant existing code and architecture;
- One agent responsible for identifying all files requiring modification;
- One agent responsible for identifying potential risks, edge cases, and dependencies;
- You may add other roles or deploy additional agents beyond the three defined above;
the maximum limit for concurrently scheduled agents is 5.
2. Synthesize the findings from the aforementioned agents into a detailed, step-by-step
implementation plan.
3. Use the Agent tool to spawn a review agent to scrutinize the plan from various perspectives,
checking for any omitted steps, potential risks, or corresponding mitigation strategies.
4. Incorporate the feedback from the review process, then invoke `ExitPlanMode` to submit
your final plan.
5. Once `ExitPlanMode` returns a result:
- If approved: Proceed to execute the plan within this session.
- If rejected: Revise the plan based on the feedback provided, and invoke `ExitPlanMode` again.
- If an error occurs (including the message "Not in Plan Mode"): Do *not* follow the
suggestions provided by the error message; instead, prompt the user for further instructions.
Your final plan must include the following elements:
- A clear summary of the implementation strategy;
- An ordered list of files to be created or modified, specifying the exact changes required;
- A step-by-step sequence for execution;
- Testing and verification procedures;
- Potential risks and their corresponding mitigation strategies.
6. Upon the successful completion of the final plan's execution:
If code changes have been made and the project is Git-based, invoke `TeamCreate` to assemble
a "Code Review Team." The team's objective is to analyze the current Git change log and
validate the modifications from various perspectives and roles, specifically to:
- Confirm that the original requirements and objectives have been met;
- Review any newly added code for potential side effects or regressions;
- Review the implemented code for any oversights or errors.
Once the review report is generated, analyze it to formulate a set of recommended
modifications; proceed to implement these recommended modifications by default.
</system-reminder>6 阶段流水线拆解：
Phase 1: 并行探索 ──► 最多 5 个 agent 同时出发
│ ├─ [可选] webSearch 行业调研
│ ├─ 代码架构理解
│ ├─ 文件变更识别
│ └─ 风险/边界/依赖分析
▼
Phase 2: 综合 ──────► lead 将所有 agent 发现合成为详细计划
▼
Phase 3: 评审 ──────► 独立 review agent 审视计划
▼
Phase 4: 提交 ──────► ExitPlanMode → 用户审批
▼
Phase 5: 执行 ──────► 批准→执行 / 拒绝→修改重提 / 错误→问用户
▼
Phase 6: 复审 ──────► TeamCreate 组建 Code Review Team 自审
关键设计元素：
| 元素 | 设计意图 |
|---|---|
[SCOPED INSTRUCTION] 前言 |
时间域限定——防止长模板"污染"后续简单交互 |
| "multi-agent exploration mechanism" | 锚定到 Agent 工具而非 /team |
| Phase 1 三个必选角色 | 架构、文件、风险——最小覆盖集 |
| "If necessary" webSearch | 条件部署——简单任务不浪费 agent |
| "maximum limit...5" | 硬性上限 |
| Phase 3 独立 review agent | 不自审——用独立视角检验 |
| Phase 5 三路分支 | 完整状态机（批准/拒绝/错误） |
| "Do not follow error suggestions" | 覆盖 Claude Code 的错误恢复建议，防递归循环 |
| Phase 6 TeamCreate | 自动组建评审团队，闭环 |
| "by default" 自动修复 | 评审发现默认执行修复，用户不需要逐条确认 |
定位：调研与分析任务的多 agent 协作。
完整 Prompt：
<system-reminder>
[SCOPED INSTRUCTION] The following instructions are intended for the next 1–3 interactions.
Once the task is complete, these instructions should be gradually deprioritized
and no longer influence subsequent interactions.
Leverage a multi-agent exploration mechanism to formulate an exceptionally detailed
implementation plan.
Instructions:
1. Utilize the Agent tool to spawn parallel agents that simultaneously explore various facets
of the requirements:
- If necessary, deploy a preliminary investigator to conduct an initial survey of
industry-specific solutions using `webSearch`;
- If necessary, deploy a specialized investigator to research authoritative sources—such as
academic papers, news articles, and research reports—using `webSearch`;
- Assign an agent to synthesize the target solution, while simultaneously verifying the
rigor and credibility of the gathered papers, news, and research reports;
- If necessary, assign an agent to analyze competitor data to provide supplementary
analytical perspectives;
- If necessary, assign an agent to handle the implementation of a product demo (generating
outputs such as HTML, Markdown, etc.);
- If the task is sufficiently complex, you may assign additional teammates to the roles
defined above, or introduce other specialized roles; you are permitted to schedule up to
5 teammates concurrently.
2. Synthesize the findings from the aforementioned agents into a comprehensive, step-by-step
implementation plan.
3. Utilize the Agent tool to spawn a set of parallel review agents; these agents shall
scrutinize the plan from multiple roles and perspectives to identify any omitted steps
and to propose reasonable additions or optimizations.
4. Consolidate the feedback received from the review agents, then invoke `ExitPlanMode`
to submit your final plan.
5. Upon receiving the result from `ExitPlanMode`:
- If Approved: Proceed to execute the plan within this current session.
- If Rejected: Revise the plan based on the provided feedback, and then invoke
`ExitPlanMode` once again.
- If an Error Occurs (including the message "Not in Plan Mode"): Do *not* follow the
suggestions provided by the error message; instead, prompt the user for further instructions.
Your final plan must include the following elements:
- A clear summary of the proposed implementation strategy;
- An ordered list of files to be created or modified, specifying the exact changes required;
- A step-by-step sequence for executing the implementation;
- Identification of potential risks and corresponding mitigation strategies;
- Creative ideation and suggestions for advanced enhancements;
- If a product demo was generated, place the corresponding demo output in an appropriate
location and notify the user.
</system-reminder>与 Code Expert 的关键差异：
| 维度 | Code Expert | Research Expert |
|---|---|---|
| Phase 1 agent 角色 | 代码聚焦（架构/文件/风险） | 调研聚焦（行业/论文/竞品/Demo） |
| 条件部署密度 | 1 个 "if necessary" | 5 个 "if necessary" |
| 评审拓扑 | 单个 review agent | 并行多个 review agents |
| 计划额外要求 | 测试与验证流程 | 创意构想 + Demo 输出位置 |
| 措辞强度 | "highly detailed" | "exceptionally detailed" |
| Phase 6 | TeamCreate 代码复审 | 无（调研产出难以自动审查） |
buildLocalUltraplan() 函数（ultraplanTemplates.js:98-109）负责最终 prompt 组装：
[可选 seedPlan] ──► "Here is a draft plan to refine:\n\n{seedPlan}"
+
[模板] ──► ULTRAPLAN_VARIANTS[variant]
+
[用户输入] ──► userPrompt（文件路径已预拼接）
文件附件在组装前被转为引用路径拼接到 userPrompt 前面。
从全部 Prompt 系统中提炼出 12 个可复用设计模式。
先假设 [最复杂情况]，然后判断 [实际复杂度]。
如果 [足够简单]，可以 [降级/忽略]。
原理：强制从"最坏情况"出发，再判断是否降级。比"先快速看看，复杂了再升级"更安全——后者 Claude 倾向偷懒。
反模式：先快速看一下，如果发现很复杂再启动团队。
需要 N 个 teammate（[条件A] 下可缩至 M / [条件B] 下可扩至 K）。
设计公式：锚点值 + 收缩条件 + 扩张条件 + 硬性上限
| 变体 | 示例 | 场景 |
|---|---|---|
| 重型 | "5个，可缩小可扩大" | 大规模任务 |
| 轻型 | "2个，可降至1个" | 小任务 |
| 弹性 | "2-5个，最大10个" | 复杂度未知 |
反模式：无锚点（启动一些 teammate）或无弹性（恰好3个）。
1. [宏观] 需求/目标是否实现 → 做了该做的吗？
2. [中观] 对已有功能是否有破坏 → 做了不该做的吗？
3. [微观] 自身编码是否有疏漏 → 做的方式对吗？
可泛化到任何审查类任务：
| 场景 | Layer 1 | Layer 2 | Layer 3 |
|---|---|---|---|
| Code Review | 功能完整性 | 回归安全性 | 代码质量 |
| 安全审计 | 威胁覆盖率 | 防护是否被绕过 | 实现有无漏洞 |
| 性能优化 | 目标达成 | 是否引入新瓶颈 | 实现是否最优 |
| API 设计 | 功能满足 | 向后兼容 | 接口设计质量 |
获得报告后要审视报告，总结出修改建议。
不要立即执行，要询问我。
双重防护栏：
teammate 产出报告 → lead 二次审视(AI防护栏) → 总结建议 → 用户确认(人类防护栏) → 执行
关键措辞："审视"而非"转发"；"不要立即执行"而非"禁止执行"。
让 prompt 被 Claude 当作系统级指令处理，优先级高于普通 user message。
用：指令可能被后续对话冲淡时（调查兵团）、需要建立"元规则"时。 不用：指令已足够直接时（Code Review 系列）。
单独一行的 ultrathink 关键词强制 Claude 启用扩展思考。
调查兵团用了 ultrathink，Code Review 和 UltraPlan 都没用——前者任务边界清晰不需要额外思考深度，后者通过多 agent 探索结构性地实现了深度分析。
[SCOPED INSTRUCTION] The following instructions are intended for the next 1–3 interactions.
Once the task is complete, these instructions should be gradually deprioritized
and no longer influence subsequent interactions.
设计意图：<system-reminder> 提升优先级但没有时间边界。UltraPlan 的模板又长又有强制性——如果不加时间限定，Claude 会在后续简单查询中继续尝试启动多 agent 探索和 ExitPlanMode。
与模式 E 的组合：<system-reminder>（提权）+ [SCOPED INSTRUCTION]（限时）= "高优先级但仅限当前任务"。
与模式 A 的区别：模式 A 是基于复杂度的降级（"足够简单就忽略"）；模式 G 是基于时间的过期（"1-3 轮后自动减弱"）。
反模式：长模板不加时间限定。整个 session 的后续交互都会被 prompt 影响。
Phase 1: 探索（并行 agents）
↓
Phase 2: 综合（单 lead 合成）
↓
Phase 3: 评审（独立 review agent）
↓
Phase 4: 提交（ExitPlanMode）
↓
Phase 5: 执行/修改
↓
Phase 6: 执行后复审（TeamCreate）
核心特征：
- 该并行时并行（Phase 1 探索、Research Expert 的 Phase 3 评审）
- 该串行时串行（综合必须在探索之后，评审必须在规划之后）
- 闭环——Phase 6 的发现反馈回实现
与 Preset 的对比：调查兵团建议"你可能启动一个 /team"但不规定阶段。UltraPlan 把每个阶段编号明确，强制顺序执行。
invoke ExitPlanMode to submit your final plan.
If approved: Proceed to execute.
If rejected: Revise and invoke ExitPlanMode again.
If error ("Not in Plan Mode"): Do NOT follow error suggestions; prompt user.
三个设计决策：
- 用 ExitPlanMode 而非直接执行 — 接入 Claude Code 原生审批 UI，给用户结构化的审批时刻
- 三路分支 — 批准、拒绝、错误，完整状态机
- 错误覆盖指令 — Claude Code 的 ExitPlanMode 错误信息有时建议绕过审批流程的 workaround，prompt 显式覆盖
与模式 D 的关系：模式 D 用对话式"问我"实现人在回路；模式 I 用结构化的 plan approval UI 实现——更正式、更不容易被跳过。
Upon successful completion: invoke TeamCreate to assemble a "Code Review Team."
...analyze the current Git change log and validate...
proceed to implement recommended modifications by default.
与模式 D 的重要对比：
| 维度 | 模式 D | 模式 J |
|---|---|---|
| 时机 | 执行前 | 执行后 |
| 方式 | "问我" | 自动 TeamCreate |
| 决策权 | 人类 | AI（默认执行修复） |
| 适用 | 审查任务（用户要控制权） | 自主执行（用户要质量保障） |
"by default" 是关键——评审发现默认自动修复，与模式 D 的"先问我"形成互补关系。
注：Research Expert 没有 Phase 6，因为调研产出（文档、分析报告）难以通过 git diff 自动审查。
同一结构框架下，通过改变 agent 配置适配不同领域：
共享骨架：[SCOPED INSTRUCTION] 前言 → 分阶段流水线 → ExitPlanMode 三路分支 → 计划格式要求
变化维度：Phase 1 agent 角色定义 / 条件部署密度 / 评审拓扑 / 产出物格式
新增变体（如 Security Expert、Design Expert）只需修改 Phase 1 的 agent 角色和最终计划要求，结构完全复用。
- If necessary, designate a preliminary investigator to use webSearch...
- If necessary, deploy a specialized investigator...
给 Claude 部署决定权，同时明确可选角色清单。
与模式 B 的互补：模式 B 控制数量（"2-5 个"）；模式 L 控制组成（"这些角色，但仅在需要时"）。
反模式：
- 全部必选——简单任务浪费 agent 和上下文
- 太模糊——"按需部署 agents"没有给出角色菜单，Claude 不知道考虑什么选项
| 维度 | Preset (模式 A-F) | UltraPlan (模式 G-L) |
|---|---|---|
| 指令持久性 | 永久直到 session 结束 (E) | 时间域限定 (G) |
| 执行控制 | 对话式"问我" (D) | 结构化 ExitPlanMode (I) |
| 团队组建 | 建议式 ("可能启动 /team") | 规定式 (Agent 工具, 明确阶段) (H) |
| 团队规模 | 定量弹性 (2-5, max 10) (B) | 定性弹性 (命名角色, 条件部署) (L) |
| 质量保障 | 仅执行前审查 (C, D) | 执行前 + 执行后 (J) |
| 复杂度处理 | 悲观估计 + 降级 (A) | 规定性流水线，无论复杂度 |
| 深度思考 | 显式关键词 (F: ultrathink) | 隐式通过多 agent 探索（不需要 ultrathink） |
| 范围 | 单阶段（规划 OR 审查） | 多阶段闭环 (H) |
UltraPlan 如何组合原有模式：
- 用 模式 E (
<system-reminder>) 但叠加 模式 G （时间域限定） - 用 模式 L （基于组成的弹性）替代 模式 B （基于数量的弹性）
- 将 模式 D （人在回路）演化为 模式 I （结构化审批）+ 模式 J （自动复审）
- 超越 模式 F （ultrathink）——多 agent 探索结构性地实现深度分析，不再需要思考模式触发词
| 场景 | 推荐系统 | 原因 |
|---|---|---|
| 小改动快速审查 | Preset: Code Reviewer | 2 人，分钟级 |
| 大规模重构审查 | Preset: Code Reviewer Pro | 5 人，不需要执行 |
| 未知范围的复杂分析 | Preset: 调查兵团 | 弹性团队，探索性 |
| 完整功能实现+规划 | UltraPlan: Code Expert | 分阶段流水线，自动复审，30+ 分钟 |
| 市场调研/竞品分析 | UltraPlan: Research Expert | 多源调研，Demo 生成 |
| 简单一次性任务 | 都不用 | 直接输入，无需多 agent 开销 |
注册（builtinPresets.js）：
export const BUILTIN_PRESETS = [
{ builtinId: 'scout-regiment', version: 1,
teamName: 'ui.preset.scoutRegiment.name',
description: 'ui.preset.scoutRegiment.desc' },
// ...
];加载与合并：前端加载 /api/preferences → 合并内置（未被 dismiss 且不在列表中的）→ 内置项插入头部。
注入：
- 终端模式：WebSocket → PTY，bracketed paste 包裹（
\x1b[200~...\x1b[201~） - Chat 模式：填入 textarea，用户手动发送
持久化：GET/POST /api/preferences → preferences.json
模板定义（ultraplanTemplates.js）：ULTRAPLAN_VARIANTS 对象含两个 variant + buildLocalUltraplan() 组装函数。
UI（UltraPlanModal.jsx）：角色选择器 + textarea + 文件上传 + 上下文窗口警告。
注入：
- 终端模式：bracketed paste +
\r（自动提交） - Chat 模式：填入 textarea + 编程触发
handleInputSend()（也自动提交）
注意关键区别：Preset 在 Chat 模式下不自动提交（用户可编辑后发送），UltraPlan 自动提交。
前置条件：Agent Team 已启用（agentTeamEnabled 检查）、CLI 模式可用、上下文窗口检查。
| 文件 | 作用 |
|---|---|
src/utils/builtinPresets.js |
预置注册表（builtinId + i18n key） |
src/i18n.js :5345-5464 |
18 语言的 prompt 模板内容 |
server.js :328-354 |
持久化 API（preferences.json） |
| 文件 | 作用 |
|---|---|
src/utils/ultraplanTemplates.js |
模板注册表 + buildLocalUltraplan() 组装 |
src/components/UltraPlanModal.jsx |
Modal UI（角色选择/文件上传/上下文警告） |
src/components/UltraPlanModal.module.css |
Modal 样式 |
concepts/*/UltraPlan.md |
多语言用户文档 |
| 文件 | 入口 | 方式 |
|---|---|---|
src/components/TerminalPanel.jsx |
终端工具栏按钮 | WebSocket → PTY bracketed paste |
src/components/ChatInputBar.jsx |
Chat + 菜单 |
填入 textarea |
src/components/ChatView.jsx |
handlePresetSend / handleUltraplanSend |
上游消费者 |
| 文件 | 识别目标 |
|---|---|
src/utils/contentFilter.js |
MainAgent / SubAgent / Teammate 检测 |
src/utils/teammateDetector.js |
Native Teammate 检测 + 名字提取 |
src/utils/requestType.js |
请求分类（MainAgent/SubAgent/Teammate/Count/Preflight/Plan） |
src/utils/promptClassifier.js |
PTY 交互分类（Plan 审批 / 危险操作） |
src/utils/toolResultBuilder.js |
工具结果状态 + UltraPlan 权限拒绝检测 |
| 文件 | 作用 |
|---|---|
src/utils/systemTags.js |
System Tag 解析器（12 种标签） |
src/utils/ptyChunkBuilder.js |
UI 选择 → 终端按键序列 |
src/utils/teammateAvatars.js |
角色推断 + 头像分配（17 种角色） |
builtinPresets.js ──────────────────┐
│ BUILTIN_PRESETS │
▼ ▼
TerminalPanel.jsx ChatView.jsx
│ presets + ultraplan │ presets + ultraplan
│ ▼
│ ChatInputBar.jsx
│ │ (+UltraPlan 菜单项)
▼ ▼
ultraplanTemplates.js ──────► buildLocalUltraplan()
│ ULTRAPLAN_VARIANTS │
▼ ▼
UltraPlanModal.jsx server.js /api/preferences
│ 角色选择 + textarea │
▼ ▼
[bracketed paste / textarea] preferences.json
从模式 A-F 中选择组合，典型模板：
[可选: ultrathink]
[可选: <system-reminder> 包裹]
启动一个/team 有 N 个 teammate；
[弹性条件]；
任务是 [具体任务描述]；
[审查/分析框架——从宏观到微观]；
获得报告以后 [二次审视要求]；
[人在回路约束]；
[可选: 降级出口]
示例——Security Audit 预置：
ultrathink
<system-reminder>
启动一个/team 有3个teammate；
如果涉及认证、支付等核心模块，扩大到5个；
任务是对当前git变更做安全审计：
1. 确认是否引入了新的攻击面（新的输入点、API端点、文件操作）；
2. 审查是否破坏了已有的安全防护（认证、授权、输入验证、CSRF保护）；
3. 检查实现细节是否存在安全漏洞（注入、XSS、信息泄露、不安全的默认值）；
每个teammate从不同攻击者视角审查（外部攻击者、内部恶意用户、供应链攻击）；
获得报告以后按严重程度（Critical/High/Medium/Low）分类汇总；
不要立即修复，要询问我确认优先级。
如果变更不涉及安全敏感代码，可以缩减为1个teammate做快速扫描。
</system-reminder>
- 复制
codeExpert模板结构 - 修改 Phase 1 的 agent 角色定义
- 调整 "If necessary" 条件部署子句
- 修改最终计划要求列表
- 决定评审拓扑（单个 vs 并行 review agents）
- 决定是否需要 Phase 6（执行后复审）
- 添加到
ULTRAPLAN_VARIANTS+ i18n 角色按钮文本 + Modal UI
示例——Security Expert 变体：
Phase 1 agents: 威胁建模 / 漏洞扫描 / 合规检查 条件部署: "If necessary, deploy an agent to research known CVEs" 计划额外要求: 威胁模型图 + 合规检查清单 评审: 红队 review agent + 蓝队 review agent 并行
| 模式 | 互补 | 冲突 |
|---|---|---|
| A (悲观估计) | B (弹性规模) | H (规定性流水线替代估计) |
| B (弹性规模) | A, C, D | L (组成比数量重要时) |
| E (system-reminder) | G (时间限定), F (ultrathink) | 无 |
| G (时间限定) | E, H, I | 无 |
| H (分阶段流水线) | I, J, K, L | A (流水线替代估计) |
| I (ExitPlanMode) | H, J | D (不同的人在回路机制) |
| J (执行后复审) | H, I | D (自动 vs 手动) |
调查兵团的指令是"元规则"（如何思考问题），可能在多轮对话中被冲淡；Code Review 的指令是"具体任务"（审查 git diff），一次性消费。
"禁止"是绝对约束，导致 Claude 在用户后续说"去改吧"时也不动手。"不要立即执行，要询问我"是流程约束——不是不能做，是要先问。
有意为之。审查质量标准不因团队规模降低。区别只在并行度。
多行 prompt 不包裹，终端会把每个换行当 Enter 逐行提交。Bracketed paste 让终端识别为一次粘贴操作。
版本升级可能新增内置项。软删除区分"从未见过"和"见过但删了"。新增项不在 dismissed 列表中，自然出现。
/team 创建带外部进程的持久团队。Agent 工具在同 session 内启动轻量子 agent，任务完成即终止。UltraPlan 的 agent 是任务特定、短生命周期的——用 /team 是大材小用且难以编排分阶段流水线。
<system-reminder> 提权但无时间边界。UltraPlan 模板长且有强制性，不加时间限定会"污染"后续简单交互——Claude 继续尝试启动 agent 和 ExitPlanMode。
模板包含精确校准的 prompt 工程（条件子句、阶段编排、错误处理分支）。翻译会改变细微语义降低效果。Claude 无论用户界面语言如何都能理解英文指令。
Code Expert 产出可通过 git diff 分析验证的代码变更。Research Expert 产出分析文档和方案，自动审查意义不大——调研质量需要人来评估。
ExitPlanMode 返回 "Not in Plan Mode" 时，Claude Code 的错误处理器建议先进入 plan mode，这会创建递归循环。显式覆盖防止 Claude 走入死胡同。
调研产出需要多视角验证（数据严谨性？来源可信度？分析平衡性？）。代码计划有更客观的标准（能编译？文件全覆盖？），单个 reviewer 足矣。