--- layout: post.njk source: https://yage.ai/share/team-context-infrastructure-20260423.html speaker: yage.ai title: 团队中共享 AI skills 的原则与方法 date: '2026-04-23' summary: 文章探讨了团队中共享AI技能的挑战与方法。提出了一种去中心化的知识管理体系，包含共享技能池、个人索引、AI驱动的扫描机制和引用追踪，以促进共识的自然涌现，而非强制收敛。最终目标是构建一个动态的“上下文基础设施”，使AI能成为领域内有洞察力的实践者。 area: tech-engineering category: ai-application tags: - ai-skills - team-collaboration - knowledge-management - context-infrastructure - personalized-ai people: [] companies_orgs: [] products_models: - ai-skills - context-infrastructure - semantic-layer - index-file media_books: [] draft: true status: evergreen --- 组织内部要积累知识，人数一多就容易出问题。两三个人的时候，共识靠聊天就能对齐，知识库基本上就是大家日常工作的延伸。人再多一点，同一个概念会冒出三四个说法，你也搞不清楚该信哪份文档。到后来维护的成本比使用的收益还高，要么指派一个人当唯一的维护者，要么大家各写各的，整件事慢慢就烂掉了。 内部 wiki 走过这条路，内部 CLI 走过，共享代码规范走过，一部分内部 BI 工具也走过。现在轮到 AI 的 skill 库。这篇文章的前作《Context Infrastructure》聊的是怎么把个人的认知攒成一套能喂给 AI 的资产，让 AI 输出超越 consensus 的分析。不过那篇里所有的机制都默认你只服务自己一个人。那怎么把它应用到团队身上呢？ ## 冲突从哪里来 Skill 系统在个人层面能成立，是因为它反映了你一个人的判断。你怎么理解某张表、怎么定义某个指标、碰到某类问题习惯走哪条 join 路径，这些加起来才让 AI 能给出 non-consensus 的分析。Skill 如果不 personalized，就退回成一份通用文档，AI 也就退回到 consensus 的默认行为。 所以 skill 必须 personalized，这条没得商量。 但到了团队场景，这件事马上变成麻烦。同一张 orders 表，两个分析师可以有两套都说得通但不一样的用法。同一个活跃用户指标，A 按七天算，B 按三十天算，两个人都没写错，但 Agent 生成的 query 会因此偏差。各人的 skill 都 check in 到一个目录里，AI 加载时会撞到互相矛盾的指令。都不 check in，团队层面什么都留不下来，新人进来还得从头学。 这就是核心矛盾所在：不个性化用不上，个性化了大家又打架。个人视角的价值和团队的知识积累，在现在这套机制下是互相拆台的。 ## 两种直觉上的应对，都走不远 碰到这个矛盾，直觉上的应对有两种。 第一种是搭一套大家认可的基础 skill 库，覆盖核心表、通用定义、跨团队共用的业务逻辑，剩下的每个人自己扩展。这样做推进起来快，不用额外搞审核。代价是知识还是攒在个人手里，团队层面基本没积累下来什么，新人进来照样得资深成员手把手带。 第二种是找专人，或者组一个小组，去收集、审核、合并大家的 skill 贡献，维护一份权威版本。这样做能攒下系统性的知识资产，一致性也有保障。代价是审核成本高到离谱，这本身就跟当初做这个工具的初衷反着来，而且团队里连 schema 文档都没人愿意补，更别说长期做这件事。 这两种应对看起来方向相反，但底下藏着同一个假设：团队知识最终应该收敛成一份权威版本。 第一种承认办不到，就放弃积累；第二种硬要办到，就得付出养不起的成本。 数据工程领域其实给过一个成熟的答案，叫 semantic layer。dbt、Looker、Holistics 这些工具的思路都是把 metric 定义抽到一个 Git 里的中央契约，所有下游查询强制走这一层。这套东西对大型数据团队很管用。不过它背后有一个隐含前提：你得有一个平台团队在专职养契约、跑 CI/CD、审每一次变更。换句话说，一个连 schema 文档都推不动的团队，也推不动 semantic layer。这条路本身是通的，只是它针对的是另一种场景，跟我们这里要讨论的对不上。 所以要换个问法：一份权威版本，真的是唯一合理的终点吗？ ## 换一个终点：让共识自己浮出来 松开”必须收敛”这个假设，另一种形态就出现了。 具体来说，每个人维护自己的 skill 集合，允许和别人重复，甚至允许和别人矛盾。团队不要求所有人用同一份定义，而是让共识在实际使用里自己浮出来。比如说，五个人的 skill 里都写了几乎一样的那张表的解释，这件事本身就说明它已经是团队知识了。某人写的一条 join 逻辑被另外三个人抄走了，它就在事实上成了 baseline。 这样的共识不靠中央审核，也不靠某个人长期维护。它要的是两样东西：每个人能看到别人写的 skill；AI 定期跨人比对这些 skill，告诉大家哪里重合、哪里分叉。 具体怎么做，我分成四个部件来讲。 ### 共享池和个人 INDEX 第一步，把存和用分开。 所有人把自己的 skill 放到同一个共享的地方（一个 Git repo 最自然，网盘或共享目录也行），每个人一个子文件夹，自己维护自己那份。共享空间允许不同人写的 skill 之间彼此矛盾，它只负责存。 加载这件事，由每个人的 INDEX 文件控制。INDEX 是个小清单，列出这个人当前认可、愿意让 AI 加载的 skill。AI 干活时只读这个人的 INDEX，共享池里其他人没被引用的部分根本进不了上下文。所以别人在共享池里写了什么、和你有没有矛盾，跟你的 Agent 行为完全没关系。 这里其实直接用上了 skill 系统本来就有的 progressive disclosure 特性。AI 本来就不会把所有 skill 一股脑加载进来，而是按需加载。个人 INDEX 做的事情，是把”按需”的边界从每次任务按需，扩展到每个人按需。 这样一来，每个人的 Agent 行为完全可控，共享池里又攒下了团队所有的 skill 原材料。两个需求原先互相拆台，现在可以共存。 ### 一份 baseline INDEX 作为起点 话说回来，新人进来从零挑 skill 不现实。所以共享池里还要额外维护一份 baseline INDEX，算是团队推荐的默认 skill 集合。新人拿这份作为起点，之后慢慢换成自己的版本。 这份 baseline 可以由团队负责人维护，也可以轮值。但关键是它不强制。任何人都可以改自己本地的 INDEX，用不用 baseline 随自己。它起的作用类似 editor 社区里的 oh-my-zsh 或 vim-sensible，一份比较合理的起点，仅此而已。 至于 baseline 怎么更新，要靠再下一个部件。 ### Heartbeat：AI 定期扫描 共享池和个人 INDEX 解决了存和用，但还没解决积累。所以还需要第三个部件：一个定期跑的扫描任务，完全交给 AI 做。 扫描本身很简单。AI 定期遍历所有人的 skill，用 semantic search 或者字符串匹配找出谈同一张表、同一个指标、同一类分析模式的条目，建一张相关性图。图里哪几条高度重合，AI 就给对应的几位作者各发一条提示：你和某某在 orders 表上重合度大概八成，主要差异在活跃用户的定义，要不要看看彼此的版本？ 注意，这个过程里 AI 不做强制合并，它只做两件事：发现重合、提示作者。要不要采纳、要不要合、合成什么样，全由作者自己决定。 这套机制背后，对应着 skill 积累的两种真实动力。一种是个人动力：我看了别人写的版本觉得有启发，自愿抄过来，或者修改自己的版本。大部分积累其实就是这么发生的。另一种是组织动力：团队负责人看到有几条 skill 已经高度重合、形成了事实共识，就把它升到 baseline INDEX 里去，让新人默认继承。这时候升上去的，不是一个被强推通过的版本，而是一个已经在日常使用里被验证过的版本。 两种动力都不靠全职维护者，也都不剥夺个人的 skill 自主权。但加起来，足够让团队知识逐年积累下来。 ### 引用的 skill 变了，怎么办 INDEX 里引用别人 skill 的方式有两种。一种是把别人写的内容抄到自己文件里，之后这份文件就跟源头断开了，源头怎么改跟自己没关系，语义上和自己写的无异。另一种是在 INDEX 里直接写上别人那个文件的相对路径，每次 AI 加载时现场读取源文件内容。后一种引用的好处是对方改进时你自动受益，坏处是对方改了可能让你的 AI 行为悄悄偏移，你还不知道。 这就需要第四个部件：一个定期跑的 review 任务，同样交给 AI 做。共享池在 Git 里，你引用了哪些别人的文件一目了然，改了什么 git log 和 git diff 里都记录着。AI 定期检查每个人 INDEX 里的跨人引用，看源文件有没有变化，有变化就判断风险等级。 分两档就够。低风险是这个 skill 的 success criteria 没变，只是作者又踩了几个新坑、补了一些 workaround。你引用的那份东西目的没变，只是更成熟了。AI 在日报里捎一句就行，不用打断你。高风险是这个 skill 长大到一定程度被拆成了两个，原来那份文件的承载范围变小了。这时候 AI 通过 email 或更强的通道主动提醒你，建议你在 INDEX 里把两个新文件都引上，免得漏掉原来覆盖的一部分场景。两档的切分标准很朴素：这次改动会不会让你原本依赖的行为丢失或走样。 Baseline INDEX 是一份被很多人引用的特殊条目，改动自动走高风险通道，不需要单独讨论。 讲到这里，多半会有一个疑问：这样不是在鼓励重复吗？工程师的本能是 DRY，代码里重复意味着 bug 要改两遍、接口要改两遍。 但 skill 不是代码，是 prompt。一份 skill 被十个人各自微调过，不会产生技术债，也不会出现接口不兼容的问题。反过来看，它保留了十种视角。遇到一个横跨多个业务线的分析任务，十种视角比一种唯一正确的版本更有用，因为你本来就需要看到不同作者对同一个指标的不同切法。 说到底，code reuse 优化的是机器层面的一致性。Skill 之间的关系应该优化的是人的启发性。目标函数不一样，把代码世界的习惯照搬过来，skill 库会失掉它最重要的属性。 ## Context Infra 作为一种岗位 再往上看一层。一个团队要把 skill 库认真用起来，上面这些部件（共享池、个人 INDEX、baseline、heartbeat、review）总得有人搭、有人维护、有人看着效果。这些事谁来做？ 想类比的话，可以看 Platform Engineering 那边的历史。早年每个产品团队都自己搭数据库、自己管部署，规模上来之后，才出现专门的 Infra 组把共性工作集中做。Context Infrastructure 很可能也在走同一条路。 不一样的地方在于，Context Infra 的大部分体力活可以交给 AI。扫描、比对、追踪引用变更、整理相关性图、给作者发通知，这些 AI 都能做。留给人的是几件更上层的事：设定 heartbeat 和 review 的节奏、写几条 meta-skill 教 AI 怎么判断重合和风险等级、审 AI 提出的合并建议、决定 baseline INDEX 往哪个方向演化。所以这个组不会很大，三五个人，甚至一两个人就够。 但和所有 Infra 组一样，它面临的挑战是能不能推得动。Infra 组的成败从来不是技术问题，是 adoption 问题。做得好的让全公司一起受益，做得差的就被所有产品团队绕着走。Context Infra 会碰到同样的测试。 我写这段不是在建议每家公司都成立一个 Context Infra 组。真正想说的是，如果你读到这里，已经在琢磨怎么把 context infrastructure 带进自己的团队，那你其实就是这个岗位的第一版。这件事没有现成的职位描述，也没有现成的 playbook，它的样子正在由你定义。 ## 总结 回到开头那个矛盾：个人视角和团队积累在现在的机制下互相拆台。这其实不是天然的矛盾，而是”必须收敛到一份权威版本”这个假设造成的。 松开这个假设之后，矛盾就消失了。共享池允许随便重叠，个人 INDEX 保证每个人的 Agent 行为可控，baseline 给新人一个合理起点但不逼他们用，heartbeat 让共识在日常使用里自己浮出来，review 盯住跨人引用的变化。四个部件里，没一个要全职维护者，没一个要 code review，也没一个要求团队成员让渡自己的视角。 往回看会发现，这篇和前作其实是一体两面，原则完全一样。核心机制只有一套：从大量素材里提炼 axiom，axiom 的筛选标准是稳定性。前作用的是时间维度的稳定，指的是同一个人在不同场景、不同时间反复出现的判断；这篇用的是空间维度的稳定，指的是不同人独立写出来的相同内容。筛选的过程都交给 heartbeat 驱动的 AI 去做。提炼出来的东西最终拼成一个可以动态加载、progressive disclosed 的 context infrastructure。维度不同，驱动引擎和产物结构是同一个。 有了这套基础设施，AI 就不再是一个 off-the-shelf 的 generalist，而是一个 informed practitioner，甚至在领域积累足够深的时候，成为一个 proprietary 的 insightful analyst。这才是 context infrastructure 真正的目标。