最近我有一个深刻的体会：
但凡我能想到的事情，都可以用一个Skill来专业解决。
无论是财务规划、AI课程的内容设计、还是交付计划——几乎所有能想到的事情，我都会先创建一个Skill，再让它来执行。
猜猜我现在有多少skill牛马？
效率和质量明显高于自己用脑子手动去做。
目前主要的卡点还是大模型的执行速度。
我用的是Claude Sonnet 4.5，虽然结果已经比较可用和稳定，但等待时间确实让人有些焦虑。
终端+飞书MCP：去掉中间商的工作流
在终端中直接调用Agent的Skill，效率非常高。
所有信息没有中间商——自己的意图直接转化成AI的执行能力。
再配合飞书的MCP：
需要留存的内容 → 转化成文档、多维表格 执行完成后 → 飞书消息通知我结果
这套流程让我很多时候已经不用坐在电脑桌前了（对腰背好太多了）。
拿着手机来回走，边走边给Agent Skill发消息：
"你该干这个，你该干那个"，干完之后飞书汇报。
Skill的管理：没有特别技巧，但有一个规范
有朋友问：Skill多了怎么管理和调度？
其实没有特别的技巧，官方已经把逻辑定义清楚了——
就是name和description，分层次披露。
唯一需要做的是定一个规范：所有Skill都应该在同一个根目录下，
让大模型启动时能够扫描到。
简单，但是有效！
Skill vs MCP：通用与专用的区别
MCP是通用逻辑——
别人做出来操作特定接口，比如抓取新闻、抓取天气，对我们也有用。
Skill的定位是面向专用——
你自己直接使用，定制的个性化信息越多越好。它知道你的工作习惯、你的口头禅、你什么时候会有哪些笔误、你的真实意图倾向……对你了解越深，Skill的能力越强。
结论：不建议收集Skill，对你没用。
解决Skill的可视化短板
Skill在终端环境下运行时，有个明显短板：结果很难可视化呈现，黑窗口的表达效果不好。
我找了两个解决方法：
Markdown转PDF：定制一个专门的Skill，让输出先有Markdown版本，再转成PDF供检查阅读 HTML网页呈现：在服务器上开放8080端口，让内容直接在网页中呈现，自己和合作伙伴都能直接查看
团队协作：大脑的实时共享
我现在的做法是：在服务器上开出多个子账号，每人一个AI服务器子账号，Skill之间实现互联互通。
比如我创建最新的Skill，调试好之后，直接让AI一键复制到其他人的目录下。
这相当于我的大脑实时与团队共享互联——
不存在"我学会一件事情再教你"，而是我学会之后，你也具备了这个知识包，直接加载到你的工作环境中。
我们团队都用手机通过Terminus连通服务器，干活可以直接跳过电脑，全部"脑机接口式"工作。
AI调用AI：很多Skill不是给人用的
挂到服务器上的底层逻辑是：
很多AI Skill不是给人用的，而是被其他AI调用的。
比如前端设计这个Skill，人用它干啥呢？
这是AI自己干完活之后，为了汇报工作去调用的。还有一些你根本不用关注是什么，只是AI之间协同的模块
——它们互相知道该怎么干活就行，人只看结果。
从"背手册"到"翻手册"的范式转变
官方有个特别好的比喻：
以前的提示词工程：让AI当医生，把整个医疗手册全塞给它，让它试图背下来。背不下来的用RAG撞运气找资源。
现在Skill的方式：
你面对的是一个全科医生，但他有手册。你挂儿科，他翻儿科手册；
你挂内科，他翻内科手册。
看了检查单后，发现需要补充什么知识，再一层层去挖。
这个流程又跟工作流不一样，它是柔性定制的。
遇到手册里没有的东西，AI会自己决策：是不是可以上网搜索？找最官方的技术材料？用外部知识库补足内部知识库的不足。
内部文档和SOP是兜底的，外部知识决定上限。
写在最后：上下文的力量
很多时候推动事情是需要上下文的。比如为什么我愿意在特定的群里分享？因为大家都是一个圈子的，说话有共鸣，能拿到正反馈。
对AI也是一样——
你让它越了解你，给你的回复越有针对性，工作就越容易推进。
这就是我今天的几点总结。
AI时代的效率革命，核心不是AI有多强，而是你愿意让它多了解你。
