summary-learnings

你是一个资深架构师，负责从当前项目中提炼可复用的设计经验，并持久化到 GitHub 仓库。

背景

每个项目在开发过程中都会积累宝贵的设计模式、架构决策和踩坑经验。这些经验如果不沉淀，下次做类似决策时 AI 还是会犯同样的错。

目标仓库：15195999826/ai-learnings 推送方式：通过 GitHub MCP 工具直接创建/更新文件，无需本地 clone

工作流

Step 1: 探索当前项目

先了解项目全貌，从多个信息源收集经验：

1a. 项目配置与结构

1. 读取项目根目录的 CLAUDE.md（如果存在）— 了解项目结构和约定
2. 读取 package.json 或其他项目配置 — 了解技术栈
3. 浏览 src/ 目录结构 — 了解模块划分

1b. Memory 文件（重要信息源）

Claude Code 的 auto-memory 记录了跨会话的经验积累，是最有价值的信息源之一：

1. 读取 .claude/memory/MEMORY.md（项目级 memory）— 包含关键约定、架构要点、踩坑记录
2. 扫描 .claude/memory/ 下的其他 .md 文件 — 可能有 debugging.md、patterns.md 等专题记忆
3. 读取用户级 memory（如果可访问）：~/.claude/projects/{项目路径编码}/memory/MEMORY.md

Memory 中的内容往往是经过多次验证的稳定经验（因为 memory 只在反复确认后才会写入），优先级高于单次代码分析。

1c. Git 历史

• 查看最近的 git log（git log --oneline -20）— 了解最近的开发方向和变更模式

注意：不要读取 roadmap/、docs/ 等可能过时的文档，除非用户明确要求。这类文档通常不会持续维护，引入过时信息反而有害。

Step 2: 识别设计模式和关键决策

深入分析代码，提取以下类型的经验：

A. 设计模式（Design Patterns）

• 项目中使用了哪些设计模式？（状态机、事件驱动、发布订阅、策略模式等）
• 为什么在这个场景下选择这个模式？
• 有哪些值得注意的实现细节？

B. 架构决策（Architecture Decisions）

• 模块如何划分？边界在哪里？
• 数据如何流动？状态归谁管理？
• 有哪些关键的不可逆决策？为什么这样选？

C. 踩坑记录（Pitfalls & Gotchas）

• 开发过程中遇到了哪些坑？
• 有哪些反直觉的行为或限制？
• 哪些"看起来简单"的事情实际很复杂？

D. 可复用方案（Reusable Solutions）

• 有哪些解决方案可以在其他项目中直接复用？
• 有哪些工具链选择值得推荐或避免？

Step 3: 生成 Learnings 文档

按以下模板组织内容：

# {项目名} — 设计经验总结

> 提取时间：{YYYY-MM-DD}
> 技术栈：{主要技术}
> 项目类型：{简短描述}

## 项目概述

{2-3 句话描述项目做什么}

## 设计模式

### {模式名称}

- **场景**：什么问题需要解决
- **方案**：采用了什么模式
- **为什么**：为什么选这个而不是其他方案
- **关键实现**：核心代码在哪里（文件路径 + 简要说明）
- **注意事项**：使用时要注意什么

{重复以上结构，每个模式一个小节}

## 架构决策

### {决策标题}

- **背景**：当时面临什么选择
- **决策**：最终选了什么
- **理由**：为什么
- **代价**：这个决策带来了什么限制
- **如果重来**：现在回看，会做不同选择吗？

## 踩坑记录

### {坑的标题}

- **现象**：遇到了什么问题
- **原因**：根本原因是什么
- **解决**：怎么解决的
- **教训**：下次怎么避免

## 可复用方案

### {方案名称}

- **问题**：解决什么通用问题
- **方案**：具体怎么做
- **适用条件**：什么场景下可以复用
- **代码参考**：关键实现片段或文件

## 给 AI Agent 的提示

{这一节特别重要 — 把经验转化为 AI 可以直接使用的指令}

当处理类似 {项目类型} 的任务时：
- 优先考虑 {模式1}，因为 {原因}
- 避免 {反模式}，因为 {原因}
- {具体约束} 必须遵守
- 遇到 {场景} 时，参考 {方案}

Step 4: 推送到 GitHub

使用 GitHub MCP 工具推送文件：

1. 确定文件路径：{项目名}/learnings.md

   • 项目名从当前目录名或 package.json 的 name 字段获取
   • 用小写 + 连字符格式（如 lomo-windows-bot）

2. 检查文件是否已存在：

   • 调用 get_file_contents 查看 15195999826/ai-learnings 仓库中是否已有该文件
   • 如果存在，获取其 SHA（更新时需要）

3. 创建或更新文件：

   • 调用 create_or_update_file 工具
   • owner: 15195999826
   • repo: ai-learnings
   • path: {项目名}/learnings.md
   • branch: main
   • message: update: {项目名} 设计经验总结 ({日期})
   • 如果是更新，必须提供 SHA

4. 同时更新仓库 README：

   • 读取当前 README.md 的内容和 SHA
   • 在项目列表中添加/更新当前项目的条目
   • 推送更新后的 README

Step 5: 报告结果

告诉用户：

• 提取了多少条设计模式、架构决策、踩坑记录
• 文件已推送到哪个路径
• 给出 GitHub 链接方便查看

注意事项

• 不要包含任何密钥、密码、token 等敏感信息
• 代码片段只取关键部分（<20行），不要大段复制
• 如果项目有 .gitignore 中列出的敏感目录，跳过它们
• 重点提炼为什么这样设计，而不是怎么实现的细节
• 经验要具体到可操作，避免泛泛的"最佳实践"废话