Skills热背后的冷思考：AI产品经理如何穿越技术迷雾？

🚀 欢迎来到AI产品经理研习之旅 🚀

各位，好久不见。想必诸位也和我一样，近期被“Skills”这个到处都在讨论、展示的新概念/新实践所刷屏（当然严格来说它是Anthropic在去年10月份所提出的，不算很“新”）。

过去两年，我们经历了不少这样的"新概念时刻"：Workflow、Tools、Context Engineering、Skills……相比于着急或焦虑是不是该立即跟上这波浪潮，我想关键是理解它背后的真实价值。

不知道你是否也有这样的困惑：

• 困惑1：技术概念层出不穷。Tools让你标准化调用，Workflow让你可视化编排，JIT让你动态加载，Skills让你封装知识……看上去都很有道理，但到底该信谁？

• 困惑2：不知道如何选择。A说Workflow+RAG是未来；B说Agent+Skills是方向；C说Context Engineering才是王道。

• 困惑3：害怕错过（FOMO）。担心如果我不跟上，会不会被淘汰？我们不用是不是就落后了？

这些困惑都很真实，但我们不应迷失在技术迷雾中，忘记了探索本质——这些技术演化的背后，到底是什么在驱动？旨在解决什么问题？

依我看来，每个新方法的诞生，都在解决上一个阶段的核心痛点。但同时，每个新方法也引入了新的代价。在当下，也许还没有能解决Agentic 系统所有问题的完美方案。

以Skills为例，我认为它是吸收了JIT（动态加载）、Workflow（工作流）、Tools（标准化工具）的经验教训后的"集大成者"。

但Skills不是银弹。它需要平台支持，需要知识封装能力，需要成熟的生态系统。如果你的场景不匹配，盲目跟风只会带来更高的成本和复杂度。

所以，关键不是"什么是Skills"，而是"我的场景需要什么"。

如果你期待的是一个‘Skills 上手指南’，这篇文章可能会让你失望；
但如果你关心的是：在资源有限、风险真实存在的情况下，如何做出不后悔的 AI 产品决策，那这正是我想讨论的。

读完这篇文章，我希望你能得弄懂它，并为你的企业找到最具性价比的解决方案。

说实话，技术演化的驱动力，根本不是更先进的技术，而是更高效地解决实际问题。

让我们看看这四年里的四个关键演化逻辑：

逻辑1：从不确定性到确定性

✅ 不是技术退步，而是工程进步

逻辑2：从手工到自动化

✅ 不是"偷懒"，而是效率提升

逻辑3：从静态到动态

✅ 不是"更高级"，而是"更高效"

逻辑4：从一次性到可复用

✅ 不是"创新"，而是"沉淀"

现在让我们聊聊Skills。关于Skills本身，我当然更推荐你去阅读Anthropic的工程博客，这里就不展开了。

地址：https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills

skill-name/  SKILL.md        # 元信息 + 高层流程/准则（按需加载）  references/     # 口径、schema、边界条件、例外（按需加载）  scripts/        # 校验/生成/转换/对比等确定性工具（执行但不入上下文）  templates/      # 输出模板（邮件、报告、表单字段映射等）  tests/          # 用例与评测样例（供离线评测/CI）

为什么它值得关注？我认为因为它不是替代，而是吸收。它吸收了：

- 动态加载和渐进式披露 ← 来自JIT（Just-in-time Instructions）和Context Engineering

- 结构化组织 ← 来自Workflow

- 标准化接口 ← 来自Tools

动态加载和渐进式披露本质上是为了解决LLM上下文窗口不足的问题：

我的判断是：Skills代表了未来趋势——可复用的知识/经验封装。但不要盲目跟风，要看你的场景是否需要。

需要强调的是：Workflow、Tools、JIT、Skills 并非简单的‘你死我活’，而是在不同复杂度区间的最优解。

Shopify的Sidekick是一个帮助商家管理店铺的AI助手。在建设过程中，他们遇到了一个经典问题：工具复杂度危机。

🟢 阶段1（0-20 tools）：

"挺好用的，边界清晰，容易调试。"问题还没暴露。

🟡 阶段2（20-50 tools）：

"开始乱套了，工具组合产生意外结果。"调试成本开始上升。

🔴 阶段3（50+ tools）：

"三种方式做同一件事，系统难以推理。"

他们称之为"Death by a Thousand Instructions"——System Prompt变成了臃肿的特殊情况集合。

Shopify的选择是：不是继续增加工具，而是改变提供指令的方式。

他们推出了JIT（Just-in-Time Instructions），核心思路是：

1. Localized guidance：指令只在相关时出现

2. Cache efficiency：动态调整不破坏缓存

3. Modularity：可根据上下文动态提供不同指令

结果呢？系统可维护性提升，性能指标全面改善。他们从加工具转向了优化上下文管理。

Shopify给AI产品经理的三个建议：

1. Stay simple：保持简单，不要为了加工具而加工具

2. Start modular：从一开始就用模块化模式

3. Avoid multi-agent early：早期避免多智能体架构

快速自查：

[ ] 你的工具数量超过20个了吗？

[ ] System Prompt超过10000 tokens了吗？

[ ] 团队开始抱怨"难以调试"了吗？

如果都打勾 → 考虑JIT，但要接受系统复杂度会增加，需要精心设计。

Stripe面临的挑战完全不同。他们的Agent要帮用户花钱——这在AI领域是个大问题。

三重难题：

1. 信任问题：Agent要帮用户花钱，如何确认是用户本人授权？如何防止fraudulent transactions？

2. 碎片化问题：每个Agent都要单独对接吗？成本太高，维护太难

3. 灵活性需求：不仅是"一键购买"，还有"buy for me"后台运行、多商家购物车、订阅、使用模型...

Stripe的选择是：不是自建封闭系统，而是推出开放标准ACP（Agentic Commerce Protocol）。

ACP的三个特点：

1. Built for businesses：保持商家控制权

2. Works with existing systems：兼容支付基础设施

3. Supports complex flows：支持多种交易类型

结果呢？OpenAI ChatGPT的Instant Checkout由Stripe提供支持，Etsy、Shopify（Glossier、Vuori、Spanx、SKIMS）等商家纷纷接入。

给AI产品经理的启示：

[ ] 你的Agent需要跨系统交互吗？

[ ] 你希望避免被单一平台锁定吗？

[ ] 你有能力推动生态建设吗？

如果都打勾 → 考虑开放标准（ACP）。 但需要生态支持，早期可能陷入单打独斗。

Malt（欧洲领先的自由职业者平台）的故事最有趣，因为他们展示了从"炫酷技术"到"实用工具"的完整演化路径。

1: Building In-House

他们一开始自己建：Qdrant（向量数据库）+ Vertex AI（LLM）+ Slack bot。结果呢？频繁幻觉、难以验证、扩展难。

2: Testing Phase

他们采用Dust平台（SaaS）。但真正的突破不是技术，而是让业务团队拥有自己的AI。他们组建了跨职能团队：产品经理+客服+工程师+设计师。

3: Malty AI品牌化

他们创建了logo、宣传视频、甚至AI生成的歌曲。目的是什么？让员工理解这个"新队友"，不是冷冰冰的工具，而是团队成员。

4: AI Workflows

场景：产品反馈流程自动化。技术：Slack + Malty AI + Make。成果：处理150+反馈，强采用率。

5: AI Agents

第一阶段：简单Agent，通过标签请求AI帮助。

成果：L0支持handle time减少80%（2'20" → 20"）

第二阶段：7个专业助手（客户、自由职业者、项目专家...），Make编排，路由问题到合适专家。

Malt的金句>>>

It's not about replacing people, it's about augmenting them with tools tailored to their domain expertise.即不是替代人，而是增强人。

在 Malt，我们采取了一种独特的方法，为每个团队量身定制专属的 AI 助手，以满足其特定需求和工作流程。我们没有采用千篇一律的解决方案，而是为不同的垂直领域（从产品、客户服务到其他特定领域的工作流程）创建了专属的 AI 代理（品牌名称均为 Malty AI）。每个助手都针对特定领域进行专门开发，并深度集成到日常运营中。

给AI产品经理的启示：

[ ] 你是从PoC开始的吗？

[ ] 业务团队能参与配置吗？

[ ] 你做了品牌化吗？

如果都打勾 → 你在正确的路径上。但要接受：需要持续迭代，跨职能协作要求高。

但前提是：必须尊重Sidekick已经形成的三条产品契约:

• 写入必经人确认：Human-in-loop策略要保留并强化，例如表单紫色高亮、资金转移预览、主题编辑需手动保存等已形成用户预期的交互语义

• 上下文输入机制：附件、目标模式、@提及、记忆开关、聊天历史等，因为这些是 agent 获取正确上下文、降低幻觉与误操作的关键“输入管线”

• 工程闭环：JIT +评测 +校验，这些已验证的能力必须保留

有不少人把 Skills 理解成“把提示词存起来复用”。这只对了一半。
我更愿意把 Skills 定义为：

Skills = 能力的最小治理单元
你封装的不只是“怎么做”，还包括：什么时候能做、做到什么程度、怎么证明没做错、出了错怎么回退。

所以一个真正生产级的 Skill，不是只有一段指令，而至少包含五个要素（这是我认为它比Prompt/Workflow/Tools 更“重”的原因）：

1. 能力合同：输入/输出是什么，边界是什么（强结构）

2. 执行剧本：标准流程与对话要点（让推理可预测）

3. 安全护栏：权限、风险分级、写入前必须预览/审批

4. 确定性校验：能用规则/脚本验证的，就别让模型“凭感觉”

5. 评测与回归：真值集与模拟重放，作为发布门禁

• 平台内置 Skills（Shopify 官方维护，最高治理）：折扣、客户分群、ShopifyQL、主题编辑、资金相关等核心流程，强校验、强审计、强回滚语义、强评测门禁

• 生态 Skills（中治理）：通过 app extensions 让第三方应用接入，沙箱/隔离执行、schema 声明、权限明确，尽量“引导用户回到应用完成最终写入”，Sidekick 做好检索与建议

• 用户自定义 Skills（轻治理但可控）：从“提示词快捷键”升级为“受限 skill 包”，允许模板/清单/字段映射，默认禁止自动调用高风险写入工具（至少要显式确认）

这背后的判断很简单：越接近资金/店铺状态这类不可逆写入，治理成本就必须越高。

用户说："给我创建一个学生折扣，六月份九折。"

Step 1 (Level 0 & 1)：Agent的核心提示词和所有技能的元数据被加载。模型通过"折扣"关键词，迅速从几十个技能中匹配到了discount技能。

Step 2 (Level 2)：Agent加载discount技能的SKILL.md文件。它首先学习了文件中的"工作流程"部分，知道了创建折扣需要确认类型、范围、时间等。然后，它注意到了"JIT工具指令"部分，知道了有一个名为create_discount_code的工具可用，但此时并不加载该工具的详细API文档。

Step 3 (执行与交互)：Agent开始与用户对话，确认折扣细节。当所有信息收集完毕，准备调用工具时，它才将create_discount_code工具的详细指令动态注入到上下文中，完成调用。

Step 4 (Level 3)：在调用前，Agent发现工作流程中提到"学生折扣需要特殊验证"。于是，它进一步按需加载了references/student_rules.md文件，学习了验证规则，确保了操作的合规性。

Step 5（Plan + Preview）：Sidekick 先生成“变更计划”，把折扣范围、时间、叠加规则、验证方式等用结构化清单展示，并高亮风险点。
Step 6（Approve → Execute → Undo）：用户点击确认后才写入；执行完成给出结果与“撤销入口”，并记录审计日志，确保可追溯。

• 当前系统最痛的瓶颈在哪里

• 哪些复杂度是“必须承担的”，哪些只是“想象中的先进”

• 我们是在解决问题，还是在缓解焦虑

在我看来，Skills 的真正价值，并不在于它有多“新”，而在于它提醒我们一件事：
当问题足够稳定、足够重复、且值得长期投入时，才配得上被封装、被沉淀、被复用。

如果你只是害怕错过，那不妨慢一点。

希望这篇文章，能帮你在下一次面对“又一个新范式”时，多一分冷静，少一点焦虑。
技术会继续演进，但判断力，才是我们最值得长期投资的能力。

👉 点赞+在看+分享，让我们一起探索更多AI前沿技术和产品实践 🌟

也欢迎你在留言区与我互动。