知识库的下一步：从静态文档到持续运行的局部上下文

历史车轮滚滚向前，这篇文章真正有价值的未必是结论，而是它带给你的思考扰动：这套东西对我的团队意味着什么？它和我们现在的知识库有什么区别？哪些文件夹可以先跑起来？哪些工作可以逐渐交给常驻 Agent？ 这些问题，可能都比“帮我总结全文”得到的最大公约数更有价值。

一、核心判断

未来 AI 原生的组织，或许会越来越像一棵持续运行的文件树：一个个业务单元的上下文，被挂载为一个个文件夹。

人和 AI 可以加入业务文件夹协作；业务文件夹也可以通过 README 对外提供自己的状态与能力。

随着文件夹内的信息与工作方式不断收敛，人类就有可能逐渐从部分文件夹中退出，留下 AI 长期自主运转。

这不是在说“用文件夹整理资料”。

真正的变化是：

组织长期稳定存在的东西，不再是某个群、某个人、某次会议，而是一个个持续维护的局部上下文。

文件夹，就是这个局部上下文的容器。

二、现实里本来就是这样工作的

一个需求，现实里通常会归属于某个持续存在的业务上下文。

货架
  -> 某个需求
    -> 需求群
    -> 开发群
    -> 测试群
    -> 运营群

就比如“货架”业务。

人会换，群会换，工具会换，但事一直在。需求群、开发群、测试群、运营群，都是这个业务在某个阶段、某些角色下的协作视图。

唯一稳定存在的，只有这个业务上下文本身。

而真实的组织，就是由一个个业务组成的树；每个业务，都是一个持续存在的局部上下文。

只是过去，业务信息散落在群聊、会议和文档里，没有像业务架构一样，被显式地组织成文件树。

三、为什么是文件夹

文件夹天然适合表达“局部上下文”。

一个文件夹可以装下：

如果把协作载体粗略分成三代，大概是这样：

第一代是群聊。

它解决的是即时沟通问题。大家可以快速讨论、通知、对齐，但信息主要按时间流动。

第二代是飞书、Notion 类在线文档。

它解决的是聊天记录信息带宽有限的问题。聊天适合快速对齐，但很难承载结构化结论、背景解释、方案推导和长期可读的上下文。所以第二代协作把一部分信息从聊天里抽出来，整理成更结构化的文档。

但文档本身通常还是一次压缩结果。它比聊天更清楚，但也会把大量原始材料和过程细节丢掉。

第三代是 AI 时代的业务文件夹。

文件夹天然支持多媒体，也支持无限细节。会议录音、截图、群聊记录、Excel、SQL、日志、设计稿、临时草稿，都可以作为原始信息素材库留在里面。

过去人处理不了这么高带宽的原始材料，所以必须提前压缩成文档。到了 AI 时代，非结构化材料也可以被 AI 即时读取、检索和组织，按当前角色或问题生成一次性的视角文档。

这里的“视角文档”，指的是：同一批原始材料，在某个角色或问题下，临时生成的一次性说明。

写文件夹的人，不需要提前预设未来所有读者会从什么视角理解这些材料，也不需要把所有可能的问题都写进一篇总文档。

读文件夹的人，也不需要无效地顺着文章顺序读完一整篇文档。他可以直接带着自己的问题进入文件夹，让 AI 从原始材料里生成当前需要的视角文档。

所以第三代文件夹，不是让人直接阅读所有原始材料，而是让人和 AI 围绕同一个文件夹工作，进而可以直接问文件夹：

这个需求现在最大的风险是什么？
PRD 和最新讨论有没有冲突？
研发方案有没有漏掉设计约束？
QA 需要重点覆盖哪些边界？

所以文件夹的价值，不只是“能装更多东西”，而是它开始成为人和 AI 共同工作的上下文运行面。

它有几个关键特征：

所以文件夹不是“资料收纳盒”。

在这个模型里：

文件夹 = 一个局部工作作用域
文件树 = 组织的上下文结构

文件夹里的内容，不只是静态文档，而是这个局部世界的连续状态。

四、聊天也应该进入文件夹

过去最大的问题是：真正的状态经常发生在聊天里，但长期知识却要求写进文档里。

结果就变成：

文档不是现实
群聊才是现实

大家做决策在群里，解释背景在群里，讨论风险在群里，出了问题再去翻几百条聊天记录。最后文档慢慢腐烂，群聊又无法承载长期状态。

文件树中心制要把这两件事统一起来。

聊天本身也应该是文件夹上下文的一部分。

比如：

/交易/货架/
  README.md
  facts/
    chats/
      2026-05-19.md
    meetings/
      2026-05-19.md
  ...

群聊记录、会议转录、截图、日志等原始材料，都应该进入 facts/，成为这个文件夹的事实层。不要在进入文件夹之前先筛一遍“重要不重要”。因为“重要”其实是一种视角投影：这次看起来不重要的事实，未来业务环境变了，可能就会变得重要。

聊天进入里面，会议转录进入里面，PR 进入里面，日志和截图也进入里面。它们都是这个文件夹状态的增量更新。

这样，新人或 Agent 进入一个文件夹时，看到的不是一段断裂的聊天历史，而是一个有当前状态、有历史轨迹、有决策依据的局部世界。

未来，只要愿意投入算力分析，就能重建因果，洞察关联。

五、文件夹内部保存完整上下文，对外只暴露必要状态

如果每个文件夹都保存完整上下文，那会不会导致信息爆炸？

不会，前提是：文件夹内部和文件夹外部的通信方式要分开。

文件夹内部可以保存完整上下文。

因为同一个局部作用域里的成员，需要共享足够多的细节。开发细节、测试风险、事故讨论、临时截图、会议转录，都可以沉淀在这个文件夹里。

但文件夹对外不应该暴露全部细节。

对外只需要暴露必要的状态、能力、风险和接口。

最简单的形式就是 README.md。

一个好的 README 应该回答：

外部文件夹不需要翻你的全部聊天记录，上级文件夹也不需要读完你的全部细节。有些文件夹的内部过程甚至可以完全封闭，对外只暴露 README、接口人，或者一个负责解释当前状态的接口 AI。

这和真实组织很像。一个团队内部怎么讨论、怎么试错、怎么分工，不一定全部对外展开；外部真正需要的是它当前的状态、能力、风险和接口。

这就是组织里的抽象边界。

团队、部门、业务线本来就需要对外接口。业务文件夹只是把这种接口显式化。

六、README 也不一定是固定文档

以前 README 必须靠人提前写好，因为人类检索慢、总结慢、上下文重组也慢。

但 AI 时代，README 可以变成一种动态视图。

文件夹内部保存原始上下文，驻守在文件夹里的 Agent 熟悉这些上下文。外部来访问时，它可以按访问者的角色生成不同版本的说明：

也就是说：

文件夹 = 原始状态空间
Agent = 局部状态解释器
README = 默认状态视图
即时问答 = 按需生成的状态视图

静态 README 仍然有价值，它至少应该保留一个稳定骨架。但大量具体摘要，可以由 Agent 根据当前访问者实时生成。

这和知识库里的“事实与视角解耦”是同一件事。

底层保留事实，上层按角色生成摘要。不要过早把某一种视角写死成唯一真相。

七、为什么过去没彻底这样做

过去企业其实也尝试过用文件组织长期状态。

共享盘、Notion、Confluence、飞书文档、Git 仓库、服务树、接口文档，本质上都在做这件事。

但它们没有彻底成为组织中心，原因很简单：

文件不会自己更新。

人类更愿意发消息、开会、口头同步，因为这比持续维护文档便宜。

所以最后经常变成：

AI 补上的，正是这个缺口。

Agent 可以长期驻守在文件夹里，持续读取变化，更新摘要，整理风险，维护入口，回答外部查询。

于是文件夹第一次有机会从“静态资料库”变成“持续运行的状态空间”。

八、Agent 不是临时助手，而是文件夹里的常驻进程

在这个模型里，Agent 不应该只是被人临时 @ 一下的工具。

它更像文件夹里的常驻进程。

这个方向已经开始在行业里出现了。OpenAI 的 Codex 和 Anthropic 的 Claude Code 这类工具，已经不再只把 Agent 放在聊天框里，而是在往后台任务、定时循环、自动修复和 PR 工作流演进。它们还不是最终形态，但已经能看出一个趋势：Agent 正在从“被提问时才工作”，变成“持续观察、持续处理”的常驻进程。

它长期做几类事：

现实组织里其实早就有类似角色。

很多小组长、接口人、项目协调者，本质上就在做：

读取局部细节
  -> 压缩成外部能理解的状态
  -> 同步给上游、下游、同级

这类信息形式变换，正是 AI 的舒适区。

AI 第一波接管的，未必是具体的执行，而可能是这些信息同步工作。

九、Skill 本质上是基于文件夹的局部 Agent

很多人现在做 Agent Skill，会把 Skill 理解成一堆全局可用的提示词或能力包。

但真正有价值的 Skill，大概不会是那些通用能力。

如果一个 Skill 很通用，自然就会被很多人使用，自然就会进入训练语料，自然就会被模型内化。

而是高度绑定某个业务文件夹的“打螺丝”技能。

它们高度依赖文件夹里的原始事实、历史记录、接口约定、指标定义、风险阈值、工作流程和团队习惯。

比如一个“货架埋点指标回归 Skill”，离开这个文件夹里的埋点口径、指标定义、历史波动、发布记录、实验分组和异常阈值，就会变成空话。

更准确地说：

Skill
= 基于某个文件夹局部上下文运行的 Agent

即文件夹提供事实和上下文，Skill 提供在这个上下文里观察、判断和处理问题的方式，让 Agent 可以周期性执行。

十、人和 Agent 都只是执行器，稳定的是信息结构

AI 时代更好的结构是：

业务上下文是稳定本体
文件夹是显式容器
人 / Agent 是读写它的执行器

人可以进来，也可以退出。Agent 可以升级，也可以替换。模型可以换，工具可以换。

但业务上下文里的状态、历史、接口、Skill、工作方式应该持续存在。

文件树 = 业务上下文的显式结构
人 / Agent = 读写状态的执行器

这会带来一个很大的变化：

组织能力越来越依赖一件事：能不能维护出高质量的信息结构。

执行器会不断变化。模型会升级，Agent 框架会升级，自动化工具也会升级。

但事实和信息结构能经得起时间考验：

所以建设这种知识库，不是在赌某个执行器，而是在建设一个能持续吃到模型和工具进步红利的信息底座。

十一、无人文件夹会逐渐出现

一开始，文件夹可能完全靠人运转。

由人来写文档、记录流程、整理 README。

再后来，懒惰但聪明的人自然会外包一些重复琐碎给 Agent。

继续往后，Agent 可以接管这个局部上下文里的更多具体工作：观察、汇总、检查、同步、提醒、生成报告、处理常规问题。

最后，某些足够稳定的文件夹，会进入低人类参与甚至无人值守状态。

它不是没有人类责任，而是日常运转不再依赖人类持续驻守。

它可能只需要在异常、策略变化、重大风险时让人介入。

这个过程大概是：

人类维护
  -> 人类 + Agent 辅助
  -> Agent 维护状态，人类决策
  -> Agent 处理日常，人类低频介入
  -> 文件夹长期自主运行

AI 替代的不是“整个公司”，而是一个个文件夹里的稳定局部工作。

十二、什么样的人能创造无人文件夹

不是所有人都能把自己的工作交给 AI。

关键不在于这个人写了多少文档，而在于他能不能把局部世界结构化。

很多人在公司工作几年，留下的只有周报、日报、汇报材料、不得不写的技术方案。这些东西大多是流程要求的输出，生命周期短，也很难被别人复用。

另一类人会主动留下：

这类人其实在做一件事：

把自己脑子里的局部世界，编译成别人和 AI 都能接手的信息结构。

未来组织真正稀缺的人，可能不是最会汇报的人，也不是最会忙的人，而是最会把局部世界结构化的人。

因为只有结构化之后，AI 才能低成本接管。

如果一个团队没有抽象能力，也不是完全不能用 AI。但它只能让更强的模型反复从大量聊天、操作轨迹和历史样本里重新推断世界模型。

这会更贵、更慢，也更不稳定。

所以 AI 时代的组织竞争力，最后可能会回到一个很朴素的东西：

谁能把复杂局部工作，压缩成更清晰、更稳定、更低成本可运行的信息结构。

十三、一个探索中的雏形

我们现在在做的 context-repo，其实就是这个方向的一个低配版本。

详见：One Folder, One Context

结构大概是：

单周迭代/
└── 2026/
    └── W15-04-06/
        └── 需求名/
            ├── PM/README.md
            ├── DS/README.md
            ├── RD/README.md
            └── QA/README.md

它现在还很简单：

这一步看起来很小，但它改变了协作的起点。

以前是：

我应该去哪个群里问？

现在是：

这个需求的上下文在哪里？

只要上下文开始聚到一个文件夹里，后面才有可能引入 Agent，维护状态，生成视角，沉淀 Skill，最后让人逐渐退出稳定工作。

十四、最后收束

文件树中心制的核心，不是文件夹，也不是 Git，也不是 Markdown。

它真正想解决的是：

组织如何让局部上下文持续存在，并让人和 AI 围绕这些上下文长期协作。

在这个结构里：

最终，AI 原生组织可能会从“人围绕群聊协作”，逐渐变成“人和 Agent 围绕文件树维护局部状态”。

当越来越多局部文件夹能够长期自主运行时，企业就会越来越像一个由文件树、人类和 Agent 共同运行的软件系统。