夜雨聆风
Kreuzberg 连接文档世界,Tree-sitter 连接代码结构,LSP 连接工程语义——三者组合,构成下一代工程智能入口.
在很多人的直觉里，文档处理和代码理解是两条完全不同的链路：
- PDF、Word、PPT、截图、扫描件、邮件附件，归文档工具处理；
.ts、.py、.rs、SQL、Shell，归代码工具处理。
但真实世界里的研发工作流，并不是这样割裂的。
一个典型问题工单，往往同时包含：
- 一张报错截图；
- 一段 SQL；
- 一页 PDF 操作文档；
- 一段聊天里贴出来的代码；
- 以及仓库里真正需要被修改的源文件。
这也是为什么，单独强调 OCR、单独强调 AST、或者单独强调 LSP，都还不够。 真正有产品价值的，是把这几条能力链路接起来。
而 Kreuzberg + Tree-sitter Language Pack，正好构成了这样一套非常自然的组合：
- Kreuzberg 负责把现实世界中的异构材料吃进来；
- Tree-sitter Language Pack 负责把代码相关内容提升为结构化语法对象；
- 如果进一步叠加 LSP，就能把这套链路推向更强的编程助手与工程智能能力。
一、为什么这两个项目天然适合放在一起
1. Kreuzberg 解决的是“摄入问题”
Kreuzberg 的价值不只是 OCR。
它真正重要的地方在于：把现实世界里杂乱、异构、带格式、带图片、带扫描噪声的材料，统一转换成后续流程可以继续消费的文本与结构化输出。
换句话说，它是一个非常强的入口层：
- 可以吃 PDF、Office、图片、邮件附件；
- 可以处理扫描件和截图；
- 可以输出 text / markdown / json；
- 可以把“本来根本没法进代码理解流程”的材料，转成后续可处理的输入。
如果没有这一步，很多真正有业务价值的场景根本无法开始。
2. Tree-sitter Language Pack 解决的是“结构问题”
Tree-sitter Language Pack 的价值也不只是“支持很多语言”。
它真正重要的地方在于：把代码文本从字符串，抬升为语法结构。
这意味着系统不再只是看到一段文字，而是能进一步理解：
- 这是一段函数定义还是调用；
- 这是 import 还是配置项；
- 这是 SQL 语句块还是 Bash 脚本片段；
- 这段代码应该如何切块、如何抽取 symbol、如何作为后续分析的结构化对象。
所以，从产品视角看：
- Kreuzberg 负责“让材料进得来”；
- Tree-sitter Language Pack 负责“让代码看得懂”。
二、单独使用为什么都不够
1. 只用 Kreuzberg，不够“代码智能”
只用 Kreuzberg，系统当然能抽取出代码文本。 但很多高价值问题依然回答不好：
- 这段代码属于哪个函数？
- 这段 SQL 到底是查询、变更还是迁移脚本？
- 这段错误日志最可能对应哪类代码结构？
- 文档里的这段 fenced code block，在仓库里可能落到什么对象上？
因为它还停留在“文本内容”层，而不是“代码结构”层。
2. 只用 Tree-sitter，不够“现实世界输入”
只用 Tree-sitter Language Pack，系统当然能处理源代码。 但它天然不擅长：
- OCR；
- PDF / Word / PPT 的统一摄入；
- 截图、扫描件、邮件附件的处理；
- 从异构文档中提取代码片段和技术上下文。
这意味着，很多现实业务里的高价值材料，根本进不了 Tree-sitter 的处理链路。
三、联合使用后的完整价值链
如果把这两个项目放在一起，它们形成的不是简单叠加，而是一条完整的价值链：
可以把这条链路理解为四层：
- 输入层：文档、截图、扫描件、邮件附件、代码仓、代码文件、代码块。
- 摄入层：Kreuzberg 负责统一提取、OCR 和格式归一化。
- 结构层：Tree-sitter Language Pack 负责语法解析、chunking、symbol 抽取。
- 应用层：问答、检索、审计、迁移、代码导航、修改建议、影响面分析。
如果再叠加 LSP，则还会出现一层更强的“工程语义增强层”：
- definition
- references
- hover
- diagnostics
- rename
这时，这套组合就不只是“文档处理 + 代码解析”，而是更接近一个真正可落地的工程智能底座。
四、最值得讲出去的 6 类业务场景
下面这些场景，最能体现 Kreuzberg + Tree-sitter Language Pack 联合使用的价值。
1. 工单自动分诊：从截图和附件，直接落到代码对象
这是最容易被理解、也最容易体现价值的场景。
一个工单并不总是规范输入，更多时候包含的是：
- 一张错误截图；
- 一段日志；
- 一个 PDF 手册；
- 一段 SQL；
- 一段用户从 IDE 里复制出来的代码。
Kreuzberg 先把这些材料统一抽出来，Tree-sitter 再把其中的代码与脚本部分结构化。 这样输出就不只是“这像是数据库问题”，而是可以进一步走向：
- 可能是哪个模块；
- 可能是哪一类函数；
- 可能对应哪段脚本；
- 应该把工单路由给谁。
这就是从“文本理解”升级到“工程对象定位”的关键一步。
2. 升级迁移助手：把 release notes 变成真实改造清单
这是另一个非常强的宣传点。
升级迁移从来不是纯代码问题，也不是纯文档问题。 真正的困难在于：
- 上游的变化写在 release notes、迁移指南、博客和示例里；
- 真正需要改动的内容，分散在多个语言、多种脚本和多个仓库里。
Kreuzberg 适合吃掉升级说明、文档、示例和附件。 Tree-sitter Language Pack 适合扫描实际代码结构，找到受影响的 import、API 调用、脚本块和配置入口。
这样系统输出的就不是普通摘要，而是：
- 哪些位置会受影响；
- 哪些语言的仓库需要优先处理；
- 哪些改动风险更高；
- 可以怎样分阶段迁移。
3. 交付验收一致性检查：文档承诺是否真正落到代码里
这是非常强的企业场景。
很多交付问题不在“有没有文档”，也不在“有没有代码”，而在于： 文档写了，但代码到底有没有实现？
这里恰好需要两边同时存在：
- Kreuzberg 负责读取需求说明书、接口文档、数据库说明书、演示截图；
- Tree-sitter Language Pack 负责解析交付代码、SQL 初始化脚本、Shell 运维脚本。
这样就能从“文本承诺项”走到“代码实现点”，真正做出：
- 接口是否真的存在；
- 字段是否真的实现；
- 配置是否真的落地；
- 脚本是否真的包含交付承诺中的动作。
这类能力非常容易让业务方感知价值。
4. 工程知识库 / RAG：让文档和代码不再分家
很多技术知识库失败，不是因为资料太少，而是因为：
- 文档系统有文档；
- 代码仓有代码；
- 两者互相不通。
Kreuzberg 让文档、截图、扫描件、附件都能进系统； Tree-sitter Language Pack 让代码文件、文档里的代码块、OCR 出来的代码片段，都能变成结构化对象。
于是，知识库不再只是“文本切块”，而会变成：
- 文档按标题、段落、结构切；
- 代码按函数、类、语句块切；
- 问答时既能拿到业务背景，也能拿到真实代码结构。
对于研发助手来说，这是非常核心的体验差异。
5. OCR 代码截图恢复：把图片里的代码变成可分析资产
这类场景很容易被低估，但其实极其实用。
在真实工作中，代码经常不是以源码文件形式出现，而是：
- IDE 截图；
- 手机拍照；
- 扫描 PDF 中的一小段代码；
- 聊天消息里的图片。
Kreuzberg 负责 OCR，把图片里的文字捞出来； Tree-sitter 负责把它从“像代码的字符串”变成“可以切块、可以识别语言、可以分析结构的代码对象”。
这并不一定意味着直接自动改代码， 但非常适合做：
- 检索；
- 问答；
- 归档；
- 代码片段分类；
- 与正式仓库内容做关联。
6. 编程助手 + LSP：从“读代码”走向“理解工程”
如果说前面的 5 类场景已经足够说明 Kreuzberg + Tree-sitter 的价值， 那么再叠加 LSP，整个故事就会更完整。
这时系统的能力边界会进一步拉高：
- Kreuzberg 负责让文档、截图、附件进入系统；
- Tree-sitter 负责统一语法层，处理代码结构、代码块、OCR 片段和多语言 fallback；
- LSP 负责语义层，处理 definition、references、hover、diagnostics 等需要项目上下文的能力。
这意味着系统可以同时处理：
- 文档里的代码片段；
- 聊天里贴出来的不完整代码；
- 仓库里的真实文件；
- 带 workspace 语义的跨文件分析。
这时的产品形态，就已经非常接近现代编程助手与 IDE assistant 的期望值了。
五、结语
真正高价值的技术产品，往往不是单点能力最强，而是能够把原本割裂的世界接起来。
Kreuzberg 和 Tree-sitter Language Pack 的组合，恰好具备这种气质：
- 一个向上连接真实世界里的文档、截图、扫描件和附件；
- 一个向下连接代码的语法结构与工程对象；
- 如果再叠加 LSP，就能把这条链路推进到更完整的工程智能与编程助手场景。
