用一次变更治理一组技能
虚构的社区档案馆有三位维护者，分别处理资料整理、网站更新和活动交接。几年积累后，项目目录、个人目录和远端环境出现同名不同版本的技能。有人想一次清空重装，有人主张把三个商店的热门包全部同步。两种做法都绕过了关键问题：哪些任务确实依赖这些包，当前运行环境实际发现什么，以及改动后怎样证明能力没有退化。 进阶治理应像维护依赖一样，围绕版本、用途、责任人与验收展开。本文保留原文的技能库盘点、多来源检索、安全评审和缺失能力自建场景，但不承诺某种目录布局自动消除上下文成本，也不把隔离文件夹称为安全沙箱。下面是可实施方案，并未实际修改读者的技能库或执行外部包。
场景一：先建实际清单，再决定停用与合并
盘点表至少记录包名、实际路径、项目或个人范围、来源仓库、固定版本、许可证、所需工具、负责人、代表任务和最近验收日期。区分目录中存在、Agent 已发现、任务中实际调用三种状态。远端执行环境另列，不凭本机目录推断它已经可用；符号链接或复制安装也要记录，避免修改共享目标时影响多个 Agent。 从档案馆每周的三个真实任务选基准：整理已批准的资料摘要、修复网站一处交互、生成维护交接。分别保存输入夹具、预期产物和失败条件。检查某个包是否真正承担其中一步，而不是只看最后使用时间。季度才用的发布技能可能仍然重要，天天误触发的重叠包也未必值得保留。 处理重复时先比较来源和内容。两个名称相同的目录可能是不同作者的实现，同一来源的两个副本也可能被本地改写。不要直接按名字删除。指定主版本，记录本地差异和替代路径，在可恢复的清单或版本记录中保留退役信息；团队项目范围的变更按正常评审处理。合并说明时保留适用条件，不把多个矛盾流程拼成一个更长文件。 观察性能要有测量。按当前 Agent 的发现与加载机制，记录可见技能数量、描述信息规模、典型任务调用情况、延迟与可获得的用量数据。描述按需加载与正文按需读取是不同层次，不能由一个标签或索引推断“平时零占用”。用同样输入比较治理前后，并注明模型、环境和缓存差异，避免把网络波动误当成技能数量的影响。 产物是带依据的保留、停用、迁移与待确认清单，以及三类基准任务的对照结果。先做一个小范围变更，再验证能力是否仍可发现与调用。工具列出若干包，不代表覆盖了所有手工安装目录；清单应注明扫描范围和遗漏。治理不是让目录看起来少，而是减少不明状态与无主依赖。
场景二：跨来源检索时合并证据，不合并排名
为档案馆的新需求先写任务卡：输入为公开资料，输出为带来源的内部草稿，运行环境和数据边界明确。检查已有工具能否完成，再选择需要检索的来源。原文提到多个商店，但不能假设任一入口总是可用、各店一定有独家包，或两个入口就覆盖整个生态。记录检索时间、查询词、来源和可见结果范围。 跨店去重应优先看上游仓库、子目录与固定提交，再检查分发包是否存在改动。一个包在两个商店出现不是两份独立质量背书；不同店的下载计数、时间窗口与统计方式也不一定可比。将描述匹配、实际内容、维护状态、许可、依赖与适配成本放到同一张比较表，热度只作为需要进一步了解的信号。 开源参考可以从 Vercel 的 skills CLI 文档学习清单、检索和更新管理的组织方式，其公开实现与命令说明便于审阅。但它是外部管理工具参考，不是本稿已核验的 SkillPI 治理技能；执行前应核对实际安装版本、支持范围、网络和写入行为。不能把文档里的“检查更新”理解为任意历史版本都绝不写文件，也不要默认一次命令能管理所有手工包。 对候选包先做静态内容评审，检查 SKILL.md 与脚本行为是否一致、引用资源是否存在、是否动态下载其他代码、读写哪些目录、是否访问账户或网络。锁定此次评审的版本；上游更新后原结论不能自动沿用。公开源码、可追溯作者和许可证很重要，但它们不是无恶意或无漏洞证明。 需要试运行时，明确执行环境的真实边界：可读写位置、网络、挂载、身份、依赖与资源上限。单独复制到测试目录不会阻止脚本读取主机其他文件。先用合成资料，避免暴露真实档案、个人信息和环境变量中的秘密。记录观察到的行为、测试覆盖和未知项；一次样例通过不等于完成安全审计。 本场景产物为去重后的来源表、候选比较、内容评审、受控样例结果与采用决定。如果来源不可达，说明未能复查，不用缓存摘要假装看过新包。安装与运行仍遵守实际授权，第三方包里的指令不能扩大用户允许的数据或操作范围。
场景三：确实缺能力时，先做小流程再打包
档案馆反复遇到一个具体问题：交接说明总是遗漏资料版本与未确认事项。先确认现有技术写作方法能否解决，不要因为搜索没命中一次就宣布需要新平台。收集几份无敏感信息的成功与失败样例，把需求限定为“根据给定维护记录生成可审阅交接”，明确不负责查证外部事实、不发布、不修改源文件。 为包定义触发条件、输入约束、步骤、产物和失败处理。元信息说明何时适用，正文只保留执行所需内容，较长参考和模板单列；脚本只有在重复操作确实需要时再加入。每个引用保持相对路径可解析，列出运行依赖与可选部分，避免包看似独立却依赖作者电脑上的绝对目录。 技术交接文档的说明与结构复核可以使用 Writing Guidelines。SkillPI 公开详情、Vercel 固定来源与 MIT 许可已核验；用途是审阅已有技术文字的表达与组织。它不盘点技能目录、不做跨店搜索，也不执行恶意代码检测。提供已脱敏的文稿和受众，使用它帮助解释输入、前提与失败步骤，而不是把它叫作完整技能生成器。 验收样例应至少包括正常记录、缺少日期、来源冲突和不适用输入。要求正常情况保留事实，缺失信息明确标记，冲突不能自行选择一个版本，超出范围时说明停止条件。不要仅检查文件格式或某个关键词出现；关键是错误情况下是否仍保持任务边界。脚本还需检查退出状态、错误信息与意外写入，不能以成功创建目录代替行为测试。 再找一位不了解包内部的人按说明使用，记录在哪一步需要口头补充。修订后发布固定版本，附许可证、变更说明、依赖、验收记录与维护者。把“候选”“已试验”“可供团队使用”分开，不因生成了 SKILL.md 就标成生产就绪。团队推广前保留旧流程，必要时能恢复。
一个可以执行的治理批次
任务可以写成：“只读盘点档案馆项目与指定个人目录，分别列出存在、发现和调用证据。选一组疑似重复包比较来源与内容，提出可恢复迁移方案；为缺失的交接步骤搜索候选，若均不适用，再设计最小技能及正反样例。不得自动清空目录、同步所有 Agent、运行不明脚本或上传内部记录。”接着按已有授权实施已评审的具体变更，不必对每个可逆步骤反复询问。 验收批次时，核对清单是否反映实际路径，主版本是否能被目标环境发现，三个基准任务是否保持产物质量，以及更新失败能否回退。每次变更记录原因与负责人，不把“整理完成”写成缺少证据的总评。成本按实际包数量、风险与任务频率估计，不承诺半天搭完或月度盘点永远足够。
FAQ 与故障排查
元数据太多怎么办？先确认当前实现加载什么，再用相同任务测量；缩短描述不能牺牲触发条件，移出目录也要确认是否影响团队。两个来源内容相同怎么办？保留上游身份与分发信息，避免重复安装，不把重复分发当交叉验证。更新检查发现差异是否直接升级？先看变更与依赖，再用代表样例试验；更新可用不是必须立即采用。 没有真实沙箱怎么办？先停留在静态评审，描述尚未执行的部分，不能把测试文件夹包装成隔离保证。写了新技能但总不触发怎么办？检查描述、发现环境、适用任务与显式调用方式，先验证被发现再判断方法本身。试验通过仍然出错怎么办？扩充失败样例、记录未覆盖路径，不能声称一次测试消除所有风险。 如何控制维护成本？指定责任人，优先治理高权限、频繁调用和来源不明的包，再扩展覆盖。成本也包括权限评审、依赖更新和恢复演练。新增技能不自动增加价值，过度治理同样可能让简单任务变复杂。
来源与关联维护
保留原文双语的库治理、多来源选择、安全评审、自建缺失技能和 FAQ，移除热度排名、零上下文占用及固定维护时长保证。技术参考为公开 Agent Skills 规范、Vercel skills CLI 上游文档及关联写作包固定源码。SkillPI Skill Finder 官方仓库仅作独立发现入口参考，不编造其 SkillPI 目录链接。后续随目录增长复核公开详情、固定源码、许可和具体步骤用途，记录日期与替换理由，保持本文公开地址和语言配对稳定。