diff --git a/docs/README.md b/docs/README.md
index 10207f8a..6a81282c 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -27,6 +27,7 @@
 
 ### 🤝 团队协作
 - **[团队协作模式](./workflow/团队协作模式.md)** - 当前推荐分工、分支规则、提交流程
+- **[高频协作五条铁律](./workflow/高频协作五条铁律.md)** - 双 Codex 高频协作时的 5 条固定规则
 - **[主线同步操作手册](./workflow/主线同步操作手册.md)** - 主线持续更新时，同事如何安全同步自己的分支
 - **[同事本地 AGENTS 使用说明](./workflow/同事本地AGENTS使用说明.md)** - 如何给同事单独加 AI 约束，而不污染仓库共享规则
 - **[同事本地 AGENTS 模板](./workflow/同事本地AGENTS模板.md)** - 可直接复制到同事电脑外层工作区的 `AGENTS.md` 模板
@@ -91,6 +92,7 @@ docs/
 ├── PHASES_8_9_SUMMARY.md        # 📊 最新阶段总结
 ├── workflow/                    # 🤝 团队协作规则
 │   ├── 团队协作模式.md
+│   ├── 高频协作五条铁律.md
 │   ├── 主线同步操作手册.md
 │   ├── 同事本地AGENTS使用说明.md
 │   ├── 同事本地AGENTS模板.md
diff --git a/docs/workflow/同事本地AGENTS模板.md b/docs/workflow/同事本地AGENTS模板.md
index 462a9bcd..d36330c8 100644
--- a/docs/workflow/同事本地AGENTS模板.md
+++ b/docs/workflow/同事本地AGENTS模板.md
@@ -61,6 +61,10 @@
 - 主负责人刚推了重要改动后，再同步一次
 - 自己准备提交前，再同步一次
 
+高频协作固定铁律见：
+
+- `docs/workflow/高频协作五条铁律.md`
+
 默认同步步骤：
 
 ```bash
@@ -88,6 +92,7 @@ git push origin <你的分支名>
 - Route / Page 不直接写 Prisma 业务规则。
 - 先复用现有实现，不重复造新结构。
 - 遇到冲突或边界不清，先停下来说明，不要硬改。
+- 主导航、主流程骨架、公共数据结构，不要擅自大改。
 
 ## 7. 前端与文档
 
diff --git a/docs/workflow/团队协作模式.md b/docs/workflow/团队协作模式.md
index b65af89d..d065157c 100644
--- a/docs/workflow/团队协作模式.md
+++ b/docs/workflow/团队协作模式.md
@@ -177,6 +177,7 @@ git push origin <自己的分支>
 - 分支已经多人共用，先用 `merge`
 
 详细操作说明见：`docs/workflow/主线同步操作手册.md`
+高频协作总规则见：`docs/workflow/高频协作五条铁律.md`
 
 ---
 
@@ -292,3 +293,4 @@ git push origin <自己的分支>
 
 - `docs/workflow/同事本地AGENTS使用说明.md`
 - `docs/workflow/同事本地AGENTS模板.md`
+- `docs/workflow/高频协作五条铁律.md`
diff --git a/docs/workflow/高频协作五条铁律.md b/docs/workflow/高频协作五条铁律.md
new file mode 100644
index 00000000..6765e79b
--- /dev/null
+++ b/docs/workflow/高频协作五条铁律.md
@@ -0,0 +1,110 @@
+# 高频协作五条铁律
+
+适用对象：主负责人和协作者都用 Codex、而且主线更新频繁的团队。  
+目标：把最容易出问题的协作动作压成 5 条固定规则，减少分支打架、AI 扩范围、同步滞后。
+
+---
+
+## 1. 先说结论
+
+这 5 条铁律，建议这样放：
+
+- 完整版：放在仓库文档里，作为团队协作规则
+- 精简版：摘到你和同事各自本地工作区的 `AGENTS.md`
+
+不要直接把整份长文全塞进仓库根目录 `AGENTS.md`。  
+仓库根目录那份更适合放长期稳定的硬规则，不适合塞太多高频协作动作。
+
+---
+
+## 2. 五条铁律
+
+### 铁律 1：开工先同步主线
+
+- 每天开始开发前，先同步一次最新 `main`
+- 主负责人刚推了重要改动后，再同步一次
+- 自己准备提交前，再同步一次
+
+白话理解：  
+不要拿旧主线继续往下改。
+
+### 铁律 2：每次任务先写清边界
+
+- 先说这次只改什么
+- 再说这次不改什么
+- 再说哪些目录不能碰
+
+白话理解：  
+先把边界说清楚，再让 Codex 动手，不要让 AI 顺手越改越大。
+
+### 铁律 3：公共模块优先由主负责人收口
+
+- 主导航、主流程骨架、公共 Service、公共数据结构，优先由主负责人收口
+- 协作者优先做自己负责模块里的局部实现
+
+白话理解：  
+公共骨架不要两边同时乱改。
+
+### 铁律 4：冲突先停，不硬解
+
+- 同步 `main` 出现冲突时，先判断是不是自己负责的模块
+- 不是自己负责的模块，先问主负责人
+- 是自己负责的模块，再让 Codex 只处理冲突文件
+
+白话理解：  
+不要为了快，把冲突文件一把全选成“保留我的版本”。
+
+### 铁律 5：小步提交，小步收口
+
+- 不要攒很久再一次性提交
+- 每完成一个小闭环，就及时提交或至少先整理一次状态
+- 主负责人定期把已经稳定的小步结果收进 `main`
+
+白话理解：  
+小步走，比最后爆一次大冲突安全得多。
+
+---
+
+## 3. 主负责人本地 AGENTS 摘抄版
+
+下面这段可以直接摘到你自己电脑外层工作区的 `AGENTS.md`：
+
+```md
+## 高频协作五条铁律
+
+- 开工前、刚有人更新主线后、准备提交前，先同步最新 `main`
+- 每次任务先写清楚：这次只改什么、不改什么、哪些目录不能碰
+- 公共模块和主链骨架优先由我收口，不让协作者顺手改成多份真相
+- 遇到冲突先停下来判断边界，不要硬解
+- 默认小步提交、小步收口，不攒大改动
+```
+
+---
+
+## 4. 协作者本地 AGENTS 摘抄版
+
+下面这段可以直接摘到你同事自己电脑外层工作区的 `AGENTS.md`：
+
+```md
+## 高频协作五条铁律
+
+- 开工前、主负责人刚更新主线后、准备提交前，先同步最新 `main`
+- 每次任务先说清楚：这次只改什么、不改什么、哪些目录不能碰
+- 主导航、主流程骨架、公共数据结构，不要擅自大改
+- 同步主线遇到冲突时，先只处理自己负责的文件，不要硬改别人的模块
+- 默认小步开发、小步提交，不要长期不同步后再一次性推很多改动
+```
+
+---
+
+## 5. 最后建议
+
+如果后面你同事承接更多模块，这 5 条铁律本身不用推翻。  
+你们只需要调整各自本地 `AGENTS.md` 里的“负责范围”和“禁止改动范围”。
+
+也就是说：
+
+- 铁律长期稳定
+- 模块边界按阶段调整
+
+这样最稳。