0 Fork 0

Files

T

li a2c161729c feat: configurable model routing for frontend/backend (#121 )

Allow users to choose which model (Gemini/Codex) handles frontend and
backend tasks during init (Step 2/4) and via menu option 6. Gemini model
name is also configurable (e.g. gemini-2.5-flash). All 21 command
templates updated from hardcoded model names to template variables.

2026-03-31 14:20:01 +08:00

5.9 KiB

Raw Permalink Blame History

description

description
多模型性能优化：{{BACKEND_PRIMARY}} 后端优化 + {{FRONTEND_PRIMARY}} 前端优化

Optimize - 多模型性能优化

双模型并行分析性能瓶颈，按性价比排序优化建议。

使用方法

/optimize <优化目标>

上下文

优化目标：$ARGUMENTS
Codex 专注后端性能（数据库、算法、缓存）
Gemini 专注前端性能（渲染、加载、交互）

你的角色

你是性能工程师，编排多模型优化流程：

{{BACKEND_PRIMARY}} – 后端性能优化（后端权威）
{{FRONTEND_PRIMARY}} – 前端性能优化（前端权威）
Claude (自己) – 综合优化、实施变更

多模型调用规范

工作目录：

{{WORKDIR}}：必须通过 Bash 执行 pwd（Unix）或 cd（Windows CMD）获取当前工作目录的绝对路径，禁止从 $HOME 或环境变量推断
如果用户通过 /add-dir 添加了多个工作区，先用 Glob/Grep 确定任务相关的工作区
如果无法确定，用 AskUserQuestion 询问用户选择目标工作区

调用语法（并行用 run_in_background: true）：

Bash({
  command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--progress --backend <{{BACKEND_PRIMARY}}|{{FRONTEND_PRIMARY}}> {{GEMINI_MODEL_FLAG}}- \"{{WORKDIR}}\" <<'EOF'
ROLE_FILE: <角色提示词路径>
<TASK>
需求：<增强后的需求（如未增强则用 $ARGUMENTS）>
上下文：<目标代码、现有性能指标等>
</TASK>
OUTPUT: 性能瓶颈列表、优化方案、预期收益
EOF",
  run_in_background: true,
  timeout: 3600000,
  description: "简短描述"
})

角色提示词：

模型	提示词
Codex	`~/.claude/.ccg/prompts/codex/optimizer.md`
Gemini	`~/.claude/.ccg/prompts/gemini/optimizer.md`

并行调用：使用 run_in_background: true 启动，用 TaskOutput 等待结果。必须等所有模型返回后才能进入下一阶段。

等待后台任务（使用最大超时 600000ms = 10 分钟）：

TaskOutput({ task_id: "<task_id>", block: true, timeout: 600000 })

重要：

必须指定 timeout: 600000，否则默认只有 30 秒会导致提前超时。如果 10 分钟后仍未完成，继续用 TaskOutput 轮询，绝对不要 Kill 进程。
若因等待时间过长跳过了等待 TaskOutput 结果，则必须调用 AskUserQuestion 工具询问用户选择继续等待还是 Kill Task。禁止直接 Kill Task。
⛔ Gemini 失败必须重试：若 Gemini 调用失败（非零退出码或输出包含错误信息），最多重试 2 次（间隔 5 秒）。仅当 3 次全部失败时才跳过 Gemini 结果并使用单模型结果继续。
⛔ Codex 结果必须等待：Codex 执行时间较长（5-15 分钟）属于正常。TaskOutput 超时后必须继续用 TaskOutput 轮询，绝对禁止在 Codex 未返回结果时直接跳过或继续下一阶段。已启动的 Codex 任务若被跳过 = 浪费 token + 丢失结果。

沟通守则

在需要询问用户时，尽量使用 AskUserQuestion 工具进行交互，举例场景：请求用户确认/选择/批准

执行工作流

优化目标：$ARGUMENTS

🔍 阶段 0：Prompt 增强（可选）

[模式：准备] - Prompt 增强（按 /ccg:enhance 的逻辑执行）：分析 $ARGUMENTS 的意图、缺失信息、隐含假设，补全为结构化需求（明确目标、技术约束、范围边界、验收标准），用增强结果替代原始 $ARGUMENTS，后续调用 Codex/Gemini 时传入增强后的需求

🔍 阶段 1：性能基线

[模式：研究]

调用 {{MCP_SEARCH_TOOL}} 检索目标代码（如可用）
识别性能关键路径
收集现有指标（如有）

🔬 阶段 2：并行性能分析

[模式：分析]

⚠️ 必须发起两个并行 Bash 调用（参照上方调用规范）：

{{BACKEND_PRIMARY}} 后端分析：Bash({ command: "...--backend {{BACKEND_PRIMARY}}...", run_in_background: true })
- ROLE_FILE: ~/.claude/.ccg/prompts/codex/optimizer.md
- 需求：分析后端性能问题（$ARGUMENTS）
- OUTPUT：性能瓶颈列表、优化方案、预期收益
{{FRONTEND_PRIMARY}} 前端分析：Bash({ command: "...--backend {{FRONTEND_PRIMARY}}...", run_in_background: true })
- ROLE_FILE: ~/.claude/.ccg/prompts/gemini/optimizer.md
- 需求：分析前端性能问题（Core Web Vitals）
- OUTPUT：性能瓶颈列表、优化方案、预期收益

用 TaskOutput 等待两个模型的完整结果。必须等所有模型返回后才能进入下一阶段。

务必遵循上方 多模型调用规范 的 重要 指示

🔀 阶段 3：优化整合

[模式：计划]

收集双模型分析结果
优先级排序：按 影响程度 × 实施难度⁻¹ 计算性价比
请求用户确认优化方案

⚡ 阶段 4：实施优化

[模式：执行]

用户确认后按优先级实施，确保不破坏现有功能。

✅ 阶段 5：验证

[模式：评审]

运行测试验证功能，对比优化前后指标。

性能指标参考

类型	指标	良好	需优化
后端	API 响应	<100ms	>500ms
后端	数据库查询	<50ms	>200ms
前端	LCP	<2.5s	>4s
前端	FID	<100ms	>300ms
前端	CLS	<0.1	>0.25

常见优化模式

后端：N+1→批量加载、缺索引→复合索引、重复计算→缓存、同步→异步

前端：大 Bundle→代码分割、频繁重渲染→memo、大列表→虚拟滚动、未优化图片→WebP

关键规则

先测量后优化 – 没有数据不盲目优化
性价比优先 – 高影响 + 低难度优先
不破坏功能 – 优化不能引入 bug
信任规则 – 后端以 Codex 为准，前端以 Gemini 为准

5.9 KiB Raw Permalink Blame History Unescape Escape