企业官网建设流程全解析

如果你经常需要在一份长文档里查证一个细节，应该对下面这个过程很熟悉：看到一段关键结论，选中文本，复制，打开问答工具，粘贴，然后在输入框里补一句“这是文章里的一句话，请解释它的背景依据”。问题本身不算复杂，但每次重来一遍，耐心会消耗很多。DeepGraph 提出的“选中即问”，改变的正是这个环节。它不是让你更快地搜索，而是让你在保留上下文的情况下直接提问。顺着这个思路往下想，会发现这背后不只是少复制两次粘贴的问题，而是人和知识交互方式的颗粒度变了。

无论 DeepGraph 最终面向的是知识图谱、文档库还是代码分析场景，“选中即问”这四个字都值得单独讨论。它意味着用户不再需要先描述背景，再描述问题，最后等待模型根据一段被抽离出来的文字“盲猜”。它把选中的内容当成提问的锚点，把上下文交给工具去感知。这篇文章不打算猜测 DeepGraph 的全部功能，而是想从“选中即问”这个交互范式出发，聊聊它为什么有价值、落地时有哪些关键问题、以及真正用起来之后会遇到什么样的坑。

1. “选中即问”真正解决的不是提问速度，而是上下文锚点问题

1.1 传统问答丢掉的那部分信息

过去我们使用通用 AI 问答工具，最常见的工作流是：复制文本、粘贴、补充背景、提问。问题在于，当你把一段话单独拿出来的时候，它原本所处的位置、前后段落、章节标题、文档上下文，全都消失了。

这会造成什么后果？同一段文字在不同的上下文里，含义可能完全不同。比如“这个方案成本很高”，在预算评审文档里，讨论的是资金压力；在技术架构文档里，讨论的可能是计算资源复杂度。模型没有上下文，只能从这段话本身去猜。你需要在输入框里手动补全“这是某某文档中第几章关于成本的结论”这类信息，但大多数用户不会这么做，而且也不应该由用户来做。

更麻烦的是，很多内容并不适合被单独复制出来。代码里的一行函数调用，脱离了所在的模块、调用链和依赖关系，就很难判断它的真实行为。产品需求文档里的一句“用户可以自定义规则”，脱离了前后功能清单，就无法区分它究竟是权限模型的一部分，还是交互设计的一部分。传统问答方式把所有组织上下文的成本都推给了用户，而用户在真实工作里是不愿意做这件事的。

1.2 选中即问如何把上下文变成锚点

“选中即问”的思路是从交互层面解决这个问题。用户选定一段内容，然后点击提问或按快捷键，系统不再只把选中的文本交给模型，而是把选区位置、周围内容、文档元数据、甚至关联对象一起组装成一个完整的提示词。

这个过程在工程上并不神秘。假设实现一个通用版本，整体逻辑大致是这样的：

def handle_selection(selection): anchor = { "text": selection.text, "source_path": get_current_document_path(), "title": get_current_document_title(), "surrounding": extract_context( selection, before=1000, after=1000 ) } prompt = build_prompt( instruction="请基于选区内容回答用户问题，并标注引用。", anchor=anchor, question=user_question ) return ask_llm(prompt, enable_citation=True)

这里最关键的一步是extract_context。它决定了模型能看到多少背景信息。可以取选区前后各若干字符，可以扩展出一整段、一整章节，也可以根据文档结构把标题层级填进去。对于 DeepGraph 这类工具，如果它真的包含图结构，那么上下文还可能包括选中节点相邻的节点、边、关系类型等。

所以，“选中即问”真正改变的并不是“问得快一点”，而是让模型从一开头就拿到必要的位置信息。选区不再是孤立的文本，而是知识结构里的一个锚点。模型不需要靠猜测来补全背景，回答的自然度、准确度和可验证性都会因此变化。

1.3 真正被改变的是提问的“上下文精度”

我可以直接给你一个判断：上下文精度，是“选中即问”这类工具最核心的收益，而不是交互酷炫。

过去在通用问答中，用户要同时承担两个角色：一个是提问者，一个是上下文整理者。提问者思考“我想知道什么”，上下文整理者思考“模型需要知道哪些背景”。后者往往更耗精力，也更影响回答质量。一旦“选中即问”把上下文理解交给工具，用户就可以更专注于提问本身。

这会带来一个容易被忽略的行为变化：因为提问成本降低了，人们会愿意问更多小问题、验证更多细节。以前你可能不会为了一个术语解释去复制整段上下文，现在你可以选中它直接问。这种“随时追问”的小动作积累起来，会让一个人对复杂材料的理解深度发生改变。换句话说，“选中即问”不是帮你省时间，而是降低了你深入理解事物的启动成本。

2. DeepGraph 的想象空间：问答结果接回图结构

2.1 从命名看，问答的终点可能不是文本，而是图

DeepGraph 这个名字里带了 Graph，很难不让人往知识图谱、关系网络、图数据库方向想。如果它只是做一个划词问答，那名字也许不会带 Graph。合理的猜测是，它想让内容之间的关联变成可视化结构，然后在这个结构上支持问答。

这样的产品逻辑其实很自洽。普通问答是“文本进、文本出”，每次交互都是独立的。但如果把选中的内容当成图上的一个节点，把问题和答案当成新的节点，把每次引用关系当成边，那么“选中即问”就不再是一次性消费，而是在逐步构建一张知识网络。

举个例子，当你在一份技术文档里选中“缓存穿透”这个词，问“这个概念的触发条件是什么”，系统如果能把答案和原文段落、上游概念、风险后果连接到同一个节点上，那么下次你选中“缓存穿透”时，就已经能看到它的历史问答和相关节点。这是一种比聊天记录更有结构的知识积累方式。

2.2 单次问答和图谱积累的差别

单次问答是消费型交互，问完就结束。即使答案正确，这段对话的价值也仅限于当下。图谱化积累则不同，它把每一次问答当作一次知识补充：问题是一个节点，答案是另一个节点，选区对应的内容是锚点，引用关系是边。

这种设计对有长期维护价值的场景非常有用。比如阅读代码库时，选中一个函数问“这个函数被哪些模块调用”，系统如果能把函数节点和调用模块节点连起来，逐渐就能形成一张调用关系图。比如阅读合规文档时，选中一条规则问“这条规则对应哪些业务动作”，问答记录可以持续更新，成为团队内部的解释入口。

但要注意，这种复利不是自动发生的。问答变成图谱节点，需要经过实体识别、关系抽取、去重、合并等步骤。任何一个环节出错，图谱里的内容就可能变成垃圾进、垃圾出。后续再基于图谱问答，错误会被放大。所以，图结构应该先服务于“组织信息”，而不是一开始就追求“自动生成复杂关系”。

2.3 不要高估自动建图，先跑通“问答链路”

从我的经验看，很多图产品翻车都翻在“自动建图”这一步。模型抽取出来的实体和关系不一定准，如果直接把它们铺成图谱，用户会看到大量错误连线、重复节点和无意义标签。这样的图谱比纯文本更难维护，因为错误藏在视觉结构里，散落在屏幕上，肉眼很难逐一检查。

如果你正在评估 DeepGraph 或者类似工具，我建议把关注顺序反过来：先看“选中 -> 提问 -> 得到带引用的答案”这条链路是不是稳定；再看问答结果能不能保存、回看、批量审查；最后才看图谱是否自动生成。图可以作为可视化索引，但节点的准确性要靠用户确认或规则校验。自动化的东西越复杂，越需要人机协同来兜底。

3. 接入工作流之前，先想清楚四个关键问题

3.1 选区边界：选一句、选一段，还是一屏？

“选中即问”看起来简单，但“选多少”是一个被低估的设计问题。选得太短，模型看不到完整背景；选得太长，噪声和成本一起上升。

我的建议是：

• 问术语、概念、字面意思时，选一个词或一个短语就够了。
• 问逻辑、观点、风险时，选一个完整段落，并让系统附带章节标题。
• 问“整篇文章讲了什么”时，选区反而不重要，应该直接把整个文件作为上下文。

如果你在使用支持参数调节的工具，通常应该先设置“选中后自动扩展上下文”的开关。默认扩展 500 到 1000 字是一个比较稳妥的起点。不要一上来就把整个文档塞进去，上下文窗口不是越大越好。

3.2 上下文窗口：不是越多越好，而是越相关越好

很多人的第一反应是：既然模型支持长上下文，那我干脆把整篇文档都给它。这个想法听起来合理，实际并不高效。窗口越大，无关信息越多，模型越容易被不相关的内容带偏；同时 token 开销和响应延迟都会上升。

可以考虑这样处理：先把选区的全文作为候选上下文，然后做一次相关性筛选。常用的做法是 embedding 召回，把与选区最相似的前几个片段拼接到 prompt 里。如果工具没有实现召回，也可以退而求其次，把选区前后各 N 个字符固定作为上下文。关键在于，你要给上下文设置预算，而不是无限制地增长。

另外，历史对话也是一个容易被忽略的上下文来源。不要在每次提问时都带上全部历史消息，只需要保留与当前选区相关的几个轮次即可。否则对话一长，输入 token 会迅速膨胀，回答质量反而下降。

3.3 引用溯源：没有引用原文的问答，只能算半成品

“选中即问”的价值在于可验证，而可验证的前提是答案能回到原文。如果模型给了你一个判断，却不告诉你是从哪句话推出来的，你仍然要自己重新读一遍文档去确认。这实际上把验证成本又还给了用户。

因此，一个合格的“选中即问”实现，必须让答案携带引用。至少应该包含：来源文档路径、选中原文的起止位置、命中的关键句子。更可靠的实现方式是让模型只能基于给定片段作答，并要求它把每个结论映射回原文片段，而不是让它自由发挥后假装标一个引用。

工程上可以维护“文本段落到原始位置”的映射关系。先把文档按段落或句子切分，给每段一个 ID，模型在生成答案时返回段落 ID，前端再根据 ID 定位到原文。这个方法不复杂，但能极大提升可用性。

3.4 权限边界：你选中的内容，不一定是模型该看到的

在企业场景落地时，权限问题比算法问题更致命。“选中即问”天然会把用户当前阅读的内容送给模型。一旦用户选择了一段他有权阅读但模型无权使用的数据，就可能造成越权请求或敏感信息外泄。

在接入任何大模型 API 之前，至少要检查三件事：当前用户是否有权限查看这个文档、这个章节、这段文本；请求日志里是否记录了谁在什么时候选中了什么内容；外部模型调用链路是否做了脱敏、截断或私有化部署。尤其是在合规行业，这一步不能省。

如果 DeepGraph 使用的是云端模型，而你的场景又比较敏感，可以选择本地模型或者私有化部署。虽然成本更高，但至少数据不会离开你的控制边界。否则，哪怕工具再方便，也不能把内部资料随意送出去。

4. 落地时最容易踩的坑，以及一套排查路径

4.1 选中了内容，AI 还是答非所问

这类问题出现时，不要急着怀疑模型能力不够。答案很可能是上下文没有正确传进 prompt。

可以按这个顺序排查：

1. 选区文本是否真的包含关键信息。有些时候，用户选中的是图片、表格，或者动态渲染出来的伪文本，选区内容可能为空。
2. 扩展上下文是否覆盖了重要背景。选区的下一句可能不在上下文中，导致模型看不到后续解释。
3. 提示词里是否把“用户问题”和“选中内容”的位置放反了，或者没有明确指示模型“优先参考选中内容”。
4. 模型是否被历史对话干扰。如果历史里有一大段无关讨论，当前回答也会被带偏。

更好的做法是：先跑一个最小测试。固定选中同一段文字，只提问“请用一句话总结这段话”，观察回答是否稳定。如果这个基础能力都不稳定，大概率是上下文组装的问题，而不是提问技巧的问题。

我可以给你一个排查参考表：

4.2 划词选不中，或者选区内容获取失败

如果你在用浏览器插件或桌面客户端，最常见的坑是：普通网页文本可以选，但 PDF、输入框、iframe 里的内容选不中。这本质上不是 AI 的问题，而是前端选区 API 和渲染层的问题。

排查链路可以这样走：先用一个纯网页文本测试，排除基础事件绑定问题；再检查动态 DOM，确认内容是否在页面加载后才渲染，需要等待 selection 事件；如果跨了 iframe，需要监听到 iframe 内部的文档内容；如果是 PDF，通常要使用 PDF 解析层提取文本，而不是依赖浏览器的 Selection API。

另外，桌面端如果基于 Electron 或 Tauri 开发，选区获取还要考虑文本是通过 Canvas 绘制的还是 DOM 渲染的。Canvas 文本无法直接 Selection API 获取，需要先做 OCR 或从数据层映射文本位置。这类问题很琐碎，但恰恰是“选中即问”落地时最影响体验的地方。

4.3 上下文超限、回答变慢、费用飙升

这三个问题放在一起，通常只有一个根因：不设预算的上下文增长。

可以给每次请求做一个 token 计算：选中文本 + 扩展上下文 + 系统提示 + 历史记录 + 当前输出。如果总 token 持续接近模型上限，就要裁剪上下文；如果单次请求速度变慢，往往是因为输入 token 太大；如果费用飙升，多半是因为每个操作都在重复发送大量 token。

比较实际的做法是：设置单次请求上下文 token 上限；对相同选区、相同问题的请求做缓存；清理无关历史；必要时选择更小、更快的模型。不要为了追求“完整背景”让每个问题都携带整份文档。先用最小上下文跑通，不够再加，才是更划算的策略。

5. 从“能用”到“用得久”：别只把它当成快捷问答

5.1 给“选中即问”配一套预置问题模板

“选中即问”最大的风险不是技术不好用，而是用户不知道问什么。如果每次都临时想问题，很容易停留在“解释一下这段”的低质量提问，浪费了工具本身能带来的深度。

可以提前设计几个高频问题模板：

• 解释：用一句话解释这段内容。
• 找依据：这段结论在原文中有哪些支撑证据？
• 找矛盾：这段内容和文档其他部分是否存在矛盾？
• 找风险：如果按这段操作，最可能遇到哪些问题？
• 对比：这段提到的方法和常见做法相比有什么差异？

模板的好处是让提问具备结构。你不用每次从零开始组织语言，只需要选中内容、选择模板、补充具体条件，就能得到比较稳定的输出。这也是把工具嵌入工作流最自然的方式。

5.2 为每一次问答建立结构化日志

个人使用可以不考虑日志，团队使用则一定要做。日志不只是为了留痕，更是为了评估工具长期效果和发现错误模式。

一条完整的问答日志至少应该包含：

{ "id": "q-0001", "source": "docs/architecture.md", "anchor": "keepalive 可以降低连接延迟", "question": "这段有什么前提条件？", "answer": "前提是连接池已经建立……", "citation": "docs/architecture.md#L102-L104", "created_at": "2025-01-01T10:00:00Z" }

当日志积累到一定量以后，你可以回过头来看：哪些问题类型经常出现？哪些文档内容的引用总是标错？模型在回答哪类问题时最不可靠？这些问题单靠记忆是总结不出来的，必须有一个结构化的记录。

5.3 建议的落地路径：先最小闭环，再图谱化

接触任何“选中即问”类工具，我的建议都是分层推进，不要一步跨到知识图谱。

第一步，选一个真实项目里的资料库，不要随便拿一篇公众号文章试，真实场景才有真实问题。第二步，定义五个高频问题类型，比如上文提到的解释、找依据、找矛盾、找风险、对比。第三步，跑通最小闭环，选中一段内容，提问，拿到带引用的答案，确认引用位置准确。第四步，连续记录二十次问答，观察错误分布，是选区问题、上下文问题还是模型回答问题。第五步，如果基础链路已经稳定，再尝试把问答结果沉淀成节点，让图谱慢慢长出来。

这套路径的核心原则是：先让每一次提问都准确、可验证，再谈自动化和知识网络。反过来做，大概率会得到一个看起来很炫但经不起推敲的图谱，最后连原始问答都不可靠。

“选中即问”看起来是一个交互小改进，但我更愿意把它理解成一个信号：AI 时代的人机问答，正在从“用户负责组织上下文”转向“工具负责感知上下文”。DeepGraph 这样的工具能不能做好，不取决于动画多炫，而取决于它有没有真的把选区、上下文和引用这三件事管理清楚。如果你正打算尝试这类工具，我建议不要从复杂知识图谱开始。先选一份你最熟悉的文档，问五个问题，把答案和原文对照一遍。能经得起这一关，再谈以后。