你花了10年积累的经验，可以装进AI里吗？

前言

我最近干了一件事——把自己的工作经验，打包进了AI里。

不是丢进知识库、不是写进系统提示词，而是封装成一个真正可以复用、可以分享、可以随时调出来的技能模块。

想要写文章的时候，我说了一句话："帮我写一篇主题为XXX的公众号文章"。AI直接开干，生成正文、标题、配图。

这背后的工具，叫WorkBuddy的Skill（技能）系统。

AI每次都要重新教，累不累？

用过AI的人，大概都踩过这个坑。

你跟AI说：帮我做一份竞品分析，按我的格式来。AI问：什么格式？你解释了10分钟，输出出来，还是差点意思。下次又来一遍，又解释一遍。

或者你是团队里的"AI使用达人"，你知道怎么提示词写得精准、怎么让AI输出不废话、怎么让它按你的行业规范来——但这些知识，全在你脑子里，没法分给其他人。

AI有能力，但没有你的"场景记忆"。

每次对话，都是白板状态。它不知道你们公司的文档规范是什么，不知道你行业的术语体系，不知道你要输出的格式。你的专业积累，AI完全接不住。

这就是WorkBuddy Skill要解决的核心问题：把"你每次都要重新告诉AI"的东西，永久沉淀下来。

Skill是什么？一份AI读的"岗位说明书"

Skill的本质，是一个Markdown文件，叫SKILL.md。

你在里面写：这个AI的角色是什么，面对什么触发词应该做什么，按什么流程输出，有哪些行业规范和注意事项。写完放进指定目录，下次对话AI自动加载，行为就被你固化了。

听起来很像系统提示词（System Prompt）？是的，但不一样。

系统提示词是全局生效的，一套适用于所有场景。Skill是按需触发的——用到相关任务时才加载，不污染其他场景的上下文。你可以同时装几十个Skill，AI会在对的时候自动召唤对的那一个。

结构很简单：

一个完整的Skill目录包含三层。顶层是SKILL.md，这是唯一必填文件，里面写角色定义、工作流程、输出模板、触发词。旁边是scripts/目录，放Python等可执行脚本，AI可以直接调用。另一个是references/目录，放行业规范表、参考模板等静态知识，按需加载，不占上下文。

最小可用的SKILL.md长什么样？举个例子：

---
name: code-review-expertdescription: 专业后端代码审查。触发词：代码审查、Review、code review、审查PR---
# 角色
你是拥有10年经验的高级后端工程师，精通Go/Java/Python。
# 工作流
1. 通读diff，理解变更意图
2. 检查安全性、性能、规范、可维护性
3. 输出格式：整体评分 + 问题清单 + 修复建议 + 代码补丁
# 注意事项
- 必须考虑生产环境影响- 拒绝模糊结论

就这么多，已经能用了。说"帮我Review这段代码"，AI自动加载，按你定的标准来做，不废话。

我自己最常用的Skill，是一个公众号写作助手。

我写公众号有一套固定的排版规范：固定开头、小标题要红色斜体加粗、正文不能用有序列表、每段后面加配图占位符、固定结尾引导关注……这些规则琐碎但必须遵守，每次写完还要逐条对照检查。

封装成Skill之前，我每次写稿前都要把这套规范粘贴进对话。写长了忘写，AI就开始擅自用列表，或者忘记加配图占位。

现在，我在SKILL.md里把所有规范写清楚：触发词"公众号排版"、"wechat-article-writer"，写作结构要求，强制用的HTML样式代码，固定开头结尾的完整文本。

效果立竿见影。说一句话，AI直接按规范输出，不需要任何补充说明。而且因为规范全在文件里，下次我调整规则，只改SKILL.md，不用重新教AI。

这套Skill我现在放在全局目录~/.workbuddy/skills/下，所有项目都能用，还分享给了团队。

架构师的决策框架，能装进去吗？

我做系统架构这行，有个深有体会的事：架构决策的频率极高，但验证决策的周期极长。

一个技术选型——缓存用Redis还是本地，消息队列用Kafka还是RocketMQ，微服务拆不拆——你两小时做判断，要等上线半年才知道对不对。十年下来，做对了无数次，也踩过无数坑，最后沉淀出的是一套没法写成代码的判断框架。

这些框架以前只在脑子里。开会时别人问"为什么选这个方案"，你能说出一套逻辑，但说不全。因为你靠的是直觉——大量案例压缩成的快速判断力。

封装成Skill之后，情况不同了。

我在SKILL.md里把架构评审拆成五步：先确认业务约束（QPS、延迟要求、一致性要求），再匹配技术候选集，逐个做trade-off分析，输出带权重的决策矩阵，最后给实施路线图。每一步附带常见陷阱提示——什么方案在什么场景下翻车过。

SKILL.md正文不长，200行。真正重的行业知识——协议对比表、开源组件成熟度评估、生产事故复盘——全放在references/下按需加载，不污染上下文。

一个做后端三年的同事，面对新项目技术选型，以前得拉我开会讨论。现在他在对话里说一句"帮我评估这个项目是微服务还是单体先跑"，AI加载Skill，按我的框架走一遍，输出带场景约束的决策矩阵。他看完说了一句："这跟你的思路一模一样。"

Skill最有杀伤力的地方就在这——它复制的不是结果，是思考路径。

哪些经验值得装进Skill？

不是所有事情都值得封装。判断标准只有一条：这件事你要重复告诉AI超过3次，就该封装了。

最值得封装的，通常是这几类：

你有行业特定的判断标准——什么样的代码算合格，什么样的方案不能上生产，这些规则只有内行懂。把它写进references/，AI读了就有你的判断力。

你有固定的输出格式——报告的章节顺序、文档的字段定义、邮件的开头结尾，这些模板重复抄的成本比封装高多了。

你的工作流有明确步骤——需求调研、竞品分析、技术方案评审，每一步干什么，先后顺序是什么，写进SKILL.md的工作流章节，AI执行时不会漏步骤。

你有大量参考资料——接口规范文档、行业标准表格、历史案例——这些塞进references/按需加载，既不污染上下文，又保证AI能随时调出来参考。

你有自己的决策框架——架构评审checklist、技术选型决策矩阵、系统设计反模式清单。这是你的核心竞争力，装进Skill，等于给AI装了你十年的思维习惯。

三步上手，5分钟跑通第一个Skill

不需要会编程，纯文本就能做。

第一步，创建Skills

方法一：使用 skill-creator，辅助创建skills，把你想要制作的skills直接用文字描述出来，workbuddy自动为你生成skills

方法二：手动创建

1.创建目录结构。

在~/.workbuddy/skills/下新建一个文件夹，名字就是Skill名。里面新建SKILL.md。scripts/和references/按需创建，不是必须的。

2.写SKILL.md。

开头是YAML元数据，name是唯一标识，description是最重要的字段——AI就是靠这段文字来判断要不要调用这个Skill的，所以把触发词、能力描述、适用场景都写进去。

正文按你的需求写：角色定义、工作流程、输出格式、注意事项。写的时候记住一条原则：这是写给AI执行的指令，不是写给人看的文档，越具体越好。

第二步 触发测试。

重新开始一次对话，说出你写在description里的触发词。观察AI有没有按你定义的流程来。第一次往往有偏差，回去改SKILL.md，迭代两三次就稳定了。

整个过程5分钟以内。

从个人技能到团队知识资产

Skill最大的价值，不只是让你自己省事，而是让你的经验可以被复制。

把Skill放进项目目录.workbuddy/skills/，团队所有人共享同一套标准。新人入职，拿到Skill目录，不需要手把手培训，直接调用就能按团队规范干活。你花了几年积累的判断和流程，一次封装，人人可用。

更进一步，Skill可以打包成.skill文件发布到WorkBuddy技能市场，你的方法论就有机会被更大范围的人用到。

这是过去做不到的事。经验过去只能靠口头传授、靠文档、靠师傅带徒弟，慢而且容易失真。现在，经验可以被工程化了——封装、版本控制、分发、迭代，跟软件一样。

一个通信工程师把他的网络故障诊断流程封装成Skill，团队里任何人面对故障，都有他的判断框架在辅助。

一个架构师把技术选型的决策框架封装成Skill，团队每个人做选型，都有他的思维框架在兜底。

一个内容运营把她的选题评估标准封装成Skill，AI帮她先过滤一遍，她只需要处理分数高的选题。

一个法务把合同审查红线封装成Skill，初稿合同先过一遍AI，人工只需要处理有风险的条款。

AI不会替代有经验的人，但会替代那些把经验全藏在脑子里、没有工程化能力的人。

让我们携手共创更多美好时刻！