过去团队也会共享知识。有人写 wiki，有人补 FAQ，有人沉淀规范，还有人负责维护各种“唯一权威口径”。这些事不是没价值，但做过的人都知道，它们最后总会碰到同一个问题：团队越大，知识越多，冲突越多，维护成本越高，最后要么变成没人信的资料库，要么变成少数几个人维护的瓶颈。
所以我一开始看鸭哥那篇《团队中共享 AI skills 的原则与方法》，并没有把重点放在“这套目录怎么建”。真正让我觉得值得往下想的，是它实际上动了一个更深的前提：团队知识不一定非得先统一，才能被共享。
这件事一旦成立，AI 时代的团队知识库就和传统 wiki 不是一个物种了。
传统知识库管理的是信息，AI 时代管理的是行为
传统知识库的目标很明确：把信息写下来，方便人去查。最好的状态通常是一份统一定义，一份标准口径，一套大家都能接受的说法。它服务的对象首先是人，所以它天然追求可读、可查、可统一。
但 AI 时代不一样了。你写下来的东西，不只是给人看，还会被 Agent 拿去当运行时上下文。它会影响 AI 选什么工具、走什么路径、按什么口径解释问题、输出什么风格。也就是说，知识不再只是“描述世界”，而开始“塑造行为”。
传统团队知识库在解决“信息怎么保存”。
AI-oriented Context Infrastructure 在解决“组织经验怎样在任务执行时被稳定调用”。
这就是我觉得最本质的结构变化。对象变了，治理方式就一定会变。
真正被打碎的，不是文档格式，是“唯一权威版本”这个幻想
鸭哥文章里最有价值的地方，在我看来不是共享池，不是 baseline，也不是 heartbeat，而是它公开放弃了“团队知识最终应该收敛成一份权威版本”这个假设。
过去我们处理知识冲突，第一反应通常是合并。两个人对同一个指标有两种说法，那就拉会对齐，定一套标准，然后写进文档。这个逻辑在很多场景都成立，尤其是财务、合规、监管这种必须统一的东西。
但放到 skill 这类 AI 资产上，问题就出来了。因为 skill 的价值恰恰来自个人判断。一个分析师怎么理解某张表，另一个工程师怎么定义一个故障路径，第三个人怎么做代码审查，这些东西很多时候不是“谁对谁错”，而是带任务语境的工作偏好。你把它们过早磨平，最后沉淀下来的往往只剩 consensus，而 consensus 恰恰是 AI 最不缺的东西。
所以文章里那个“共享池负责存，个人 INDEX 决定加载”的设计，我觉得很对。它不是简单地把个人知识拿出来共享，而是第一次把“共享”和“统一”拆开了。
冲突在这里不再只是问题，而是系统信号
我越来越觉得，AI 时代很多过去要被消灭的东西，现在反而应该被保存下来。
重复是一种信号。五个人都写了差不多的 skill，说明这件事已经接近团队共识了。分叉也是一种信号。同一个对象有三种不同写法，说明这里要么存在真实的任务差异，要么还没有形成稳定共识。以前这些东西会被知识库管理员当成脏数据，现在反而可以成为治理输入。
这也是为什么我会觉得 heartbeat 这个思路很重要。它不是替人做裁判，而是先替团队做观察员：哪里高度重合，哪里明显分叉，哪些 skill 被频繁引用，哪些 baseline 已经过时。AI 第一次不只是知识使用者，也开始变成知识系统的维护者了。
AI 没有降低知识维护成本，只是改写了成本结构
很多人会直觉觉得，AI 这么强了，知识维护应该更轻了。我的判断正好相反：它没有让维护变轻，只是让维护的重点换了地方。
传统 wiki 的核心成本在写和更新。谁来写，谁愿意持续更新，谁来处理冲突。这是典型的人工编辑成本。
到了 AI 这里，新增的反而是运行成本和治理成本。你要考虑的事情会变成：哪些上下文默认加载，版本怎么定位和回滚，被引用的 skill 改了以后会影响谁，哪些记忆该保留多久，改完之后怎样证明 Agent 行为更好了而不是更飘了。
这也是为什么现在很多厂商开始把 prompt sharing、multi-agent orchestration、memory service 这些能力做成产品层。Google 已经把保存与共享 prompt做成显式能力。微软在讲multi-agent patterns时，已经不是在讲聊天体验，而是在讲任务委派和结构化协作。AWS 甚至把memory configuration直接做成了参数。
这背后其实在说明同一件事：团队真正要维护的，不再是一堆静态资料，而是一套可执行的上下文系统。
公司级 Context Infra，应该先建什么
如果站在公司层面，我会把这件事拆成五层。
最上面是组织硬规则。安全、合规、品牌、权限边界，这些必须统一，不能交给每个人各写各的。
第二层是 baseline。也就是团队推荐默认集。新人不需要从零开始，老手也不必被它绑死。它像一个比较合理的起点，不是唯一正确答案。
第三层是 personal overlay。真正值钱的 knowhow 很多都在这里。一个团队如果只剩 baseline，没有个人扩展，最后只会沉淀出一种“正确但没味道”的平均版本。
第四层是 activation。也就是在什么任务下加载什么，哪层覆盖哪层，什么是默认启用，什么只是候选能力。没有这一层，所有 skills 再多也只是一个仓库，不是 infra。
最后一层是 evaluation。哪条规则改了之后真的更好，哪些失败样本应该沉淀为新 skill，哪些 baseline 应该晋升，哪些要回滚。没有评测闭环，所有升级最后都会退化成感觉。
公司级 Context Infra 的重点，不是先做一个更大的知识中心。
而是先做一套允许分叉、能自动观察、能逐步晋升共识的上下文编排系统。
为什么很多老问题会在 AI 面前重新长出来
你如果回头看，会发现很多问题其实并不新。知识冲突、定义漂移、维护成本、标准与灵活性的拉扯，这些过去在 wiki、语义层、规范库里都出现过。
真正变化的地方在于，这些问题第一次直接进入执行层了。过去文档冲突，影响的是人理解得慢一点；现在 skill 冲突，影响的是 Agent 当场走偏。过去知识库过期，顶多是查的人多问一句；现在上下文过期，可能直接塑造出错误行为。
所以 AI 不是把这些老问题消灭了，而是把它们推到了一个更靠近产出的地方。你不能再用“反正人会二次判断”来兜底了。
最后我更关心的，不是文章写得对不对，而是它指向了什么
鸭哥那篇文章当然还不是一套完整的方法论。它没有把 evaluation 层完全展开，也没有细讲公司级 policy、权限和回滚。但它已经很明确地指向了一个方向：团队共享 Skills 这件事，不能再按传统知识库的方法来管了。
我觉得这件事最值得讨论的，不是“这个目录怎么搭”，而是它背后的那个转向：从管理信息，转向管理上下文；从统一文档，转向分层编排；从人工维护，转向 AI 参与维护。
这也是我现在对公司级 Context Infra 最核心的判断。它不会再长成一个新的 wiki。它更像一个组织级的控制平面。真正要维护的，不是一份大文档，而是一套会在运行时不断塑造 Agent 行为的系统。
如果这个判断成立，那很多事情就顺了。为什么 skill 可以允许重复，为什么 baseline 不能太重，为什么 heartbeat 比大编辑部更有前途，为什么 eval 比内容运营更重要。
因为在 AI 时代，知识库不再只是“告诉你答案是什么”，而是“提前影响系统会怎么做”。