企业官网建设流程全解析

文档处理是很多业务系统绕不开的地基工程。无论是合同信息录入、发票批量归档、简历解析，还是把 PDF 里的表格搬进数据库，团队通常要经历一套固定的流程：找 OCR 方案、写后处理脚本、处理乱版、调阅读顺序、再对接业务系统。这套流程不是不能跑，但每次换一种文档类型，就又要重新折腾一轮。

合合信息 TextIn xParse 上架 WorkBuddy 的消息，值得所有做 Agent 应用、知识库搭建和文档中台的人重新审视一次自己的技术选型。这次上架真正改变的，不只是“多了一个解析接口”，而是文档理解能力的使用方式：从过去写给代码开发者，变成现在可以服务“只说一句话的人”。

这篇文章会先拆解 TextIn xParse 和 WorkBuddy 分别解决了什么问题，再完整演示如何在 WorkBuddy 中接入 xParse Skill、如何用一句话跑通“上传文档—解析—结构化输出—入库”的全流程，最后给出实际项目中的选型建议和排查思路。无论你是 Agent 开发者、RAG 知识库搭建者，还是在做电商、合同、简历等文档密集型业务的工程师，这篇文章都值得收藏备用。

1. 这篇文章真正要解决的问题

先说一个经常被低估的事实：大模型出现之后，很多团队以为文档处理的难点已经被解决了。但实际上，大模型只能处理“已经变成文本的文档”，而真实世界里大量文档是扫描件、图片、复杂表格、双栏排版、甚至带印章的合同。

即使你用的是 GPT-4o 级别的多模态模型，直接把一个 50 页的扫描版 PDF 扔给它，也会遇到这几个问题：

• 长文本截断，中间页内容丢失。
• 表格结构识别不准确，合并单元格错乱。
• 阅读顺序混乱，双栏排版经常先读右栏再读左栏。
• 页码、页眉、页脚混进正文，污染后续的 Embedding 效果。

这就是 TextIn xParse 这类专业文档解析引擎存在的价值。它做的事情不是“识别文字”，而是把一份物理文档完整地还原成有结构、有顺序、有语义的数字化文档。

那 WorkBuddy 又是什么？从公开信息和实际使用逻辑来看，WorkBuddy 是一个面向个人和团队的 Agent 工作台，它整合了模型接入、知识库、Skill、MCP 工具连接等能力。你可以把它理解成一个“能力编排中心”：把大模型、文档解析、数据库、各类第三方工具都挂到同一个工作台上，然后用自然语言去调度它们。

这次 xParse 以 Skill 形式上架 WorkBuddy，意味着用户不用再写代码去调 xParse 的 API，直接在 WorkBuddy 对话里说“把附录的发票解析成表格存到知识库”，就能触发完整流程。

这篇文章适合以下读者：

• 正在用 WorkBuddy 搭建个人或团队工作台的开发者。
• 做 RAG 知识库，经常被 PDF 解析效果困扰的工程师。
• 做电商、金融、法律等文档密集型业务，想降低文档处理开发成本的人。
• 想了解 Agent 时代“能力即服务”到底怎么落地的技术决策者。

2. TextIn xParse 与 WorkBuddy 的核心概念

2.1 xParse 是什么：从“OCR 识别”到“文档结构化”

先区分一组容易混淆的概念：OCR、文档解析、文档结构化。

传统 OCR 做的只是“把图片里的文字变成可编辑文本”。但一份真实的业务文档远不止文字：它有标题层级、有表格、有图片、有页眉页脚、有复杂的阅读顺序。这些结构信息如果全部丢失，后面的 RAG 检索和结构化抽取都会受影响。

xParse 要解决的是更高一层的问题：把一份 PDF、扫描件或图片，还原成保留版面结构、阅读顺序、表格关系、标题层级的数字化文档。在 RAG 场景里，这种“结构保真”能力直接决定了检索质量。举个例子，一份双栏排版的论文 PDF，普通 OCR 会把左右两栏的文字混在一起输出，导致语义完全错乱；而 xParse 这类专业解析引擎会先识别版面布局，再按正确阅读顺序重组内容。

2.2 WorkBuddy 是什么：从“对话机器人”到“工作台”

WorkBuddy 不能简单理解成一个聊天框。从热词搜索中可以看到，WorkBuddy 相关的典型操作包括：安装教程、自定义指令、Skill、知识库、接入 DeepSeek、通过 MCP 直接访问数据库、搭建个人工作台。

把这几件事串起来，就能看出 WorkBuddy 的定位：它是一个 Agent 运行时环境，让非程序员也能通过自然语言编排工具链，同时保留开发者所需的扩展能力。

关键组件包括：

• 模型接入层：可以接入 DeepSeek 等主流模型。
• Skill 机制：把特定能力封装成可复用的指令模块，xParse 这次就是作为一个 Skill 上架。
• 知识库：用于存储和检索业务文档。
• MCP 连接器：通过标准协议对接外部数据源，比如数据库。
• 自定义指令：用户可以用自然语言定义 WorkBuddy 的“角色”和“行为方式”。

2.3 为什么 Skill 模式是这次变化的重点

过去接入 xParse，开发者需要做这几件事：

1. 注册 TextIn 账号，申请 API 密钥。
2. 阅读接口文档，构造请求参数。
3. 写代码处理 PDF 上传、等待解析、解析回调。
4. 写后处理逻辑，把返回结果清洗成业务需要的 JSON。
5. 和业务系统做对接。

整个过程短则一两天，长则几周。

而 xParse 上架 WorkBuddy 之后，xParse 的解析能力被封装成了 Skill，用户在对话中描述需求即可触发。开发者不需要关心请求格式、密钥管理和任务调度，这些都被 WorkBuddy 的运行时接管了。

这不是简单的“封装”，而是能力分发模式的变化。我把它总结成下表：

Skill 模式的价值在于：让专业能力可以被“广播”到更多非技术角色手中，同时保留技术角色做深度定制的空间。

3. 环境准备与前置条件

在开始接入之前，需要准备好以下环境。需要注意的是，具体版本号和界面入口会随着产品迭代变化，本文重点演示通用思路，版本细节以官方最新文档为准。

3.1 账号准备

接入 TextIn xParse 上架到 WorkBuddy 的 Skill，通常需要两个账号：

• WorkBuddy 账号：用于登录工作台、添加 Skill。
• TextIn 账号：有些接入模式下，xParse 的 API 凭证绑定在 TextIn 开放平台，需要先注册并获取 API Key。

如果你的团队使用的是 WorkBuddy 企业版或私有化部署版本，凭证获取方式可能会有调整，建议先联系对应平台的客户支持确认。

3.2 环境选择

WorkBuddy 的使用方式主要有两种：

• 在线使用（网页版）：直接在浏览器打开 WorkBuddy 的官网，登录后即可使用。适合个人工作台、快速体验和团队协作场景。
• 本地安装（桌面版 / Linux / 麒麟版）：从热搜词可以看到 WorkBuddy 有 Linux 版本和麒麟版，说明它覆盖了国产化环境。如果你的项目在信创环境内运行，选择本地安装或私有化部署更合适。

选择建议：

3.3 模型配置

WorkBuddy 作为 Agent 工作台，需要配置一个推理模型来驱动对话和任务编排。从相关的网络材料可以看到 WorkBuddy 可以接入 DeepSeek，这也是国内团队常用的选择。

在 WorkBuddy 的设置中，通常可以在“模型设置”或“模型管理”中找到配置入口。一般需要准备：

• 模型服务商提供的 API Key。
• 模型名称和接口地址（如果使用兼容 OpenAI 协议的网关）。

配置完成后，建议先发一条消息测试对话是否正常，再做 xParse Skill 的接入。

4. 在 WorkBuddy 中接入 xParse Skill 的完整流程

4.1 步骤一：在 WorkBuddy 中添加上架 Skill

登录 WorkBuddy 后，找到“Skill 市场”或“技能市场”入口。xParse 上架后，应当可以在 Skill 列表中找到。不同版本的迭代中，入口名称可能是“Skill 市场”“技能包”或“插件中心”，但逻辑一致：找一个可以浏览或安装能力模块的入口。

找到 xParse Skill 后，点击“添加”或“安装”。这一步通常只需确认授权范围，一般无需填写复杂参数。安装成功后，Skill 会出现在工作台的已安装列表里。

4.2 步骤二：配置 xParse API 凭证

从技术原理上看，WorkBuddy 的 Skill 底层仍然需要调用 xParse 的解析服务，因此大概率需要配置 API 凭证。这里有一个常见误区：很多人以为安装完 Skill 就能直接用，实际上还需要把 TextIn 的 API Key 关联到 WorkBuddy。

配置路径一般是：

1. 进入“账号设置”或“API 配置”。
2. 选择“TextIn”或“xParse”服务。
3. 填入 TextIn 平台获取的 API Key 和 Secret。
4. 点击“验证连接”，确认凭证有效。

验证是否成功的方法：看连接状态是否变为“已连接”。如果验证失败，先检查 API Key 是否复制完整、是否有多余空格，以及 TextIn 账号是否有对应服务权限。

4.3 步骤三：用一句指令触发文档解析

配置完成之后，不需要写任何代码，直接在 WorkBuddy 的对话窗口发出一条指令即可。例如：

请解析附件中的 PDF 合同，提取甲方、乙方、合同金额、签署日期，输出成 Markdown 表格。

如果你上传的是扫描件或者图片型 PDF，xParse 会自动执行 OCR。如果文档是文本型 PDF，xParse 则会走版面分析和结构化解析的路径。这一层差异不需要用户关心，WorkBuddy 会在后台自动选择合适的解析策略。

这里的核心判断是：xParse Skill 减掉的是“开发量”，不是“决策量”。也就是说，你仍然需要告诉 WorkBuddy 你想要什么结构、什么输出格式，但不需要关心拆 PDF 页、调 OCR、拼接结果这些底层工程细节。

5. 一句话触发智能文档处理的完整示例

这一节给出几个可以直接复用的示例。第一个是 WorkBuddy 对话式用法，第二个是自定义指令的编写思路，第三个是开发者眼中 xParse API 的对照实现，帮助大家理解 Skill 封装到底做了什么事。

5.1 示例一：WorkBuddy 对话指令

以下指令适用于已经安装 xParse Skill 的 WorkBuddy：

解析附件中的采购订单 PDF： 1. 提取所有商品名称、单价、数量、小计金额 2. 保留原表格的合并单元格关系 3. 输出为 Markdown 表格 4. 顺便计算合计金额

这条指令里的“顺便计算”其实很关键。xParse 只负责解析文档结构，而计算合计属于业务逻辑。在 WorkBuddy 这种 Agent 工作台中，解析结果出来后，WorkBuddy 的模型会继续执行计算，最终返回的是处理后的业务结果。

如果不用 WorkBuddy，以上的效果一般要写一个 Pipeline：

PDF 上传 → xParse 解析 → JSON 结果 → 后端计算合计 → 渲染 Markdown

而现在，这个 Pipeline 被 WorkBuddy 编排层串起来了。

5.2 示例二：自定义 Skill 指令的写法

WorkBuddy 支持用户自定义指令，这部分其实是 Skill 模式最容易发挥威力的地方。你可以把“发票录入”这类高频操作封装成一条固定指令，团队其他人直接复用。

一个常见的自定义指令模板：

{ "name": "invoice-parser", "description": "解析发票 PDF 或图片，提取发票号、开票日期、金额、购方、销方信息", "trigger_rules": [ { "keywords": ["发票", "invoice", "报销"], "action": "调用 xParse 解析附件，提取结构化字段" } ], "output_format": { "invoice_no": "string", "invoice_date": "string", "total_amount": "number", "buyer_name": "string", "seller_name": "string" }, "fallback": "如果 xParse 返回结果缺少字段，在回复中明确标注缺失项" }

注意：这段 JSON 是 Skill 编排思路的示例，具体字段名以 WorkBuddy 官方模板为准。但其中的设计思想是通用的——明确触发词、明确动作、明确输出结构、明确异常兜底。

5.3 示例三：开发者视角的 xParse API 调用对照

为了理解 Skill 封装到底省掉了什么，这里给出一个通过代码直接调用 xParse API 的最小示例。注意，实际 URL 和参数以 TextIn 开放平台文档为准，这里演示的是通用调用模式。

import requests import json # 凭证信息，从 TextIn 开放平台获取 api_key = "your_textin_api_key" api_secret = "your_textin_api_secret" # 实际接口路径以 TextIn 官方文档为准 url = "https://api.textin.com/ai/service/v1/parse_ocr" headers = { "x-ti-app-id": api_key, "x-ti-app-secret": api_secret, "Content-Type": "application/pdf" } # 读取 PDF 文件 with open("contract.pdf", "rb") as f: file_data = f.read() resp = requests.post(url, headers=headers, data=file_data) if resp.status_code == 200: result = resp.json() # 这里返回的是结构化解析结果 print(json.dumps(result, ensure_ascii=False, indent=2)) else: print("请求失败:", resp.status_code, resp.text)

这段代码展示的是传统接入方式。在 WorkBuddy 中，这些细节被 Skill 封装了，业务人员不需要接触。但对开发者而言，理解底层调用逻辑仍然非常重要——当 Skill 返回结果异常时，你需要知道问题出在解析环节还是编排环节。

6. 运行结果与效果验证

6.1 怎么判断解析成功

在 WorkBuddy 对话中发出解析指令后，预期会出现以下结果：

1. WorkBuddy 返回结构化内容（Markdown 表格、JSON 片段或自然语言总结）。
2. 如果要求输出表格，表格中的行列能和原文档对应。
3. 如果要求提取字段，返回的字段值核对无误。
4. 附件数量多时，WorkBuddy 会分批处理并在回复中提示进度。

一个稳妥的验证方式是：先拿一份样本文档做对照测试。准备一份你已经知道答案的合同或发票，让 WorkBuddy 解析后，把结果和标准字段逐一比对。比如甲方名称是否准确、金额小数点是否一致、表格是否需要列对齐。

这里提醒一句：解析引擎不是百分百完美，扫描质量差的文档仍然可能出现识别误差。建议在关键业务场景中保留“人工复核”节点，而不是完全信任自动化结果。

6.2 如果失败，先看哪里

优先按以下顺序排查：

7. 常见问题与排查方法

针对 WorkBuddy 接入 xParse Skill 和日常使用中的高频问题，整理如下：

特别提示：如果你把 xParse 解析后的内容存入数据库，务必先确认数据库表结构支持新增字段，并做好备份。允许在生产环境变更前，先在测试环境的 WorkBuddy 实例中跑一遍完整流程。

8. 最佳实践与工程建议

8.1 文档解析类 Skill 的正确打开方式

xParse Skill 在 WorkBuddy 中的最佳定位，不是“万能文档魔法”，而是“可靠的结构化管道”。要发挥它的价值，需要注意三件事：

第一，输入规范化。在上传 PDF 之前，先做命名规范，比如合同-供应商A-20240115.pdf。结构化文档命名有助于后续检索和管理。解析执行前通知用户填写文档类型、关键词或目标格式，能显著提升模型编排成功率。

第二，输出结构化。不要只在对话里让人读结果，尽量要求 xParse 输出为 JSON 或 Markdown 表格，并挂载到知识库或数据库。否则解析结果无法被下游消费。

第三，建立反馈闭环。当用户纠正了解析结果后，WorkBuddy 中的记忆机制或自定义指令可以保存这些经验，下次再遇到同类文档时，触发规则、输出格式等信息会更明确。

8.2 与知识库和 MCP 的组合使用

从 WorkBuddy 热搜词可以看出，知识库和 MCP 是 WorkBuddy 的重要能力。在文档处理场景里，推荐这样组合：

1. 使用 xParse 解析 PDF 生成结构化 Markdown。
2. 将 Markdown 写入 WorkBuddy 知识库，作为 RAG 检索源。
3. 通过 MCP 连接企业内部数据库，把解析结果写入业务表。
4. 由 WorkBuddy 的模型统一编排，形成“解析—入库—检索—问答”闭环。

例如：

把刚刚解析的 20 张发票写入 invoice 数据库表，并把附件原文件传到知识库“财务-2024年发票”目录下。

这句指令同时触发了 xParse 解析、MCP 数据库写入、知识库存储三个动作。这在传统的 API 工具链里，通常需要三个不同系统的开发协作。

8.3 什么时候应该退回直接调用 API

WorkBuddy 加 xParse Skill 的组合虽然方便，但也有一些场景不适合：

• 每日处理上万份文档的重度场景。Skill 编排会带来额外调度开销，直接调用 API 更高效。
• 需要深度定制解析策略的场景，比如特定票据的专用识别模型。
• 对数据链路有严格审计要求的企业，可能需要完整的 API 日志体系。

判断标准很简单：当工作流的复杂度和稳定性要求超过 Agent 编排层的承载力时，回到 API 模式。

8.4 安全与权限实践

• 最小化权限：给 WorkBuddy 配置数据库权限时，只授予其需要的表的读写权限，不要使用管理员账号。
• 密钥管理：xParse API Key 不要明文写在群聊或文档里，尽量使用平台的密钥管理功能。
• 数据隔离：涉及客户敏感信息的文档，优先选择本地安装版或私有化部署，不要用公共网页版。
• 备份意识：无论是导入知识库还是写入数据库，执行前先备份原始 PDF 和解析结果，便于回滚。

9. 总结与后续学习方向

TextIn xParse 上架 WorkBuddy，本质上是把“专业文档解析能力”从 API 工具升级成了 Agent 生态中的可编排 Skill。对使用者来说，最大的变化是：从“我需要写代码调用解析接口”到“我只需要描述我要处理的文档和目标结果”。

这篇文章讲清楚了四件事：xParse 和 WorkBuddy 各自解决什么问题；Skill 模式相比传统 API 调用的差异；在 WorkBuddy 中接入 xParse Skill 并完成一句话文档处理全流程的方法；以及在实际工程中如何取舍、排错和保障安全。

如果你现在正在做 RAG 知识库项目，下一步可以试试把 xParse 解析后的 Markdown 作为知识库的导入格式，对比一下和之前用普通文本抽取插件的检索效果差异。如果你正在用 WorkBuddy 做个人工作台，可以先从发票、合同、简历这几个高频场景入手，写一个自定义 Skill 指令跑一个完整流程，感受一下“定义触发词—配置输出格式—挂入知识库”的这套工作方式。

也建议关注合合信息 TextIn 开放平台和 WorkBuddy 官方的后续更新——Skill 市场类的能力分发机制还在快速迭代，未来可能会看到更多专业能力以这种低门槛方式接入 Agent 工作流。对技术团队来说，提前掌握这种“能力编排”的思路，比死磕某一个具体接口更有长期价值。