写 Skill 别堆料：Token 省在「够用」

先钉四条规矩

五条改法：胖稿怎么削

原文给了「高 Token → 低 Token」对照。节省比例是经验估计，当方向看，别当精确账本。

1. 精简描述（估省 30%+）
   长自我介绍、背景铺垫 → 一句角色 + 任务。

2. 结构化表达（估省 20%+）
   「请详细分析…再给方案…注意全面…」→ 固定回答骨架：分析 / 方案 / 收尾判断 + 短要求。

3. 精简指令（估省 15%+）
   「仔细阅读并理解…多角度…最佳答案」→ 「理解问题，分析，给出最佳答案。」

4. 复用公共内容（估省 10%+）
   每个 Skill 复制同一 JSON schema → 父 / 全局定义 {code, message, data}，子 Skill 引用。

5. 控制示例数量（估省 10%+）
   四个超长示例 → 两个短而有代表性的。

改 Skill 时顺手扫一眼

• 合并重复指令
• 缩写不影响理解再用
• 写明输出长度 / 范围
• 非必要说明懒加载（真用到再给）
• 复杂任务拆多步 / 多 Skill，别做一个巨型 Prompt
• 改完前后对比效果，再迭代

和本仓写法怎么对上

落到个人博客或小型工具链也一样：主说明只写常用路径，细则另开附录；公共校验抽成一份复用，别每个技能各抄一遍；发文、校验、索引更新拆成独立能力，用到再串。这就是「聚焦单一能力 + 按需调用」的落地版。

写新 Skill 前先问三句：这段每次都会注入吗？能上提到父规则吗？这个示例删了模型还懂吗？

别踩的坑

• 「信息越全效果越好」在 Skill 里常常变成「上下文越胖、越贵、越好偏」。
• 拆 Skill 不是拆成碎片：边界要清，公共契约（输出格式、红线）要共享。
• 原文百分比未给测量条件；落地时用自己的前后 token 对比验收。