01｜引言：最怕的不是没写完，而是被问"依据在哪"
做项目汇报时，我遇到过一种很熟悉的场面。
PPT 上的结论写得很完整，图表也放上去了。老师突然问一句："这个判断是从哪份材料里得出来的？"
然后就开始翻文件。
先翻 PDF，再找聊天记录，最后发现那句话可能来自一张截图。材料其实有，只是已经说不清它究竟在哪一页、哪一段，也不知道后来有没有被另一份文件推翻。
我就在想，AI 已经很会总结文档了，能不能别只给我一段"看起来很对"的回答，而是顺手把证据也整理出来？
于是有了真源 ProofMate。
一句大白话介绍它：你把答辩、申报或项目材料交给它，它会帮你找出哪些结论有证据，哪些互相冲突，哪些还得继续补材料。
02｜相关技术栈
这个项目用到的东西不算少，但它们并不是简单堆在一起。每一项技术都对应材料审查流程中的一个具体环节。
TextIn xParse：先让扫描材料真正"可读"
你可以使用下边这个链接去注册(可以额外获得免费额度)：www.textin.com/market/deta...
xParse 不是后期附加的 OCR 按钮，而是 ProofMate 证据链的起点。
当用户上传图片或没有文本层的扫描 PDF 时，xParse 会把页面解析成可搜索、可引用的 Markdown，并提供 JSON 结构化结果。相比只返回一段纯文本，它能够尽量保留双栏阅读顺序、标题、列表、表格与页内元素，为后面的主张提取和证据定位提供更可靠的输入。
ProofMate 还会保留原文件、原始解析内容和提取方式。模型引用某句话时，用户可以回到对应扫描页核对，不需要把 OCR 输出直接当成最终事实。
WorkBuddy：把开发、调用和验证留在同一条线上
WorkBuddy 贯穿了需求拆解、现有代码阅读、xparse-parse Skill 加载、真实材料解析、接口检查以及测试构建。开发过程中发现的 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 推理，但文件上传、云端分析、证据关系和人工确认都还在。完整版和公开版的区别，主要就是有没有本地初审这一层。
在线体验：lucianaib2004.github.io/proofmate/
项目源码：github.com/LucianaiB20...
06｜加入档案，不应该等于"到此为止"
早期版本里，我把分析结果加入档案以后，流程其实就断了。
页面会告诉我"缺少证据"，但后面没有继续操作的入口。这个体验很奇怪，像医生说完"这里有问题"，然后转身走了。
后来我把后半段补了起来：缺证据时给出建议材料，用户补充文件后重新建立关联；找到原文后，可以确认、纠正或撤销；云端再次复核时，只处理仍未解决的部分；最后把来源、摘录、提取方式和人工状态一起归档。
页面顶部的"证据健康度"也不是在猜结论有多大概率为真。它看的其实是材料覆盖、相互一致、时间信息和人工复核进度。没有原文、不能回查、没有确认过的模型提示，不会被算成已经证实。
07｜开发过程中，确实踩了几个坑
第一个坑出现在 OCR 结果里。
早期代码直接切分 Markdown，标题符号和 HTML 表格标签也被当成了主张。索引卡里一度出现过 <td>，还有一条"主张"只写着 ## 待审查。模型当然可以继续分析，但分析这种内容没有意义。
后来我把正文清洗和语义分段放到主张提取之前：展示给用户的是整理后的句子，原始 OCR 文本仍保留用于回查。
第二个坑是重复复核。第一次发现六条问题，第二次云端复核如果又生成五段相似描述，档案很快就会越来越乱。现在系统会根据来源、正文和关系做合并，只更新真正发生变化的内容。
第三个坑是原文件预览。只显示 OCR 文本时，用户没法确认它到底读对没有；只显示 PDF 又不方便检索。最后采用左右对照：中间看提取结果，右侧直接翻原文件。
这些问题都不是什么"宏大创新"，但它们决定了产品能不能真的用。
开发过程很简单，只需要快速在 WorkBuddy 一键接入TextIn xParse，然后直接对它提出需求即可。
- 打开 WorkBuddy，进入「专家 · 技能 · 连接器」页面；
- 于连接器列表中选择「TextIn xParse 智能文档解析」；
- 进入连接器并绑定 TextIn 账号：www.textin.com/console/das...；
你可以使用下边这个链接去注册(可以额外获得免费额度)：www.textin.com/market/deta...
- 返回对话框，开启该连接器即可使用。
后续过程中也会需要到x-ti-app-id和x-ti-secret-code。
验证标准：于对话框上传 PDF 或图片，由 xParse 解析为结构化内容；返回正常结果即视为接入成功。
08｜WorkBuddy 在这个项目里做了什么
这个项目从需求拆解到开发验证，主要都在 WorkBuddy 里完成。
我先给出产品目标、技术路线、真实测试材料和验收条件。WorkBuddy 阅读现有工程后，加载项目里的 xparse-parse Skill，继续检查文件上传、xParse 调用、OCR 展示、主张提取和证据入档是不是一条真链路。
最开始的提示词也很简单：
Bash
开发一个项目
一、项目目标
项目名称：真源 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 做的事情并不复杂。它只是尽量把每一个结论，重新带回它的证据。
这也是"真源"这个名字的来历。