Harness 工程实践：用大模型搭建个人知识库

一、教程目标

本教程的目标非常明确：带领读者围绕自己感兴趣的研究或学习主题，搭建一套“由大模型参与撰写、持续维护的个人知识库”，并基于它完成三类核心任务——资料沉淀、复杂问答与结构化输出。

这套方法的理论背景，是近两年业界讨论较多的 Harness 工程。简单来说，大模型本身只是一个推理引擎，真正决定任务成败的，往往是模型外围的工程化外壳：上下文如何组织、中间状态如何持久化为“工件”、工具如何接入、人如何以“在环监督”的方式参与、结果如何固化成可复用的文件。近期有知名研究者公开分享了自己的实践：用大模型为研究主题构建个人知识库，把大量 token 消耗从“处理代码”转向“处理知识本身”，并通过按目录组织的 Markdown 文件、索引与摘要来支撑复杂问答。这正是 Harness 思想的一个典型注脚，也是本教程要复现的完整流程。

读完后，你将获得：一套可直接落地的目录与工件规范；一条“原始资料 → 条目编译 → 索引摘要 → 问答 → 输出”的完整流水线；以及配套的验证方法、排查思路和优化建议。

二、适用场景

• 技术调研与综述撰写：围绕新领域快速建立知识地图；
• 个人学习管理：把文章、论文、仓库文档、数据说明统一沉淀；
• 长期研究追踪：持续摄入新资料并保持条目更新；
• 团队知识沉淀：将流程复用于内部培训材料、常见问题库；
• 汇报与分享：直接从知识库生成报告、幻灯片与图表。

三、前置准备

1. 基础环境：一个本地工作目录（建议纳入版本管理）；一种能读写本地文件、可调用大模型的脚本环境或通用编程助手；任意主流大模型服务接口即可，本教程不依赖特定平台。
2. 语料准备：文章、论文、仓库文档、数据集说明、图片等，越杂越好，后续统一“编译”。
3. 可选工具（通用类别即可）：浏览器网页剪藏扩展（可将网页正文保存为 Markdown）；本地双链笔记软件，作为知识库的查看前端；基于 Markdown 的通用幻灯片格式，用于演示输出；通用绘图库，用于脚本生成图表。
4. 可选云上能力：语料体量较大或需要跨设备同步时，可使用对象存储托管原始文件与图片，例如百度智能云对象存储等通用对象存储产品，并配合访问控制保障安全。

四、实施步骤

步骤一：设计目录结构与工件规范

Harness 的第一原则是“状态沉淀为工件”，因此先定目录，再谈流程：

knowledge-base/
├── raw/          # 原始资料，只进不改
├── assets/       # 图片附件，命名含来源编号
├── wiki/         # 编译后的概念条目
│   └── index.md  # 主题目录 + 每条目摘要
├── outputs/      # 报告、幻灯片、图表
└── manifest.md   # 原始资料登记清单

注意：raw/ 目录是唯一事实来源，只允许新增，不允许改写；所有编辑行为都发生在 wiki/ 中，保证可追溯。

步骤二：语料摄取

把网页、论文、文档统一转换为 Markdown 存入 raw/，图片全部下载到本地 assets/，并用“来源编号+主题+序号”的方式命名，方便后续引用。同时在 manifest.md 中登记：来源类型、入库日期、主题标签、文件路径。这一步的作用是建立“原文可追溯”的基础——wiki 中任何结论都必须能指回 raw/ 里的某份文件。涉敏内容需先脱敏再入库。

步骤三：让大模型“编译”wiki 条目

这是整套流程的核心。按主题分批，让模型从 raw/ 资料中抽取概念，为每个概念撰写条目，包含：一句话定义、关键要点、争议与开放问题、来源引用、相关条目（反向链接）。不要试图一次性全量处理：上下文长度与输出质量都会受限，分批编译、逐主题收敛才是稳妥做法。新资料入库时采用增量编译：先生成摘要，再判断是并入已有条目还是新建条目。

步骤四：构建索引与摘要层

在 wiki/index.md 中维护两级内容：主题目录，以及每个条目 3~5 句的摘要。这层是问答 agent 的“地图”。实践中的经验量级是：当知识库达到百篇条目、数十万字规模时，“索引 + 摘要 + 条目”的分层结构通常足以支撑较高质量的问答，未必需要一上来就引入向量库与检索增强生成；只有当规模继续膨胀、问答质量明显下降时，再考虑 RAG 等通用检索方案。

步骤五：搭建问答流程

问答遵循“先地图、后深入”的顺序：

输入：用户问题 Q
1. 读取 wiki/index.md，筛选与 Q 相关的候选条目
2. 阅读候选条目正文，必要时回读其引用的 raw/ 原文
3. 仅基于上述材料组织答案
4. 答案末尾列出引用的条目路径与原始资料来源
5. 材料不足时明确说明缺口，而不是编造

同时用提示词约束行为：只依据知识库回答、关键结论必须附来源路径、引用原文时不得改写数据与术语。这一步体现了“人在环监督”的理念：重要结论由人抽查核验，模型负责检索与组织。

步骤六：生成输出工件

相比在对话窗口里拿答案，更推荐让模型直接生成文件工件：Markdown 报告、基于 Markdown 的通用幻灯片格式文件、由脚本调用通用绘图库生成的图片，统一归档到 outputs/，按“日期+主题”命名。人在笔记软件或查看前端中审阅成品即可。

五、结果验证

• 完整性：用脚本比对 manifest.md 与 wiki 中的引用，确认每份原始资料至少被一个条目覆盖；
• 链接有效性：扫描条目中的相对链接，检查目标文件是否存在；
• 忠实性抽检：随机抽取条目与 raw/ 原文比对，确认没有事实性偏差；
• 问答回归：维护一份固定问题集，每次知识库更新后重新提问，观察答案的稳定性与引用质量。

六、常见问题与排查

1. 模型编造结论：多因提示词缺少约束或条目缺来源段。解决：强化“必须引用路径”的约束，补齐条目来源，重要结论人工核对原文。
2. 知识库变大后上下文装不下：坚持“索引 → 摘要 → 条目 → 原文”的分层阅读，按主题裁剪候选范围，必要时引入向量检索。
3. 概念条目重复、粒度混乱：定期让模型执行“合并重构”，将近义概念合并为主条目并统一模板。
4. 图片利用率低：文件名即描述，为关键图片撰写图注；具备多模态能力时可让模型生成图片文字说明。
5. 更新后旧条目过期：引入变更日志，新资料先摘要再增量编译，定期巡检高频引用条目。
6. 问答范围漂移：在入口处限定“仅基于知识库回答”，超范围问题直接提示补充资料。

七、优化建议

• 性能与成本：区分“编译期”与“问答期”开销，缓存摘要等中间产物，低价值资料只做摘要登记，避免重复全量编译；
• 安全与合规：敏感语料先脱敏；有合规要求时优先本地或私有化部署的模型能力；使用云端对象存储时配置最小权限与日志审计；
• 可维护性与稳定性：知识库整体纳入版本管理，将链接检查、清单一致性检查写成脚本并例行执行。

八、总结

本教程以 Harness 工程思想为主线，完整走通了“目录规范 → 语料摄取 → 条目编译 → 索引分层 → 问答 → 输出”六步流水线。核心经验有三条：把状态沉淀为文件工件，让上下文可持久化；用索引与摘要构建分层检索，控制上下文规模；人保持“在环”审校，模型负责撰写与维护。后续可以继续探索更细粒度的溯源引用、多模态资料的沉淀方式，以及问答质量的量化评估，并把这套个人知识库经验迁移到团队级知识管理中。