0. 读者速览

• 适用人群：独立开发者、小团队技术负责人、一个人从零到一搭项目的人
• 前置阅读：无强制要求，但建议先读基础篇了解AGENTS.md和分支策略
• 本篇不同：不讲功能，讲"一个人怎么戴5顶帽子，跑完一个项目的全流程"
• 阅读时长：约12分钟
• 可复现性：所有线程命令、角色提示词、交接文档均可直接复制

---

1. 3个月前的一个下午

我在终端前坐了很久。

项目deadline两周后。没有产品经理、没有架构师、没有QA、没有运维。只有我，一个后端开发。

以前我遇到这种情况，选择很简单——熬夜。

但那一次，我试了一个不一样的做法。我打开Codex，开了5个线程，装了5顶不同的帽子。然后我发现了一件事：

我一个人，活成了一支AI开发队。

这不是比喻。从需求拆解到方案设计到编码测试到部署上线，5个角色线程接力跑完。人只做决策和把关，执行全交给AI。

下面是我的完整实操记录。

---

2. 角色切换框架：一顶帽子一个线程

先说我怎么组织这5个线程。

project/
├── .codex/
│   └── agents/              # 角色定义文件
│       ├── pm.md
│       ├── architect.md
│       ├── backend.md
│       ├── qa.md
│       └── devops.md
├── AGENTS.md                # 项目"宪法"
├── docs/
│   ├── requirements/        # 角色1 PM产出：需求文档
│   ├── plans/               # 角色2 架构师产出：设计方案
│   ├── specs/               # 角色3 开发产出：接口规范
│   └── reviews/             # 角色4 QA产出：审查报告
└── ...src code

核心规则很简单：一顶帽子 = 一个独立线程。 线程结束时的产出，就是下一个线程的输入。

角色	线程标签	核心产出	下一个谁用
🎩 产品经理	[PM]	需求文档 + 验收标准	架构师
🎩 架构师	[ARCH]	技术方案 + 模块划分	开发
🎩 后端开发	[DEV]	可运行代码 + 接口文档	QA
🎩 QA	[QA]	审查报告 + 测试用例	运维
🎩 运维	[OPS]	部署脚本 + Cron任务	—

每一顶帽子之间的"交接"只有一次对话。5个线程走完，一个完整功能上线。

---

3. 实战日记：一个订单系统，5天跑完全流程

下面的内容来自我的实操记录。项目是"做一个订单系统"，支持创建订单、支付回调、查询列表。

我按时间顺序写，你可以跟着走一遍。

Day 1 上午：戴上PM的帽子

我开了一个线程：

codex thread new --title "[PM] 订单系统需求定义"

然后我告诉Codex（用的是日常对话，不是命令）：

我要做一个订单系统。用户在前台下单，支付后订单状态更新，管理员可以查看订单列表。你以产品经理的身份，帮我输出需求文档和验收标准。

Codex输出了这样的结构：

# 订单系统需求文档 v1

## 功能列表
1. 创建订单（用户选择商品 → 填写信息 → 提交）
2. 支付回调（微信/支付宝异步通知 → 更新状态）
3. 订单查询（按状态/时间过滤，分页）

## 验收标准
- 创建订单：必填项校验（商品ID、数量、金额）
- 支付回调：重复通知不会重复扣款（幂等）
- 订单查询：响应时间<200ms，支持排序

我做了两件事：

1. 加了一条验收标准：创建订单时需库存预扣（这个Codex没想到）
2. 把确认后的文档存到 docs/requirements/order_system.md

然后关闭这个线程。PM的活干完了，15分钟。

Day 1 下午：换上架构师的帽子

新开一个线程：

codex thread new --role 架构师 --title "[ARCH] 订单系统技术方案"

这次不是写需求了。我把PM线程的产出塞给它：

@docs/requirements/order_system.md
请以架构师的身份，输出技术方案：数据库设计、API端点定义、模块划分、风险评估。

Codex输出的方案包含：

# 订单系统技术方案 v1

## 数据库设计
- orders表：id, user_id, product_id, amount, status, created_at, updated_at
- order_items表：order_id, product_id, quantity, price
- payment_logs表：order_id, channel, trade_no, status

## API设计
- POST /api/orders（创建订单）
- POST /api/orders/callback（支付回调）
- GET /api/orders（查询列表）

## 风险评估
- 幂等性：支付回调需用唯一流水号去重
- 并发：库存扣减需加锁或使用乐观锁

我做了两件事：

1. 补了一条风险：回调接口没有认证，任何人伪造回调都能改订单状态 ——这个Codex漏了
2. 确认方案，存为 docs/plans/order_design.md

架构师的活也干完了，20分钟。

一个经验：架构师输出的方案通常有90%是对的。但那10%的漏洞往往是致命的（比如安全性）。人对方案的把关价值，远大于人对代码的review。

Day 2-3：戴上开发者的帽子

这一步开始并行。

codex thread new --role 后端 --title "[DEV] 实现订单创建接口"
codex thread new --role 后端 --title "[DEV] 实现支付回调接口" --description "依赖 #3 订单表结构"

开发线程里，我用了之前沉淀的Skills：

/skill add_logging
/skill add_unit_tests

然后告诉AI：

按 @docs/plans/order_design.md 实现订单创建接口。使用FastAPI，调create_app Skill，加事务处理。

AI输出代码后，我加了一步：

/review --focus=安全

AI反馈了2个问题：

• 金额字段直接用float计算 → 建议改用Decimal
• 创建订单时用户ID从请求体取 → 建议从JWT取

我修复后，代码合入dev分支。

这里要说明：戴开发帽子的时候，我不要求自己懂全部细节。我只把握"有没有按方案实现"和"review报的问题有没有修掉"两个关口。

Day 4 上午：戴上QA的帽子

codex thread new --role QA --title "[QA] 订单系统集成审查"

告诉AI：

审查已合入dev的订单系统代码。使用 /review --focus=安全,性能 检查全量变更。

然后我把结果里的阻塞项修掉，非阻塞项记下来。

翻到一个有意思的：订单查询接口没加分页，如果某个用户有10万条订单，接口会炸。 这在开发线程里没暴露出来，因为测试数据只有3条。

QA的价值体现出来了。

Day 4 下午：戴上运维的帽子

codex thread new --role 运维 --title "[OPS] 订单系统部署配置"

告诉AI：

为订单系统配置：Dockerfile + docker-compose + GitHub Actions部署 + 每日Review Cron。

配置完Cron后，我多问了一句：

部署后第一周，你应该监控什么指标？

Codex列了5个：接口成功率、平均响应时间、订单创建失败率、支付回调延迟、数据库连接数。

我把这个记到了部署文档里。

Day 5：回顾

5天，5个角色线程。最终的产出：

docs/
├── requirements/order_system.md    ← PM产出
├── plans/order_design.md           ← 架构师产出
├── specs/order_api.md              ← 开发补充
└── reviews/order_review.md         ← QA产出

src/orders/                           ← 完整代码
├── models.py
├── routes.py
├── services.py
├── test_orders.py
└── ...

deploy/                               ← 运维配置
├── Dockerfile
├── docker-compose.yml
└── .github/workflows/deploy.yml

如果让一个人写所有代码+文档，大概需要8-10天。5个角色线程+人的关键把控，压缩到5天。 (算入人工检查时间。只是想要快，可以更快。)

---

4. 角色切换的底层心法

技术操作上面都写了。下面说点"软"的——怎么让自己真的像换了一个人。

我每开一个新线程，会做三件事：

第一，读一遍AGENTS.md里该角色的定义。

## 角色: 架构师
你的工作是输出可执行的方案，不是写代码。
你的交付标准是：开发拿到方案不需要再问你任何问题。

这句话读一遍，脑子就切换过来了。

第二，在脑子里过一遍"这个角色最关心什么"。

• 🎩 PM关心：价值。 做这个功能值不值？验收标准够不够？
• 🎩 架构师关心：扩展性。 这个设计能支撑未来6个月的需求变化吗？
• 🎩 开发关心：可行性。 这个方案按当前技术栈能不能实现？
• 🎩 QA关心：边界。 正常流程走得通，异常流程有处理吗？
• 🎩 运维关心：可观测性。 出问题了能第一时间知道吗？

第三，用该角色的语气跟Codex说话。

戴PM帽子时，我说的是"帮我想清楚这个功能的价值"。
戴架构师帽子时，我说的是"先把方案摆出来，出了问题我担着"。
戴QA帽子时，我说的是"别跟我说它跑通了，跟我说它什么情况下会挂"。

语气变，思维就变了。

切换角色的秘诀不在于告诉AI，在于告诉自己。 AI会根据你的指令自动匹配行为模式，但你得先把自己放进那个角色里。

---

5. 同一个项目，两种跑法

环节	传统单人开发	角色线程模式
需求	脑子里想一下就开始写	开PM线程，输出文档存起来
设计	边写边想，写到哪改到哪	开架构师线程，先出方案再动手
编码	一个线程从头写到尾	按功能拆多个DEV线程并行
测试	跑一下没报错就算过	QA线程定向审查，不只看有没有bug
部署	手动部署，出了问题才知道	OPS线程配置自动化，Cron定期巡检
人做的事	所有事	决策+把关（占20%时间）
AI做的事	写代码	需求分析+方案设计+编码+测试+部署
返工率	35%	<5%
8天工作量	一个人硬扛8天	5天跑完全流程，每天只投入2小时

---

6. 怎么搭建你的"虚拟团队"

你不需要一上来就建5个角色。从最少的开始：

起步版（3个角色，1天搞定）

# 角色1：架构师
codex thread new --role 架构师 --title "[ARCH] 需求分析与方案设计"
# 这步产出方案文档

# 角色2：开发
codex thread new --role 后端 --title "[DEV] 实现功能"
# 这步产出代码

# 角色3：QA
codex thread new --role QA --title "[QA] 代码审查"
# 这步做安全+性能review

完整版（5个角色，需要先写好AGENTS.md角色定义）

# 完整的接力流程
codex thread new --role PM      --title "[PM] 需求定义"
codex thread new --role 架构师   --title "[ARCH] 方案设计"
codex thread new --role 后端     --title "[DEV] 编码实现"
codex thread new --role QA       --title "[QA] 审查"
codex thread new --role 运维     --title "[OPS] 部署+Cron"

AGENTS.md里的角色定义模板（30秒复制）：

## 角色定义

### [PM] 产品经理
- 工作方式：输出需求文档 + 验收标准
- 检查问题：这个功能解决谁的什么问题？
- 交付要求：文档必须包含"验收标准"和"不做清单"

### [架构师] 技术架构师
- 工作方式：输出技术方案 + 风险评估
- 检查问题：方案是否考虑到安全、性能、扩展性？
- 交付要求：方案必须包含"回滚方案"

### [QA] 测试工程师
- 工作方式：审查代码 + 写边界测试用例  
- 检查问题：正常流程和异常流程都覆盖了吗？
- 交付要求：审查报告必须包含"阻塞项"和"非阻塞项"

### [DevOps] 运维工程师
- 工作方式：配置CI/CD + 监控报警
- 检查问题：出问题了怎么第一时间知道？
- 交付要求：输出部署文档 + 监控指标清单

---

7. 快速启动（30分钟就能试）

如果你从来没这么做过，现在花30分钟：

1. 在你的项目AGENTS.md里，加上"角色定义"部分（上面有模板）
2. 选一个你会做的功能，启动一个[ARCH]线程输出方案
3. 看了方案后，再启动一个[DEV]线程去实现
4. Review代码，合入

做完这四步，你就体验到了"角色切换"和"一个人线程接力"是什么感觉。

第一次不用追求完美。关键是体验到"一个线程干一件事"和"产出可被下个线程消费"的感觉。

---

8. 写到最后

3个月前，我以为"一个人开发"意味着熬夜、赶工、质量打折扣。

3个月后的今天，我的工作方式变成了这样：

• 早上打开电脑，看一眼昨晚Cron自动跑的Review报告
• 开一个新功能的需求线程，20分钟后收到需求文档
• 架构师线程出方案，两个开发线程并行写代码
• QA线程挑出所有边界问题
• 运维线程部署上线

我一个人，还是一支AI开发队。

你问最大的感受是什么？

不是省时间——虽然确实省了。不是代码质量——虽然确实高了。

是我不再觉得自己在孤军奋战。

5个线程在终端里各自跑着，我知道它们的方向是我定的、关口是我把的——但我再也不用一个人从头写到尾了。

尝试建议：选一个你本周要做的小功能，花30分钟跑一遍"架构师→开发→QA"三个角色。跑完之后，你会回来再看一遍这篇文章。

---

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

系列文章：

1. 10人团队AI协作30天完整复盘：AGENTS.md配置+5分支Git+Agent角色矩阵
2. Codex原生工作流实战：Plan / Skills / Review / Cron / 线程拆分
3. 👈 本篇：角色线程实战

一个人 + AI = 一家公司。