当个人技能演变为团队资产，版本冲突与理念分歧便成为不可避免的挑战。本文深入探讨团队级 Skill 治理机制，从软件工程的分支管理中汲取灵感，提出主分支与私有分支的协同方案，并设想技能库作为规则孵化器的可能性。这是一场关于如何在 AI 协作时代系统管理分歧的前瞻思考。

感谢资深产品经理@踮起脚尖。在上篇关于 vibe coding 的讨论中，他提出了一个被很多人忽略的关键问题：当技能从个人资产变成团队资产后，版本冲突和理念分歧会浮现。如果团队里每个人都维护自己的 rule 文件，协作时反而会增加认知负担。有没有可能建立一套团队级别的 Skill 治理机制？这个问题，促成了本文的全部思考。

上一篇文章聊了如何培育个人的 vibe coding 协作 Skill。这篇文章想往前再走一步：当 Skill 从一个人的工具箱，变成一群人共享的基础设施时，会发生什么？我们能从软件工程的分支管理、开源社区的治理实践中借来什么思路？

一、团队级 Skill 的核心挑战：管理分歧，而非统一规则

个人 Skill 解决的是“把隐性判断力外化成 AI 可执行的规则”。它的逻辑是私有的、单人的、不需要说服任何人的。但一旦要变成“团队资产”，那些原本藏在个人习惯里的分歧就全浮上来了——你觉得信息密度是第一原则，他觉得可读性和留白才是；你认为所有金额必须二次确认，他觉得高频小额场景这样做会拖死体验。

这里有一个很容易踩进去的误区：把团队级 Skill 的目标设定为“统一规则、消灭分歧”。但 B 端产品的复杂之处在于，分歧本身是合理的。做后台的和做客户侧的，对“好界面”的定义天然不同；做桌面端和做移动端的，交互约束天然不同。强行统一，要么统一在某个人的偏好下，要么统一在一个谁都不满意的折中方案上。

因此，团队级 Skill 治理的终极价值，不是“统一规则”，而是让分歧可以被管理。

这意味着建立一套机制，让分歧能够：被显性化（知道我们在哪里意见不一致），被结构化（不是“我觉得你不对”，而是“在 XX 场景下你的规则不适用”），被有序处理（不是吵架，而是标记、讨论、决策、迭代）。

判断一个分歧该不该被管理，有一个简单的标准：这个分歧如果不解决，会不会影响其他人？会影响，就进主分支讨论；不影响，就允许在私有分支里保留多样性。

二、借用 Git 的分支模型：主分支、私有分支与合并机制

那位资深 PM 提出的“版本冲突和理念分歧”，天然让人联想到软件工程里的分支管理。事实上，用“主分支 + 私有分支”的逻辑来管理团队 Skill，是一个可以借用的成熟范式。

这套模型有三层结构：

1. 主分支（团队通用 Skill）：约束的是“不能妥协的底线”。比如 UI 风格必须参考某个 Design System，所有涉及金额的操作必须有二次确认，敏感字段必须标注“待业务确认”。规则少而精，每一条都是团队共识的产物，不允许随便改。
2. 私有分支（个人 Skill）：每个人在自己的项目里，可以在主分支的基础上加自己的规则。不和主分支冲突即可，个人可以随意增删。
3. 合并到主分支的机制：当个人分支里的某条规则，经过多个项目的验证，证明对团队其他人也有价值，就可以提一个“合并请求”。团队评审通过后合入主分支，其他人下次拉取就能用到。

这套逻辑的精髓在于：主分支的规则不是开会拍脑袋定的，而是从一线实战中“长”出来的、被验证过的好东西。

但规则合并和代码合并有一个本质区别：代码冲突可以用 diff 工具自动发现，规则冲突只能靠人脑判断。两条规则可能文本上毫无矛盾，但组合执行时逻辑互斥。这意味着每次合并到主分支，必须有人做“冲突审查”——不是看文本有没有冲突，而是看逻辑上会不会打架。这个人的角色，类似于开源项目里的 maintainer。

三、一次简短的推演：试点第一周的 15 分钟站会

为了验证这套机制能不能跑起来，我们在团队内部做了一次推演。场景设定为一个 B 端 SaaS 产品团队，试点模块是“UI 风格底层框架”，已确定三条铁律，运行一周后开第一次站会。

站会上暴露了三种典型分歧，也对应了三种治理动作：

第一种：规则模糊。PM A 反馈铁律里“弹窗只用于极简表单”的“极简”一词太模糊，AI 无法执行。团队快速共识将其精确化为“弹窗内表单字段不超过 3 个，不含表格、富文本、分步表单”，直接合入主分支。治理动作：将模糊约束精确化。

第二种：场景缺口。PM B 做的客户侧看板，在“参考 Ant Design Pro 后台风格”这条铁律下产出的页面像操作后台。这不是规则错了，而是场景覆盖有缺口。团队新增一条规则“客户侧可适度降低信息密度”，与原有铁律并列，各自标注适用场景。治理动作：新增场景分支，而非推翻原规则。

第三种：平台例外。PM C 在移动端审批驳回场景下主动用了弹窗而非抽屉，理由是移动端抽屉体验很差。团队没有直接修改铁律，而是先以“平台特例”标记，约定下次再评审是否正式写入主分支。治理动作：面对例外，先标记、观察、再决定是否修改。

站会结束前，PM A 提了一个元问题：“规则区分平台后，维护成本会不会上去？”这个问题当下无法回答，但被记录为“待解决事项”。这本身就是一个值得关注的点：治理机制运行中会自然浮现元问题，机制的健康程度取决于它能不能接住这些问题，而不是忽略它们。

四、超越主分支：Skill 技能库的设想

主分支只能容纳“对所有人都适用”的规则。但现实中，大量的好规则是“对某一类场景适用，但不是全场景”。比如一套高密度表单布局规则，对做后台配置工具的 PM 是利器，对做客户侧看板的 PM 却是负担。

于是我们提出一个设想：在主分支和私有分支之间，增加一个“Skill 技能库”作为中间层。

• 主分支：强制生效，每一条都是团队共识，规则之间不能冲突。
• 技能库：按需检索。不强制生效，但当你遇到一个具体场景时，可以去库里搜“有没有人已经解决过类似问题”，找到后自己决定是否引用。入库不需要严格评审，只需要标注清楚场景、规则类型、设计系统依赖和验证次数。

一条规则的成长轨迹可能是：在个人项目中被验证有效 → 提交到技能库 → 被其他 PM 检索、引用、再次验证 → 累积足够验证次数后，讨论是否合入主分支。

技能库充当了规则的“孵化器”和“试炼场”。主分支的规则不再是一拍脑袋定的，而是从技能库里“杀”出来的、被多人验证过的规则。

五、治理机制的演化路径：从简会到类代码工具

治理机制本身也是一个需要逐步演化的东西。一上来就追求完美的规则体系和自动化工具，是绝大多数团队规范失败的原因。

我们设想了三个阶段：

第一阶段：口头共识 + 简会。最轻量的启动方式。团队有一个共享文档，记着三五条“铁律”。每周或每两周花 15 分钟聊聊：有没有新规则值得加？旧规则有没有需要改的？这个阶段的重点是养成“规则是可以被讨论和修改”的习惯。

第二阶段：结构化文档 + 场景标注。当规则积累到 20 条以上，需要结构化仓库，每条规则强制带场景标注和不适场景。简会从“讨论规则怎么写”变成“讨论规则的适用边界”。

第三阶段：类代码工具。当规则数量达到几十上百条，且存在复杂场景分支时，可能需要冲突检测、依赖分析、版本追溯、场景匹配推荐等自动化能力。但工具的引入不能过早——简会阶段培养的是“治理习惯”，工具只是习惯成熟后的效率放大器，不是习惯的替代品。

六、写在最后

回到最开始那位资深 PM 的问题：有没有可能建立一套团队级别的 Skill 治理机制？

我们认为有可能，但它的核心不是“写一套完美的规则”，而是建立一套让规则能够持续演化的机制。这套机制的雏形可以很简单——一个共享文档、一个周简会、三条铁律。它的成长方向也足够清晰——技能库、场景标注、类代码工具。

这篇文章里的设想，大部分还在推演和讨论阶段，离真正落地还有距离。但这种讨论本身就有价值：当 AI 编程工具正在重塑产品经理的工作方式时，我们不仅需要学会如何使用工具，更需要思考如何以团队为单位，系统性地管理我们与 AI 的协作方式。

这或许才是 vibe coding 时代，产品经理值得投入的思考之一。