01引言最怕的不是没写完而是被问“依据在哪”做项目汇报时我遇到过一种很熟悉的场面。PPT 上的结论写得很完整图表也放上去了。老师突然问一句“这个判断是从哪份材料里得出来的”然后就开始翻文件。先翻 PDF再找聊天记录最后发现那句话可能来自一张截图。材料其实有只是已经说不清它究竟在哪一页、哪一段也不知道后来有没有被另一份文件推翻。我就在想AI 已经很会总结文档了能不能别只给我一段“看起来很对”的回答而是顺手把证据也整理出来于是有了真源 ProofMate。一句大白话介绍它你把答辩、申报或项目材料交给它它会帮你找出哪些结论有证据哪些互相冲突哪些还得继续补材料。02相关技术栈这个项目用到的东西不算少但它们并不是简单堆在一起。每一项技术都对应材料审查流程中的一个具体环节。TextIn xParse先让扫描材料真正“可读”你可以使用下边这个链接去注册(可以额外获得免费额度)https://www.textin.com/market/detail/xparse?from5l21wcsktgxParse 不是后期附加的 OCR 按钮而是 ProofMate 证据链的起点。当用户上传图片或没有文本层的扫描 PDF 时xParse 会把页面解析成可搜索、可引用的 Markdown并提供 JSON 结构化结果。相比只返回一段纯文本它能够尽量保留双栏阅读顺序、标题、列表、表格与页内元素为后面的主张提取和证据定位提供更可靠的输入。ProofMate 还会保留原文件、原始解析内容和提取方式。模型引用某句话时用户可以回到对应扫描页核对不需要把 OCR 输出直接当成最终事实。WorkBuddy把开发、调用和验证留在同一条线上WorkBuddy 贯穿了需求拆解、现有代码阅读、xparse-parseSkill 加载、真实材料解析、接口检查以及测试构建。开发过程中发现的 OCR 清洗、重复主张和原文件预览问题也是在同一段项目上下文中继续追踪和修正的。它在这里并不是项目运行时依赖而是开发 ProofMate 的工作台。它帮助我把“接入了 xParse”继续追问到“解析结果有没有进入主张提取、证据关系和人工确认”。OpenVINO Qwen3-4B INT4在本机完成第一遍筛查本地模型负责从材料中定位候选主张、风险提示和补证方向。它的价值不是替用户直接下结论而是在材料离开电脑之前先完成一轮隐私优先的初审减少不必要的云端传输。INT4 量化让模型能够在普通个人电脑上运行。即使没有独立服务器用户也可以先对答辩材料、内部报告或尚未公开的项目文件做基础检查。百炼 Qwen只复核仍未解决的问题云端模型负责处理本地初审之后仍然模糊、冲突或缺证的主张。它不会重新生成一份彼此割裂的报告而是沿用已有档案对主张进行新增、更新、合并或解决。这样设计以后云端能力更像第二位复核者它补充本地模型没有处理好的部分但不能绕过原文证据和人工确认。简单来说xParse 负责“把材料读出来”两个模型负责“帮我找问题”ProofMate 负责“把问题和原文重新连起来”。03先把一份真实材料丢进去ProofMate 的入口不是聊天框而是文件。我可以上传 PDF、图片、扫描件或项目文档。文件读完以后系统会先从正文里找出值得核验的主张比如“低温环境已经完成验证”“数据覆盖完整”“当前方案没有明显风险”。这些句子单独看都很像结论但它们不一定有材料支撑。所以接下来不是让模型继续往下写而是逐条去找原文有没有说过其他材料有没有相反信息时间、数据和来源是否齐全点开一条主张后可以看到它关联了哪份文件、引用了哪段原文、是通过什么方式提取的以及为什么被判断为“支持”“冲突”或“待补证”。这一步看起来有点较真但很有用。因为 AI 给出的判断只是线索不应该直接变成事实。只有回到原文件核对过这条关系才会进入档案。04图片里的字交给 xParse普通文本型 PDF 可以直接读取没有必要再做一遍 OCR。真正麻烦的是手机拍照、扫描 PDF 和复杂图表人能看见程序却不一定找得到里面的句子。这部分我交给了 TextIn xParse。为了测试它我没有只用排版规整的中文材料而是找了 NASA 挑战者号事故调查资料中的 O 形环风险图表。测试 PDF 的第二页有双栏、项目符号、英文术语、多个时间区间还有扫描噪声。这一页的提取结果让我比较惊喜。O-RING、temperature、secondary seal这些关键词识别出来了0-170 ms、170-330 ms、330-600 ms三段次级密封时间窗口也没有被打乱。原图里“温度低于现有数据库范围”“初级 O 形环密封动作时间发生变化”这些信息提取之后仍然能够顺着读下来。更重要的是它不只是给出一坨纯文本。Markdown 保留了大致的阅读顺序和列表层级JSON 则可以继续检查页码、元素类型和表格结构。ProofMate 把提取文字与浏览器原文件放在一起我可以一边看 OCR 结果一边对照第二页原图。WorkBuddy开发过程开发验证时我保留了两次真实调用的 Markdown、JSON、输入输出路径、耗时和文件哈希。两次完整调用分别用了 3813 ms 和 4230 ms。当然OCR 不是魔法。扫描噪声仍然会带来拼写错误所以系统不会偷偷把它“润色”成正确事实。原始提取结果一直保留用户可以对照原图校正。05本地先看云端再补材料读出来以后完整版会先让本地的 OpenVINO Qwen3-4B INT4 跑一遍。这一步更像初筛先在电脑上找出候选主张、风险和补证方向。项目材料如果比较敏感不必为了第一轮筛查就全部交给云端。如果还有问题没有解决再调用百炼 Qwen 复核。本轮新增了什么、更新了什么、合并了什么、还剩多少条系统都会单独记录。第二次复核不会把同一条问题换个说法后再塞进档案。公开体验版没有携带本地模型权重所以省去了 OpenVINO 推理但文件上传、云端分析、证据关系和人工确认都还在。完整版和公开版的区别主要就是有没有本地初审这一层。在线体验https://lucianaib2004.github.io/proofmate/项目源码https://github.com/LucianaiB2004/proofmate06加入档案不应该等于“到此为止”早期版本里我把分析结果加入档案以后流程其实就断了。页面会告诉我“缺少证据”但后面没有继续操作的入口。这个体验很奇怪像医生说完“这里有问题”然后转身走了。后来我把后半段补了起来缺证据时给出建议材料用户补充文件后重新建立关联找到原文后可以确认、纠正或撤销云端再次复核时只处理仍未解决的部分最后把来源、摘录、提取方式和人工状态一起归档。页面顶部的“证据健康度”也不是在猜结论有多大概率为真。它看的其实是材料覆盖、相互一致、时间信息和人工复核进度。没有原文、不能回查、没有确认过的模型提示不会被算成已经证实。07开发过程中确实踩了几个坑第一个坑出现在 OCR 结果里。早期代码直接切分 Markdown标题符号和 HTML 表格标签也被当成了主张。索引卡里一度出现过td还有一条“主张”只写着## 待审查。模型当然可以继续分析但分析这种内容没有意义。后来我把正文清洗和语义分段放到主张提取之前展示给用户的是整理后的句子原始 OCR 文本仍保留用于回查。第二个坑是重复复核。第一次发现六条问题第二次云端复核如果又生成五段相似描述档案很快就会越来越乱。现在系统会根据来源、正文和关系做合并只更新真正发生变化的内容。第三个坑是原文件预览。只显示 OCR 文本时用户没法确认它到底读对没有只显示 PDF 又不方便检索。最后采用左右对照中间看提取结果右侧直接翻原文件。这些问题都不是什么“宏大创新”但它们决定了产品能不能真的用。开发过程很简单只需要快速在 WorkBuddy 一键接入TextIn xParse然后直接对它提出需求即可。打开 WorkBuddy进入「专家 · 技能 · 连接器」页面于连接器列表中选择「TextIn xParse 智能文档解析」进入连接器并绑定 TextIn 账号https://www.textin.com/console/dashboard/setting你可以使用下边这个链接去注册(可以额外获得免费额度)https://www.textin.com/market/detail/xparse?from5l21wcsktg返回对话框开启该连接器即可使用。后续过程中也会需要到x-ti-app-id和x-ti-secret-code。验证标准于对话框上传 PDF 或图片由 xParse 解析为结构化内容返回正常结果即视为接入成功。08WorkBuddy 在这个项目里做了什么这个项目从需求拆解到开发验证主要都在 WorkBuddy 里完成。我先给出产品目标、技术路线、真实测试材料和验收条件。WorkBuddy 阅读现有工程后加载项目里的xparse-parseSkill继续检查文件上传、xParse 调用、OCR 展示、主张提取和证据入档是不是一条真链路。最开始的提示词也很简单开发一个项目 一、项目目标 项目名称真源 ProofMate 文档证据审查台。 产品目标用户上传 PDF、图片、扫描材料或项目文档后系统把材料整理为可回查的主张—证据档案指出 哪些结论已经有原文证据支持 哪些结论与材料存在冲突 哪些结论仍然缺少证据 每条判断引用了哪份材料、哪段原文 用户下一步需要补充什么材料。 系统不能把模型生成内容直接当成事实。每条证据必须保留来源、原文摘录、提取方式和人工确认状态。 二、现有技术路线 请先阅读项目 README、package.json 和相关源代码确认实际实现不要臆造文件或接口。 现有技术组件 TextIn xParse解析图片和扫描 PDF输出可搜索、可引用的 Markdown/JSON PDF.js读取带有文本层的普通 PDF OpenVINO Qwen3-4B INT4在本地完成隐私优先的材料初审 百炼 Qwen按需复核尚未解决的主张 React TypeScript Vite产品界面 ProofMate 证据管线负责正文清洗、主张提取、证据关联、冲突识别、评分和人工入档。 凭证必须通过以下环境变量或本机设置读取不要要求我在对话中粘贴密钥也不要输出密钥内容 XPARSE_APP_ID XPARSE_SECRET_CODE DASHSCOPE_API_KEY QWEN_MODEL 三、本次必须完成的真实工作 找到并阅读项目级 xparse-parse Skill。 检查以下实际代码路径及其职责 server/xparseClient.ts server/providerSettings.ts vite.config.ts src/features/onboarding/extractFileText.ts src/features/onboarding/buildImportedAudit.ts src/features/audit/SourceMaterialPanel.tsx 使用 WorkBuddy 中的 xparse-parse Skill 或对应 TextIn xParse Connector真实解析 ProofMate-真实案例-挑战者号/03-NASA-O形环风险图表.jpg 使用 WorkBuddy profile 和自动 API 路由。不得模拟返回值不得使用手写结果代替调用。 把真实解析结果保存到 submission-textin/evidence/workbuddy-development/xparse-output/ 至少保留 Markdown 解析结果 JSON 结构化结果 实际命令或调用方式 成功/失败状态 实际耗时 输入输出文件路径 输入输出 SHA-256。 检查解析结果中是否实际出现以下内容并引用真实输出 O-RING temperature secondary seal 低温对 O 形环密封时间的影响 次级密封能力随时间窗口下降的描述。 基于现有实现完成一次开发审查检查 图片和扫描 PDF 是否真正进入 xParse 普通文本型 PDF 是否避免无意义 OCR OCR 结果是否会展示给用户 OCR 结果是否进入主张与证据核验 OCR 误识别是否保留人工校正入口 API Key 是否只保存在本机 页面是否会把 OCR 结果误写成最终事实 失败状态、超时状态和空结果是否有清晰提示。 如果发现明确且低风险的问题请直接在现有架构内修复并补充相应测试不要进行无关重构。修改前先说明原因修改后运行针对性测试和构建。若没有必要修改代码也要明确说明“不修改”的证据。 生成以下真实开发产物 submission-textin/evidence/workbuddy-development/01-项目需求与技术方案.md 内容包括产品目标、用户流程、技术架构、xParse 的职责边界、OpenVINO 与 Qwen 的协同方式、凭证管理和错误处理。 submission-textin/evidence/workbuddy-development/02-xParse真实调用记录.md 内容包括 Skill/Connector 名称、实际调用方式、执行时间、耗时、状态、文件路径、哈希和真实解析摘要。 submission-textin/evidence/workbuddy-development/03-开发检查与验证报告.md 内容包括代码检查结果、发现的问题、实际修改、测试结果、构建结果和剩余限制。 submission-textin/evidence/workbuddy-development/04-参赛项目说明.md 四、过程展示要求 请在 WorkBuddy 界面中保留清晰的任务列表并依次显示 阅读 ProofMate 现有项目 加载 xparse-parse Skill 审查 xParse 接入代码 真实解析 NASA O 形环图表 检查 Markdown/JSON 输出 完成项目开发审查或必要修复 运行测试与生产构建 生成项目技术方案和调用记录。 执行过程中不要隐藏真实错误不要把未执行的命令写成已成功不要展示任何 API Key、Secret Code 或完整账号凭证。 五、最终汇报 完成后请在 WorkBuddy 的最终结果中明确展示 使用的 Skill 或 Connector xParse 调用成功状态与真实耗时 生成的 Markdown、JSON 和开发文档 实际识别出的 O-RING、temperature、secondary seal 信息 xParse 在 ProofMate 中承担的具体作用 实际修改的文件 测试和构建结果 所有产物的相对路径。 最后停留在包含“任务完成总结、真实调用结果、产物列表和项目文档预览”的界面不要自动关闭任务。它比较好用的一点是上下文没有断。前面讨论的是“为什么要做证据审查”后面可以继续追到具体文件、接口返回、测试结果和构建产物而不是写完一个页面就结束。真实解析 NASA 图表时它也不只是告诉我“调用成功”而是把 Markdown、JSON、耗时、路径和哈希一起留下来。后续检查代码时可以直接拿这些结果验证 OCR 有没有进入主张与证据流程。它也不是完全不需要人管。任务一长如果只说一句“帮我接一下 OCR”很容易得到一个表面能跑的结果。文件路径、真实调用要求、失败状态和验收条件必须提前写清楚。对我来说WorkBuddy 更像一个能持续跟进项目的开发搭档而不是按一下就自动交付成品的按钮。9总结做完这一版以后我对 AI 文档工具的想法变了一点。以前总觉得回答写得越完整越好。真正把材料拿来审查时才发现更重要的是它愿不愿意停下来告诉我这句话有出处那句话和另一份材料冲突还有一句暂时什么都证明不了。ProofMate 做的事情并不复杂。它只是尽量把每一个结论重新带回它的证据。这也是“真源”这个名字的来历。