---
name: ops-case-notes
description: >-
  脱敏运营记录（Sanitized ops case notes）。一人总控、多个长期助手真实跑过一段日更流水线后，
  留下的方法级案例：真实问题、采取的改法、实际结果、仍未解决的限制。
  想知道同仓派收、交活证据两支技能在真活里怎么用、会在哪里漏，或要给自己的团队写同型运营记录时用。
  Use when you want real, redacted cases of how a human-led AI team changed its handoff and
  verification habits, what improved, and what is still unproven.
---
# 脱敏运营记录

属于开源包 Solo to Team · 一人成队（solo-to-team-skills）。

## 含什么

两组脱敏案例和一份验证说明：

- **A｜日更流水线怎样改出来的**：一条每日多板块交付链跑了约两周余，期间改了哪些方法、哪些还没证明。
- **C｜验收链怎样抓漏**：三个真实漏项，每个按「问题／改法／结果／仍未解决」四块写，并指向同仓技能的对应做法。
- **平台依赖条件表**：哪些做法换任何环境都能用，哪些依赖宿主平台的能力。
- **验证说明**：这些记录能证明什么、不能证明什么。

## 适合谁

- 已经或打算让一个人总控多个长期助手（或子代理）分工交付的人
- 装了同仓 `../dispatch-accept-verify/`（派收）和 `../evidence-before-done/`（交活证据），想看它们在真活里怎么落地、会在哪里漏的人
- 想给自己团队写一份「改了什么、还没证明什么」运营记录的人

## 怎么用

1. 先读 A 总览，判断你的协作链和这里的规模、节奏像不像。
2. 再读 C 的三个漏项，对照每项末尾「对应技能」，回到同仓技能里找具体做法。
3. 看「平台依赖怎么写」，按你的宿主有没有对应能力，选自动方式或人工替代。
4. 要写自己的运营记录：照本文件四块结构，每条结果后面都跟一句「仍未证明什么」。

## 依赖

- 本技能是**阅读型**记录，不调用任何工具，不需要额外权限。
- 真正落地要配同仓两支技能：`../dispatch-accept-verify/`、`../evidence-before-done/`。
- 文中提到的定时检查、跨助手发消息、叫醒等，都是原实践所在平台的宿主能力，**不随本包提供**，见「平台依赖怎么写」。

## 示例

C1「交了没交接标记」一节：一个执行人交了正文却没留提交标记，接收方在合订前才发现。对照 `../dispatch-accept-verify/` 第 4 节「没有『已收到成果』这一行，就当没收」，以及 `../evidence-before-done/` 第 3 节「东西放到某处了」一行，就是这次补上的检查。

## 验证到哪

本文件记录的是队内真跑过的方法变化，依据是队内复盘和派收记录的脱敏摘要。外人无法复核原始档案；本包承诺方法可照做，**不承诺**战绩可独立审计，也**尚未证明**全队错误率下降或催办减少。详见文末「验证说明」。

---

一句话：**把改了什么、换来什么、还没证明什么，一起写下来。**

## 经验从哪来

这些记录来自在 **Grok Bot** 上的真实运转：一个负责人做委托方，一个总控助手统筹，多个长期助手各管一块，每天接力出一份多板块交付，每周集中复盘一次。原始实践里用到了该平台的若干宿主能力，例如定时检查、助手之间互发消息、叫醒另一个助手、群聊、共享文件读写。

本文件把其中**不绑定平台**的协作方法提炼出来：登记一行、到点有人查、接单／收到成果／验收分开记、交活前要有对得上当前版本的证据、放行后当场叫下一棒开工。这些方法换到别的环境也能照做。同套方法其后也在多个 Agent 工具里做过实际加载和调用验证，范围见包根 [README](../../README.md)。A、C 仍只记录队内日更主链上的方法变化，不把安装验证算作案例成效。

需要说清的边界：**装上本包，不会得到 Grok Bot 的派活、叫醒、群聊或定时能力。** 本包只有技能文字和模板，没有任何自动化。

## A｜日更流水线怎样改出来的

### 总览

| 项 | 内容 |
|---|---|
| 跑了多久 | 约两周余日更主链，另加每周一次复盘（已复盘 3 次） |
| 规模级 | 每日多板块分册交接；素材先经独立复核再交下一棒；每周另出一期工具动态 |
| 参与方 | 一个负责人（委托方）、一个总控、多个长期协作助手 |
| 不写的 | 内部任务总数、编号、路径、具体日程 |

### 真实问题

起步时的做法是「每天整本交付全审一遍」。板块一多，全审本身成了瓶颈：审核排队，交付推迟；同时「谁交了、谁收了」只靠聊天里的一句话，交没交、收没收常常说不清。

### 采取的改法

1. **全审改抽核**：各棒先按交活证据自查；每天只抽少数数字、日期、出处回原文核对；每周集中复盘一次，看整体问题。
2. **提交和接收分开记**：交的人留提交标记，收的人另写「已收到成果」；不能拿提交标记当作已经收到。
3. **放行后当场叫开工**：复盘后补进派收技能——授权或放行一出，派活的人当场叫下一棒开工，收到「已接单」或开工证据才算接住。
4. **素材先复核再交**：上游素材先经另一个助手独立复核，通过后才交给下游。

### 实际结果

- 日更主链在方法调整期间持续运行，累计约两周余，期间复盘 3 次。
- 「先复核再交」连续多日跑通；抽核连续多日所抽条目回原文核对通过。
- 上面三条方法已写进同仓两支技能，成为可照做的做法。

### 仍未解决的限制

- **尚未证明全队错误率下降或催办减少。** 复盘明确写了：不能证明同类错误变少，不能证明负责人少催，总体是否更好不下结论。
- 「收到后多久记已收到成果」这类时限曾标「待验证」，本包不作承诺。
- 抽核能否长期替代全审，时间还太短，看不出。
- 没有对照组，没有同口径的前后发生率统计。

## C｜验收链怎样抓漏

以下三个漏项都是真实发生过的，已去掉编号、日期、作品名和角色真名。

### C1｜正文齐了，交接标记没交

- **真实问题**：某日一个执行人把正文交齐了，但没留提交标记，也缺一项封面信息。接收方在合订前核对才发现。
- **采取的改法**：明确「提交标记」和「已收到成果」是两件事；接收方收件时按清单核文件和附属信息，缺一项就不写「已验收」。
- **实际结果**：提醒后当日补齐。
- **仍未解决的限制**：这次是接收方核出来的；交的一方会不会每次自己先核，还靠习惯，没有强制手段。
- **对应技能**：`../dispatch-accept-verify/` 第 4 节「收到写已接：拆成三个状态记」（接单／收到成果／验收分开记）；`../evidence-before-done/` 第 3 节「东西放到某处了」。

### C2｜放行了，没人叫开工

- **真实问题**：某件活已经得到授权放行，总控转身去收口别的活，漏叫执行人开工。直到负责人追问，才发现这件活一直没动。
- **采取的改法**：派收技能加一条——授权或放行一出，派活的人当场叫下一棒开工，对齐执行人、交付物、交时；只有「消息收到了」不算接住，要「已接单」或开工证据。并行收口别的活不是漏叫的理由。
- **实际结果**：改法已写进派收技能，成为可照做的一条；漏叫是在复盘里被记下、才逼出这条改法的。
- **仍未解决的限制**：复盘时定的检验办法是「看下一件已授权的真活」，是否从此不再靠负责人追问，还在观察中，**尚未证明**。
- **对应技能**：`../dispatch-accept-verify/` 第 6 节「开工、收工点名」、第 8 节「放行后立刻叫开工」。

### C3｜内部打了高分，成品观感还是漏了

- **真实问题**：某个视频成品在内部评审里已经拿到高分，交给负责人后，字幕节奏和观感问题由负责人先指出。
- **采取的改法**：把这次记进复盘，明确内部评分不能代替真看一遍成品；对照交活证据的做法，「视频做好了」要从头播过、至少抽看开头中间结尾。
- **实际结果**：这条漏项被记进复盘，作为「末端验收仍会漏」的例子保留，没有被包装成已解决。
- **仍未解决的限制**：观感类问题很难写成清单项；评审打分高、委托方仍不满意的情况，本方法不能保证不再发生。
- **对应技能**：`../evidence-before-done/` 第 3 节「视频做好了」、第 4 节「该停一下的信号」。

### 三个漏项的共同点

都不是「没人干活」，而是**交接处没留痕**或**核对停在了中途**。登记、接单／收到成果／验收分开记、放行后叫开工、交活前亲手看一遍，就是分别针对这几个缝。

## 平台依赖怎么写

通用方法（登记一行、到点有人查、接单／收到成果／验收分开记、交活前要有对得上当前版本的证据、放行后叫开工）**在任何环境都能用**，最低只需一份共享记录和一个会按时查看的人。下面只列依赖宿主的部分。

### 按能力

| 能力 | 宿主有，则可以 | 宿主没有，则改用 |
|---|---|---|
| 定时检查 | 到点自动提醒检查人查所有未完项 | 登记行写预计时间和检查人；检查人每次开工、醒来第一件事查所有未完项（没人接、接了没交、交了没核） |
| 跨助手发消息 | 放行后直接给下一棒发「开工」 | 在共享记录写「叫开工」一行，由负责人或总控转达 |
| 叫醒另一个助手 | 被叫的助手醒来先看待办 | 由人打开对应会话，贴上开工说明 |
| 群聊 | 多方同时看到放行和开工 | 共享文档一处置顶，所有人以它为准 |
| 共享文件读写 | 结果放约定位置，收的人去原处核 | 交件时附文件本身或链接；收的人在自己这端打开核过再写「已验收」 |

### 按平台

| 平台 | 状态 | 方法怎么用 |
|---|---|---|
| Codex／WorkBuddy／DeepSeek Harness／Cursor／CodeBuddy／Kimi Work／千问办公（QwenWork） | 支持，已有走通记录（装／配置、按名调用、产出登记行） | 加载后按名调用，照正文做派收和核对；具体装法及验证范围见包根 [README](../../README.md)。 |
| Grok Bot | 支持，需手动配置；主要经验来源 | 把技能正文 Save 为私有技能后按名调用；也不写成开箱即用的安装入口；仅指 Grok Bot，不代表 Grok 其他客户端。 |
| Claude Code | 结构已备，走通待补；不在首发支持之列 | 已备插件结构，能否走通仍待验证。 |
| 其他宿主 | 尚未验证，适配方式待确认 | 可先读通用方法，能否加载和调用需另行验证。 |

再说一次：本包里**没有**自动派工、自动叫醒、自动回执。到点查、记接单／收到成果／验收、叫开工，都靠技能里的人工或会话步骤完成。

## 验证说明

1. **跑了多久**：约两周余日更主链，每周一次复盘，共 3 次。
2. **派收量级**：每日多板块分册交接；素材先经独立复核再交下一棒；每周一期工具动态。不列内部编号和总数。
3. **改过什么方法**（改前 → 改后）：
   - 每天整本全审 → 各棒自查＋每日抽核少数事实＋每周集中复盘
   - 一句「交了」就算 → 提交标记和「已收到成果」分开记
   - 放行后等人自己开工 → 派活的人当场叫开工，有「已接单」或开工证据才算接住
   - 内部评分高就交 → 交前亲手看完成品
4. **仍未证明什么**：没有对照实验，没有同口径的前后发生率；尚未证明全队错误率下降或催办减少；放行后叫开工的改法仍在观察；八家各有一例有限任务的验收记录，不代表稳定性或所有任务都能做成。
5. **证据类型**：依据队内复盘和派收记录的脱敏摘要。外人无法复核原始档案。本包承诺方法可照做，不承诺战绩可独立审计。

---

方法换平台可以带走，平台的自动化带不走；改了什么和还没证明什么，要一起写。