人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek【免费下载链接】ccg-workflow多模型协作开发系统 - Claude 编排 Codex 后端 Gemini 前端28 个命令覆盖开发全流程一键安装零配置项目地址https://gitcode.com/fengshao1227/ccg-workflow点击查看免费下载本文聚焦 ccg-workflow 多模型协作开发系统中的Agent Teams 需求研究命令/ccg:team-research完整剖析其并行探索代码库 → 聚合约束集 → 消解歧义 → 落地研究文件的执行流程并结合仓库源码讲解底层codeagent-wrapper的参数机制。读完本文你将掌握研究阶段Research在 8 阶段团队流水线中的定位、约束集驱动后续零决策规划的设计哲学以及如何在 Claude 中手工复现这条双模型并行探索链路。命令定位研究是 8 阶段流水线的第二环在 ccg-workflow 的 Agent Teams 统一工作流中见 templates/commands-legacy/team.md完整流水线被划分为 8 个阶段Phase 0: PRE-FLIGHT → 环境检测 Phase 1: REQUIREMENT → Lead 需求增强 → mini-PRD Phase 2: ARCHITECTURE → 后端模型∥前端模型 分析 Architect teammate 出蓝图 Phase 3: PLANNING → Lead 拆任务 → 零决策并行计划 Phase 4: DEVELOPMENT → Dev×N teammates 并行编码 Phase 5: TESTING → QA teammate 写测试跑测试 Phase 6: REVIEW → 后端模型∥前端模型 审查 Reviewer teammate 综合判决 Phase 7: FIX → Dev teammate(s) 修复 Critical最多 2 轮 Phase 8: INTEGRATION → Lead 全量验证 报告 清理/ccg:team-research是这一体系中的研究Research阶段专用命令位于需求增强之后、架构与规划之前。它的上游产物是增强后的结构化需求下游产物是写入.claude/team-plan/任务名-research.md的约束集与成功判据供/ccg:team-plantemplates/commands-legacy/team-plan.md直接消费。核心哲学研究产出的是约束集不是信息堆砌team-research.md开篇即点明该命令的设计出发点这是理解整条工作流的关键研究产出的是约束集constraint sets不是信息堆砌。每一条约束都在缩小解决方案空间narrow the solution space。约束告诉后续阶段不要考虑这个方向使 plan 阶段能产出零决策计划zero-decision plan——Builder teammates 拿到计划后只需机械执行无需再做技术判断。输出物约束集合 可验证的成功判据写入.claude/team-plan/任务名-research.md。这一理念与仓库中 templates/engine/strategies/deep-research.md 的深度研究策略一脉相承研究阶段绝不修改代码只做探索与综合分析最终给出结构化输出而非自由聊天式结论。Guardrails研究阶段的四条红线命令在执行任何动作前必须遵守以下防护栏STOP! BEFORE ANY OTHER ACTION必须先做 Prompt 增强Step 0这是强制且不可跳过的。按上下文边界划分探索范围不按角色划分——严禁出现架构师 agent安全专家 agent这类按职能拆分的子任务。多模型协作是强制的mandatory必须同时调用{{BACKEND_PRIMARY}}后端边界与{{FRONTEND_PRIMARY}}前端边界两个外部模型。不做架构决策——只发现约束架构选择留给后续 Architect/Plan 阶段。使用AskUserQuestion解决任何歧义绝不假设。其中按上下文边界而非角色划分是这套工作流最具辨识度的设计每个探索边界自包含、无需跨边界通信从而保证两个外部模型可以真正并行、互不干扰。Step 0MANDATORY Prompt 增强研究阶段的第一步不是扫描代码而是先增强需求分析$ARGUMENTS的意图、缺失信息、隐含假设补全为结构化需求明确目标、技术约束、范围边界、验收标准后续所有步骤都使用增强后的需求而不是原始输入。这保证了两个外部模型拿到的是同一份完整、无歧义的任务描述避免因原始需求过于口语化而导致探索方向漂移。仓库中 templates/commands/spec-research.md新世代 spec 版本同样把 Prompt 增强列为NON-NEGOTIABLE的第一步可见这是贯穿整个 ccg-workflow 的通用铁律。Step 1–2代码库评估与探索边界定义Step 1 代码库评估用 Glob/Grep/Read 扫描项目结构判断项目规模单目录 vs 多目录识别技术栈、框架与现有模式。Step 2 定义探索边界按上下文划分识别自然的上下文边界不是功能角色原文档给出三个典型示例边界 1用户域代码models, services, UI边界 2认证与授权middleware, session, tokens边界 3基础设施configs, builds, deployments每个边界应自包含无需跨边界通信。在实际执行时{{BACKEND_PRIMARY}}负责后端相关边界{{FRONTEND_PRIMARY}}负责前端相关边界形成两条互不重叠的探索线索。Step 3多模型并行探索——命令逐参数拆解这是整个研究阶段的核心动作。CRITICAL 规则必须在同一条消息中同时发起两个 Bash 调用run_in_background: true不能先调一个等结果再调另一个。工作目录获取铁律{{WORKDIR}}必须通过 Bash 执行pwdUnix或cdWindows CMD获取当前工作目录的绝对路径禁止从$HOME或环境变量推断。这是为了防止环境变量与实际终端工作目录不一致导致外部模型探索了错误的目录。第一条 Bash 调用{{BACKEND_PRIMARY}} 后端探索Bash({ command: ~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--progress --backend {{BACKEND_PRIMARY}} {{GEMINI_MODEL_FLAG}}{{GROK_MODEL_FLAG}}{{KIMI_MODEL_FLAG}}{{OPENCODE_MODEL_FLAG}}- \{{WORKDIR}}\ EOF\nROLE_FILE: ~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/analyzer.md\nTASK\n需求增强后的需求\n探索范围后端相关上下文边界\n/TASK\nOUTPUT (JSON):\n{\n \module_name\: \探索的上下文边界\,\n \existing_structures\: [\发现的关键模式\],\n \existing_conventions\: [\使用中的规范\],\n \constraints_discovered\: [\限制解决方案空间的硬约束\],\n \open_questions\: [\需要用户确认的歧义\],\n \dependencies\: [\跨模块依赖\],\n \risks\: [\潜在阻碍\],\n \success_criteria_hints\: [\可观测的成功行为\]\n}\nEOF, run_in_background: true, timeout: 3600000, description: {{BACKEND_PRIMARY}} 后端探索 })第二条 Bash 调用{{FRONTEND_PRIMARY}} 前端探索同一条消息Bash({ command: ~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--progress --backend {{FRONTEND_PRIMARY}} {{GEMINI_MODEL_FLAG}}{{GROK_MODEL_FLAG}}{{KIMI_MODEL_FLAG}}{{OPENCODE_MODEL_FLAG}}- \{{WORKDIR}}\ EOF\nROLE_FILE: ~/.claude/.ccg/prompts/{{FRONTEND_PRIMARY}}/analyzer.md\nTASK\n需求增强后的需求\n探索范围前端相关上下文边界\n/TASK\nOUTPUT (JSON):\n{\n \module_name\: \探索的上下文边界\,\n \existing_structures\: [\发现的关键模式\],\n \existing_conventions\: [\使用中的规范\],\n \constraints_discovered\: [\限制解决方案空间的硬约束\],\n \open_questions\: [\需要用户确认的歧义\],\n \dependencies\: [\跨模块依赖\],\n \risks\: [\潜在阻碍\],\n \success_criteria_hints\: [\可观测的成功行为\]\n}\nEOF, run_in_background: true, timeout: 3600000, description: {{FRONTEND_PRIMARY}} 前端探索 })等待结果TaskOutput({ task_id: codex_task_id, block: true, timeout: 600000 }) TaskOutput({ task_id: gemini_task_id, block: true, timeout: 600000 })失败处理与等待纪律原文档对两条探索链路给出了截然不同的容错策略⛔前端模型失败必须重试若前端模型调用失败最多重试 2 次间隔 5 秒3 次全败才允许跳过。⛔后端模型结果必须等待后端模型执行 5-15 分钟属正常现象TaskOutput超时后必须继续轮询禁止跳过。这一不对称设计反映了两条探索链路的角色差异后端模型是权威分析来源其结论是约束集的主体前端模型是补充视角可以在极端情况下降级。命令中的占位符与真实参数映射上述命令中的{{LITE_MODE_FLAG}}、{{GEMINI_MODEL_FLAG}}等占位符在安装时由安装器替换为真实参数。从仓库源码 codeagent-wrapper/config.go 的参数解析逻辑看codeagent-wrapper实际支持的 CLI 参数包括参数作用解析位置--lite/-L启用轻量模式禁用 WebServer、减少日志、缩短消息后延迟config.go--backend name指定外部模型后端config.go--gemini-model name指定 Gemini 模型名如--gemini-modelgemini-2.5-proconfig.go--grok-model name指定 Grok 模型名config.go--kimi-model name指定 Kimi 模型别名config.go--opencode-model name指定 OpenCode 模型provider/model 格式config.go--with-mcp让子 agent 加载 Claude 的 MCP 服务器默认关闭较慢config.go--progress向 stderr 输出紧凑进度行config.go--skip-permissions/--dangerously-skip-permissions跳过权限确认config.go占位符展开后的命令形态例如~/.claude/bin/codeagent-wrapper --progress --backend codex --gemini-model gemini-2.5-pro - /path/to/workdir后端注册表BACKEND_PRIMARY 能取哪些值从源码 codeagent-wrapper/config.go 的backendRegistry可以确认当前 wrapper 支持的后端有 8 个var backendRegistry map[string]Backend{ codex: CodexBackend{}, claude: ClaudeBackend{}, gemini: GeminiBackend{}, antigravity: AntigravityBackend{}, agy: AntigravityBackend{}, grok: GrokBackend{}, kimi: KimiBackend{}, opencode: OpencodeBackend{}, }未指定--backend时默认使用codex见 codeagent-wrapper/main.go 的defaultBackendName。因此{{BACKEND_PRIMARY}}通常展开为codex{{FRONTEND_PRIMARY}}通常展开为gemini与项目Claude 编排 Codex 后端 Gemini 前端的定位一致{{LITE_MODE_FLAG}}在轻量模式下展开为--lite。ROLE_FILE外部模型扮演的 analyzer 角色命令中的ROLE_FILE: ~/.claude/.ccg/prompts/backend/analyzer.md指向安装后写入用户主目录的角色提示词。其仓库源文件对应 templates/prompts/codex/analyzer.md 与 templates/prompts/gemini/analyzer.mdCodex后端视角扮演 Technical Analyst擅长架构评估、技术债分析、可扩展性、安全漏洞识别、技术栈评估与权衡分析Gemini前端视角扮演 Design Analyst擅长用户体验评估、设计系统分析、组件架构、可访问性合规与响应式设计。两者都是ZERO file system write permission只读沙箱只输出结构化分析报告不做任何代码修改——这从机制上保证了研究阶段只发现约束、不产生变更。Step 4聚合与综合——四类约束的统一两个模型返回后Lead 将探索输出合并为统一约束集原文档定义了四个分类维度硬约束Hard constraints技术限制、不可违反的模式软约束Soft constraints惯例、偏好、风格指南依赖Dependencies影响实施顺序的跨模块关系风险Risks需要缓解的阻碍。聚合时两个模型各自返回的 JSON 中的constraints_discovered、dependencies、risks字段正是这四个维度的直接输入。值得注意的是输出模板中还有success_criteria_hints可观测的成功行为字段它会在 Step 6 转化为可验证的成功判据。Step 5歧义消解——用 AskUserQuestion 系统性收敛研究阶段不允许猜编译优先级排序的开放问题列表来自两个模型 JSON 中的open_questions字段用AskUserQuestion系统性呈现分组相关问题、为每个问题提供上下文、在适用时建议默认值将用户回答转化为额外约束追加进约束集。这一步骤保证了研究文件的零开放问题残留退出条件Exit Criteria 之一是可以达成的。Step 6写入研究文件——标准格式模板聚合与消解完成后将结果写入.claude/team-plan/任务名-research.md原文档给出了完整格式# Team Research: 任务名 ## 增强后的需求 结构化需求描述 ## 约束集 ### 硬约束 - [HC-1] 约束描述 — 来源后端/前端模型/用户 - [HC-2] ... ### 软约束 - [SC-1] 约束描述 — 来源后端/前端模型/用户 - [SC-2] ... ### 依赖关系 - [DEP-1] 模块A → 模块B原因 ### 风险 - [RISK-1] 风险描述 — 缓解策略 ## 成功判据 - [OK-1] 可验证的成功行为 - [OK-2] ... ## 开放问题已解决 - Q1: 问题 → A: 用户回答 → 约束[HC/SC-N]每个约束都带来源标注后端模型/前端模型/用户使后续阶段能追溯每条约束的可信度与出处成功判据采用[OK-N]编号成为 team-plan 阶段拆分任务验收标准的直接依据。Step 7上下文检查点与阶段边界报告当前上下文使用量提示用户研究完成运行 /clear 后执行 /ccg:team-plan 任务名 开始规划。这一提示明确了研究阶段与规划阶段的交接方式研究文件落地后研究阶段即告完成不得越界进入规划或实现。同源的 spec 版本 templates/commands/spec-research.md 也强调此阶段只产出提案 artifact不修改任何源代码生成后 STOP 并提示用户运行/ccg:spec-plan继续。Exit Criteria研究完成的验收清单- [ ] {{BACKEND_PRIMARY}} {{FRONTEND_PRIMARY}} 探索完成 - [ ] 所有歧义已通过用户确认解决 - [ ] 约束集 成功判据已写入研究文件 - [ ] 零开放问题残留四条退出条件与 Step 4–6 一一对应两条探索链路都拿到结果、歧义全部收敛、产物落盘、开放问题清零。只有全部勾选研究阶段才算正式完成。源码级支撑wrapper 的超时与并行机制研究阶段两个 Bash 调用均设置timeout: 36000001 小时而TaskOutput等待超时为60000010 分钟。wrapper 侧 codeagent-wrapper/main.go 定义的defaultTimeout 72002 小时为命令级兜底。两个超时层级的关系是wrapper 进程本身最长运行 2 小时每次TaskOutput阻塞等待 10 分钟超时后继续轮询而非放弃配合后端模型 5-15 分钟属正常的预期确保长任务不被误杀。此外wrapper 支持resume session_id task恢复模式见 config.go若研究过程中断可用会话 ID 无缝续跑不必重新发起完整的双模型探索。与 team-plan、team-exec 的流水线衔接研究文件不是终点而是规划阶段的输入契约/ccg:team-research本文产出.claude/team-plan/任务名-research.md约束集 成功判据/ccg:team-plan基于约束集做架构方案与任务拆分产出.claude/team-plan/任务名.md其TaskUpdate等待逻辑同样要求timeout: 600000且绝对不要 Kill 进程team-plan.md/ccg:team-exec读取计划文件通过TeamCreateAgent(team_name...)spawn Builder teammates 并行实施team-exec.md。正是因为研究阶段已经把方向性决策全部压缩成约束team-plan 才能产出零决策并行实施计划team-exec 的 Builder 才能纯机械执行。整条链路体现了 ccg-workflow 的核心设计思想把判断力前置到研究阶段把执行力留给并行阶段。从 legacy 到 spec研究范式的演进值得注意的是本命令templates/commands-legacy/team-research.md属于commands-legacy目录仓库同时提供新世代的 templates/commands/spec-research.md。两者共享同一套研究哲学约束集、上下文边界划分、双模型并行、AskUserQuestion 消歧区别在于产物形态legacy 版本直接写入.claude/team-plan/任务名-research.mdspec 版本通过openspec new change脚手架生成openspec/changes/name/proposal.md并强调遵循 OPSX 规范、使用{{MCP_SEARCH_TOOL}}减少 grep/find 操作。如果你在使用新版命令体系/ccg:spec-research是本文所讲流程的规范化升级版阅读本文的并行探索与约束聚合方法论对两个版本都完全适用。实战要点小结研究阶段绝不写代码外部模型处于只读沙箱analyzer.md 明确 ZERO write permissionLead 也只做聚合与消歧两个 Bash 调用必须同消息发起这是实现真正并行的前提串行调用会成倍拉长研究时长后端结果必须等到前端失败可降级两条链路的容错策略不同不要混用每条约束都要带来源[HC-1] ... — 来源后端/前端模型/用户保证可追溯成功判据必须可观测[OK-N]描述的是可验证的成功行为而非主观感受结束即交接研究文件落盘后运行/clear并切换到/ccg:team-plan 任务名不越阶段。赞分享人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek【免费下载链接】ccg-workflow多模型协作开发系统 - Claude 编排 Codex 后端 Gemini 前端28 个命令覆盖开发全流程一键安装零配置项目地址https://gitcode.com/fengshao1227/ccg-workflow点击查看免费下载相关推荐如何利用japanese-hubert-base进行日语语音特征提取实战代码详解如何利用japanese hubert base进行日语语音特征提取实战代码详解 japanese hubert base是一个专为日语语音处理优化的预训练模Create React App Kitchensink E2E 测试套件实战指南从 Docker 运行到编写 env/syntax/webpack 测试Create React App Kitchensink E2E 测试套件实战指南从 Docker 运行到编写 env/syntax/webpack 测试 C人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeekAsspp高级功能AirDrop安装与本地安装的完整对比分析Asspp高级功能AirDrop安装与本地安装的完整对比分析 Asspp作为多账户生态系统的应用商店提供了灵活多样的安装方式其中AirDrop安装与本地安开发工具上一篇WLED与Adalight联动PC屏幕氛围灯制作教程下一篇告别CD地狱20个z命令技巧让目录跳转效率提升10倍创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek【免费下载链接】ccg-workflow多模型协作开发系统 - Claude 编排 Codex 后端 Gemini 前端28 个命令覆盖开发全流程一键安装零配置项目地址https://gitcode.com/fengshao1227/ccg-workflow点击查看免费下载本文聚焦 ccg-workflow 多模型协作开发系统中的Agent Teams 需求研究命令/ccg:team-research完整剖析其并行探索代码库 → 聚合约束集 → 消解歧义 → 落地研究文件的执行流程并结合仓库源码讲解底层codeagent-wrapper的参数机制。读完本文你将掌握研究阶段Research在 8 阶段团队流水线中的定位、约束集驱动后续零决策规划的设计哲学以及如何在 Claude 中手工复现这条双模型并行探索链路。命令定位研究是 8 阶段流水线的第二环在 ccg-workflow 的 Agent Teams 统一工作流中见 templates/commands-legacy/team.md完整流水线被划分为 8 个阶段Phase 0: PRE-FLIGHT → 环境检测 Phase 1: REQUIREMENT → Lead 需求增强 → mini-PRD Phase 2: ARCHITECTURE → 后端模型∥前端模型 分析 Architect teammate 出蓝图 Phase 3: PLANNING → Lead 拆任务 → 零决策并行计划 Phase 4: DEVELOPMENT → Dev×N teammates 并行编码 Phase 5: TESTING → QA teammate 写测试跑测试 Phase 6: REVIEW → 后端模型∥前端模型 审查 Reviewer teammate 综合判决 Phase 7: FIX → Dev teammate(s) 修复 Critical最多 2 轮 Phase 8: INTEGRATION → Lead 全量验证 报告 清理/ccg:team-research是这一体系中的研究Research阶段专用命令位于需求增强之后、架构与规划之前。它的上游产物是增强后的结构化需求下游产物是写入.claude/team-plan/任务名-research.md的约束集与成功判据供/ccg:team-plantemplates/commands-legacy/team-plan.md直接消费。核心哲学研究产出的是约束集不是信息堆砌team-research.md开篇即点明该命令的设计出发点这是理解整条工作流的关键研究产出的是约束集constraint sets不是信息堆砌。每一条约束都在缩小解决方案空间narrow the solution space。约束告诉后续阶段不要考虑这个方向使 plan 阶段能产出零决策计划zero-decision plan——Builder teammates 拿到计划后只需机械执行无需再做技术判断。输出物约束集合 可验证的成功判据写入.claude/team-plan/任务名-research.md。这一理念与仓库中 templates/engine/strategies/deep-research.md 的深度研究策略一脉相承研究阶段绝不修改代码只做探索与综合分析最终给出结构化输出而非自由聊天式结论。Guardrails研究阶段的四条红线命令在执行任何动作前必须遵守以下防护栏STOP! BEFORE ANY OTHER ACTION必须先做 Prompt 增强Step 0这是强制且不可跳过的。按上下文边界划分探索范围不按角色划分——严禁出现架构师 agent安全专家 agent这类按职能拆分的子任务。多模型协作是强制的mandatory必须同时调用{{BACKEND_PRIMARY}}后端边界与{{FRONTEND_PRIMARY}}前端边界两个外部模型。不做架构决策——只发现约束架构选择留给后续 Architect/Plan 阶段。使用AskUserQuestion解决任何歧义绝不假设。其中按上下文边界而非角色划分是这套工作流最具辨识度的设计每个探索边界自包含、无需跨边界通信从而保证两个外部模型可以真正并行、互不干扰。Step 0MANDATORY Prompt 增强研究阶段的第一步不是扫描代码而是先增强需求分析$ARGUMENTS的意图、缺失信息、隐含假设补全为结构化需求明确目标、技术约束、范围边界、验收标准后续所有步骤都使用增强后的需求而不是原始输入。这保证了两个外部模型拿到的是同一份完整、无歧义的任务描述避免因原始需求过于口语化而导致探索方向漂移。仓库中 templates/commands/spec-research.md新世代 spec 版本同样把 Prompt 增强列为NON-NEGOTIABLE的第一步可见这是贯穿整个 ccg-workflow 的通用铁律。Step 1–2代码库评估与探索边界定义Step 1 代码库评估用 Glob/Grep/Read 扫描项目结构判断项目规模单目录 vs 多目录识别技术栈、框架与现有模式。Step 2 定义探索边界按上下文划分识别自然的上下文边界不是功能角色原文档给出三个典型示例边界 1用户域代码models, services, UI边界 2认证与授权middleware, session, tokens边界 3基础设施configs, builds, deployments每个边界应自包含无需跨边界通信。在实际执行时{{BACKEND_PRIMARY}}负责后端相关边界{{FRONTEND_PRIMARY}}负责前端相关边界形成两条互不重叠的探索线索。Step 3多模型并行探索——命令逐参数拆解这是整个研究阶段的核心动作。CRITICAL 规则必须在同一条消息中同时发起两个 Bash 调用run_in_background: true不能先调一个等结果再调另一个。工作目录获取铁律{{WORKDIR}}必须通过 Bash 执行pwdUnix或cdWindows CMD获取当前工作目录的绝对路径禁止从$HOME或环境变量推断。这是为了防止环境变量与实际终端工作目录不一致导致外部模型探索了错误的目录。第一条 Bash 调用{{BACKEND_PRIMARY}} 后端探索Bash({ command: ~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--progress --backend {{BACKEND_PRIMARY}} {{GEMINI_MODEL_FLAG}}{{GROK_MODEL_FLAG}}{{KIMI_MODEL_FLAG}}{{OPENCODE_MODEL_FLAG}}- \{{WORKDIR}}\ EOF\nROLE_FILE: ~/.claude/.ccg/prompts/{{BACKEND_PRIMARY}}/analyzer.md\nTASK\n需求增强后的需求\n探索范围后端相关上下文边界\n/TASK\nOUTPUT (JSON):\n{\n \module_name\: \探索的上下文边界\,\n \existing_structures\: [\发现的关键模式\],\n \existing_conventions\: [\使用中的规范\],\n \constraints_discovered\: [\限制解决方案空间的硬约束\],\n \open_questions\: [\需要用户确认的歧义\],\n \dependencies\: [\跨模块依赖\],\n \risks\: [\潜在阻碍\],\n \success_criteria_hints\: [\可观测的成功行为\]\n}\nEOF, run_in_background: true, timeout: 3600000, description: {{BACKEND_PRIMARY}} 后端探索 })第二条 Bash 调用{{FRONTEND_PRIMARY}} 前端探索同一条消息Bash({ command: ~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--progress --backend {{FRONTEND_PRIMARY}} {{GEMINI_MODEL_FLAG}}{{GROK_MODEL_FLAG}}{{KIMI_MODEL_FLAG}}{{OPENCODE_MODEL_FLAG}}- \{{WORKDIR}}\ EOF\nROLE_FILE: ~/.claude/.ccg/prompts/{{FRONTEND_PRIMARY}}/analyzer.md\nTASK\n需求增强后的需求\n探索范围前端相关上下文边界\n/TASK\nOUTPUT (JSON):\n{\n \module_name\: \探索的上下文边界\,\n \existing_structures\: [\发现的关键模式\],\n \existing_conventions\: [\使用中的规范\],\n \constraints_discovered\: [\限制解决方案空间的硬约束\],\n \open_questions\: [\需要用户确认的歧义\],\n \dependencies\: [\跨模块依赖\],\n \risks\: [\潜在阻碍\],\n \success_criteria_hints\: [\可观测的成功行为\]\n}\nEOF, run_in_background: true, timeout: 3600000, description: {{FRONTEND_PRIMARY}} 前端探索 })等待结果TaskOutput({ task_id: codex_task_id, block: true, timeout: 600000 }) TaskOutput({ task_id: gemini_task_id, block: true, timeout: 600000 })失败处理与等待纪律原文档对两条探索链路给出了截然不同的容错策略⛔前端模型失败必须重试若前端模型调用失败最多重试 2 次间隔 5 秒3 次全败才允许跳过。⛔后端模型结果必须等待后端模型执行 5-15 分钟属正常现象TaskOutput超时后必须继续轮询禁止跳过。这一不对称设计反映了两条探索链路的角色差异后端模型是权威分析来源其结论是约束集的主体前端模型是补充视角可以在极端情况下降级。命令中的占位符与真实参数映射上述命令中的{{LITE_MODE_FLAG}}、{{GEMINI_MODEL_FLAG}}等占位符在安装时由安装器替换为真实参数。从仓库源码 codeagent-wrapper/config.go 的参数解析逻辑看codeagent-wrapper实际支持的 CLI 参数包括参数作用解析位置--lite/-L启用轻量模式禁用 WebServer、减少日志、缩短消息后延迟config.go--backend name指定外部模型后端config.go--gemini-model name指定 Gemini 模型名如--gemini-modelgemini-2.5-proconfig.go--grok-model name指定 Grok 模型名config.go--kimi-model name指定 Kimi 模型别名config.go--opencode-model name指定 OpenCode 模型provider/model 格式config.go--with-mcp让子 agent 加载 Claude 的 MCP 服务器默认关闭较慢config.go--progress向 stderr 输出紧凑进度行config.go--skip-permissions/--dangerously-skip-permissions跳过权限确认config.go占位符展开后的命令形态例如~/.claude/bin/codeagent-wrapper --progress --backend codex --gemini-model gemini-2.5-pro - /path/to/workdir后端注册表BACKEND_PRIMARY 能取哪些值从源码 codeagent-wrapper/config.go 的backendRegistry可以确认当前 wrapper 支持的后端有 8 个var backendRegistry map[string]Backend{ codex: CodexBackend{}, claude: ClaudeBackend{}, gemini: GeminiBackend{}, antigravity: AntigravityBackend{}, agy: AntigravityBackend{}, grok: GrokBackend{}, kimi: KimiBackend{}, opencode: OpencodeBackend{}, }未指定--backend时默认使用codex见 codeagent-wrapper/main.go 的defaultBackendName。因此{{BACKEND_PRIMARY}}通常展开为codex{{FRONTEND_PRIMARY}}通常展开为gemini与项目Claude 编排 Codex 后端 Gemini 前端的定位一致{{LITE_MODE_FLAG}}在轻量模式下展开为--lite。ROLE_FILE外部模型扮演的 analyzer 角色命令中的ROLE_FILE: ~/.claude/.ccg/prompts/backend/analyzer.md指向安装后写入用户主目录的角色提示词。其仓库源文件对应 templates/prompts/codex/analyzer.md 与 templates/prompts/gemini/analyzer.mdCodex后端视角扮演 Technical Analyst擅长架构评估、技术债分析、可扩展性、安全漏洞识别、技术栈评估与权衡分析Gemini前端视角扮演 Design Analyst擅长用户体验评估、设计系统分析、组件架构、可访问性合规与响应式设计。两者都是ZERO file system write permission只读沙箱只输出结构化分析报告不做任何代码修改——这从机制上保证了研究阶段只发现约束、不产生变更。Step 4聚合与综合——四类约束的统一两个模型返回后Lead 将探索输出合并为统一约束集原文档定义了四个分类维度硬约束Hard constraints技术限制、不可违反的模式软约束Soft constraints惯例、偏好、风格指南依赖Dependencies影响实施顺序的跨模块关系风险Risks需要缓解的阻碍。聚合时两个模型各自返回的 JSON 中的constraints_discovered、dependencies、risks字段正是这四个维度的直接输入。值得注意的是输出模板中还有success_criteria_hints可观测的成功行为字段它会在 Step 6 转化为可验证的成功判据。Step 5歧义消解——用 AskUserQuestion 系统性收敛研究阶段不允许猜编译优先级排序的开放问题列表来自两个模型 JSON 中的open_questions字段用AskUserQuestion系统性呈现分组相关问题、为每个问题提供上下文、在适用时建议默认值将用户回答转化为额外约束追加进约束集。这一步骤保证了研究文件的零开放问题残留退出条件Exit Criteria 之一是可以达成的。Step 6写入研究文件——标准格式模板聚合与消解完成后将结果写入.claude/team-plan/任务名-research.md原文档给出了完整格式# Team Research: 任务名 ## 增强后的需求 结构化需求描述 ## 约束集 ### 硬约束 - [HC-1] 约束描述 — 来源后端/前端模型/用户 - [HC-2] ... ### 软约束 - [SC-1] 约束描述 — 来源后端/前端模型/用户 - [SC-2] ... ### 依赖关系 - [DEP-1] 模块A → 模块B原因 ### 风险 - [RISK-1] 风险描述 — 缓解策略 ## 成功判据 - [OK-1] 可验证的成功行为 - [OK-2] ... ## 开放问题已解决 - Q1: 问题 → A: 用户回答 → 约束[HC/SC-N]每个约束都带来源标注后端模型/前端模型/用户使后续阶段能追溯每条约束的可信度与出处成功判据采用[OK-N]编号成为 team-plan 阶段拆分任务验收标准的直接依据。Step 7上下文检查点与阶段边界报告当前上下文使用量提示用户研究完成运行 /clear 后执行 /ccg:team-plan 任务名 开始规划。这一提示明确了研究阶段与规划阶段的交接方式研究文件落地后研究阶段即告完成不得越界进入规划或实现。同源的 spec 版本 templates/commands/spec-research.md 也强调此阶段只产出提案 artifact不修改任何源代码生成后 STOP 并提示用户运行/ccg:spec-plan继续。Exit Criteria研究完成的验收清单- [ ] {{BACKEND_PRIMARY}} {{FRONTEND_PRIMARY}} 探索完成 - [ ] 所有歧义已通过用户确认解决 - [ ] 约束集 成功判据已写入研究文件 - [ ] 零开放问题残留四条退出条件与 Step 4–6 一一对应两条探索链路都拿到结果、歧义全部收敛、产物落盘、开放问题清零。只有全部勾选研究阶段才算正式完成。源码级支撑wrapper 的超时与并行机制研究阶段两个 Bash 调用均设置timeout: 36000001 小时而TaskOutput等待超时为60000010 分钟。wrapper 侧 codeagent-wrapper/main.go 定义的defaultTimeout 72002 小时为命令级兜底。两个超时层级的关系是wrapper 进程本身最长运行 2 小时每次TaskOutput阻塞等待 10 分钟超时后继续轮询而非放弃配合后端模型 5-15 分钟属正常的预期确保长任务不被误杀。此外wrapper 支持resume session_id task恢复模式见 config.go若研究过程中断可用会话 ID 无缝续跑不必重新发起完整的双模型探索。与 team-plan、team-exec 的流水线衔接研究文件不是终点而是规划阶段的输入契约/ccg:team-research本文产出.claude/team-plan/任务名-research.md约束集 成功判据/ccg:team-plan基于约束集做架构方案与任务拆分产出.claude/team-plan/任务名.md其TaskUpdate等待逻辑同样要求timeout: 600000且绝对不要 Kill 进程team-plan.md/ccg:team-exec读取计划文件通过TeamCreateAgent(team_name...)spawn Builder teammates 并行实施team-exec.md。正是因为研究阶段已经把方向性决策全部压缩成约束team-plan 才能产出零决策并行实施计划team-exec 的 Builder 才能纯机械执行。整条链路体现了 ccg-workflow 的核心设计思想把判断力前置到研究阶段把执行力留给并行阶段。从 legacy 到 spec研究范式的演进值得注意的是本命令templates/commands-legacy/team-research.md属于commands-legacy目录仓库同时提供新世代的 templates/commands/spec-research.md。两者共享同一套研究哲学约束集、上下文边界划分、双模型并行、AskUserQuestion 消歧区别在于产物形态legacy 版本直接写入.claude/team-plan/任务名-research.mdspec 版本通过openspec new change脚手架生成openspec/changes/name/proposal.md并强调遵循 OPSX 规范、使用{{MCP_SEARCH_TOOL}}减少 grep/find 操作。如果你在使用新版命令体系/ccg:spec-research是本文所讲流程的规范化升级版阅读本文的并行探索与约束聚合方法论对两个版本都完全适用。实战要点小结研究阶段绝不写代码外部模型处于只读沙箱analyzer.md 明确 ZERO write permissionLead 也只做聚合与消歧两个 Bash 调用必须同消息发起这是实现真正并行的前提串行调用会成倍拉长研究时长后端结果必须等到前端失败可降级两条链路的容错策略不同不要混用每条约束都要带来源[HC-1] ... — 来源后端/前端模型/用户保证可追溯成功判据必须可观测[OK-N]描述的是可验证的成功行为而非主观感受结束即交接研究文件落盘后运行/clear并切换到/ccg:team-plan 任务名不越阶段。赞分享人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeek【免费下载链接】ccg-workflow多模型协作开发系统 - Claude 编排 Codex 后端 Gemini 前端28 个命令覆盖开发全流程一键安装零配置项目地址https://gitcode.com/fengshao1227/ccg-workflow点击查看免费下载相关推荐如何利用japanese-hubert-base进行日语语音特征提取实战代码详解如何利用japanese hubert base进行日语语音特征提取实战代码详解 japanese hubert base是一个专为日语语音处理优化的预训练模Create React App Kitchensink E2E 测试套件实战指南从 Docker 运行到编写 env/syntax/webpack 测试Create React App Kitchensink E2E 测试套件实战指南从 Docker 运行到编写 env/syntax/webpack 测试 C人工智能AI 应用开发工具CLIAI Agentdsh-pluginDeepSeekAsspp高级功能AirDrop安装与本地安装的完整对比分析Asspp高级功能AirDrop安装与本地安装的完整对比分析 Asspp作为多账户生态系统的应用商店提供了灵活多样的安装方式其中AirDrop安装与本地安开发工具上一篇WLED与Adalight联动PC屏幕氛围灯制作教程下一篇告别CD地狱20个z命令技巧让目录跳转效率提升10倍创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
 运行时)
