很多 enterprise skills 在上线时看起来很好用，但很快就会退化，因为没有人真正负责更新闭环、复核策略和长期质量标准。
这篇指南帮助团队尽早把维护模型讲清楚，避免可复用能力在发布后迅速衰减。
为什么维护才是真正的扩张问题
一个 skill 的第一版往往不是最难的，真正困难的是上线之后：业务上下文变化、质量漂移、边界情况不断累积时，谁来接住这件事。
如果 owner 模糊，可复用能力很快就会从资产变成负担。
Owner 应该怎样定义
团队应明确谁负责内容更新、谁复核表现、谁批准结构性调整，以及什么时候这个 skill 应该被退休，而不是无限打补丁。
这些规则决定了 skill catalog 是否能在长期里保持可信。
FAQ
谁最适合先从这篇指南开始？
已经有 skills 在生产环境中运行，但缺少长期维护模型的团队，最适合先从这里开始。
什么时候该讨论维护模型？
应该在 skill 数量扩张到维护开始变成被动救火之前，就先把这件事讲清楚。