TL;DR — CCB 让你在 Claude Code 里直接调用 Gemini、Codex 等模型：用 Gemini 头脑风暴，用 Codex 做代码审查，用 Claude 做最终决策。11 个 Skills、5 分钟上手、成本还能省一半。
引言
Claude 擅长推理和架构设计，Gemini 有超大上下文和免费额度，Codex 代码精度高——但如果你只用其中一个，就浪费了其他的优势。
CCB (Claude Code Bridge) 就是为了解决这个问题：让多个模型协同工作，各自发挥所长，组合起来比单独使用更强大。
image-20260220200622416
一、为什么不让它们一起工作？
1.1 每个模型都有自己的"性格"
单独用任何一个，都是在做妥协。
1.2 组合起来是什么效果？
前端设计 ──→ Gemini（视觉理解强）
+
后端逻辑 ──→ Codex（代码精度高）
+
架构决策 ──→ Claude（推理能力强）
‖
▼
一个高质量的产品
CCB 的核心价值：不是"多加几个 API 调用"，而是让每个模型做它最擅长的事，然后协调它们一起完成复杂任务。
二、CCB (Claude Code Bridge) 核心原理
2.1 架构总览
CCB 是异构智能的认知总线，核心设计理念是让多个 AI（Claude、Codex、Gemini 等）协同完成复杂开发任务。
image-20260220200814529
2.2 核心组件详解
2.2.1 askd Daemon（守护进程）
image-20260220201634716askd 是 CCB 的核心守护进程，负责：
┌─────────────────────────────────────────────┐
│ askd Daemon 职责 │
├─────────────────────────────────────────────┤
│ • Session 生命周期管理 │
│ • 消息队列 (异步/同步) │
│ • Provider 路由与负载均衡 │
│ • Hook 系统触发 │
│ • 日志与状态持久化 │
└─────────────────────────────────────────────┘
运行机制：
Claude 发起请求
│
▼
ask daemon (RPC)
│
├──→ gemini pane (tmux)
├──→ codex pane (tmux)
└──→ opencode pane (tmux)
│
▼
pend 获取回复
2.2.2 角色抽象系统
CCB 使用抽象角色而非具体 provider，实现灵活的模型分配：
|
|
|
|
designer |
|
|
|
inspiration |
|
|
|
reviewer |
|
|
|
executor |
|
|
|
配置方式：
角色映射可通过 .autoflow/roles.json 覆盖：
{
"schemaVersion": 1,
"enabled": true,
"roles": {
"designer": "claude",
"inspiration": "gemini",
"reviewer": "codex",
"executor": "codex"
}
}
或通过 CLAUDE.md 中的 CCB_ROLES 区块配置：
<!-- CCB_ROLES_START -->
## Role Assignment
| Role | Provider | Description |
|------|----------|-------------|
| `designer` | `claude` | Primary planner |
| `inspiration` | `gemini` | Creative brainstorming |
| `reviewer` | `codex` | Quality gate |
| `executor` | `claude` | Code implementation |
<!-- CCB_ROLES_END -->
2.2.3 FileOpsREQ 协议
核心原则：Claude 永不直接修改仓库文件
所有文件操作委托给 Codex 执行：
Claude (主控)
│
│ FileOpsREQ (JSON Protocol)
▼
Codex (执行者)
│
│ Read/Write/Patch Operations
▼
文件系统
协议示例：
{
"proto": "autoflow.fileops.v1",
"id": "TP",
"purpose": "write_plan_files",
"ops": [
{ "op": "write_file", "path": ".ccb/todo.md", "content": "..." }
],
"report": {
"changedFiles": true,
"diffSummary": true
}
}
状态返回：
2.2.4 异步通信协议
┌─────────────────────────────────────────────────────────┐
│ 异步调用流程 │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. Claude 调用: ask gemini "问题" │
│ │ │
│ ▼ │
│ 2. 返回: [CCB_ASYNC_SUBMITTED provider=gemini] │
│ │ │
│ ▼ │
│ 3. Claude 立即结束当前回合 (MANDATORY) │
│ │ │
│ ▼ │
│ 4. Hook 系统检测完成，触发通知 │
│ │ │
│ ▼ │
│ 5. 新回合: pend gemini 获取结果 │
│ │
└─────────────────────────────────────────────────────────┘
关键规则：
- 收到
CCB_ASYNC_SUBMITTED 后必须立即结束回合
2.2.5 状态机驱动
CCB 使用状态机驱动任务执行：
pending → in_progress → review → done/blocked
↑
自动循环 (autoloop daemon)
|
|
pending |
|
in_progress |
|
review |
|
done |
|
blocked |
|
三、CCB Skills 体系
3.1 Skills 概述
CCB Skills 是封装好的多模型协作能力模块，共 11 个核心 Skills：
~/.claude/skills/
├── ask/SKILL.md # 异步调用其他模型
├── pend/SKILL.md # 获取异步回复
├── mounted/SKILL.md # 查看已挂载 providers
├── cping/SKILL.md # 测试连接
├── review/SKILL.md # 双重代码审查
├── file-op/SKILL.md # 文件操作委托
├── all-plan/SKILL.md # 多模型协作规划
├── tp/SKILL.md # 任务计划创建
├── tr/SKILL.md # 任务执行
├── continue/SKILL.md # 上下文恢复
└── autonew/SKILL.md # 启动新会话
3.2 Skills 总览表
|
|
|
|
all-plan |
|
协作规划（5维需求澄清 + inspiration 头脑风暴 + reviewer 评分） |
|
ask |
|
|
ask $PROVIDER "$MSG" |
autonew |
|
|
autonew $PROVIDER |
continue |
|
|
|
cping |
|
|
ccb-ping $PROVIDER |
file-op |
|
委托 Codex 执行文件 I/O（FileOpsREQ 协议） |
ask codex "..." |
mounted |
|
|
ccb-mounted |
pend |
|
|
pend $PROVIDER |
review |
|
双重评审（Claude 初评 + Codex 交叉评审） |
/ask codex |
tp |
|
|
|
tr |
|
|
|
3.3 核心 Skills 详解
3.3.1 ask - 异步调用
# 用法
ask <provider> [options] <message>
# Providers
gemini, codex, opencode, droid, claude
# 选项
-t, --timeout SECONDS # 超时时间 (默认 3600)
--notify # 通知模式，不等待回复
--foreground # 前台运行
--background # 强制后台模式
示例：
# 异步调用 Gemini
ask gemini "分析这个 API 设计的优缺点"
# 带超时的调用
ask codex -t 60 "实现快速排序算法"
# 通知模式（不等待回复）
ask gemini --notify "记录这个决策到日志"
3.3.2 pend - 获取回复
# 用法
pend <provider>
# 示例
pend gemini # 获取 Gemini 最新回复
pend codex # 获取 Codex 最新回复
3.3.3 mounted 和 cping - 状态检查
# 查看挂载状态
ccb-mounted
# 输出: {"gemini": {"session": true, "daemon": true}, ...}
# 测试连接
ccb-ping gemini
ccb-ping codex
挂载定义：mounted = has_session AND daemon_on
3.3.4 review - 双重代码审查
# 用法
/review
# 流程
# 1. Claude 初评（PASS/FIX/UNCERTAIN）
# 2. Codex 交叉评审
# 3. 合并得出最终决定
3.3.5 all-plan - 多模型协作规划
# 用法
/all-plan "需求描述"
# 执行流程
Phase 1: 需求澄清 (5维度评分)
↓
Phase 2: 创意头脑风暴 (Gemini → Claude 过滤建议)
↓
Phase 3: 制定计划 (Claude)
↓
Phase 4: 评分审查 (Codex → 通过≥7.0 或修正)
↓
Phase 5: 输出最终计划
5维度需求评分：
3.3.6 tp 和 tr - 任务计划与执行
# tp: 创建任务计划（内部调用 all-plan）
/tp "实现用户认证系统"
# tr: 执行当前步骤（自动循环）
/tr
# tr 执行流程:
# - Preflight: 读取当前状态
# - Dual Design: Claude + Codex 设计
# - Execute: Codex 执行文件操作
# - Review: 双重评审
# - Finalize: 更新状态，触发下一步
3.3.7 file-op - 文件操作委托（核心组件）
file-op 是 CCB 架构中最重要的组件之一，它实现了 Claude 和文件系统之间的解耦。
核心原则
Claude 永远不直接修改仓库文件，所有文件操作都委托给 Codex 执行。
为什么需要 file-op？
┌─────────────────────────────────────────────────────────────┐
│ 问题：Claude 在 Plan Mode 下不能/不应该直接修改文件 │
│ │
│ 解决：通过 JSON 协议委托 Codex 执行文件操作 │
│ │
│ 好处： │
│ - 所有变更可追溯 (proof 记录) │
│ - Claude 保持"只读/规划"角色 │
│ - 支持多种执行器 (Codex/OpenCode) │
└─────────────────────────────────────────────────────────────┘
工作流程
Claude (主控/规划)
│
│ 1. 构造 FileOpsREQ (JSON)
│ - 要做什么操作
│ - 操作的具体内容
│
▼
/file-op (转发)
│
│ 2. ask codex "执行这个 JSON"
│
▼
Codex (执行者)
│
│ 3. 解析 JSON，执行操作
│ - 读写文件
│ - 运行命令
│ - 更新状态
│
▼
FileOpsRES (JSON 返回)
│
│ 4. 返回结果给 Claude
│ - status: ok/fail/ask/split
│ - changedFiles / diffSummary
│
▼
Claude 继续下一步
FileOpsREQ 协议结构
{
"proto": "autoflow.fileops.v1",
"id": "唯一标识",
"purpose": "操作目的说明",
"done": ["完成条件1", "完成条件2"],
"ops": [
{ "op": "write_file", "path": "文件路径", "content": "内容" },
{ "op": "patch_file", "path": "文件路径", "patch": "diff内容" },
{ "op": "read_file", "path": "文件路径" },
{ "op": "run", "cmd": "shell命令", "cwd": "工作目录" },
{ "op": "autoflow_state_init", ... },
{ "op": "autoflow_state_advance", ... }
],
"report": {
"changedFiles": true,
"diffSummary": true
}
}
操作类型 (ops)
|
|
|
write_file |
|
|
patch_file |
|
|
read_file |
|
|
run |
|
npm test
|
autoflow_* |
|
|
FileOpsRES 返回结构
{
"proto": "autoflow.fileops.v1",
"id": "对应请求的ID",
"status": "ok | fail | ask | split",
"proof": {
"changedFiles": ["src/auth.ts", "src/user.ts"],
"diffSummary": "+50 -20 lines",
"commands": ["npm test (exit 0)"],
"notes": "执行说明..."
},
"ask": { "questions": ["需要用户确认的问题"] },
"fail": { "reason": "失败原因" },
"split": { "substeps": ["拆分的子步骤"] }
}
状态码含义
实际使用示例
# 示例：让 Codex 创建一个计划文件
/file-op '{
"proto": "autoflow.fileops.v1",
"id": "CREATE_TODO",
"purpose": "Create todo.md file",
"ops": [
{
"op": "write_file",
"path": ".ccb/todo.md",
"content": "# Task List\\n- [ ] Step 1\\n- [ ] Step 2"
}
],
"report": { "changedFiles": true }
}'
# Codex 执行后返回
# {
# "proto": "autoflow.fileops.v1",
# "id": "CREATE_TODO",
# "status": "ok",
# "proof": {
# "changedFiles": [".ccb/todo.md"],
# "diffSummary": "+5 lines"
# }
# }
# 示例：读取文件并运行测试
/file-op '{
"proto": "autoflow.fileops.v1",
"id": "READ_AND_TEST",
"purpose": "Read config and run tests",
"ops": [
{ "op": "read_file", "path": "package.json" },
{ "op": "run", "cmd": "npm test", "cwd": "." }
],
"report": { "commands": true }
}'
执行器路由
file-op 支持多种执行器，通过 .autoflow/roles.json 或默认配置决定：
|
|
codex |
|
opencode |
|
codex+opencode |
混合模式，简单操作 Codex，复杂操作委托 OpenCode |
设计原则
- Claude 永不编辑文件 - 所有写操作通过 Codex
- JSON-only 边界 - 请求/响应都是机器可解析的 JSON
- 执行器路由 - 支持 Codex、OpenCode 等多种执行器
简单理解
file-op = Claude 的"远程文件操作代理"
Claude: "我要创建这个文件，帮我执行"
↓
file-op: 转发给 Codex
↓
Codex: 实际执行文件操作
↓
file-op: 返回结果给 Claude
3.3.8 continue 和 autonew - 会话管理
# continue: 恢复上下文
/continue
# 从 ./.ccb/history/ 加载最新的上下文转移文件
# autonew: 启动新会话
/autonew gemini
# 重置 Gemini provider 会话
3.4 按需启用/禁用 CCB Skills
如果你担心 CCB Skills 影响日常其他任务，可以通过管理脚本按需启用/禁用这些 Skills。
3.4.1 管理脚本
创建管理脚本 ~/.claude/scripts/ccb-skills.sh：
#!/bin/bash
# CCB Skills 管理脚本
# 用法: ccb-skills [enable|disable|status|toggle]
SKILLS_DIR="$HOME/.claude/skills"
CCB_DIR="$HOME/.claude/skills-ccb"
# CCB 相关的 skills 列表
CCB_SKILLS=(
"all-plan"
"ask"
"autonew"
"continue"
"cping"
"file-op"
"mounted"
"pend"
"review"
"tp"
"tr"
)
enable_skills() {
echo"启用 CCB Skills..."
for skill in"${CCB_SKILLS[@]}"; do
if [ -d "$CCB_DIR/$skill" ]; then
mv "$CCB_DIR/$skill""$SKILLS_DIR/$skill"
echo" ✓ $skill"
fi
done
echo"完成! CCB Skills 已启用。"
echo"提示: 重启 Claude Code 或开启新会话生效。"
}
disable_skills() {
echo"禁用 CCB Skills..."
for skill in"${CCB_SKILLS[@]}"; do
if [ -d "$SKILLS_DIR/$skill" ]; then
mv "$SKILLS_DIR/$skill""$CCB_DIR/$skill"
echo" ✓ $skill"
fi
done
echo"完成! CCB Skills 已禁用。"
echo"提示: 重启 Claude Code 或开启新会话生效。"
}
show_status() {
echo"=== CCB Skills 状态 ==="
echo""
echo"已启用 (在 skills/):"
for skill in"${CCB_SKILLS[@]}"; do
if [ -d "$SKILLS_DIR/$skill" ]; then
echo" ✓ $skill"
fi
done
echo""
echo"已禁用 (在 skills-ccb/):"
for skill in"${CCB_SKILLS[@]}"; do
if [ -d "$CCB_DIR/$skill" ]; then
echo" ○ $skill"
fi
done
}
case"${1:-status}"in
enable|on|1)
enable_skills
;;
disable|off|0)
disable_skills
;;
status|show|s)
show_status
;;
toggle)
# 如果任一 skill 在 skills 目录，则禁用；否则启用
if [ -d "$SKILLS_DIR/all-plan" ]; then
disable_skills
else
enable_skills
fi
;;
*)
echo"用法: ccb-skills [enable|disable|status|toggle]"
echo""
echo"命令:"
echo" enable, on - 启用 CCB Skills"
echo" disable, off - 禁用 CCB Skills"
echo" status, s - 查看当前状态"
echo" toggle - 切换启用/禁用状态"
exit 1
;;
esac
3.4.2 安装和使用
# 1. 创建脚本目录
mkdir -p ~/.claude/scripts
# 2. 保存脚本并添加执行权限
chmod +x ~/.claude/scripts/ccb-skills.sh
# 3. 添加 alias 到 shell 配置
echo 'alias ccb-skills="~/.claude/scripts/ccb-skills.sh"' >> ~/.zshrc
source ~/.zshrc
3.4.3 命令使用
# 查看状态
ccb-skills status
# 禁用 CCB Skills（移到备份目录）
ccb-skills disable
# 输出:
# 禁用 CCB Skills...
# ✓ all-plan
# ✓ ask
# ✓ autonew
# ...
# 启用 CCB Skills（移回 skills 目录）
ccb-skills enable
# 切换状态
ccb-skills toggle
3.4.4 状态输出示例
=== CCB Skills 状态 ===
已启用 (在 skills/):
✓ all-plan
✓ ask
...
已禁用 (在 skills-ccb/):
(空)
3.4.5 推荐使用方式
- 默认禁用：先运行
ccb-skills disable，日常使用不涉及 CCB 工作流
- 按需启用：需要使用
/tp、/tr 等命令时，运行 ccb-skills enable
- 新会话生效：切换后需要开启新的 Claude Code 会话
四、双重设计 + 双重评审机制
4.1 双重设计（Dual Design）
每个步骤执行前，采用双重设计确保方案质量：
┌─────────────────────────────────────────────────────────┐
│ 双重设计流程 │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. Claude 独立设计方案 A │
│ │ │
│ ▼ │
│ 2. Codex 独立设计方案 B │
│ │ │
│ ▼ │
│ 3. Claude 合并两者方案 │
│ - 采纳 A 的优点 │
│ - 采纳 B 的优点 │
│ - 协调冲突点 │
│ │ │
│ ▼ │
│ 4. 输出最终设计方案 │
│ │
└─────────────────────────────────────────────────────────┘
4.2 双重评审（Dual Review）
每个步骤完成后，采用双重评审确保代码质量：
┌─────────────────────────────────────────────────────────┐
│ 双重评审流程 │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. Claude 初评 │
│ - PASS: 通过 │
│ - FIX: 需要修改 │
│ - UNCERTAIN: 不确定，需要 Codex 评审 │
│ │ │
│ ▼ │
│ 2. Codex 交叉评审 │
│ - 独立评估代码质量 │
│ - 提供详细反馈 │
│ │ │
│ ▼ │
│ 3. 合并评审结果 │
│ - 综合两者意见 │
│ - 做出最终决定 │
│ │
└─────────────────────────────────────────────────────────┘
五、启用和停止 CCB
5.1 前置条件
# 1. 安装依赖
# - Node.js 20+
# - Python 3.10+
# - tmux 或 WezTerm
# 2. 安装 CLI 工具
npm install -g @anthropic-ai/claude-code # Claude CLI
npm install -g @google/gemini-cli # Gemini CLI
npm install -g @openai/codex-cli # Codex CLI
# 3. 配置 API Keys
export ANTHROPIC_API_KEY=your_key
export GEMINI_API_KEY=your_key
export OPENAI_API_KEY=your_key
5.2 启动 CCB
# 1. 进入 tmux (必须)
tmux
# 2. 进入项目目录
cd /path/to/your/project
# 3. 启动 CCB
ccb start
# 4. 验证启动成功
ccb status
启动后 tmux 布局：
┌─────────────────────────────────────────────────────────┐
│ Pane 0: Claude CLI (主控) │
├─────────────────────────────────────────────────────────┤
│ Pane 1: OpenCode CLI │
├─────────────────────────────────────────────────────────┤
│ Pane 2: Gemini CLI │
├─────────────────────────────────────────────────────────┤
│ Pane 3: Codex CLI │
└─────────────────────────────────────────────────────────┘
5.3 停止 CCB
# 1. 停止 CCB session
ccb stop
# 2. 停止 askd daemon (如果需要)
pkill -f askd
# 3. 完全清理 (包括日志)
ccb clean
5.4 常用运维命令
# 查看状态
ccb status
# 查看日志
tail -f ~/.cache/ccb/projects/*/pane-logs/tmux/*.log
# 重启某个 provider
ccb restart gemini
# 检查 daemon
ps aux | grep askd
# 查看 tmux panes
tmux list-panes
5.5 故障排除
|
|
|
askd daemon not running |
|
ccb start
|
No reply available |
|
|
Not in tmux |
|
|
Session not found |
|
|
六、协作模式深度解析
6.1 模式一：智能路由 + 任务分工
┌─────────────────────────────────────────────┐
│ Claude Code (主控/协调) │
│ - 决策、审查、工作流控制 │
└─────────────────┬───────────────────────────┘
│
┌─────────┴─────────┐
▼ ▼
┌───────────────┐ ┌───────────────┐
│ Codex (后端) │ │ Gemini (前端) │
│ - 算法/逻辑 │ │ - UI/CSS │
│ - 调试 │ │ - 组件 │
└───────────────┘ └───────────────┘
路由规则：
6.2 模式二：并行执行 + 交叉验证
┌──────────────┐
│ 任务输入 │
└──────┬───────┘
│
┌────────┴────────┐
▼ ▼
┌─────────┐ ┌─────────┐
│ Codex │ │ Gemini │
│ 方案 A │ │ 方案 B │
└────┬────┘ └────┬────┘
│ │
└────────┬───────┘
▼
┌──────────────┐
│ Claude 审查 │
│ 选择最优方案 │
└──────────────┘
6.3 模式三：All-Plan 协作流程
使用 /all-plan skill 实现完整的结构化协作：
/all-plan "实现一个分布式任务队列系统"
# 自动执行:
# 1. 需求澄清 → 5维度评分
# 2. Gemini 创意 → Claude 过滤
# 3. Claude 制定计划
# 4. Codex 评分审查 (≥7.0 通过)
# 5. 输出最终计划到 plans/ 目录
七、实际工作流案例
image-20260220200945786
7.1 新功能开发
# Step 1: 创建任务计划
/tp "实现用户认证系统"
# all-plan 流程:
# - 5维需求澄清
# - Gemini 头脑风暴
# - Claude 制定计划
# - Codex 评分（≥7.0 通过）
# Step 2: 执行任务
/tr
# tr 流程 (自动循环):
# - Dual Design: Claude + Codex 设计
# - Execute: Codex 执行文件操作
# - Review: 双重评审
# - Finalize: 更新状态，触发下一步
# Step 3: 查看进度
/pend codex # 查看 Codex 回复
/mounted # 检查 provider 状态
7.2 代码审查
# 使用 review skill
/review
# Claude 和 Codex 同时审查
# 对比两个模型的反馈
# Claude 综合决策
7.3 大型重构
# Phase 1: 多模型协作规划
/all-plan "将单体应用拆分为微服务"
# Phase 2: 创意收集
ask gemini "微服务拆分策略"
# Phase 3: 方案评审
ask codex "评估拆分方案的技术可行性"
# Phase 4: 执行 (Claude 主导，Codex/Gemini 辅助)
/tr
# Phase 5: 验证
/review
八、技术亮点
|
|
| Plan Mode |
|
| Provider 路由 |
|
| Auto-loop |
|
| 上下文转移 |
/continue
|
| 可恢复性 |
|
| 双重设计 |
|
| 双重评审 |
|
| 评分门控 |
|
结语
CCB (Claude Code Bridge) 是一个企业级多 AI 协作框架，核心思想：
- 质量保证 - 双重设计 + 双重评审 + 评分门控
- 自动化 - autoloop daemon 驱动自动执行
CCB 是 Unix 哲学的 AI 版本：cat 不知道 grep 的存在，但管道 (|) 让它们能构建复杂系统。CCB 就是这个"认知管道"。
附录：快速参考
核心命令速查
# 启停
ccb start # 启动 (需在 tmux 中)
ccb stop # 停止
ccb status # 查看状态
# Skills 管理
ccb-skills status # 查看 CCB Skills 状态
ccb-skills enable# 启用 CCB Skills
ccb-skills disable# 禁用 CCB Skills
ccb-skills toggle # 切换启用/禁用
# 调用模型
ask gemini "问题"# 异步调用 Gemini
ask codex "问题" # 异步调用 Codex
pend gemini # 获取回复
# 检查状态
ccb-mounted # 查看挂载状态
ccb-ping gemini # 测试连接
# 协作 Skills
/review # 双重审查
/all-plan "需求" # 多模型规划
/tp "任务" # 创建计划
/tr # 执行步骤
/file-op # 文件操作委托
/continue # 恢复上下文
/autonew gemini # 重置会话
配置文件位置
|
|
|
|
CLAUDE.md
|
|
|
.autoflow/roles.json |
|
|
~/.claude/skills/*/SKILL.md |
|
|
~/.claude/skills-ccb/ |
|
|
~/.claude/scripts/ccb-skills.sh |
|
|
./.ccb/*.session |
|
|
./.ccb/todo.md |
|
|
./.ccb/state.json |
|
|
./.ccb/plan_log.md |
|
|
./.ccb/history/*.md |
|
|
~/.cache/ccb/projects/*/pane-logs/ |
|
本文由 Claude 主笔，Gemini 提供创意输入，Codex 协助审查。
最后：最简单的多模型协作方式
如果觉得 CCB 的配置和 Skills 体系过于复杂，其实有一个最简单的方式——直接使用各模型的非交互式命令行 + YOLO 模式：
非交互式命令
# Gemini 非交互式
gemini -p "分析这段代码的架构问题"
# Codex 非交互式
codex "实现一个快速排序算法"
# 管道方式
cat code.py | gemini -p "重构这段代码"
git diff | codex "审查这个改动"
YOLO 模式（自动授权）
避免每次操作都要手动确认授权：
# Codex YOLO 模式 - 自动批准所有操作
codex --dangerously-auto-approve-everything "实现用户登录功能"
# 或者使用简写
codex --yolo "重构这个模块"
# Gemini 也有类似模式
gemini --yolo -p "分析整个项目的架构"
完整示例
# 一行命令完成代码审查
git diff main | codex --yolo "审查这个 PR，指出潜在问题"
# 让 Gemini 帮你写文档
cat src/auth.ts | gemini -p "为这个模块写 JSDoc 文档" > docs/auth.md
# Codex 直接修改代码
codex --yolo "修复 src/utils.ts 中的所有 TypeScript 错误"
这种方式虽然没有 CCB 的自动化流程、双重评审和状态管理，但对于单次任务（代码审查、问题分析、快速原型、自动修复）来说已经足够。CCB 的价值在于复杂、多步骤、需要持续跟踪的任务——如果你只是偶尔需要多模型协作，直接用命令行就好。
简单胜于复杂。工具是为了解决问题，不是制造问题。先用最简单的方式，复杂度需要时再引入。
粤ICP备14082021号
免费POC，
零成本试错
