dev-mem · AI 编程经验知识库

> 当前版本：v2.6

> 本 Skill 的职责：被触发时，从对话上下文自动判断意图，路由到正确工作流，执行知识库读写操作。「自动」意味着被触发时从上下文中提取，不是后台常驻进程。

知识库文件

文件名：dev-mem.md，首次写入自动创建，无需手动操作。

路径规则：

> 📌 路径提醒规则：首次创建时高亮告知路径；Skill 升级后首次触发时告知路径；其他情况静默。

触发与意图路由

@emem 强制触发（优先级最高）

消息中出现 @emem → 立即调用本 Skill → 按下表理解用户意图路由：

> 关键区分：用户说「@emem 我要做个登录功能」→ 工作流B（预检）；说「@emem 登录功能搞定了」→ 工作流A（录入）

自然语言触发（无 @emem）

被动触发：上下文监测

仅在当前消息包含录入触发词或 @emem 时，顺带检查上下文是否有已解决但未存档的问题：

> 话题切换信号：用户开始讨论与上一个问题完全不同的内容（如从「Redis连接」切换到「写个接口」），或发出新指令（「帮我改一下这里」「再看看这个文件」），视为话题切换。

轻提格式（末尾型）：

---
💡 上面「{问题关键词}」的解法要存入知识库吗？说「存」就行

话题切换提示格式（插入新话题回复第一句之前，一行，不占独立段落）：

💾 「{上一问题关键词}」已解决，顺手存一下？[说「存」] [说「跳过」忽略]

用户说「存」→ 立即提炼存入，然后继续回答新话题；说「跳过」或忽略 → 静默，不重复提。

> ⚠️ 频次控制：话题切换提示 + 末尾轻提合计，每次会话最多 2 次，超出后静默。

锚点模式（「mark」「标记一下」）

用户随时说「mark」→ 静默记录当前轮次的问题摘要，不打断对话流程：

Step 1：提取当前轮次关键信息（问题关键词 + 当前状态：已解决/进行中）

Step 2：在会话内存中追加一条锚点记录：

[锚点 #{N}] {问题关键词} | {状态} | 第{轮次}轮

Step 3：仅回复一行确认，不展开：

📌 已标记「{问题关键词}」，复盘时优先整理

锚点用途：工作流G复盘时，优先按锚点列表整理，再补扫未标记内容——有锚点时复盘质量显著提升，尤其是长会话中早期内容即将滚出窗口时。

> 💡 最佳实践：每当某个子问题解决时说一句「mark」，复盘时 AI 会优先整理这些节点，不会遗漏。

工作流A：即时录入

Step 0：判断录入模式

Step 1：提取 6 维度字段

从当前消息 + 对话上下文自动提取（见 references/templates.md，无需用户重新描述）：

Step 1.5：自动填充项目名

写入前按以下优先级确定 项目 字段，无需用户开口：

> ⚠️ 重要限制：目录名推断仅适用于知识库在项目根目录的场景（IDE/CodeBuddy/Cursor）。

> Knot 平台知识库在工作区根目录（如 /data/workspace），不应将 workspace 作为项目名，此时按优先级4处理，省略项目字段。

Step 2：写入知识库（执行细节见 references/knowledge-base-guide.md）

1. 读取知识库确认分类序号，生成 ID：EXP-{分类}-{YYYYMM}-{NNN}
2. 找到对应分类区块，在末尾追加条目
3. 更新统计概览对应行（条数+1，更新日期）
4. 更新文件头（最后更新日期、总条目数）

> 分类判断规则见 references/categories.md，优先级：PROMPT > CODE > API > ENV > PKG > DEPLOY > DESIGN

Step 3：告知用户

✅ 已存入 → EXP-{分类}-{YYYYMM}-{NNN}「{经验标题}」
🧠 知识库：{总条目数} 条经验 | 📄 dev-mem.md

> 若对话轮次 ≤ 2 或上下文描述较简短，6 维度中部分字段可能标了 ?（如根本原因不明确）。如需补全，说「完善一下刚存的那条」即可。

> 低置信标注（仅在异常时出现）：当上下文信息不完整（如只看到结论未看到完整排查过程），在 Step 3 末尾追加一行：

> ⚠️ 上下文不完整，以下字段基于推断，建议核对：{字段名列表}

> 高置信时不显示任何置信度信息，避免多余噪音。

工作流A · 补全模式（「完善一下刚存的那条」）

触发：用户说「完善一下」「补一下刚存的」「刚存的那条加上...」等。

Step 1：确认目标条目——默认为本次会话最近写入的条目 ID；若无法确认，引导用户两种方式指定：

• 直接说 ID：「EXP-CODE-202604-003」
• 说关键词：「上周那条 Redis 连接超时的」→ 先执行工作流C检索找到条目，再进入补全流程

Step 2：读取该条目当前内容，列出所有标 ? 或留空的字段：

📝 EXP-XXX「标题」有以下字段待补全：
- 根本原因：?
- 排查链路：（空）

你可以直接描述，我来填入。

Step 3：用户补充描述后，AI 提炼并更新对应字段，覆盖写入知识库，告知结果：

✅ 已更新 → EXP-XXX「标题」（补全了 N 个字段）

问题链提炼模式

Step 1：扫描完整解决过程，识别每个「问题节点」和「解决节点」，标记无效尝试。

Step 2：对每个问题节点，按 6 维度提炼。

Step 3：生成预览供确认：

📋 解决过程提炼（共 N 个问题）

① [ENV] 「标题」
   现象 / 根本原因 / 修复方案 / 教训（一行摘要）

⚠️ 曾尝试但无效：{描述}

---
全部存入？（说「确认」，或「去掉第X条」）

Step 4：用户确认后批量写入，每条独立 ID。

诊断树模式

适用于同一表象可能由多个根因引发（多因一果）。

Step 1：提取表象描述（一句话）

Step 2：整理所有可能根因，每个根因对应快速验证方式 + 解法

Step 3：按命中频率/排查优先级排序，生成预览：

🌳 诊断树预览

表象：{描述}

| 优先级 | 可能原因 | 快速验证 | 解法 |
|---|---|---|---|
| 1 | ... | ... | ... |

存入诊断树？（说「确认」）

> 💡 关于优先级：初始优先级由你来定（上面表格里从高到低排就行）。每次命中某个原因后会自动上移排序，积累多次后会越来越反映实际频率——首次存入效果有限，多用才会准。

Step 4：写入知识库，ID 前缀 EXP-DT-{YYYYMM}-{序号}

Step 5：检索命中诊断树时，输出完整排查路径表，询问「这次是哪个原因？」，确认后追加命中记录并将该原因上移排序。

工作流B：新功能预检

触发判断：@emem 消息中含「要做/准备做/打算/开始做/我想实现」等前置意图词。

> ⚠️ 触发限制：预检仅在 @emem + 前置意图词时触发。纯自然语言说「我要做个登录功能」不触发预检（因为无 @emem 无法区分是随口一说还是真正需要预检）。引导用户习惯：做新功能前加 @emem 前缀可获得历史坑提示。

Step 1：提取需求关键词（技术栈 + 功能类型 + 集成点）

Step 2：模糊匹配检索知识库，标注相关度：

• ✅ 高度匹配：技术栈 AND 功能类型同时命中
• ⚠️ 场景相近：功能相同但技术栈不同，或反之
• 🔍 部分相关：只有某个技术点/风险点相似

Step 3：根据命中数量分三档处理：

> ⚠️ 预检能力说明：预检精度取决于知识库积累量，条目越多命中越准；知识库较少时可能漏匹配或无命中，不代表没有风险，仅代表暂无历史记录。

📚 发现 N 条相关历史经验，供参考（场景不完全相同，请按需参考）

① ✅ EXP-XXX「标题」→ {一句话：核心风险}
② ⚠️ EXP-XXX「标题」→ {一句话：场景差异 + 注意点}

---
（下面正常回答需求）

工作流C：检索

精确检索

Step 1：读取知识库；不存在或为空 → 「暂无相关经验记录。这次解决后说『存』，我帮你提炼成结构化条目，下次遇到同类问题直接命中。」

若知识库有内容但未命中当前查询 → 「没找到直接匹配的经验。如果这次你解决了，说『存』记下来，下次就有了。」

Step 2：语义匹配，返回最相关 1-3 条（命中诊断树时输出完整排查路径表）

相关度分级输出：

• 高相关（技术栈 + 问题类型均命中）→ 直接展示完整条目
• 低相关（只有部分技术点匹配）→ 附注说明「相关度较低，场景不完全相同，供参考」，不隐藏但要降级展示
• 无命中 → 「没找到直接匹配的经验。如果这次你解决了，说『存』记下来，下次就有了。」

Step 3：输出：

📚 找到 N 条相关经验

**EXP-XXX · 标题**（{分类} | {日期}）
- 触发场景：...
- 解决方案：...
- 预防措施：...

模糊探测

触发条件：用户说「好像之前遇到过」「依稀记得」，或直接贴报错信息。

Step 1：提取探测线索（技术方向、问题现象、报错关键词）

Step 2：宽松匹配，命中任意线索即纳入候选（上限 5 条）

Step 3：输出候选列表附匹配理由，问「是这几条里的某一条吗？」

Step 4：用户确认后展开完整条目详情

工作流D：今日沉淀

> 与工作流G的区分：工作流D侧重批量提取+存入，适合会话结束时整体沉淀；工作流G侧重结构化复盘分析+自动补全遗漏，适合主动回顾。触发词「整理今天的」→ 工作流D；「帮我复盘」→ 工作流G。

扫描会话上下文 → 生成草稿 → 展示供确认 → 用户说「确认」后批量写入：

> ⚠️ 注意「今日」的实际含义：工作流D扫描的是当前上下文窗口，不是今天所有会话。跨会话早期对话内容无法获取。最佳实践是每次会话结束前各自沉淀，而不是一天结束后再做汇总。

📝 今日沉淀草稿（共 N 条）
⚠️ 扫描范围：当前上下文窗口（跨会话内容无法获取）

① [CODE] 「标题」  核心内容一句话摘要
② [PROMPT] 「标题」  核心内容一句话摘要

全部存入？（说「确认」或「去掉第X条」）

工作流G：会话复盘

> ⚠️ 只能扫描当前上下文窗口。长会话旧内容滚出后无法获取，这是平台机制限制。最可靠方式：问题解决后立即说「存」。

> 与工作流D的区分：工作流G是主动复盘，会做结构化分析、识别遗漏、自动补全——不是简单列清单，而是真正检查有没有漏掉的。

Step 1：扫描当前上下文——优先读取本次会话的锚点记录（用户说过「mark」的节点），再补扫未标记内容

> 有锚点时：优先按锚点整理，补扫作为兜底

> 无锚点时：全量扫描，准确率取决于上下文窗口完整度

Step 2：识别所有问题事件（报错/多轮调试/「搞定了」等）+ 实现记录（新增功能、值得复用的设计）

Step 3：对每个问题事件按 6 维度提炼，过滤无沉淀价值内容

Step 4：主动核对已存档条目——读取知识库，通过以下方式判断「已存」：

• 知识库中有条目的录入时间与本会话日期相同，且问题描述与当前会话问题高度吻合（技术栈+现象双匹配）
• 仅满足其一不算「已存」——避免把无关的同类历史条目误判为已归档

判断结果：

• 已存的：标注「已归档 ✅」，跳过
• 未存的：自动纳入复盘草稿，不等用户提示

Step 5：生成复盘草稿：

📋 本次会话复盘

【实现记录】
· {完成的功能/改动}

【问题经验】（共 N 条）
① [ENV] 「标题」✅ 已归档（EXP-XXX）
② [CODE] 「标题」📌 已标记 · ⚠️ 未存档 → 已纳入草稿
③ [API] 「标题」⚠️ 未存档 → 已纳入草稿

【自动补全】（发现 N 条遗漏未存）
① [CODE] 「标题」📌（mark过）
   现象 / 根本原因 / 修复方案 / 教训
② [API] 「标题」⚠️（上下文不完整，根本原因基于推断，建议核对）
   现象 / 根本原因? / 修复方案 / 教训

【跳过】
· {通用基础知识，跳过原因}

---
说「全存」批量写入遗漏条目，或「存第1条」单独存入

> 如果所有问题均已存档，输出：「✅ 本次会话所有经验已全部归档，无遗漏。」

工作流E：统计

两种模式：

• 无项目名 → 全库统计
• 有项目名（如「查 proj-cloud 的统计」）→ 项目维度统计

项目维度统计

仅统计含 项目：{项目名} 字段且值匹配的条目，输出格式见 references/knowledge-base-guide.md。

执行前必须告知用户以下限制（一行，不可省略）：

⚠️ 项目统计仅覆盖录入时填写了「项目」字段的条目。早期录入的条目若未填项目名，不会出现在统计中。

项目名匹配规则：大小写不敏感，支持部分匹配（如「cloud」可匹配「proj-cloud」）。

无匹配条目时：告知用户「暂无 {项目名} 的条目，可能是历史条目未填项目字段」，并提示可用工作流I重整时补填。

全库统计输出

📊 dev-mem 知识库统计

| 分类 | 条数 | 最近录入 |
|------|------|---------|
| 🤖 PROMPT | N | YYYY-MM-DD |
| 💻 CODE   | N | YYYY-MM-DD |
| 🔧 ENV    | N | YYYY-MM-DD |
| 🔗 API    | N | YYYY-MM-DD |
| 📦 PKG    | N | YYYY-MM-DD |
| 🚀 DEPLOY | N | YYYY-MM-DD |
| 🎯 DESIGN | N | YYYY-MM-DD |
| 🌳 诊断树 DT | N | YYYY-MM-DD |

合计：N 条 | 最后更新：YYYY-MM-DD
📁 dev-mem.md

工作流F：最近记录

> ⚠️ 说明：「最近 5 条」是按录入时间倒序，不是按「最近解决的问题」排序。如果你刚做了一次今日沉淀批量写入，最近几条会全是那次的内容。若想查特定问题，说「查 XXX」用检索更准。

📋 最近 5 条经验（按录入时间倒序）

① EXP-CODE-202604-003「标题」（2026-04-03）
② EXP-ENV-202604-002「标题」（2026-04-02）
...

共 N 条 | 说「查 XXX」可以检索具体内容

工作流H：版本查询

输出当前版本号 + 更新日志（见 references/changelog.md），并引导升级：

📦 dev-mem 当前版本：v2.4

（更新日志内容来自 references/changelog.md）

🔄 升级方式：在 CodeBuddy / Cursor 的 Skill 管理面板中重新导入最新 zip。
   升级后知识库文件完整保留，数据不丢失。
📁 知识库路径：{实际路径}/dev-mem.md

工作流I：知识库重整

适用场景：手动编辑后格式混乱、旧版迁移、统计数字错误。

Step 1：诊断，扫描以下问题并输出报告：

🔍 知识库诊断报告

实际条目数：{N} 条
发现问题：
① 文件头显示 {X} 条，实际 {N} 条 → 需修正
② ...

执行修复？（说「修复」）

Step 2：修复（用户确认后执行）

必修：补全文件头、补全缺失分类区块、修正统计数字、补全条目末尾分隔线、纠正条目错放分类。

可选（需用户说「顺便升级格式」才执行）：旧版格式条目升级为 6 维度模板。

可选（需用户说「顺便补填项目名」才执行）：批量补填项目字段——扫描所有缺少 项目 字段的条目，按知识库目录名推断项目名（遵循 Step 1.5 优先级规则），一次性展示拟填清单供确认：

📝 发现 N 条条目缺少项目字段，拟补填为「{项目名}」：
① EXP-XXX「标题」
② EXP-XXX「标题」
...
确认填入？（说「确认」，或「跳过」）

确认后批量写入，告知补填条数。

Step 3：输出修复结果，说明修了哪些项。

> ⚠️ 只修格式，不改条目内容；涉及大范围结构调整时提醒用户先备份。

工作流J：备份

触发：「@emem 备份」或「备份知识库」

执行步骤和输出格式见 references/knowledge-base-guide.md（备份规范章节）。

首次使用引导

知识库不存在，或用户问「怎么用」时：

👋 我是 dev-mem，帮你把每次踩坑变成永久资产

两件事就够了：
  · 问题解决后说「存」→ 我帮你记下来
  · 写新功能前说「@emem 我要做 XXX」→ 我提前告诉你历史有没有坑
    （加「我要做」三个字触发预检，光说 @emem 我会问你想干嘛）

长会话时随手说「mark」→ 我静默标记当前节点，复盘时优先整理标记过的内容，不怕遗漏。

其他场景（检索/整理/统计/复盘）直接自然语言说就行。

📁 知识库文件：dev-mem.md（自动创建在当前项目/工作区根目录）

全局行为规则

1. 静默优先：能自动完成的事不打扰用户，完成后小字告知
2. 分级写入：主动说「记一下/存」→ 直接写入；被动轻提 → 用户回「存」后才写入
3. 分级预检提示：命中 ≥ 2 条插入预检区块；命中 1 条轻提示一行；命中 0 条告知「暂无匹配，积累后更准」
4. 推断优先：能从上下文提取的字段不询问用户
5. 一次提问：需要补充信息时只问一句
6. 增长感知：每次写入显示总条目数
7. 每会话上限：话题切换提示 + 末尾轻提合计，每次会话最多 2 次，超出后静默
8. 即时沉淀优先：问题解决后立即存，不要等到会话末尾
9. 锚点优先：工作流G复盘时先读锚点再补扫，有锚点时质量更高；鼓励用户养成「mark」习惯
10. 低置信仅异常提示：正常录入不显示置信度；仅在上下文明显不完整时才追加一行低置信警告，避免全量噪音
11. 有价值内容判断标准：以下内容均有沉淀价值，不局限于「出错/踩坑」：
• 约束/前提：版本要求、平台限制、使用前提、配额/权限约束
• 结论：关于某技术/接口/工具的明确结论（即使没有踩坑过程）
• 注意事项：使用时容易忽略的细节、副作用、兼容性问题
• 提示词习惯：有效的 Prompt 写法、AI 调优技巧
• 无报错的正向经验：某个方案/工具/流程「就是这样用的」，对未来有参考价值
• 无效路径：尝试过但行不通的方案（避免下次重复浪费时间）

References 索引

常见陷阱（速查）

> 完整版见 references/pitfalls.md

1. 判断一的误触：被动轻提只在当前消息触发了 @emem 或录入词时才检查上下文——不要在每次普通对话结尾都跑这个逻辑
2. 工作流B路由错误：区分「描述准备做的需求（预检）」vs「描述已有问题（录入）」，判断依据是有无前置意图词
3. 诊断树命中完整更新：命中后必须执行全部 5 步：次数+1 → 冒泡上移 → 追加命中记录 → 覆盖写入 → 更新文件头。验证方式：写入后重新读取，确认顺序和记录均已更新
4. 会话末尾复盘遗漏：早期内容可能已滚出上下文窗口，工作流G扫描前必须说明这一限制
5. 多平台路径差异：Knot 平台路径是工作区根目录；Claude Code 无项目时是 ~/.dev-mem/；不要硬编码路径