| name | save-solution |
| description | 将当前对话中的问题解决过程或工作方式洞察总结为结构化笔记，保存到 Obsidian 知识库。两种触发场景：(1) 问题解决型——用户说"总结一下""保存这个方案""记录一下这个问题""save solution""存到知识库"，或对话中包含问题解决过程；(2) 方法/洞察型——用户说"这个做法不错存一下""发现 X 比 Y 好""记下这个思路""以后都这么做""存一下这个经验"，或对话中出现"用了子代理效果更好""先读 XX 再动手会更快"之类的效率发现。即使用户只说"存一下""记一下"，也应触发。 |
Save Solution
将 code agent 对话中沉淀下来的知识提炼为可检索的笔记，存入飞书知识库。支持两类笔记：
- A. 问题解决型：遇到具体报错/卡点后，走完"问题 → 解决"流程的经验。
- B. 方法/洞察型：日常工作中发现的更高效做法、工作模式、工具使用心得，不一定是"解决某个故障"。
为什么需要这个 skill
用户经常借助 code agent（Claude Code、Codex 等）工作，对话中既会解决问题，也会意外发现"原来这样做更好"。对话结束后这些经验容易丢失。
这个 skill 把两类知识都沉淀为结构化笔记，让经验可复用、可检索。
工作流程
Step 0：前置判断——是否值得存
在分流之前，先自检本次对话是否真的有可沉淀的内容。三类情况直接停止，不进入后续流程：
- 纯闲聊、纯探索，没有可复现的操作或明确收敛
- 问题没解决、也没找到新方法，只是中途搁置
- 对话里既没有"问题 → 解决"的路径，也没有可对比的两种做法
如果命中上述任一，直接回复用户："这次对话没有值得沉淀的内容（原因：xxx），暂不生成笔记"，结束流程。不要为了响应"存一下"这句话而硬编伪笔记。
Step 1：分流——判断笔记类型
先判断本次对话属于 A 还是 B，这决定后续走哪套模板。
| 类型 | 识别信号 | 笔记定位 |
|---|
| A. 问题解决型 | 对话围绕一个具体报错/卡点；有"不行 → 报错 → 换方法 → 成功"的收敛路径；最终产出是"怎么修好某个东西" | 可复现的解决方案 |
| B. 方法/洞察型 | 没有明确故障；在日常任务中注意到某种做法更好；出现"比之前快""原来这样更省事""以后都这么做""这个思路不错"之类信号 | 可迁移的工作方式 |
判断规则：
- 两类信号都有时，看重心——如果"解决了什么"是主线，选 A；如果"发现了什么做法"是主线，选 B。
- 纯粹歧义时默认 A。
- 同一次对话通常只产出一类笔记。若用户明确要求两类都存，分别生成两个文件。
Step 2A：问题解决型——判断复杂度并提取信息
先判断简单还是复杂问题，这决定模板：
| 信号 | 说明 |
|---|
| 尝试了多个方案才成功 | 对话中出现了"不行""报错""换个方法"等反复 |
| 涉及多个系统/工具的交互 | 问题横跨多个组件，不是单点修复 |
| 需要先理解概念才能解决 | 根因涉及对某个原理/机制的认知空白 |
| 对话轮数多、中间有明显弯路 | 花了较长时间才收敛到最终方案 |
有任意一条信号，视为复杂问题，使用扩展模板。
提取原则：
- 简单问题聚焦最终方案，弯路不记
- 复杂问题的弯路和失败尝试有教训价值，单独记录
- 代码片段只保留关键部分，不要整段复制
- 用简洁的中文书写，技术术语保留英文原文（如 SSH、API、Docker）
Step 2B：方法/洞察型——提取洞察与对比
提取原则：
- 抓住"新做法比原做法好在哪"这一核心
- 必须有可对比的两种（或多种）做法，没有对比的"感想"不值得存
- 写清适用边界——这个洞察在什么情况下成立，什么情况下别用
- 不追求完整故事，只留可迁移的方法论
Step 3：生成或更新笔记文档
文件名：用一个简短精炼的关键词短语命名，能让人一眼看出是什么。
- A 类命名（名词为主）：
SSH 连接 Mac 配置、Tauri 签名密钥生成、MATLAB 编译 Python 调用
- B 类命名（动作/方法为主）：
并行子代理加速大范围搜索、先读 CLAUDE.md 再动手减少返工、用 Plan 模式对齐复杂改动
- 避免：过长的句子、日期前缀（飞书文档有创建时间元数据）、模糊的名字如
问题记录、一些心得
默认保存位置：飞书云空间 Inbox 文件夹。路径：https://my.feishu.cn/drive/folder/Fm10fJpXrlTs9QdxhdbcuQrmncs
Step 3.1：先查重，再决定新建 / 更新
在落盘之前，必须先扫一遍知识库，避免产生近义重复笔记：
- 从本次笔记主题提炼 1-3 个核心关键词（如 "SSH Mac"、"子代理 并行"）
- 使用
lark-drive skill 的 +list 命令搜索飞书云空间中的 Inbox 文件夹，匹配相近标题的文档
- 对命中的候选文档，用
lark-doc skill 的 +read 命令打开看内容是否确实是同一主题
判定与动作：
| 情况 | 动作 |
|---|
| 没有命中同主题文档 | 在 Inbox 中新建飞书文档 |
| 命中一个明确同主题文档 | 更新已有文档：在文档末尾追加 ## 补充 <YYYY-MM-DD> 节；不新建文档 |
| 命中多个或不确定是否同主题 | 停下来问用户："找到可能相关的已有文档 X / Y，是追加到其中某一个，还是新建？" |
追加的内容形态要自适应：
- A 类：若新信息是对原方案的修正/补充，只写修正点；若是同问题的新场景，补一段场景说明 + 关键步骤
- B 类：若对原洞察的边界有新认识，写进"补充"节；避免重复抄原文
Step 3.2：写入文档
A 类 · 简单问题模板（四区块）
# 问题描述
<用 1-3 句话简明扼要地描述遇到了什么问题>
# 环境与上下文
- <项目/工具/语言/OS 等，用列表形式>
# 解决方案
<关键步骤，用有序列表或代码块>
# 根因分析
<为什么会出现这个问题，1-2 句话>
A 类 · 复杂问题模板（六区块）
# 问题描述
<比简单问题更详细——描述问题的表现、影响范围、最初的错误方向>
# 环境与上下文
- <项目/工具/语言/OS 等，用列表形式>
# 踩过的坑
- **方案 A**：XXX → 失败原因（为什么行不通）
- **方案 B**：XXX → 失败原因
# 关键概念
- <解决这个问题需要理解的核心知识点或原理，1-3 条>
# 解决方案
<最终有效的关键步骤，可以比简单问题更详细>
# 根因分析
<复杂问题的根因往往更深——说清楚认知盲点在哪，下次如何更早识别>
B 类 · 方法/洞察模板（四区块）
# 洞察
<1-2 句话：发现了什么更好的做法 / 哪种方式更有效>
# 触发场景
<是在做什么任务时注意到的，为什么会做对比或为什么想到换方式>
# 对比与收益
- **原做法**：…… → 问题 / 成本（慢、返工多、token 高、结果散等）
- **新做法**：…… → 收益（速度、质量、准确度、可维护性等）
<如有第三种做法或更细的分项，继续列>
# 适用条件与边界
- 适用：<什么场景下值得这么做>
- 不适用 / 注意：<什么时候别用，或代价是什么>
内容要求（两类通用）：
- 每个区块都要有实质内容，不要留空或写占位符
- 涉及命令或代码，用 code block 包裹并标注语言
- A 类简单问题控制在 30 行内；A 类复杂问题与 B 类不限行数，但只写有价值的内容，不凑字数
- B 类必须有"对比"——只有单一做法、没有参照物的，不要存
Step 4：在日笔记中记录引用
日笔记位置：飞书知识空间 note2026 中，路径格式为 <年>/Daily/<月>月/<年>-<月>-<日>
例如 2026 年 4 月 12 日 → note2026/2026/Daily/4月/2026-04-12
注意月份不补零：1月、2月 ... 12月。
引用格式：- [笔记标题](飞书文档链接) — <一句话摘要>
摘要生成规则（≤25 字，从本次写入的笔记正文里抽取，不新编）：
- A 类：取"问题描述"首句的核心表述，去掉修饰词
- B 类：取"洞察"首句
- 更新已有文档时：摘要用本次"补充"节的要点，不用原文开头
示例：
- [SSH 连接 Mac 配置](https://my.feishu.cn/docx/xxx) — 公司网络下 ControlMaster 残留连接导致超时
- [并行子代理加速大范围搜索](https://my.feishu.cn/docx/yyy) — 主 agent + 双子核查，平衡效率与正确性
操作方式：
- 使用
lark-doc skill 读取当天日笔记（若不存在则新建）
- 找到
# 记录 区块
- 先检查该区块是否已存在该笔记标题的链接（只比对链接本身，忽略后面的摘要）——若已存在，跳过本步
- 未存在时，在该区块末尾追加一行：
- [笔记标题](链接) — <摘要>
- 如果日笔记不存在或没有
# 记录 区块，在文档末尾追加 # 记录 节和引用行
注：即使本次走的是"更新已有文档"路径，日笔记也要补一条引用（方便追溯这一天补充了哪些内容），去重逻辑同上。
Step 5：确认完成
告诉用户：
- 本次判定为哪一类笔记（A 问题解决 / B 方法洞察）及理由一句话
- 本次是新建还是追加到已有文档（若追加，说明追加到哪个文档）
- 飞书文档链接
- 日笔记引用状态（新增 / 已存在未重复追加）
- 简要预览本次写入的核心内容（2-3 句话）
