夜雨聆风
Skill 设计 7 大原则:让你的 AI 助手从＂能用＂到＂好用＂
Skill设计
AI编程
Agent
你有没有遇到过这种情况：
给 AI 编程助手配了一堆 Skill（技能），结果该触发的不触发，不该触发的乱调用；输出格式时对时错；稍微复杂点的任务就跑偏。
问题可能不在模型，而在 Skill 设计本身。
今天总结 7 个核心设计原则，每个都附”正确 vs 错误”对比，直接能用。
① 专注模糊逻辑
核心理念：Skill 的上下文窗口极其昂贵，别浪费在计算机本来就能完美执行的任务上。
判断标准——写之前先问自己：这步有唯一标准答案吗？
有 → 写进脚本或 MCP 工具（确定性逻辑）
没有 → 留在 Skill 里（模糊逻辑：决策、判断、理解）
❌ “逐行读取 CSV 文件，计算第三列的总和”
✅ 调用 calculate_csv_sum 工具，只处理异常和结果解释
角色定位：Skill 是大脑（判断做什么），脚本/MCP 是手脚（执行怎么做）。
② 渐进式披露
核心理念：上下文是所有 Skill 共享的公共内存。一次性加载所有信息会污染全局。
L1 钩子（常驻） — Name + Description，<100 tokens
L2 核心（触发加载） — SKILL.md 正文，<5k tokens
L3 资源（按需引用） — API 文档、Schema，用时才读
❌ 把 50 页 API 文档全塞进正文
✅ 正文写”鉴权规则见 auth.md”，按需引用
把 Skill 当目录设计，不当百科全书。
③ 明确触发描述
核心理念：Description 是 Skill 的门面。描述不清 → AI 误触或不触发。
Description = 能力定义 + 触发场景/关键词
关键词埋点很重要——显式包含高频词（如 Excel、.xlsx、表格分析），便于向量检索匹配。
❌ “Excel 助手”（太泛，不知道什么时候用）
✅ “从 Excel 提取销售数据…当用户上传 .xlsx 或请求季度报表时触发”
④ 指令的绝对性
核心理念：Skill 是操作手册，不是建议书。模糊语气增加幻觉风险。
消灭代词 — 不用”你应该”、”我建议”
命令式动词 — 直接以动词开头（扫描…、提取…、格式化为…）
示例驱动 — 格式要求给 Input → Output，少谈抽象规则
❌ “你可以尝试用 JSON 格式输出…”
✅ “输出必须严格遵循 JSON 格式。示例：{‘status’: ‘success’}”
⑤ 清晰定义边界
核心理念：AI 倾向于讨好用户，即使面对危险任务也会强行回答。Skill 必须当安全护栏。
三件事必须写清楚：
否定约束：”严禁…”、”不要…”
失败路径：死胡同怎么走（找不到字段返回什么 Error Code）
安全阈值：高风险操作需确认步骤
❌ 只写成功流程
✅ “若 API 返回 404 重试一次；仍失败则停止并报告”
只定义成功是不够的，必须定义失败。
⑥ 工程化闭环
核心理念：Skill 是代码，不是散文。必须有通过/失败标准和测试机制。
不做这件事的后果：手动聊一次感觉不错就发布，上线后各种边缘 case 爆雷。
正例：应该触发的输入
反例：相似但不该触发的输入
边缘案例：空输入、超长输入、特殊字符
❌ 手动聊一次觉得 OK 就发布
✅ 维护 tests/ 目录，每次更新后自动回归验证
⑦ 最小够用
核心理念：模型已有通用知识。Skill 的价值在于提供特有知识和约束。冗余信息稀释权重。
剔除常识 — 不解释什么是 PDF，直接说用什么库提取
聚焦差异 — 只写模型不知道的（内部规范、特殊 API）
高信噪比 — 删掉不影响执行的每一句话
❌ 复制维基百科定义到 Skill
✅ 只保留针对当前任务的精简步骤和约束
一个字都不要多写。
一张图总结
① 模糊逻辑 — 只留决策判断，确定性交给代码
② 渐进披露 — L1常驻 / L2触发 / L3按需
③ 明确触发 — 能力+场景，关键词埋点
④ 绝对指令 — 命令式语气，不给选择
⑤ 清晰边界 — 定义失败路径和安全护栏
⑥ 工程闭环 — 测试集+正例反例+自动回归
⑦ 最小够用 — 冗余=稀释权重，一字不多写
下次写 Skill 或调 Prompt 效果不理想的时候，对照这 7 条查一遍——大概率能找到问题。
你在项目里有哪些想让 AI 自主完成的任务？欢迎在评论区说说，下一篇我打算写一个 Agent 实战案例。
觉得有用，转发给你团队里对 AI 编程感兴趣的同事——这个概念值得搞清楚。
——VibeCoding大爆炸，持续分享 AI 编程的真实经验