7.7
深览指数
产品人人都是产品经理·Serencry··AI 生成
从个人 Skill 到团队级 Skill：一个 B 端 PM 的 Vibe Coding 治理设想
本文提出了一套针对 AI 编程时代团队级 Skill 的治理框架，核心观点是治理目标不是“统一规则”而是“管理分歧”。作者借鉴 Git 分支模型，设计了“主分支（团队底线规则）+ 私有分支（个人偏好）+ 中间‘技能库’（按需检索）”的三层结构，并通过一次团队站会推演展示了规则模糊、场景缺口、平台例外三类典型治理动作。文章适合在产品、设计、工程团队中负责 AI 协作规范或工具链建设的深度读者，尤其是关注如何系统化而非口号式地管理团队 AI 协作的 PM。原文 ↗
核心观点
- ▍团队级 Skill 治理的终极价值不是“统一规则”，而是“管理分歧”，即让分歧能被显性化、结构化、有序处理。
- ▍治理机制的核心不是写一套完美规则，而是建立一套让规则能够持续演化的机制，其雏形可以是一个共享文档和一个周简会。
- 01文章借用 Git 分支模型，提出了“主分支（团队通用 Skill / 不能妥协的底线）+ 私有分支（个人 Skill / 主分支基础上增删）+ 合并到主分支机制（个人分支经验证明对团队有价值后提合并请求，团队评审）”的三层结构。
- 02规则合并与代码合并有本质区别：代码冲突可自动发现，规则冲突只能靠人脑判断是否逻辑互斥，因此每次合并需有人做“冲突审查”。
- 03一次团队推演（B 端 SaaS 团队试点 UI 风格底层框架，一周后开站会）暴露了三种典型分歧：规则模糊（“极简”不明确，精确化为“弹窗内表单字段不超过 3 个”）、场景缺口（客户侧看板不宜套用后台风格）、平台例外（移动端审批驳回场景弹窗优于抽屉）。
- 04作者提出了“技能库”作为主分支和私有分支之间的中间层：不强制生效，按需检索，入库仅需标注场景、规则类型和验证次数；一条规则从个人验证到技能库再到主分支，形成成长轨迹。
- 05治理机制分三阶段演化：第一阶段口头共识+简会；第二阶段结构化文档+场景标注（20条以上规则时）；第三阶段类代码工具（几十上百条时引入冲突检测、场景匹配等自动化能力）。
反方 / 局限
- — 作者承认推演阶段 PM A 提出的元问题“规则区分平台后，维护成本会不会上去？”当下无法回答，被记录为待解决事项，体现机制运行中会自然涌现需持续追踪的挑战。
- — 作者开头指出一个常见误区：将团队级 Skill 目标设定为“统一规则、消灭分歧”，而本文主张分歧本身合理，尤其在 B 端复杂产品场景下（不同端、不同角色用户需求天然不同）。
- — 文章自身定位为“推演和讨论阶段，离真正落地还有距离”，承认其设想尚缺乏大规模真实落地案例的验证。
Vibe CodingSkill 治理Git 分支模型主分支私有分支技能库Ant Design ProB 端 PM人人都是产品经理
8 分钟 · 5 卡片 · 9 资料
读原文 →