当所有人都在蒸馏「同事.skill」，我想聊剩下的 90%

当所有人都在蒸馏「同事.skill」，我想聊剩下的 90% 当所有人都在蒸馏「同事.skill」，我想聊剩下的 90% Modified April 10 🔧 模式一 · 领域变体（Domain Variant） 当一个 Skill 要支持多个技术栈时，不要把所有情况都塞进 SKILL.md。用 references/ 分离变体逻辑： Code block Plain Text Copy cloud deploy/├── SKILL.md 通用工作流 + 选择逻辑└── references/├── aws.md├── gcp.md└── azure.md Claude 只读它需要的那一份。 🔧 模式二 · 脚本捆绑（Script Bundling） 关键信号 ：如果 Claude 每次都独立写几乎一样的辅助脚本——那就是该把这个脚本固化到 scripts/ 里的信号。写一次，所有调用复用。 Claude 不该重复发明轮子。 🔧 模式三 · 模板驱动（Template Driven） 对于有固定输出格式的任务（报告、邮件、code review），在 SKILL.md 里定义精确模板。 这是最常见、最实用、见效最快的模式。新手从这个开始做就对了。 🔧 模式四 · 渐进引用（Progressive Reference） 大型参考文档不要塞进 SKILL.md。放进 references/，附一张目录导航： 需要 API 细节时，读取 references/api spec.md（700 行）。结构：§1 认证（1 50 行）· §2 端点列表（51 200 行）…… 先确定需要哪个部分，只读相关段落。 这让 Claude 学会像翻书一样读文档，而不是一次性啃完。 🔧 模式五 · 认知函数（Cognitive Function） 这是最强大、也最难写的模式。当 Skill 的核心是 思维方式 而不是操作步骤时： Code block Plain Text Copy 你的思考遵循第一性原理：1. 收到命题 → 分解到原子级假设2. 逐个测试假设（已验证 / 已证伪 / 未测试）3. 从验证过的地基重建4. 识别二阶、三阶后果 这类 Skill 定义的不是"做什么"，而是"如何思考"。 它们的价值密度远高于操作型 Skill。 给 Agent 装一个处理 PDF Skill，只在处理 PDF 时有用。装一个第一性原理 Skill，在做任何决策时都会变得更清醒。 07 官方没告诉你的：当你有 200+ Skill 时 Anthropic 的官方文档，默认场景是一个用户装十几个 Skill。一切都很美好。 但当你把规模放大到 200+（比如在多 Agent 系统中每个 Agent 需要不同的 Skill 子集），你会遇到三个 官方文档一个字都没讲 的问题。 💥 坑 1 · 触发精度断崖式下降 超过大约 80 个 Skill 后，description 之间的语义开始互相干扰。两个 Skill 都提到"文档处理"，模型就开始在它们之间犹豫、误触发、甚至互相取消。 解法 ：分层可见性。对于企业级架构而言，这本质上就是 基于角色的能力权限管控模型（RBAC for Agent Skills） 。按角色 / 域 / 任务类型进行硬过滤——每个 Agent 的权限组应限制在 40 60 个它真正需要的 Skill 域内。 Code block Plain Text Copy ✓ 好的命名：包含差异化关键词 name: cloud deploy aws ec2description: Deploy containerized apps to AWS EC2 with auto scaling groups ✗ 差的命名：语义重叠 name: cloud deploydescription: Deploy to cloud providers 一个让这件事具体化的实战 ：把系统里 79 个 portable Skill 一个个 mapping 到不同核心业务域 × 8 个能力大类（数据抽取 / 研究情报 / 代码生成 / 测试安全 / 运维发布 / 自动化 / 协作 / 元工作）。借鉴的是 Anthropic 自己的 cybersecurity skills 思路——他们把上百个 skill mapping 到 MITRE ATT&CK 标准分类法。 核心洞察 ：大型 Skill 库必须有 外部权威分类法 作为坐标系，不能只用扁平 tag，否则就是几百个 skill 在一个目录里互相干扰。 mapping 完成后，立刻浮现几个能力空白点：文本处理 + 基础代码生成 2 个域反而 over staffed，加起来占了 43%——这是受限于旧有打杂场景的历史路径依赖，不是真实需求分布。而深度核查与架构级治理域的专属 Skill 却严重缺失。这就是 分层可见性的真实落地 ——它帮你识别能力盲区并防止不同域的 Skill 互相干扰。 💥 坑 2 · 同一个 Skill，不同 Agent 行为完全不同 一个 calendar ops Skill： · 在 PMO Agent 手里 → 里程碑调度、会议筹备、阻断非计划内的上下文切换· 在 QA Agent 手里 → 测试排期、资源审计、发布节奏优化· 在 DevOps Agent 手里 → 环境协调、定时任务触发与业务同步 同一段 SKILL.md，完全不同的使用哲学。 但 Anthropic 的架构假设一个 Skill 对所有 Agent 行为一致。这个假设在多 Agent 系统中不成立。 更优雅的解法是 Skill 参数化 ： Code block Plain Text Copy name: calendar opsparameters: mode: type: enum values: [scheduling, audit, family] default: scheduling 💥 坑 3 · Skill 之间的隐藏依赖会炸 当一个 Skill 在执行时需要调用其他 Skill 的能力，就形成了依赖链。但 Anthropic 没有定义 Skill 间的依赖声明机制。你现在只能在 SKILL.md 正文里用自然语言写"完成后参考 X Skill 的 Schema"——这是 脆弱的 。重命名或删除一个 Skill，不会触发任何依赖检查。 建议方案 ：在 YAML 前言中显式声明依赖。当规模突破百级，成熟的技术团队必须开始强硬践行 Skill as Code (SaC) 的治理理念——即将 SKILL.md 视同常规的后端微服务代码，全部纳入 GitOps 版本控制。 Code block Plain Text Copy name: prd to issuesdependencies: name: write a prd version: "^1.0.0" required: true name: slack notify required: false fallback: "skip notification, log to console" 08 让 Skill 自己进化 讲完规模化的坑，这里还需要抛出一个更前沿的问题： Skill 应该是写完就冻结的静态文件，还是能基于使用数据自我迭代的活物？ 去年圈内有研究者把 Karpathy 的 autoresearch 思路迁移到 Claude Skills，用强化学习让 Skill 自己优化自己——一份流传的实验数据是：一个落地页文案 Skill 的通过率从约 56% 提升到约 92% 。当时这件事还是 hypothetical 的方向。 今天（2026 年 4 月）这套闭环已经在实际系统中跑通 。 在这个以构建者为中心的个人操作系统中有一个叫 Project Crucible（熔炉） 的子项目，由负责"成长 / 学习"那个域的 agent 维护，正在做的事完全是闭环图的真实落地。（关于自我进化的安全边界控制理念，特此致敬 EvoMap 项目的启发。） Code block Plain Text Copy PROJECT CRUCIBLE · 自优化闭环 Phase 1 · Baseline 收集（14 天 CQS 基线） Phase 2 · Hypothesis 生成（4 类） – model swap（换底模） – fallback reorder（换 fallback 顺序） – threshold adjust（调阈值） – skill tune（改 Skill 内容）Phase 3 · Shadow 部署（双 agent A/B）Phase 4 · LLM Judge 打分（CQS delta）Phase 5 · 通过则 promote，否则 discardPhase 6 · 写入 capsule（审计追溯） 几个关键设计点 ① 评分机制叫 CQS（Character Quality Score） ——不要让 Agent 随意盲改。 输入：角色定义 + 测试 prompt + 实际响应5 个维度各打 0 10 分：角色一致性 · 任务完成度 · 信息准确性 · 边界意识 · 表达清晰度CQS = 五维平均分进化决策看 CQS delta：Δ +0.5 → promote，否则 discard ② 4 类 hypothesis 各自有风险等级 ：TRIVIAL / MINOR / MAJOR。不同风险走不同的 gate——TRIVIAL 直接 shadow 跑，MAJOR 必须人工审。 Skill tune 类默认是 MINOR ，因为 Skill 的 blast radius 通常小于换底模。 ③ 不同的核心业务域都需要建立自己独立的 test prompts ——研发侧 / 运营侧 / 财务侧 / 架构侧各 1 组，让变体在它实际服务的域上被验证，而不是跑在统一的抽象 benchmark 上。 ④ Shadow 部署 + Capsule 留底 ——hypothesis 跑在影子 session 里，不影响生产。每个 promoted 的改动都进 capsule，含 before snapshot，任何时候可回滚。 Skill 进化的本质，就是一个用真实数据喂养的认知飞轮（Data driven Cognitive Flywheel）。这是企业形成长期资产复利、碾压纯调包玩家的根本结构。 Skill 不必是一次性写出来的产物。它可以有自己的生命周期，像模型一样被持续训练。 对写 Skill 的人来说，这意味着一个范式转移： PAST 一次性把 Skill 写到 90 分，上线。 NOW 先写一个 60 分的 Skill 上线，让系统跑一周、收集失败样本，然后让它自己迭代到 92 分。 区别在于 你再也不需要凭想象去预测用户会怎么用这个 Skill——真实使用数据会直接告诉你答案 。 当然，这条路有两个硬门槛你得先解决： 1. 失败信号要可被识别 ——没有自动化评分机制，进化链跑不起来2. 变体要能被隔离测试 ——不能在生产环境直接上新版本 预测： 未来 12 个月内，skill creator 这类工具会内建进化管道，把这一整套闭环默认打开。手写 SKILL.md 的时代正在结束， SKILL 自己写 SKILL 的时代正在开始 。 09 一句话带走的结论 Skills 的本质是什么？把它拆到原子级： Skill 是一种可复用、可测试、可分发的 Agent 认知模块。 但这个定义还缺一层。在实践中，Skills 不只是能力——它们是 Agent 认知架构的组成部分 。 🔧 模式一 · 领域变体（Domain Variant） 当一个 Skill 要支持多个技术栈时，不要把所有情况都塞进 SKILL.md。用 references/ 分离变体逻辑： Claude 只读它需要的那一份。 🔧 模式二 · 脚本捆绑（Script Bundling） 关键信号 ：如果 Claude 每次都独立写几乎一样的辅助脚本——那就是该把这个脚本固化到 scripts/ 里的信号。写一次，所有调用复用。 Claude 不该重复发明轮子。 🔧 模式三 · 模板驱动（Template Driven） 对于有固定输出格式的任务（报告、邮件、code review），在 SKILL.md 里定义精确模板。 这是最常见、最实用、见效最快的模式。新手从这个开始做就对了。 🔧 模式四 · 渐进引用（Progressive Reference） 大型参考文档不要塞进 SKILL.md。放进 references/，附一张目录导航： 需要 API 细节时，读取 references/api spec.md（700 行）。结构：§1 认证（1 50 行）· §2 端点列表（51 200 行）…… 先确定需要哪个部分，只读相关段落。 这让 Claude 学会像翻书一样读文档，而不是一次性啃完。 🔧 模式五 · 认知函数（Cognitive Function） 这是最强大、也最难写的模式。当 Skill 的核心是 思维方式 而不是操作步骤时： 这类 Skill 定义的不是"做什么"，而是"如何思考"。 它们的价值密度远高于操作型 Skill。 给 Agent 装一个处理 PDF Skill，只在处理 PDF 时有用。装一个第一性原理 Skill，在做任何决策时都会变得更清醒。 07 官方没告诉你的：当你有 200+ Skill 时 Anthropic 的官方文档，默认场景是一个用户装十几个 Skill。一切都很美好。 但当你把规模放大到 200+（比如在多 Agent 系统中每个 Agent 需要不同的 Skill 子集），你会遇到三个 官方文档一个字都没讲 的问题。 💥 坑 1 · 触发精度断崖式下降 超过大约 80 个 Skill 后，description 之间的语义开始互相干扰。两个 Skill 都提到"文档处理"，模型就开始在它们之间犹豫、误触发、甚至互相取消。 解法 ：分层可见性。对于企业级架构而言，这本质上就是 基于角色的能力权限管控模型（RBAC for Agent Skills） 。按角色 / 域 / 任务类型进行硬过滤——每个 Agent 的权限组应限制在 40 60 个它真正需要的 Skill 域内。 一个让这件事具体化的实战 ：把系统里 79 个 portable Skill 一个个 mapping 到不同核心业务域 × 8 个能力大类（数据抽取 / 研究情报 / 代码生成 / 测试安全 / 运维发布 / 自动化 / 协作 / 元工作）。借鉴的是 Anthropic 自己的 cybersecurity skills 思路——他们把上百个 skill mapping 到 MITRE ATT&CK 标准分类法。 核心洞察 ：大型 Skill 库必须有 外部权威分类法 作为坐标系，不能只用扁平 tag，否则就是几百个 skill 在一个目录里互相干扰。 mapping 完成后，立刻浮现几个能力空白点：文本处理 + 基础代码生成 2 个域反而 over staffed，加起来占了 43%——这是受限于旧有打杂场景的历史路径依赖，不是真实需求分布。而深度核查与架构级治理域的专属 Skill 却严重缺失。这就是 分层可见性的真实落地 ——它帮你识别能力盲区并防止不同域的 Skill 互相干扰。 💥 坑 2 · 同一个 Skill，不同 Agent 行为完全不同 一个 calendar ops Skill： · 在 PMO Agent 手里 → 里程碑调度、会议筹备、阻断非计划内的上下文切换· 在 QA Agent 手里 → 测试排期、资源审计、发布节奏优化· 在 DevOps Agent 手里 → 环境协调、定时任务触发与业务同步 同一段 SKILL.md，完全不同的使用哲学。 但 Anthropic 的架构假设一个 Skill 对所有 Agent 行为一致。这个假设在多 Agent 系统中不成立。 更优雅的解法是 Skill 参数化 ： 💥 坑 3 · Skill 之间的隐藏依赖会炸 当一个 Skill 在执行时需要调用其他 Skill 的能力，就形成了依赖链。但 Anthropic 没有定义 Skill 间的依赖声明机制。你现在只能在 SKILL.md 正文里用自然语言写"完成后参考 X Skill 的 Schema"——这是 脆弱的 。重命名或删除一个 Skill，不会触发任何依赖检查。 建议方案 ：在 YAML 前言中显式声明依赖。当规模突破百级，成熟的技术团队必须开始强硬践行 Skill as Code (SaC) 的治理理念——即将 SKILL.md 视同常规的后端微服务代码，全部纳入 GitOps 版本控制。 08 让 Skill 自己进化 讲完规模化的坑，这里还需要抛出一个更前沿的问题： Skill 应该是写完就冻结的静态文件，还是能基于使用数据自我迭代的活物？ 去年圈内有研究者把 Karpathy 的 autoresearch 思路迁移到 Claude Skills，用强化学习让 Skill 自己优化自己——一份流传的实验数据是：一个落地页文案 Skill 的通过率从约 56% 提升到约 92% 。当时这件事还是 hypothetical 的方向。 今天（2026 年 4 月）这套闭环已经在实际系统中跑通 。 在这个以构建者为中心的个人操作系统中有一个叫 Project Crucible（熔炉） 的子项目，由负责"成长 / 学习"那个域的 agent 维护，正在做的事完全是闭环图的真实落地。（关于自我进化的安全边界控制理念，特此致敬 EvoMap 项目的启发。） 几个关键设计点 ① 评分机制叫 CQS（Character Quality Score） ——不要让 Agent 随意盲改。 输入：角色定义 + 测试 prompt + 实际响应5 个维度各打 0 10 分：角色一致性 · 任务完成度 · 信息准确性 · 边界意识 · 表达清晰度CQS = 五维平均分进化决策看 CQS delta：Δ +0.5 → promote，否则 discard ② 4 类 hypothesis 各自有风险等级 ：TRIVIAL / MINOR / MAJOR。不同风险走不同的 gate——TRIVIAL 直接 shadow 跑，MAJOR 必须人工审。 Skill tune 类默认是 MINOR ，因为 Skill 的 blast radius 通常小于换底模。 ③ 不同的核心业务域都需要建立自己独立的 test prompts ——研发侧 / 运营侧 / 财务侧 / 架构侧各 1 组，让变体在它实际服务的域上被验证，而不是跑在统一的抽象 benchmark 上。 ④ Shadow 部署 + Capsule 留底 ——hypothesis 跑在影子 session 里，不影响生产。每个 promoted 的改动都进 capsule，含 before snapshot，任何时候可回滚。 Skill 进化的本质，就是一个用真实数据喂养的认知飞轮（Data driven Cognitive Flywheel）。这是企业形成长期资产复利、碾压纯调包玩家的根本结构。 Skill 不必是一次性写出来的产物。它可以有自己的生命周期，像模型一样被持续训练。 对写 Skill 的人来说，这意味着一个范式转移： PAST 一次性把 Skill 写到 90 分，上线。 NOW 先写一个 60 分的 Skill 上线，让系统跑一周、收集失败样本，然后让它自己迭代到 92 分。 区别在于 你再也不需要凭想象去预测用户会怎么用这个 Skill——真实使用数据会直接告诉你答案 。 当然，这条路有两个硬门槛你得先解决： 1. 失败信号要可被识别 ——没有自动化评分机制，进化链跑不起来2. 变体要能被隔离测试 ——不能在生产环境直接上新版本 预测： 未来 12 个月内，skill creator 这类工具会内建进化管道，把这一整套闭环默认打开。手写 SKILL.md 的时代正在结束， SKILL 自己写 SKILL 的时代正在开始 。 09 一句话带走的结论 Skills 的本质是什么？把它拆到原子级： Skill 是一种可复用、可测试、可分发的 Agent 认知模块。 但这个定义还缺一层。在实践中，Skills 不只是能力——它们是 Agent 认知架构的组成部分 。 当你设计一套 Skill 体系时，你不只是在定义 Agent 能做什么。你在定义它如何理解世界、如何做出判断、如何从经验中学习。这就是为什么认知函数型 Skill 的价值密度，永远高于操作型 Skill。 操作型 Skill 教 Agent 完成一件事。认知型 Skill 改变 Agent 完成所有事的方式。 🍵 结语 做 Agent 这件事，真正难的从来不是敲下那行代码。 难的是想清楚：你究竟在设计一个外挂工具、一个独立员工、还是一个拥有自己世界观的认知体？ 答案不同，架构就完全不同。 📚 参考资料 官方与标准 · Anthropic Skills 官方文档（platform.claude.com/docs）· Anthropic Skills 参考实现（github.com/anthropics/skills）· agentskills.io — Anthropic 主导的 Skill 开放标准· agentskills 规范 repo（github.com/agentskills/agentskills） platform.claude.com/docs github.com/anthropics/skills github.com/agentskills/agentskills 已采用 agentskills.io 的客户端 Claude Code · Cursor · Goose (Block) · Letta · OpenHands · Junie (JetBrains) · Gemini CLI · OpenAI Codex · GitHub Copilot · VS Code · Roo Code · Amp · Mux · Trae (字节) · hermes agent · Firebender · Autohand · Spring AI ……完整名单见 agentskills.io 相关项目与扩展参考 · Karpathy autoresearch — 自动化科研迭代讨论· EvoMap — 向导式进化的前沿探索· Letta — stateful agent platform· DSPy (Stanford NLP) — programmatic prompt optimization· wondelai/skills — 43 个 portable 商业书籍 skill· MITRE ATT&CK — 外部权威分类法参考案例· hermes agent (NousResearch) — 已内置 643 skill 🔗 原文链接： https://mp.weixin.qq.com/s/YW3uEYqt... https://mp.weixin.qq.com/s/YW3uEYqt... 原创 延君晨 延君晨 君晨不器2026年4月10日 00:19 美国 Prompt 是用完即走的消耗品，而 Skill 沉淀的是可规模化复用的认知资产。它不是外挂玩具，是这一轮 Agent 落地的 关键基础设施 。 00 破圈热潮背后的冷思考 最近两周，从「同事.skill」开始，各种诸如乔布斯、老板、前任甚至赛博算命的蒸馏人格系列铺天盖地。Skill 这概念第一次真正破圈。 让几十万人感受到原来 AI 能力可以这样打包，这本身极具价值。 但剥开表象会发现一个现象 ：这波热潮里的绝大多数项目，仅仅发挥了 Skill 10% 的能力——本质上只是把一段角色 Prompt 存成了文件。 至于渐进式加载、跨 Skill 依赖、引用机制、工程 eval 体系……极少有人触及。 本文不是教你做「同事.skill」那种角色扮演玩具。 如果你想把 Skill 做成 持续运转的系统 ——像搭乐高一样拼装 Agent 的能力边界，这篇文章正是为你准备的。 本文不是教你做「同事.skill」那种角色扮演玩具。 如果你想把 Skill 做成 持续运转的系统 ——像搭乐高一样拼装 Agent 的能力边界，这篇文章正是为你准备的。 核心导览 ① 关键洞察：不是所有能力都应该做成 Skill ② Skill 的底层工程价值：渐进加载、测试体系、跨客户端标准 ③ 200+ Skill 时的规模化崩塌（官方文档没讲的 3 个坑） ④ 让 Skill 自己进化的强化学习闭环 01 先说一个打破惯性认知的瞬间 当 OpenClaw 撕开了 Agent 新形态的口子之后，这里也曾构建过一个多 Agent 协作系统来处理实际的复杂工作流。在这个系统里，每个 Agent 都装了一个叫 self compass 的自我能力边界评估工具——本意是让 Agent 学会"知道自己不知道什么"。 跑了两周后暴露出了一个问题： 这个工具，Agent 几乎从不主动调用。 它只有在被明确提示"评估一下你自己的边界"时才会用。平时它该冒进就冒进，该胡说就胡说。即便强行装配了一把好刀，但它从不记得从刀鞘里拔出来。 后来将那 300 tokens 的工具描述 整个删掉 ，把同样的内容改写成 Agent 行为准则里的 3 行认知指令。效果立刻变好。 这件事揭示了全文最核心的事实 Skill 不是工具。它是认知架构的一部分。 02 Skill 和 Prompt 模板，到底有啥不一样？ 如果你只是偶尔让 Claude 帮你写一封邮件、翻一篇稿子，prompt 模板就够了。复制粘贴，走人。 但如果你在构建 持续运行的 AI 工作流 ——比如： · 每周自动生成一份 OKR 复盘· 每次提交代码前自动做一轮 review· 管理一组分工协作的 Agent 团队 你需要的就不再是 prompt 模板，而是 Skill。它们的区别可以用一个直观的类比： Prompt 模板 像是你给实习生的便签——每次都得重新贴一遍。 Skill 像是你给员工的员工手册——写一次，他在合适的场景自动翻开相关那页。 Prompt 模板 像是你给实习生的便签——每次都得重新贴一遍。 Skill 像是你给员工的员工手册——写一次，他在合适的场景自动翻开相关那页。 更准确地说，Skill 是 可复用、可测试、可分发的 Agent 认知模块 。它不是每次手动注入，而是成为 Claude 认知环境的一部分， 按需被激活 。 03 不是所有能力都应该做成 Skill 刚才那个 self compass 的例子说明了一个更深的问题。大部分人的本能反应是：希望能让 Agent 具备 X 能力——那就做一个 Skill 吧。 但 有些能力不适合做工具 。它们更适合作为 Agent 的 内化认知指令 。一个判断标准： 一个人类在这个角色上，会使用专门的工具，还是运用自己的专业判断？ 能力 Skill 认知指令 调用 API ✓ — 处理 PDF ✓ — 知道自己不知道什么 — ✓ 元认知 知道什么时候该让权 — ✓ 自知边界 用第一性原理思考 — ✓ 思维模式 能力 能力 Skill Skill 认知指令 认知指令 调用 API 调用 API ✓ ✓ — — 处理 PDF 处理 PDF ✓ ✓ — — 知道自己不知道什么 知道自己不知道什么 — — ✓ 元认知 ✓ 元认知 知道什么时候该让权 知道什么时候该让权 — — ✓ 自知边界 ✓ 自知边界 用第一性原理思考 用第一性原理思考 — — ✓ 思维模式 ✓ 思维模式 为什么要这么区分？ 作为 Skill 的两个硬伤 · 占上下文：description 常驻吃预算· 可以被跳过：除非被提示，否则不会主动调用 作为内化指令的两个优势 · 零额外开销：长在 Agent 行为准则里· 不可跳过：每次思考都自动受其影响 这就是为什么删掉这类元认知 Skill 之后，效果反而更好。 它们从需要主动调用的工具，变成了永远在线的默认思考模式。 ⚠️ 延伸：什么时候根本不该做 Skill？ 不仅是元认知能力，还有以下三种情况，也不该死磕 Skill 格式： · 一次性任务 → 直接写 prompt 即可，不值得封装· 每次条件都不同 → 高度上下文依赖的任务，Skill 的固化反而成为负担· 还没跑过 3 次以上的工作流 → 过早固化会锁死改进方向。先手动跑 3 遍，找准稳定模式再封装 04 为