项目资料越存越乱？先用“原件—工作页—规则”三层结构，再让本地 AI 接手

项目资料一多，最容易出现的错觉是：文件都存下来了，以后就能找到。

实际工作里，合同、方案、会议纪要、变更记录、周报和交接材料可能散在不同文件夹里。同一份方案有好几个“最终版”，会议纪要里写了新决定，旧台账却没有更新。等到汇报、验收或交接时，项目经理面对的难题往往是分不清哪份可信、哪份生效、哪项还在等待确认。

这时把整个目录一股脑交给 AI，通常只会把混乱带进答案。更稳妥的起点，是先把资料分成原件、工作页和规则三层，再让本地 AI 在明确边界内参与整理。

01 为什么不能直接把整个文件夹交给 AI

第一个问题是版本冲突。文件名里的“最终版”“确认版”只是命名，不能证明它就是当前有效版本。AI 可以帮助比对资料，并标出部分疑似不一致，但能否找到相关内容会受解析、切分和检索召回影响。它也无法据此判断哪次审批有效、哪份附件已经正式发出，更不能裁定哪个版本生效。

第二个问题是原件和加工件混在一起。合同扫描件、会议原始记录、AI 摘要、人工台账都放在同一目录时，后续检索可能同时命中来源文件和二次整理结果。如果工作页里有一次提取错误，它还可能被当成新的事实继续引用。

第三个问题在文档解析。文件能上传，只表示系统接收了它。复杂 PDF 的阅读顺序、扫描件的数字、DOCX 里的修订和文本框、XLSX 的公式与隐藏行列，都可能在提取时缺失或错位。没有预览提取结果，索引完成也不能说明内容已经读对。

还有一个常被忽略的问题：谁来持续更新。今天生成一份项目摘要，明天新增一次变更，后天又改了交付日期。如果没有规定新资料放哪里、工作页由谁确认、旧结论怎样标记，知识库很快会再次失去可信度。

02 三层结构分别放什么

本文把“原件—工作页—规则”作为一种最小编辑框架，方便项目团队分清资料来源、加工结果和维护方法。它不属于行业标准，也不依赖某个特定产品。普通本机文件夹可以用，习惯 Obsidian 的人也可以用 Markdown 工作页承载台账。

原件层：保留来源，限制修改

原件层存合同原文件、签批件、正式方案、会议原始记录、客户确认材料、变更通知和已发出的周报。新资料到达时，先保留一份不可修改的副本，登记原文件名、来源和接收时间，再进入后续处理。原件层尽量避免覆盖式更新。

AI 可以只读原件层，用来分类、提取候选字段和查找相关片段，但不应直接改写这些文件。规则中要明确写出“禁止编辑原件”，并按资料风险配合 sandbox、操作系统权限、版本历史或独立备份。只在提示词里写一句“不要修改原件”，保护力度不够；某些 Agent 调用的子进程也可能绕开应用内的路径规则。

工作页层：承接提炼结果，允许持续更新

工作页层放项目概览、里程碑、决策记录、行动项、风险清单、变更台账和交接说明。它们是从原件提炼出来的可用视图，每一条高风险信息都应保留来源定位和确认状态。不同格式的定位方式也不同：PDF 和扫描件可记页码，DOCX 可记标题与段落，XLSX 可记工作表与单元格。

AI 适合在独立草稿区生成候选内容，例如从新纪要中提出行动项，从合同中提取一组待核对字段，或提示两个日期可能存在不一致。项目经理确认后，再把内容转入正式台账。未经确认的内容要明确标成“草稿”或“待确认”，不能悄悄混入已确认结论。

规则层：告诉人和 AI 怎么维护

规则层放命名方式、目录说明、工作页模板、读写范围和维护检查表。比如：原件目录禁止编辑；AI 对原件只有读取权限，只能写入独立草稿区；合同金额必须记录来源位置并回查；变更记录要写明提出时间、确认人和对应原件；新版本进入后，旧版本保留并标记状态。

规则要短，最好能在实际工作中逐条执行。写成一份很长的制度，却没有人按它整理新文件，价值有限。

03 三层资料为什么用了四个一级目录

下面是虚构项目“园区访客系统升级”的示意目录，只用于说明结构：

园区访客系统升级/
├── 00-原件/
│   ├── 合同与签批/
│   ├── 方案与需求/
│   ├── 会议原始记录/
│   └── 变更与验收/
├── 10-Inbox/
│   ├── 待归档原件/
│   └── AI-草稿输出/
├── 20-工作页/
│   ├── 项目概览.md
│   ├── 里程碑与行动项.md
│   ├── 决策与变更台账.md
│   └── 风险与待确认.md
└── 90-规则/
    ├── README-目录说明.md
    ├── 工作页模板.md
    └── 每周检查.md

四个一级目录依然对应三类长期资料：00-原件保存来源，20-工作页承载加工后的可用视图，90-规则维护读写与更新方法。10-Inbox 只承担临时流转，不属于第四类长期资料。它又拆成两个互不混放的入口：待归档原件放新收到的资料副本，AI-草稿输出只放加工结果。

以一份新会议纪要为例。资料进入待归档原件入口后，先保留不可修改副本，并登记原文件名、来源、接收时间；随后把副本归入 00-原件。登记记录同时保存原件归档位置，让入口记录与归档文件能够对应。AI 只读取原件，生成的行动项和疑似变更写进 AI-草稿输出，并带上原文件名、来源、接收时间和具体位置。项目经理回看原件，确认责任人、日期和决定是否生效，再更新 20-工作页。入口中的临时记录按 90-规则清理或标记完成，原件和 AI 加工件始终分开。

04 本地知识库怎样“读”项目资料

很多人会把本地知识库理解成模型打开文件后通读一遍。常见的 RAG 流程更像一套资料检索链路：提取、切分、embedding、索引、检索、生成。

文件进入系统后，解析器先提取文字，较长内容再被切成多个片段。embedding 可以理解为给每个片段生成一组便于机器比较语义接近程度的数字表示；它和原文不同，也不等于最终答案。系统把这些表示写入索引。收到问题后，检索环节找出可能相关的片段，再把问题和片段交给生成模型组织答案。

六个环节都可能影响结果。解析可能漏掉表格，切分可能拆散上下文，检索也可能没有召回真正相关的段落。复杂 PDF、扫描件、DOCX 和 XLSX 入库后，先预览提取文本，抽查金额、日期、表格和关键段落，再决定是否用于工作页。

05 文件在本机，不代表整条链路都在本机

项目目录保存在本机，只回答了“文件存在哪里”。解析、embedding、索引和生成分别由什么组件完成，决定了处理链路是否会连接外部服务。embedding 既可以使用本机模型，也可以调用远端服务；选择不同，数据边界也会变化。

举个组合示意：项目目录或 Obsidian 存放原件和工作页，自托管 Open WebUI 负责文档处理与检索，本机 Ollama 运行模型。这样的组合可以配置成本地处理，但仍需逐项检查：解析器是否调用远端 OCR，embedding 是否使用外部接口，向量索引放在哪里，生成模型是不是云模型，是否开启联网搜索，项目目录是否由 OneDrive、iCloud 等工具同步。

因此，看到网页地址是 localhost，或者模型名称出现在本机应用里，都不能单独证明全链路没有外联。设备账户、插件、日志、备份和磁盘保护也会改变资料边界。

涉及个人信息或商业秘密时，应遵循最小必要原则，只处理完成任务所需的资料；同时限制访问人员，约定留存期限和删除方式。具体法律及行业要求，需要由组织内有权限的人员或专业人士结合资料类型和处理活动判断，本文不作合规结论。

06 把 AI 放在辅助位置

AI 可以参与新文件分类、候选字段提取、工作页草稿生成，也可以帮助比对资料并标出部分疑似不一致或候选冲突。“候选”和“疑似”两个词要保留，因为结果会受解析质量、切分方式和检索召回影响。

AI 不负责判断合同效力，不替代签批，也不能自行决定哪个版本有效。金额、日期、责任人、交付范围和对外承诺，都要回到原件，核对上下文、签署状态、附件和审批记录。币种、税率、含税与未税、大小写金额、分项和合计都可能影响金额结论；日期也有签署日、生效日、交付日、工作日与自然日之分。

外部文件还可能夹带诱导 Agent 执行操作的内容。资料读取和命令执行应分开控制，网络访问与写入动作保留人工批准，关键变更逐项检查。

07 今天就能开始的最小做法

先选一个正在进行、资料量适中的项目，不必一上来迁移所有历史文件。建立 00-原件、10-Inbox、20-工作页和 90-规则四个目录，再把 Inbox 拆成待归档原件和 AI-草稿输出。原件层写明禁止编辑规则，并按风险配合 sandbox、操作系统权限、版本历史或可恢复的备份。

工作页先建项目概览、行动项、决策与变更、风险与待确认。模板加入“来源文件”“原件位置”“状态”“确认人”字段。新资料先保留不可修改副本并完成来源登记，AI 只读归档原件，只写草稿输出；人工核对后，再把确认内容写进正式台账。

接着选两三份低风险资料测试解析。对照原文件查看标题、段落、表格和数字，不要拿合同原件作为第一次试验材料。测试通过后，再逐步加入会议纪要、方案和周报；合同、签批、报价与验收材料始终保留更严格的人工核验。

每周留十几分钟检查一次：Inbox 中的流转记录是否处理完，新原件是否完成归档，工作页里有没有缺少来源的结论，疑似冲突是否有人确认，备份和版本历史能否恢复。项目发生正式变更时，当天更新台账并关联原件。

先从最近一次“找不到依据”或“分不清版本”的时刻回看：缺的是原件、工作页，还是一条真正有人执行的规则？把那个缺口补上，再考虑增加更多工具和自动化。