企业官网建设流程全解析

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

【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC

本文基于 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 任务的多模型协作。三方模型的权责划分是整套范式的核心：

这一分工与后端版 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:字段传入：

这些路径在安装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-toolMCP 可用，调用mcp__ace-tool__enhance_prompt增强用户原始需求$ARGUMENTS，并用增强结果替换后续所有 Gemini 调用的 Requirement；若 MCP 不可用，则直接使用$ARGUMENTS。

Phase 1：调查（Research）

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

1. 代码获取：若ace-toolMCP 可用，调用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生成.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任务描述>即开即用。

【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC