ECC `/multi-frontend` 命令实战：前端多模型编排工作流（研究 → 构思 → 计划 → 执行 → 优化 → 评审）

本文以 docs/es/commands/multi-frontend.md 为主体，详解 ECC（The agent harness performance optimization system）中 /multi-frontend 命令的完整工作流：它如何以 Gemini 为前端权威、Codex 为辅助参考、Claude 负责编排与写盘，围绕"组件设计、响应式布局、UI 动画、样式优化"组织一次六阶段多模型协作开发。读完本文，你能掌握该命令的调用方式、各阶段职责划分、会话复用机制，以及"外部模型零写权限"这一安全边界的设计依据。

命令定位与调用方式

/multi-frontend 是 ECC 命令集中专门面向前端场景的多模型编排命令。在 docs/COMMAND-REGISTRY.json 中它被登记为 type: orchestration，描述为 "Run a frontend-focused multi-model workflow for components, layouts, animation, and UI polish"（针对组件、布局、动画与 UI 打磨的前端多模型工作流），对应实现文件为 commands/multi-frontend.md。

基本用法：

/frontend <UI 任务描述>

任务描述会绑定到工作流的 $ARGUMENTS 变量，贯穿后续所有阶段。适用场景包括：

• 组件设计（diseño de componentes）
• 响应式布局（layout responsivo）
• UI 动画（animaciones de UI）
• 样式优化（optimización de estilos）

前置条件：ccg-workflow 运行时

该命令属于 ECC 的 multi-* 系列，基础安装并不包含其运行依赖。英文版命令文档 commands/multi-frontend.md 与 README.md 均明确说明：

• 需要先执行 npx ccg-workflow 初始化外部运行时；
• 该运行时会供给 ~/.claude/bin/codeagent-wrapper 可执行文件与 ~/.claude/.ccg/prompts/* 角色提示文件，这两者正是命令内部跨模型调用所依赖的外部资源；
• 缺少该运行时时，multi-* 命令无法正确运行。

COMMANDS-QUICK-REF.md 将 /multi-frontend 归入 "Planning & Architecture" 分区，与 /multi-plan、/multi-workflow、/multi-backend、/multi-execute 并列，可视为同一编排家族的"前端特化"成员。

角色分工：三个模型如何协作

文档定义了明确的"前端编排者"（Orquestador Frontend）角色，Claude 自身承担编排职责，并管理三个协作模型之间的信任边界：

模型	角色	信任级别
Gemini	UI/UX 前端	前端权威，观点可信（Autoridad frontend, confiable）
Codex	后端视角	前端相关观点仅供参考（solo como referencia）
Claude（自身）	编排、计划、执行、交付	所有代码写入与文件操作由 Claude 完成

这种"权威分级"是该命令的核心设计：当 Gemini 与 Codex 在前端问题上意见冲突时，以 Gemini 为准；Codex 的价值主要在于后端视角（如接口契约、数据流）对前端方案的补充。

六阶段主工作流

整个流程严格遵循固定顺序：Investigación → Ideación → Plan → Ejecución → Optimización → Revisión，每个阶段的回复必须以模式标签开头（如 [Modo: Investigación]），便于追踪当前所处环节。

阶段 0：提示词增强（可选）

[Modo: Preparar] — 若 ace-tool MCP 可用，则调用 mcp__ace-tool__enhance_prompt 对 $ARGUMENTS 做增强；不可用时直接沿用原始参数。

对照英文版命令 commands/multi-frontend.md，这里有一个值得注意的细节：增强后的结果会替换原始的 $ARGUMENTS，用于后续所有对外部模型的调用，保证下游各阶段拿到的是同一份高质量需求描述。

阶段 1：研究（Investigación）

[Modo: Investigación] — 理解需求并收集上下文，包含两步：

1. 代码检索：拉取项目中已存在的组件、样式与设计系统（design system）。英文版命令给出了具体实现路径——若 ace-tool MCP 可用则调用 mcp__ace-tool__search_context；否则使用内置工具组合：Glob 做文件发现、Grep 做组件/样式搜索、Read 做上下文收集、Task（Explore 代理）做深度探索；
2. 需求完整度评分（0–10 分）：得分 ≥7 才继续推进；<7 则必须停下向用户补充信息。

这道"完整度闸门"防止在需求模糊时贸然进入设计阶段，是整个工作流的第一道质量防线。

阶段 2：构思（Ideación）

[Modo: Ideación] — 由 Gemini 主导的分析环节，必须调用 Gemini，要求产出：

• UI 可行性分析
• 至少 2 个推荐解决方案
• UX 评估

关键约束：保存返回的 SESSION_ID（记为 GEMINI_SESSION）供后续阶段复用。文档明确要求向用户呈现至少 2 个方案，并等待用户选择后才进入下一阶段。

阶段 3：计划（Plan）

[Modo: Plan] — 仍由 Gemini 主导，但改用 resume <GEMINI_SESSION> 复用阶段 2 的会话，避免重复传递上下文。要求产出：

• 组件结构（Estructura de componentes）
• UI 流程（flujo de UI）
• 样式方案（enfoque de estilos）

Claude 负责综合（synthesis）各模型输出形成最终计划，经用户批准后保存到 .claude/plan/nombre-tarea.md。这形成了"外部模型出分析、Claude 出计划、用户出批准"的三方确认链。

阶段 4：执行（Ejecución）

[Modo: Ejecutar] — 代码开发阶段，三条硬性要求：

• 严格遵循已批准的计划；
• 遵循项目既有的设计系统与代码标准；
• 确保响应式（responsividad）与可访问性（accesibilidad）。

注意：本阶段不要求再调用外部模型，写盘工作全部由 Claude 完成。

阶段 5：优化（Optimización）

[Modo: Optimizar] — 再次必须调用 Gemini，输入是阶段 4 的改动（git diff 或代码内容），要求输出四类问题的清单：

• 可访问性问题
• 响应式问题
• 性能问题
• 设计一致性问题

整合评审反馈后，需用户确认才执行优化改动。

阶段 6：质量评审（Revisión）

[Modo: Revisión] — 最终评估，对照批准的计划逐项检查完成度，再次核验响应式与可访问性，并输出问题与改进建议报告。

跨模型调用规范与会话复用

西语文档以"保存 SESSION_ID、后续 resume"的方式描述了会话机制，而英文版 commands/multi-frontend.md 给出了完整的调用协议，两者互为印证：

新会话调用语法：

Bash({
  command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend antigravity - \"$PWD\" <<'EOF'
ROLE_FILE: <角色提示路径>
<TASK>
Requirement: <增强后的需求（未增强时为 $ARGUMENTS）>
Context: <项目上下文与前序阶段分析结果>
</TASK>
OUTPUT: 期望的输出格式
EOF",
  run_in_background: false,
  timeout: 3600000,
  description: "简要描述"
})

会话续接调用只需在命令中插入 resume <SESSION_ID>：

~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend antigravity resume <SESSION_ID> - "$PWD" <<'EOF'
ROLE_FILE: <角色提示路径>
...（同上）
EOF

协议要点：

要素	说明
ROLE_FILE	按阶段选取的角色提示文件，存放于 ~/.claude/.ccg/prompts/ 下
每次调用返回	SESSION_ID: xxx，后续阶段用 resume xxx 复用
保存变量	阶段 2 保存 ANTIGRAVITY_SESSION，阶段 3、5 使用 resume
超时	timeout: 3600000（毫秒），前台同步执行（run_in_background: false）

需要说明的是：西语文档（Gemini 主导）与英文源命令（Antigravity 主导）在"权威模型"命名上存在版本差异——docs/es/commands/multi-frontend.md 使用 GEMINI_SESSION 变量与 Gemini 后端，英文源命令则使用 ANTIGRAVITY_SESSION 与 antigravity 后端；两者共享同一套"调用 → 保存会话 ID → resume 复用"的会话协议。以当前仓库中西语文档的实际文字为准，会话变量名为 GEMINI_SESSION。

关键规则：外部模型的写权限为零

文档末尾的 "Reglas Clave" 是整套工作流的安全基石，共四条：

1. Gemini 的前端观点可信（Las opiniones frontend de Gemini son confiables）；
2. Codex 的前端观点仅供参考（solo de referencia）；
3. 外部模型对文件系统拥有零写入权限（cero acceso de escritura al sistema de archivos）；
4. Claude 负责所有代码写入与文件操作。

从源码结构看，这一约束与 multi-* 家族的定位一致：docs/COMMAND-REGISTRY.json 中 /multi-execute 的描述明确写着 "preserving Claude as the only filesystem writer"（保持 Claude 为唯一文件系统写入者）。外部模型（无论 Gemini 还是 Codex）通过 codeagent-wrapper 以"咨询者"身份接入，只产出分析与建议；所有落盘动作——修改组件、调整样式、写入计划文件 .claude/plan/nombre-tarea.md——都由 Claude 在本地完成。这一设计使得多模型协作不引入额外的写入副作用，任何阶段出错都可以安全回滚。

与其他多模型命令的关系

/multi-frontend 不是孤立命令，而是 ECC 多模型编排矩阵中按"关注面"切分的一个特化入口：

• /multi-plan：只做多模型协作规划，不改动生产代码（multi-plan 在注册表中还关联了 accessibility 技能）；
• /multi-execute：执行多模型实现计划，同样保持 Claude 为唯一写盘者；
• /multi-backend：后端侧特化版本；
• /multi-workflow：覆盖研究、规划、执行、优化、评审的完整多模型开发流。

选型建议：如果你只需要一份前端实现计划而不想动代码，用 /multi-plan；如果任务是明确的前端 UI 工作（组件、布局、动画、样式打磨），/multi-frontend 提供了最贴切的阶段划分与模型信任分级。

总结

ECC 的 /multi-frontend 命令把"多模型协作"落成了可复制的确定性流程：需求完整度打分决定是否开工，Gemini 作为前端权威主导构思/计划/优化三个环节，会话 ID 复用减少上下文重复传递，用户选择与批准作为阶段间的显式闸门，而"外部模型零写权限 + Claude 统一写盘"的规则保证了协作过程的安全与可回滚。配合 ccg-workflow 运行时（npx ccg-workflow）与 codeagent-wrapper 调用协议，这套流程可以直接用于组件设计、响应式布局、UI 动画与样式优化等前端任务。