save-solution

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. 从本次笔记主题提炼 1-3 个核心关键词（如 "SSH Mac"、"子代理 并行"）
2. 使用 lark-drive skill 的 +list 命令搜索飞书云空间中的 Inbox 文件夹，匹配相近标题的文档
3. 对命中的候选文档，用 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 + 双子核查，平衡效率与正确性

操作方式：

1. 使用 lark-doc skill 读取当天日笔记（若不存在则新建）
2. 找到 # 记录 区块
3. 先检查该区块是否已存在该笔记标题的链接（只比对链接本身，忽略后面的摘要）——若已存在，跳过本步
4. 未存在时，在该区块末尾追加一行：- [笔记标题](链接) — <摘要>
5. 如果日笔记不存在或没有 # 记录 区块，在文档末尾追加 # 记录 节和引用行

注：即使本次走的是"更新已有文档"路径，日笔记也要补一条引用（方便追溯这一天补充了哪些内容），去重逻辑同上。

Step 5：确认完成

告诉用户：

• 本次判定为哪一类笔记（A 问题解决 / B 方法洞察）及理由一句话
• 本次是新建还是追加到已有文档（若追加，说明追加到哪个文档）
• 飞书文档链接
• 日笔记引用状态（新增 / 已存在未重复追加）
• 简要预览本次写入的核心内容（2-3 句话）