实战 C3：大型项目中的双工具策略——团队级分工、工具标准化与冲突避免
# 大型项目双工具策略
## 团队分工矩阵
- 角色与工具匹配
- 按服务分配工具
- 按任务阶段分配
## 工具标准化
- 共享配置层
- 统一 Skills 仓库
- 代码审查流水线
## 冲突避免
- 文件锁约定
- Git 分支命名规范
- 工作区隔离策略
当一个团队同时使用 Codex 和 Claude Code，最大的挑战不是"哪个工具更好"，而是"如何让 20 个人 + 2 个 AI 工具不打架"。本文从真实团队经验出发，给出可复制的策略框架。
案例 1：团队级工具分工——谁用什么、什么时候用
背景：一个 20 人的平台团队，维护 10 个微服务 + 2 个前端应用。
按角色分配
| 角色 | 主要工具 | 次要工具 | 原因 |
|---|---|---|---|
| 前端开发 (4人) | Codex | Claude Code | 快速迭代，Fast mode |
| 后端开发 (8人) | Codex | Claude Code | 日常 CRUD + TDD |
| 架构师 (2人) | Claude Code | Codex | 深度分析，架构审查 |
| DevOps (2人) | Codex | — | Automations 定时任务 |
| QA (2人) | Claude Code | — | 安全审查，深度测试生成 |
| Tech Lead (2人) | 两者都用 | 两者都用 | 审查 + 决策 + 自动化 |
按服务分配
不是所有服务都需要同样的 AI 策略：
| 服务 | 工具策略 |
|---|---|
| 前端 (web, admin) | Codex 主力 + Fast mode —— 原因：迭代快，需要频繁的 UI 调整 |
| API 网关 (gateway) | Claude Code 主力 —— 原因：高流量入口，安全性和性能要求严格 |
| 核心业务 (orders, payment, users) | Codex 日常开发 + Claude Code 审查 —— 原因：需要质量和速度的平衡 |
| 辅助服务 (notif, analytics) | Codex 为主，轻量模型 —— 原因：改动频率低，成本敏感 |
| 基础设施 (terraform, Docker, CI) | Codex 为主 + Automations —— 原因：配置标准化，适合自动化 |
按任务阶段分配
| 阶段 | 工具 | 说明 |
|---|---|---|
| 需求分析 | 两者都能 | 低风险阶段，随便用 |
| 方案设计 | Claude Code | /plan + /deep-research |
| 代码实现 | Codex | TDD 闭环 |
| 单元测试 | Codex | 随代码一起生成 |
| 集成测试 | Codex | Cloud Tasks 并行跑 |
| 代码审查 | Claude Code | /code-review effort=high |
| 安全审查 | Claude Code | /security-review |
| CI/CD | Codex | Automations 定时触发 |
| 部署 | Codex | Cloud Tasks 或 Automations |
| 监控与告警 | Codex | Automations 定时检查 |
案例 2：工具标准化——统一配置层
项目根目录结构
platform/
AGENTS.md ← 唯一真相源，两个工具共享
CLAUDE.md → AGENTS.md ← 符号链接
.codex/ ← Codex 专属
config.toml
skills/ ← Codex Skills
db-migration/SKILL.md
release/SKILL.md
.claude/ ← Claude Code 专属
settings.json
skills/ ← Claude Code Skills
deep-review/SKILL.md
deploy/SKILL.md
incident/SKILL.md
.gitignore ← 包含两个工具的忽略规则
.gitignore
# Codex
.codex/logs/
.codex/cache/
# Claude Code
.claude/logs/
.claude/cache/
团队 Onboarding Checklist
新成员加入时，自动脚本完成配置：
#!/bin/bash
# setup-ai-tools.sh
# 1. 安装工具
brew install codex claude-code
# 2. Clone 配置仓库（如果有独立的配置 repo）
git clone git@github.com:team/ai-config.git ~/ai-config
# 3. 创建符号链接
cd ~/projects/platform
ln -sf ~/ai-config/AGENTS.md AGENTS.md
ln -sf AGENTS.md CLAUDE.md
cp -r ~/ai-config/.codex/skills .codex/
cp -r ~/ai-config/.claude/skills .claude/
# 4. 验证
codex --version
claude --version
echo "AI tools ready. Start with: codex or claude"案例 3：冲突避免——当 20 人 + 2 个 AI 同时工作
策略 1：Git 分支命名约定
分支命名格式：<tool>/<type>/<description>
示例：
codex/feat/orders-endpoint ← Codex 开发的新功能
codex/fix/payment-rounding ← Codex 修的 bug
claude/refactor/auth-module ← Claude Code 做的重构
claude/security/fix-sql-inject ← Claude Code 发现并修复的安全问题
好处：
- CI 可以根据分支前缀选择不同的验证策略
- 审查者一眼知道这个 PR 是哪个工具主导的
- 回滚时知道该用什么工具修复
策略 2：文件级"锁"约定
在大型重构期间，建议的团队约定：
# TEAM.md (团队工作约定)
## AI Tool File Ownership
在进行跨文件重构时：
1. 在 Slack #eng-ai 频道声明你要修改的文件范围
2. 格式：@here Taking ownership of services/orders/** for the next 2 hours (Claude Code refactor)
3. 其他人（和其他 AI 工具）在这期间不要修改这些文件
4. 完成后在频道声明释放
策略 3：审查隔离
| PR 类型 | 审查策略 |
|---|---|
| codex/feat/* | Claude Code 初审 → 人工复审 |
| claude/refactor/* | Codex 初审 → 人工复审 |
| codex/fix/* | 人工直接审查（改动小） |
| human/* | 两个 AI 都审查，结果对比 |
这个策略的核心：让 AI 审查另一个 AI 的代码，人工审查两者的交叉结果。
策略 4：自动化监控——防止工具跑偏
用 Codex Automations 设置护栏：
自动化 1：每天早上 9:00
检查所有 open PR 的 CI 状态。
如果 codex/feat/* 的 PR 中有类型错误，自动推修复。
如果 claude/refactor/* 的 PR 中有测试失败，通知对应开发者。
自动化 2：每 4 小时
扫描 platform/ 根目录，检查是否有不在 .gitignore 中的工具生成文件。
如果有，通知 #eng-ai 频道。
自动化 3：每次 PR merge 后
对比 AGENTS.md 和 CLAUDE.md 是否同步（如果 CLAUDE.md 是 symlink 则自动同步）。
如果 AGENTS.md 被修改，提醒更新相关 Skills。
大型项目的成本控制
两个工具同时使用意味着双份成本。团队级的成本控制策略：
分层模型策略
| 任务复杂度 | Codex 模型 | Claude Code effort |
|---|---|---|
| 简单（格式化等） | gpt-5.4-mini | 不用 |
| 日常开发 | gpt-5.5 medium | 不用 |
| 复杂功能 | gpt-5.5 high | effort=medium |
| 架构重构 | gpt-5.5 high | effort=high |
| 安全审查 | 不用 | effort=high + /security-review |
| 批量迁移 | 不用 | ultracode (谨慎使用) |
成本监控自动化
# 每周一自动运行的成本报告
# 放在 Codex Automation 中
统计上周的 API 使用情况。
Codex: 列出 token 消耗 top 5 的会话
Claude Code: 列出 token 消耗 top 5 的会话
如果某个会话的 token 超过 [阈值]，标记为异常并通知 Tech Lead。一个真实的混合工作流：从 Issue 到 Deploy
展示一个完整的端到端流程：
flowchart TB
A[Issue 创建] --> B[性能分析<br/>Claude Code]
B --> C[方案设计<br/>Claude + 人工]
C --> D[代码实现<br/>Codex 并行]
D --> E[代码审查<br/>Claude Code]
E --> F[安全审查<br/>Claude Code]
F --> G[集成测试<br/>Codex Cloud Tasks]
G --> H[部署 Staging<br/>Codex]
H --> I[监控验证<br/>Codex Automation]
I --> J[合并 PR]
classDef codex fill:#2563eb,color:#fff,stroke:#1d4ed8
classDef claude fill:#d97706,color:#fff,stroke:#b45309
classDef neutral fill:#6b7280,color:#fff,stroke:#4b5563
class A,J neutral
class D,G,H,I codex
class B,C,E,F claude
总共 10 步，Codex 执行了 6 步（实现、测试、部署、监控），Claude Code 执行了 3 步（分析、方案、审查），人工执行了 1 步（方案确认）。这就是 AI 辅助开发的最佳配比。
总结
大型项目中使用双工具的核心原则：
| 原则 | 说明 |
|---|---|
| 角色匹配 | 根据团队成员的角色分配主要工具 |
| 服务匹配 | 核心服务用强推理，辅助服务用低成本 |
| 阶段匹配 | 实现用 Codex，审查用 Claude Code |
| 分支约定 | <tool>/<type>/<desc> 命名，可追踪 |
| 审查隔离 | AI 审查 AI，人工审查交叉结果 |
| 成本监控 | 自动化报告，异常标记 |
| 护栏机制 | Automations 做持续监控，防止跑偏 |
回到系列开头：A1: Codex 项目初始化与配置实战
实操清单
- 为团队制定工具分配矩阵（按角色、按服务、按任务阶段）
- 创建
setup-ai-tools.sh自动化 onboarding 脚本 - 建立 Git 分支命名规范：
<tool>/<type>/<description> - 设计审查隔离策略：AI 审查 AI 的代码，人工审查交叉结果
- 设置自动化护栏：监控 PR CI 状态、工具生成文件、配置同步
- 建立成本监控自动化：每周统计 token 消耗 top 5，标记异常
- 实践一次完整的 Issue → Deploy 混合工作流