组织内部要积累知识，人数一多就容易出问题。两三个人的时候，共识靠聊天就能对齐，知识库基本上就是大家日常工作的延伸。人再多一点，同一个概念会冒出三四个说法，你也搞不清楚该信哪份文档。到后来维护的成本比使用的收益还高，要么指派一个人当唯一的维护者，要么大家各写各的，整件事慢慢就烂掉了。
内部 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，告诉大家哪里重合、哪里分叉。
具体怎么做，我分成四个部件来讲。
第一步，把存和用分开。
所有人把自己的 skill 放到同一个共享的地方（一个 Git repo 最自然，网盘或共享目录也行），每个人一个子文件夹，自己维护自己那份。共享空间允许不同人写的 skill 之间彼此矛盾，它只负责存。
加载这件事，由每个人的 INDEX 文件控制。INDEX 是个小清单，列出这个人当前认可、愿意让 AI 加载的 skill。AI 干活时只读这个人的 INDEX，共享池里其他人没被引用的部分根本进不了上下文。所以别人在共享池里写了什么、和你有没有矛盾，跟你的 Agent 行为完全没关系。
这里其实直接用上了 skill 系统本来就有的 progressive disclosure 特性。AI 本来就不会把所有 skill 一股脑加载进来，而是按需加载。个人 INDEX 做的事情，是把”按需”的边界从每次任务按需，扩展到每个人按需。
这样一来，每个人的 Agent 行为完全可控，共享池里又攒下了团队所有的 skill 原材料。两个需求原先互相拆台，现在可以共存。
话说回来，新人进来从零挑 skill 不现实。所以共享池里还要额外维护一份 baseline INDEX，算是团队推荐的默认 skill 集合。新人拿这份作为起点，之后慢慢换成自己的版本。
这份 baseline 可以由团队负责人维护，也可以轮值。但关键是它不强制。任何人都可以改自己本地的 INDEX，用不用 baseline 随自己。它起的作用类似 editor 社区里的 oh-my-zsh 或 vim-sensible，一份比较合理的起点，仅此而已。
至于 baseline 怎么更新，要靠再下一个部件。
共享池和个人 INDEX 解决了存和用，但还没解决积累。所以还需要第三个部件：一个定期跑的扫描任务，完全交给 AI 做。
扫描本身很简单。AI 定期遍历所有人的 skill，用 semantic search
或者字符串匹配找出谈同一张表、同一个指标、同一类分析模式的条目，建一张相关性图。图里哪几条高度重合，AI
就给对应的几位作者各发一条提示：你和某某在 orders
表上重合度大概八成，主要差异在活跃用户的定义，要不要看看彼此的版本？
注意，这个过程里 AI 不做强制合并，它只做两件事：发现重合、提示作者。要不要采纳、要不要合、合成什么样，全由作者自己决定。
这套机制背后，对应着 skill 积累的两种真实动力。一种是个人动力：我看了别人写的版本觉得有启发，自愿抄过来，或者修改自己的版本。大部分积累其实就是这么发生的。另一种是组织动力：团队负责人看到有几条 skill 已经高度重合、形成了事实共识，就把它升到 baseline INDEX 里去，让新人默认继承。这时候升上去的，不是一个被强推通过的版本，而是一个已经在日常使用里被验证过的版本。
两种动力都不靠全职维护者，也都不剥夺个人的 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 库会失掉它最重要的属性。
再往上看一层。一个团队要把 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 真正的目标。