ECC `/frontend` 命令实战：Gemini 主导的前端多模型协作开发工作流

本文基于 ECC 仓库中的 docs/ja-JP/commands/multi-frontend.md 及其英文原版 commands/multi-frontend.md 编写，系统讲解 /frontend（多模型前端）命令的完整使用方式。该命令在 ECC 中属于 multi-* 系列的多模型协作命令，用于以"前端中心"的视角完成 UI/UX 任务，工作流为 Research（调查）→ Ideation（点子创出）→ Plan（计划）→ Execute（实现）→ Optimize（优化）→ Review（评审），由 Gemini 主导前端决策，Claude 负责编排与全部文件写入。读完本文你将掌握：如何安装其依赖的 ccg-workflow 运行时、如何按规范调用外部模型、如何驱动 7 个阶段的完整工作流，以及这套协作范式的信任边界与安全规则。

一、命令定位：前端中心的多模型协作范式

在 ECC 的 multi-* 命令家族中，/frontend 承担的是"前端专项"角色。与面向服务端任务的 multi-backend.md（Codex 主导）、面向全栈的 multi-workflow.md 相比，/frontend 将权威决策权交给 Gemini（日语版文档）或 Antigravity（英文版文档），而 Codex 仅以"后端视角"提供参考意见。

该命令的适用场景非常聚焦，原文档明确列出：

• 组件设计（Component design）
• 响应式布局（Responsive layout）
• UI 动画（UI animations）
• 样式优化（Style optimization）

在 COMMANDS-QUICK-REF.md 中，/multi-frontend 被描述为 "Frontend-focused multi-model development"（前端聚焦的多模型开发），与 /multi-plan（多模型协作规划）、/multi-backend（后端聚焦）、/multi-execute（多模型协作执行）并列，共同构成 ECC 的多模型开发能力矩阵。

版本差异提示：仓库同时维护了英文版与多语言版（日文、中文、土耳其文等）的命令文档。英文原版 commands/multi-frontend.md 以 Antigravity 作为前端权威模型（调用参数为 --backend antigravity），而日语版 docs/ja-JP/commands/multi-frontend.md 使用 Gemini（调用参数为 --backend gemini --gemini-model gemini-3-pro-preview）。本文以日语版为准展开，并在涉及调用参数处同步标注英文版的差异。

二、前置条件：安装 ccg-workflow 运行时

/frontend 命令依赖外部 ccg-workflow 运行时，该运行时不包含在 ECC 基础安装中。 这一点在命令文档的开头以醒目方式强调，并在 README.md 中有对应说明：multi-* 命令不包含在基础 plugin/rules 安装中，若要使用 /multi-plan、/multi-execute、/multi-backend、/multi-frontend 和 /multi-workflow，必须额外安装 ccg-workflow 运行时。

安装命令：

npx ccg-workflow

该运行时负责供给命令所依赖的外部组件，包括：

• ~/.claude/bin/codeagent-wrapper —— 命令脚本中实际被调用的包装器可执行文件；
• ~/.claude/.ccg/prompts/* —— 供各阶段使用的角色提示词（role prompt）文件。

注意：如果未安装 ccg-workflow，这些 multi-* 命令将无法正常运行（原文档明确写道 "Without that runtime, this command will not run correctly"）。

三、使用方法与上下文注入

/frontend <UIタスクの説明>

$ARGUMENTS 即用户在斜杠命令后输入的任务描述。命令内部通过以下上下文变量理解任务：

• Frontend task: $ARGUMENTS
• 主导模型: Gemini 主导，Codex 作为辅助参考（Gemini主導、Codexは補助的な参照用）
• 适用范围: 组件设计、响应式布局、UI 动画、样式优化

四、角色分工：前端编排者与三方协作模型

/frontend 命令要求你扮演 前端编排者（Frontend Orchestrator），协调 UI/UX 任务的多模型协作。三方模型的权责划分是整套范式的核心：

模型	定位	话语权
Gemini	前端 UI/UX	前端权威，可信赖（前端の権威、信頼できる）
Codex	后端视角	前端意见仅供参考（フロントエンドの意見は参考のみ）
Claude（自身）	编排、计划、实现、交付	唯一的文件系统写入者

这一分工与后端版 multi-backend.md 形成镜像：后端任务中 Codex 是权威、Gemini 仅供参考。其设计意图是"专业的事交给专业的模型"，同时通过"外部模型零写入权限"来保证代码主权（Code Sovereignty）——外部模型只能产出分析和建议，所有实际代码写入与文件操作都由 Claude 完成。

五、多模型调用规范

5.1 调用语法

所有对外部模型的调用统一通过 codeagent-wrapper 发起，以 Bash 工具包装。日语版文档给出了两种调用形态：

新会话调用（New session call）：

Bash({
  command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend gemini --gemini-model gemini-3-pro-preview - \"$PWD\" <<'EOF'
ROLE_FILE: <ロールプロンプトパス>
<TASK>
Requirement: <強化された要件(または強化されていない場合は$ARGUMENTS)>
Context: <前のフェーズからのプロジェクトコンテキストと分析>
</TASK>
OUTPUT: 期待される出力形式
EOF",
  run_in_background: false,
  timeout: 3600000,
  description: "簡潔な説明"
})

会话恢复调用（Resume session call）：

Bash({
  command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend gemini --gemini-model gemini-3-pro-preview resume <SESSION_ID> - \"$PWD\" <<'EOF'
ROLE_FILE: <ロールプロンプトパス>
<TASK>
Requirement: <強化された要件(または強化されていない場合は$ARGUMENTS)>
Context: <前のフェーズからのプロジェクトコンテキストと分析>
</TASK>
OUTPUT: 期待される出力形式
EOF",
  run_in_background: false,
  timeout: 3600000,
  description: "簡潔な説明"
})

调用要点解析：

• {{LITE_MODE_FLAG}}：可替换的轻量模式标记。参照同系列日语文档 docs/ja-JP/commands/multi-plan.md 与 docs/ja-JP/commands/multi-execute.md 的说明，使用 --backend gemini 时需附加 --gemini-model gemini-3-pro-preview（注意保留参数末尾的空格）；若使用 --backend codex 则为空字符串。
• - "$PWD"：- 表示从 stdin 读取任务，"$PWD" 传入当前项目目录作为工作目录。
• timeout: 3600000：即 1 小时（毫秒）。注意此处的调用是前台串行（run_in_background: false），因为前端工作流的阶段之间依赖前序输出。
• Heredoc（<<'EOF'）：任务内容、角色文件路径、期望输出格式全部通过 heredoc 传入，'EOF' 单引号防止 shell 展开。

英文版 commands/multi-frontend.md 的差异在于后端参数为 --backend antigravity，无 --gemini-model 附加项。

5.2 角色提示词（Role Prompts）

每个阶段为 Gemini 指定不同的角色提示词文件，由 ROLE_FILE: 字段传入：

阶段	Gemini 角色提示词路径
分析（Analysis）	~/.claude/.ccg/prompts/gemini/analyzer.md
计划（Planning）	~/.claude/.ccg/prompts/gemini/architect.md
评审（Review）	~/.claude/.ccg/prompts/gemini/reviewer.md

这些路径在安装 ccg-workflow 时由运行时供给（见 README.md）。英文版对应的目录为 ~/.claude/.ccg/prompts/antigravity/。

5.3 会话复用（Session Reuse）

每次调用都会返回 SESSION_ID: xxx。为了让后续阶段延续同一上下文（避免重复描述需求与背景），必须：

1. 在**第 2 阶段（点子创出）**保存返回的 SESSION_ID 为 GEMINI_SESSION；
2. 在**第 3 阶段（计划）与第 5 阶段（优化）**使用 resume xxx 恢复会话。

注意恢复语法是 resume <SESSION_ID> 子命令（英文版 multi-workflow.md 特别强调是 resume 而非 --resume）。

六、沟通指南（Communication Guidelines）

编排者与用户、模型之间的交互需遵守三条约定：

1. 模式标签：每次响应以 [Mode: X] 开头，初始为 [Mode: Research]；
2. 严格顺序：必须遵循 Research → Ideation → Plan → Execute → Optimize → Review，不可跳序；
3. 用户交互：在需要确认、选择、批准时，使用 AskUserQuestion 工具与用户交互。

七、核心工作流：7 个阶段详解

Phase 0：提示词增强（可选）

[Mode: Prepare] —— 若 ace-tool MCP 可用，调用 mcp__ace-tool__enhance_prompt 增强用户原始需求 $ARGUMENTS，并用增强结果替换后续所有 Gemini 调用的 Requirement；若 MCP 不可用，则直接使用 $ARGUMENTS。

Phase 1：调查（Research）

[Mode: Research] —— 理解需求、收集上下文：

1. 代码获取：若 ace-tool MCP 可用，调用 mcp__ace-tool__search_context 检索现有组件、样式与设计系统；否则回退到内置工具：Glob 查找文件、Grep 搜索组件/样式、Read 收集上下文、Task（Explore 子代理）做深层探索。
2. 需求完整度评分（0-10）：评分 ≥ 7 则继续，< 7 则停止并让用户补充信息。这一"止损机制"与 multi-execute.md 中的 Stop-Loss Mechanism 一脉相承——当前阶段产出未验证前不进入下一阶段。

Phase 2：点子创出（Ideation）

[Mode: Ideation] —— 必须调用 Gemini，按前述调用规范执行：

• ROLE_FILE: ~/.claude/.ccg/prompts/gemini/analyzer.md
• Requirement: 增强后的需求（未增强则为 $ARGUMENTS）
• Context: Phase 1 收集的项目上下文
• OUTPUT: UI 可行性分析、推荐方案（至少 2 个）、UX 评估

同时保存返回的 SESSION_ID 为 GEMINI_SESSION 供后续复用。最后向用户输出至少 2 个候选方案，等待用户选择后才进入下一阶段。

Phase 3：计划（Plan）

[Mode: Plan] —— 必须调用 Gemini，使用 resume <GEMINI_SESSION> 复用 Phase 2 的会话：

• ROLE_FILE: ~/.claude/.ccg/prompts/gemini/architect.md
• Requirement: 用户选定的方案
• Context: Phase 2 的分析结果
• OUTPUT: 组件结构、UI 流程、样式方案

Claude 负责整合计划，在用户批准后保存到 .claude/plan/task-name.md。这一计划文件正是 multi-execute.md 中 /ccg:execute .claude/plan/xxx.md 的执行输入。

Phase 4：实现（Execute）

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

• 严格遵循已批准的计划；
• 遵循既有项目的设计系统与代码标准；
• 保证响应式（responsive）与无障碍（accessibility）。

此阶段全部由 Claude 执行写入，Gemini 无文件系统访问权。

Phase 5：优化（Optimize）

[Mode: Optimize] —— 必须调用 Gemini（按调用规范），使用 reviewer.md 角色：

• Requirement: 评审以下前端代码变更
• Context: git diff 或代码内容
• OUTPUT: 无障碍、响应式、性能、设计一致性问题清单

Claude 整合评审反馈，在用户确认后执行优化。

Phase 6：质量评审（Review）

[Mode: Review] —— 最终评估：

• 对照计划检查完成度；
• 验证响应式与无障碍；
• 报告问题与改进建议。

八、关键规则（Key Rules）

原文档在结尾处以四条规则收束整个协作范式，这是确保多模型协作不失控的底线：

1. Gemini 的前端意见可信（Geminiのフロントエンド意見は信頼できる）——前端事务以 Gemini 为准；
2. Codex 的前端意见仅供参考（Codexのフロントエンド意見は参考のみ）——Codex 的后端视角不能否决前端决策；
3. 外部模型零文件系统写入权限（外部モデルはファイルシステムへの書き込みアクセスがゼロ）——安全边界；
4. Claude 处理所有代码写入与文件操作——编排者即代码主权者。

同样的规则在后端版 multi-backend.md（Codex 后端意见可信、Gemini 后端意见仅供参考）与全栈版 multi-workflow.md（Backend follows Codex, Frontend follows Antigravity）中以镜像形式出现，构成了 ECC 多模型协作的通用信任模型（Trust Rules）。

九、与 multi-* 系列其他命令的配合

/frontend 并非孤立存在。在 ECC 的多模型体系中，命令之间有明确的分工与衔接：

命令	职责	主导模型
/multi-plan	多模型协作规划（只规划、不写业务代码）	Codex + Gemini/Antigravity 并行分析
/multi-frontend	前端中心开发（本文）	Gemini（前端权威）
/multi-backend	后端中心开发	Codex（后端权威）
/multi-execute	多模型协作执行（读计划 → 原型 → 重构 → 审计）	按任务类型路由
/multi-workflow	全栈多模型协作工作流	智能路由：前端→前端模型，后端→Codex

典型的端到端路径是：/multi-plan 生成 .claude/plan/*.md 与 SESSION_ID → 用户确认 → /multi-execute 读取计划并复用会话执行实现。而 /frontend 则适用于"任务已明确是前端 UI"的场景，直接驱动 Gemini 完成从调查到评审的全流程。相关命令清单可见 COMMANDS-QUICK-REF.md，multi-* 命令的安装依赖说明见 README.md。

十、总结

/frontend 命令将"前端专业模型主导 + 后端模型参考 + 编排者唯一写权限"的三方协作范式封装为一条可复用的斜杠命令。它的价值体现在三个层面：专业性——UI/UX 决策交给前端权威模型，避免通用模型的平庸设计；可控性——外部模型零写入权限、Claude 全权负责文件操作，从机制上杜绝了多模型协作中的意外改动；连续性——通过 SESSION_ID 会话复用，让调查、计划、优化各阶段共享上下文，无需重复描述需求。对于需要在 Claude Code 中完成组件设计、响应式布局、UI 动画与样式优化的开发者，在确保已通过 npx ccg-workflow 完成运行时安装的前提下，/frontend <UI任务描述> 即开即用。