很多人把 Skill 等同于「高级提示词」，这是一个危险的误解。一个 Skill 的结构很简洁：Skill = 触发条件 + 执行流程 + 输出约束；但一个工程化的 Skill 体系完全不同：可设计的规则 + 可验证的闭环 + 可复盘的迭代 + 可组合的链路 + 可共享的资产。

区别在于四个层级：临时提示词（写在聊天框里，不可复用不可审查）→ 抽成 SKILL.md；单个 Skill（本地能用，触发不稳）→ 加验证闭环和测试样例；技能集合（多个 Skill 放一起，职责重叠互相抢活）→ 建目录规范和组合协议；团队工程体系（共同使用）→ Git 管理、版本发布、Bad Case 回填。

设计原则：一个 Skill 只解决一个明确问题

写 Skill 最容易犯的错是一上来就想做「大而全」，结果既难触发、也难测试、更难维护。Anthropic 官方 Skill 编写指南给出核心原则——精简至上：上下文窗口是公共资源，你的 Skill 要和对话历史、系统提示、其他 Skill 的元数据共享空间。实操上遵循三条铁律：单一职责（spec-writer 写规格、task-planner 拆任务、code-reviewer 审代码、release-checklist 查发布）、渐进披露、自由度匹配。

Loop 增强写法把 Skill 装上了「刹车系统」：L0 锚定（动手前必须完成）、L1 执行（按顺序逐项完成）、L2 验证清单、L3 修正规则。

配套的落地方法是评估驱动开发：先跑基线 → 写最小 Skill → 准备测试样例 → 跑测试、收 Bad Case、写回 Skill。团队级 Skill 一定要进版本控制，这不是可选项，是底线。目标是让团队工程经验变成 AI 稳定继承、可验证、可迭代的生产线资产。