1. 从零理解知识管理 Skill 与 AI 生产力系统的关系1.1 为什么单靠大模型不够用很多人第一次接触 AI 生产力工具时都会有一个朴素的想法只要模型足够强我把问题丢进去它就能帮我搞定一切。实际用下来你会发现模型本身的能力是一回事你能不能把它的能力稳定地、可复用地调用出来是另一回事。这中间的差距就是 Skill 存在的意义。打个比方大模型像是一个知识渊博但记性不太好的顾问。你每次找他咨询他都从零开始理解你的背景、你的偏好、你的工作习惯。如果你只问一次没问题但如果你每天都要问类似的问题每次都重新解释一遍效率就极低。Skill 的作用就是把这个顾问的工作流程固化下来变成一套标准操作程序让他每次都能按照你预设的路径去执行。知识管理这个场景尤其明显。知识管理的核心不是“知道很多”而是“在需要的时候能快速找到、正确理解、有效复用”。这涉及信息的采集、分类、关联、检索、更新、淘汰等一系列动作。如果每个动作都靠手动完成那知识管理本身就成了负担。而如果把这一系列动作拆解成一个个 Skill让 AI 按照 Skill 定义的流程去执行你就能把精力真正放在思考和决策上而不是浪费在整理和查找上。1.2 Skill 到底是什么和 Agent 有什么区别这里需要先把概念理清楚。Skill 和 Agent 经常被混着用但它们的定位完全不同。Agent 是一个能自主决策、调用工具、完成复杂任务的智能体。它更像是一个“执行者”你给它一个目标它自己规划路径、选择工具、逐步推进。Agent 的核心能力在于自主性和适应性。Skill 则是一个封装好的能力单元。它定义的是“在特定场景下按照特定步骤完成特定任务”的标准流程。Skill 不负责决策它负责执行。你可以把 Skill 理解成 Agent 工具箱里的一个个专用工具每个工具都有明确的使用说明和操作步骤。用一个生活化的类比Agent 像是一个装修队长他负责统筹整个装修项目决定先刷墙还是先铺地板协调水电工和木工的时间。Skill 则像是贴瓷砖这个具体工序的操作规范它规定了基层怎么处理、瓷砖怎么泡水、砂浆怎么配比、缝隙怎么对齐。队长可以调用贴瓷砖的 Skill也可以调用刷墙的 Skill但每个 Skill 本身是独立、完整、可复用的。在知识管理场景下Agent 负责理解你的需求比如“帮我整理上周关于项目管理的所有笔记提取关键决策点生成一份摘要”。而 Skill 则负责执行具体的子任务比如“从笔记中提取决策点”这个 Skill、“生成结构化摘要”这个 Skill、“按主题分类”这个 Skill。Agent 编排这些 Skill完成最终目标。1.3 50 个 Skill 的体系化设计思路为什么是 50 个这个数字不是随便定的。知识管理涉及的信息处理环节非常多如果 Skill 太少覆盖不全很多场景还是得手动如果 Skill 太多管理成本又上去了你记不住哪个 Skill 是干什么的反而降低效率。50 个左右的 Skill刚好能覆盖知识管理的完整链路同时每个 Skill 的职责边界清晰不会出现功能重叠。按照我的实践经验这 50 个 Skill 可以分成六大类信息采集类负责从各种来源获取信息比如网页剪藏、文档导入、语音转文字、图片 OCR 等。信息处理类负责对原始信息进行清洗、格式化、去重、翻译、摘要等。知识组织类负责分类、打标签、建立关联、构建知识图谱、维护本体结构等。知识检索类负责语义搜索、关键词搜索、相似推荐、上下文召回等。知识输出类负责生成报告、制作演示文稿、撰写文章、整理问答等。系统维护类负责定期备份、版本管理、质量检查、过期内容清理等。这六类 Skill 之间不是孤立的而是通过 Agent 编排形成工作流。比如你收藏了一篇技术文章信息采集 Skill 先把它抓下来信息处理 Skill 提取正文、去掉广告、生成摘要知识组织 Skill 自动打上标签并关联到已有知识节点知识检索 Skill 在你下次搜索相关主题时把它召回知识输出 Skill 在你写报告时引用它。整个链路是打通的。提示不要一开始就追求 50 个 Skill 全部上线。先选 5 到 8 个最常用的跑通形成肌肉记忆后再逐步扩展。贪多嚼不烂这是我在多个项目中反复验证过的教训。2. 核心 Skill 的拆解与实操要点2.1 信息采集类 Skill把散落的信息收拢起来信息采集是整个知识管理链路的第一环。如果采集环节做不好后面所有环节都是白费力气。我见过太多人收藏夹里堆了几千篇文章但从来没看过第二遍。问题不在于收藏这个动作而在于收藏之后没有后续处理。网页剪藏 Skill是最基础的一个。它的核心逻辑是给定一个 URL自动提取正文内容、标题、作者、发布时间、来源网站并转换成干净的 Markdown 格式。这里的关键难点在于正文提取的准确率。很多网页有复杂的导航栏、侧边栏、广告位、评论区如果提取算法不够精准抓下来的内容会夹杂大量噪音。我的做法是在 Skill 里配置一个“正文密度检测”逻辑。具体来说先解析 HTML 的 DOM 树计算每个区块的文本密度文本字符数除以 HTML 标签数密度最高的区块大概率就是正文。然后再结合一些启发式规则比如排除 class 名包含 “comment”、“sidebar”、“footer”、“ad” 的区块。这套逻辑实测下来对主流内容网站的正文提取准确率能到 90% 以上。文档导入 Skill负责处理本地文件。PDF、Word、Excel、PPT、EPUB 这些格式都需要不同的解析库。PDF 最麻烦因为有些 PDF 是扫描件需要 OCR有些 PDF 有复杂的多栏排版解析出来顺序会乱。我的经验是对于扫描件先用 OCR Skill 转成文本再走正常的文本处理流程对于多栏排版用版面分析算法先识别分栏边界再按栏顺序提取。语音转文字 Skill适合处理会议录音、访谈记录、灵感口述。现在开源的语音识别模型效果已经不错但关键是要做好说话人分离。如果一段录音里有三个人在说话转出来的文字混在一起后续处理会很困难。我的做法是在 Skill 里集成说话人分离模块先识别出有几个说话人再把每个人的发言分段标注。图片 OCR Skill处理截图、白板照片、名片等。这里有个细节白板照片往往有透视变形直接 OCR 效果很差。需要先做透视校正把白板区域矫正成矩形再做二值化处理最后才 OCR。这个预处理步骤能显著提升识别率。2.2 信息处理类 Skill把原始信息变成可用知识采集来的信息是“生”的需要经过处理才能变成“熟”的知识。信息处理类 Skill 就是干这个的。去重 Skill看似简单实则暗藏玄机。最简单的去重是精确匹配两篇文章标题完全一样就判定为重复。但现实中更多的情况是“近似重复”比如同一篇文章在不同平台发布标题略有不同正文有少量修改。这时候就需要用语义相似度来判断。我的做法是先用 SimHash 做快速粗筛把可能重复的文档找出来再用向量相似度做精细比对。SimHash 的好处是计算极快适合大规模文档向量相似度更准但计算成本高只用在粗筛后的候选集上。摘要生成 Skill是使用频率最高的 Skill 之一。但很多人对摘要的理解有偏差以为摘要就是把文章缩短。实际上好的摘要应该保留原文的核心论点、关键数据、重要结论同时去掉冗余的论证过程和举例。我在 Skill 里设置了三个摘要层级一句话摘要不超过 50 字、段落摘要不超过 200 字、结构化摘要包含背景、方法、结论、启示四个部分。不同场景调用不同层级比如在知识库列表页显示一句话摘要在详情页显示结构化摘要。翻译 Skill在知识管理中经常被低估。很多有价值的信息是英文的但阅读英文的速度毕竟不如中文。翻译 Skill 的关键是要保持术语的一致性。比如 “Agent” 这个词如果一会儿翻译成“代理”一会儿翻译成“智能体”一会儿又保留英文读者会非常困惑。我的做法是维护一个术语表在 Skill 里强制使用术语表里的译法。术语表可以手动维护也可以让 AI 从已有翻译中自动提取。格式化 Skill负责把各种来源的内容统一成标准格式。比如网页剪藏的内容可能带有大量空行和多余空格PDF 导入的内容可能有断行问题语音转文字的内容可能没有标点。格式化 Skill 要做的就是清理这些问题输出干净、结构化的 Markdown。这里有个小技巧用正则表达式处理批量文本时一定要注意贪婪匹配和非贪婪匹配的区别。我踩过好几次坑一个贪婪匹配把整篇文章都吞掉了。2.3 知识组织类 Skill让知识之间产生连接知识管理的精髓不在于收集了多少而在于知识之间的连接有多丰富。一个孤立的知识点价值有限但当它和几十个其他知识点建立关联后价值会呈指数级增长。自动打标签 Skill是知识组织的基础。标签的质量直接决定了后续检索的效率。我的经验是标签体系不要设计得太复杂三层足够了领域标签如“人工智能”、主题标签如“知识管理”、类型标签如“方法论”。标签数量控制在 50 到 100 个之间太少覆盖不全太多记不住也用不好。自动打标签的实现方式有两种一种是基于规则的比如文章里出现“神经网络”、“深度学习”、“反向传播”就自动打上“机器学习”标签另一种是基于语义的用文本嵌入模型计算文章与标签的相似度。我通常两种结合使用规则打底保证召回率语义补充提升准确率。知识图谱构建 Skill是进阶玩法。它的核心是从文本中提取实体和关系构建成图结构。比如从“张三在 A 公司负责 B 项目该项目使用了 C 技术”这句话中提取出“张三-任职于-A 公司”、“张三-负责-B 项目”、“B 项目-使用-C 技术”三个关系。这些关系积累起来就形成了一张知识网络。构建知识图谱的难点在于实体消歧。比如“苹果”可能指水果也可能指公司。需要结合上下文来判断。我的做法是在 Skill 里加入一个实体链接模块把提取出的实体链接到知识库中的标准实体上。如果知识库里没有这个实体就创建一个新实体并记录它的上下文特征方便后续消歧。本体建模 Skill是知识图谱的上层建筑。本体定义了知识的结构包括有哪些实体类型、哪些关系类型、有哪些属性、有什么约束。比如在项目管理领域本体可能定义“项目”有“负责人”、“开始时间”、“结束时间”、“状态”等属性“项目”和“任务”之间是“包含”关系。有了本体知识图谱才能保持一致性不会出现同一个概念有多种表示方式的情况。本体建模不需要一开始就追求完美。我的建议是先建一个最小可用本体覆盖最核心的 10 到 20 个概念然后在使用过程中逐步扩展。每次遇到本体无法表达的情况就补充新的概念或关系。这样本体是“长”出来的而不是“设计”出来的更贴合实际需求。2.4 知识检索类 Skill在需要的时候找到需要的东西知识管理最大的痛点不是没有知识而是找不到知识。你明明记得自己收藏过一篇文章但就是想不起来放在哪里了。检索类 Skill 就是解决这个问题的。语义搜索 Skill和传统关键词搜索的区别在于它理解的是“意思”而不是“字面”。比如你搜“怎么提高工作效率”传统搜索只能匹配包含这些关键词的文档而语义搜索能找出讨论“时间管理”、“精力管理”、“专注力训练”的文档即使这些文档里没有出现“工作效率”这四个字。实现语义搜索的核心是文本嵌入。把每篇文档转换成一个高维向量搜索时把查询也转换成向量然后计算向量之间的余弦相似度相似度最高的就是最相关的文档。这里的关键是嵌入模型的选择。模型太小语义表达能力不够模型太大计算成本高。我的经验是对于个人知识库几千到几万篇文档用中等规模的嵌入模型就足够了没必要上最大的模型。相似推荐 Skill是在你阅读某篇文档时自动推荐与之相似的其他文档。这个功能特别适合做主题阅读。比如你在读一篇关于“间隔重复”的文章系统推荐了“主动回忆”、“费曼学习法”、“记忆曲线”等相关文章你就能顺着这条线深入下去。相似推荐的实现和语义搜索类似也是基于向量相似度。区别在于语义搜索是“查询到文档”相似推荐是“文档到文档”。另外相似推荐还需要考虑多样性不能推荐十篇几乎一模一样的文章。我的做法是在推荐结果中加入一个多样性惩罚项如果两篇推荐文档之间的相似度太高就降低其中一篇的排名。上下文召回 Skill是在你写作或对话时自动从知识库中找出相关的背景信息。比如你在写一篇关于“AI Agent”的文章系统自动把你之前收藏的 Agent 相关文章、你写过的 Agent 相关笔记、你标注过的 Agent 相关重点都召回出来放在侧边栏供你参考。这个功能能极大减少“切换应用去查找”的时间损耗。上下文召回的关键是“相关性”和“及时性”的平衡。召回太多会干扰注意力召回太少又不够用。我的做法是根据当前内容的主题动态调整召回数量。主题越聚焦召回越少而精主题越宽泛召回越多而全。3. 搭建 AI 生产力系统的完整实操流程3.1 环境准备与工具选型在开始搭建之前需要先确定技术栈。我的建议是如果你有编程基础用 Python 生态最灵活如果你不想写代码可以用现成的知识管理工具加上 AI 插件。编程方案的核心组件包括向量数据库用于存储文档嵌入向量支持快速相似度检索。可选的有 Chroma、Qdrant、Milvus 等。个人使用推荐 Chroma轻量、易用、零配置。嵌入模型用于把文本转换成向量。可选的有 OpenAI 的 text-embedding 系列、开源的 BGE 系列、M3E 系列等。中文场景推荐 BGE 或 M3E。大语言模型用于摘要、翻译、打标签、提取实体等。可选的有 GPT 系列、Claude 系列、开源的通义千问、智谱等。编排框架用于把各个 Skill 串联成工作流。可选的有 LangChain、LlamaIndex、Dify 等。个人推荐 LlamaIndex对知识管理场景的支持更原生。无代码方案的核心组件包括知识管理工具Notion、Obsidian、Logseq 等。Obsidian 的插件生态最丰富适合做深度定制。AI 插件Obsidian 有 Copilot、Text Generator、Smart Connections 等插件能实现摘要、翻译、语义搜索等功能。自动化工具Zapier、Make、n8n 等用于连接不同工具实现自动化流程。我的建议是如果你只是想快速用起来先从无代码方案开始用 Obsidian 加上几个核心插件把基本流程跑通。等你对知识管理的各个环节有了体感再考虑用编程方案做深度定制。3.2 核心 Skill 的配置与调试以“网页剪藏”这个 Skill 为例完整配置流程如下第一步确定输入输出。输入是一个 URL输出是结构化的 Markdown 文本包含标题、作者、发布时间、正文、标签。第二步选择正文提取库。Python 生态里newspaper3k和readability-lxml是两个常用的正文提取库。newspaper3k对新闻类网站效果好readability-lxml对博客类网站效果好。我的做法是两个都用取文本密度更高的那个结果。第三步配置元数据提取规则。标题通常可以从h1标签或title标签提取作者可以从meta nameauthor或页面中的作者信息区块提取发布时间可以从meta propertyarticle:published_time或页面中的时间标签提取。不同网站的规则不同需要针对常用网站做适配。第四步配置标签生成逻辑。可以用关键词匹配也可以用语义相似度。我的做法是先用关键词匹配快速打一批标签再用语义相似度补充最后合并去重。第五步调试和优化。拿 20 到 30 个不同类型的网页做测试看提取结果是否准确。常见问题包括正文提取不全、元数据缺失、标签不准确。针对每个问题调整配置直到准确率达到可接受的水平。注意调试 Skill 时一定要用真实数据不要用构造的测试数据。真实网页的复杂性远超你的想象只有用真实数据才能发现真正的问题。3.3 工作流编排让 Skill 自动运转单个 Skill 配好之后下一步是把它们串联成工作流。以“收藏文章到知识库”这个场景为例完整的工作流如下触发你在浏览器里点击“收藏”按钮或者把 URL 粘贴到指定输入框。网页剪藏 Skill抓取网页内容提取正文和元数据。去重 Skill检查知识库里是否已有相同或相似的文章。如果有提示你“已存在相似文章”并给出链接。摘要生成 Skill生成一句话摘要和结构化摘要。翻译 Skill如果原文是英文生成中文翻译。自动打标签 Skill生成领域标签、主题标签、类型标签。知识图谱构建 Skill提取实体和关系更新知识图谱。存储把处理后的内容存入知识库更新向量索引。这个工作流可以用 LlamaIndex 的 Workflow 功能来实现也可以用简单的 Python 脚本串联。关键是每个步骤都要有错误处理比如网页抓取失败怎么办、摘要生成超时怎么办。我的做法是每个 Skill 都设置重试机制最多重试三次三次都失败就记录日志并跳过不阻塞整个流程。工作流跑通之后你可以设置定时任务比如每天早上自动处理前一天收藏的文章生成一份“昨日收藏摘要”推送给你。这样你就不用手动触发系统会自动运转。3.4 效果验证与迭代优化系统搭好之后怎么判断它好不好用我的经验是看三个指标采集覆盖率你收藏的内容中有多少被成功处理并存入知识库。这个指标反映的是系统的稳定性。检索命中率你搜索时前三条结果中有多少是你真正想要的。这个指标反映的是检索的质量。复用率你写作或决策时有多少次真正引用了知识库里的内容。这个指标反映的是系统的实际价值。这三个指标不需要精确计算凭感觉估个大概就行。如果采集覆盖率低于 80%说明采集环节有问题需要排查如果检索命中率低于 50%说明检索环节有问题可能需要调整嵌入模型或检索策略如果复用率很低说明知识库的内容和你的实际需求不匹配需要重新审视你收藏的内容类型。迭代优化的节奏我的建议是每两周做一次小调整每个月做一次大调整。小调整是修修补补比如某个网站的提取规则失效了更新一下大调整是结构性优化比如发现标签体系不合理重新设计一套。4. 常见问题与排查技巧实录4.1 Skill 不生效的排查思路Skill 不生效是最常见的问题表现可能是触发了但没反应、输出结果不对、报错但不知道错在哪里。我的排查思路是“从外到内逐层定位”。先看触发层。确认触发条件是否满足比如 URL 是否合法、文件是否存在、权限是否足够。很多时候问题就出在这一层比如你配置的是“当收藏文章时触发”但你实际的操作是“分享到知识库”触发条件不匹配Skill 自然不会执行。再看输入层。确认输入数据是否符合预期。比如网页剪藏 Skill 期望的输入是一个完整的 URL但你传入的是一个短链接短链接需要先展开才能访问。这种问题很隐蔽因为 Skill 不会报错只是默默地返回空结果。然后看处理层。确认每个处理步骤是否正常执行。我的做法是在 Skill 的每个关键步骤加日志记录输入、输出、耗时。这样一旦出问题看日志就能快速定位是哪一步卡住了。最后看输出层。确认输出格式是否符合预期。有时候 Skill 执行成功了但输出格式不对导致下游 Skill 无法解析。比如摘要生成 Skill 输出的是纯文本但下游的存储 Skill 期望的是 JSON 格式就会出错。4.2 检索结果不准确的优化方法检索结果不准确通常有三个原因嵌入模型不合适、检索策略太单一、知识库质量不高。嵌入模型的问题最常见。如果你用的是英文嵌入模型来处理中文内容效果肯定不好。中文场景一定要用中文嵌入模型比如 BGE-zh 或 M3E。另外嵌入模型的维度也很重要。维度太低语义表达能力不够维度太高计算成本高且容易过拟合。我的经验是768 维或 1024 维是比较平衡的选择。检索策略太单一指的是只用向量相似度不考虑其他信号。实际上关键词匹配、时间衰减、来源权威性、用户行为反馈都可以作为排序信号。我的做法是先用向量相似度召回 Top 50再用一个综合排序模型对这 50 个结果重新排序。综合排序模型考虑向量相似度、关键词匹配度、文档新鲜度、文档质量分等多个因素。知识库质量不高指的是知识库里有很多低质量内容比如重复文章、过时信息、无关内容。这些内容会干扰检索结果。我的做法是定期做知识库清理删除重复文章归档过时信息标记无关内容。另外在检索时可以加一个质量过滤只返回质量分高于阈值的文档。4.3 系统性能瓶颈的应对策略当知识库规模增长到一定程度系统性能会成为瓶颈。常见的瓶颈包括嵌入计算慢、向量检索慢、工作流执行慢。嵌入计算慢通常是因为每次都要重新计算所有文档的嵌入。我的做法是只对新文档和修改过的文档计算嵌入已有文档的嵌入缓存起来。另外可以用批量计算代替单条计算一次处理 100 条比一条一条处理快很多。向量检索慢通常是因为向量数据库没有建索引。Chroma 默认用的是暴力检索数据量大了会很慢。需要切换到 HNSW 或 IVF 索引。HNSW 检索速度快但内存占用高IVF 内存占用低但检索速度稍慢。个人使用推荐 HNSW内存换速度是值得的。工作流执行慢通常是因为串行执行。比如一个工作流有 10 个步骤每个步骤耗时 1 秒总共就是 10 秒。如果步骤之间没有依赖关系可以并行执行。比如摘要生成和翻译可以同时进行不需要等摘要生成完再翻译。我的做法是把工作流拆成有向无环图找出可以并行的节点用异步任务并行执行。4.4 常见问题速查表问题现象可能原因排查方法解决方案Skill 触发无反应触发条件不匹配检查触发配置和实际操作是否一致调整触发条件或改变操作方式网页剪藏内容不全正文提取算法不适用查看提取结果对比原网页更换提取库或调整提取规则摘要质量差模型能力不足或提示词不佳人工评估摘要质量更换更强的模型或优化提示词检索结果不相关嵌入模型不合适用已知相关文档测试检索更换嵌入模型或增加排序信号标签不准确标签体系不合理或匹配规则太粗统计标签分布查看误标案例重新设计标签体系或细化匹配规则系统响应慢索引缺失或串行执行查看各环节耗时建索引或改为并行执行知识图谱关系错误实体消歧失败查看错误关系的上下文增加消歧规则或人工校正工作流中断某个 Skill 报错未处理查看日志定位报错步骤增加错误处理和重试机制提示这张表建议打印出来贴在显示器旁边遇到问题先查表能解决 80% 的常见问题。剩下的 20% 再深入排查。4.5 独家避坑经验分享第一个坑不要追求大而全的标签体系。我一开始设计了 200 多个标签结果发现根本用不过来而且标签之间的边界很模糊打标签时经常纠结。后来精简到 60 个左右效率反而提高了。标签是给人用的不是给机器用的人记不住那么多标签。第二个坑不要把所有内容都往知识库里塞。我有一段时间看到什么都想收藏结果知识库里堆了大量低质量内容检索时噪音很大。后来我定了一个规矩只收藏那些我未来可能会引用的内容。判断标准很简单如果这篇文章的内容我能用自己的话复述出来就不收藏如果里面有我记不住的数据、框架、方法才收藏。第三个坑不要忽视定期维护。知识库像花园需要定期修剪。我每个月会花一个小时做维护删除重复文章、归档过时内容、合并相似标签、修复错误关联。这一个小时的投入能换来接下来一个月的高效使用。第四个坑不要过度依赖自动化。自动化能解决 80% 的重复劳动但剩下 20% 的判断需要人工介入。比如一篇重要文章的标签我通常会手动检查一遍一个关键决策的摘要我会手动修改润色。自动化是辅助不是替代。第五个坑不要忽略备份。知识库是你长期积累的资产一旦丢失损失巨大。我的做法是知识库每天自动备份到本地和云端各一份保留最近 30 天的版本。备份文件要定期做恢复测试确保备份是有效的。我见过太多人备份了但从来没恢复过真出事的时候才发现备份文件是坏的。4.6 从 50 个 Skill 到个人生产力系统的演进路径50 个 Skill 不是终点而是起点。当你把这 50 个 Skill 跑通之后你会发现一些新的需求这些需求会催生新的 Skill。比如你可能会发现每次写周报都要手动从知识库里找本周的工作记录。这时候你可以做一个“周报生成 Skill”自动汇总本周的笔记、任务完成情况、关键决策生成一份周报草稿。再比如你可能会发现有些知识已经过时了但你还不知道。这时候你可以做一个“知识保鲜 Skill”定期检查知识库里的内容标记那些超过一定时间没有更新、且所在领域已经发生重大变化的内容提醒你复核。还比如你可能会发现你在不同设备上使用知识库同步是个问题。这时候你可以做一个“多端同步 Skill”自动处理冲突合并、版本对齐。这些 Skill 不是一开始就能设计出来的而是在使用过程中“长”出来的。我的建议是保持一个“Skill 想法清单”每次遇到重复劳动就记下来攒够三五个就集中实现一批。这样你的生产力系统会越来越贴合你的实际工作方式越来越好用。我个人在实际操作中的体会是知识管理系统的价值不在于它有多先进而在于你有多愿意用它。一个简单但每天用的系统远胜过一个复杂但吃灰的系统。所以不要被 50 个 Skill 这个数字吓到从最简单的开始用起来再慢慢扩展。用着用着你就会发现AI 不再是那个需要你反复解释的顾问而是真正融入了你的工作流成为了你思维的一部分。