用运营伙伴维护规则和交接

项目持续推进后，重复发生的事情往往包括提醒规范、解释任务状态、给新伙伴补背景，以及处理上一次没审仔细的问题。这些事情也需要一个明确的负责人。

Jenny 的职责从哪里开始

在 Lingxi Li 的团队中，Jenny 负责运营，也是唯一不写代码的伙伴。她承担新伙伴入职、知识分享、事故复盘和日常对齐。代码责任仍属于各工程领域的负责人。

作者安排 Jenny 每天早上五点与每个伙伴一对一交流，检查操作手册、当前阻塞和希望保持的沟通风格。作者认为，这种重复提醒有助于伙伴在多任务和有限上下文中持续遵守复杂规则。这是实践反馈，并不是已经量化验证的长期记忆保证。

图里可以看到具体的风格提醒。消息要简短，英文用小写，一次把答案说完，不要再补一条总结气泡。Jenny 还让伙伴查看操作手册，并询问正在做什么、哪里卡住。我们学习的是把规则说成可执行的行为；英文小写属于作者的个人风格，不必照搬到中文课程里。

复盘要产出下一次能用的改动

作者举到的错误包括评审没有看仔细，以及执行结果没有达到目标时，伙伴没有继续要求改进。处理办法是让相关伙伴找 Jenny，回看当时可用的信息、判断依据和后续动作，更新操作手册，再通知其他工程伙伴。

本课可以用四个问题整理复盘，但不要求伙伴披露不可提供的内部思维链。我们要检查的是可观察的行为、日志、证据和判断理由。

“以后认真一点”很难检查。“视觉任务提交前，逐项对照需求截图，并列出仍未覆盖的状态”就具体得多。

扩编时连同规则一起交接

作者让 Jenny 创建新伙伴、分享工程规范，再请 Hogan 和其他成员协助入职。扩编因此包含职责、规则和协作关系的交接，不能只停在起一个名字。

Hogan 的截图给出了一套特定工作台规则。新任务先建账本行，状态为处理中；没有记录就不启动任务；不要重复登记其他负责人的变更请求。新变更使用指定评审入口，正文遵守指定标记约定，并提供真实证明和说明，不能只贴一个裸链接。

这套截图规则还明确，伙伴运行结束不等于任务完成，已完成表示已经合并，合并交给负责人。原始入口和机器标记保留在第六课，只用于理解这个案例，不能当成我们项目的默认配置。

本课练习

先写一个只负责规则维护的运营岗位说明，要求它完成一次模拟入职和一次复盘。模拟错误可以选“只改了伙伴信息页，漏了首页长按入口”。

请根据这次漏项整理复盘。保留原需求、实际交付和缺失的证据，写出导致漏项的可观察原因。把改进规则放进操作手册，并列出哪些伙伴需要收到更新。不要创建新的执行任务，也不要改变任何合并权限。

通过标准是手册增加了一条可以检查的规则，相关负责人收到一致的说明，原任务仍由原负责人继续处理。运营伙伴的工作应减少下一次重复解释的次数。