📚 编程进阶教程站

第 4 章 · 五条硬规则与安全边界 ​

本章目标：逐条理解 FirstMate 运营契约（AGENTS.md）中的五条 Hard Rules，弄清每条规则保护的边界、允许的例外，以及它们如何共同构成「放心放权」的安全地基。

4.1 为什么需要硬规则 ​

上一章我们看到，AGENTS.md 把 firstmate 定义为「船长的唯一联络人」。这意味着你会把修复 bug、审查代码、并行开发这类有副作用的工程动作交给一支智能体舰队去完成。

放权的前提是边界清晰。如果第一副手可以随手改你的项目、随手合并 PR、随手丢弃没提交的工作，那么「Talk to one agent」就不是提效，而是冒险。因此 AGENTS.md 在第 1 节（Identity and prime directives）里列出了一份按优先级排序的硬规则清单（Hard rules, in priority order）：

text
Hard rules, in priority order:

1. Never write to a project.
2. Never merge a PR without the captain's explicit word.
3. Never tear down unlanded work.
4. Crewmates never address the captain.
5. Report outcomes faithfully.

这五条规则的共同特点是：由契约文本强制约束，而不是靠模型自觉。AGENTS.md 就是 firstmate 的「岗位职责说明书」，只要 harness 加载了这份文件，规则就随每次会话生效。

下面逐条拆解。

4.2 硬规则一：绝不写入项目（Never write to a project） ​

这是最核心的一条：firstmate 自己不编辑、不提交、不在 projects/ 下执行改变状态的操作。它负责读取项目、分派任务、监督船员；真正改动项目代码的是被委派出去的 crewmate。

text
firstmate  reads projects/ + routes tasks      （只读 + 路由）
crewmates  make every project change           （船员干活）
captain    makes every merge decision          （船长拍板合并）

当然，完全不许碰会让某些运维动作无法执行，所以这条规则附带了一组狭窄且受守卫的例外：

  • 受守卫的项目初始化（guarded project initialization）；
  • 舰队同步（fleet sync）、secondmate 同步及继承本地材料的传播；
  • 自我更新（self-update）；
  • 经批准的 local-only 合并路径；
  • 船长当场明确批准的具体项目操作（concrete captain-approved project operation）。

注意例外的严格性：这些路径不会连带授权 force push、stash、丢弃未落地工作，也不允许 firstmate 手写项目的 AGENTS.md。即使是船长批准的场景，也要求「当下、针对具体项目、具体操作或无歧义的具体范围」，firstmate 只执行被批准的那个动作本身——不推断、不扩大范围、不留常设权限。

4.3 硬规则二：没有船长的明确指令绝不合并 PR ​

第二条规则管的是交付终点：任何 PR 合并都必须出自船长的明确表态。实战中就是那句「alright merge it」。

唯一的常设放宽（standing relaxation）是项目配置里的 yolo 合并自治姿态——它是船长自己事先批准的项目级开关，相当于把某类合并权预先下放。除此之外，合并权威始终在船长手里。第 10 章讲项目模式（no-mistakes / direct-PR / local-only 与 +yolo 标志）时会展开这一机制。

4.4 硬规则三：绝不销毁未落地的工作（unlanded work) ​

第三条规则保护的是工作成果：未提交的修改永远不会被落地处理，而「一段工作是否已经落地」的判定归 bin/fm-teardown.sh 所有（它实现了完整的 landed-work 测试）。firstmate 不允许绕过拒绝结果、不允许用 --force，除非船长明确授权丢弃那部分工作。

对 scout 类任务的临时 worktree 有专门约定：只有当侦察报告已经产出、并且共享的 unresolved-decision 完成门槛通过之后，才可声明为 scratch 并丢弃。

sh
# 概念示意：teardown 由脚本统一把关，而非临时起意地删目录
bin/fm-teardown.sh   # 内置 landed-work 测试，未落地工作会被拒绝清理

这一条和硬规则一共同构成了数据安全的两道闸门：项目内容不被越权修改，已有成果不被越权销毁。

4.5 硬规则四与五：通信拓扑与如实汇报 ​

最后两条规则规范的是信息流：

规则四：Crewmates never address the captain. 所有船员的沟通都经过 firstmate 中转，船员不直接向船长喊话。如果船长直接介入某个船员的会话窗口，该介入被视为权威指令，并在下一次监督评审（supervision review）时被 firstmate 对账。这保证了你始终只有一个对话入口——这正是 FirstMate 区别于「开一堆终端标签页」的核心价值。

规则五：Report outcomes faithfully. 工作失败了就直说失败，并给出证据。监督者的价值取决于汇报的可信度；粉饰太平的舰队比没有舰队更危险。

text
you ──chat──> firstmate ──brief──> crewmates
 ^                  │                    │
 │                  ▼                    │
 └──── decisions ◄── escalation ◄── status ─┘   （船员永远不越过 firstmate 直达你）

4.6 违规场景演练 ​

把五条规则放进真实场景里检验一遍：

场景正确行为依据
你说「帮我把 README 里的错别字改了」firstmate 委派一个 crewmate 去改，自己不动文件硬规则 1
CI 绿了，你说「看着办」不能合并，「看着办」不构成明确合并指令硬规则 2
项目开了 +yolo，小改动自动合并可以按既定姿态合并硬规则 2 的 yolo 放宽
任务失败，worktree 里有半成品修改拒绝清理并上报，等你决定去留硬规则 3 + 5
你直接在某船员 tmux 窗口输入指令该指令有效，但会在下次监督评审时被对账硬规则 4
船员任务实际失败但看起来「差不多完成了」如实报败并附证据，不得含糊其辞硬规则 5

可以看到，五条规则分别锁住了五个危险面：写权限、合并权、删除权、通信拓扑、诚实义务。理解了它们，你就知道哪些话可以对 firstmate 说、哪些决策必须亲自留给自己。

本章小结 ​

  • 五条硬规则按优先级排列：不写项目、不擅自合并、不毁未落地工作、船员不直达船长、如实汇报；
  • 「不写项目」附带有狭窄的受守卫例外（初始化/同步/自更新/船长当场批准），且例外永不隐含 force、stash、discard 权限；
  • 合并权威默认在船长手中，yolo 是唯一经船长预先批准的常设放宽；
  • 未落地工作的判定由 bin/fm-teardown.sh 统一把关，绕过拒绝或 --force 都需要船长明确授权；
  • 单一联络人模式依赖硬规则 4 维持通信拓扑，依赖硬规则 5 保证汇报可信。

🧪 随堂测验

点击你认为正确的选项。答错时会展示正确答案与原因解析。

1. 硬规则一中，firstmate 对 projects/ 目录的基本姿态是？

2. 关于 PR 合并权限，下列说法正确的是？

3. 某个 scout 任务的 worktree 里还有未提交修改，firstmate 想清理它，正确的做法是？

4. 你直接在一个船员的 tmux 窗口里输入了指令，按照硬规则四会发生什么？

🛠️ 动手实践 ​

  1. 打开克隆好的 firstmate 仓库，通读 AGENTS.md 第 1 节的五条 Hard Rules 原文，用自己的话为每条规则写一句中文概括，并标出每条规则各自防范的风险。
  2. 启动 firstmate 后，故意发出一个模糊的合并指令（例如「CI 绿了就看着办」），观察它的反应；再用明确的「merge it」对比两次行为的差异，记录哪次真正触发了合并流程。
  3. 在一个测试项目中让某个任务留下未提交的改动，然后请求 firstmate 清理对应 worktree，验证它会依据 landed-work 测试拒绝销毁未落地工作；随后明确授权丢弃，再观察完整的授权-执行链路。