Skill 设计方法论与实战案例
本页由 [[wiki/concepts/Skills、Agents 与工具设计]] 拆分而来（2026-07-03），内容原样搬移。
渐进式披露：所有成熟 Agent 系统不约而同的方向
这是跨 OpenAI/Karpathy/Claude Code 三个案例反复验证的模式：不在启动时给 Agent 全部信息，而是”在对的时间给对的信息”。
- OpenAI 的 Harness Engineering 教训：一开始写巨大的 AGENTS.md 把所有规则塞进去，结果”以一种可预见的方式失败了”。痛定思痛后从”百科全书”变成约 100 行的”目录”
- Claude Code 三层渐进式加载（L1 目录层 50-100 tokens / skill → L2 指令层按需加载 → L3 资源层懒加载）：即使安装 20 个 Skill，初始加载仅 1000-2000 tokens，比全量减少约 90%
- 工具从 10 个涨到 50 个，模型选择准确率从 90% 掉到不到 50%
核心结论：真正杠杆不在给 Agent 多少信息，而在能不能做到”在对的时候只给它需要的”。 [[raw/2026-05-15/三元同学/做 Agent，请必须学会渐进式披露.md|来源: 渐进式披露]] [[raw/2026-05-12/珂罗/Agent Skill规范、构建与设计模式.md|来源: Skill 规范]]
Skill 设计模式（Google ADK 五种）
- Tool Wrapper：按需加载专家知识
- Generator：模板+风格指南强输出一致性
- Reviewer：分离检查清单和执行打分
- Inversion：Agent 先采访用户再动手
- Pipeline：带检查点的多步工作流
关键洞察：**description 绝不要总结 Skill 的工作流程，只应描述触发条件。**总结工作流程会导致 Agent 直接按 description 执行而跳过阅读完整 SKILL.md 正文。[[raw/2026-05-12/珂罗/Agent Skill规范、构建与设计模式.md|来源: Skill 规范]]
Skill 设计系统方法论（2026-06 新增）
本轮摄入贡献了多个独立验证的 Skill 设计方法，从个人草稿到工业级交付形成完整路径。
浅公式五步法 vs COP-DRR 深模型
脸谱君提出了 Skill 设计的两个层次：
浅公式五步法（适合个人快速草稿）：定义目标 → 拆解步骤 → 设计输入 → 设定规则 → 测试调优。
COP-DRR 六环节框架（适合团队交付和安全敏感场景）：Context（上下文）→ Objective（目标）→ Process（流程）→ Decision（决策点）→ Rule（规则）→ Red-teaming（对抗测试）。这套框架的核心价值是把”写提示词”变成了”设计一个决策系统”。[[raw/2026-06-17/脸谱君/我是怎么设计出那套竞品分析Skill的：两个公式模型.md|来源: 脸谱君 COP-DRR]]
浅版到深版的”三步升级法”：加边界（10分钟）→ 加决策（15分钟）→ 加测试（30分钟）。状态机图替代线性步骤描述，纳入分支和循环的回溯机制。
三层规则金字塔
平铺清单不如三层结构可靠：[[raw/2026-06-17/脸谱君/我是怎么设计出那套竞品分析Skill的：两个公式模型.md|来源: 脸谱君 三层规则]]
| 层级 | 名称 | 性质 | 违反后果 |
|---|---|---|---|
| L1 硬约束 | 红线规则 | AI 不可绕过 | 直接终止 |
| L2 质量门禁 | 关卡规则 | 必须通过才能继续 | 阻塞流程 |
| L3 风格建议 | 偏好规则 | 可忽略但有代价 | 扣质量分 |
AST（Audience-State-Transfer）模型
AI沃茨为 PPT Skill 提出了全新的方法论：PPT 不是视觉展示，而是每页推动观众从一个状态到下一个状态的工具。 Skill 的核心不是告诉 AI 写漂亮 PPT，而是设计”观众状态转移链”——每一页定义输入状态、期望输出状态、以及推动转移的核心论点。[[raw/2026-06-20/AI沃茨（卡尔 & yc星辰）/开源一个为演讲而生的PPT Skill（Humanize PPT），再不用跟观众大眼瞪小眼了.md|来源: AI沃茨 AST]]
Skill 架构分离模式：上游（结构化编排 + 大纲 + 素材 + 演讲稿）与下游（渲染输出）分离。Humanize PPT 只做大纲编排和素材规划，渲染外包给下游 Skill。这个模式可推广到任何”规划→执行”分离的场景。
前置预览模式：渲染前生成 4 页真实效果预览，提前确认风格一致性，避免全量渲染后发现方向错误。
从拆自己的工作流出发
多位作者独立验证同一核心设计哲学：Skill 设计的起点不是”AI 能做什么”，而是”拆解自己的工作流程”。 脸谱君明确提出”AI 不是我肚子里的蛔虫”——用户说不清楚 AI 就做不到。吴师兄从反向验证：“只写它猜不到的”——Skill 的价值不是复述常识，而是提供模型默认思维模式外的特殊知识。[[raw/2026-06-17/脸谱君/我是怎么设计出那套竞品分析Skill的：两个公式模型.md|来源: 脸谱君]] [[raw/2026-06-20/吴师兄/一个月给 Claude Code 烧了 1.5 万美金，我才搞懂 skill 到底该怎么写.md|来源: 吴师兄 Skill 实战]]
Scripts Attached to Skills：可执行替代可读
扶苏半年实战中的一个关键效率洞察：与其在 Skill 文档中写”如何测试某路由”，不如预置一个可直接执行的脚本。 常规做法是写文本指导”运行 node scripts/test-auth-route.js [url]”，扶苏的做法是在 Skill 子目录中预置脚本并在 SKILL.md 中直接输出可粘贴命令——Claude 即使不手动执行，也可以从脚本实际逻辑而非纯文本描述中理解操作意图。这个模式的本质是把”可读说明”升级为”可执行制品”——不让模型在文本解读和工具调用之间再做一次翻译。[[raw/2026-06-19/扶苏/Claude Code 深度实战：半年单兵重构 30 万行代码的硬核工程化指南.md|来源: 扶苏 可执行脚本]]
Description 是触发条件不是简介——源码级证据
吴师兄通过源码确认了两个关键常量：[[raw/2026-06-20/吴师兄/一个月给 Claude Code 烧了 1.5 万美金，我才搞懂 skill 到底该怎么写.md|来源: 吴师兄 源码常量]]
SKILL_BUDGET_CONTEXT_PERCENT=0.01：只分配上下文窗口的 1% 用于加载 skill description。200K 上下文约 2000 tokens，够 15-25 个完整描述。超出后按使用频率 FIFO 丢弃。MAX_LISTING_DESC_CHARS=250：单条 description 超过 250 字符直接截断，不在源码层面有任何智能截断或摘要逻辑。
这意味着 description 必须在 250 字符内完成触发判断——必须嵌入用户真实场景的关键词，而非写”此 Skill 用于…”的功能简介。Unknown 进一步强调：触发测试应”模拟用户最自然的表达方式”，显式命令不行，必须覆盖用户无意识说出来的需求。[[raw/2026-06-19/Unknown/如何写出工业级 AI Agent Skill.md|来源: Unknown 七步法]]
验证闭环是最高 ROI 投入
多位作者独立验证：验证类 Skill 对输出质量提升最显著，远超市前预期。 Anthropic 内部将 Product Verification 评为”对输出质量影响最可量化”的类别，值得投入一名工程师一周时间。吴师兄被”黑屏教育”（20 个通过里 7 个假通过）、AI沃茨被渲染静默缺陷教育（0 fail 全绿仍有页码吃掉正文的 bug）——AI 自称完成不可信，需要独立的验证手段。[[raw/2026-06-20/吴师兄/一个月给 Claude Code 烧了 1.5 万美金，我才搞懂 skill 到底该怎么写.md|来源: 吴师兄 验证]] [[raw/2026-06-20/AI沃茨（卡尔 & yc星辰）/开源一个为演讲而生的PPT Skill（Humanize PPT），再不用跟观众大眼瞪小眼了.md|来源: AI沃茨 渲染缺陷]]
无名七步法的要点：写完后至少测三件事——能不能跑通、能不能正确触发、结果是否比不用更好。评测闭环中”常见问题→修改方向”对照表：触发失败改 description / 流程漏步改工作流 / 输出不稳定加模板 / 确定性操作不稳定写脚本。[[raw/2026-06-19/Unknown/如何写出工业级 AI Agent Skill.md|来源: Unknown 评测闭环]]
验证信任危机：AI 自称完成不可信
本轮摄入多个来源将”AI 自称完成不可信”从经验观察提升为系统性问题。吴师兄的”黑屏教育”（20 个通过里 7 个假通过）、AI沃茨的渲染静默缺陷（0 fail 全绿仍有页码吃掉正文的 bug）、扶苏的风格漂移（同样配置下输出风格逐渐偏离规范）——共同指向一个根本问题：Agent 缺乏自我验证能力，需要工程手段来弥补验证缺口（Verification Gap）。 扶苏采用的实战策略包括：真实浏览器验证预期行为、连续运行自动化测试、最终重新读文档审计变更影响——形成”三层验证”模式。每个 Skill 都应自带验证步骤，没有验证的 Skill 只是半成品。[[raw/2026-06-19/扶苏/Claude Code 深度实战：半年单兵重构 30 万行代码的硬核工程化指南.md|来源: 扶苏 三层验证]] [[raw/2026-06-19/梦朝思夕/万字长文 - 带你由浅入深了解 Loop Engineering：从手动 Prompt 到设计系统的跃迁.md|来源: 梦朝思夕 Verification Gap]]
Skill Creator 的价值与局限
Anthropic 官方 Skill-Creator 的设计哲学——“像做机器学习一样做 Prompt Engineering”，有训练集、测试集、评估指标、迭代优化循环。六阶段闭环：需求捕获→编写→测试执行（A/B 测试）→评估与评审→迭代改进→优化与发布。
已知局限：Token 消耗极高（单次 description 优化消耗 69% 的 5 小时配额）、Skill 膨胀风险（5KB→50KB）、对”操作型 Skill”触发率可能始终为 0%。社区共识：对于简单需求，直接手写 SKILL.md 比用 skill-creator 快得多。 [[raw/2026-05-12/珂罗/Agent Skill规范、构建与设计模式.md|来源: Skill 规范]]
Skill 工程化的天花板：把 Agent 当算法用
“当规则写到 200 行，AI 开始叛逆。” LLM 的注意力不像 128K 上下文表面看起来那样——真正活跃在”大脑”中的只有刚读过的那几页。核心问题不是”怎么写更好的提示词”，而是”怎么设计一个让 AI 在每个时刻都只需要关注最少信息的执行环境”。
解决方案：引入 CLI 接管一切确定性事务，Agent 只做”大脑”（理解意图、组织回复）并只输出 JSON 参数。Workflow 用 Markdown 文件定义而非代码，Gate 门禁机制做精确校验。“约束越强，AI 反而越自由”。[[raw/2026-05-13/腾讯程序员/当我把 AI 变成一个-算法-：Skill 工程化设计的心路历程.md|来源: 把 AI 变成算法]]
Anthropic 内部 Skills 实践：九类框架与四大最佳实践（2026-06 新增）
Anthropic 工程团队在 2026 年 6 月公开了 Claude Code 团队内部编写技能的全部经验（Lessons from building Claude Code），核心贡献在于提供了一套从”经验总结”到”技能封装”的结构化方法论。 [[raw/2026-06-05/邵猛/Claude Code 工程实践揭秘：Anthropic 内部 Skills 设计的九类框架与编写最佳实践.md|来源: CC Skills 九类框架]] [[raw/2026-06-07/Datawhale/重磅！Anthropic内部Skills经验公开了！.md|来源: Anthropic内部Skills经验]]
九大 Skill 分类体系
所有内部 Skill 归为 9 个类别，覆盖从知识补全到运维的完整软件工作流：
| 类别 | 核心功能 | 典型示例 |
|---|---|---|
| Library & API Reference | 内部库/CLI/SDK 的正确用法与陷阱 | billing-lib, platform-cli |
| Product Verification | 驱动运行中的产品进行端到端验证 | signup-driver, checkout-verifier |
| Data & Analysis | 连接数据栈与监控体系 | funnel-query, grafana |
| Business Automation | 多工具工作流一键化 | standup-post, weekly-recap |
| Scaffolding & Templates | 框架正确的代码脚手架 | new-app, new-migration |
| Code Quality & Review | 代码质量方法论 | adversarial-review, code-style |
| CI/CD & Deployment | 安全地提交、推送、部署 | babysit-pr, deploy-service |
| Incident Runbooks | 症状→调查→报告的故障处理 | oncall-runner, queue-debug |
| Infrastructure Ops | 带安全门的运维操作 | orphans, cost-investigation |
值得注意的洞察：Product Verification 被特别强调为”对 Claude 输出质量影响最大、最可量化的 skill 类别”，团队认为值得投入一名工程师一周时间专门打磨。Infrastructure Ops 涉及破坏性操作，强调”safety-gated”（带安全门）设计——体现对 AI 自主执行风险的操作性思考。
编写 Skill 的四大最佳实践
1. Don’t state the obvious。Skill 的价值不是重述”CLI 怎么用”，而是提供将模型推出默认思维模式的特殊知识。正面案例：前端设计 skill 不教 CSS 语法，而是通过迭代训练”设计品味”，明确避免 Inter 字体和紫色渐变等陈词滥调。
2. Build a gotchas section（陷阱章节）。这是最高信号价值的内容。Gotchas 应来自 Claude 实际使用中的失败点，持续积累。示例：“subscriptions 表是 append-only 的，找 version 最高的行而非 created_at 最新的”、“Staging 环境即使 Stripe webhook 没实际处理也会返回 200”。
3. Use file system for progressive disclosure。Skill 是一个文件夹，SKILL.md 作为 hub 进行调度，spoke 文件包含具体细节。示例：queue-debugging/SKILL.md 仅 30 行，通过症状匹配表分派到 stuck-jobs.md、dead-letters.md 等具体文件。
4. Avoid railroading Claude。Skill 应提供信息而非僵化流程。对比：过度指令化是”Step 1 运行 git log → Step 2 运行 git cherry-pick”，更好的方式是”Cherry-pick the commit onto a clean branch. Resolve conflicts preserving intent.”
精妙工程技巧：动态配置
利用 !`cat ${CLAUDE_SKILL_DIR}/config.json` 语法在 Claude 读取 prompt 前执行 shell 命令，实现首次使用时的交互式配置——如果未配置则询问用户偏好并写入 config.json，后续直接复用。这是轻量级的 skill 状态管理机制。
编写 Skill 终极实战手册
腾讯程序员在 2026-06-05 发布的《如何写好 Skill》是另一份高完整度的工程化参考手册，覆盖了 Skill 编写全生命周期：三层渐进式加载机制（L1 元数据常驻 50-150 tokens → L2 SKILL.md 按需加载 → L3 资源按需引用）、description 优化方法论（写 20 个混合用例测试触发准确率）、模块化拆分原则（超过 500 行拆主 Skill + 子 Skill）、MCP vs HTTP 调用选型决策树、安全防范（无硬编码密钥 / 危险操作加确认 / 防范 Prompt 注入 / 数据库操作先备份）、Skill Creator 工程化评估（触发评估 Precision/Recall + 效果评估 Quality + 综合报告）、反模式速查（大杂烩 / 黑话 / 无示例 / 无验证点 / 写死数值 / 当 Wiki 写）、以及完整的核心检查清单。 [[raw/2026-06-05/腾讯程序员/如何写好 Skill：一份终极实战经验手册.md|来源: 写 Skill 实战手册]]
Anthropic 数据分析 Agent 的 Skill 实践（2026-06 新增）
Anthropic 内部用 Claude Code 做自服务数据分析的经验（95% 自动化、95% 准确率）展示了 Skill 在非编码场景的完整应用范式。核心发现：没有 Skill 时准确率不超过 21%，加上 Skill 后稳定在 95% 以上。他们创建配对 Skill——一个”知识型”Skill 做顶层路由器（把几百万字段搜索空间缩小到几十个参考文件），一个”非书型”Skill 编码资深分析师的工作流程。关键的维护纪律：Skill 文档和数据模型放同一个仓库，改模型 PR 必须同时修改描述文档，代码审查钩子拦截未触达 Skill 文件的变更——大约 90% 的数据模型 PR 现在都附带一个 Skill 变更。不主动维护的情况下，准确率一个月从 95% 衰减到 65%。 [[raw/2026-06-04/AI兴观点/Anthropic 用 Claude 做数据分析：95% 自动化、95% 准确率，内部方案全公开.md|来源: 数据分析 Skill 实践]]
Skill Factory：面向 Harness 的技能工厂
通过多路并发（同时调用 3 种不同策略的 Skill Creator）+ 测试驱动 + 自动化验证闭环，解决传统人工编写和对话式生成 Skill 的瓶颈。“只要有一路成功，整个任务就算成功。” [[raw/2026-05-14/月珩/Skill Factory：三天手搓面向Harness设计的技能工厂（附AI coding实践）.md|来源: Skill Factory]]
Matt Pocock 现象：心法→招式
75K star 的爆款仓库（mattpocock/skills），十几个 markdown 文件，每个几十行，没有一行新东西。本质是将 4 本经典软件工程书籍（Kent Beck TDD、Pragmatic Programmer、Domain-Driven Design、A Philosophy of Software Design）的方法论 + 个人实践判断融会贯通后压成 AI 能看懂的”招式”。
核心区分：经典书籍讲的是”心法”（认知层的道理/原则/判断），Matt 做的是把心法变成”招式”（执行层的具体协议）。真正稀缺的不是发现原则，是有能力将原则压成”朴素到没人愿意承认它复杂”的样子。这种能力反 AI：AI 能记住信息，但不能沉淀判断。 [[raw/2026-05-13/问答/75K star 的 SKILL 爆款仓库，没有一行新东西，且个位数行，凭什么疯传？.md|来源: 75K star 爆款仓库]] [[raw/2026-05-14/逛逛/强烈推荐看看这个演讲，还配套 7 万 Star 的开源 Skill。.md|来源: Matt Pocock 演讲]]
四个方法论共通的底层逻辑是”管理认知负荷”：Grill Me（写代码前先被 AI 拷问）、统一语言（CONTEXT.md）、TDD（控制每一步范围）、Deep Modules（藏复杂、露简单）。
垂直切片原则
Issue 按用户可感知行为拆而非按文件拆，每个可独立验收。这是 Matt Pocock 工作流中与 TDD 互补的核心拆分原则——不拆技术层，拆用户故事。[[raw/2026-06-20/兔兔AGI/打造真实项目的 AI 编程环境：Matt Pocock 的 Skill 工作流完整上手攻略.md|来源: 兔兔AGI 垂直切片]]
与主流工作流选型对比
| 框架 | 关注重点 | 适合场景 | 主要取舍 |
|---|---|---|---|
| Matt Pocock Skills | 手动编排，用户控制权 | 个人开发、中小型项目 | 慢但可控 |
| GSD | 全自动 Agent 流程 | 快速原型 | 不可控 |
| BMAD | 规范和文档驱动 | 大型项目 | 前期成本高 |
| Spec-Kit | Spec 驱动 + AI 生成 | 有明确规范的项目 | 需要良好初始 spec |
| Superpowers | 流程治理，自动触发 | 团队标准化 | 学习曲线 |
[[raw/2026-06-20/兔兔AGI/打造真实项目的 AI 编程环境：Matt Pocock 的 Skill 工作流完整上手攻略.md|来源: 兔兔AGI 选型对比]]
完整工作流
Matt Pocock 六步标准使用流：/grill-with-docs → /to-prd → /to-issues → /tdd → /diagnose → /improve-codebase-architecture。30 秒安装命令：npx skills@latest add mattpocock/skills。初始化向导 /setup-matt-pocock-skills 配置 Issue tracker / triage 标签 / 领域文档位置。[[raw/2026-06-20/兔兔AGI/打造真实项目的 AI 编程环境：Matt Pocock 的 Skill 工作流完整上手攻略.md|来源: 兔兔AGI 安装与配置]]
生产级 Skills 参考
- Warp 团队开源 15 个生产级 Skills，覆盖 SEO 审计、文档写作、DevOps，是社区目前较成体系的 Skill 样板。 [[raw/2026-05-07/AI兴观点/白嫖 Warp 团队 15 个生产级 AI 技能：SEO 审计、文档写作、DevOps 一键装走.md|来源: Warp 15个Skills]]
- Claude Code 团队的 Markdown 转 HTML 决策：Markdown 在各平台的解析一致性不可控，HTML 能为 Skills UI 提供更丰富的交互能力。这是一个基础设施级的设计选择。[[raw/2026-05-09/AI兴观点/Claude Code 团队：为什么我们从 Markdown 转向 HTML.md|来源: CC Markdown→HTML]]
Matt Pocock Skills 完整体系
18 个 Skills 分三类：
- 工程类（10 个）：覆盖从需求到诊断的完整流程
- 效率类（4 个）：提升日常开发效率
- 杂项类（4 个）：辅助功能
完整工作流：/grill-with-docs → /prototype → /to-prd → /to-issues → /triage → /tdd → /diagnose。
核心哲学：“软件工程基本功在 AI 时代更重要”，小而精、可组合、模型无关。
横向对比：Matt Pocock（质量层/手动编排）vs OpenSpec（规范层/DAG 驱动）vs Superpowers（执行层/自动触发）。关键矛盾：Matt Pocock 主张用户手动调用 vs Superpowers 主张 Agent 自动判断时机——这是对控制权的根本分歧。
矛盾：Matt Pocock 主张用户手动触发 Skill、AI 保持最小自主性，认为全自动流程剥夺控制权难以排查错误 vs 尼恩主张工业级 Skill 系统应四层召回+Harness 统一管控注入，通过置信度分层实现自动化（>0.85 自动加载），追求自进化闭环减少人工干预。这个张力反映了对”AI 最终应该多自主”的根本分歧——没有绝对正解，取决于项目风险容忍度和团队的人机协作哲学。来自 [[raw/2026-06-19/尼恩-技术自由圈/阿里面试官：如何设计工业级 Skills 进化体系？-一个工业级-技能-Infra-底座如何设计？.md|来源: 尼恩 全自动]]
[[raw/2026-05-18/AgentBuff/VibeCoding工程化实践之Matt Pocock Skills，软件工程经验的技能结晶.md|来源: Matt Pocock Skills]]
AgentBuff Skill 选型指南
展示了社区对 Skill/Plugin 的务实分类法：按场景分六类（写作与发布、设计与视觉、代码工程、网页与数据自动化、元能力管理），按重量分两级（Skill = 单个外挂，Plugin = 整套装备含多个 skill + 斜杠命令 + 子 agent + 记忆库）。核心选型原则：“单点需求装 Skill，想系统性提升工作流装 Plugin。” [[raw/2026-06-01/AgentBuff/我装了 30+ 个 Claude 技能和插件，这些才是真·必装（一）.md|来源: AgentBuff 选型]]
生产级 verify-data Skill 全貌
阿里云晓莄的 verify-data（数据验数 Agent Skill）是生产级 Skill 的完整工程参考：17 步条件触发工作流、14 个 references 分层文档、4 条”不可逾越的红线”（硬约束而非软建议）、基准表自动发现的两阶段算法（血缘筛选 + 维度/指标评分）、lessons-learned.md 记录 19 条踩坑经验。效率从 2-4 小时压缩到 30 分钟。
核心设计原则：约束优于指令。硬红线（禁止跳过模板、禁止猜字段映射、降级必须追加 CR、所有 JOIN 必须膨胀率验证）比文字指导的效果好得多——因为 LLM 倾向于”绕过”软性建议而”服从”硬性禁止。
[[raw/2026-05-27/verify-data：一个端到端的数据验数 Agent Skill.md|来源: verify-data Skill]]
淘宝企业购：面向 Skills 编程的端到端实践（2026-06-17 新增）
淘天集团行业运营技术（官亭）提出了**「面向 Skills 编程」**范式转移——从「人写代码」到「人写 Skills，LLM 写代码」。Skills 把领域知识、工作流、约束规则封装成可版本化的单元，让 LLM 在确定性框架内生成代码。这被定位为 DDD + 配置驱动编程的继任者。 [[raw/2026-06-17/行业运营技术/面向Skills编程-淘宝企业购端对端研发提效实践.md|来源: 淘宝企业购 面向Skills编程]]
五阶段 AI 开发演进模型：① Vibe Coding（2025-08，自由对话驱动，质量不稳不可复用）→ ② Prompt 模板（2025-09，标准化「业务→技术」语义翻译，AI 代码采纳率 70%）→ ③ SDD/Spec 驱动（2025-12，结构化 spec 驱动，代码可用率 40%→80%）→ ④ Skill 积累（2026-01/02，领域经验结晶为可复用 Skill 单元，首过成功率 90%）→ ⑤ 云端集成（2026-02，端到端 AI 开发平台，探索阶段）。
核心数据：产品域端到端交付周期从 23.5 人天降至 8 人天（提效 65%）；代码首过生成成功率 90%（从约 50% 提升）。
三层架构：原子能力层 + 模板层 + 适配层。AI 生成的代码专注于适配层，减少适配代码量 60%，实现零冲突多端并行开发。
关键洞见：「质量瓶颈不在模型，而在知识工程。」从 50% 跳到 90% 成功率完全来自知识注入和约束迭代，而非换更强的模型。领域知识（映射规则、API 签名、模式判定）不会从训练数据里涌现，必须显式注入。 [[raw/2026-06-17/行业运营技术/面向Skills编程-淘宝企业购端对端研发提效实践.md|来源: 淘宝企业购 知识工程]]
Sub-Skill 分解作为架构级方案：不指望模型在超长上下文中保持一致，而是把一个 15 接口的技术 spec 生成任务拆成 4 个独立 Sub-Skill，每个处理约 8K token。垂直领域 Skills 不可复用，但构建 Skills 的方法论是通用的。
Anthropic 内部九大 Skill 分类与编写经验（2026-06-17 新增）
程序员Carl 基于 Anthropic 官方博客《Lessons from building Claude Code: How we use skills》提炼了 Anthropic 内部使用数百个 Skill 的实践经验。Skill 不是单个 markdown 文件——它是一个含指令、脚本、资源的文件夹，遵循渐进式披露。 [[raw/2026-06-17/程序员Carl/Claude Skills实战：Anthropic用了几百个Skill，总结出9大分类和写好Skill的全部经验.md|来源: 程序员Carl 九大分类]]
Skill 文件夹结构：SKILL.md（主指令+description，决定何时触发）→ references/（按需加载的参考文档）→ scripts/（可执行脚本，能跑就别让 Claude 从零写）→ assets/（模板、样例数据）→ config.json（配置，缺失则 Claude 问用户）。
九大 Skill 分类（Anthropic 内部分类法）：① 库/API 参考 ② 产品验证（内部评为对输出质量影响最可量化） ③ 数据检索与分析 ④ 业务流程与团队自动化 ⑤ 代码脚手架/模板 ⑥ 代码质量与审查（含「对抗式审查」——起一个全新 sub-Agent 来挑刺）⑦ CI/CD 与部署 ⑧ Runbook 故障排查 ⑨ 基础设施运维。
Skill 成长模型：从「几行+一个 gotcha」开始 → 真实使用中遇到新 edge case → 加 gotcha → 重复。最好的 Skill 是「长出来的，不是设计出来的」。
关键洞见：① Skill description 是写给模型看的，不是写给人看的——要嵌入用户实际会说的触发关键词（如「babysit」），而非「此 Skill 用于监控合并请求状态」。② Gotchas 是任何 Skill 中信号量最高的部分——「不告诉 Claude 它肯定搞错」的信息，比复述官方文档有价值得多。③ Skill 可以有记忆——在文件夹内维护 append-only 日志或 JSON 文件，Claude 每次读取自己的历史并调整行为。 [[raw/2026-06-17/程序员Carl/Claude Skills实战：Anthropic用了几百个Skill，总结出9大分类和写好Skill的全部经验.md|来源: 程序员Carl Gotchas 与记忆]]
Matt Pocock：Skill 描述 Token 成本降 63% 的架构拆分（2026-06-18 新增）
TypeScript 权威 Matt Pocock（mattpocock/skills，130K+ star）发布开源 Skill 集合 v1，通过用户触发与模型触发 Skills 的架构拆分，实现 Skill 描述 token 成本降低 63%。设计哲学强调把认知负担留在用户身上而非让 AI 自主决策。 [[raw/2026-06-18/林芯/被Vibe Coding坑惨了？TypeScript大神开源skill：技能描述Token成本狂降63%，AI自主判断技能调用？.md|来源: 林芯 Matt Pocock 63%]]
两层 Skill 调用模型：
- 用户触发 Skills：必须用户手动调用。适合决策密集、节奏控制重要的流程。AI 不能自主调用。
- 模型触发 Skills：AI 根据任务上下文自主判断是否调用。例：
/grilling（现改为模型触发）、/diagnosing-bugs（测试失败时自动触发）。 - 嵌套规则：用户触发 Skill 可调用模型触发 Skill，但不能调用其他用户触发 Skill（防止「套娃」失控）。
新引入的 Skill：/ask-matt（「元 Skill」路由器——分析任务→推荐 Skill 组合→引导逐步执行）；/codebase-design（「Deep Module」架构方法论）；/domain-modeling（主动领域建模 + CONTEXT.md/ADR 维护）；/writing-great-skills（完全重写，含词汇系统和可预测输出原则）。
关键洞见：Matt 明确反对完全自主的 Agent 流程：「GSD、BMAD、Spec-Kit 这类框架试图帮你接管整个流程，但这样做的同时剥夺了你的控制权，让过程中的错误难以排查。」这是有意识的人机协作哲学，与全 AI 自主趋势形成张力。 [[raw/2026-06-18/林芯/被Vibe Coding坑惨了？TypeScript大神开源skill：技能描述Token成本狂降63%，AI自主判断技能调用？.md|来源: 林芯 认知负担哲学]]