growth-log

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Growth Log Skill

成长日志技能

The problem: Most people write "fixed a bug in X" as a learning log. That's a diary entry, not a learning artifact. A real growth log extracts the pattern so you recognize it next time.

This skill teaches: How to write learning entries that compound across sessions. Works with any note-taking system — Markdown files, Notion, Obsidian, plain text. Templates are generic; adapt to your setup.

存在的问题： 大多数人在学习日志里写“修复了X中的bug”，这只是流水账，而非有价值的学习成果。真正的成长日志会提炼出可复用模式，以便下次遇到类似情况时能识别出来。

本技能教授： 如何撰写能在不同阶段积累价值的学习记录。适用于任何笔记系统——Markdown文件、Notion、Obsidian、纯文本文件。模板通用，可根据你的使用场景调整。

When to Activate

适用场景

After completing a complex task (multi-file, new feature, architecture change)
After a failure, mistake, or "that was harder than expected" moment
When you want to review what you've learned over a period

When NOT to activate: Trivial changes (typo fixes, single-line tweaks, config value changes with no debugging). The threshold: did this task involve debugging, redoing, rollback, or a non-obvious decision? If yes → write an entry. If no → skip.

完成复杂任务后（多文件修改、新功能开发、架构调整）
遭遇失败、犯错或“这事比预想的难”的时刻后
想要复盘某段时间所学内容时

不适用场景： 琐碎修改（拼写错误修复、单行代码调整、无需调试的配置值修改）。判断标准：这项任务是否涉及调试、返工、回滚或非显而易见的决策？ 如果是→撰写记录；如果否→跳过。

The Three Rules

三大原则

Rule 1: Failures > Achievements

原则1：失败＞成就

A failure is nutritionally denser than a success. One bug that took 2 hours to find teaches more than 3 features that worked first try.

Bad: "Successfully implemented the login flow." Good (web dev): "Login flow: session token wasn't persisting because the cookie

SameSite

defaulted to

Lax

in Chrome 128+. Pattern: always explicitly set

SameSite=None; Secure

when cross-origin. Signal to recognize: auth breaks after browser upgrade or when crossing origin boundaries." Good (data pipeline): "CSV import failed silently on empty rows because

pandas.read_csv(dropna=False)

keeps zero-width rows that

len()

counts as valid. Pattern: always

df.dropna(how='all', inplace=True)

before row-count validation."

失败的学习价值比成功更高。一个耗时2小时才找到的bug，比3个一次就成功实现的功能教会你的东西更多。

反面示例： “成功实现登录流程。” 正面示例（Web开发）： “登录流程：会话令牌无法持久化，原因是Chrome 128+中Cookie的

SameSite

默认值为

Lax

。模式：跨域场景下需显式设置

SameSite=None; Secure

。识别信号：浏览器升级或跨域后认证功能失效。” 正面示例（数据管道）： “CSV导入遇到空行时静默失败，因为

pandas.read_csv(dropna=False)

会保留零宽度行，而

len()

会将其视为有效行。模式：在进行行计数验证前，务必执行

df.dropna(how='all', inplace=True)

。”

Rule 2: The Bole Principle (伯乐原则)

原则2：伯乐原则

Before writing a new entry, ask: "Is this fundamentally the same as something I already recorded?"

Same root cause, different symptom → merge, don't duplicate. New root cause → new entry.

How to check: Search existing entries for keywords from your root cause before writing. If you find a match, add your new symptom as an additional example under the existing entry rather than creating a duplicate.

Example: "Forgot to update the output index after creating a file" and "Forgot to update skill ratings after a task" — same root cause (no automatic capture trigger). Merge into one entry about "post-task capture gaps."

撰写新记录前，先问自己：“这本质上和我之前记录过的内容是否一致？”

如果是同一根因、不同症状→合并，不要重复记录。如果是新根因→创建新记录。

检查方法： 撰写前，用根因相关关键词搜索已有记录。如果找到匹配项，将新症状作为附加示例添加到已有记录下，而非创建重复条目。

示例： “创建文件后忘记更新输出索引”和“完成任务后忘记更新技能评分”——根因相同（缺少自动触发的记录机制）。合并为一条关于“任务后记录遗漏”的条目。

Rule 3: Must Be Transferable

原则3：必须具备可迁移性

Every entry must answer: "Next time I face a similar situation, what do I do differently?"

If you can't write that sentence, you haven't extracted the pattern yet.

How to extract a pattern from a concrete event:

State what happened in one sentence
Ask "why?" iteratively until you reach root cause (usually 3-5 whys)
Generalize: "What class of problem is this?" (not "Chrome 128 bug" but "browser default change breaking existing behavior")
Formulate as: "Next time I see [signal], I will [action]."
Name the signal: what specific observable tells you this pattern is active?

每条记录必须回答：“下次遇到类似情况时，我会怎么做？”

如果你写不出这句话，说明还没提炼出可复用模式。

从具体事件中提炼模式的方法：

用一句话描述发生了什么
反复问“为什么？”直到找到根因（通常需要3-5次）
归纳概括：“这属于哪类问题？”（不是“Chrome 128 bug”，而是“浏览器默认值变更导致现有功能失效”）
整理为：“下次遇到[类似场景]，我会[具体行动]。”
定义识别信号：什么具体的可观察现象能让你意识到该模式适用？

Entry Template

记录模板

Scope: One entry per distinct root cause. Typical length: 4-8 sentences. If it takes >2 minutes to write, you're narrating events. If <30 seconds, you haven't gone deep enough.

markdown

undefined

范围： 每个不同根因对应一条记录。典型长度：4-8句话。如果撰写耗时超过2分钟，说明你在叙述事件；如果少于30秒，说明挖掘得不够深入。

markdown

undefined

[Title: the pattern, not the event]

[标题：模式名称，而非事件描述]

Context

背景

What was I trying to do?
What went wrong / what worked surprisingly well?

我当时在尝试做什么？
哪里出了问题 / 什么部分的效果出乎意料地好？

Root Cause / Core Insight

根因 / 核心洞察

The underlying mechanism, not just the symptom

底层机制，而非仅症状

The Pattern (transferable)

可迁移模式

Next time [similar situation], I will [specific action].
Signal to recognize: [what observable tells me this pattern is active?]

下次遇到[类似场景]，我会[具体行动]。
识别信号：[什么可观察现象能触发我想起这个模式？]

关联记录

entry-name

undefined

记录名称

undefined

Entry Types

记录类型

All four types use the template above. The type determines which sections carry the most weight:

Type	When to Use	Emphasis	Example Title
Failure	Something broke, needed debugging, or required rework	Root Cause	"Config inheritance ≠ behavior inheritance across sessions"
Methodology	A repeatable process emerged from the work	Context / Pattern	"PPT → open-book exam study guide: three-layer structure"
Pattern Discovery	A reusable insight about tools, systems, or thinking	Pattern section	"PR description template: describe the gap, not the feature"
Capability Change	A measurable skill improvement	Context (before vs after)	"Git: from clone/push to independent PR with 12 commits"

所有四种类型均使用上述模板，类型决定了各部分的侧重点：

类型	适用场景	侧重点	示例标题
失败复盘	出现故障、需要调试或返工后	根因	“会话间配置继承≠行为继承”
方法总结	工作中形成可重复的流程后	背景 / 模式	“PPT→开卷考试复习指南：三层结构法”
模式发现	获得关于工具、系统或思维方式的可复用洞察后	模式部分	“PR描述模板：描述问题缺口，而非功能本身”
能力提升	技能有可衡量的进步后	背景（前后对比）	“Git：从克隆/推送独立完成包含12次提交的PR”

Quality Checklist

质量检查清单

Anti-Patterns

反模式

Avoid: "Fixed bug in payment module" (event, not pattern)
Avoid: Copying the git commit message verbatim (commits describe what changed; logs extract why it matters)
Avoid: Writing an entry for every commit (only when a pattern emerges)
Avoid: Skipping the transferable sentence (without it, it's just a diary — this is non-negotiable)
Avoid: Duplicating the same pattern under different titles (violates Bole Principle — search before writing)

避免：“修复了支付模块的bug”（事件描述，而非模式）
避免：直接复制Git提交信息（提交信息描述的是变更内容；日志要提炼的是其价值）
避免：为每次提交都写记录（只有当模式浮现时才需要）
避免：跳过可迁移性句子（没有这句话，就只是流水账——这是硬性要求）
避免：同一模式用不同标题重复记录（违反伯乐原则——撰写前先搜索）

Storage

存储方式

Store entries wherever you keep notes. Common patterns:

Markdown files in a
```
growth-log/
```
directory (one file per day:
```
YYYY-MM-DD.md
```
)
A dedicated section in Notion, Obsidian, or your note-taking app
Plain text files with a consistent naming convention

Pick one convention and stick to it. Searchability matters more than format.

将记录保存在你常用的笔记工具中。常见方式：

```
growth-log/
```
目录下的Markdown文件（每天一个文件：
```
YYYY-MM-DD.md
```
）
Notion、Obsidian或其他笔记应用中的专属分区
命名规则统一的纯文本文件

选择一种规则并坚持使用。可搜索性比格式更重要。

If You Use Delivery Gate

如果你使用Delivery Gate

The

delivery-gate

Stop hook checks that learning files were modified today via filesystem timestamps. This skill teaches what to write — so the file that delivery-gate checks actually contains useful patterns, not empty timestamps.

Task completes → delivery-gate checks: was the learning file touched today?
  → Stale (no file modified): block — "what did you learn?"
  → Fresh (file touched): pass — this skill ensures the content is useful

Having enforcement without methodology → empty entries. Having methodology without enforcement → forgotten captures. Each is independently useful; together they close the loop.

delivery-gate

的Stop钩子会通过文件系统时间戳检查当天是否修改了学习文件。本技能教授的是写什么内容——确保delivery-gate检查的文件包含有用的模式，而非仅修改时间戳的空文件。

任务完成 → delivery-gate检查：学习文件今天是否被修改？
  → 未更新（无文件修改）：拦截——“你学到了什么？”
  → 已更新（文件被修改）：通过——本技能确保内容有价值

只有强制机制没有方法→空记录。只有方法没有强制机制→记录被遗忘。两者单独使用都有价值，结合使用则形成完整闭环。