上个月我把用了三年的个人笔记库做了一次彻底重构。不是换了新笔记软件而是在 Cursor 和 Claude Code 里搭了一套由 50 个 Skill 组成的技能库把我平时最常做的收藏文章、拆书、做卡片、整理 MOC、写周报这些动作全部变成可复用的 AI 技能包。折腾完以后知识管理这件事终于从“人找工具”变成了“工具找人”。这套方案不挑笔记平台也不依赖某个特定的 AI 客户端。核心是一批符合通用技能包规范的 markdown 指令文件外加少量辅助脚本。你只要有一个能加载外部指令的 AI 编程助手就能在半天内把基础框架搭起来。它特别适合被笔记囤积问题困扰、收藏夹里躺着几百篇文章却很少再看、每次写周报都要花一两个小时翻记录的人。我会先讲清楚 Skill 机制和普通 Prompt 到底差在哪再把 50 个 Skill 按采集、整理、提炼、输出、复盘五条流水线完整列给你。然后给出三个可以直接抄的 SKILL.md 模板最后用两条真实链路演示这套系统是怎么从网页剪藏一路跑到周报输出的。1. 整体设计拆解知识管理为什么需要 Skill1.1 知识管理真正的痛点在哪里我先说清楚一个问题知识管理不是“存得越多越好”。很多人用 Notion、Obsidian、印象笔记订阅了一堆 RSS收藏了无数网页最后打开知识库就头疼——文件命名混乱、标签五花八门、相同主题的笔记散落得到处都是。真正要写东西时不是“没有素材”而是“素材太多且找不到”。我也尝试过让 AI 帮我整理用普通提示词让它“总结一下”“提取要点”效果非常不稳定。同一批笔记今天让它整理是一种格式明天换一个模型又是一个风格。更麻烦的是每次都要在对话框里重新描述背景、约束、输出格式聊十分钟可能还理不清。问题不在 AI 能力而在指令太散、太依赖临场发挥。你需要的不是一次高质量的对话而是一套可以被反复调用的稳定流程。知识管理本质上涉及大量固定动作网页正文提取、PDF 解析、卡片笔记生成、标签去重、MOC 整理、周复盘。这些动作都有明确的输入和输出非常适合做成模块化技能。而这恰好是 Skill 机制的主场。1.2 Skill 到底是什么和 Prompt、Agent 有什么本质区别Skill 可以理解成一个“技能包”一个独立的目录里面放一份 SKILL.md 说明文件可能还有辅助脚本和示例资源。AI 工具在运行时会扫描这些目录当用户的问题或当前任务命中 SKILL.md 里描述的触发条件时才把这份技能加载进来。你可以把它想象成给 AI 配了一个岗位手册平时不占脑子遇到对应任务才翻开。它和 Prompt、Agent 的区别很直观对比维度PromptSkillAgent触发方式每次手动写场景自动触发独立承担完整任务上下文效率全部塞进对话按需懒加载依赖工具循环调度复用性差复制粘贴结构化、可复用中等维护成本低但散乱中但集中管理高知识管理场景适合度不稳定高过重普通 Prompt 的问题是“一次性的”。Skill 则把指令、触发条件、输出格式、示例全部封装在一起AI 在真正需要时才读取详细内容。这个设计对知识管理特别关键因为知识库文件很多如果所有规则都堆在 system prompt 里上下文会被迅速撑爆。Skill 的懒加载机制保证 AI 只处理当前任务需要的技能说明既省 token 又提高准确率。1.3 选型逻辑为什么是 Skill 而不是自己写死流程我做过一轮对比试验最后选了 Skill 体系原因有三层。第一知识管理的流程是“流水线式”的比如网页文章进来后要清洗、摘要、切片、归档每个环节都是边界清晰的转化型任务用 Agent 做太重普通 Prompt 做又不稳Skill 正好卡在中间。第二Skill 是纯文本加脚本可以放进 Git 管理我改了哪个技能、哪天改的都有记录。第三主流 AI 编程工具都在往这个方向靠拢同一份 SKILL.md 经过少量调整就能在不同工具间迁移不会像以前那样换个工具就一切重来。更重要的是Skill 能跟知识管理的“动作规范”绑定。我给自己定了五条流水线采集、整理、提炼、输出、复盘。每条流水线里有大量重复动作我就把这些动作逐个固化成 Skill。50 个听起来多但很多只是同一个模板的不同变体真正花时间的是梳理自己的知识管理规范而不是写代码。2. 50 个 Skill 全景清单按场景分类的核心设计2.1 采集类 10 个让信息自动流入系统采集类 Skill 解决的是“东西进来时怎么标准化”。很多人剪藏网页就是原样丢进收藏夹结果标题乱、正文带广告、没有摘要、没有元数据。我给采集类定了一条铁律任何内容进来必须变成可检索、可归档的标准格式否则就不收。Skill 名称触发场景核心输出web-clipper遇到想收藏的网页时正文去噪、摘要、标签、元数据pdf-digest处理 PDF 论文或报告结构化阅读笔记、关键论点audio-transcript访谈、会议录音、播客转写文字稿并按主题分段image-ocr截图或扫描图片可检索的纯文本、保留版面层级wechat-saver导出微信聊天或收藏主题对话记录、重要信息卡片email-miner处理邮箱导出文件待办提取、重要信息归档rss-merge每天固定时间汇总订阅源当日阅读清单、优先级排序social-thread社交平台长文和讨论串主题档案、观点列表url-batch批量清理浏览器书签去重、补标题、按主题重排meeting-capture会议录音或会议记录粘贴纪要、行动项、责任人这里说一下我踩过的坑采集类是重灾区因为太容易“为了采集而采集”。web-clipper 如果只输出摘要没有和知识库内的文件夹结构、命名规范对接那这个 Skill 等于白做。所以我在设计采集类时统一了输出元数据字段来源、时间、主题、标签、正文路径、摘要路径所有 Skill 都按同一套 schema 输出后面整理类处理起来才不费劲。2.2 整理类 10 个给知识库建立秩序整理类 Skill 是对已有笔记的“治理”。我观察到一个规律知识库越乱越不想打开越不想打开越乱。整理类的作用就是定期把无序状态拉回来。这一层的核心是让目录结构、标签体系、双链关系保持一致。Skill 名称触发场景核心输出folder-audit目录结构混乱时目录治理建议、迁移方案tag-normalizer标签近义、重复时标签合并映射表moc-builder同一主题笔记超过 10 条主题内容地图、双链目录link-enhancer笔记缺乏关联时断链检查、补双链建议dup-finder怀疑笔记重复时相似笔记对比、保留建议rename-batch文件名风格不统一时标准化后的重命名列表meta-filler笔记缺 frontmatter 时自动补齐来源、日期、标签inbox-cleaner收件箱堆积时归类建议、归档动作cold-storage很久没访问的笔记积压冷热数据归档清单bib-fixer文献引用格式混乱时统一格式、补全 DOI 信息整理类里我最看重 dup-finder 和 meta-filler。重复笔记是知识库沉默成本的最大来源两个笔记存了同一段摘录搜索时都出现却不知道该信哪个。dup-finder 的核心逻辑是计算笔记标题、标签、正文前 200 字的相似度输出一个对比表由人决定去留而不是让 AI 直接删除。2.3 提炼类 10 个把资料变成洞察提炼类是整个系统里最能体现 AI 价值的部分。采集解决“有没有”整理解决“乱不乱”提炼解决“懂没懂”。这里的核心假设是任何一篇资料至少要产出一个能独立复用的知识单元否则它就只是占空间的冗余。Skill 名称触发场景核心输出card-maker长文或书籍章节需要拆解原子知识卡片、关联笔记concept-breaker碰到复杂概念时定义、案例、边界、反例essence-bullets需要快速抓住干货时5 条以内的核心要点tl-dr时间紧张时一句话总结、三段速览analogy-gen概念难理解时生活化类比、可视化描述counter-arg需要检验观点时反方观点、潜在漏洞清单keyword-tagger笔记需要检索标签时关键词集合、层级标签建议outline-splitter长文需要分章节时层级大纲、章节标题mind-map准备思维导图时缩进式大纲文本faq-gen资料面向读者交付时常见问题、简明回答提炼类的输出要特别注意“原子性”。一篇文章可以拆出 8 张卡片但卡片之间不能互相依赖。我在设计 card-maker 时让它必须给每张卡片加两个字段核心概念和关联笔记。前者保证这张卡片能独立被检索后者保证它不会成为孤岛。很多知识管理工具的死穴就是卡片之间没有链接一张张孤零零躺在库里等于没提炼。2.4 输出与检索类 10 个让知识变成产出输出是把知识从“存量”变成“流量”的关键。很多人积累了很多笔记但产出全靠死磕。输出类 Skill 的价值在于把笔记改写成博客、生成分享提纲、做学习路径这些动作全部可以在几分钟内完成初稿人只需要做决策和润色。Skill 名称触发场景核心输出blog-rewriter从笔记改写成文章时博客初稿、标题备选talk-outline准备分享或汇报时演讲提纲、时间分配slide-builder需要演示文稿时PPT 页面结构、每页要点newsletter周期性内容输出时电子报排版、内容精选learn-path想系统学习某主题时学习路线图、资源清单quiz-gen检验学习效果时测验题、参考答案search-ai知识库内检索时语义相关结果、摘要translate-polish处理外文资料时翻译、润色、术语统一brief-maker需要快速了解主题时主题简报、关键人物与事件portfolio-gen整理个人项目时项目集摘要、成果列表我建议输出类 Skill 不要一次全建。先把 blog-rewriter 和 weekly-review 建起来这两个使用频率最高。blog-rewriter 会读取一批卡片笔记根据用户指定的受众和发布平台生成带标题的开头段落和全文大纲。它本质上是把提炼类的卡片重新编排成线性文章结构比从零开始写快得多。2.5 项目与复盘类 10 个让知识驱动行动知识管理系统的终点不是“我知道了很多”而是“我做了什么”。所以最后 10 个 Skill 全用来管理行动目标拆解、任务分解、进度检查、周复盘、项目复盘、决策记录。这些 Skill 会把知识库里的笔记、卡片、会议纪要变成下一步行动项。Skill 名称触发场景核心输出okr-splitter设定季度目标时目标、关键结果拆解task-breaker任务太大无从下手时可执行步骤、依赖关系progress-check检查项目进度时进度报告、风险预警weekly-review周末复盘时本周完成、未完成、下周计划retro-run项目结束后做得好、做得差、改进项decision-log做了重要决策时决策背景、选项对比、结论action-extract会议纪要堆叠时行动项清单、负责人prio-ice需求或想法太多时按价值和成本排序habit-score习惯打卡需要复盘时连续天数、趋势分析dashboard-gen需要一页看板时个人核心指标汇总这 10 个里面我最推荐先做 weekly-review。它是我全系统里使用频率最高的 Skill每周日晚固定触发。它会把本周新增的笔记、完成的卡片、写下的日志全部聚合起来输出一份包含“本周完成、本周未完成、关键洞察、下周计划”四个板块的复盘报告。配合 task-breaker还能把下一周的目标自动拆成可执行的任务列表。3. 核心搭建实操目录结构、SKILL.md 与主流工具接入3.1 标准目录结构与 SKILL.md 配置规范50 个 Skill 如果散落各处很快就会失控。我建议统一放在一个“技能库”目录里用 Git 管理结构如下my-knowledge-skills/ ├── README.md ├── skills/ │ ├── card-maker/ │ │ ├── SKILL.md │ │ ├── scripts/ │ │ │ └── split_cards.py │ │ └── reference/ │ │ └── card_example.md │ ├── moc-builder/ │ │ ├── SKILL.md │ │ └── scripts/ │ │ └── cluster_notes.py │ ├── weekly-review/ │ │ └── SKILL.md │ ├── web-clipper/ │ │ └── SKILL.md │ └── ... ├── config/ │ └── global_metadata.yaml └── templates/ └── skill_template.md每个 Skill 至少包含一个 SKILL.md。这个文件是所有工具都能读懂的“岗位说明书”。我用的标准模板是 YAML frontmatter 加正文步骤说明--- name: skill-name description: 一句话说明这个技能做什么 when_to_use: 什么样的用户请求或文件内容会触发它 version: 1.0.0 tags: [知识管理, 提炼] input: format: text/markdown max_length: 20000 output: format: markdown structure: 固定输出结构描述 steps: 1. 第一步做什么 2. 第二步做什么 ---这几个字段里最重要的是 description 和 when_to_use。因为 Skill 能不能被正确触发全靠它们。description 给 AI 一个快速判断这个技能和当前问题是否有关。when_to_use 要写用户真实会说的话比如“帮我摘成卡片”“把这周总结一下”“太长了帮我提炼”。我看到很多人写得很专业却忘了用户的实际口语结果技能永远不触发。3.2 三个核心 Skill 的完整参考实现第一个推荐 card-maker这是知识管理最核心的转化动作。它把一篇长文或书章节拆成原子卡片。完整 SKILL.md 如下--- name: card-maker description: 将长文章、网页正文或书籍章节切成原子知识卡片保留原文出处与上下文链接 when_to_use: 用户说“摘成卡片”“提取知识点”“读完这篇帮我整理笔记”或输入内容超过 5000 字且希望结构化时 version: 1.2.0 tags: [知识管理, 提炼, 卡片笔记] input: format: text/markdown max_length: 30000 output: format: markdown structure: | # 卡片组源标题 源信息来源链接/书籍页码 ## 卡片 1 - 标题一句话概括 - 原文摘要200 字以内 - 核心概念概念1、概念2 - 关联笔记相关已有笔记名 - 原始出处章节/行号 steps: 1. 按 markdown 标题或段落切分出逻辑块 2. 每块提炼一个核心主题合并重复内容 3. 为每张卡片生成独立标题和 frontmatter 建议 4. 检查卡片之间的逻辑关系补关联笔记 ---这个 Skill 我会配合一个脚本使用负责把长文先切成块避免把整篇文章丢给模型处理import re def split_blocks(text: str, max_blocks: int 12): lines text.splitlines() blocks [] current_title 未命名区块 current_lines [] for line in lines: if re.match(r^#{1,3}\s, line): if current_lines: blocks.append({title: current_title, content: \n.join(current_lines)}) current_title line.strip(#).strip() current_lines [] else: current_lines.append(line) if current_lines: blocks.append({title: current_title, content: \n.join(current_lines)}) return blocks[:max_blocks]第二个是 moc-builder负责把散落的笔记变成主题地图。它的 SKILL.md 重点是“聚类”和“双链生成”--- name: moc-builder description: 从同一主题的一组笔记中生成 MOC内容地图自动聚类并生成双链目录 when_to_use: 用户说“帮我建一个 MOC”“把 XX 主题的笔记整理成地图”或知识库内同一标签笔记超过 10 条 version: 1.0.0 tags: [知识管理, 整理, MOC] input: format: markdown source: 本地知识库扫描结果 output: format: markdown structure: | # MOC主题名 ## 概览 这个主题覆盖了哪些方向适合什么人阅读。 ## 子主题 - [[笔记标题 1]] - [[笔记标题 2]] - [[笔记标题 3]] steps: 1. 收集该主题下所有笔记标题和 frontmatter 标签 2. 按关键词聚类成 5-7 个子主题 3. 生成层级结构每个子主题写一句说明 4. 用双链语法输出保证在 Obsidian 中可跳转 ---第三个是 weekly-review这是全系统里使用频率最高的工具。它的输出结构非常固定方便存档和后续任务拆解--- name: weekly-review description: 按周聚合本周完成、未完成、知识输入和下周计划生成一份可归档的复盘报告 when_to_use: 周末或用户说“周复盘”“这周总结”“本周回顾”时 version: 1.3.0 tags: [复盘, 项目管理, 输出] input: format: 任务列表、日记、会议纪要、笔记新增列表 window: 最近 7 天 output: format: markdown structure: | # 2025-Wxx 周复盘 ## 本周完成 ## 本周未完成 ## 关键洞察 ## 下周计划含优先级 steps: 1. 列出本周所有任务完成情况 2. 对比目标找出未完成项和原因 3. 从本周笔记和卡片中提取 2-3 条关键洞察 4. 根据洞察生成下周计划并给出优先级 ---这三个 Skill 放在一起基本就能跑通“采集—整理—提炼—复盘”的闭环。其他 47 个 Skill 都是从这套模板派生出来的把 name、description、when_to_use 和 output.structure 换掉就行。3.3 在 Cursor、Claude Code、OpenCode 中接入不同 AI 工具的 Skill 加载机制略有差异但底层逻辑一致把一个带 SKILL.md 的目录放到约定路径下就行。以我实际用过的几个工具为例Claude Code 原生支持 Skill 机制把 SKILL.md 放到.claude/skills/skill-name/目录下运行时会自动扫描并加载。Cursor 目前更常用的是 Rules 机制可以把 SKILL.md 内容塞进.cursor/rules/下的规则文件里或者直接让 Agent 按指定目录读取技能说明。OpenCode 也提供了 skill 配置能力常见路径是~/.config/opencode/skill/项目内也可以建.skill/目录。实际操作时我习惯在知识库项目根目录建一个skills/目录然后在工具配置里声明加载路径。这样技能库和知识库放在同一个仓库里跟着 Git 走换机器也不怕丢mkdir -p skills/card-maker/scripts # 将 SKILL.md 放入对应目录 # 在知识库项目根目录中配置 Agent 指向这个 skills 目录如果你用的工具还没有原生 Skill 机制还有一个通用做法把 SKILL.md 作为一条长期规则加载到 system prompt 里。但这样会占上下文所以我建议只保留触发频率最高的 5-6 个。真正完整的一套 Skill 目录还是留给支持懒加载的工具用。4. 实操闭环从网页剪藏到周报输出的完整跑通4.1 链路一网页文章 → 知识卡片 → MOC 地图我拿真实场景演示一遍。假设我看到一篇关于 LLM Agent 设计模式的长文想存进 Obsidian 知识库。以前我要手动复制正文、删广告、起标题、打标签、再思考它和已有笔记的关系。现在只需要把正文粘贴给 AI说一句“帮我存一下”。AI 先触发 web-clipper对网页进行清洗输出摘要、标签和元数据。我确认后再触发 card-maker把正文拆成几张原子卡片。输出大概长这样源信息https://example.com/llm-agent-patterns 标题LLM Agent 的四种设计模式 卡片 1 - 标题Agent LLM 规划 工具 记忆 - 原文摘要Agent 系统由四个核心模块组成规划循环负责决定下一步动作。 - 核心概念规划循环、工具调用、记忆单元 - 关联笔记[[Skill 机制原理]] - 原始出处第二章第 12-15 段卡片写回知识库后我再对 AI 说“把 LLM Agent 相关笔记整理成 MOC”。moc-builder 会扫描所有标题带 Agent 的笔记按主题聚类生成一个带双链的内容地图。整个过程从原来的 15 分钟压缩到 1 分钟我只需要在最后确认一下卡片是否准确。这一步解决了“收藏后再也不看”的问题因为进来的时候已经被拆成了原子卡片未来任何一篇笔记想引用它都能直接检索到。4.2 链路二项目杂谈 → 周复盘 → 下周计划第二条链路是每周日跑一次的复盘流程。我把本周新增的笔记路径、任务列表、会议记录统一喂给 AI触发 weekly-review。它会聚合本周完成的事项、没做完的事、以及从笔记里提取的关键洞察。举个例子本周我完成了三个任务搭好 web-clipper、写完卡片模板、处理两份 PDF 论文。读了两篇关于知识库索引的文章开了一次项目会会上决定要梳理标签体系。weekly-review 输出的复盘报告会把这些信息归到四个板块里。接下来我再触发 task-breaker把“梳理标签体系”这个大任务拆成“导出标签列表、识别重复标签、生成合并映射、执行 batch rename”四个步骤分配给下周。这条链路最大的价值是“知识输入和任务输出被连起来了”。以前我的周复盘要翻聊天记录、翻日记、翻任务软件现在只需要给 AI 一个范围它自动把所有散落的信息找出来按固定模板汇总。我只需要判断优先级和取舍不再需要做信息搬运。4.3 调参与协作技巧用了一段时间后我总结出几个让系统更顺手的技巧。第一when_to_use 一定要写用户口语。比如“帮我存一下”“摘卡片”“太长了”这种短句比“对文本进行知识抽取和结构化”触发率高得多。AI 判断触发靠的是语义匹配不是关键词堆砌。第二长文档不要直接丢给模型。超过两三万字的文件先用 scripts 里的脚本切块再逐块处理。Skill 里的脚本不一定每次都要写复杂逻辑有时就是一个正则切分函数但能大幅减少上下文消耗。第三多个 Skill 都可能匹配同一输入时要在 README 里定义职责边界。比如 card-maker 处理长文提炼essence-bullets 处理要点提取两者容易重叠。我通常会在 prompt 里让用户显式指定或者在 Skill 描述里写明互斥条件。第四Skill 目录一定要用 Git 管理。我每个月会清理一次不再使用的 Skill合并语义重叠的把常用角色调优后提交 commit。Skill 也是知识资产不维护就会过期。5. 常见问题与排查技巧实录5.1 六大高频问题与解决思路我在搭建和使用的过程中遇到过不少问题挑六个出现频率最高的列出来现象可能原因解决思路AI 没触发想要的 Skillwhen_to_use 触发词太少补充用户口语说法如“帮我存一下”“摘卡片”输出格式不稳定SKILL.md 里没有输出示例在 output.structure 里放一个真实模板上下文爆掉一次喂了太多文件先用 scripts 分块再逐块处理多个 Skill 重复处理两个技能描述重叠定义职责边界加互斥条件换工具后不生效目录路径或命名不合规范查目标工具的 Skill 文档确认目录名更新模型后结果变化新模型不熟悉旧指令固定模型版本或增加 few-shot 示例最麻烦的是第一个问题。很多时候不是 Skill 写错了而是描述和用户实际表达对不上。比如我很长时间没想明白为什么“帮我整理一下”不会触发 card-maker后来才发现这个请求太模糊模型不知道要拆成卡片还是生成目录。自从我在 when_to_use 里加了“摘成卡片”“提取知识点”这些明确动词后触发率明显上升。5.2 排查顺序速查表当某个 Skill 不按预期工作时我有一套固定排查顺序按步骤来基本能定位问题确认 Skill 目录被工具扫描到。打开工具的调试菜单或手动执行一次技能列表命令看目标技能是否出现在已加载列表里。把输入切到最小。用一个十几行的测试文本加一句最直白的触发指令比如“摘成卡片”排除长文本带来的干扰。检查输出是否遵守 output.structure。如果不遵守多半是示例不够具体补一个完整输出样例。考虑是否有多个 Skill 同时匹配。临时禁用其他技能只留目标技能看行为是否恢复正常。实在不触发把 SKILL.md 的内容直接作为普通 Prompt 塞进对话。如果这样能正常工作说明是加载配置的问题如果也不行说明是技能内容本身的问题。这套排查顺序帮我解决过不少看似诡异的问题。有一次我以为是模型变笨了结果发现是目录名大小写写错工具压根没扫描到那个目录。5.3 最后分享几点使用体会折腾完这套系统之后我最大的感受是知识管理的瓶颈从来不是工具不够多而是每个动作的规范没有被固化下来。Skill 把散落在提示词里的经验变成了可维护的资产也让 AI 从一个“偶尔好用的话痨”变成一个“稳定交付的整理搭子”。50 个 Skill 听起来像一个大工程但它真正的建设节奏是每周三五个不知不觉就攒出来了。我建议第一次动手不要追求一次建完 50 个。先做一个 card-maker拿收藏夹里的旧文章跑一遍。跑通之后你自然会发现下一个值得固化的动作是 moc-builder然后是 web-clipper再然后是 weekly-review。我的经验是第一个 Skill 建完后剩下的会跟着实际使用慢慢长出来。知识管理不是靠囤积而是靠流程。Skill 这套机制恰恰就是把你脑子里的流程搬到 AI 手里的最小可行方案。
用50个Skill打造AI知识管理系统：从采集到复盘的完整方案
上个月我把用了三年的个人笔记库做了一次彻底重构。不是换了新笔记软件而是在 Cursor 和 Claude Code 里搭了一套由 50 个 Skill 组成的技能库把我平时最常做的收藏文章、拆书、做卡片、整理 MOC、写周报这些动作全部变成可复用的 AI 技能包。折腾完以后知识管理这件事终于从“人找工具”变成了“工具找人”。这套方案不挑笔记平台也不依赖某个特定的 AI 客户端。核心是一批符合通用技能包规范的 markdown 指令文件外加少量辅助脚本。你只要有一个能加载外部指令的 AI 编程助手就能在半天内把基础框架搭起来。它特别适合被笔记囤积问题困扰、收藏夹里躺着几百篇文章却很少再看、每次写周报都要花一两个小时翻记录的人。我会先讲清楚 Skill 机制和普通 Prompt 到底差在哪再把 50 个 Skill 按采集、整理、提炼、输出、复盘五条流水线完整列给你。然后给出三个可以直接抄的 SKILL.md 模板最后用两条真实链路演示这套系统是怎么从网页剪藏一路跑到周报输出的。1. 整体设计拆解知识管理为什么需要 Skill1.1 知识管理真正的痛点在哪里我先说清楚一个问题知识管理不是“存得越多越好”。很多人用 Notion、Obsidian、印象笔记订阅了一堆 RSS收藏了无数网页最后打开知识库就头疼——文件命名混乱、标签五花八门、相同主题的笔记散落得到处都是。真正要写东西时不是“没有素材”而是“素材太多且找不到”。我也尝试过让 AI 帮我整理用普通提示词让它“总结一下”“提取要点”效果非常不稳定。同一批笔记今天让它整理是一种格式明天换一个模型又是一个风格。更麻烦的是每次都要在对话框里重新描述背景、约束、输出格式聊十分钟可能还理不清。问题不在 AI 能力而在指令太散、太依赖临场发挥。你需要的不是一次高质量的对话而是一套可以被反复调用的稳定流程。知识管理本质上涉及大量固定动作网页正文提取、PDF 解析、卡片笔记生成、标签去重、MOC 整理、周复盘。这些动作都有明确的输入和输出非常适合做成模块化技能。而这恰好是 Skill 机制的主场。1.2 Skill 到底是什么和 Prompt、Agent 有什么本质区别Skill 可以理解成一个“技能包”一个独立的目录里面放一份 SKILL.md 说明文件可能还有辅助脚本和示例资源。AI 工具在运行时会扫描这些目录当用户的问题或当前任务命中 SKILL.md 里描述的触发条件时才把这份技能加载进来。你可以把它想象成给 AI 配了一个岗位手册平时不占脑子遇到对应任务才翻开。它和 Prompt、Agent 的区别很直观对比维度PromptSkillAgent触发方式每次手动写场景自动触发独立承担完整任务上下文效率全部塞进对话按需懒加载依赖工具循环调度复用性差复制粘贴结构化、可复用中等维护成本低但散乱中但集中管理高知识管理场景适合度不稳定高过重普通 Prompt 的问题是“一次性的”。Skill 则把指令、触发条件、输出格式、示例全部封装在一起AI 在真正需要时才读取详细内容。这个设计对知识管理特别关键因为知识库文件很多如果所有规则都堆在 system prompt 里上下文会被迅速撑爆。Skill 的懒加载机制保证 AI 只处理当前任务需要的技能说明既省 token 又提高准确率。1.3 选型逻辑为什么是 Skill 而不是自己写死流程我做过一轮对比试验最后选了 Skill 体系原因有三层。第一知识管理的流程是“流水线式”的比如网页文章进来后要清洗、摘要、切片、归档每个环节都是边界清晰的转化型任务用 Agent 做太重普通 Prompt 做又不稳Skill 正好卡在中间。第二Skill 是纯文本加脚本可以放进 Git 管理我改了哪个技能、哪天改的都有记录。第三主流 AI 编程工具都在往这个方向靠拢同一份 SKILL.md 经过少量调整就能在不同工具间迁移不会像以前那样换个工具就一切重来。更重要的是Skill 能跟知识管理的“动作规范”绑定。我给自己定了五条流水线采集、整理、提炼、输出、复盘。每条流水线里有大量重复动作我就把这些动作逐个固化成 Skill。50 个听起来多但很多只是同一个模板的不同变体真正花时间的是梳理自己的知识管理规范而不是写代码。2. 50 个 Skill 全景清单按场景分类的核心设计2.1 采集类 10 个让信息自动流入系统采集类 Skill 解决的是“东西进来时怎么标准化”。很多人剪藏网页就是原样丢进收藏夹结果标题乱、正文带广告、没有摘要、没有元数据。我给采集类定了一条铁律任何内容进来必须变成可检索、可归档的标准格式否则就不收。Skill 名称触发场景核心输出web-clipper遇到想收藏的网页时正文去噪、摘要、标签、元数据pdf-digest处理 PDF 论文或报告结构化阅读笔记、关键论点audio-transcript访谈、会议录音、播客转写文字稿并按主题分段image-ocr截图或扫描图片可检索的纯文本、保留版面层级wechat-saver导出微信聊天或收藏主题对话记录、重要信息卡片email-miner处理邮箱导出文件待办提取、重要信息归档rss-merge每天固定时间汇总订阅源当日阅读清单、优先级排序social-thread社交平台长文和讨论串主题档案、观点列表url-batch批量清理浏览器书签去重、补标题、按主题重排meeting-capture会议录音或会议记录粘贴纪要、行动项、责任人这里说一下我踩过的坑采集类是重灾区因为太容易“为了采集而采集”。web-clipper 如果只输出摘要没有和知识库内的文件夹结构、命名规范对接那这个 Skill 等于白做。所以我在设计采集类时统一了输出元数据字段来源、时间、主题、标签、正文路径、摘要路径所有 Skill 都按同一套 schema 输出后面整理类处理起来才不费劲。2.2 整理类 10 个给知识库建立秩序整理类 Skill 是对已有笔记的“治理”。我观察到一个规律知识库越乱越不想打开越不想打开越乱。整理类的作用就是定期把无序状态拉回来。这一层的核心是让目录结构、标签体系、双链关系保持一致。Skill 名称触发场景核心输出folder-audit目录结构混乱时目录治理建议、迁移方案tag-normalizer标签近义、重复时标签合并映射表moc-builder同一主题笔记超过 10 条主题内容地图、双链目录link-enhancer笔记缺乏关联时断链检查、补双链建议dup-finder怀疑笔记重复时相似笔记对比、保留建议rename-batch文件名风格不统一时标准化后的重命名列表meta-filler笔记缺 frontmatter 时自动补齐来源、日期、标签inbox-cleaner收件箱堆积时归类建议、归档动作cold-storage很久没访问的笔记积压冷热数据归档清单bib-fixer文献引用格式混乱时统一格式、补全 DOI 信息整理类里我最看重 dup-finder 和 meta-filler。重复笔记是知识库沉默成本的最大来源两个笔记存了同一段摘录搜索时都出现却不知道该信哪个。dup-finder 的核心逻辑是计算笔记标题、标签、正文前 200 字的相似度输出一个对比表由人决定去留而不是让 AI 直接删除。2.3 提炼类 10 个把资料变成洞察提炼类是整个系统里最能体现 AI 价值的部分。采集解决“有没有”整理解决“乱不乱”提炼解决“懂没懂”。这里的核心假设是任何一篇资料至少要产出一个能独立复用的知识单元否则它就只是占空间的冗余。Skill 名称触发场景核心输出card-maker长文或书籍章节需要拆解原子知识卡片、关联笔记concept-breaker碰到复杂概念时定义、案例、边界、反例essence-bullets需要快速抓住干货时5 条以内的核心要点tl-dr时间紧张时一句话总结、三段速览analogy-gen概念难理解时生活化类比、可视化描述counter-arg需要检验观点时反方观点、潜在漏洞清单keyword-tagger笔记需要检索标签时关键词集合、层级标签建议outline-splitter长文需要分章节时层级大纲、章节标题mind-map准备思维导图时缩进式大纲文本faq-gen资料面向读者交付时常见问题、简明回答提炼类的输出要特别注意“原子性”。一篇文章可以拆出 8 张卡片但卡片之间不能互相依赖。我在设计 card-maker 时让它必须给每张卡片加两个字段核心概念和关联笔记。前者保证这张卡片能独立被检索后者保证它不会成为孤岛。很多知识管理工具的死穴就是卡片之间没有链接一张张孤零零躺在库里等于没提炼。2.4 输出与检索类 10 个让知识变成产出输出是把知识从“存量”变成“流量”的关键。很多人积累了很多笔记但产出全靠死磕。输出类 Skill 的价值在于把笔记改写成博客、生成分享提纲、做学习路径这些动作全部可以在几分钟内完成初稿人只需要做决策和润色。Skill 名称触发场景核心输出blog-rewriter从笔记改写成文章时博客初稿、标题备选talk-outline准备分享或汇报时演讲提纲、时间分配slide-builder需要演示文稿时PPT 页面结构、每页要点newsletter周期性内容输出时电子报排版、内容精选learn-path想系统学习某主题时学习路线图、资源清单quiz-gen检验学习效果时测验题、参考答案search-ai知识库内检索时语义相关结果、摘要translate-polish处理外文资料时翻译、润色、术语统一brief-maker需要快速了解主题时主题简报、关键人物与事件portfolio-gen整理个人项目时项目集摘要、成果列表我建议输出类 Skill 不要一次全建。先把 blog-rewriter 和 weekly-review 建起来这两个使用频率最高。blog-rewriter 会读取一批卡片笔记根据用户指定的受众和发布平台生成带标题的开头段落和全文大纲。它本质上是把提炼类的卡片重新编排成线性文章结构比从零开始写快得多。2.5 项目与复盘类 10 个让知识驱动行动知识管理系统的终点不是“我知道了很多”而是“我做了什么”。所以最后 10 个 Skill 全用来管理行动目标拆解、任务分解、进度检查、周复盘、项目复盘、决策记录。这些 Skill 会把知识库里的笔记、卡片、会议纪要变成下一步行动项。Skill 名称触发场景核心输出okr-splitter设定季度目标时目标、关键结果拆解task-breaker任务太大无从下手时可执行步骤、依赖关系progress-check检查项目进度时进度报告、风险预警weekly-review周末复盘时本周完成、未完成、下周计划retro-run项目结束后做得好、做得差、改进项decision-log做了重要决策时决策背景、选项对比、结论action-extract会议纪要堆叠时行动项清单、负责人prio-ice需求或想法太多时按价值和成本排序habit-score习惯打卡需要复盘时连续天数、趋势分析dashboard-gen需要一页看板时个人核心指标汇总这 10 个里面我最推荐先做 weekly-review。它是我全系统里使用频率最高的 Skill每周日晚固定触发。它会把本周新增的笔记、完成的卡片、写下的日志全部聚合起来输出一份包含“本周完成、本周未完成、关键洞察、下周计划”四个板块的复盘报告。配合 task-breaker还能把下一周的目标自动拆成可执行的任务列表。3. 核心搭建实操目录结构、SKILL.md 与主流工具接入3.1 标准目录结构与 SKILL.md 配置规范50 个 Skill 如果散落各处很快就会失控。我建议统一放在一个“技能库”目录里用 Git 管理结构如下my-knowledge-skills/ ├── README.md ├── skills/ │ ├── card-maker/ │ │ ├── SKILL.md │ │ ├── scripts/ │ │ │ └── split_cards.py │ │ └── reference/ │ │ └── card_example.md │ ├── moc-builder/ │ │ ├── SKILL.md │ │ └── scripts/ │ │ └── cluster_notes.py │ ├── weekly-review/ │ │ └── SKILL.md │ ├── web-clipper/ │ │ └── SKILL.md │ └── ... ├── config/ │ └── global_metadata.yaml └── templates/ └── skill_template.md每个 Skill 至少包含一个 SKILL.md。这个文件是所有工具都能读懂的“岗位说明书”。我用的标准模板是 YAML frontmatter 加正文步骤说明--- name: skill-name description: 一句话说明这个技能做什么 when_to_use: 什么样的用户请求或文件内容会触发它 version: 1.0.0 tags: [知识管理, 提炼] input: format: text/markdown max_length: 20000 output: format: markdown structure: 固定输出结构描述 steps: 1. 第一步做什么 2. 第二步做什么 ---这几个字段里最重要的是 description 和 when_to_use。因为 Skill 能不能被正确触发全靠它们。description 给 AI 一个快速判断这个技能和当前问题是否有关。when_to_use 要写用户真实会说的话比如“帮我摘成卡片”“把这周总结一下”“太长了帮我提炼”。我看到很多人写得很专业却忘了用户的实际口语结果技能永远不触发。3.2 三个核心 Skill 的完整参考实现第一个推荐 card-maker这是知识管理最核心的转化动作。它把一篇长文或书章节拆成原子卡片。完整 SKILL.md 如下--- name: card-maker description: 将长文章、网页正文或书籍章节切成原子知识卡片保留原文出处与上下文链接 when_to_use: 用户说“摘成卡片”“提取知识点”“读完这篇帮我整理笔记”或输入内容超过 5000 字且希望结构化时 version: 1.2.0 tags: [知识管理, 提炼, 卡片笔记] input: format: text/markdown max_length: 30000 output: format: markdown structure: | # 卡片组源标题 源信息来源链接/书籍页码 ## 卡片 1 - 标题一句话概括 - 原文摘要200 字以内 - 核心概念概念1、概念2 - 关联笔记相关已有笔记名 - 原始出处章节/行号 steps: 1. 按 markdown 标题或段落切分出逻辑块 2. 每块提炼一个核心主题合并重复内容 3. 为每张卡片生成独立标题和 frontmatter 建议 4. 检查卡片之间的逻辑关系补关联笔记 ---这个 Skill 我会配合一个脚本使用负责把长文先切成块避免把整篇文章丢给模型处理import re def split_blocks(text: str, max_blocks: int 12): lines text.splitlines() blocks [] current_title 未命名区块 current_lines [] for line in lines: if re.match(r^#{1,3}\s, line): if current_lines: blocks.append({title: current_title, content: \n.join(current_lines)}) current_title line.strip(#).strip() current_lines [] else: current_lines.append(line) if current_lines: blocks.append({title: current_title, content: \n.join(current_lines)}) return blocks[:max_blocks]第二个是 moc-builder负责把散落的笔记变成主题地图。它的 SKILL.md 重点是“聚类”和“双链生成”--- name: moc-builder description: 从同一主题的一组笔记中生成 MOC内容地图自动聚类并生成双链目录 when_to_use: 用户说“帮我建一个 MOC”“把 XX 主题的笔记整理成地图”或知识库内同一标签笔记超过 10 条 version: 1.0.0 tags: [知识管理, 整理, MOC] input: format: markdown source: 本地知识库扫描结果 output: format: markdown structure: | # MOC主题名 ## 概览 这个主题覆盖了哪些方向适合什么人阅读。 ## 子主题 - [[笔记标题 1]] - [[笔记标题 2]] - [[笔记标题 3]] steps: 1. 收集该主题下所有笔记标题和 frontmatter 标签 2. 按关键词聚类成 5-7 个子主题 3. 生成层级结构每个子主题写一句说明 4. 用双链语法输出保证在 Obsidian 中可跳转 ---第三个是 weekly-review这是全系统里使用频率最高的工具。它的输出结构非常固定方便存档和后续任务拆解--- name: weekly-review description: 按周聚合本周完成、未完成、知识输入和下周计划生成一份可归档的复盘报告 when_to_use: 周末或用户说“周复盘”“这周总结”“本周回顾”时 version: 1.3.0 tags: [复盘, 项目管理, 输出] input: format: 任务列表、日记、会议纪要、笔记新增列表 window: 最近 7 天 output: format: markdown structure: | # 2025-Wxx 周复盘 ## 本周完成 ## 本周未完成 ## 关键洞察 ## 下周计划含优先级 steps: 1. 列出本周所有任务完成情况 2. 对比目标找出未完成项和原因 3. 从本周笔记和卡片中提取 2-3 条关键洞察 4. 根据洞察生成下周计划并给出优先级 ---这三个 Skill 放在一起基本就能跑通“采集—整理—提炼—复盘”的闭环。其他 47 个 Skill 都是从这套模板派生出来的把 name、description、when_to_use 和 output.structure 换掉就行。3.3 在 Cursor、Claude Code、OpenCode 中接入不同 AI 工具的 Skill 加载机制略有差异但底层逻辑一致把一个带 SKILL.md 的目录放到约定路径下就行。以我实际用过的几个工具为例Claude Code 原生支持 Skill 机制把 SKILL.md 放到.claude/skills/skill-name/目录下运行时会自动扫描并加载。Cursor 目前更常用的是 Rules 机制可以把 SKILL.md 内容塞进.cursor/rules/下的规则文件里或者直接让 Agent 按指定目录读取技能说明。OpenCode 也提供了 skill 配置能力常见路径是~/.config/opencode/skill/项目内也可以建.skill/目录。实际操作时我习惯在知识库项目根目录建一个skills/目录然后在工具配置里声明加载路径。这样技能库和知识库放在同一个仓库里跟着 Git 走换机器也不怕丢mkdir -p skills/card-maker/scripts # 将 SKILL.md 放入对应目录 # 在知识库项目根目录中配置 Agent 指向这个 skills 目录如果你用的工具还没有原生 Skill 机制还有一个通用做法把 SKILL.md 作为一条长期规则加载到 system prompt 里。但这样会占上下文所以我建议只保留触发频率最高的 5-6 个。真正完整的一套 Skill 目录还是留给支持懒加载的工具用。4. 实操闭环从网页剪藏到周报输出的完整跑通4.1 链路一网页文章 → 知识卡片 → MOC 地图我拿真实场景演示一遍。假设我看到一篇关于 LLM Agent 设计模式的长文想存进 Obsidian 知识库。以前我要手动复制正文、删广告、起标题、打标签、再思考它和已有笔记的关系。现在只需要把正文粘贴给 AI说一句“帮我存一下”。AI 先触发 web-clipper对网页进行清洗输出摘要、标签和元数据。我确认后再触发 card-maker把正文拆成几张原子卡片。输出大概长这样源信息https://example.com/llm-agent-patterns 标题LLM Agent 的四种设计模式 卡片 1 - 标题Agent LLM 规划 工具 记忆 - 原文摘要Agent 系统由四个核心模块组成规划循环负责决定下一步动作。 - 核心概念规划循环、工具调用、记忆单元 - 关联笔记[[Skill 机制原理]] - 原始出处第二章第 12-15 段卡片写回知识库后我再对 AI 说“把 LLM Agent 相关笔记整理成 MOC”。moc-builder 会扫描所有标题带 Agent 的笔记按主题聚类生成一个带双链的内容地图。整个过程从原来的 15 分钟压缩到 1 分钟我只需要在最后确认一下卡片是否准确。这一步解决了“收藏后再也不看”的问题因为进来的时候已经被拆成了原子卡片未来任何一篇笔记想引用它都能直接检索到。4.2 链路二项目杂谈 → 周复盘 → 下周计划第二条链路是每周日跑一次的复盘流程。我把本周新增的笔记路径、任务列表、会议记录统一喂给 AI触发 weekly-review。它会聚合本周完成的事项、没做完的事、以及从笔记里提取的关键洞察。举个例子本周我完成了三个任务搭好 web-clipper、写完卡片模板、处理两份 PDF 论文。读了两篇关于知识库索引的文章开了一次项目会会上决定要梳理标签体系。weekly-review 输出的复盘报告会把这些信息归到四个板块里。接下来我再触发 task-breaker把“梳理标签体系”这个大任务拆成“导出标签列表、识别重复标签、生成合并映射、执行 batch rename”四个步骤分配给下周。这条链路最大的价值是“知识输入和任务输出被连起来了”。以前我的周复盘要翻聊天记录、翻日记、翻任务软件现在只需要给 AI 一个范围它自动把所有散落的信息找出来按固定模板汇总。我只需要判断优先级和取舍不再需要做信息搬运。4.3 调参与协作技巧用了一段时间后我总结出几个让系统更顺手的技巧。第一when_to_use 一定要写用户口语。比如“帮我存一下”“摘卡片”“太长了”这种短句比“对文本进行知识抽取和结构化”触发率高得多。AI 判断触发靠的是语义匹配不是关键词堆砌。第二长文档不要直接丢给模型。超过两三万字的文件先用 scripts 里的脚本切块再逐块处理。Skill 里的脚本不一定每次都要写复杂逻辑有时就是一个正则切分函数但能大幅减少上下文消耗。第三多个 Skill 都可能匹配同一输入时要在 README 里定义职责边界。比如 card-maker 处理长文提炼essence-bullets 处理要点提取两者容易重叠。我通常会在 prompt 里让用户显式指定或者在 Skill 描述里写明互斥条件。第四Skill 目录一定要用 Git 管理。我每个月会清理一次不再使用的 Skill合并语义重叠的把常用角色调优后提交 commit。Skill 也是知识资产不维护就会过期。5. 常见问题与排查技巧实录5.1 六大高频问题与解决思路我在搭建和使用的过程中遇到过不少问题挑六个出现频率最高的列出来现象可能原因解决思路AI 没触发想要的 Skillwhen_to_use 触发词太少补充用户口语说法如“帮我存一下”“摘卡片”输出格式不稳定SKILL.md 里没有输出示例在 output.structure 里放一个真实模板上下文爆掉一次喂了太多文件先用 scripts 分块再逐块处理多个 Skill 重复处理两个技能描述重叠定义职责边界加互斥条件换工具后不生效目录路径或命名不合规范查目标工具的 Skill 文档确认目录名更新模型后结果变化新模型不熟悉旧指令固定模型版本或增加 few-shot 示例最麻烦的是第一个问题。很多时候不是 Skill 写错了而是描述和用户实际表达对不上。比如我很长时间没想明白为什么“帮我整理一下”不会触发 card-maker后来才发现这个请求太模糊模型不知道要拆成卡片还是生成目录。自从我在 when_to_use 里加了“摘成卡片”“提取知识点”这些明确动词后触发率明显上升。5.2 排查顺序速查表当某个 Skill 不按预期工作时我有一套固定排查顺序按步骤来基本能定位问题确认 Skill 目录被工具扫描到。打开工具的调试菜单或手动执行一次技能列表命令看目标技能是否出现在已加载列表里。把输入切到最小。用一个十几行的测试文本加一句最直白的触发指令比如“摘成卡片”排除长文本带来的干扰。检查输出是否遵守 output.structure。如果不遵守多半是示例不够具体补一个完整输出样例。考虑是否有多个 Skill 同时匹配。临时禁用其他技能只留目标技能看行为是否恢复正常。实在不触发把 SKILL.md 的内容直接作为普通 Prompt 塞进对话。如果这样能正常工作说明是加载配置的问题如果也不行说明是技能内容本身的问题。这套排查顺序帮我解决过不少看似诡异的问题。有一次我以为是模型变笨了结果发现是目录名大小写写错工具压根没扫描到那个目录。5.3 最后分享几点使用体会折腾完这套系统之后我最大的感受是知识管理的瓶颈从来不是工具不够多而是每个动作的规范没有被固化下来。Skill 把散落在提示词里的经验变成了可维护的资产也让 AI 从一个“偶尔好用的话痨”变成一个“稳定交付的整理搭子”。50 个 Skill 听起来像一个大工程但它真正的建设节奏是每周三五个不知不觉就攒出来了。我建议第一次动手不要追求一次建完 50 个。先做一个 card-maker拿收藏夹里的旧文章跑一遍。跑通之后你自然会发现下一个值得固化的动作是 moc-builder然后是 web-clipper再然后是 weekly-review。我的经验是第一个 Skill 建完后剩下的会跟着实际使用慢慢长出来。知识管理不是靠囤积而是靠流程。Skill 这套机制恰恰就是把你脑子里的流程搬到 AI 手里的最小可行方案。
