20 个章节 · 支持关键词组合搜索
技能与能力包发布
实践 / 建议能力库发布：把 Skill 当作有版本的工程资产
延续 fs-ai-hub 设计，补齐从源到运行的链路
推荐链路为：唯一源码 → 检查/评测 → 候选能力包 → 试点 → 固定版本目录 → TeamAI 安装 → 安装记录 → Multica 单次运行快照 → 漂移检测与回滚。 沿用 feeds/grafana 的 Catalog、Bundle、安装记录及 checksum 思路，减少新造格式。
能力包建议包含 Skill 与引用资源、工具/客户端兼容范围、输入输出合同、权限需求、 前置条件、终止条件、正负样例和变更说明。仅用于当前工程的 Skill 仍由当前工程维护。 fs-ai-hub 可以统一发现、订阅和发布；不能因此把诊断引擎和业务代码全搬进技能库。
已有来源如何处理
| 资产 | 维护源与发布安排 | 需要避免的错误 |
|---|---|---|
| 通用 code-search | fs-ai-hub；bug-finder 已采用完整副本、upstream-lock、漂移检查 | 在消费仓另起长期分叉 |
| 诊断/巡检/影响评估与 collector | bug-finder；统一目录登记固定能力版本 | 只拷贝 SKILL.md，漏掉运行协议、脚本和测试 |
| Golden Path 五角色与流程技能 | 现有 fs-multica-extensions / 网关工程 | 在 fs-ai-hub 再维护一套流程正文 |
| 项目 AGENTS、测试规则、局部技能 | 项目仓 | 分发时覆盖项目已有 .agents/skills 或客户端链接 |
| Online 独有技能 | 已声明的 Online 权威源 | 以本地目录为全集强制覆盖 Online |
TeamAI 上游已提供 role/project 订阅、固定 ref 和资源分发，但实际安装模式有兼容限制；
公司“禁止散放根级 skill”的约束可以保留，不应把上游根级资源语义简单解释为全员无条件安装。
同名技能有确定性解析，也仍应在发布前检测业务冲突。
sharing.rules.enforced 目前为空；即使配置了 enforced，也仍需 CI 和工具权限执行强制约束。
一次技能升级的操作剧本（建议）
- 维护者改源工程，回放历史成功、历史失败、误触发和无权限样例，检查引用资源完整性。
- 打候选包，记录上游 commit、包 digest、工具与模型配置、适用团队及不兼容变化。
- 在一个部门的代表任务试用，对比旧包的正确率、接管率和耗时，审阅失败轨迹。
- 通过后更新目录和消费者锁定 MR；安装器预览新增/删除/冲突，不吞掉本地未登记资产。
- 新任务采用新包；在途 run 保留原快照。异常时回退包指针并保留审计，不重写旧运行记录。
验收样例：同一任务在第二台干净 runtime 能装出相同资源、解析相同规则并通过代表测试。 符号链接、junction 或 copy 只是客户端适配；安装清单和内容摘要才是可检查的实际使用事实。
技能评测至少分四类
| 评测 | 应检验什么 | 如何判定 |
|---|---|---|
| 触发与路由 | 该触发、近义表达、相似但不该触发、岗位/范围冲突 | 固定正负样例，记录误触发与漏触发 |
| 工具与合同 | 输入校验、缺依赖、权限拒绝、超时、输出 schema | 确定性断言及负向夹具 |
| 任务结果 | 修复是否满足 验收标准、诊断是否支持事实、是否越界改动 | 行为测试为主，模型 judge 辅助，人抽样校准 |
| 真实运行回归 | 多轮、重启、重复事件、工具真实返回和环境变化 | 隔离环境端到端轨迹与最终状态 |
样例从真实失败脱敏沉淀，训练/提示调优样本与留出验收样本分开，定期补新故障类型。 同一用例重复执行时记录结果分布；既看能否偶尔做对，也看多次运行是否稳定。 固定模型、工具、规则和数据版本后比较新旧包，避免把模型变化误算为 Skill 改进。 硬约束与关键回归不通过就不发布；模型评分阈值先由人工样本校准，不独立决定高风险放行。 bug-finder 的结构自述、合成 fixture、同进程 tool-replay 和真实端到端结果应分开报表， 不能把较便宜的检查汇总成“已验证生产自主闭环”。
本节依据： code-search 维护源合同、Skill 开发与门禁；TeamAI U1 和 grafana L3a 见证据索引。