庞九林1. AI技能开发的核心认知重构
在AI技术快速发展的今天，Skill（技能）已经成为连接用户需求与AI能力的核心桥梁。但现实情况是，许多团队投入大量资源开发的Skill最终沦为"僵尸文件"——触发率低、执行结果不稳定、维护成本高。这种现象背后反映的是我们对Skill本质的认知偏差。
1.1 Skill的本质定义
Skill不是简单的Prompt（提示词），而是一个完整的"AI能力模块"。它需要明确回答三个核心问题：
- When（触发条件）：在什么场景下必须使用这个Skill？什么场景绝对不能用？
- How（执行步骤）：AI需要按照什么流程、什么规则来完成任务？
- What（输出结果）：执行后应该产出什么格式、什么标准的结果？
以代码审查Skill为例，它不应该只是简单的"帮我审查代码"，而应该明确定义：
- 触发条件：用户提交PR、重构代码，或询问代码实现细节时触发；用户仅查看代码时不触发
- 执行步骤：先检查安全性（如SQL注入），再看可读性（如命名规范），最后验证逻辑正确性
- 输出结果：结构化报告，包含问题清单、风险等级和修改建议，每条建议标注对应代码行号
1.2 三大认知误区解析
误区一：Skill=Prompt
这是最常见的错误认知。Prompt是"一次性对话指令"，侧重即兴交互；而Skill是"长期复用的能力单元"，强调稳定性和可工程化。
对比示例：
- Prompt："帮我跑一下测试"（模糊、临时）
- Skill："running-unit-tests"（明确、可复用，包含完整触发条件和执行流程）
关键区别在于：Prompt依赖模型临场判断，结果不可复现；Skill通过标准化约束确保每次执行结果一致。
误区二：Skill是写给人看的文档
许多开发者把Skill写成"技术说明书"，堆砌原理和背景，却忽略了核心受众是AI模型。模型需要的是结构化指令，而不是通俗解释。
错误示例：
"这个Skill用来生成报告，主要帮助用户整理数据。报告要包含核心信息、分析过程和建议，大家可以根据实际情况调整。"
正确示例：
code复制name: report-generator
description: 当用户需要生成报告时，按以下结构输出内容：
template:
摘要：简要概述核心信息（不超过3句话）
分析：分点列出背景、原因、关键数据（每点不超过50字）
建议：提出3条具体可行的行动方案，标注优先级（P0/P1/P2）
误区三：Skill越复杂越强大
实际上，复杂度与故障率成正比。AI的上下文窗口有限，复杂Skill会让模型"抓不住重点"。
实验数据：
- 将4个功能打包成一个Skill：触发率32%，执行遗漏率30%
- 拆分为4个单一职责Skill：触发率提升至89%，执行准确率100%
结论：职责单一、边界清晰的Skill才是高可用的关键。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. Skill设计的黄金标准
2.1 元数据设计规范
元数据是AI识别Skill的"入口"，直接影响触发准确率。关键字段包括name和description：
| 字段 | 设计规范 | 正面示例 | 反面示例 |
|---|---|---|---|
| name | 1. 简洁唯一 2. 动名词形式 3. 不超过64字符 |
running-tests | test-helper（模糊） |
| description | 1. 第三人称（模型视角） 2. 包含核心功能+触发关键词 3. 不超过1024字符 |
"Review code for quality, correctness, and maintainability. Use when evaluating pull requests, refactoring existing code, or when the user asks for feedback on implementation details." | "I can help you review code"（第一人称） |
关键技巧：在description中埋入"触发关键词"。例如代码审查Skill应包含"pull requests"、"refactoring"等关键词，帮助AI精准匹配用户意图。
2.2 三级自由度分级
不同任务需要不同的约束强度。我们总结出三级自由度分级标准：
| 自由度等级 | 适用场景 | 指导方式 | 示例 |
|---|---|---|---|
| 高自由度 | 多种有效方法，依赖上下文决策 | 给"原则"（启发式策略） | 代码审查："先看安全性，再看可读性，最后验证逻辑正确性" |
| 中自由度 | 有首选模式，允许适度变通 | 给"框架"（模板/伪代码） | 报告生成："按'摘要-分析-建议'结构，摘要不超过3句话" |
| 低自由度 | 操作易错，一致性至关重要 | 给"代码"（可执行脚本） | 数据库迁移："1. 备份数据库→2. 执行001脚本→3. 执行002脚本" |
核心原则：任务越关键、越容易出错，约束越严格。例如数据库迁移、支付相关Skill必须用低自由度；创意生成类Skill可用高自由度。
2.3 五大核心设计标准
这五个标准是Skill稳定运行的基石，可作为评审checklist：
-
边界明确：定义"正向条件"和"负向条件"
- 正确示例："Use when: 用户意图是触发CI/CD流水线；Do NOT use when: 用户仅查看测试报告"
-
输入输出结构化：用"函数签名"方式定义
typescript复制Input: { prId: string, branch: string } Output: { success: boolean, testReport?: object[] } -
步骤明确：指令式动作，非概括性描述
- 正确示例："Steps: 1. 验证PR→2. 切换分支→3. 运行测试→4. 收集结果"
-
失败策略完备：定义不同失败场景的处理方式
- 示例："测试失败：自动重试1次，仍失败则返回'单元测试未通过，失败用例：xxx'"
-
职责绝对单一：一个Skill只做一件事
- 正确示例：拆分"运行测试"、"更新PR状态"、"发送通知"为独立Skill
3. Skill的可维护性设计
3.1 渐进式披露原则
AI的上下文窗口是宝贵资源，应采用"入口导航+按需加载"的设计：
SKILL.md标准结构：
markdown复制## 基础用法
描述核心触发条件和执行流程
## 高级功能
参见advanced-f