When to Use

• 触发语：「复盘」「总结」「回顾」「写个教训」「记一笔」
• 自检触发：用户纠错后 / 跨 agent 交接失败后 / 连续两次踩同类坑 / 一次改动牵动 ≥3 个文件或外部服务 / 一次会话烧 token > 30 万
• 不用于：纯跑流程（无坑无结论的完工不算复盘，最多记一条「完成」到 log）

复盘（retrospective）

把"今天做完了"变成"未来不会再踩同一脚"。结论先行：四处都落文件 + 八项校对全过 + wiki lint 0 issues + 一笔 commit，才叫复盘完成；任一不过只能报「未完成 + 卡在哪」。

准则全文（事实源）：本技能 references/retrospective-standard.md（通用版）。本技能是流程骨架与触发语；详细字段、判据、反模式、收尾五问都从那读，不在这复写——避免双写飘移。

流程骨架（六步）

1. 定位要复盘的对象：单次会话/单次事件/单条教训/一次跨 agent 交接——四种粒度选一种，别混。
2. 跑四连（骨架见下，正文判据读 retrospective-standard.md 第一节）：
   • ① 教训库 <MEMORY_DIR>/lessons-learned.md（先挂靠后开号；追加规则见记忆库入口 README 的 Append SOP）
   • ② 技能 <SKILLS_DIR>/<name>/SKILL.md（下次同类任务会加载的那个）
   • ③ Wiki ~/wiki/（建/改页面 + index.md + 对应域 GUIDE.md 收录清单 + log.md 三连）
   • ④ commit（2026-10-14 知识层入库后新增）：git status 分清自己的改动 → 只 git add 自己动过的文件（禁 git add -A，多 agent 共用这三处）→ 提交前重跑凭据扫描（只列路径不打印内容）→ 一笔 commit 装完本次三处改动，message「复盘：<主题>」。永不推远端；回滚 = git checkout -- <path>。
3. 跑八项校对（每项留一行实测输出：命令 + 结果）—— 全文在 retrospective-standard.md 第二节；不重写，重点是这三项最常踩：
   • 计数必带口径命令（禁 ls -1 | wc -l 手数，10-12 39→41 实踩）
   • 事实断言逐条现场复核（API 端点名、md5、端口、进程号都是，10-12 wiki 页里 api/list 写成泛称实踩）
   • 改完回跑依赖方（改共享看板必跑其配套校验脚本、改 wiki 必跑 lint）
   • 索引指针类字段要单独核：给共享索引追加了带编号的新条目（lessons 编号、log 序号、wiki 页）之后，索引里「指向最新那条」的指针字段会静默过期——deep-memory/README.md 的「最新 #NNN」指针、wiki/index.md 的「Last updated」行都属于这类：它们不在你新写的那个文件里，不主动 grep 就不会发现过期。八校对没有这项，每次给编号体系追加条目后手动补跑：grep -n '最新 #' <MEMORY_DIR>/README.md、grep -n 'Last updated' ~/wiki/index.md，与新条目的编号/日期对不上就改。
   • 共享文件追加条目前，先确认谁在里面：lessons-learned.md / server-notes.md / wiki index+log 是多 agent 共用的，文件里同时存着对方的条目。追加自己那条后 git add <file> 会把对方的改动一起扫进本次 commit——这不一定是坏事（省得他们再提交一次），但commit message 必须写明连带收编了谁的内容，否则下次对方 diff 时会看到「我的条目消失在一个我没见过的 commit 里」。规则：先 git diff <file> 看未提交的部分属于谁，再决定 add 哪些文件，并在 message 里点名。
4. 跑硬门槛：retrospective-standard.md 第三节打勾清单——任一不过只能报「未完成 + 卡在哪」，不得宣布完成。
5. 校对抓到错误当场修 + 复检，修不了列进待办/W<n>，不许静默跳过。
6. 交付：四连落点清单（①②③ 文件落点 + ④ commit hash）+ lint 结果 + 本轮抓到的错误与处置；收尾自检五问（retrospective-standard.md 第五节）。

③ wiki 蒸馏的改页操作（patch 是替换语义，不是插入语义）

给已有 wiki 页加一个新章节时，最顺手的做法是拿旁边一行当锚点去 patch——这会删掉锚行。patch 把 old_string 那行从文件里拿掉，不会自动替你留在 new_string 里；只把它顶掉而没重新写出，那行就没了。

危险锚点有两类，删掉后都不报错：

• 交叉链接行（- 见 [[other-slug|…]]）：删了 = 该页少一条出链。lint 的断链检查看的是「目标页有没有入链」，少一条出链它不报，所以 lint PASS 也发现不了。
• 节尾最后一条 list：删了 = 一节内容凭空少一条。

做法三条任选：①new_string 里原样带回锚行（新节写在前或在后都行）；②改让锚点是新节标题本身（old_string 取一段将被重写的正文首句）；③插完 tail -40 <page> 回读文件尾，逐行确认锚行还在。

这是「四连第③步」的专属检查点，不在八校对清单里，但八校对第 3 项（事实断言现场复核）要靠它才成立——锚行被删后，你的「本轮改动清单」和文件实际内容就对不上了。

四连落点判据（①②③ 避免三处写一样；④ 是固化动作不是内容层）

落点	该层该有的形态	不该写的
① lessons	现象 → 根因（机制层）→ 解法（带命令）→ 自检句；缺自检句 = 只是日志	不写日期叙事流水账
② 技能 SKILL.md	祈使句 + 为什么 + 坑带实踩日期与回滚方式；写到下次同类任务会 load 的那个技能	不复写 lessons 的整段叙述
③ wiki 页面	事实描述 + 命令/路径/端口/常量 + 引用源；frontmatter 六字段齐 + 出链 ≥2 + 至少 1 个别页链入（否则 lint 孤儿页）	不写个人语气、不写日期叙事

判错落点的代价：「下次遇到 X 类任务怎么做」写到 wiki 没用（不 load），「这环境有什么坑」写到技能没用（不 load），「这台机器现在什么样」写到 lessons 没用（没有可读查询接口）。

八项校对速记（详见准则第二节）

1. wiki lint 0 issues（medium 也不算过）
2. 数字必带口径命令，与权威脚本一致
3. 事实断言逐条现场 grep/run 复核
4. 占位符清零（<见…>/<填>/TODO/待补）
5. 编号唯一（lessons/W<>/log 条目不撞号、不跳号）
6. 改完回跑依赖方（看板→配套校验脚本、wiki→lint、技能→注明"开新会话才生效"）
7. 动共享文件前重读尾部（防并发覆盖，10-12 实踩）
8. 结构完整性对账（板 6 段/5 条/0 留言抬头/wiki 实际页数=index Total=GUIDE 行数）

二·三、用户说「校对」时的独立复核（2026-10-12 实测要补的环节）

• 用户说「校对/校一遍/check」→ 不重新跑八项校对就算完——那只是重放生成步骤。用户要的是独立视角。
• 流程：① 用 docx_read.py --text（或对应产物的全量读接口）把产物全读出来当陌生文件看待；② 关键数字/编号/章节数/副标题逐项 grep 独立口径（不要用生成时用的同一段脚本，防止同一个 bug 复现）；③ 与权威源（lessons 真实条数= grep -oE '^[0-9]{2,4}\\. \\*\\*' ... | grep -oE '[0-9]+' | sort -n | wc -l，wiki 页数= find ... | wc -l 等）双向核对；④ 发现错直接 docx_edit.py replace 原地改或 patch 文件，再 read 复检，最后跑 docx_validate；⑤ 报告里写「原值/新值/口径命令/出错性质（写错 vs 算错 vs 漏列）」。
• 结构化元数据最易错：章节副标题（应列几条 vs 实际列几条）、编号最大号 vs 实际条数、版本号 vs 装版本、占位符。这些是 write_file 时按"约数"写的，不是按计算结果写的。
• 与「二·零、写前取值」配对：二·零管写之前的取值，这条管写之后被用户要求校对时的复核。

反模式（出现即打回重做，全文七条在准则第四节）

• 复盘 = 复述今天干了什么（流水账）
• 只写「做了什么」，不写「为什么错/下次怎么防」
• 同一段落在三处互相抄（每层写各层该有的形态）
• 数字不带口径、断言不带出处
• 拿别人的「已确认送达」代替自己复核（发件方的自检不是收件方的证据）
• lint 没跑/没过就宣布完成
• 为过 lint 凑链接凑来源（入链要真的让邻居页受益）

与其他技能的关系

• 本机任何会话的「总结/复盘」收尾都走本技能；不要只发一张汇报图了事——那只是「进度汇报」，不是复盘。
• 各领域技能自己的 pitfalls 管领域内专项（惯例、闸门、任务结果分类等），领域内教训不挪走；本技能管跨领域通用骨架。
• problem-solving Step 6 的"复盘"是问题解决后的单条教训，粒度比本技能小——本技能可以引用它。
• llm-wiki-slim 的 Ingest workflow 是 wiki 子任务的标准动作；本技能在四连第③步直接调它。

二·零、写前取值（2026-10-12 用户定，防「为什么总是不能一遍搞好」）

• 写进任何产物或回复的路径、版本号、数字，落笔前当场跑一次取值，不允许凭记忆写：路径用 [ -f ]（或全局文件搜索确认存在），版本用 pip3 show/--version/python3 -c "import x;print(x.__version__)"，数字用 nproc/free -h/df -h/wc -l。批量跑完再一次写入，别边写边猜。
• 跑不了的（站点反爬 403、被墙）→ 换能跑通的口径，或在产物里标「未验证」。
• 自检句：这条路径/数字我今天在这台机器上跑过吗？没跑 → 先跑再写。
• 口径也要验：跑了 ≠ 对。凡 count 类结果要写进产物，先 sed -n '1,3p' 看数出来的头几行是不是你以为的东西，或拿已知数对照，再落笔（实例：ffmpeg -filters | grep -cE '^ ' 多算 7 行图例，474 实为 467）。
• 两分法：「跑了才知道」属正常循环成本（lint 规则、上游陈旧常量、站点反爬都在这层）；「没跑就写」是可消除的错，校对报告里两类分开列。

二·一、下诊断/分类前先做反方证据扫描（2026-10-15 实踩沉淀）

数字 + 词表类诊断（"X 处污染 / N 条假任务 / Y 个口子"）在报给用户当事实之前，必须先做反方证据扫描，不只正向跑一次词表就下结论。

• 正向跑是「这个词在不在文件里」；反方是「这个词在别的地方还有没有别处出现、出现得合不合理」。常见误伤：① 假数据引用过真实 id/agent 名（真实存在的 id 被测试数据引用过 → 拿它当指纹跨文件复用必误伤）；② 站内界面词（界面提示语在前后端代码里本来就有多处）；③ 真实数据自有字段（实例 id、任务编号、用户名字）。
• 三件套必跑：① 命中归属反查——grep -n 词 文件 站代码 确认这个词是不是代码自有、别处还在哪里出现；② 演示窗口复核——指明"哪段时间/哪个副本"是真、其它是污染，跨窗口不能混；③ 真实数据抽查——挑 1-2 条命中项去源数据（配置/任务表/流水日志等）核它到底是真是假。
• 自检句：这个指纹词站代码/真实数据里还有别处出现吗？假数据引用的 id 是不是正好真实存在的？三件套任一没过不下结论。

结论复查推翻就公开撤回，别将错就错：发出"X 处污染"类报告后，如果用户批了清理但复查发现是误判，必须同轮就公开撤回（不是埋进下一轮、不是只在 todo 里悄悄改），列清「撤回什么 / 实际是什么 / 三件套哪一步漏了」。用户的信任账户不靠"坚持原判"积攒，靠"复查到位就改"积攒。

• 与二·零（写前取值）配对：二·零管已知事实的取值（路径/版本/数字），二·一管分类/诊断的反方验证。
• 与本节正模式（"X 处污染"事故）的反义 = 「X 处是污染、Y 个是待办」那种「已发报告带数字、漏做反方」的形态最容易在事故刚处理完的复盘里再发一次。

二·二、产物 vs 源头：改生成物必须回改源头，否则重新生成即回退（2026-10-12 用户定）

• 产物由 spec/模板/源数据生成时（docx 由 spec JSON 生成、报告由模板生成、wiki 由源页生成），修错必须改源头 + 重新生成；只改产物 = 下次生成时被静默冲掉。
• 触发语场景：用户说「再写一版/重写/补一段/更新」 → 这是重新生成信号 → 必查产物里的修正是否已落源头，否则修复丢失。
• 自检句：这个文件是「生成物」还是「源头」？改的是生成物的话，源头改了吗？源头没改就重新生成 = 把已修对的内容打回原样。
• 例外：产物视作一次性（已交付、不会再生成）才允许只改产物。
• 与「二·零、写前取值」和「二·三、独立复核」配对：二·零管写之前取值，二·三管写完之后被校对时复核，本节管多轮生成场景下的回退。

完成判据

• ①②③ 三处都有文件级改动（口头/聊天说明不算）
• 第④环有一笔 commit，git status --porcelain 收尾干净
• wiki lint 0 issues
• 八项校对每项有实测输出
• 每个数字带口径命令，每条事实断言带出处或现场复核
• 校对抓到的错误当场修完复检；修不了列待办
• 向用户交付清单含「四连落点（含 commit hash）+ lint + 本轮抓到的错」

未完成时只报「复盘未完成 + 卡在第 N 步 + 缺什么」，不报"差不多做完了"。

收尾自检五问（2026-10-15 增）

四连 + 八校对 + 硬门槛全过、准备宣布复盘完成前，先问自己这五题，任一没过 = 复盘未完成、不许发完成消息：

1. 本次进的是哪一类粒度？ 单次会话 / 单次事件 / 单条教训 / 一次跨 agent 交接。混粒度 = 落点判错（教训写进 wiki、技能写进 lessons）= 必返工。
2. 落点判据对得上吗？ ① lessons 形态=现象→根因→解法→自检句；② 技能=祈使句+为什么+坑+实踩；③ wiki=事实+命令+路径+出链≥2。形态错位 = 写成日志不是复盘。
3. 数字/版本/路径今天当场跑过几次？ 「写前取值」跑了 = 校对时口径命令必须和它一致；没跑就靠记忆 = 八校对抓的 3 条里大概率有 1 条是这种。
4. 「用户说了先复盘再继续」我拖到下一轮了吗？ 复盘是当下事的收尾，不是写完代码之后的可选步骤——用户把复盘拎出来说 = 这一刻就要做，别合并到下一会话。
5. commit 里只装了我自己动过的文件吗？ git status 分清多人共改区再 git add；多装一个别人的改动 = 把他的活也签到我账上，下次他动的时候 diff 会诡异。