我做了一套 AI Expert Skills，但后来开始尽量少用 Skill

我做了 Praxis 的 Core 和 Expert Skills，却也在设计原则里写下：简单、明确的任务，可以一个 Skill 都不加载。把这两件事放在一起，乍看有点矛盾。既然花时间写了专家指导，为什么又要尽量少用？

标题里的“后来”，指的是我对使用方式的判断变化，并非一段已经完成的减量实验。仓库当前仍保留四个 Core 和八个 Expert；真实业务净收益尚未验证。我没有证据说自己少加载几个 Skill 后，质量或效率已经提高。

主题值得研究，不等于值得独立加载

最容易扩充 Skill 的办法，是按知识领域列目录：需求、架构、测试、安全、性能，每项再拆工具和技术栈。问题在于，目录越完整，越容易让“这个主题很重要”替代“这里有一个独特的判断缺陷”。

Praxis 的边界审查给了我一个具体提醒。最初八个候选主题中，证据校准、最小变更和工作学习被并入共同原则或文档约定；方法蒸馏留作研究用途，四项成为 Core。后来增加的 Expert 也合并了产品与 UX、数据与 API，以及 AI 里的 prompt、RAG 和 eval，没有按名词逐个建 Skill。

这些取舍是设计决定，还不是增益证明。我现在更关心：它会在哪种可辨认情境下改变什么选择？何时应该退出？如果两份指导的触发条件、核心取舍和停止点相同，分成两份可能只是多了两个入口。

在增加一层之前，先看缺了什么

Praxis 当前使用一条干预层次：Native Agent → Context → Principle → Reminder → Skill → Tool → Deterministic Mechanism。这里的 Context 是项目真实上下文，Reminder 是针对当前情境的简短提醒。

原生能力足以完成的任务，直接做。缺业务事实，就补上下文。一个跨情境的取舍足够，就留作原则。只是这次有个边界容易忘，一句提醒也许已经够用。只有存在可辨认的重复判断问题，而且多条相关启发能提供独特帮助时，才有理由保留 Skill。

再往后，缺现实访问或操作能力，需要 Tool；真实权限、协议或完整性不变量需要保证，则应由确定性机制承担。没有生产访问，长 Skill 不能制造生产事实；需要对象授权，提示词也不能代替执行服务的校验。

这条顺序是增加复杂度前的举证责任，使用时不要求从第一层逐项试到最后。已有数据库约束就直接复用，已有授权下的事故止损也不必先补齐一套认知练习。

我想教的是判断

Teach judgment, not procedure. 我现在会用这句话检查正文：它是在告诉 Agent 普通操作怎么做，还是在说明什么差异会改变判断？常规 Git、搜索、编码和规划，默认交给原生能力。具体框架和协议资料按需查阅，项目的权限关系和负载事实则留在项目里。

以性能为例，值得保留的是区分等待与服务时间、判断负载是否代表用户、识别优化后瓶颈是否转移。某个 profiler 的命令语法可以查资料。把操作教学和专业取舍混在一起，既增加阅读量，也容易让随工具变化的细节看起来像永久原则。

Skill 还需要教会停止。如果原因已明确，继续展开系统诊断可能只会拖延修复；用户目标已经确定，重新要求需求访谈也可能妨碍工作。输出更长、更谨慎，并不能单独证明判断更好。

少用不是把成本假装成零

Praxis 项目安装默认只选择 Core，Expert 显式添加。按需加载正文能控制一部分成本，但已安装的名称和描述仍会参与选择；完整套件与项目副本共存，还会出现重复语义。没有自己的 Router，也不意味着宿主必定选对或自动去重。

目前测量的是静态字符和字节，以及有限单轮场景中的实际读取。真实 token、加载延迟、多轮累积与其它技能竞争仍未测量。更重要的成本可能是误触发、过度调查、冲突指导和打断用户，这些不能只靠文件大小估计。

我还在等待什么证据

Zero unnecessary skills 是我想守住的方向：每份指导都应该允许被更轻的方式替代。它并不表示当前十二份全部必要，也不表示它们全部多余。两种结论现在都没有足够证据。

接下来需要在真实任务里比较原生能力、相同项目上下文、短提醒和 Skill，观察关键决定是否改善，收益是否抵消成本。若一句提醒已经足够，退回提醒是合理结果。模型增强后，原来的指导也可能需要合并或删除。这是我目前的判断，仍需要真实 Dogfood 验证；我不想为了维护一套自己写的 Skills，反过来给它们寻找必须出场的任务。