Agent Skills 到底解决了什么，又没解决什么？
先说结论
Skills不是Prompt的升级版，而是把隐性工作经验变成Agent可执行的固定流程；
好的Skills核心是限制而非赋能，它让Agent在明确边界内稳定输出；
当前公开Skills大多质量堪忧，真正的生产级Skills需要由一线业务人员参与定义。
从Skills热潮退去后的冷静期切入，聚焦它到底解决了Agent“稳定做事”的痛点，同时毫不回避当前Skills集合中大量伪劣品、以及边界固化带来的灵活性损失。
今年初 Skills 这个词在 AI 圈几乎天天见，各种 Marketplace、公开 Skills 合集、Agent 产品都在强调它。但现在回头看，那波热潮里真正沉淀下来的东西其实不多。
很多团队花精力整理 Skills，结果发现大多数公开 Skills 根本没法直接用——要么太笼统，像“请深度思考”这种话，要么太死板，换个场景就翻车。今天再来聊 Skills，不是跟风，而是想把它到底能解决什么、不能解决什么，理清楚。
先说结论：Skills 的价值在于让 Agent 学会稳定做事，而不是变得更聪明。但代价是灵活性下降。这个取舍，不是所有场景都划算。
Skills 热潮为什么没持续下去
年初那段时间，大家觉得 Skills 是 Agent 落地的钥匙。但很快发现，很多公开 Skills 只是把一段 Prompt 包装成新概念。真正能用的，需要大量业务经验去提炼、测试、维护。
一个常见的误区是：以为 Skills 是给 Agent 增加能力。其实它更接近“限制能力”——就像给新员工发一份 SOP，告诉他哪些事必须做、哪些事绝对不能碰。
但问题在于，SOP 需要有人写，而且需要不断迭代。大多数团队没有这个精力。
Skills 到底长什么样：不只 Prompt
一个成熟的 Skills 远不止一段指令。它往往包含五层：
- Instructions：任务规则，比如“先提取关键字段，再进行分类，最后输出表格”。
- Workflow：执行步骤，比如“读取文件 → 校验格式 → 调用API → 生成报告”。
- Templates：输出模板，比如周报格式、PRD 结构、客诉回复框架。
- Scripts：可执行代码，比如 Python 脚本处理 CSV、校验 JSON。
- References：参考资料，比如公司规范、API 文档、风格指南。
这意味着 Skills 已经不仅是 Prompt 工程，它越来越像微型的软件模块。写一个可用的 Skills，成本其实不低。
Skills 的真正价值：给 Agent 画地为牢
为什么需要画地为牢？因为 Agent 在真实业务中最危险的，不是不够聪明，而是不可控。
你希望合同审查 Agent 永远记得检查终止条款、不要自己编法律建议、高风险内容必须留人工确认。这些不是靠模型推理能力能解决的，需要硬性规则。
Skills 就是这些规则的载体。它把业务经验固化下来，让 Agent 每次都按同一套标准执行。
但代价也很明显：规则越细，适应性越差。一个写好的周报 Skills，换一家公司就可能失效。而且维护这些规则的长期成本，经常被低估。
坏的 Skills 比没有更糟糕
现在很多公开 Skills 充满了空话：“请系统化分析”“从战略层面展开”。这类 Skills 除了增加 Token 消耗，对输出质量没什么帮助。
更糟的是，一些 Skills 包含了错误的流程或过时的模板。如果用这类 Skills 辅助生产，反而会引入系统性的错误。
真正好的 Skills 非常具体，甚至会指明哪些情况 Agent 必须拒绝执行、哪些内容禁止生成。这需要实际业务经验，不是写 Prompt 能替代的。
Skills 的方向：从“写得好”到“管得住”
一个容易被忽视的点：Skills 的成功与否，不取决于它写得有多好，而取决于它能不能被长期维护和更新。
业务规则会变，参考文档会更新，输出格式也会调整。如果一个 Skills 半年没人管，它很可能从资产变成负债。
所以，更现实的做法是：先小范围跑几个高重复、低风险的场景（比如周报、日报、客诉分类），验证流程的稳定性，再考虑扩展。
如果按这个方向做，我会优先关注“如何让业务人员能参与定义和更新 Skills”，而不是“如何写出更聪明的 Prompt”。
说到底，Skills 是个管理问题，不是技术问题。
最后留一个讨论点
如果让你选，你愿意用一个100%稳定但无法处理任何意外情况的Skill，还是用一个80%稳定但能灵活应变的通用Prompt？为什么？