compound-learnings
目的
每次工程工作应让后续工作更轻松。本 skill 提供一个经验沉淀与检索机制,将解决过的问题文档化为可检索的 learning 文件,避免重复踩坑。
借鉴自 compound engineering 理念:80% 的价值在规划和复盘,20% 在执行。
目录结构
在项目根目录维护 .learnings/ 文件夹:
.learnings/
├── patterns/ # 可复用的模式和最佳实践
├── gotchas/ # 踩坑记录和解决方案
├── decisions/ # 架构和技术决策记录
└── README.md # 索引(自动维护)
Learning 文件格式
每个 learning 是一个 markdown 文件,带结构化 frontmatter:
---
title: "Webhook 验证必须使用 raw body"
category: gotchas
tags: [stripe, webhook, python]
created: 2025-01-15
context: "集成 Stripe webhook 时验证始终失败"
---
## 问题
Stripe webhook 签名验证要求使用原始请求体(raw body),但 FastAPI 默认会解析 JSON。
## 解决方案
在验证前获取 raw body:
\```python
@app.post("/webhook")
async def webhook(request: Request):
body = await request.body() # raw bytes
sig = request.headers.get("stripe-signature")
event = stripe.Webhook.construct_event(body, sig, secret)
\```
## 关键点
- 必须在任何 JSON 解析之前获取 raw body
- `request.json()` 和 `request.body()` 不能同时调用(body 只能读一次)
沉淀流程(解决问题后)
- 识别沉淀时机 — 刚解决了一个耗时 >15 分钟的问题、做了一个非显而易见的技术决策、发现了一个文档未记录的坑
- 选择分类:
patterns/— 可复用的模式(如「用 X 做 Y 的标准方式」)gotchas/— 踩坑记录(如「X 在 Y 条件下会失败」)decisions/— 决策记录(如「选 X 而非 Y,因为...」)
- 撰写 learning — 按上述文件格式写入
.learnings/<category>/<slug>.md - 更新索引 — 在
.learnings/README.md中追加条目
检索流程(新 session 开始时)
- 自动扫描 — 检查当前项目是否有
.learnings/目录 - 关键词匹配 — 根据当前任务的技术栈、库名、问题关键词搜索相关 learnings
- 呈现相关经验 — 将匹配的 learnings 摘要展示给 agent,作为上下文
# 搜索相关 learnings
grep -rl "stripe" .learnings/
grep -rl "webhook" .learnings/
# 按 tag 搜索(在 frontmatter 中)
grep -rl "tags:.*stripe" .learnings/
索引文件格式
.learnings/README.md 作为索引:
# Project Learnings
## Patterns
- [组件懒加载标准方式](patterns/lazy-loading.md) — React, performance
## Gotchas
- [Webhook 验证必须用 raw body](gotchas/stripe-webhook-raw-body.md) — stripe, webhook, python
## Decisions
- [选 FastAPI 而非 Flask](decisions/fastapi-over-flask.md) — python, web, framework
与其他 skill 的关系
- 与
get-api-docs互补:chub annotation 解决 API 文档补丁,本 skill 解决项目级经验沉淀 - 与
project-workflows互补:可作为统一工作流一次非平凡推进后的收尾步骤 - 与
tech-preferences互补:decisions 分类中的选型决策可以反哺 tech-preferences 的偏好基线
More from zrr1999/skills
unix-software-design
适用于软件设计、架构拆分、边界划分、接口规划、复杂度控制等场景。只要任务核心是“怎么把系统设计得更简单、更透明、更可组合”,就应参考。
33tech-preferences
适用于技术选型、架构规划、工具推荐、重构方向判断、开新坑定栈等场景。只要任务里出现“该选什么”“什么更适合我”“要不要换工具/框架”这类问题,就应先使用。
23modern-stack
个人现代化技术栈说明。在进行任何规划或实现功能、搭建项目脚手架、写示例代码或 CI/自动化配置等任务时,优先按照这里提供的内容来思考和生成方案。
13agent-cli-toolkit
终端取证与 CLI 自动化优先:用 rg/fd、bat、sd、delta/difft、http/jq、fzf、hyperfine、dust/duf/procs/btm、gh/gh-llm、x/vp/bun/uv;多窗格/命名会话/长时并行或 layout 用 zellij。应在用户或任务出现「终端/命令行/shell/CLI」「在机器上跑/验证」「搜仓库/找文件」「看 diff 或 JSON」「查 PR/Issue/GitHub」「磁盘/进程/性能对比」「并行跑多个服务或测试」「tmux 式多会话」或 agent 需用上述工具链而非仅靠编辑器时加载。
12maintenance-pass
适用于“维护老坑”“接着做下去”“修一下这个 repo”“挑下一步最值得做的点”“这个项目有点乱先帮我收一收”这类任务。只要重点是基于现状继续向前,而不是从零设计,就应使用。
7modern-python
用现代 Python 工具链(uv、ruff、ty)初始化或改造项目:生成/调整 pyproject.toml、本地检查命令、预提交与 CI 模板;按项目最低版本(默认 >=3.12,尽量用最新稳定小版本)从 3.12 起叠读各版 What's New 以利用新特性。应在「新建 Python 项目」「写独立脚本要可维护」「统一 lint/format/类型检查」或用户提到 uv/ruff/ty/Python 工程化时加载;与 tech-preferences 的 Python 基线一致,本 skill 负责落地步骤与文件内容。
6