用途
growth-log 是一个成长记录撰写技能，用于把已完成工作中可复用的模式提取出来。它的定位不是写日记，而是产出「学习工件」：多数人会把「修好了 X 里的一个 bug」当作学习日志，但那只是日记式记录，真正的成长记录应当提炼出模式，使你在下次遇到类似情况时能够识别出来。
该技能可与任意笔记系统配合使用——Markdown 文件、Notion、Obsidian 或纯文本皆可，模板是通用的，需按自己的环境调整。
何时启用
- 完成复杂任务之后（涉及多文件、新功能、架构变更）
- 经历失败、犯错，或出现「这比预想难得多」的时刻之后
- 想要回顾某一时期学到了什么时
不启用的情况：琐碎改动（错别字修复、单行微调、无需调试的配置值修改）。判断门槛是：这个任务是否涉及调试、返工、回滚，或非显而易见的决策？是则写条目，否则跳过。
三条规则
规则一：失败优先于成就。 一次失败的信息密度高于一次成功。一个花两小时才找到的 bug，比三个一次就通过的功能更有教学价值。
示例（反对）：「成功实现了登录流程。」
示例（推荐，Web 开发）：「登录流程：会话令牌没有持久化，因为 Chrome 128+ 中 cookie 的 SameSite 默认为 Lax。模式：跨源时必须显式设置 SameSite=None; Secure。识别信号：浏览器升级后或跨源边界时认证失效。」
示例（推荐，数据管道）：「CSV 导入在空行上静默失败，因为 pandas.read_csv(dropna=False) 会保留零宽行，而 len() 仍将其计为有效。模式：在做行数校验前始终先执行 df.dropna(how='all', inplace=True)。」
规则二：伯乐原则。 写新条目之前先问：这与我已记录的内容是否本质相同？相同根因、不同症状 → 合并而非重复；新根因 → 新条目。检查方法是写之前用根因关键词搜索已有条目，若找到匹配，就把新症状作为附加示例补充到已有条目下，而不是新建重复条目。
示例：「创建文件后忘记更新输出索引」与「任务完成后忘记更新技能评分」——根因相同（缺少自动捕获触发器），应合并为一条关于「任务后捕获缺口」的记录。
规则三：必须可迁移。 每条记录都必须回答：下次面对类似情况，我会做什么不同？如果写不出这句话，说明模式还没被提取出来。
从具体事件中提取模式的方法：
- 用一句话陈述发生了什么
- 迭代追问「为什么」，直到抵达根因（通常 3-5 个为什么）
- 泛化：「这属于哪一类问题？」（不是「Chrome 128 的 bug」，而是「浏览器默认值变更破坏既有行为」）
- 表述为：「下次我看到 [信号]，我会 [动作]。」
- 命名信号：什么具体的可观察现象告诉你这个模式正在生效？
条目模板
范围：每个不同根因写一条。典型长度为 4-8 句。如果写起来超过 2 分钟，你是在叙述事件；如果少于 30 秒，说明挖得不够深。
## [标题：写模式，不写事件]
### Context
- 我试图做什么？
- 什么出错了 / 什么意外地顺利？
### Root Cause / Core Insight
- 底层机制，而不仅是症状
### The Pattern（可迁移）
- 下次遇到 [类似情况]，我会 [具体动作]。
- 识别信号：[什么可观察现象告诉我这个模式正在生效？]
### Related
- [entry-name](../path/to/related-entry.md)
条目类型
以下四种类型都使用上述模板，类型决定哪些部分承载最多分量：
- 失败（Failure）：适用于出了故障、需要调试或返工的情况；重点是根因。示例标题：「Config inheritance ≠ behavior inheritance across sessions」
- 方法论（Methodology）：工作中浮现出可重复的流程；重点是 Context / Pattern。示例标题：「PPT → open-book exam study guide: three-layer structure」
- 模式发现（Pattern Discovery）：关于工具、系统或思考的可复用洞见；重点是 Pattern 部分。示例标题：「PR description template: describe the gap, not the feature」
- 能力变化（Capability Change）：可衡量的技能提升；重点是 Context（前后对比）。示例标题：「Git: from clone/push to independent PR with 12 commits」
质量检查清单
在最终确定条目之前，检查：
- 标题是否命名了模式，而不是事件？
- 是否有「下次我会……」的句子？
- 「识别信号」是否足够具体，能在下次触发这个模式？
- 写之前是否搜索过已有条目以排查重复？（伯乐原则）
- 根因是否与症状区分开来？
- 相关记忆是否交叉链接？
- 条目是否为 4-8 句？更短则太浅，更长则是在叙述事件。
反模式
- 避免：「修复了支付模块的 bug」（这是事件，不是模式）
- 避免：逐字复制 git commit 信息（提交描述改了什么，日志提取的是为什么重要）
- 避免：为每个提交都写条目（只在模式浮现时写）
- 避免：省略可迁移的那句话（没有它，就只是日记——这一点不可让步）
- 避免：用不同标题重复同一模式（违反伯乐原则，写前先搜索）
存储
把条目存放在你保存笔记的地方。常见做法：
- 在 growth-log/ 目录下用 Markdown 文件（每天一个文件：YYYY-MM-DD.md）
- 在 Notion、Obsidian 或笔记应用中开设专门分区
- 采用一致命名约定的纯文本文件
选定一种约定并坚持使用。可检索性比格式更重要。
与 Delivery Gate 配合
若使用 delivery-gate，其 Stop 钩子会通过文件系统时间戳检查学习文件当天是否被修改。本技能教的是「写什么」，因此 delivery-gate 检查的文件里承载的是有用的模式，而不是空时间戳。
流程为：任务完成 → delivery-gate 检查学习文件今天是否被改动 → 过期（无文件被修改）：拦截，问「你学到了什么？」 → 新鲜（文件被修改）：通过。本技能确保内容有用。
有执行机制而无方法论 → 条目空洞；有方法论而无执行机制 → 遗忘捕获。两者各自都有价值，合在一起才闭环。