20人团队的roles.yaml怎么写TeamAI角色设计完整模板【免费下载链接】teamai-cliMake Every Team AI Native项目地址: https://gitcode.com/GitHub_Trending/te/teamai-cliTeamAIteamai-cli是一款让每个团队 AI 原生化的开源 CLI 工具通过 Git 自动同步团队 Skills、Rules 和共享知识库。当团队规模扩大到 20 人后端同学的部署技能和前端同学的组件规范不该互相干扰——这时就需要在团队仓库的manifest/roles.yaml里设计好角色Roles让每个成员只拿到与自己职能相关的 AI 技能。本文将给出一个可直接套用的20 人团队 roles.yaml 模板并分享 5 条角色设计技巧。一、先搞懂 roles.yaml 的 3 个核心字段TeamAI 的角色本质是一个资源命名空间namespace白名单管理员在manifest/roles.yaml定义角色成员执行teamai roles set 角色后teamai pull只同步该角色命名空间下的 skills。一个角色只有 3 个字段极其简单字段作用示例id角色唯一标识也是 skills 子目录名backenddescription角色说明方便成员辨认后端服务与 API 开发resources可访问的知识/技能命名空间列表common, backend校验逻辑非常严格roles必须是非空数组、id不可重复、resources不可缺失否则teamai pull会直接报错——规则源码见 roles.ts。二、20 人团队的完整模板假设团队构成为10 名后端、6 名前端、2 名测试、1 名 DevOps、1 名架构师。推荐如下结构common是全员共享区这是关键设计version: 1 roles: - id: backend description: 后端服务与 API 开发 resources: knowledge: [common, backend] skills: [common, backend] - id: frontend description: 前端组件与页面开发 resources: knowledge: [common, frontend] skills: [common, frontend] - id: qa description: 测试与质量保障 resources: knowledge: [common, qa] skills: [common, qa, backend, frontend] - id: devops description: 基础设施与发布 resources: knowledge: [common, devops] skills: [common, devops, backend]对应的仓库目录结构就是角色即目录skills/ ├── common/ # 全员技能代码规范、Git 工作流 ├── backend/ # 后端专属接口脚手架、SQL 审查 ├── frontend/ # 前端专属组件生成、样式规范 ├── qa/ # 测试专属用例生成 └── devops/ # 运维专属部署脚本、发布检查 注意细节qa角色额外挂了backend, frontend——测试同学需要读两边代码这种跨角色只读正是 namespace 列表最灵活的用法。三、5 条角色设计技巧1. 一定留一个common公共命名空间代码评审规范、提交规范这类全员技能放common避免复制 4 份。这也是 roles-cmd.ts 中roles init的默认建议。2. 角色数量控制在 3~6 个按职能不按人20 人团队 ≠ 20 个角色。角色是职能抽象不是花名册。每人可选一个主角色primaryRole 若干附加角色additionalRoles例如架构师主角色backend 附加frontend即可获得两个命名空间的并集见 resolveRoleResourceNamespaces。3. 用tags补充临时兴趣而不是新增角色有人想临时学习运维技能让他teamai tags subscribe订阅打了标签的 skill 即可无需动 roles.yaml。标签订阅与角色正交是轻量补充通道。4. 经验learnings不需要按角色隔离一个常见误区想在 roles.yaml 里给learnings划命名空间。实际上 TeamAI 的 learnings 是全团队扁平共享的旧配置里的learnings字段会被忽略团队经验应该流动起来项目级经验隔离请用manifest/projects.yaml的 project 维度。5. 改动走 MR合并后自动生效所有teamai roles add/update/remove命令都会自动创建分支并发起 MR——角色变更天然经过团队评审这是 20 人协作不出错的关键机制。四、角色日常维护6 条命令走完全流程# 管理员交互式初始化 / 增删改自动开 MR teamai roles init teamai roles add devops --namespaces common,devops -d 基础设施与发布 teamai roles update backend --add-namespaces devops # 后端也看运维技能 teamai roles remove qa # 删除至少保留 1 个角色 # 成员查看并选择自己的角色 teamai roles list teamai roles set backend --add frontend # 主角色 附加角色 teamai pull # 同步新角色的 skills⚠️ 两个安全设计值得了解角色被删了怎么办配置了已删除角色的成员 pull 时不会报错而是安全降级为全量同步并提示重新选择见 rolesRemove 的警告逻辑。写坏了怎么办加--dry-run预览变更不落盘、不开 MR。五、常见问题速答Qroles.yaml 放哪里团队仓库的manifest/roles.yaml。该文件的存在同时是启用角色化 skills的开关——没有它所有 skills 全量同步给所有人。Qknowledge 和 skills 为什么要写两遍一样的列表两者分别控制知识文档与技能包的可访问范围通常保持一致如果某角色能看后端文档但不能用后端技能可以写成不同的列表。Q角色和项目projects是什么关系正交维度role回答我是干什么的project回答这个目录属于哪个项目成员实际拿到的是两者命名空间的并集详细说明见使用指南-多项目章节。六、总结设计要点一句话原则公共区common承载全员技能永远保留数量3~6 个职能角色不按人建跨职能用additionalRoles取并集不复制技能临时需求用tags订阅不污染角色定义变更流程命令自动开 MR团队评审后生效20 人团队的 roles.yaml 其实只需要 20 行 YAML。真正的设计智慧在于把谁能用什么 AI 技能变成一份可评审、可追溯、可回滚的团队契约。 延伸阅读docs/usage-guide.zh-CN.md完整使用指南、roles.tsmanifest 校验源码、roles.test.ts解析与兼容性测试用例【免费下载链接】teamai-cliMake Every Team AI Native项目地址: https://gitcode.com/GitHub_Trending/te/teamai-cli创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
