上一篇知识库文章，记录的是我还在搭建它时的想法和进度。那时，目录已经有了，角色和方法也积累了不少，但怎样找到当前有效的信息、怎样让新窗口接续工作，仍然需要继续梳理。

现在，这一版个人知识库的建设与接入工作已经交付。我想补上这篇记录：它是怎样建立起来的，最后留下了什么，以及我为什么愿意把它作为以后与 AI 协作的起点。

这里的“完成”，指的是这一版进入日常使用和维护。实际任务的效果还要继续验证，知识和方法也会随着工作更新。

一、我需要的，是下一次工作还能接得上

我做的事情横跨网站开发、文章写作和短视频制作。每个项目都有自己的背景、已经作出的决定、确认过的内容，以及暂时不能动的部分。这些信息一旦散在不同窗口里，接续工作就容易变成重新介绍项目。

真正麻烦的地方，是新窗口很难仅凭一段聊天判断：哪个说法仍然有效，哪个方案已经被放弃，哪些只是当时的打算。如果把旧计划当成现在的任务，回答写得再完整，也可能走错方向。

所以，2026 年 8 月开始建设时，我先明确了目标：保存跨领域工作所需的事实、决定、方法和交接材料。让人可以查阅，也让具备文件读取能力的 AI 能够按任务使用。

我希望下一次继续工作时，能够先回答几个简单的问题：现在要做什么？已经确认了什么？应当参考哪套方法？结果放在哪里？做到什么程度才算完成？这些问题，比把聊天内容全部存下来更有用。

二、从建立目录，到分清哪些内容值得留下

最初，我建立了收件箱、候选区、协作画像、工作领域、项目和交接机制。随后逐步加入项目开发、视频制作、教学表达的方法，再补充对应的角色职责、能力说明和模板。

内容增加之后，建设重点也发生了变化。知识多了，需要能找到；规则多了，需要知道哪些适用；记录多了，需要分清历史与当前。继续增加文件，已经不能独自解决这些问题。

稳定习惯，与一次任务的要求分开

例如，我确认希望 AI 使用通俗中文、说明不确定性，这类稳定协作方式可以长期保留。但某一期视频需要什么颜色、多长时长、采用什么案例，应当留在该项目里，不能自动变成以后所有工作的要求。

待确认想法，与正式方法分开

AI 提出的建议，以及从一次对话推测出的习惯，先进入候选区。经过核查和确认，才更新正式位置。这样，知识库不会因为一段看起来合理的回答，就替我作出长期决定。

做事方法，与实际作品分开

知识库保存可复用的工作方法、模板和必要资源；稿件、进度、临时帧、配音和成片留在实际项目。完成一条视频后，可以提炼确认过的经验，但不用把整条视频的过程文件都变成正式知识。

图 1：信息先分类、核查与确认，再进入对应位置；临时要求留在项目，过期内容保留替代关系。结构示意，非软件截图。

另一个重要约定，是同一条当前正式事实只保留一个正文位置，其他地方通过链接引用。否则，几个窗口各自维护一份“最终版”，很快又会产生新的矛盾。

到 9 月 30 日，我对入口和旧过程记录做了集中整理。旧建设材料经过校验后压缩归档，当前状态留在项目入口中。归档仍然能追溯，但不再混入日常方法检索。这一步让知识库的使用路线更明确，也让我接受了一个取舍：历史可以保留，不必成为每次工作的必读内容。

三、现在，一项工作怎样通过知识库接续

目前的结构，围绕协作习惯、工作领域、项目状态、职责、知识、方法、资产和维护展开。首页负责导航，具体事实由对应项目保存。AI 先读基础规则和协作摘要，再读当前项目；方法参考可以通过检索查找，命中后仍要打开原文。

这套读取顺序有一个实际作用：不用把整个知识库一次性塞进上下文。做视频时读取视频所需的方法，处理开发任务时读取开发相关内容，旧建设记录也不会自动变成新的工作指令。

以“继续制作一条已经确认文案的视频”为例，现在可以沿着这样的入口接续：

1. 核对项目与确认稿。先确认目标受众、表达目的、当前版本和制作范围，已有确认稿就继续使用。

2. 精修文案与表达。按本次目标检查事实、读法和表达，保留唯一确认稿，不为了进入下一步重新写一篇。

3. 进入个人声音制作。按登记的模型与认可音色处理配音，结合实际音频检查停顿、读法和字幕。

4. 选择制作路线。概念解释、流程说明可以进入解说动画；产品、网站或功能介绍可以进入宣传视频。两条路线按目的选择。

5. 核对后交付。对齐终稿、音频、字幕和画面，结果保存在作品项目，实际效果由我验收。

图 2：已有确认稿的任务接续示例；解说动画与宣传视频是可选路线，输出留在实际项目。流程示意，不表示本次重新完成了视频生产。

这条路线已经形成正式入口，所需的方法和选定工具资源也已接入。但入口存在，并不表示 AI 已经获得执行权限，更不表示每一次配音或成片都会自动合格。

职责也采用按需启用的方式。库中已经有开发、视频、教学和审查等角色卡，但简单工作只使用必要职责。角色卡用来说明谁负责什么，不能直接当成一支已经验证、会自主运行的团队。

四、技术各有用途，检索负责把方法找出来

Obsidian 与 Markdown：保存正文，连接入口

正文以 Markdown 文本保存，我用 Obsidian 查阅和组织链接。工作领域、职责、方法和模板可以相互连接，具体项目保留自己的状态。Obsidian 的内部链接可以指向笔记和标题，这也是我组织导航的基础之一。相关机制可参考 Obsidian 官方内部链接说明。

文字正文可以随文件夹携带；换到别的阅读工具时，仍需确认它怎样处理链接，不能把 Obsidian 的所有交互也视为自动迁移。

Python 与本地 E5 模型：按意思寻找参考

这一版已经交付本机离线语义检索。通俗地说，可以用自己的话问“怎样交接一个长任务”，由工具寻找意思相关的方法，再返回源文件位置、行号和短摘录；知道明确名称或角色编号时，也可以用关键词查找。

语义检索使用本地 multilingual-e5-base 模型，把文本转换为便于比较的数字表示，再按相似度查找相关片段。模型用途可参考其发布者的 E5 模型说明。库内正文和查询在这套检索调用中不发送到外部服务。

截至 2026 年 10 月 1 日，本地索引快照收录 283 份文档、1343 个片段。这是限定范围内的日常方法索引，不是整库资料数量。项目过程、候选、原始资料、模型资源和历史归档不在这个索引范围里。

查到结果之后，仍要看原文的状态和适用条件。相似度只用于排序，不能当成正确率。源文件修改、删除或失效后，旧结果会被过滤；新增与修改内容需要更新索引。索引可以重建，不能代替正文或备份。

生产资源与环境检查：把调用条件说清楚

10 月 1 日，知识库又接入了现有创作者内容生产体系，以及筛选后的声音、解说动画和宣传视频资源。个人声音沿用 Qwen3 TTS 基础模型与认可音色，并没有把它描述成新训练出的专属模型。

必要资源集中保存，运行仍依赖本机的 Python、Node、浏览器、FFmpeg 和相关环境。换电脑说明与只读检查工具可以帮助判断缺少什么；E5 模型和部分创作技能实现还要另外携带、接入。

图 3：知识正文、检索索引、生产资源与运行环境各有职责；携带文件后仍需接好工具，作品输出位于知识库之外。结构示意，非实际界面截图。

这些技术分别处理保存、查找和执行条件。AI 是否能读本地文件、运行工具或使用定时任务，还取决于宿主软件与授权，不能仅靠一份说明文档获得。

五、这一版完成了什么，哪些仍要靠使用验证

目前，日常入口与读取规则、本地语义和关键词检索、历史过程整理、创作者体系接入、视频资源吸纳，以及换电脑检查入口，都已完成相应交付。

其中，本地检索的交付记录包含 17 项基础测试和独立审查通过；视频资源与环境检查采用各自范围内的技术核对。它们证明对应工具和接入达到交付标准，不能替代实际创作、跨电脑运行或长期效果的验证。

历史上暂停、失败或没有闭合的工程记录，也继续保留原结论。这次交付没有把它们全部改成通过。完整迁移到另一台电脑、不同真实任务的检索质量、每次声音与视频的效果，都需要在实际使用中继续确认。

这一轮最明显的变化，是已经有了清楚的使用入口。建设工作可以停下来，后续根据真实需求调用和维护，不必为了证明体系存在，再不断增加新的过程文件。

六、完成之后，我想把注意力放回实际工作

回看这段建设过程，我更在意的是信息能不能被正确接续。资料再多，如果找不到当前版本，或者不知道是否适用于眼前任务，仍然需要重新判断。

下一阶段，我准备通过实际开发、写作和视频任务观察：方法是否容易找到，交接是否说得清楚，旧要求是否会干扰新任务。现有四日维护安排用于检查已授权、可访问的变化；它不能自动读取所有平台的聊天，也不会让知识库自行扩张。

长期希望保留下来的，是一套可以随着工作改进的协作方式：做事前有可靠的起点，过程中知道依据和边界，结束后能留下下一次用得上的经验。

这篇记录的是 2026 年 10 月 1 日这一版的状态。接下来，知识库会进入日常使用；新的事实和确认过的方法，再回到各自的位置。