做项目汇报时，我遇到过一种很熟悉的场面。
PPT 上的结论写得挺完整。
图表也放上去了。
老师突然问一句：“这个判断是从哪份材料里得出来的。”
然后就开始翻文件。
先翻 PDF，再找聊天记录，最后发现那句话可能来自一张截图。
翻不到。
材料其实有。
只是说不清它在哪一页、哪一段。
也不知道后来有没有被另一份文件推翻。
我就在想，AI工具已经很会总结文档了。
能不能别只给一段“看起来很对”的回答。
顺手把证据也整理出来。
于是有了一套叫真源 ProofMate 的东西。
一句大白话介绍它。
你把答辩、申报或项目材料交给它。
它帮你找出哪些结论有证据，哪些互相冲突，哪些还得继续补材料。
它的入口不是 AI对话 的聊天框，是文件。
上传之后，文本类的材料在浏览器里直接读，图片和扫描件才交给文字识别。
密钥只留在当前页面的内存里，不上传。
这点让人安心。
先把材料读出来
普通文本型的 PDF，直接读就行，没必要再做一遍文字识别。
省一遍功夫。
麻烦的是手机拍照、扫描件和复杂图表。
人能看见，程序却不一定找得到里面的句子。
这部分交给了 TextIn xParse。
它不是后期附加的一个识别按钮，而是整条证据链的起点。
扫描件进到它手里，会被解析成可搜索、可引用的文本。
还会额外给一份带结构的结果。
双栏的阅读顺序、标题和列表都尽量保留。
表格与页内元素也有交代。
为了测试，我没有只用排版规整的中文材料。
我挑了个麻烦的。
我找的是 NASA 挑战者号事故的调查资料。
其中一张是关于 O 形环风险的图表。
第二页有双栏、项目符号，还有英文术语和扫描噪声。
这一页的提取结果让我有点惊喜。
出乎意料。
O-RING、temperature 这些关键词都识别出来了。
secondary seal 也没漏，三段密封时间窗口同样没被打乱。
没乱。
原图里“温度低于现有数据库范围”这句，提取之后仍然顺得下来。
“初级 O 形环密封动作时间发生变化”也一样。
当然，文字识别不是魔法。
扫描噪声还是会带来拼写错误。
这点避不开。
所以系统不会偷偷把它“润色”成正确事实。原始提取结果一直保留，用户可以对着原图校正。
这点很关键。
开发这一整套的过程，主要在 WorkBuddy 里完成。
它贯穿了需求拆解、读现有代码，以及加载项目里的解析技能。
真实材料解析和接口检查也在同一条线上，测试构建也一样。
中途发现的识别清洗和重复主张问题，也在同一个项目上下文里继续追。
原文件预览的问题也一样。
它在这里不是项目运行时要依赖的东西，而是我做这个项目的工作台。
只是工作台。
本地先筛一遍，云端只补没解决的
材料读出来以后，完整版会先让本地的千问小模型跑一遍。
它负责在材料里找出候选主张、风险提示和补证方向。
价值不是替用户下结论。
而是在材料离开电脑之前，先做完一轮隐私优先的初审。
量化之后模型能塞进普通个人电脑，没有独立服务器也能跑。
门槛不高。
剩下那些仍然模糊或冲突的主张，再交给云端的千问。
云端不是重新生成一份彼此割裂的报告。
它沿用已有的档案，对主张做合并和更新。
这样它更像第二位复核者。
分工很清楚。
它补充本地没处理好的部分，但不能绕过原文证据和人工确认。
这条底线不能松。
一句话概括。
解析工具负责把材料读出来，两个模型负责找问题。
审查台负责把问题和原文重新连起来。
公开体验版没有带本地模型的权重，所以省掉了本地推理。
所以轻。
文件上传和云端分析都还在，证据关系与人工确认也在。
完整版和公开版的差别，主要就是有没有本地初审这一层。
差别就这一层。
材料丢进去之后
文件读完，系统先从正文里挑出值得核验的主张。
比如“低温环境已经完成验证”“数据覆盖完整”“当前方案没有明显风险”。
这些句子单独看都很像结论。
但说不准。
但它们不一定有材料支撑。
很可能没有。
所以接下来不是让模型继续往下写，而是逐条去找。
原文有没有说过，其他材料有没有相反信息。
时间、数据和来源齐不齐。
与其多生成一份漂亮的报告，不如先把每句话的出处找齐。
点开一条主张，能看到它关联了哪份文件、引用了哪段原文。
还能看到它是通过什么方式提取的。
以及为什么被判成“支持”“冲突”或“待补证”。
这一步看起来有点较真，但很有用。
确实较真。
但有用。
AI 给出的判断只是线索，不该直接变成事实。
宁可这一步慢一点，也别把模型的话当成已经证实的事实。
只有回到原文件核对过，这条关系才会进档案。
绕不过去。
开发验证时我保留了两次真实调用的记录。
带结构文本、耗时，还有输入输出路径和文件哈希。
两次完整调用分别用了 3813 毫秒和 4230 毫秒。
不慢。
早期版本有个很别扭的地方。
很别扭。
分析结果加进档案以后，流程其实就断了。
页面会告诉你“缺少证据”，但后面没有继续操作的入口。
路断了。
像医生说完“这里有问题”，然后转身走了。
后来我把后半段补了起来。
缺证据时给出建议材料，用户补充文件后重新建立关联。
找到原文后，可以确认、纠正或撤销。
云端再次复核时，只处理仍未解决的部分。
最后把来源、摘录，以及提取方式和人工状态一起归档。
一步不留空。
页面顶部的“证据健康度”也不是在猜结论有多大概率为真。
它看的其实是材料覆盖、相互一致，还有时间信息和人工复核进度。
都在算分。
没有原文、不能回查的模型提示，不会被算成已经证实。
开发时踩的几个坑
第一个坑出现在识别结果里。
早期代码直接切分带格式的文本，标题符号和表格标签也被当成了主张。
索引卡里一度出现过表格标签，还有一条“主张”只写着“待审查”。
模型当然能继续分析，但分析这种内容没有意义。
没意义。
后来我把正文清洗和语义分段放到了主张提取之前。
第二个坑是重复复核。
这个更常见。
第一次发现六条问题。
第二次云端复核又生成五段相似描述，档案很快就会越来越乱。
现在系统会根据来源、正文和关系做合并。
只更新真正发生变化的内容。
第三个坑是原文件预览。
这个最费劲。
只显示识别出来的文本时，用户没法确认它到底读对没有。
只显示原文件又不方便检索。
最后做成左右对照：中间看提取结果，右侧直接翻原始文件。
接入这一步其实不复杂。
打开 WorkBuddy，进到“专家 · 技能 · 连接器”页面。
在连接器列表里找到“TextIn xParse 智能文档解析”。
选中它，绑定 TextIn 账号，返回对话框把连接器打开就能用。
过程中还会用到一对账号密钥，建议只放在本机，不要贴进对话。
验证标准也简单。
一句话说清。
上传一份扫描件或图片，解析出结构化内容，返回正常就算接通。
够用了。
它也不是完全不需要人管。
任务一长，只说一句“帮我接一下识别”。
很容易得到一个表面能跑的结果。
文件路径、真实调用要求，还有失败状态和验收条件。
这些得提前写清楚。
对我来说，它更像一个能持续跟进项目的开发搭档。
而不是按一下就自动交付成品的按钮。
做完这一版，我对 AI 文档工具的想法变了一点。
以前总觉得回答写得越完整越好。
真正把材料拿来审查时才明白，更重要的是它愿不愿意停下来告诉你。
这句话有出处。
那句话和另一份材料冲突。
还有一句暂时什么都证明不了。
审查台做的事情并不复杂。
它只是尽量把每一个结论，重新带回它的证据。
这也是“真源”这个名字的来历。
