会话一长，AI 就忘了你教过的东西——这才是 skill 和 MCP 真正的意义
先交代一下我是个什么样的人：我对 AI 的各种新概念，一向很排斥。
我不跟着自媒体追名词。今天一个 prompt 工程，明天一个什么 agent 范式，后天又是某某 skill 模版——我基本不看。我做事的方式一直是反过来的：先撞到一个具体问题，再去找能解决它的东西。 概念是不是热门、有没有人在吹，我不关心。
所以这一篇对我来说有点特别。它不是我学来的，是我被逼出来的。
这一周，我重度用一个 AI agent 帮我做一件步骤多、容易出错、需要它一步步替我操作的活。我被它折磨到连续一周对着屏幕破口大骂——骂的核心就一句：你他妈为什么不会复用上次已经搞定的东西。 骂到最后，我第一次心甘情愿地去接了开源项目的官方 MCP，自己动手做了 skill。不是谁安利的，是疼出来的。
下面是我疼明白的东西。不管你写代码、做设计还是做科研，只要你认真用 AI 干活，应该都用得上。
真正的问题，不是"换个对话它就忘了"
"AI 没有记忆，换个新对话之前说的就全没了"——这是常识，谁都知道，不值得拿出来讲。
真正折磨人的，是一件更隐蔽的事：
在同一个对话里，聊久了，它也会忘。
AI 能"看到"的内容是有上限的（业内叫上下文窗口）。一段对话里，你说过的每句话、它做过的每件事、你们一起调通的每个方法，都在抢这块有限的空间。对话越长，越早的内容就越容易被挤出去、被压缩、被稀释——它对你半小时前确立的那个做法的"印象"，会一点点变淡，直到等于没有。
于是你会看到这种怪事：明明这个对话的前半段，某个方法已经验证可行了；聊到后半段，它又像没见过一样，重新开始瞎试。
我这一周反复撞这堵墙：
- 同一个会话里，前面已经跑通的连接方式，后面它又从头研究怎么连；
- 一个操作失败了，它不去想原因，而是闷头换七八种写法挨个试，全错——后来发现根因很简单，是目标早就变了，它一直对着一个不存在的旧目标反复点；
- 为了"看一眼当前状态"，它一次又一次现写新脚本、研究新工具，原问题没解决，反而引出一堆它自己造的新问题。
想通这一层，会得出一个让人不太舒服、但极其重要的结论：
你在对话里辛辛苦苦调出来的一切——精心打磨的提示词、好不容易跑通的方法——都活在那块会被冲掉的上下文里。它们是沙子，不是资产。
潮水一来（对话变长、上下文被压缩），全没了。
解法：把"有效的东西"搬到对话之外
既然活在对话里的东西保不住，那答案就很清楚了：
把真正有效的东西，搬到对话之外，做成 agent 能反复调用、不随上下文消失的资产。
这正是 skill 和 MCP 这两个词真正的意义所在。我以前一直觉得它们是自媒体黑话，绕着走；这周才发现，它们解决的就是上面这个把我逼疯的具体问题。
一句话先记住：
- skill，是让 agent "知道该怎么做"——把你的经验沉淀成它能随时调取的知识与流程；
- MCP，是让 agent "够得着你的东西"——给它一扇稳定的门，直接读你的数据、用你的工具、看真实状态。
下面分开说。
skill：你的"操作手册"，而且它本来就不该是通用的
很多人一听 skill 就联想到："我准备了一套提示词，开头写'你是某某领域的资深专家，请帮我……'"。
那种东西，基本是空的。它只是一件戏服，谁都能套，里面没有任何只属于你的经验。
真正的 skill，是一份你维护的操作手册。 它至少装四样东西：
- 固定入口：这件事该用哪个文件、哪个模板、哪套流程。"截图用这个程序、查数据走这个口、风格参考这个文件。"
- 验证过的做法：上次什么方法成功了，写下来，要求它复用，而不是每次重新发明。
- 踩过的坑 + 兜底：上次哪里出过错、根因是什么、再遇到怎么处理。
- 红线：哪些操作绝不能自己做，必须停下来问人。
它为什么有用？因为它不在对话里，而在对话之外。需要时才被加载进来，所以哪怕你们已经聊了很久、上下文换了好几茬，那条验证过的做法依然能被原样调回——它不会被潮水冲走。
但我这周做着做着，意识到一件更重要、也更反主流的事：
skill 根本不是一种"通用技术能力"，它极其个人化。
它绑死在你这个具体项目、你这套具体做法、你踩过的那些具体的坑上。换到另一个项目，它就不灵了；当成"标准工作流"原样交给另一个人，照样跑不动。它压根不是那种能下载下来直接套用的模版工具。
这也是为什么市面上那些"我整理了一套万能 skill"基本没用——不是因为作者藏私，而是skill 里真正值钱的部分，天生就不可转让。 一旦把它抽象成谁都能用的通用模版，那点最关键的、属于你项目的经验就被抽干了，剩下的就是一件空戏服。
所以别去找别人的 skill 抄。这东西的价值，恰恰在于它是你自己一次次踩出来、攒出来的。换个领域同理：
- 做科研：一份你自己的文献处理手册——你要的格式、你的方法、你归类时栽过的跟头；
- 做设计：一份你自己的风格手册——验证过的方向、明确的禁忌、上次让它跑偏的那个词；
- 写代码：一份你这个项目的规则文件——已知可用的配置、你这套代码里修某类问题的固定套路、绝不能碰的红线。
每更新一次，agent 下次就少犯一次同样的错。它会增值，越用越厚，越厚越省心——但它只对你、对这个项目增值。
MCP：给 agent 一扇"永久的门"，而不是每次现搭桥
如果说 skill 解决"它知不知道怎么做"，那 MCP 解决的是另一半：它够不够得着你的东西。
我这周最大的内耗之一，就是 agent 为了访问一个东西，每次都现写一个一次性的、脆弱的脚本：这次写一套截图的、下次写一套查状态的，脚本不稳就再研究一套新工具链。它在反复"搭临时的桥"，桥还经常塌。
MCP（可以理解成一种标准化的、稳定的连接方式）做的事，就是把这座桥固定下来，变成一扇永久的门。有了它，agent 能直接读你的数据、调你的工具、看到真实状态，而不是每次临场现搭、用完即弃。
我这次也是头一回真的去接了开源项目提供的官方 MCP——以前我对这种"又一个新接口"是本能抗拒的，接完才承认它确实把"每次重造接入"变成了"一次建好、长期复用"。
换成你的领域：
- 做科研：与其一篇篇往对话里粘论文，不如让 agent 通过一个固定连接，直接查你的文献库；
- 做设计：让它直接读你的设计系统、组件库，拿到真实规范，而不是凭感觉猜；
- 写代码：让它直接看仓库、数据库、页面的真实状态，而不是写一堆一次性脚本去间接窥探。
所以 skill 和 MCP 是一对：skill 让它知道该做什么，MCP 让它真的能去做。 缺一个都不行——光有手册却够不着东西没用，够得着东西却没章法照样乱来。
也得泼一句冷水：MCP 不是魔法。它不替你想业务逻辑，不保证对象不变，也不会自动判断什么时候该停下来问人。它的价值很朴素——把接入这件事，从"每次重造"变成"一次建好、长期复用"。
落地时，顺手把这几条规矩写进你的 skill
把资产建起来的同时，有几条行为规则也值得固化进手册，让 agent 每次自动遵守，而不是你每次口头交代（口头交代也会被上下文冲走）：
- 一步一汇报：一次只做一步，做完就说结果，等你反馈再继续。别让它闷头干十件事，错了你都不知道错在哪一步。
- 失败先给原因：失败时先说它判断的根本原因，不要直接换方法。先诊断、再下手，能省掉大半无效折腾。
- 强制复用：凡是已有验证过的做法，明确点名让它用，别让它另起炉灶——它默认倾向于"生成一个新方案"，而不是"翻你已有的旧方案"。
- 长操作透明：可能等很久的操作，先说在等什么、卡在哪。不接受沉默的黑盒。
- 关键动作确认：越不可逆的操作（付钱、发送、删除、提交、覆盖），越要留一道"等我点头"的关口。
这些写进 skill，就成了 agent 稳定的行为底座；留在对话里，就是随时会蒸发的口头约定。
最后
我还是不会去追那些 AI 新概念。下次再有什么名词火起来，我大概率还是绕着走。
但这次我服了。不是服了"skill""MCP"这两个词，而是服了它们背后那个被我亲手撞出来、骂了一整周的问题：AI 在一段长对话里，根本守不住你教过它的东西。
想通这个问题之后，skill 和 MCP 对我才不再是黑话，而是答案——把经验和接入搬到对话之外，做成我这个项目、我这个 agent 真正拥有、且只属于它的技术资产，让它下一次、下一百次都不必从零开始，也不会聊到一半就把好不容易调通的东西忘掉。
我没有变成某个工具的专家。我只是终于知道，该怎么给自己的 AI 队友，建一套它能一直带在身上的家当。
这是被折磨一周之后，我唯一真正想明白、也真正愿意传出去的东西。
