你好，我是joe45。

0. 读者速览

• 适用人群：已经搭好Codex基建（AGENTS.md + 分支策略 + CI/CD），想解锁原生工作流深度玩法的人
• 前置阅读：10人团队AI协作30天完整复盘：AGENTS.md配置+5分支Git+Agent角色矩阵（附脚本）
• 本篇覆盖：5个原生能力 — 线程拆分、Plan、Skills、Review+Cron、角色线程
• 阅读时长：约10分钟
• 可复现性：所有命令和配置可直接复制

---

1. 上篇之后还差什么

上篇落地了三件事：AGENTS.md立规矩、5分支管代码、角色矩阵分工种。

效果立竿见影：代码风格统一了，合并冲突从日均8次降到1次，PR从4小时缩到20分钟。

但跑了一段时间，我发现"不乱"不等于"高效"。新问题浮出来了：

问题1：一个线程里什么都有，AI的上下文被冲散

我在一个线程里同时说了"加登录API、改数据库表、修一个bug"，AI写着登录忽然跑去改数据库了——因为它觉得"数据库改了登录才好写"。

问题2：AI一上来就写代码，方向错了整段白费

我让AI做OIDC+LDAP双认证，它写了3天，review才发现连LDAP的DDL都没建。重来，3天白费。

问题3：同样的配置，每次要重新描述一遍

“加日志，JSON格式，输出到stdout，带trace ID，更新requirements.txt”——每换一个项目说一遍，偶尔漏条件结果就不对。

问题4：代码合进去了，上线两天才发现有Bug

review了，但AI自己写的代码让自己review——它不太会找自己的茬。

这些问题的根因是：基建（AGENTS.md+分支）解决的是"不乱"，但要让AI"出好活"，需要Codex的原生工作流能力。

下面5个能力，按我的实践顺序排列：先改线程习惯，再上Plan保方向，再用Skills提效率，然后Review+Cron守质量，最后用角色线程做分工。

---

2. 线程拆分与依赖管理

这是所有进阶能力的前提。线程不拆分，Plan/Skills/Review全用不好。

2.1 为什么必须拆

Codex每个线程维护独立的上下文窗口。一个线程里塞了太多内容，AI会"迷失优先级"——它觉得改数据库表比修bug重要，就先去改表了。

我的规则：一个线程只做一件事。

场景	❌ 错误做法	✅ 正确做法
开发登录功能	一个线程：加登录API + 改用户表 + 修bug	3个线程各做一件
写新模块	一个线程：写完全部再交	按模块拆：路由→逻辑→测试→文档
重构	一个线程：一个重构全做完	拆成小步骤，每步独立提交

2.2 依赖声明

当一个线程依赖另一个线程的输出时，在描述里写明：

codex thread new --title "[FEATURE] 实现用户登录API" \
  --description "依赖 #12 的用户表迁移完成，需对接用户表结构和密码加密方法"

这样AI读到这个依赖说明，会先检查前置条件是否满足，不会"假设表已经建好了"。

2.3 命名规范

用[]标签表明任务类型，方便后续用tag过滤和管理：

标签	用途	示例
[FEATURE]	新功能	[FEATURE] JWT验证中间件
[BUGFIX]	修bug	[BUGFIX] 用户登录状态缓存失效
[REFACTOR]	重构	[REFACTOR] 用户模块统一OAuth2
[PLAN]	计划	[PLAN] 订单状态机设计
[CRON]	定时	[CRON] 每日回归测试
[DOCS]	文档	[DOCS] API接口文档更新

这意味着：你同时开5个线程，相当于5个AI在并行开发互不干扰。人只需要在关键节点介入（Plan审批、Review确认），其余时间5个线程自己跑自己的。

实测：拆分前一个"用户系统重构"线程跑了5天才完成，因为AI在不同子任务之间反复切换上下文。拆分后4个线程并行，2天完成，人只介入3次（Plan确认×1 + Review×2）。

---

3. Plan：先设计，后编码

多数人用AI的习惯：需求写进去 → AI直接出代码 → 检查 → 改bug。

这套流程有个致命问题——AI的第一次输出决定了你的最低返工成本。方向对了，只需要微调。方向错了，返工成本是3-10倍。

3.1 什么时候必须Plan

必须Plan	不需要Plan
涉及3个以上文件修改	单一文件的增删改
涉及数据库变更或API重构	纯配置修改
涉及安全、权限、支付	简单的工具函数
涉及外部系统集成	代码格式化

3.2 怎么用

在线程中输入：

/plan 我要重构用户认证模块，当前有3个API使用不同鉴权方式，目标统一为OAuth2。
请给出详细步骤，包括：受影响文件列表、中间件设计、测试策略、回滚方案。

AI输出的Plan包含完整设计。你确认后它才开始写代码。如果计划有漏洞，直接在Plan上修改，不用等代码写出来再debug。

3.3 跨线程Plan

对于涉及多个实现线程的大计划：

codex thread new --title "[PLAN] 订单系统状态机设计"

产出的Plan文档存为 docs/plans/order_state_machine.md。实现线程通过 @ 引用：

@docs/plans/order_state_machine.md，请实现CREATE_ROUTE状态

这意味着：一个Plan线程产出架构设计，多个开发线程各自执行自己的部分，方向一致不冲突。相当于你请了一个架构师把方案写清楚，然后3个开发各自领任务。

我的数据：Plan消耗15%的开发时间，但返工率从35%降到了5%。花15分钟做的Plan，省下的是3-5小时的无意义返工。

---

4. Skills：一次沉淀，永久复用

这是ROI最高的一个能力——花30分钟写一个Skill，之后每次调用都是净收益。

4.1 问题在哪

每次让AI做同样的事都要重新描述一遍：

“加日志，JSON格式，输出到stdout，带trace ID和请求耗时，日志级别从环境变量读，还要自动更新requirements.txt……”

今天说一遍，做对了。明天换线程，再说一遍。漏了一个条件，结果有偏差。下周项目多了，不记得上次怎么说的——再描述一遍。

Skills就是把这些"经常让AI做的事"写成SOP，下次一句话执行。

4.2 创建你的第一个Skill

在项目里建 skills/add_logging.md：

# Skill: 添加结构化日志

## 触发条件
用户要求"为项目添加日志"或"接入日志系统"

## 步骤
1. 检查是否存在 /src/utils/logger.py，若无则创建
2. 使用 logging + python-json-logger 配置JSON格式输出
3. 在 main.py 中调用 `setup_logging()`
4. 在其它模块中使用 `from utils.logger import get_logger`

## 输出要求
- 提供配置示例（环境变量 LOG_LEVEL）
- 自动更新 requirements.txt

然后在任何线程中：

/skill add_logging

AI按标准流程执行，效果100%一致。

4.3 Skills的三个层次

层次	内容	示例	创建耗时	ROI
L1 工具型	单一标准流程	加日志、加测试、生成Dockerfile	15-30分钟	每次调用省3分钟
L2 流程型	多步骤协作	新增API模块（路由+逻辑+测试+文档）	45分钟	每次调用省15分钟
L3 策略型	涉及决策	重构策略、数据库迁移方案	1小时	每次调用省30分钟+

从L1开始，跑通3个工具型Skills。我自己的经验：一个月沉淀12个Skills，80%的重复配置工作变成了一句话。

这意味着：Skills是你最值得投资的"AI数字资产"。换项目、换电脑、换AI工具——Skills文件直接带走。你的经验不再是记在脑子里，而是沉淀为可执行的SOP。

---

5. Review + Cron：质量把关 + 自动化巡检

5.1 Review：不要让AI自己检查自己

AI写的代码让AI自己review——天然有问题。它写的时候满足的条件，review的时候也满足。它不会主动找自己的茬。

解法是 定向审查：不笼统说"review这段代码"，而是指定审查维度。

三看策略（由浅入深）：

# 第一步：安全审查（入门）
/review --focus=安全

输出示例：

• 输入参数未做类型校验 → SQL注入风险
• 用户ID直接从URL取 → 越权风险
• 密钥硬编码 → 泄漏风险

# 第二步：性能审查（进阶）
/review --focus=性能

• 循环里反复查数据库 → N+1问题
• 接口未分页 → 大结果集内存溢出
• 热路径上做日志序列化 → 性能损耗

# 第三步：可维护性审查（高级）
/review --focus=可维护性

• 函数超过100行 → 建议拆分
• 缺少类型注解 → 建议补充
• 魔法数字硬编码 → 建议提取常量

入门建议：先只做安全审查一项。等跑顺了再加性能和可维护性。第一次就上三把斧，AI输出太长的Review报告你反而不会逐条看。

我的数据：引入安全Review后拦截的线上问题从每月3次降为0。最值的一次是圈出了"用户密码明文日志输出"——这个问题不解决等于把密码写在门板上。

5.2 Cron：让AI当值夜班

Cron是Codex的定时任务能力。我主要用来做两件事：

每日自动回归测试：

codex cron add --schedule "0 2 * * *" \
  --thread-name "[CRON] 每日回归测试" \
  --action "/test run"

每日全量安全审查：

codex cron add --schedule "0 3 * * *" \
  --thread-name "[CRON] 每日安全审查" \
  --action "/review --all --focus=安全 /src"

每天早上醒来，你收到的不是"出bug了"的告警，而是：

[CRON] 每日安全审查 — 2026-06-11 报告
- 已审查：47个文件
- 高风险：0
- 中风险：2（见附件）
- 低风险建议：5

这意味着：代码质量不是靠自觉，而是靠制度。AI在你睡觉的时候帮你把全量代码筛了一遍。之前上线前要花半天做回归测试，现在每天自动跑，上线前10分钟看一眼报告就够了。

---

6. 角色线程：用–role让AI分"工种"

角色矩阵在上篇的角色定义基础上更进一步：Codex原生支持--role参数，启动不同"工种"的专用线程。

6.1 在AGENTS.md中定义角色

## 角色定义
- [架构师] 负责设计评审，使用 /plan 输出完整方案
- [后端工程师] 实现业务逻辑，自动执行 /review
- [QA工程师] 编写测试用例，触发 /test run
- [运维工程师] 管理定时任务和MCP连接

6.2 启动角色线程

codex thread new --role 架构师 --title "设计订单状态机"

AI以架构师风格对话：先出方案、列风险、提替代方案，而不是上来就给代码。

codex thread new --role QA工程师 --title "为用户模块生成边界测试用例"

AI以QA风格对话：等价类划分、边界值分析、异常场景覆盖。

这意味着：一个项目内，你同时有一个"写设计方案"的架构师、一个"写代码"的开发、一个"找茬"的QA。三个线程各干各的，分工明确。

实用技巧：对于单人开发者，最推荐的配置是「1个Plan线程 + 2个开发线程 + 1个Review线程」。Plan线程负责设计，开发线程负责实现，Review线程负责挑刺。4个线程并行，相当于你组了一个4人小队。

---

7. 上篇 + 本篇，完整能力矩阵

能力	层级	上篇	本篇	一句话
AGENTS.md	基建	✅	—	AI的行为规范
5分支模型	基建	✅	—	代码管理秩序
Agent角色定义	基建	✅	—	AI分工框架
CI/CD自动化	基建	✅	—	发布自动化
线程拆分	进阶	—	✅	一个线程只做一件事
Plan	进阶	—	✅	先设计后编码，保方向
Skills	进阶	—	✅	SOP沉淀，提效率
Review	进阶	—	✅	定向审查，守质量
Cron	进阶	—	✅	自动巡检，省人力
角色线程	进阶	—	✅	–role分工种

搭的顺序：上篇保"不乱"，本篇保"好用"。

---

8. 先说结论，再选路径

上篇做了，这篇可以不做吗？

可以。如果你团队小、项目简单、每天产出有限，上篇的基建能力已经够用。

但如果出现下面任何一个信号，建议把这5个能力补齐：

信号	对应的能力
AI写着写着跑偏了	线程拆分：一个线程只做一件事
写完后发现方向错了	Plan：强制先设计后编码
同样的事情每次都要重说	Skills：一次沉淀永久复用
代码上线后冒出安全/性能问题	Review+Cron：自动审查+每日巡检
让AI干不同工种的事，行为都一样	角色线程：用–role区分角色

先练哪一个？按这个顺序：

线程拆分（改习惯，免费） → Skills（ROI最高，30分钟回本） → Plan（降返工） → Review（守质量） → Cron（自动化） → 角色线程（进阶分工）

---

9. 总结

一句话说清楚这5个能力的本质：

线程拆分管边界，Plan管方向，Skills管效率，Review+Cron管质量，角色线程管分工。

上篇给AI画了"围栏"，这篇给AI装了"引擎"。两篇合在一起，不管你是一个人还是10人团队，Codex都能从"代码生成器"变成"你信得过的开发队友"。

下篇考虑从 树状目录结构、分阶段使用流程、真实场景案例，以及团队/个人两种开发模式的完整操作指南来写。

或者，

评论区说说：你最想知道的是哪个能力的细节？我下篇拆开来写。

---

关于作者：joe45，二十年技术老兵，独立开发者。专注AI开发效能，所有方法论均来自亲身实践。

一个人 + AI = 一家公司。