Imported from TRY-0508/basic-setting (
skills/knowledge-accumulation/SKILL.md). Install upstream withnpx skills add TRY-0508/basic-setting --skill knowledge-accumulation. Copyright stays with the author (MIT).
经验知识沉淀
解决两个核心问题：
本 skill 生成的模式、回顾和总结文档均遵循 AGENTS.md 中的「个人文档内容偏好」：平实语言、具体而非抽象、不堆砌术语、不用虚饰限定词。
- 总结过于具体：提取的经验绑定在单个项目上下文上，无法跨项目复用
- 触发不了：已有 skill 的描述不够精确，LLM 不会自动加载
1. 模式模板
沉淀经验时使用以下模板，确保在抽象和具体之间取得平衡：
### 模式：[短名称，3-10 字]
**触发条件**：遇到什么情况时应该用这个模式？（用`特征`描述，不要绑定特定项目）
**做法**：具体怎么做？（1-4 步）
**原理**：为什么这样做有效？
**实例**：从一个真实项目案例中抽象出来的情景说明（去掉项目特有名词，保留结构）
**反模式**：常见的错误做法，或这样做会导致什么问题示例：好的模式 vs 差的模式
差的模式（过于具体）：
"在 notebook-ai 项目中，我们用
src/core/validator.ts来校验用户输入..."
好的模式（适当抽象）：
模式：输入校验前置
触发条件：外部输入（用户请求、API 响应、文件读取）进入核心逻辑前 做法：在模块入口处放置校验层，核心逻辑假定输入已通过校验 原理：分离校验关注点，核心逻辑更简洁。错误尽早返回，减少无效计算 实例：用户请求 → Controller 校验参数 → 校验通过才进 Service 层。Service 不重复校验 反模式：在多个层级重复校验同一输入，导致校验逻辑分散且不一致
2. 经验分类
沉淀时先判断类型，不同类型存放位置不同：
| 类型 | 定义 | 存放位置 | 示例 |
|---|---|---|---|
| 原则 (Principle) | 做什么、不做什么的行为准则 | 优先放到对应 skill 文件，或 AGENTS.md | "设计文档不含历史痕迹" |
| 模式 (Pattern) | 可复用的做法，有触发条件和使用方式 | 相关 skill 文件中添加"模式"章节 | "输入校验前置" |
| 反模式 (Anti-pattern) | 常见错误及其后果 | 附加在对应模式后，或相关 skill 中 | "提案放在文档末尾" |
| 约定 (Convention) | 特定领域的命名、格式、流程约定 | 对应 skill 文件 | "论文 PDF 命名格式" |
| 触发词 (Trigger) | 什么话/什么场景应该触发哪个 skill | 对应 skill 的 description 字段 |
见第 4 节 |
不是所有经验都值得沉淀
沉淀前问自己：
- 这个经验在另一个项目中也有用吗？
- 是不是一个可重复的决策模式？
- 如果只有这一次会遇到，那不需要沉淀。
3. 从具体到抽象的方法
当 LLM 在项目中注意到一个值得记录的经验时，按以下步骤处理：
Step 1: 记录原始实例
在项目 X 中，我们遇到了问题 P，用方法 S 解决，结果 R
Step 2: 剥离项目上下文
去掉"项目 X""模块名 Y""具体的文件名"等特有信息
提炼：什么底层问题？什么通用的解决思路？
Step 3: 匹配已有分类
这是原则、模式、反模式还是约定？
是否与已有模式冲突或重复？
Step 4: 选择存放位置
属于某个现有 skill 的领域 → 追加到该 skill
全新领域且模式数 ≥ 3 → 考虑创建新 skill
跨领域的通用原则 → AGENTS.md
Step 5: 用模板编写
使用第 1 节的模式模板格式化
确保"实例"部分是一个能独立理解的小场景
4. 触发条件优化
Skill 能否被自动加载，取决于 description 字段的质量。
4.1 好的触发描述应包含
- 场景描述：在什么情况下应该用这个 skill
- 具体触发词：用户在对话中可能说的原话（3-8 个）
- 边界说明：什么情况下不要用这个 skill
4.2 触发描述模板
description: |
[1-2 句核心场景描述]。
触发语："[用户原话1]""[用户原话2]""[用户原话3]"
不要用在：[不适用场景]。4.3 触发优化检查清单
检查一个 skill 的触发描述是否合格：
- 如果不看 YAML 名字，只看 description，能猜到是什么 skill 吗？
- description 中是否包含 3 个以上的具体用户问法（用引号括起来）？
- 是否有"不要用在"排除不适用场景？
- 触发词是否覆盖了用户可能说的不同表述方式？
4.4 常见触发问题
| 问题 | 示例 | 修正 |
|---|---|---|
| 太抽象，没有具体词 | "管理项目流程" | "讨论设计方案""组织文档结构""拆分模块""创建 INDEX.md" |
| 只用术语，不用日常语 | "进行域驱动设计" | "按功能拆分""模块怎么划分""接口怎么定义" |
| 覆盖太广，误触发 | "写代码时" | "当项目超过 3 个模块时""当需要协调多个文档时" |
| 没有触发词 | "科研写作规范" | 加上"写论文""LaTeX 排版""课程论文""毕设""Word 排版" |
5. 项目回顾流程
当用户说"总结一下""回顾""学到了什么"或项目阶段结束时：
5.1 回顾清单
## 项目回顾
### 什么有效
- [具体做法/模式]：为什么有效？
- [具体做法/模式]：为什么有效？
### 什么问题反复出现
- [问题]：根因是什么？后续如何避免？
- [问题]：根因是什么？后续如何避免？
### 有什么工具/流程可以改进
- [改进点]：当前问题是什么？建议怎么改进？
- [改进点]：当前问题是什么？建议怎么改进？5.2 回顾输出
- 立即行动：哪些经验现在就值得写入 skill 或 AGENTS.md？
- 观察项：哪些还不够成熟，需要再多观察几次？
- 不需要处理：哪些只是这一次项目的特殊情况？
5.3 回顾频率
不需要等到项目完全结束。以下时机都可以触发小回顾：
- 完成一个模块后
- 遇到一个特别棘手的问题解决后
- 用户说"这个地方要注意"
- 同一个错误出现第二次
6. 知识新鲜度维护
6.1 何时更新已有模式
- 发现模式有例外情况 → 更新"触发条件"或"反模式"
- 找到更好的做法 → 更新"做法"，旧的转为"反模式"
- 模式变得不再适用 → 标记为"已废弃"+
6.2 何时拆分/合并
- 一个 skill 文件超过 200 行 → 考虑拆分
- 两个模式本质上说的是同一件事 → 合并
- 一个模式的"做法"分叉成两个方向 → 拆分为两个独立模式
7. 与其他 skill 的关系
consistency-management：其中发现的一致性问题模式应沉淀到本 skillproject-workflow：文档组织相关的经验追加到 project-workflowkarpathy-guidelines：行为层级的经验追加到 karpathy-guidelines- 下载安装的 skill：不得修改其文件。如果经验属于该领域，在本 skill 中添加"补充模式"章节