搭建并维护适用于各种 AI 的技能库

## 分好文件夹，让技能的详细内容只在用到时加载 为每项技能设置独立目录，其中包含主指令文件、必需的元数据，以及可选的参考资料和脚本目录。将完整示例、研究材料、规范模板和集合级文档分别放在清晰分隔的位置。维护一份根级技能索引，使用户或智能体无需加载每项技能的正文就能浏览整个集合。 将名称和描述作为启动索引。只有在技能激活后，才加载详细指令、参考资料和脚本。这种结构既能将注意力留给当前任务，又能在需要时提供更深入的材料。 ## 让技能主文件保持简短，在任何工具中都能用 将技能的主指令文件控制在500行以内，并把详细材料移入参考资料。要求YAML元数据包含名称和第三人称描述，目录名使用小写字母并以连字符分隔，同时审视每个段落是否具有足够的信息价值。除非技能明确教授基础知识，否则应假定受众具备较高水平。 编写不依赖具体平台的指导。除非平台限制不可或缺，否则应抽象供应商专用工具；示例也应具备可移植性，不要把概念性伪代码当作可直接用于生产的代码。 ## 写清每项技能什么时候用、什么时候不用 设置激活条件、核心概念、实践指导、示例、准则、易错点、集成和参考资料等章节。每个激活章节都必须说明正向触发条件和禁止激活的边界，并将相邻工作引导至正确的技能。 尤其重视来自实践经验的易错点，因为它们记录了通用指导经常遗漏的失败模式。在集成指导中，如果链接会因安装布局不同而失效，应使用稳定的纯文本名称引用其他技能。 ## 修改技能时，一起更新列表和数字的来源 新增或更改技能时，同时更新集合概览、分发清单和语料索引。将技能映射到其激活场景、可复用的行为机制和支撑主张，使发现、打包和评估描述的是同一个产物。 为数值、基准、易变信息或供应商性能相关主张记录来源。每当技能引入可复用的行为变化或需要证据支撑的论断时，都要更新机制登记表和主张登记表；不得只在正文中隐含这些关系。 ## 让 AI 判断之前，先运行固定的自动检查 接受变更之前，运行仓库声明的检查，以验证元数据解析、严格模式与语料结构、兼容平台的安装布局、技能正文健康状况、激活边界和对抗性基准。将这些检查视为评审关卡，而不是可选的诊断。 先以确定性方式验证结构、清单同步、评分规则运算、检索状态和登记表结构。只有这些检查通过后才能使用基于模型的判断，并且不得用模型判断为可复现的结构性失败开脱。 ## 每个示例项目都用它自己的安装和测试命令 如果仓库没有顶层构建系统，就不得自行创建一个。识别每个示例或子项目声明的运行时和包管理器，然后使用其自身的设置、构建、测试、代码检查、格式化和类型检查命令。将环境和依赖项限定在对应子项目内。 迭代时先运行范围最小且相关的命令，评审前再完成子项目文档规定的整套关卡。区分编译、单元测试、异步测试、代码检查、格式化和静态类型检查，不要把一条命令成功当作所有关卡都已通过的证明。 ## 用提供的工具，按固定阶段推进每次研究 通过提供的生命周期工具初始化每次研究运行，使其以一致方式创建状态文件、队列条目、线程日志、来源评估框架和机制提案模板。使用受支持的状态转换依次推进检索、评估、提案、新颖性评审、运行验证、评审就绪和关闭；绝不能手动编辑运行状态。 应独立于仓库级关卡验证处于活动状态的运行。只有在运行已就绪、所需评审者已有记录并且就绪检查通过后，才能提升提议的机制。在数值、基准或易变主张进入技能之前，先补充其来源记录。 ## 自动循环的研究在定好预算前不调用付费 AI 无论循环由人工启动还是由特定平台的调度器启动，都要提供用于发现、单步推进、每日处理和状态报告的确定性命令。确保检索无需调用付费模型也能使用；在建立明确的预算关卡之前，不得从无人值守的循环中调用付费模型。 将队列、运行时日志、快照、状态报告、暂缓的评审、事件流、失败记录和普通运行目录视为运行状态，而不是源文件。除非是经过审慎指定的种子运行，否则绝不能提交这些内容。 ## 把相关技能打成一个包，而不是复制多份 如果宿主会分别缓存每个插件的全部源文件，应通过一个软件包分发一组相关技能，而不要让多个软件包指向同一源代码树。这样既能避免重复缓存，也能维持统一的版本和清单边界。 启动时只公开发现技能所需的元数据。将完整技能正文和支撑资源延迟到激活后再加载，避免软件包的广度转化为永久的上下文负担。 ## 精简交给 AI 的资料，发送更改（push）前先取得人的同意 优先保证上下文质量，而不是上下文数量：注意力有限且中间位置的信息容易丢失，更多材料反而可能降低表现。使用子智能体为有明确边界的工作隔离注意力，而不是仅仅模仿组织角色。让概念性示例保持可移植性，例如使用与语言无关或普遍易读的伪代码。 让确定性证据先于模型判断，并将远程发布置于人工控制之下。智能体可以准备变更并通过所有本地关卡，但在推送或合并之前必须获得明确的人工批准。