团队共享约定：标准化模板库
系列入口：如何使用 Agent。M10 第 2 篇；紧接团队推广路线图。
一、为什么需要统一模板
没有统一约定时，团队会迅速长出一堆"方言"：规则文件每人写法不同、Skill 名字和结构各异、子 Agent 职责重叠、命令参数风格不统一。后果是资产无法互相阅读和复用，维护成本翻倍，新人面对一堆约定俗成却没有文档的东西。
标准化模板解决的不是"审美统一"，而是让这些资产可预测、可组合、可治理：任何人拿到一个 Skill 都知道去哪看描述、入口、边界；任何子 Agent 都遵循相同的职责定义方式。统一让协作和复用的摩擦力降到最低。
二、模板库应包含什么
一个实用的团队模板库，通常覆盖四类资产，每类配一个"标准骨架"。
规则文件模板：分层结构（团队级 / 项目级 / 模块级）、统一的章节（项目概述、技术栈与命令、编码约定、禁区与安全、如何验收），并讲清与私有个人规则的边界。Skill 模板：标准的元信息（name/description）、适用场景、触发方式、正文与渐进式披露结构，命名与目录规范。
子 Agent 模板：明确角色定位、可用工具与权限边界、输入输出契约、何时该升级回主 Agent 或人工。斜杠命令模板：统一的参数占位写法、描述、示例。每个模板都应带填写说明和一个真实范例，让大家照着填空就能产出合格资产，而不是对着空文档无从下笔。
三、命名、结构与单一事实来源
统一的命名约定极重要：见名知意、避免同义多名（同一个意图别出现三个不同命令名）、最好有前缀或分类以避免冲突。结构上约定每类资产的标准目录和必备字段，使检索和自动加载可靠。
坚持单一事实来源：同一条约定只在一个权威文件里定义，其他地方引用，避免多份拷贝一改全漏。模板库本身应纳入版本控制，变更走评审——因为这些资产会影响整个团队的产出质量，改动应可追溯、可讨论，而不是某人随手覆盖。
四、让模板被真正使用而非束之高阁
模板最大的失败是建完没人用。推动复用的关键：
- 从真实高频场景抽取：模板应来自被验证有效的实践，而非凭空设计。
- 一键脚手架：提供命令快速生成合规模板骨架，降低使用门槛。
- CI 校验：检查资产是否符合结构约定（必填字段、命名规范），不合格即提示。
- 可发现：有索引/目录让人知道"库里已经有什么"，避免重复造轮子。
让"先查模板库、复用或在其基础上改"成为默认习惯，而不是各自另起炉灶。
五、统一与差异的平衡
全组织强推一套过细的模板，会压制不同技术栈和团队的合理差异。更稳妥的是分层：核心层统一——安全红线、必备字段、命名与互操作规范全员一致；团队层可定制——具体命令、技术栈相关 Skill 由各团队按需扩展，但遵守统一骨架。这样既保证资产能跨团队互通，又不强迫用 Java 的团队照搬前端的细节。模板库应留出清晰的扩展机制，而不是非黑即白。
六、模板的"最小必填"该有哪些
模板设计有个分寸问题：字段太少，起不到统一和校验作用；字段太多，使用者嫌烦就绕开。把握的关键是区分"真正影响复用和安全的最小必填"与"可选的补充信息"。
对绝大多数资产，几个必填项是共通的：清晰的名称与描述——描述要写明"何时该用、何时不该用"，因为它往往也决定能否被自动触发或检索；职责与范围——尤其子 Agent 和 Skill，要写清做什么、不做什么，防止边界蔓延；输入输出契约——期望接收什么、产出什么格式，让它们能被可靠组合；权限与风险——可访问哪些工具/数据、有无危险操作需要确认。这几项直接关系到资产能否被他人理解、组合和安全使用，缺一不可。
而像作者、版本备注、示例扩展、性能提示等可作为可选字段，鼓励但不强制。一个检验标准是：去掉某字段后，他人是否仍能正确、安全地复用它？ 若会误用，就应保留为必填；若不影响，就别增加填表负担。把必填压到最小、再配一个已填好的真实范例，人们才会愿意遵守，模板也才能真正落地而不被规避。
七、随反馈持续迭代
模板库是活的。建立轻量的反馈与演进机制：定期看哪些模板高频被用、哪些从没动过（可能不好用或不需要）、使用中暴露了什么缺陷；由使用者贡献改进、经评审合并。把生产中出现的典型问题反映为模板的默认约束，让每一次事故都提高整个资产库的下限。
七、常见问题
Q：模板会不会限制发挥？ 模板管的是结构与必备信息，不管具体内容；它减少重复劳动，反而让人把精力放在真正有创造性的部分。成熟后也可在合规前提下扩展。
Q：已有一堆不规范资产，要一次性重写吗？ 不必。先立标准、用在新建资产上，旧的随每次触碰渐进迁移，避免大规模冻结式整改。
Q：怎么防止库里出现大量重复 Skill？ 用可发现的索引 + 提交前查重 + 评审，鼓励在已有资产上改进而非新建；定期合并重叠项。
Q：模板库谁来维护？ 可设少量维护者把关结构与评审，但内容由全体使用者贡献，避免变成单点负担或与实际脱节。
八、模板库的治理与演进机制
模板库要长期可信，需要一套轻量治理机制，否则它会在大家随手修改中逐渐走样、或因无人维护而僵化。
明确把关角色：少量维护者负责结构一致性、评审和合并，但鼓励全员贡献内容，避免既成为单点瓶颈、又与实际脱节。走变更评审：对会影响全团队产出的模板修改，像代码一样评审、可追溯，重大变更说明原因和影响。定期清理：移除长期无人使用或已过时的模板、合并高度重叠的项，保持库的精简和可发现性。
版本与迁移：模板结构升级时，给出平滑迁移旧资产的方式，而非强制一次性重写。建立反馈入口：让使用者能方便地报告"这个模板不好用/缺字段"，让库紧贴真实需要。治理的目标是让模板库既统一稳定、又保持鲜活——它是团队协作的公共基础设施，值得像对待核心代码一样长期经营。
九、让新成员快速上手模板库
模板库再完善，若新人不知道怎么用，仍会各写一套。降低上手成本是它真正发挥作用的关键。
有清晰入口和索引：一页说明"有哪些资产、各自用途、遇到什么任务先查哪里"，避免面对一堆文件不知从何下手。一键脚手架 + 范例：用命令生成骨架，并在每个模板旁放一个真实填好的例子，照着改即可。把规则做进 CI：结构不合规时自动提示，让学习发生在提交当下，而不是靠评审口头纠正。
配对答疑：新人前几次贡献有人带，快速建立感觉。目标是让"复用模板"成为阻力最小的路径——当照着做比自己另写更快更省心，统一约定自然会被遵守，模板库才不会只在老成员中转、对新人却形同虚设。
十、安全与权限约定不可缺席
模板库统一的不只是写法，更应把安全边界固化进每个相关资产，避免各团队在权限上各自踩坑。
子 Agent 和命令模板中应明确可用工具、数据范围和高危操作的确认要求，默认最小权限；涉及敏感数据的资产要标注合规边界。让这些约束随模板开箱即用、并由 CI 或运行时校验，比事后口头强调可靠得多。统一约定的一大价值，正是把分散的安全经验变成所有人默认继承的底线，让复用资产在提高效率的同时不放大风险。
十一、防止重复与过度膨胀
资产库长大之后，重复和冗余会迅速侵蚀可发现性，需要持续治理。
提交前查已有索引、评审中拦截同义新建、定期合并重叠项并移除无人使用的模板；新增资产应回答"它失败时守护了什么独特价值"。保持库的精简，复用才能真正发生——一个臃肿、找不到东西的库和没有库一样会逼人另起炉灶。
十二、与企业治理的衔接
共享模板库同时也是企业治理的落点——统一的资产结构让访问控制、审计与数据合规能够规模化地生效。
在模板中固化最小权限、敏感操作确认和数据边界，使每个复用资产的团队默认继承安全要求；资产的版本化与评审则为审计提供轨迹。约定与治理并非两件事，治理通过统一模板落到一线，而模板因治理获得权威。 当团队把这套库作为协作默认，安全与效率才真正被一起交付，而不是在规模化后相互冲突。
Q：不同工具链（不同 Agent 产品）约定能统一吗？ 统一的应是与工具无关的原则与信息模型（职责、输入输出、权限、单一事实来源），具体声明语法按各工具适配；这样即使将来更换工具，团队沉淀的约定和资产也能迁移，不被单一产品锁死。
十三、检查清单
- 四类资产（规则/Skill/子 Agent/命令）都有标准骨架与范例。
- 统一命名、目录与必备字段，约定与私有规则的边界。
- 坚持单一事实来源，模板库版本化、变更走评审。
- 提供脚手架与可发现索引，CI 校验结构合规。
- 核心统一、团队可扩展，按使用反馈持续迭代。
总结
团队共享约定的核心，是用标准化模板把个人"方言"变成可复用、可治理的公共资产：为规则文件、Skill、子 Agent 和斜杠命令各定一套带范例的标准骨架与命名契约，坚持单一事实来源并纳入版本控制和评审，再用脚手架、可发现索引和 CI 校验让大家真正复用而不是重复造轮子；同时采用"核心规范全员统一、具体内容团队可扩展"的分层策略，并随真实反馈持续迭代，模板库才能既消除协作浪费、又不压制各团队的合理差异。