第十六章 团队协作与流程复用

16.1 个人提效到组织提效的拐点

前面 15 章主要讲"你"怎么用 Codex。这一章讲"你的团队"怎么一起用。

这两件事的差别比你想象的大。

个人用 Codex，省的是你一个人的时间。一年大约多 50 个工作日。

团队用 Codex，省的是 N 个人的时间，且沉淀的是组织能力——新人入职即用，老人离职不带走经验。一年大约多 50N 个工作日，加上 5 年后回头看，整个团队的"工作方式"已经被重塑。

这才是真正改变企业的力量。

16.2 团队 Codex 化的三个阶段

阶段 1：个人各自用（自发期）

团队里几个人发现 Codex 好用，自己买 Plus 订阅，自己写 Skills，互相不知道对方在做什么。

特征：

• 每个人有自己的"高效区"
• 重复造轮子（A 写过的 Skill，B 又写了一遍）
• 知识不沉淀
• 离职就带走

适合的团队：还没决定"是否要全员推广"的小团队。可以让先用的人当"火种"。

阶段 2：团队共享 Skills 库（规范期）

明确决定全员用，建立共享 Skills 仓库，制定基本规范。

特征：

• 共享 team-skills Git 仓库
• 共享 team-AGENTS.md 模板
• 每周分享会："本周谁写了新 Skill"
• 新人入职第一天 clone 仓库就能干活

适合的团队：5-50 人的中型团队。

阶段 3：流程级整合（系统期）

Codex 不只是工具，是组织流程的一部分。CI/CD 里有 Codex GitHub Action，飞书 / Slack 里有 Codex 机器人，工单系统对接 Codex。

特征：

• "Codex 自己会做"取代了"派给某某做"
• 部分岗位重新定义（客服一线 → AI + 客服监督）
• 数据反哺：Codex 处理的任务回流到 Skills 优化
• KPI 体系开始考虑"AI 协作度"

适合的团队：50+ 人的成熟组织。

大多数团队从阶段 1 走到阶段 2 需要 3 个月，从阶段 2 到阶段 3 需要 1 年。不要跳级，每个阶段沉淀的东西都不能省。

16.3 第一步：选定"火种"

你不可能让 50 个人一起从零开始。找 2-3 个"火种"先跑通。

火种的特征：

• 对新工具有兴趣，愿意试
• 工作里有大量重复劳动（最先尝到甜头）
• 有一定的写作或文档能力（能把心得写下来）
• 在团队里有影响力（同事愿意听他说话）

让火种先用 1 个月，让他们：

• 摸清 Codex 的边界
• 沉淀 5-10 个真实可用的 Skills
• 整理一份"我们团队的 AGENTS.md 草稿"

1 个月后，火种已经是"团队 Codex 专家"。再让他们带其他人。

16.4 团队 Skills 仓库怎么建

仓库结构

team-skills/
├── README.md                        # 仓库说明、贡献指南
├── INDEX.md                         # 所有 Skills 的索引（自动生成）
├── CHANGELOG.md                     # 版本变更
├── .github/
│   └── workflows/
│       └── update-index.yml         # 自动更新 INDEX
├── skills/
│   ├── prd-review/
│   │   ├── SKILL.md
│   │   ├── references/
│   │   └── README.md                # 使用说明（给团队成员看的）
│   ├── meeting-minutes/
│   │   └── ...
│   ├── customer-faq/
│   │   └── ...
│   └── ...
└── docs/
    ├── how-to-write-skill.md        # 团队 Skill 写作规范
    ├── review-checklist.md          # Skill 审核清单
    └── case-studies/                # 各业务用 Skill 的真实案例

命名规范

避免冲突，用"业务域-操作"格式：

sales-quote-generator      # 销售-报价生成
support-ticket-classify    # 客服-工单分类
hr-resume-screen           # HR-简历筛选
finance-invoice-extract    # 财务-发票提取
content-topic-radar        # 内容-选题雷达

Skill 的 README

每个 Skill 旁边放一份给"团队成员"看的 README（区别于 SKILL.md，那个是给 AI 看的）：

# Skill: PRD 评审

## 这个 Skill 解决什么问题
PM 同学每周要评审多份 PRD，但维度容易遗漏、评分容易主观。
这个 Skill 提供"清晰度/可行性/商业价值/风险"四维度的客观评审框架。

## 谁应该用
- 产品经理
- 产品总监
- 技术 Lead（评估技术可行性）

## 什么场景用
- 收到一份 PRD，准备评审会前
- 自己写完 PRD 想自检
- 给新同事示范"PRD 评审标准"

## 怎么用

帮我评审这份 PRD（path/to/prd.md），调用 prd-review Skill

## 注意事项
- Skill 的评分是参考，最终判断还是人
- 评审结果要放到 reviews/ 目录归档（团队规范）
- 涉及商业敏感数据的 PRD 不要评审（数据外发）

## 反馈与迭代
- 用了不顺？给 #ai-tools 频道留言
- 想优化？发 PR 改 SKILL.md
- 维护人：@pm-team

这份 README 让"团队成员"在 1 分钟内决定"我要不要用这个 Skill"。

贡献流程

团队成员有了一个新想法
        ↓
开 Issue 描述场景（不要一上来就写代码）
        ↓
讨论：是否值得 Skill 化、用现有的能不能改造
        ↓
有共识 → 写 PR
        ↓
2 个人 review（一个 PM 角度，一个使用者角度）
        ↓
合并到 main，自动更新 INDEX
        ↓
全员邮件 / 群通知

跟代码 review 一样的流程。Skill 也是"团队资产"，要被认真对待。

同步到每个人本地

每个团队成员把团队 skills 仓库 clone 到 ~/.codex/skills/team/：

git clone git@github.com:yourteam/team-skills.git ~/.codex/skills/team

每天 / 每周 pull 一次拿最新：

cd ~/.codex/skills/team && git pull

可以做成定时任务，自动 pull。

16.5 团队 AGENTS.md 模板

每个项目仓库放一份基础 AGENTS.md，团队所有人都遵守：

# {项目名}

## 团队规约（继承自 team-AGENTS.md）

### 编码风格
（从团队规范继承）

### Git 流程
- 分支命名：feat/xxx, fix/xxx, docs/xxx
- Commit 用 Conventional Commits
- 不允许直接 push 到 main，必须走 PR
- PR 必须有至少 1 个 reviewer

### Code Review 边界
- AI 可以做"语法/风格"层 review
- 业务逻辑 review 必须人来做
- 安全相关代码必须 senior+ 来 review

### 数据安全
- 客户数据脱敏后才能给 AI 看
- 内部数据库 schema 不要外发
- 任何涉及金额、密码、密钥的代码必须人审

## 项目特定规则

### 技术栈
- ...

### 部署
- ...

### Boundaries

#### Always
- 改动核心模块前先在 group chat 同步
- 跑数据库迁移前在测试环境验证

#### Ask First
- 引入新依赖
- 改动 schema
- 改动 CI/CD

#### Never
- 不要直接连生产数据库
- 不要把 .env 推到任何分支
- 不要在 PR 描述里贴客户真实数据

16.6 团队场景实战：3 个最高 ROI 的应用

应用 1：标准化的代码 Review

每个 PR 提交后，Codex GitHub Action 自动:

1. 跑 lint + test
2. 调用 team-skills/code-review Skill 做"语法/风格/常见问题"层 review
3. 在 PR 评论里留下 AI review
4. 高级别的人只 review AI 漏掉的、AI 标"需要人判断"的

ROI：senior 节省 60% 的 review 时间，专注真正难的判断。第十九章详讲怎么做。

应用 2：跨部门"对账"自动化

财务跟销售对账，过去要相互导出 Excel、人工 VLOOKUP：

1. 设一个 Skill cross-team-reconcile
2. 每月 1 号 Automation 自动跑：
   • 拉销售系统的"应收"
   • 拉财务系统的"已收"
   • 自动匹配，差异列出
3. 财务和销售各自收到"差异清单"邮件
4. 人工只处理差异，不再对全表

ROI：5 人 × 2 天的对账压缩到 5 人 × 半天。

应用 3：新人入职"AI 副驾驶"

新员工入职第一天发本电脑，预装：

• Codex 桌面版
• 团队 skills 仓库 clone 好
• 个人 ~/.codex/AGENTS.md 模板（包含他的角色、团队、汇报关系）

新人的"AI 副驾驶"立即可用：

• "我是新来的产品 A，团队负责啥？" → 副驾驶答（基于团队知识库）
• "PRD 评审是什么标准？" → 副驾驶答（基于 prd-review Skill 的 references）
• "我这周该做什么？" → 副驾驶基于 onboarding Skill 给清单

ROI：新人上手时间从 1 个月压缩到 1 周。

16.7 团队 Codex 化常见的反对声音

推团队用 AI，会遇到一些反对。提前想好应对：

"AI 会取代我的工作"

回答：AI 取代的是"重复劳动"，不是"判断"。AI 让你少做体力活，多做需要脑力的事。具体到岗位：

• 客服：从"打字工"变"问题解决教练"
• 财务：从"录入工"变"分析师"
• HR：从"筛简历工"变"人才规划师"
• PM：从"文档工"变"策略制定者"

每一个升级，都是"更值钱的位置"。

"AI 会出错，我担责任"

回答：所以我们用"两层交付"工作流——AI 做，人审。最终决策和责任永远在人。

"学习成本太高"

回答：火种带新人，1 周入门。不是"学会编程"，是"学会指挥 AI"。

"数据安全怎么办"

回答：

• ChatGPT Business 协议下不用你的数据训练模型
• 敏感数据脱敏后再给 AI
• 真敏感的事用本地小模型
• 关键操作人审

第二十一章详讲。

"团队不齐心，有人不用"

回答：不强求所有人。先让 30% 的"愿意用的人"先跑通，做出明显业绩。其他人看到效果会主动跟上。

16.8 团队 Codex 化的 KPI

怎么衡量团队 Codex 化的效果？建议三个层次的 KPI：

行为层（短期）

• 团队 Skills 库里 Skills 数量
• 月活跃 Skills 数（被调用过的）
• 团队 AGENTS.md 完整度（覆盖了多少项目）
• 每人每月 Codex 会话数

效率层（中期）

• 重复任务平均耗时变化
• 单个 PR 的 review 周期
• 新人入职到独立产出的时间
• 报告 / 文档的产出量

结果层（长期）

• 团队人均产出
• 客户响应速度
• 错误率
• 员工满意度

前两层 1-3 个月能看到效果，第三层要 6-12 个月。

16.9 一个真实案例

某 50 人的 SaaS 公司客户成功团队，2025 年 12 月开始 Codex 化。

起点：3 个火种（一个 CSM、一个文档工程师、一个数据分析师）。

3 个月：搭起 12 个团队 Skills（客户回复模板、续费分析、健康度评估、月度报告...），全员开始用。

6 个月：客户回复响应时间从 4 小时 → 30 分钟。续费分析从每月 1 周 → 每月 2 天。新员工入职 → 独立产出从 4 周 → 1 周。

12 个月：团队人数没变（仍 50 人），但服务客户数从 1200 → 2400。客户满意度（NPS）从 +28 → +47。

关键学习：

1. 火种很重要（前 3 个月主要靠他们）
2. Skills 库是核心资产（后期所有效益都来自这里）
3. 不强求所有人立即用（30% → 70% → 95%，自然增长）
4. 节省的时间不是用来 layoff，是用来做"过去想做但没时间做"的事（更深度的客户研究、更精细的产品反馈）

16.10 一个常被忽略的好处

团队 Codex 化的最大好处，不是省时间，是知识不再随人走。

过去：销售老 A 离职，他脑子里"怎么对付难搞客户"的 know-how 全带走了。

现在：销售老 A 用过的 customer-handle Skill 留在团队仓库，他写过的 review 全在 commit 历史里，他建立的 references/customer-types.md 文档还在。新人接手，AI 副驾驶基于这些资料让他"上手就有 80% 老 A 的能力"。

这是组织级的"知识基础设施"。值钱的不是 Skills 本身，是"沉淀过程"和"复用机制"。

16.11 团队 Codex 化的 100 天行动清单

如果你是团队负责人，下面这份清单作为参考：

第 0-30 天：选定火种
[ ] 选 2-3 个火种（自愿 + 高潜）
[ ] 给火种 1 周时间集中学习（看这本书 + 实操）
[ ] 火种产出第一批 Skills（5 个起步）
[ ] 建立 #ai-tools 内部频道

第 31-60 天：建仓库
[ ] 建 team-skills 仓库
[ ] 写第一版 team-AGENTS.md
[ ] 火种把现有 Skills 整理进去
[ ] 写"贡献指南"和"使用指南"
[ ] 邀请 5-10 个早期采用者

第 61-90 天：扩散
[ ] 全员宣讲会（火种讲 + 早期采用者作证）
[ ] 1 对 1 帮 30% 的人入门
[ ] 每周一次"Skills Show"分享会
[ ] 收集反馈，迭代规范

第 91-100 天：评估
[ ] 收集 KPI 数据
[ ] 复盘：哪些 Skills 有效、哪些没人用
[ ] 决定下一步：扩到全员？深化某些场景？接 CI/CD？

16.12 本章小结

• 团队 Codex 化分三阶段：自发 → 规范 → 系统，3 个月一阶段
• 第一步：选 2-3 个火种，给他们 1 个月时间
• 团队 Skills 仓库结构：skills/ + docs/ + INDEX/CHANGELOG
• 团队 AGENTS.md 模板包含：编码风格 / Git 流程 / Code Review 边界 / 数据安全
• 三个最高 ROI 应用：标准化 Code Review / 跨部门对账 / 新人 AI 副驾驶
• KPI 三层次：行为 / 效率 / 结果，对应短中长期
• 真正价值：知识不随人走，组织级"知识基础设施"
• 100 天行动清单可直接套用

第五篇结束。下一篇我们到"高手篇"，看看 Codex 怎么跟其他工具组合发挥更大威力。第十七章 · Codex 与其他工具。