AI优先｜不要只做知识库：建立AI真正能用的项目文件系统
很多人一说AI工作系统，第一反应就是：
做知识库。
把合同放进去；
把法规放进去；
把案例放进去；
把以前的项目资料放进去。
当然，知识库很重要。
但我现在越来越觉得，如果目标是让Agent真正参与日常工作，只有知识库远远不够。
因为AI工作不只是“查资料”。
它还要：
- 读取当前项目文件；
- 知道哪个版本是最新的；
- 找到项目规则；
- 生成中间结果；
- 调用脚本；
- 保存输出；
- 记录任务进度；
- 让另一个Agent继续接手。
这些事情靠知识库解决不了。
所以我现在更重视另一件事情：
建立一套AI真正能使用的项目文件系统。
一、知识库解决“知道什么”，文件系统解决“现在干什么”
我觉得这两者最好分开理解。
知识库主要解决的是：
过去有哪些可以参考的知识。
比如：
- 以前审过的合同；
- 高质量法律意见书；
- 案例；
- 法规；
- 监管问答；
- IPO反馈回复。
而项目文件系统解决的是：
这一次具体要处理什么。
比如：
- 客户刚发来的合同；
- 最新版本的交易文件；
- 本次尽调资料；
- 今天需要处理的证据；
- 当前任务输出；
- 项目指令。
知识库更像图书馆。
项目文件系统更像办公桌。
一个Agent真正工作的时候，不可能只待在图书馆。
它首先要知道：
今天桌上到底有哪些文件。
二、文件放得乱，Agent再强也很难稳定工作
人其实很擅长在混乱环境里找东西。
我们可能知道：
“客户昨天微信发的那个版本应该在下载文件夹。”
“最终版应该是名字后面有final2的那个。”
“这个Word虽然叫旧版，但其实才是最新的。”
人自己长期使用电脑，可能还能勉强判断。
但对Agent来说，这种环境非常危险。
比如一个文件夹里同时存在：
- 合同.docx
- 合同修改版.docx
- 合同最终版.docx
- 合同最终版2.docx
- 合同最终版-真的最终.docx
Agent到底应该以哪个为准？
如果没有明确规则，它只能猜。
所以我觉得AI时代反而会逼着我们重新重视一个很传统的问题：
文件管理。
以前文件管理不好，主要是人自己找起来麻烦。
以后文件管理不好，AI也会一起出错。
三、一个项目最好有稳定的目录结构
我现在比较喜欢给项目建立固定结构。
不一定很复杂，但最好稳定。
比如可以分成：
- 01_Input
客户提供的原始材料。
- 02_Project_Rules
项目说明、客户立场、特殊要求、任务规则。
- 03_Reference
法规、案例、模板、历史参考材料。
- 04_Working
AI处理过程中的中间文件。
- 05_Output
准备给人复核或者最终交付的成果。
- 06_Archive
旧版本和已经废弃的材料。
这样Agent一进入项目就能理解：
- Input里的东西原则上不改；
- Working可以处理；
- Output放交付成果；
- Archive不要作为当前有效版本使用。
这种简单的目录约定，其实非常有价值。
因为它减少了大量解释成本。
四、输入文件最好永远不要直接覆盖
这是我认为非常重要的一条规则。
原始文件尽量只读。
尤其是法律工作。
客户给的合同、底稿、证据、尽调资料，最好保留原样。
Agent修改文件时，生成新的版本。
比如：
原文件：
股权转让协议.docx
AI修改后：
股权转让协议_修订版.docx
或者直接放到Output目录。
这样出了任何问题，都可以回到原件。
这不仅是AI使用习惯，其实也是很基本的项目管理和风险控制。
所以我通常会建议把一条规则直接写进全局指令：
不得覆盖原始文件。
五、项目目录里最好有一个“说明文件”
这一点我觉得特别实用。
每个复杂项目，可以放一个类似：
README.md
或者：
PROJECT.md
的文件。
里面只放最重要的信息。
例如：
- 项目名称；
- 客户；
- 代表立场；
- 项目目标；
- 当前阶段；
- 核心规则；
- 主要文件位置；
- 输出要求；
- 已经确定的重大事项。
这样无论换到哪个Agent，第一件事情都可以是：
先读取PROJECT.md。
它就能快速进入状态。
而不是重新翻几十轮聊天记录。
这其实也是把“项目记忆”从某一个AI产品里拿出来。
六、任务也可以用文件来交接
前面我讲多Agent时提到：
Agent之间最好有交接机制。
文件系统就是最好的交接媒介之一。
例如在项目目录里维护一个：
TASK_STATUS.md
里面写：
- 当前任务是什么；
- 已经完成哪些步骤；
- 生成了哪些文件；
- 哪些步骤失败；
- 有哪些待处理事项；
- 哪些问题需要人工确认；
- 下一步建议是什么。
那么Agent A做到一半以后退出。
Agent B进来，只需要：
- 读PROJECT.md；
- 读TASK_STATUS.md；
- 检查Working和Output目录。
基本就能继续。
这比“把上一段对话全部发给它”稳定很多。
七、中间文件不是垃圾，而是AI工作的“底稿”
AI做复杂任务时，经常会产生很多中间结果。
比如：
- 文件清单；
- OCR结果；
- 数据清洗表；
- 事实摘要；
- 法规索引；
- 案例列表；
- 风险初筛；
- 对比表。
这些东西不一定最终交付给客户。
但它们其实非常重要。
因为它们记录了AI：
是怎么走到最终结论的。
我觉得可以把这类文件理解成：
AI底稿。
特别是在法律工作里，这一点很有价值。
比如最终报告里说：
“公司存在劳务派遣比例超标风险。”
那么最好还能回溯：
- 这个判断来自哪份文件；
- 哪一页；
- 什么数据；
- 适用什么法律依据。
如果中间过程完全没有保存，最终只剩一个结论，复核会非常困难。
所以AI工作系统不应该只保存最终答案。
还应该保留必要的：
可追溯过程。
八、文件命名本身也是给AI看的
以前文件名主要是给人看。
以后其实也是给Agent看。
好的文件名应该尽量具有信息量。
比如：
2026-08-31_股权转让协议_客户原稿.docx2026-08-31_股权转让协议_律师修订版_v1.docx2026-09-01_股权转让协议_对方反馈版.docx
比：
- 新合同.docx
- 合同2.docx
- final.docx
清楚得多。
尤其是复杂项目里，我觉得至少可以考虑加入：
- 日期；
- 文件名称；
- 版本身份；
- 版本号。
这样AI在批量读取文件时，也更容易判断时间和版本关系。
九、知识库不要和项目原始材料混在一起
还有一个很常见的问题。
所有文件全部丢在一个大知识库里。
以前的合同；
当前客户合同；
法规；
案例；
项目底稿；
模板；
甚至已经废弃的版本，
全部混在一起。
我觉得这种方式风险很大。
因为“参考资料”和“当前事实”不是一回事。
比如以前某个项目的合同条款，只能作为参考。
但当前客户签署的合同，是当前事实依据。
如果AI把二者混在一起，可能会得出错误判断。
所以至少应该区分：
- 当前项目材料。
- 外部参考知识。
项目事实优先来自当前项目目录。
知识库只是辅助参考。
这条边界特别重要。
十、文件系统应该成为所有Agent的共同工作空间
如果用了多个Agent，我会更倾向于：
让Agent共享项目文件，而不是共享聊天记录。
ChatGPT可以读同一个项目说明；
Codex可以处理同一个代码仓库；
OpenCode可以检查同一批文件；
其他Agent也可以读取同一个输出目录。
这样真正承载项目状态的，不是某一个Agent的对话。
而是：
文件本身。
这会让整个系统稳定很多。
因为Agent是可以替换的。
但项目文件一直在那里。
这也符合我前面讲的原则：
工具可以换，工作系统不能丢。
十一、真正成熟的AI工作流，应该尽量“文件驱动”
我现在越来越喜欢一种工作方式：
不是所有东西都留在聊天里。
而是让聊天负责：
- 下达任务；
- 讨论问题；
- 做关键判断。
真正的工作状态放在文件系统里。
比如：
- 规则写进PROJECT.md；
- 流程写进Skill；
- 任务进度写进TASK_STATUS.md；
- 原始材料放Input；
- 中间结果放Working；
- 最终成果放Output。
这样一个项目即使换了对话、换了Agent、甚至换了模型，
也不会丢失主要状态。
这其实是一种：
文件驱动的AI工作方式。
十二、AI工作系统的底座，其实还是文件
很多时候我们喜欢讨论：
模型；
Agent；
MCP；
Skill；
记忆；
知识库。
这些当然都很重要。
但真正到了日常工作，你会发现最底层、最稳定的东西，往往还是：
文件。
客户给你的，是文件。
AI读取的，是文件。
AI修改的，是文件。
知识库的来源，也是文件。
最终交付的，还是文件。
所以如果要搭建自己的AI工作系统，我觉得不要一上来只研究复杂技术。
可以先做一件非常简单的事情：
把自己的项目文件夹整理好。
明确：
- 什么是输入；
- 什么是规则；
- 什么是参考；
- 什么是中间结果；
- 什么是输出；
- 什么已经归档。
当这些结构稳定以后，很多Agent能力才能真正发挥出来。
所以我现在越来越认为：
AI工作系统的第一层基础设施，不一定是知识库。
很可能是：
一套结构清楚、Agent可以理解、不同AI可以共同使用的文件系统。
知识库让AI知道过去。
文件系统让AI处理现在。
两者结合起来，AI才真正开始进入完整的工作流程。
