个人 AI Lab 资料治理：项目 / 归档 / 审计 / 时间线，四类各管一摊

资料治理笔记

一台 AI 工作站跑过一年以后，硬盘上会出现一种很奇怪的状态——目录结构看起来还算整齐，但你已经找不到东西了。

一开始我以为是目录分得不够细。再切一层、再加一层 tag，总能解决。后来发现不是。问题不在细不细，而在我从一开始就按错了维度切——按内容主题切目录，半年以后必然乱。同一份资料在不同生命周期里，治理属性会变；内容主题不会。你今天按主题摆得再齐，过半年它在你心里的身份已经动了，目录却不会自动跟着动。

这篇往上抽一层。站点上已有几篇讲「某一类资料怎么管」——知识库 6 种页面类型、从日志到知识的保留排除规则、Mac mini 某一次系统审计、系统级资料库整理规则。那些都是「往下切」。这篇往上抽：在动任何具体库、做任何具体审计之前，所有产出先按什么属性切成几类。根目录切法不定，下面怎么管都是乱的。

我现在用的切法是四类——项目（projects）、归档（archive）、审计（audits）、时间线（timeline）。各管一摊，不重叠。

为什么不按内容主题切

最早一年我用过的切法是「AI 模型 / 工程项目 / 音乐 / 视频 / 调研」。看起来直觉、看起来对——每件事都能找到归属。

但它撑不过半年。内容主题是静态标签，治理属性是动态身份。同一份东西，今天是「活的项目」，明天可能变成「已经结案的归档」，后天可能因为做了一次盘点变成「审计快照（snapshot，某个时间点拍下的状态截图）」。它的内容主题没变——还是属于 AI 工程那个抽屉——但在我手里要被怎么对待，完全变了。

举个例子。纪嫣然语音工作台这个项目，去年是个正在跑的工程，每周都有 commit（git 提交）推进。中间做过两次外部审计，留下了两份带时间戳的快照。某些早期模块已经停止演化、不会再改了，按理说该进归档。整个项目里几次决定性的架构调整，我又顺手写进了系统级时间线。

按内容主题切，「纪嫣然」就是一个目录，所有东西都堆在里面。结果就是——下次想知道「现在系统是什么状态」，会被一堆已经过期的旧设计文档干扰；想查「最近一次正式审计的结论」，要翻好几层；想看「这套架构什么时候定的」，时间线淹没在 commit 历史里根本看不见。

说白了，按主题切的目录里，每一份文件都没告诉你「应该用什么态度对待它」。你必须每次打开都重新判断。十次以后没人想打开。

按治理属性切就不一样。一份资料躺在「项目」里，意思就是它还活着，可能随时被改、被引用、被推进。躺在「归档」里，意思就是它已经死了，看可以、但别把它当现在的真相。躺在「审计」里，意思是它是某个时刻的快照，要看带的时间戳判断还能不能用。躺在「时间线」里，意思是它在记录一次系统级变化，不要展开内容，只看引用。

属性稳定。资料一旦定性，对待方式就定了。下面展开说。

第一类：项目（projects）——活的、有 owner、还在变

项目目录放的是当下还在跑的活。判断标准很笨——还有人负责、还有产出、还在被推进、有验收标准。任何一条不满足，它就不该再待在项目目录里。

我现在同时在跑的项目有几条线——音乐索引、OpenClaw、纪嫣然语音工作台、林鹿视频工厂。每一条都有自己的目录、git 仓库、.env（环境变量文件）、venv（Python 虚拟环境）。目录、git、env、venv 这四件事缺一个都不行。

为什么要这么强调隔离？AI 工程的依赖冲突极其凶。两个项目共用 venv，半年后必有一方依赖被另一方升级悄悄破坏。共用 .env，token 迟早串了——一个项目的 key 被另一个项目的代码读走，轻则配额穿仓，重则被错误的人调用。共用 git 仓库更糟，commit 历史会乱成什么样不用想。

项目目录里允许混乱，活的东西本来就乱——草稿、实验脚本、跑废的 log、半成品文档。这些都可以堆在项目里，没关系，命运跟着项目走。要么哪天升级成正式产出，要么项目结案一起搬归档，要么确认没用直接删。

项目目录最大的危险，是没及时把死掉的部分搬出去。一个项目里如果同时存在「活的当前版本」和「已经死的旧版本」，又没标清楚谁是谁，下次你想改的时候 95% 会改错那份。这个坑我踩过——本来该改 v3，结果改了 v1 时代留下来的同名文件，半天才反应过来为什么改了没生效。

所以项目目录默认全是活的。一旦发现某份东西死了，立刻搬走，别"放这儿也没关系"。这是项目与归档之间最常见的污染源。

第二类：归档（archive）——过去的、已结案、还有参考价值

归档放的是已经死掉、但还值得留的东西。冷存储里的旧 wiki（百科库）、过往的调研报告、做完没继续推的实验、教学性的整理稿——这一类。

归档的特征很清楚：不会再改，偶尔回头查，留着比删好，但绝对不能当权威。

我现在归档跟当前项目是物理隔离的——最好直接放在另一块盘。这听起来有点过——一个目录的事至于换块盘吗？但物理隔离有个心理效应——你伸手够不着的东西，就不会顺手引用。这是治理最不起眼但最关键的一招：不让坏选项触手可及。

归档最大的坑就一条——被当成权威源引用。

我吃过的最大一次亏，是某次排查一个配置问题。我让 AI 助手翻文档，找到一份带 FINAL（最终版）字样的设计稿，里面明明白白写着接口走 v3、字段叫 X。我照着改了一圈，发现根本对不上。最后才反应过来，那份 FINAL 是一年前的 FINAL，v3 早就被推翻、字段早就改名，只是这份稿子被搬进归档以后没人去戳它。它躺在归档里，文件名还叫 FINAL，看起来像权威。

从那以后我给归档加了一条死规矩——归档目录里的所有材料默认都标 stale（过期的、不新鲜的）。哪怕文件名写着 FINAL / SPEC / canonical（权威的、官方的），只要在归档里，它就是 stale。想拿归档里的内容当依据，得先回项目里找活版本——找不到，就当不存在，不许直接引用归档。

这条规矩听起来不近人情——明明有东西为什么不能用？但它其实是在保护我。归档里的东西保留的是「当时是这样」的历史价值，不是「现在还是这样」的事实价值。把两者混淆，比直接不留更危险——直接不留只是没信息，混淆是有错误信息。

所以归档不是数据的坟墓，是数据的展览馆。可以看、可以引用为"那个时候的状态"，但不能拿展品当现役装备。

第三类：审计（audits）——某个时间点的快照

审计是一次性盘点的产物。重装系统前的系统快照、跨项目拓扑梳理、第三方做的安全审计、自己定期的资料盘点——这些都属于这一类。

审计的特征跟项目和归档都不一样。项目是活的，归档是死的，审计是「死在某个时间点，但那个时间点很重要」。它是一张照片，照下来的是当时的状态。

审计目录的治理规矩有两条——必须带时间戳，必须带 stale 标签。

时间戳必须直接写进文件名或者目录名，不能藏在文件内部。这是被无数次坑出来的经验。时间戳如果只写在文件头的 frontmatter（开头的元数据块）里，得打开才看得到——目录列表扫一眼根本看不出新旧。文件名里直接带年月，扫一眼就知道这份是今年的还是去年的。

stale 标签更关键。审计快照一拍下来就开始过期——过期速度取决于系统变化速度。系统稳定的部分，一份审计可能半年还有效；系统在动的部分，一份审计可能两周就废了。所以审计目录得有个机制告诉你「这份还能不能用」——目前我用的还是手工标，每次系统有重大变化，回头把对应模块的审计标 stale。

审计最大的地雷，是过期了还被人当现状用。

这比归档被错引更坑。归档大家心里有数——你看的是历史。但审计不一样——审计本来是让人知道现状的，默认假设就是"这是真的"。一份三个月前的审计，如果中间系统改过几次，但没人去标 stale，下次有人翻出来当依据，错的可能性极高。

所以我现在做审计的时候，会同时做两件事——拍快照、并且在系统有重大变化时回来标 stale。第二件事经常忘，但忘一次就出一次问题。这也是我在推 stale 自动化的原因——手工纪律撑不住。

审计和归档容易被混淆，区别其实很清楚：归档是「这个东西已经死了，搬进展览馆」，审计是「这个东西还活着，但我在某一刻拍了张照」。被拍照的东西继续活，照片不会跟着更新。

第四类：时间线（timeline）——系统级变化的流水账

时间线只记系统级变化。

什么叫系统级？改宪法（机器级通用工作指南）、改目录结构、装常驻服务、配 LaunchAgent（macOS 开机后台服务）、决定性架构调整。这一类。

不属于系统级的，一律不进时间线。具体项目里某次改了某个文件——那是项目的 commit 历史，不进时间线。某次审计发现了什么——那是审计目录里的事，不进时间线（除非审计触发了系统级变化）。某天读了一篇文章学到一个新东西——那是笔记，不进时间线。

时间线追加式写法——不删不改，按月归档。每条变化必须写清楚四件事：改了什么、为什么改、影响谁、引用了哪个任务或审计。

其中"引用"最关键。时间线不重复内容，只放指针。每条时间线条目，如果你想知道详情，得跳到它引用的项目目录或审计快照去看。这条规矩保证时间线永远是薄的——薄才有人读。

时间线最大的危险，是所有小改动都往里塞。

这个诱惑很大——既然有个流水账，每次改东西顺手记一笔多好。但只要试着记一周——时间线立刻被淹没。本来想看「这个月有什么重大变化」，结果翻出来 80 条，70 条是「调了个参数」「改了个文案」「装了个工具」。这种密度的流水账没人读，读了也找不到信号。

所以时间线门槛要高。一条变化要不要进时间线，我的判断标准是——三个月后回头看，还会不会觉得它重要？如果不会，就不要进。

判断不准的时候，宁愿不写。漏写一条不重要的变化，损失很小；写多了不重要的变化，时间线整体作废，损失很大。

四类之间怎么互相引用

四类目录的关系比想象中紧。但有个原则——只引指针，不复制内容。

项目跑到某个节点需要拍快照，就触发一次审计——项目目录里只留一行"已审计，详见 audits/2026-05-jiyanran-stage-1.md"，详细内容在审计目录里。审计如果发现重大问题、需要做系统级调整，就触发一次时间线条目——审计报告里留一行"已触发时间线变更，详见 timeline/2026-05/CHANGE_xxx.md"，时间线里留一行"起因详见 audits/2026-05-jiyanran-stage-1.md"。两边互引，但内容只在一处。

项目结案搬归档同理——项目目录消失，归档目录里留下完整快照，时间线里留一条"某项目已结案，归档详见 archive/xxx"。这条时间线条目以后是找这个项目唯一的入口。

时间线是事后总结，项目和审计是事中产物。时间线引用它们，它们很少引用时间线。单向引用让目录不循环。

归档跟其它三类的关系最弱——基本只被引用，不主动引别人。终点站。

这套引用关系一开始我也没想清楚，用着用着才摸出来。一旦稳下来，找资料变成一种机械动作——先看时间线知道大概在哪个时段发生过什么，再跳到项目或审计看具体内容，最后翻归档查历史背景。三步走完任何一次查询。

真实场景：4 类怎么联动起来做决策

这套切法的价值，在真实场景里才显出来。举三个最近常遇到的情境。

场景一：接手一个已经放了三个月没动的老项目。

以前的流程是——翻项目目录，看最新文档，然后开始猜。问题是项目目录里的文档真假不分，有些是当年留下的设计稿，有些是中间废弃的方案，有些才是真正在跑的版本。我经常花一两个小时才能搞清楚「这个项目当下到底是个什么状态」。

现在的流程是——先看项目目录里最近一次 commit 在干嘛，再去审计目录找这个项目最近一次审计快照（带时间戳，扫一眼就知道几月份的），最后去时间线里翻最近三个月这个项目相关的系统级变化。三件事拼起来，10 分钟进状态。审计快照告诉我"那个时间点是什么样"，时间线告诉我"从那之后改过什么"，项目目录的最新 commit 告诉我"现在正在动什么"。三个角度互相对照，比单独看任何一个都准。

场景二：排查一个不知道哪里来的配置冲突。

比如某天发现某个服务突然连不上某个端口，记忆里没改过相关配置。

以前我会一头扎进项目代码查 commit，常常查不出来——问题可能不在这个项目，而在某次系统级调整改了端口分配或者某个 LaunchAgent 的配置。

现在第一步先翻时间线，看最近一个月有没有跟网络、端口、服务相关的系统级变化。第二步翻最近一次系统审计的「配置冲突登记」那一段——一般审计里都会顺手记一笔已知冲突。两步走完，80% 的诡异问题能定位根因。剩下 20% 才回到具体项目里翻 commit。

顺序很重要——先看系统级（时间线 + 审计），再看项目级（commit）。反过来效率会差一倍。

场景三：写一篇技术博客。

比如我现在写这篇。素材两块——归档里有过去一年陆陆续续做过的相关整理，项目里有最近一两个月还在动的实践。

归档负责"我以前怎么想"，项目负责"我现在怎么做"。两个一起引，文章才有时间纵深。如果只引归档，文章像在讲历史；如果只引项目，文章像在讲技术细节。两边对照，才能讲出「为什么我改了这么多次最后落在这套切法上」。

审计在这种场景不太常用——审计是工程档案，公开写文章不需要引它。但偶尔写"某次重大调整"复盘，审计快照就是最权威的素材。

这套治理带来的实际差别

数字上的差别比我以为的大。

切之前——工作产出分散在十几个目录，找一份资料平均翻 3-4 个目录，运气不好半小时找不到。

切成四类后——95% 的资料 30 秒内能定位。剩下 5% 多半是我当初没分好的灰区，每次遇到顺手归位，灰区在持续变小。

更大的差别在心理上——不再害怕「找不到」。以前每次要回头找一份资料都有一种"这次找不到怎么办"的隐性焦虑。这种焦虑会反过来影响行为——下意识少回头查，更多凭记忆判断，更多相信"应该没问题"。

现在不需要凭记忆。需要什么去对应抽屉里拿。

还在改的部分

这套治理远远不算完成。下面几件事都还在长。

第一件事，stale 标签自动化。目前是手工标——系统有变化我手动回去标一批审计快照过期。漏标的概率不低。理想状态是有个脚本能定期扫审计目录，根据系统当前状态自动算出哪些快照已经过期。这件事比想的复杂——「系统当前状态」本身没有机器可读的定义，得先把"系统状态"形式化，脚本才能判断。

第二件事，项目转归档的判定标准。目前完全靠经验——我觉得项目死了就搬。但"觉得死了"和"真的死了"之间有一段模糊区，搬早了还会被找回来，搬晚了死的东西继续在项目里污染。理想状态是有一组标准——比如多久没 commit、依赖是否还活着、有没有 owner——满足几条就触发"建议归档"的提醒。

第三件事，跨类别引用机制。前面写过了——四类互引，但目前是 markdown 里的纯文本路径。文件搬过位置，路径就断了。一台机器内还能忍，多机器场景完全撑不住。

第四件事，多机器同步。我现在不止一台机器——Mac mini、Mac Studio、Mac Air 各有各的角色。四类目录每台机器都有，但应不应该全量同步、还是各自只装本机用的部分，目前还没定。全量同步好处是任何一台机器接手都能用，坏处是项目目录迅速膨胀；只装本机用的好处是干净，坏处是跨机器协作会缺东西。这件事大概要拆成「项目按机器划分、归档全量同步、审计按机器划分、时间线全量同步」——但还没真跑过，不知道会踩什么坑。