在大量实践之后，我总结出16条可以直接落地的Skill设计原则，帮你写出稳定、好维护、易扩展的AI能力。
一、设计要简单：小而美，别贪大
1. 单一职责：一个 Skill 只做一件事
不要把整理、发邮件、建任务全部塞进同一个Skill。步骤越长、功能越多，越容易出错、越难调试。正确做法是，每个Skill聚焦单一目标，拆小、拆专、拆清晰。一句话：小而美，比大而全更稳。
2. 最小可用：先跑通，再完美
不要一上来就追求支持多语言、多格式、多场景，那样永远上不了线。先做最小可用版，跑通核心流程，稳定后再迭代扩展。一句话：今天能用，比下周完美更重要。
二、接口与版本：稳定才能被依赖
3. 向后兼容：老接口不能随便砍
不要直接修改参数名，否则上游全部报错。正确做法是新旧参数并行，过渡期提示迁移，逐步下线旧字段。
4. 版本稳定：不要频繁大改
一周多个版本、频繁重构，会让用户无所适从。稳定版本长期维护，开发版内部迭代，成熟后再发布。一句话：稳定，才敢依赖。
三、质量与测试：不校验 = 不稳定
5. 用例先行：先写用例，再写 Skill
不要写完直接上线，遇到空输入、异常格式就崩溃。必须覆盖正常、边界、异常场景，准备完整测试用例集。
6. 步步校验：每一步都要验证
不要直接信任LLM输出，格式错、数据乱才发现。LLM输出后必须校验：JSON合法性、字段合规、内容可信。一句话：不校验=不稳定。
四、性能与执行：脑手分离才好维护
7. 固化责任：确定性逻辑交给脚本
不要让LLM做格式化、拼接、计算，既慢又贵还不稳定。LLM负责理解和决策，脚本负责确定性格式化、数据处理。
8. 控制流与数据流分离
不要让LLM既判断又执行，逻辑混在一起，难调试。LLM是大脑，负责决策；脚本或Agent是手脚，负责执行。一句话：脑手分离，才好维护。
五、调用稳定性：边界越清，调用越准
9. 描述要 " 攻击性 " ：触发条件写死
描述模糊，比如只写"处理文件"，AI根本不知道什么时候调用。要明确适用场景、典型说法、触发关键词，越具体越稳定。
10. 边界清晰：写清什么时候不该用
不要只说能做什么，不说不能做什么，否则AI会乱调用。明确不适用场景、替代Skill、参数缺失处理。一句话：边界越清，调用越准。
六、约束与输出：格式死、约束严、不脑补
11. 白名单优于黑名单：正向约束更有效
靠"不要做什么"约束，LLM很容易忽略。用"只能做什么、只能输出什么格式"，正向约束效果更强。
12. 样例胜过描述：给标准答案
只写文字规则，LLM容易自由发挥。提供一份标准样例，LLM照着模仿，输出格式高度一致。
13. 强制输出格式：不给自由发挥空间
自由文本输出，格式五花八门，难以对接。强制JSON、表格或固定字段，用严格Schema约束。
14. 幻觉控制：只能用原文，不许脑补
允许LLM"合理补充"，很容易编造信息。必须严禁推理、严禁补充，所有内容必须来自输入原文。一句话：格式死、约束严、不脑补，才可信。
七、迭代与维护：持续优化才长久
15. 反馈闭环：错例驱动优化
上线后不管，同类错误反复出现，等于没做维护。建立闭环：收集错例、分析原因、强化规则、更新Prompt或模板，持续迭代。
16. 脚本自包含：少依赖外部
依赖大量外部API、内部服务，网络一断就挂，稳定性差。优先用标准库、本地文件、内置逻辑，尽量减少外部依赖。一句话：少依赖=更稳定。
最后总结：好 Skill 的四大特征
第一，规则严：白名单、强约束、不给自由发挥。
第二，流程清：单一职责、脑手分离、步步校验。
第三，格式死：固定输出、样例参考、Schema强制。
第四，迭代快：错例闭环、持续优化、小步快跑。
写好AI Skill，从来不是Prompt玄学，而是经验、规范和工程化的结果。你的Skill好不好，对照这16条就够了。