learn-and-improve

学习与改进

PDCA 的 Act 阶段：将已完成的工作转化为可复用的知识。这项技能之所以存在，是因为大多数“经验教训”环节都流于浅表——只列出含糊的“哪些做得好／哪些做得不好”，虽然记录了经验，却从未应用。这项技能让复盘和沉淀成为一种严谨且有深度的实践。

为什么需要这项技能

在各种 PDCA 式修复工作流中，审查阶段常常被视为事后补充——每个宿主都自行编写一个浅显的内联版本，没有人引入真正的方法论，同样的经验被记录下来后又遭遗忘。可以对比 solution-review：它是一项针对第 3 阶段的深度独立技能（引用 FMEA / SRE PRR / CBAM）。这项技能是 Act 阶段的对应技能：同样深入、以方法论为依据且可复用。

它要解决的核心问题是 “记录了却没有应用”——经验写进文档后就再也没有被查阅。PMI 将此视为经验教训项目最主要的失败原因。因此，检索／有效性验证在这里是一个首要步骤，而非事后补充（经验教训 5 步法中的 Retrieve 步骤：Identify → Document → Analyze → Store → Retrieve）。

何时使用

• 独立使用：用户完成工作后想进行反思——“复盘一下这次”、“做个回顾总结”、“what did we learn from this”。
• 集成使用：PDCA 宿主进入审查或收尾阶段，并通过 frontmatter dependencies 加载这项技能。

描述中的触发短语适用于这两种使用方式。

与其他技能的关系

• 被以下对象引用：PDCA 宿主通过 frontmatter dependencies 引用（强依赖；缺失时 → 宿主在前置条件检查时中止）。宿主是此依赖关系的事实来源——这项技能不会维护集成方名称列表。
• 类似于：solution-review（针对第 3 阶段的深度审查技能）。这项技能是针对 Act 阶段的深度审查技能。模式相同，阶段不同。

框架——4 个步骤

步骤 1——结构化复盘

不要默认采用含糊的“哪些做得好／哪些做得不好”列表——这正是这项技能要取代的问题。根据具体情况选择格式（完整指南见 reference.md § 复盘格式）：

• Stop-Start-Continue——轻量，适用于新团队和短周期。
• KPT (Keep / Problem / Try)——以问题为导向，发现问题并提出实验方案。
• After-Action Review (AAR)——适用于项目结束或事件结束后，以及重大事件。包含四个问题：原本打算做什么 → 实际发生了什么 → 差距为何产生 → 要做出哪些改变。

找出三类发现：有效做法（保留）、失败的经验（避免）和意外发现（往往最有价值——没人预料到的事情）。

随后，对任何非简单的失败进一步使用 5Why：追查根本原因，不要停留在症状上。停留在症状层面的“经验教训”会导致下次重蹈覆辙。

步骤 2——判断沉淀价值（决定哪些经验值得保留）

大多数“经验教训”只适用于单次情况，不应固化为长期规则。对每个候选项依据三道关卡进行判断（完整决策树见 reference.md § 沉淀价值）：

1. 是否会再次发生？——未来的项目／任务是否有可能遇到同样的问题？如果不会 → 仅写入总结文档，不要设为规则。
2. 是否经过验证？——是否已在 ≥2 个不同场景中得到确认，而非单次巧合？如果没有 → 暂缓，暂不固化（将一次巧合过度泛化为规则，会造成污染）。
3. 是否属于团队／工程层面，而非个人偏好？——不得将个人喜好强加为团队规则。

只有通过全部三道关卡的候选项，才适合长期沉淀。其余内容应放入一次性总结文档。

本质上，这是 SECI Externalization（Nonaka & Takeuchi）——将隐性经验转化为显性规则。并非所有隐性知识都应该显性化——只有反复出现、经过验证且为众人共享的知识才应该如此。

步骤 3 — 载体选择（写入位置）

根据受众 × 持久性 × 变更频率来选择，而不是凭习惯。完整决策树见 reference.md § 载体选择；概要如下：

载体	适用场景
AGENTS.md	跨工具、面向整个团队的长期工程规范
CLAUDE.md	Claude Code 特有的行为或工作流偏好
.cursor/rules/	Cursor 专属规则
项目技能	稳定、可复用的工作流／领域知识，未来工作可自行触发
CONTEXT.md（通过 domain-language-discipline）	仅用于项目通用语言／术语表，不用于实现或 OpenSpec 规格
总结文档	一次性回顾、背景记录（不是规则）

写入任何长期载体前，请等待用户明确请求（“写入规则”／“创建技能”／“更新 AGENTS.md”）。默认做法是提出建议，而不是写入——随意写入共享的长期规则会污染规范，这是一扇单向门。

步骤 4 — 效果验证与改进循环

这是大多数评审会跳过的一步，也是解决“已记录但未应用”问题的关键。

• 为每项固化内容定义检索／复用机制——触发条件、检查清单、守护措施或 CI 规则。无人检索的规则就是累赘；只有在之后被检索并应用，沉淀的价值才能实现，而不是写下时就已实现。
• 检查学习深度：你是否只是在修正表面行为（单环学习——“换种方式做 X”），还是也在质疑根本假设和目标（Argyris 的双环学习——“我们当初为何会假设 X？”）？对于顽固或反复出现的问题，应推动双环学习。
• 改进循环：如果评审得出目标未达成的结论，应反馈到相关的前置阶段，而不是到此为止。（在集成模式下，由宿主工作流决定返回哪个阶段。）

两种模式

• 集成模式（由工作流的评审阶段调用）：宿主工作流负责阶段编排（例如，solve-workflow 可能会返回分析／规划阶段；opsx-solve-workflow 还会归档 OpenSpec 变更并运行覆盖率门禁）。**本技能负责如何反思和沉淀，不负责阶段顺序。**对已完成的工作执行步骤 1–4，并返回沉淀建议和下一步建议。
• 独立模式（由用户直接触发）：完整执行步骤 1–4。如果不清楚已完成工作的范围，请先询问要评审哪项工作。

输出

【Learn & Improve — 回顾总结】
1. Retrospective (format: SSC / KPT / AAR)
   - Keep (effective practices): ...
   - Problem / Avoid (failed lessons): ...
   - Discoveries (unexpected): ...
   - Root cause (5Why, for any non-trivial failure): ...
2. Sediment candidates (judged)
   - ✅ Solidify: <item> → <carrier>   (recurs × verified × team-level)
   - ⏸ Hold (unverified): <item>
   - 📝 One-off only: <item> → summary doc
3. Effectiveness
   - Retrieval/reuse mechanism per solidified item: ...
   - Learning depth: single-loop / double-loop (did we question assumptions?)
4. Next step
   - Loop back to <stage> / conclude

反模式

• ❌ 没有框架的模糊“哪些做得好／哪些没做好”——这正是本技能要替代的问题。
• ❌ 将一次性的巧合固化成规则（过度泛化）。
• ❌ 将未经验证的猜测写入 AGENTS.md／CLAUDE.md——这会污染长期规则；应先在至少 2 种场景中验证。
• ❌ 没有检索途径的沉淀——“已记录但未应用”。
• ❌ 假设本身有误时，只做单环修正（调整行为）——应推动双环学习。
• ❌ 不顾情境，一律采用同一种回顾格式（重大事故采用 SSC，与琐碎调整采用 AAR 一样不妥）。
• ❌ 在集成模式下接管宿主工作流的阶段编排——你负责如何反思，而不是阶段顺序。

参考

深入内容——包括完整的回顾格式对比、沉淀价值与载体选择的完整决策树、单环／双环学习、SECI 外化，以及扩展版反模式目录——见 reference.md。当某个步骤的判断存在歧义时，请阅读相关章节。