Synthetix 如何把本地文档知识库用于可追溯的长文写作？

Synthetix 是一个可自托管的知识与长文写作工作台，适合把大量 PDF、DOCX、PPTX、HTML、EPUB 和文本资料整理成可检索知识库，再按大纲逐节生成报告、方案或技术文档。它不会把全部文件简单塞进一次对话，而是维护原始分块、知识图谱和 Wiki 三层知识，并记录每个章节使用的来源。

它解决的不是普通聊天问题

当资料超过模型上下文窗口时，一次性上传和总结容易遗漏细节；当文章包含多个章节时，逐次对话又容易前后矛盾。Synthetix 把资料处理、检索、头脑风暴、大纲、章节生成、版本确认和导出做成有状态流程。

项目更适合研究报告、咨询文档、技术提案和项目材料等需要来源检查的长文。它不是无需配置的桌面笔记软件，源码运行依赖严格的 Node、pnpm、Python、数据库迁移和模型服务环境。

三层知识库各自负责什么

知识层	内容	写作作用
原始分块	带全文与向量索引的文档片段	保留可核对的直接证据
LightRAG 图谱	实体、关系和跨文档连接	发现单纯相似度检索遗漏的关系
知识 Wiki	摘要、主题、概念和主张	形成可编辑、可复用的综合知识

Wiki 是模型综合层，不是原文。重要主张仍应通过关联来源回到原始分块核查。

选择安装方式

Windows 用户可优先使用项目 Releases 提供的 Electron 安装程序。源码开发要求 Node.js 24.18.0 且低于 25、pnpm 11.15.0 和 Python 3.14.6；macOS 桌面开发要求 macOS 12 或更高版本。

git clone 项目仓库地址
cd Synthetix
pnpm install
cp .env.example .env
npx prisma migrate dev
npx prisma generate
npm run dev

本机访问 3000 端口后创建首个管理员账户。部署到其他机器时必须为 JWT_SECRET 生成高强度随机值，并正确设置应用地址。

配置聊天与嵌入模型

设置中至少需要一个聊天模型和一个嵌入模型。系统支持 OpenAI 兼容端点、Anthropic、Ollama 等路径，实际可用能力取决于提供方和模型。

若要启用知识图谱和完整分析模式，嵌入维度必须至少为 1536。768 或 1024 维模型会使图谱模式不可用，并回退到基础检索。配置后应在界面确认系统检测到的真实维度，而不是只根据模型名称判断。

使用远端聊天或嵌入服务时，相关文档片段会发送给服务商。只有处理链、数据库和模型端点均在本机时，才能称为完整离线。

上传并处理来源文档

当前写作管线支持 PDF、DOCX、PPTX、HTML、EPUB、TXT 和 Markdown，不包含电子表格。上传后，文档会经历转换、结构化切分、嵌入、全文索引等阶段；图谱和 Wiki 作为后台增强继续运行。

项目允许基础检索先于所有增强层完成，因此“文档可搜索”不代表图谱和 Wiki 已完成。开始重要写作前应检查文档状态和各处理分支。

先验收知识库再开始写作

1. 在关键词搜索中查找独有术语，验证 SQLite FTS5 索引。
2. 用改写问题测试语义搜索和直接嵌入回退。
3. 检查来源预览、相关度和文档身份是否正确。
4. 在图谱中抽查实体关系是否有证据支撑。
5. 打开 Wiki 条目，区分来源事实与模型综合。

语义搜索会组合 LightRAG、直接向量、关键词和排序融合。高相关度仍不是事实证明，数字、否定条件和因果关系必须回到原文。

从头脑风暴生成递归大纲

写作流程从目标、受众、范围和文档形态澄清开始，再生成可编辑的递归大纲。正式生成正文前，应人工调整章节顺序、删除重复节点，并为每节写出明确任务。

好的章节要求包含预期结论、必须引用的资料范围、篇幅和禁止推断项。大纲越明确，分节检索越容易找到正确上下文。

逐节生成而不是一键写完

每个章节的提示上下文可包含当前大纲位置、父级与相邻章节、已完成章节摘要、Wiki 条目、RAG 分块和图谱来源。这样既控制单次上下文规模，也维持全文一致性。

建议先生成一节试稿，检查语气、来源和结构后再批量处理。对关键章节可以用 A/B 模式让两个模型在相同上下文下生成，再选择或合并。

如何检查可追溯性

Synthetix 会保存章节所用的来源文档、分块、来源类型、相关度和支持内容。引用面板把原始 RAG 片段、图谱来源和 Wiki 条目分开显示。

审阅每个关键主张时应完成三步：

1. 确认章节确实列出支持片段。
2. 打开片段并定位到对应来源文档。
3. 判断原文是否支持当前措辞和推理强度。

引用被保存只证明系统使用过该上下文，不自动证明生成句子准确。

利用拓扑视图发现证据缺口

文档拓扑把生成章节与支持它们的上传文档连接起来，并显示覆盖率及高频来源。它适合发现某一章节没有来源、全文过度依赖单一文件，或大量资料从未被使用。

拓扑没有连线时，不应仅为提高覆盖率随意添加引用。应先判断该章节是否属于原创分析，还是检索策略遗漏了证据。

版本确认、审计与导出

章节可以保存多个版本、确认当前版本并回滚。只有确认后的章节才能稳定进入最终导出。完成全文后，应运行内容审计，重点检查无来源断言、章节重复、术语不一致和结论超出证据。

导出支持 Markdown、PDF 和 DOCX。PDF 渲染依赖 Playwright，DOCX 和 PDF 生成还涉及 Python 导出脚本。交付前应打开成品检查目录、图片、分页、代码块和中文字体。

MCP 自动化入口

配套 MCP 服务可以让 Codex、Claude Code 或 OpenCode 通过 REST API 驱动文档摄入、头脑风暴、双模型写作和导出。需要先在设置中创建 API 密钥，再把服务注册到 MCP 客户端。

API 密钥应存入客户端的安全配置或环境变量，不要写入正文、版本库和日志。MCP 自动化不会替代人工审核，尤其不能自动接受所有章节版本。

当前限制与风险

• 源码工具链版本要求严格，升级 Node 或 Python 前需验证。
• 电子表格不属于当前文档写作管线。
• 低维嵌入模型会关闭图谱增强。
• 后台队列和 Python RAG 任务增加了故障排查复杂度。
• 自托管不等于模型请求必然本地。
• Wiki 和图谱都是派生知识，可能包含模型错误。

一套稳健的交付流程

阶段	通过标准
资料	文件处理完成，来源身份清楚
检索	关键词与语义测试都能命中证据
大纲	章节任务、受众和范围明确
写作	逐节生成并确认版本
引用	关键主张逐条回到原始分块
覆盖	拓扑中的缺口与单一来源偏差已解释
导出	Markdown、PDF 或 DOCX 视觉检查通过

Synthetix 的核心优势在于把长文写作变成可检查的状态流程。真正的可追溯性来自保存引用、回看原文和控制推理强度，而不是仅在章节末尾显示一串来源名称。