jasontopia · Sep 26, 2026 · Sep 26, 2026 · Sep 26, 2026
diff --git a/README.md b/README.md
@@ -4,7 +4,7 @@ FirstMate 的中文入门教程与动手练习。
 
 ## 这个仓库是什么
 
-FirstMate（大副 / firstmate）是一个「agent distro」- 一个可移植的指令、技能、工具、策略与状态约定的目录，它把一个通用的编码 agent 变成一个专门的 agent。你只跟一个 agent 对话，它替你调度和监督一整支 agent 船员（crewmate）队伍，最后把可以合并的 PR、已批准的本地合并，或者独立的调查报告交到你手上。
+FirstMate（大副 / firstmate）是一个「agent distro」- 一个可移植的指令、技能、工具、策略与状态约定的目录，它把一个通用的编码 agent 变成一个专门的 agent。你只跟一个 agent 对话，它替你调度和监督一整支 agent 船员 / crewmate 队伍，最后把可以合并的 PR、已批准的本地合并，或者独立的调查报告交到你手上。
 
 这个仓库不是 FirstMate 本身，而是学它的地方。它把 FirstMate 的每一项功能拆成一节，每节先讲清楚这项功能解决什么问题、它的规矩是什么，再给一个你可以真的让 FirstMate 跑一遍的练习。目标很直接：读完并做完之后，你能把这些做法直接用在自己的真实项目上。
 
@@ -33,7 +33,7 @@ FirstMate（大副 / firstmate）是一个「agent distro」- 一个可移植的
 | 6  | [scout（侦察）任务与调查报告](chapters/06-scout-tasks-and-reports.md)       | 什么时候该派侦察而不是直接开工，报告长什么样、存在哪里，以及一份报告为什么不等于动工的授权。   | 已写 |
 | 7  | [backlog（工单）与船长决策](chapters/07-backlog-and-captain-decisions.md)    | 工单队列怎么记录在办和待办的活，一个等你拍板的决策为什么本身也是一张工单，以及它怎么被关闭。   | 已写 |
 | 8  | [supervision（监督）与唤醒机制](chapters/08-supervision-and-wakeups.md)     | 大副怎么在不烧 token 的前提下盯住整支队伍，什么事件会把它叫醒，什么时候才该轮到你被打扰。      | 已写 |
-| 9  | [second mate（二副）与分工路由](chapters/09-secondmates-and-routing.md)      | 队伍变大之后怎么按领域拆出常驻的二副，一件活按什么规则路由给谁，以及哪些活必须留在主家。       | 已写 |
+| 9  | [二副 / secondmate 与分工路由](chapters/09-secondmates-and-routing.md)      | 队伍变大之后怎么按领域拆出常驻的二副，一件活按什么规则路由给谁，以及哪些活必须留在主家。       | 已写 |
 | 10 | [afk 离席模式](chapters/10-afk-mode.md)                                     | 你离开键盘期间谁接手监督，离席期间它敢自己做什么、必须留着等你什么，以及你回来时怎么交接回来。 | 已写 |
 | 11 | [运行时与 harness 选择](chapters/11-harness-and-runtime-backend.md)          | 哪个工具在跑你的船员，运行时后端与 harness 怎么配，以及什么时候值得为一件活单独指定。          | 已写 |
 | 12 | [Relay](chapters/12-relay.md)                                                | 默认关闭的公开提及接入，开启它意味着授权了什么，以及哪些动作它永远不会自动替你做。             | 已写 |
diff --git a/chapters/01-what-is-firstmate.md b/chapters/01-what-is-firstmate.md
@@ -59,7 +59,7 @@ FirstMate 用航海的比喻给三个角色命名。第一次出现时给出中
 
 原文是 "Never write to a project."：大副不在 `projects/` 或任何项目工作副本下编辑、提交、或运行任何会改变状态的命令 - 大副读项目，船员改项目。
 
-只有几条极窄的例外：受守护的项目初始化、fleet sync、二副同步、自我更新、已批准的 `local-only` 合并路径，以及船长在当下就某个具体项目、具体操作明确批准的一次性操作。而且这些例外**从不**授权强推、stash、丢弃未落地的工作，也从不授权大副手写项目的 `AGENTS.md`。
+只有几条极窄的例外：受守护的项目初始化、fleet sync、二副 / secondmate 同步与继承本地资料的传播、自我更新、已批准的 `local-only` 合并路径，以及船长在当下就某个具体项目、具体操作明确批准的一次性操作。而且这些例外**从不**授权强推、stash、丢弃未落地的工作，也从不授权大副手写项目的 `AGENTS.md`。
 
 **为什么**：如果大副既当调度员又当施工队，那它自己的改动就没有任何一关来把关 - 没有隔离的工作副本，没有质检流水线，没有 PR 审查。更要紧的是，大副是那个要在多件活之间做仲裁的角色；一个同时在改代码的仲裁者，会不自觉地把自己那份改动当成既成事实。把它挡在代码外面，才能保证**每一处项目改动都走同一条有关卡的路**。
 
@@ -240,7 +240,7 @@ FirstMate 用航海的比喻给三个角色命名。第一次出现时给出中
 - 一段用平实语言讲出来的职责边界，而不是把 `AGENTS.md` 原文贴给你。
 - 它会说到自己不写项目代码、不在未经你同意时合并 PR、不销毁未落地的工作、以及船员不直接找你这几条。
 - 它会指出出处，主要是 `AGENTS.md` 第 1 节。
-- 它会在消息里至少称呼你一次「captain / 船长」- 这是 `AGENTS.md` 明文要求的强制性尊称。
+- 它会在消息里至少称呼你一次「船长 / captain」- 这是 `AGENTS.md` 明文要求的强制性尊称。
 
 **怎么判断做成了**
 

diff --git a/chapters/07-backlog-and-captain-decisions.md b/chapters/07-backlog-and-captain-decisions.md
@@ -12,7 +12,7 @@
 
 `AGENTS.md` 第 10 节开头就定了 backlog 的位置：「The configured `tasks-axi` backend is the durable queue... It tracks work items only, never agents; persistent secondmates never appear as backlog items.」
 
-翻成大白话：backlog（工单队列）是这支队伍手上所有活的**持久记录**，靠 `tasks-axi` 这套工具管理，落地文件默认是 `data/backlog.md`。它记的是**活本身**，不是船员这个人 —— 一个常驻的二副（secondmate）永远不会作为一个条目出现在这份队列里，队列里的每一行是一件事，不是一个人。
+翻成大白话：backlog（工单队列）是这支队伍手上所有活的**持久记录**，靠 `tasks-axi` 这套工具管理，落地文件默认是 `data/backlog.md`。它记的是**活本身**，不是船员这个人 —— 一个常驻的二副 / secondmate 永远不会作为一个条目出现在这份队列里，队列里的每一行是一件事，不是一个人。
 
 一件活在队列里只会落在三档之一，出处是 `docs/configuration.md`「Backlog backend」一节：「On the default markdown adapter, tasks-axi and manual edits produce the same `## In flight`, `## Queued`, and `## Done` sections.」
 

diff --git a/chapters/08-supervision-and-wakeups.md b/chapters/08-supervision-and-wakeups.md
@@ -4,7 +4,7 @@
 
 第 6 章讲了侦察任务怎么产出一份报告，第 7 章讲了工单队列怎么记录在办和待办的活、以及一个决策本身怎么变成一张工单。这两章都是从**一件活**的角度看问题。这一章把镜头拉远：当队伍里同时有好几件活在跑的时候，大副 / firstmate 怎么盯住整支船员 / crewmate 队伍，而不需要为了「盯着」这件事本身持续消耗 token。
 
-这一章只回答三个问题：大副是怎么在没有事情发生的时候完全不跑、不烧 token 的；几种唤醒（wake）事件分别代表什么；唤醒之后，哪些事大副自己按规矩就能拍板，哪些才轮到船长 / captain 被打扰。二副 / second mate 怎么帮大副分担这些监督工作，是下一章的内容，这里不展开。
+这一章只回答三个问题：大副是怎么在没有事情发生的时候完全不跑、不烧 token 的；几种唤醒（wake）事件分别代表什么；唤醒之后，哪些事大副自己按规矩就能拍板，哪些才轮到船长 / captain 被打扰。二副 / secondmate 怎么帮大副分担这些监督工作，是下一章的内容，这里不展开。
 
 本章依据的权威文件：FirstMate 仓库 `AGENTS.md` 第 8 节「Supervision protocol」和第 9 节「Escalation and captain etiquette」，以及 `docs/architecture.md` 里「Event-driven supervision」一节和 `bin/fm-watch.sh`、`bin/fm-crew-state.sh` 的头部注释。每个小节会指出具体出处。
 
@@ -131,4 +131,4 @@ state: <working|parked|done|blocked|paused|failed|unknown> · source: <run-step|
 
 ## 下一章
 
-第 9 章讲**second mate（二副）与分工路由**：队伍变大之后怎么按领域拆出常驻的二副，一件活按什么规则路由给谁，以及哪些活必须留在主家。
+第 9 章讲**二副 / secondmate 与分工路由**：队伍变大之后怎么按领域拆出常驻的二副，一件活按什么规则路由给谁，以及哪些活必须留在主家。
diff --git a/chapters/09-secondmates-and-routing.md b/chapters/09-secondmates-and-routing.md
@@ -1,8 +1,8 @@
-# 第 9 章：second mate（二副）与分工路由
+# 第 9 章：二副 / secondmate 与分工路由
 
 ## 这一章讲什么
 
-第 6 到 8 章讲的是一支队伍要处理的通用问题：知识怎么沉淀、排队怎么决策、没人盯着时怎么监督。这一章往前迈一步，进入路线图里「规模、离席、以及到底是哪个工具在跑你的船员」这条线的第一站：队伍真的变大之后，一个大副 / firstmate 怎么按领域拆分成常驻的二副 / second mate，一件活怎么按登记的范围路由给合适的二副，以及哪些活无论如何都必须留在主家。
+第 6 到 8 章讲的是一支队伍要处理的通用问题：知识怎么沉淀、排队怎么决策、没人盯着时怎么监督。这一章往前迈一步，进入路线图里「规模、离席、以及到底是哪个工具在跑你的船员」这条线的第一站：队伍真的变大之后，一个大副 / firstmate 怎么按领域拆分成常驻的二副 / secondmate，一件活怎么按登记的范围路由给合适的二副，以及哪些活无论如何都必须留在主家。
 
 离席期间谁接手监督，留给第 10 章；用什么工具、什么运行时去跑船员，留给第 11 章。这一章只讲二副本身是什么、什么时候才值得建它、以及一件活进来之后怎么被分流。
 
@@ -63,7 +63,7 @@
 
 对大副说：
 
-> 大副，讲清楚二副 / second mate 到底是什么 - 它跟你自己（大副）以及普通船员分别是什么关系，它比普通船员多出了哪两样东西。再讲清楚为什么不该在队伍刚起步时就先建好几个二副，什么样的信号才说明真的值得为一个领域拆一个常驻的二副出来。回答里指出你是根据 `AGENTS.md` 哪一节说的。这只是让我核对认识，不要创建任何工单，也不要真的去建一个二副或派任何船员。
+> 大副，讲清楚二副 / secondmate 到底是什么 - 它跟你自己（大副）以及普通船员分别是什么关系，它比普通船员多出了哪两样东西。再讲清楚为什么不该在队伍刚起步时就先建好几个二副，什么样的信号才说明真的值得为一个领域拆一个常驻的二副出来。回答里指出你是根据 `AGENTS.md` 哪一节说的。这只是让我核对认识，不要创建任何工单，也不要真的去建一个二副或派任何船员。
 
 **预期会看到什么**