type
Post
status
Published
date
Sep 27, 2026
slug
summary
四层知识库的分工、写入规则与它自己的维护成本
tags
Write
AI Note
知识沉淀与记忆
category
DSH
icon
password
url
一、真正的痛点不是「AI 记不住」
用 AI 做长期项目，最消耗人的不是写代码，而是每开一个新会话都要重新交代一遍背景。上个月定过的选型要重讲，上周踩过的坑这周再踩一次。你会发现，真正花掉的不是 token，是每次开口前那二十分钟的复述。
我早期试过三种「让它记住」的办法，全失败了：写在对话里——下个会话看不到；写在项目仓库的 README 里——和代码耦合，杂事塞不进去；写在项目本地的一个隐藏目录里——换个目录就丢。三种做法的失败原因其实是同一个：没有固定落点，没有固定写入时机，没有分类。
所以这套体系的设计目标不是「记得多」，而是一句话：同一类知识永远只去同一个地方，每次收尾都自动去一遍。
二、四层落盘：一次收尾，同时服务四种用途
现在我的知识库分四层。不讲目录名，只讲层级示意：
四层各管一件事，混一层，检索就废一半：
- 项目档案：一个项目的当前真相——它是干什么的、现在到哪一步、下一步做什么、踩过什么。一个项目只准一个文件，全部内容都是它的章节，不建子文档、不建子文件夹。
- 跨项目主题结论：能复用的「当前有效结论」。比如一个主题笔记，它是一份会被反复改写的收敛稿，不是按时间堆起来的记录本。
- 会话记录：只负责溯源——回答「这条结论是哪次会话得出的」。它不是对话 transcript，把聊天记录存下来不叫知识库。
- 每日回顾：精简版，只写今天的主线、回顾、产出落在哪、明天建议。它回答的是「这段时间发生了什么」。
还有一条设计决定，我在踩过坑之后才明白它有多重要：项目真相和过程历史必须分开。做法是在同一个文件里切两个章节——一个按时间追加，记流水；一个按类型沉淀，记结论。这样才能「让项目真相好找，让过程历史不污染项目主页」。不分开的后果很具体：新会话读完这个文件，仍然不知道哪一条还是有效的。
三、写入规则：靠骨架和元信息约束，不靠自觉
四层听起来简单，真正决定它能不能活下来的是写入规则。我的做法是给每一层都定一个固定的骨架，让它「只能那样写」。
项目档案的骨架是固定的几节：项目简介、当前状态、下一步行动、进展记录、知识沉淀；而知识沉淀下面再按类型分节——Bug 修复、技术决策、模块、踩坑。
注意，每一类下面写哪些字段也是有规定的：Bug 修复要写现象、根因、修复、影响范围、预防；决策要写背景、备选方案、决定、理由、影响；模块要写职责、接口、依赖、验证方式；踩坑要写现象、原因、解决、教训。字段缺了就等于白写——少了「预防」下次还会踩，少了「备选方案」，三个月后就会有人问「当时为什么不选另一个」。
主题结论靠元信息管新鲜度：正文固定三节——当前有效知识、历史变更、来源会话。最关键的一条规矩是：当前有效知识里的每条结论，下面都跟一行「证据」，指向真实文件、真实命令或真实接口。没有证据的结论就是传说，而传说是会过期的。
会话记录只写几节：目标、过程、结果、踩坑、待处理、下次起点。它刻意写得短——百行左右就够，长了没人看，价值本来也只在反链回具体日期。
每日回顾四节：今日主线、今日回顾、产出文件、明日建议。这里有一条来自踩坑的硬约束：回顾里禁止出现「今日数据」「概览」「会话明细」这类统计流水。那是中间数据，写进去只会把一份 60 秒读完的回顾，变成没人看的报表。
上面四层都是「落盘的」。这套体系其实还有两层「自动注入的」：一层是每次会话自动注入的运行时热记忆，管的只是「每次都必须知道的偏好和铁律」；另一层是几个 AI 工具共同读同一份的记忆文件，解决的是它们各自有记忆、互相看不见的问题——做法很简单，让每个工具都指向同一个文件。分工口径也很简单：跨工具通用的事实进公共文件，项目与工具的细节留在各自的运行时记忆里。
四、这套体系自己的维护成本
搭起来不难，难的是它会自己长歪。把实际吃过的成本记下来，比讲它多优雅诚实得多。
索引漂移。 索引一旦超过一份，早晚会分叉——我本机就同时存在两份「同一个索引」，各自停在不同日期，格式还不一样，都自称是准的。
结论过期。 元信息里那个「最后验证日期」就是干这个用的。我见过一条标注早已过期的结论，里面还写着某个后来被推翻的做法，它没被误用，纯粹是因为文件末尾的「历史变更」说明了哪条被取代。结论过期不可怕，可怕的是过期了没人知道。
同名混淆。 流程层里有若干条并列的工作流，每条都有一个同名入口文件——同一个文件名在多个平级目录里重复。教训很具体：同文件夹内可以用短名互引，跨文件夹必须写全路径。
写错位置不报错，这是最阴的一类。 清理目录时我发现过一批没有扩展名的同名文件，里面装着几行知识片段，是某几次收尾把内容追加到了没有后缀的路径上；而笔记软件只索引 markdown，它们在界面上根本不存在。抽查的那一份，正式档案里已有同样一段，属于重复残影。这类错误的特征可以概括成一句：格式对了、位置错了、工具不报错。 所以收尾之后值得做一次机械核对——条目数、文件数、索引日期，用机器去对，别用眼睛。
最后，每次收尾本身就有成本。 收尾不是「写个文件」，而是一套固定四步：更新项目档案 → 归并主题结论并更新索引 → 写会话记录并更新会话索引 → 生成当日回顾、把待办同步出去。只做前 3 步不算跑完。 按我的实测估算，跑完一次约消耗五六万 token 的量级——一天一次、一年下来，成本是几十块钱的量级，不是我放弃它的理由。
压住这些成本的办法有三条，其实都很朴素：
把收尾写成固定四步，并承认哪一步最容易漏。 我的经验是最后一步（同步待办、推送回顾）最容易漏，因为它不产出任何文件，没有痕迹提醒你它没做。
索引越少越好。 一份索引是准源，两份就要先定哪份是准的；每多一份，就多一份漂移。同理，只登记真实跑过的路线：没启动的流程只留一个入口文件、标上「计划中」，不要连导航和看板一起建——没有产物时那两份只能写空表，反而成了新负担。
让触发不依赖自觉。 这套体系里唯一不靠记性的一环，是把收尾挂成定时任务，每晚固定时间跑；没有主会话的日子也有兜底。所有需要「记得去做」的设计，最后都会变成没做。
五、想搭同类体系，这几条可以拿走
给准备搭类似东西的人，六条我认为真正可迁移的：
- 一个项目一个文件。 别建子文件夹和分类子文档——文件一多，「哪份是当前的」就没有答案了。
- 四层各管一件事。 真相、结论、溯源、回顾混在一起，检索就废一半；项目主页尤其要保住，过程历史不要往上堆。
- 每条结论配一行证据。 指向真实文件或真实命令。没有证据的结论，会以「事实」的身份骗你半年。
- 每层都写元信息。 一个「类型」字段让查询和看板能分类，一个「最后验证日期」让过期可见。这两样是让体系能被机器检查的前提。
- 允许小错，但要让错能被发现。 那些残影文件证明了「不报错的错误」有多难查——收尾后做一次机械核对，比相信自己更可靠。
- 算清成本，然后别怕它。 一次收尾几万 token、一年几十块钱。真正贵的从来不是这点钱，是每次重新交代背景的那二十分钟。
这套东西没有一处聪明的设计，它做的只有一件事：把「知识该去哪、什么时候去」写成不依赖记性的固定动作。半年下来最直观的变化是——新会话开头，我不再需要讲「我们上次做到哪了」。