先识别重复工作的信号
同一任务第二次出现、关键步骤依赖记忆、交接时总要重新解释、失败后恢复路径不清楚，或完成质量难以判断——出现任何一个信号，就值得写最小 SOP。
只保留必要字段
- 触发条件：什么时候使用。
- 输入：开始前必须具备什么。
- 步骤：按顺序执行的最小动作。
- 完成检查：怎样证明结果成立。
- 输出：最终留下的文件、决定或状态。
- 异常：常见失败与最短恢复路径。
- 更新记录：何时、为何改变流程。
一个够用的 Markdown 模板
# SOP：<工作名称>
## 触发条件
-
## 输入
-
## 步骤
1.
2.
## 完成检查
- [ ]
## 输出
-
## 异常
- 症状：
- 恢复：
## 更新记录
- YYYY-MM-DD：根据一次真实复盘更新。字段可以为空，但不能用模糊词掩盖不知道。尤其是“完成检查”，它把“我执行过步骤”和“结果确实成立”区分开。
把一次研究收尾变成 SOP
第一次做竞品研究时，你发现结论散落在 Agent 对话里，来源链接没有统一保存。复盘后形成：
- 触发条件：需要比较三个以上方案并形成决策。
- 输入：明确问题、评价维度、截止时间。
- 步骤：先公开调研；标记证据和待验证项；生成完整 Markdown；用 BrainPost Skill 归档。
- 完成检查：本地笔记含问题、结论、证据、来源、未知项和下一步；关键链接可打开。
- 输出：项目目录中的调研笔记与一条决策。
- 异常：一直等待同步时，先打开对应的 Obsidian Vault 与插件状态，不重复提交。
第二次调研按它执行；完成后复盘发现“缺少反方证据”，就在步骤中新增一项。SOP 因真实使用变得可靠。
遇到重复问题再更新 SOP
每个失败都写成规则，会让流程很快失去可读性。失败能够复现、确实影响结果，并且有明确的预防或恢复动作时，我才更新 SOP。
复盘时记录：原步骤哪里含糊、什么证据证明完成、下次能否更早发现异常。更新记录写原因，不只写“优化”。
SOP 库不必很大
我先按触发场景检索，不急着搭建复杂分类。一个 SOP 长期没有被使用，可能应该归档；两个 SOP 高度重叠，合并公共步骤；执行者必须临场猜测，补充输入或完成检查。
BrainPost 负责把调研、来源和复盘材料送到本地。将哪次经验晋升为 SOP、怎样修改步骤，仍是人的判断。