人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek【免费下载链接】ccg-workflow多模型协作开发系统 - Claude 编排 Codex 后端 Gemini 前端28 个命令覆盖开发全流程一键安装零配置项目地址https://gitcode.com/fengshao1227/ccg-workflow点击查看免费下载导读optimize是 CCG Workflow 命令体系中的多模型性能优化命令它以「后端权威 前端权威」双专家并行分析为骨架让 Codex或配置中的后端主模型专注数据库、算法与缓存瓶颈让 Gemini或配置中的前端主模型专注渲染、加载与 Core Web Vitals最后由 Claude 综合排序并实施变更。读完本指南你将掌握/optimize的完整调用语法、六阶段执行工作流、并行 Bash 调用与 TaskOutput 等待规范以及「先测量后优化、性价比优先」的量化决策方法。一、命令定位与使用方式optimize属于命令模板目录templates/commands-legacy/optimize.md其 frontmatter 声明了命令本质多模型性能优化{{BACKEND_PRIMARY}}后端优化 {{FRONTEND_PRIMARY}}前端优化安装时由 CCG CLI 将模板变量替换为用户的实际模型配置见src/utils/installer-template.ts的injectConfigVariables()写入~/.claude/commands/后即可在 Claude Code 中以斜杠命令触发。调用语法/optimize 优化目标优化目标可以是任意性能诉求例如/optimize 用户列表接口 P95 延迟、/optimize 首页首屏加载时间、/optimize 数据导出任务内存占用。命令上下文上下文要素说明优化目标$ARGUMENTS用户在斜杠命令后传入的原文{{BACKEND_PRIMARY}}专注后端性能数据库、算法、缓存{{FRONTEND_PRIMARY}}专注前端性能渲染、加载、交互模板变量{{BACKEND_PRIMARY}}与{{FRONTEND_PRIMARY}}由安装器在安装期替换src/utils/installer-template.ts:84-93默认前端主模型为antigravity、后端主模型为codex用户可在ccg init的模型路由步骤中自定义。这一设计意味着同一份命令模板可服务于 Codex、Gemini、Grok、Kimi、Opencode 等任意主模型组合而无需维护多份命令文件。二、角色分工谁是性能权威执行/optimize时Claude 扮演性能工程师角色编排如下三角结构{{BACKEND_PRIMARY}}后端权威——后端性能优化如数据库查询、算法复杂度、缓存策略{{FRONTEND_PRIMARY}}前端权威——前端性能优化如渲染、加载、交互体验Claude自己——综合优化、实施变更两条「权威」的专业边界由独立角色提示词文件定义安装后被写入~/.claude/.ccg/prompts/下。仓库中可直接查看其设计模型角色提示词仓库源文件核心能力域后端Codextemplates/prompts/codex/optimizer.md数据库查询优化、算法复杂度分析、缓存策略、内存管理、异步处理模式、连接池、负载均衡考量前端Geminitemplates/prompts/gemini/optimizer.mdReact 渲染优化、Bundle 体积分析、代码分割、图片与静态资源优化、Core Web Vitals、网络性能两份提示词均强制两条铁律ZERO 文件系统写权限只读沙箱以及输出格式必须为「分析报告 Unified Diff Patch」——即优化专家只负责诊断与出补丁实际改动由具备写权限的 Claude 完成形成读写分离的职责边界。提示词还要求专家输出统一结构化的报告Response Structure先给Performance Analysis瓶颈表Issue / Impact / Difficulty / Expected Improvement再给按优先级排列的Optimization Plan最后是ImplementationUnified Diff Patch与Validation优化前/后指标与度量方法。这一结构正好与optimize命令阶段 3 的整合排序逻辑衔接。三、多模型调用规范并行 Bash TaskOutput 等待这是optimize命令最关键的工程细节两个专家模型必须并行发起、全部返回后才能进入下一阶段。3.1 工作目录约定{{WORKDIR}}必须通过 Bash 执行pwdUnix或cdWindows CMD获取当前工作目录的绝对路径禁止从$HOME或环境变量推断如果用户通过/add-dir添加了多个工作区先用 Glob/Grep 确定任务相关的工作区如果无法确定用AskUserQuestion工具询问用户选择目标工作区。3.2 并行调用语法run_in_background: trueBash({ command: ~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--progress --backend {{BACKEND_PRIMARY}}|{{FRONTEND_PRIMARY}} {{GEMINI_MODEL_FLAG}}{{GROK_MODEL_FLAG}}{{KIMI_MODEL_FLAG}}{{OPENCODE_MODEL_FLAG}}- \{{WORKDIR}}\ EOF ROLE_FILE: 角色提示词路径 TASK 需求增强后的需求如未增强则用 $ARGUMENTS 上下文目标代码、现有性能指标等 /TASK OUTPUT: 性能瓶颈列表、优化方案、预期收益 EOF, run_in_background: true, timeout: 3600000, description: 简短描述 })对上述命令作逐段拆解便于理解每个占位符在安装期的落点片段含义~/.claude/bin/codeagent-wrapper模型执行包装器由src/utils/installer.ts下载安装Windows 上为codeagent-wrapper.exe{{LITE_MODE_FLAG}}轻量模式标志--lite仅在用户选择 lite 性能模式时注入src/utils/installer-template.ts:220-223--progress启用进度输出供调用方感知后台任务进展codeagent-wrapper/config.go:326-328解析该标志--backend 模型指定执行后端模型由codeagent-wrapper/config.go:234-246解析缺值时报错--backend flag requires a value{{GEMINI_MODEL_FLAG}}等模型型号标志--gemini-model xxx、--grok-model xxx、--kimi-model xxx、--opencode-model xxx安装器按行感知替换若某行硬编码了非 gemini/grok/kimi/opencode 后端则剥离该标志避免输出无效 flagsrc/utils/installer-template.ts:103-218-从 stdin 读取任务描述{{WORKDIR}}工作目录绝对路径ROLE_FILE:角色提示词路径指向~/.claude/.ccg/prompts/模型/optimizer.md3.3 等待后台任务TaskOutputTaskOutput({ task_id: task_id, block: true, timeout: 600000 })timeout必须指定为 600000ms10 分钟否则默认只有 30 秒会导致提前超时。四、执行工作流六阶段0-5完整拆解/optimize的执行过程划分为 6 个阶段每一阶段对应一种 Claude Code 模式阶段 0Prompt 增强可选模式准备按/ccg:enhance的逻辑执行分析$ARGUMENTS的意图、缺失信息、隐含假设补全为结构化需求明确目标、技术约束、范围边界、验收标准。用增强结果替代原始$ARGUMENTS后续调用后端/前端模型时传入增强后的需求。阶段 1性能基线模式研究调用{{MCP_SEARCH_TOOL}}检索目标代码如可用识别性能关键路径收集现有指标如有。{{MCP_SEARCH_TOOL}}占位符由安装器按 MCP provider 注册表替换src/utils/installer-template.ts:50-55, 225-243默认ace-tool映射为mcp__ace-tool__search_context可选ace-tool-rs、contextweaver、fast-context若选择skip未配置 MCP则降级为Glob 定位文件 Grep 搜索关键符号 Read 读取文件内容。阶段 2并行性能分析模式分析⚠️ 必须发起两个并行 Bash 调用参照第三节调用规范{{BACKEND_PRIMARY}}后端分析ROLE_FILE~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/optimizer.md需求分析后端性能问题$ARGUMENTSOUTPUT性能瓶颈列表、优化方案、预期收益{{FRONTEND_PRIMARY}}前端分析ROLE_FILE~/.claude/.ccg/prompts/{{FRONTEND_PRIMARY}}/optimizer.md需求分析前端性能问题Core Web VitalsOUTPUT性能瓶颈列表、优化方案、预期收益用TaskOutput等待两个模型的完整结果必须等所有模型返回后才能进入下一阶段。阶段 3优化整合模式计划收集双模型分析结果优先级排序按影响程度 × 实施难度⁻¹计算性价比请求用户确认优化方案。阶段 4实施优化模式执行用户确认后按优先级实施确保不破坏现有功能。此阶段由具备写权限的 Claude 完成——两个专家模型在只读沙箱中只输出分析报告与 Unified Diff Patch实际代码改动由 Claude 落地。阶段 5验证模式评审运行测试验证功能对比优化前后指标。五、性能指标参考基准命令内置了可直接套用的量化基准良好/需优化阈值类型指标良好需优化后端API 响应100ms500ms后端数据库查询50ms200ms前端LCP2.5s4s前端FID100ms300ms前端CLS0.10.25前端三项正是 Core Web Vitals 官方阈值体系与 Gemini 前端专家提示词中的Core Web Vitals Targets表LCP 2.5s / FID 100ms / CLS 0.1 为 Good完全一致templates/prompts/gemini/optimizer.md说明命令内置基准与角色专家遵循同一度量口径。六、常见优化模式速查命令模板内置两类高频优化模式清单后端N1 → 批量加载、缺索引 → 复合索引、重复计算 → 缓存、同步 → 异步前端大 Bundle → 代码分割、频繁重渲染 → memo、大列表 → 虚拟滚动、未优化图片 → WebP这与两个专家角色提示词的Analysis Framework一一对应——Codex 优化器会从「数据库查询N1、缺索引、慢查询、算法低效O(n²) vs O(n log n)、内存泄漏、阻塞 I/O、多余网络调用」五条线定位瓶颈并给出 EXPLAIN 分析、索引建议、连接池、读副本、Redis/Memcached 缓存、异步队列、CDN、水平扩展等策略Gemini 优化器则从「渲染性能多余重渲染、缺失 memo、渲染期重计算、列表虚拟化、Bundle 优化代码分割、路由/弹窗动态导入、Tree shaking、大依赖分析、加载性能懒加载、WebPsrcset、字体 swap/preload、关键 CSS 提取、运行时性能事件处理、防抖节流、Web Worker、CSS vs JS 动画」四个维度展开。七、关键规则与失败处理命令内置四条不可违背的规则先测量后优化—— 没有数据不盲目优化性价比优先—— 高影响 低难度优先不破坏功能—— 优化不能引入 bug信任规则—— 后端以{{BACKEND_PRIMARY}}为准前端以{{FRONTEND_PRIMARY}}为准。以及两条针对模型失败/超时的硬性约束命令中的「重要」指示⛔ 前端模型失败必须重试若前端模型调用失败非零退出码或输出包含错误信息最多重试 2 次间隔 5 秒。仅当 3 次全部失败时才跳过前端模型结果并使用单模型结果继续。⛔ 后端模型结果必须等待后端模型执行时间较长5-15 分钟属于正常。TaskOutput 超时后必须继续用 TaskOutput 轮询绝对禁止在后端模型未返回结果时直接跳过或继续下一阶段。已启动的后端任务若被跳过 浪费 token 丢失结果。若因等待时间过长跳过了等待 TaskOutput 结果则必须调用AskUserQuestion工具询问用户选择继续等待还是 Kill Task禁止直接 Kill Task。沟通守则方面命令要求在需要询问用户时请求用户确认/选择/批准尽量使用AskUserQuestion工具进行交互。八、与底层引擎的呼应度量驱动优化策略optimize命令的「先测量后优化」哲学在仓库引擎层有对应的策略实现——templates/engine/strategies/optimize-measure.md度量驱动优化。命令表 templates/commands/go.md 将optimize及 performance、optimize、speed、slow、优化、性能、latency、慢 等关键词映射到该策略。策略定义了四阶段状态机与/optimize的阶段 1-5 互为印证策略阶段对应命令阶段核心要求Phase 1 性能基线阶段 1确定指标 → 运行基线测试time/benchmark/profiler→ 记录具体数值Phase 2 瓶颈分析阶段 2M 复杂度时可调用 backend/frontend 模型的 optimizer 角色按影响排序Phase 3 针对性优化阶段 4一次只优化一个瓶颈便于归因效果Phase 4 优化后度量阶段 5用与 Phase 1完全相同的方式重新度量对比基线输出提升百分比策略还补充了命令模板未展开的三条铁律可作为实施优化时的方法论补全不可在没有基线的情况下优化Phase 1 不可跳过优化前后必须有数据对比Phase 4 不可跳过效果不明显必须回退——不可保留无效的「优化」。若效果不明显应回退该优化并尝试下一个瓶颈形成 Phase 2-4 的迭代循环。九、实现原理小结模板变量如何变为真实命令最后从源码角度串起整条链路。/optimize之所以能实现「一套模板、多模型通用」核心在于安装期变量替换机制安装npx ccg-workflow init运行时src/utils/installer.ts的installWorkflows()将templates/commands-legacy/optimize.md拷贝至~/.claude/commands/替换src/utils/installer-template.ts的injectConfigVariables()完成{{BACKEND_PRIMARY}}、{{FRONTEND_PRIMARY}}、{{LITE_MODE_FLAG}}、{{GEMINI_MODEL_FLAG}}、{{MCP_SEARCH_TOOL}}等占位符替换路径落地replaceHomePathsInTemplate()将~/.claude/bin/codeagent-wrapper替换为绝对路径Windows 追加.exe统一使用/分隔符执行运行时由包装器codeagent-wrappercodeagent-wrapper/config.go 的parseArgs()解析--backend、--lite、--progress及各模型型号 flag将 stdin 任务分发给指定后端模型并在~/.claude/.ccg/prompts/模型/optimizer.md角色提示词的约束下输出瓶颈分析与优化补丁。至此一次「双模型并行诊断 → 性价比排序 → Claude 实施 → 前后对比验证」的性能优化闭环即可完整跑通。关键规则速查表#规则说明1先测量后优化没有数据不盲目优化2性价比优先高影响 低难度优先3不破坏功能优化不能引入 bug4信任规则后端以 BACKEND_PRIMARY 为准前端以 FRONTEND_PRIMARY 为准5前端失败重试最多重试 2 次间隔 5 秒3 次全败才降级为单模型6后端必须等待后端 5-15 分钟属正常禁止跳过未返回的后端任务7禁止直接 Kill跳过等待时必须用 AskUserQuestion 询问用户赞分享人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek【免费下载链接】ccg-workflow多模型协作开发系统 - Claude 编排 Codex 后端 Gemini 前端28 个命令覆盖开发全流程一键安装零配置项目地址https://gitcode.com/fengshao1227/ccg-workflow点击查看免费下载相关推荐ccg-workflow 多模型协作开发工作流实战Claude 编排 Codex/Gemini 六阶段研发管线/workflow 命令全解析ccg workflow 多模型协作开发工作流实战Claude 编排 Codex/Gemini 六阶段研发管线/workflow 命令全解析 导读 /人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeekccg-workflow 前端专项工作流全解析多模型编排的 /frontend 命令从研究到评审实战指南ccg workflow 前端专项工作流全解析多模型编排的 /frontend 命令从研究到评审实战指南 在 ccg workflow 多模型协作开发体系中人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeekccg-workflow 多模型编排实战Codex 主控 Agent 的决策框架、任务持久化与并行实施协议ccg workflow 多模型编排实战Codex 主控 Agent 的决策框架、任务持久化与并行实施协议 ccg workflow 是一个以Claude人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek上一篇【亲测免费】 Terser 项目使用教程下一篇DeskHop快速桌面切换神器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考