企业官网建设流程全解析

长对话里最让人头疼的问题是什么？不是模型不聪明，而是聊到最后，模型把前面说的关键信息忘了、混淆了，甚至一本正经地给出和前面矛盾的回答。这个现象有一个专门的称呼：LLM context drift，上下文漂移。这次我们来看一个思路非常直接的项目，作者在 Hacker News 上用一句话概括了全部工作：我搭了一个空间节点画布，用来修复 LLM 的上下文漂移。

这个项目没有走 RAG 或长窗口那套路线，而是把上下文从“一长串文本”改造成“一张可以摆放和连接节点的画布”。对话、文档、知识片段都变成节点，模型在回答时不再只盯着最后几轮对话，而是从画布上按需取用相关信息。本文会拆解 context drift 产生的原因、空间画布的设计思路、通用架构、部署与验证流程、API 接入和批量任务处理，最后给出一套可直接参考的排查清单。

先说结论：如果你正在做长对话、文档问答、知识库整理这类 LLM 应用，并且被“聊着聊着就丢信息”折磨过，这个方向值得认真试一遍。它不追求让模型记住更多，而是让模型更容易找到该记住的内容。

1. 核心能力速览

从项目标题和关键词能确认的核心信息如下表。由于原项目没有公开完整的参数文档，和显存、版本、运行环境相关的细节以通用实践为准。

这个项目的核心卖点不是“更强的模型”，而是一套更贴近人脑工作方式的上下文组织方式。它把 LLM 的单线叙事变成二维空间里的关系网络，从根上降低漂移发生的概率。

2. 适用场景与使用边界

空间节点画布本质上是一个“上下文管理中间层”。它坐在 LLM 前面，负责决定哪些信息进入 prompt，哪些信息先留着。理解了这一点，就能判断它适合什么场景。

2.1 适合谁

• 长对话应用开发者：需要让模型记住用户早期提到的一堆约束条件。
• 知识库问答团队：把不同来源的文档拆成节点，再按问题动态组装。
• Prompt 工程调试者：把复杂 prompt 展开成画布，直观查看上下文结构。
• 个人知识管理用户：类似 Obsidian Canvas 的用法，但目标变成让 LLM 读得更准。

2.2 不适合什么

• 简单单轮问答：杀鸡用牛刀，画布维护成本远大于收益。
• 对延迟极其敏感的生产服务：画布需要检索和组装上下文，比直连 LLM 多一层开销。
• 纯离线场景：如果没有本地 LLM 服务，画布前端本身没有生成能力。

2.3 使用边界

涉及版权素材、私有文档、用户隐私时，必须确认数据来源合法、使用已获授权。尤其是把画布内容传给第三方 LLM API 时，要评估敏感信息泄露风险。如果处理的是人脸、声纹、身份信息等，部署环境需要放在可信边界内，并做好访问限制。

3. 为什么线性对话会漂移：问题拆解

在理解空间节点画布之前，先搞清楚 context drift 为什么会发生。这决定了后面所有设计选择是否站得住脚。

3.1 线性窗口的天然缺陷

LLM 的上下文窗口是有上限的。当对话超过窗口长度，早期内容会被截断或压缩。更隐蔽的问题是，即使内容还在窗口内，新出现的语义相似的文本也会对模型的注意力产生干扰，导致模型“想不起来”前面的准确描述。

传统做法通常是三种：

• 增大上下文窗口：成本线性上涨，而且模型对窗口中间部分的注意力本来就偏弱。
• 摘要压缩：摘要本身就是一次有损压缩，关键数字和约束很容易丢。
• RAG 切割召回：适合事实检索，但对话中的逻辑依赖、前后顺序、矛盾修正信息很难用向量相似度找回。

3.2 对话结构比对话长度更重要

观察一个长对话的典型流程：用户先提需求 A，中途补充限制 B，之后纠正了对 C 的理解，最后让模型输出一份总结。

线性文本流里，这些信息是平铺的。模型只能靠位置去猜测哪些信息重要。一旦中间穿插了大量无关内容，关键信息就会被稀释。

空间节点画布的思路是：把信息按主题切块，每个块成为一个节点。节点之间用边表示依赖、补充、矛盾的逻辑关系。模型在生成回答时，只需要读取当前任务相关的子图，而不是从头到尾扫一遍。

3.3 漂移的三种表现

从实际使用角度，中文用户最容易遇到的漂移问题有三种：

4. 空间节点画布的设计思路

现在进入核心设计。空间画布解决漂移问题，靠的是三个机制：节点化、空间化、按需组装。

4.1 节点化：信息最小单元

每个节点是一个自包含的信息块。一个节点包含三件事：

• 内容：文本、代码、图片描述、超链接等。
• 元信息：创建时间、来源、标签、向量、重要性权重。
• 位置：画布上的二维坐标和尺寸。

节点的粒度很关键。太粗，节点内部还是会漂移；太细，画布会被碎片淹没。经验值是，一个节点表达一个完整的最小结论、要求或事实。比如“用户要求输出格式为 JSON”是一个节点，“模型的回复风格偏好”是另一个节点。

4.2 空间化：用二维位置承载语义

线性的上下文只能靠顺序表示关系，画布上可以同时表达多层关系：

• 左右位置：表示先后顺序或并列关系。
• 上下位置：表示抽象层级或从属关系。
• 分组框：表示同一个主题域。
• 连线：表示依赖、引用、修正、冲突。

空间化带来的直接好处是全局可见。用户能一眼看出某个主题的节点是否散落各处、重点是否被边缘化。模型在组装上下文时，也能按照空间邻近性和连接关系做局部采样，避免长尾干扰。

4.3 按需组装：动态生成 prompt

画布本身不是喂给模型的原始输入，它是一张“地图”。真正送到 LLM 的 prompt，是在每次请求时动态组装出来的。

组装流程可以设计成：

接收用户问题 -> 解析问题意图 -> 在画布上定位相关节点 -> 沿边扩展关联节点 -> 按重要性和时间排序 -> 拼装成结构化 prompt -> 调用 LLM

这个流程和 RAG 很像，区别在于关系扩展不是靠向量相似度，而是靠画布上的显式连接。显式连接的好处是可控、可解释，坏处是需要维护。所以这个工具最好配合一个还不错的本地 LLM 服务，让模型辅助完成节点切分和连线。

5. 原型系统架构与数据模型

把设计落成原型，至少需要前端画布、后端服务、LLM 接入三块。下面给出通用架构，实际项目路径、端口和依赖名需要按仓库说明替换。

5.1 前端画布

前端不需要从零写。可以借用成熟的开源图编辑库，比如 React Flow、Canvas 类组件库，或者直接基于 Obsidian Canvas 的功能思路做定制。

关键交互功能：

• 创建节点。
• 拖拽节点。
• 连接节点。
• 分组与折叠。
• 画布缩放与鹰眼导航。

5.2 后端服务

后端负责节点存储、关系管理、上下文组装、LLM 代理。一个最小后端接口设计如下：

5.3 数据模型

节点和边用 JSON 存储，示例结构如下。

{ "node_id": "node_001", "type": "requirement", "content": "用户要求所有回复使用 Markdown 表格输出", "meta": { "created_at": "2025-01-01T10:00:00Z", "source": "user_message", "importance": 0.9 }, "position": { "x": 120, "y": 240 } }

边的结构：

{ "edge_id": "edge_001", "source": "node_001", "target": "node_002", "relation": "supports" }

relation 字段建议支持这些枚举值：

• supports：支持/补充。
• depends_on：依赖。
• contradicts：与...矛盾。
• revises：修正/覆盖。
• example_of：举例。

5.4 Python 伪代码示例

下面是一段上下文组装的 Python 伪代码，展示如何把画布节点变成 prompt。实际项目需要用具体框架替换 HTTP 层和存储层。

def build_context(canvas_id, question, max_chars=6000): nodes = load_all_nodes(canvas_id) target_nodes = locate_nodes_by_semantics(nodes, question) selected = set() for node in target_nodes: selected.add(node) for edge in load_edges_from(node): if edge.relation in ("supports", "depends_on", "revises"): selected.add(edge.target) selected = prune_by_importance(selected, max_chars=max_chars) ordered = topological_sort(selected) return assemble_prompt(ordered)

这段伪代码已经体现了空间画布解决漂移的关键点：初始化时只选相关节点，再沿关系边扩展，最后做重要性裁剪和排序。

6. 环境准备与启动部署

由于原项目没有给出精确的启动命令，这里给一套通用部署流程。你拿到真实仓库后，按仓库 README 替换路径、端口和脚本名即可。

6.1 前置环境清单

• Node.js 18 或更高版本，用于前端画布。
• Python 3.10 或更高版本，用于后端服务。
• 可用的 LLM 服务：OpenAI 兼容接口、本地 Ollama、vLLM 服务均可。
• 磁盘空间：代码和依赖按项目大小预留，纯前端项目通常不足 1GB，后端依赖另算。

6.2 前端启动模板

cd spatial-canvas-frontend npm install npm run dev

启动后浏览器访问http://127.0.0.1:5173，如果端口被占用，按终端提示切换端口。

6.3 后端启动模板

cd spatial-canvas-backend python -m venv .venv source .venv/bin/activate pip install -r requirements.txt python app.py --host 127.0.0.1 --port 8000

6.4 配置 LLM 服务

后端需要知道 LLM 服务的地址。典型配置用环境变量，不要写死在源码里。

# .env 示例，实际变量名以项目为准 LLM_API_BASE=http://127.0.0.1:11434/v1 LLM_API_KEY=local-test-key LLM_MODEL=llama3.1 CONTEXT_MAX_CHARS=8000

如果使用 OpenAI 兼容接口，直接指向本地 Ollama、LM Studio、vLLM 都可以。注意，不要把敏感的 API Key 提交到 Git，也不要在公网裸奔。

6.5 一键启动脚本模板

方便日常开发，可以写一个启动脚本。

#!/bin/bash # start-dev.sh 模板，路径按实际项目修改 npm --prefix ./frontend run dev & uvicorn backend.main:app --host 127.0.0.1 --port 8000 & wait

7. 功能测试与效果验证

部署完成后，按照下面的顺序验证核心功能。

7.1 节点创建与画布编辑

测试目的：确认画布可以正常创建、拖拽、连接节点。

操作步骤：

1. 打开画布页面。
2. 右键创建三个节点。
3. 分别输入“用户要求 JSON 输出”“核心字段是 name 和 age”“错误示例：age 是字符串”。
4. 用连线把三个节点连接起来，后一个节点标记为 revises。

预期结果：节点能保存，拖动后刷新画布位置不丢失，连线方向正确。

如果节点位置不保存，优先检查后端存储接口是否正常工作。

7.2 上下文组装测试

测试目的：确认后端能根据问题把画布节点组装成有序的上下文。

请求示例：

curl -X POST http://127.0.0.1:8000/api/context/build \ -H "Content-Type: application/json" \ -d '{ "canvas_id": "demo_canvas", "question": "请输出用户要求的 JSON 字段" }'

预期输出：返回一段按依赖顺序排好的上下文文本，并且包含“输出格式必须为 JSON”“字段为 name 和 age”“age 不是字符串”这三条信息。

如果遗漏了 revises 节点，说明扩展边的逻辑只包含了 supports，需要在后端补上 revises 关系。

7.3 漂移对比测试

这是最重要的测试。设计一个对比实验：

• 对照组：用普通对话模式连续提问，长度逐渐增加，观察模型是否忘记最初约束。
• 实验组：把同样信息放入画布，每次追问前先调用 build_context 组装。

测试脚本逻辑可以这样写：

questions = [ "第一条限制：不要使用 markdown 表格", "第二条限制：语气要正式", "现在总结一下，输出风格上我要求什么？" ] # 对照组：直接把 questions 拼接进同一个 session # 实验组：把每条限制做成节点，每次调用前组装

判断标准：实验组应该稳定回答出“不要使用 markdown 表格、语气正式”，对照组在经历大量无关对话后可能出现遗漏。

7.4 长文本与多轮稳定性测试

准备一份大约 5000 字的中文文档，拆成 20 个节点，随机分布在画布上，然后用 20 轮追问验证信息召回率。每轮记录：

• 模型回答是否包含对应节点内容。
• 组装耗时。
• 输入 token 数。

这个测试可以暴露画布工具在高负载下是否真的比线性上下文更稳定。

8. 接口 API 调用与批量任务

空间画布的价值，长期看要靠 API 生态放大。只有能对接外部工具，它才能从“demo”变成“基础设施”。

8.1 核心接口请求示例

创建一个节点的请求：

curl -X POST http://127.0.0.1:8000/api/nodes \ -H "Content-Type: application/json" \ -d '{ "canvas_id": "demo_canvas", "content": "用户要求每次回答先给结论", "type": "requirement", "position": {"x": 10, "y": 20} }'

调用 LLM 生成回答：

curl -X POST http://127.0.0.1:8000/api/chat \ -H "Content-Type: application/json" \ -d '{ "canvas_id": "demo_canvas", "question": "我最早提的格式要求是什么？" }'

返回结构建议保持统一：

{ "reply": "用户要求每次回答先给结论。", "context_nodes": [ { "node_id": "node_001", "content": "用户要求每次回答先给结论" } ], "usage": { "prompt_tokens": 1200, "completion_tokens": 30 } }

返回 context_nodes 非常重要，它让用户能审计模型到底看了哪些内容，这一步对排查漂移问题非常关键。

8.2 批量导入文本

批量任务场景，比如把一批 Markdown 文档导入画布并切成节点，需要设计一个导入脚本。

import json import requests BASE_URL = "http://127.0.0.1:8000" def import_markdown(path, canvas_id): with open(path, "r", encoding="utf-8") as f: blocks = split_markdown_blocks(f.read()) for i, block in enumerate(blocks): payload = { "canvas_id": canvas_id, "content": block["text"], "type": "document_block", "position": {"x": i * 200, "y": (i % 5) * 100} } resp = requests.post(f"{BASE_URL}/api/nodes", json=payload, timeout=10) print(resp.status_code, block["title"])

批量任务的工程化要求：

• 每个节点带上 source 字段，记录原始文档路径。
• 处理失败后记录到 error.log，不中断整体流程。
• 增量导入时用文档 hash 判断是否重复，避免画布内容无限膨胀。

8.3 批量任务失败重试

画布工具处理长文档时，最容易失败的情况是节点切分后内容错乱。常见原因有两种：一种是文档编码不是 UTF-8，一种是分隔符太简单导致代码块被切断。

解决思路是给导入脚本增加校验。导入完成后，后端对每个节点做合法检查，包含节点大小阈值和文本编码检测，发现异常就丢弃或回退。

9. 资源占用与性能观察

资源占用没有统一的答案，取决于后端 LLM 服务和前端画布的数据量。但还是有一些通用观察方法。

9.1 前端画布性能

画布节点数量超过 1000 个时，浏览器渲染会成为瓶颈。建议观察：

• 拖动节点时 FPS 是否下降。
• 初始化加载是否出现白屏。
• 浏览器 DevTools Performance 面板是否有长任务。

如果卡顿，优先考虑节点懒渲染方案，只渲染视野范围内的节点。

9.2 后端组装性能

上下文组装耗时主要花在节点检索和排序上。节点数量在万级别以下，用普通内存遍历即可；超过十万，需要引入索引。

建议后端记录每次组装的耗时：

context build time: 23ms selected nodes: 12 prompt chars: 4560

如果组装时间持续上升，优先检查是不是每次把全部节点都加载到了内存里。

9.3 LLM 推理资源

显存占用由后端 LLM 决定。以 7B 量化模型为例，常见情况下 8GB 显存可以运行，但这只是参考值。实际占用必须按模型版本、量化精度和并发数测试。

观察方法：

• 后端是 Ollama，看ollama ps。
• 后端是 vLLM，看/metrics接口。
• 后端是 API 服务，看返回的 usage 字段。

空间画布本身不会显著增加显存开销。它的成本更多是组装的延迟和 token 的消耗。

10. 常见问题与排查方法

11. 最佳实践、合规与下一步

把一个画布工具真正用起来，有下面几条具体建议。

11.1 工程化建议

• 第一次使用小数据集验证，20 个节点以内最合适。
• 保存一套最小可运行配置，包括示例画布、示例 LLM 服务地址和示例问题集。
• 节点、输入素材、输出结果分目录管理，方便回溯。
• 批量任务必须有日志和失败重试。
• 接口服务绑定 127.0.0.1，不要直接暴露公网。
• 画布内容定期导出备份，JSON 结构适合直接纳入版本管理。

11.2 合规提醒

项目中如果涉及用户对话、个人文档、企业内部知识，要确认数据授权范围。上传到云端 LLM 服务前，必须脱敏或确认服务商的隐私协议。涉及人脸、声音、身份信息的材料，原则上不要流向未知服务。商用发布前对模型输出做人工复核，避免产生不当内容。

11.3 下一步可以扩展的方向

这套思路如果验证有效，可以继续往三个方向扩展：

• 在画布上实现节点级 RAG。点击一个节点就能看到它的相似节点，减少手动连线的成本。
• 自动冲突检测。每次新增节点时，调用 LLM 判断是否与既有节点矛盾，如果有，自动画出 revises 边。
• 从普通聊天记录反推画布。给定一段长对话，自动切分节点并建立关系，让用户无需手动整理就能用画布管理旧会话。

相比换更大的模型，空间节点画布提供的是另一种解法：通过改变上下文的结构，而不是无脑扩大容量，来解决信息遗漏和矛盾问题。值得先在一个真实的迷你长对话场景里跑一次漂移对比测试，再决定要不要把这个思路带到生产项目里。