企业官网建设流程全解析

1. 答辩材料审阅这件事，为什么值得用 AI 重做一遍

每年到了答辩季，我身边总有一批人处于一种高度焦虑的状态。论文写完了，PPT 也做完了，但心里没底——评委老师会问什么？我的论证链条有没有漏洞？数据引用是否站得住脚？这种焦虑的本质，其实是信息不对称：你知道自己写了什么，但你不知道别人会怎么审视你写的东西。

传统的做法是找同门帮忙看一遍，或者自己反复读。但同门也有自己的事要忙，自己读自己的材料又容易陷入“知识诅咒”——你觉得理所当然的推导，别人可能完全接不上。我试过把答辩材料丢给通用大模型，让它帮我审一遍，结果它给了一堆“建议补充数据”“论证可以更充分”之类的废话，没有任何实质性的帮助。

后来我换了一个思路：不是让 AI 泛泛地“审”，而是让它像真正的评委一样，追着我要证据。这个思路的转变，涉及两个关键工具的组合使用——TextIn xParse 负责把答辩材料里的非结构化内容（PDF、扫描件、图片表格）解析成干净的结构化文本，Workbuddy 负责在这个基础上做智能审阅和追问。再配合 OpenVINO 加速的 Qwen 模型做本地推理，整个流程可以完全跑在自己的机器上，不用担心材料外泄。

这套方案适合什么人？如果你正在准备答辩、项目评审、课题结题，或者任何需要面对专家质询的场合，这套流程都能帮你提前把漏洞找出来。如果你对 OCR 识别、文档解析、本地大模型部署感兴趣，这里面的技术细节也足够你参考复现。下面我把整个实践过程拆开来讲，包括为什么这么选型、每一步怎么操作、踩过哪些坑。

2. 整体方案设计与工具选型逻辑

2.1 为什么不是“一个模型搞定所有事”

很多人第一反应是：直接把 PDF 丢给大模型不就行了？我一开始也是这么想的，但实测下来问题很多。答辩材料通常包含几种内容形态：正文文字、数据表格、流程图、公式、参考文献。通用大模型对纯文本的处理没问题，但一旦涉及扫描件里的表格、图片里的文字，它就抓瞎了——要么识别错误，要么直接忽略。

更关键的是，答辩材料往往有几十页甚至上百页，直接塞进模型的上下文窗口，要么超长被截断，要么模型“看了后面忘了前面”，追问的时候根本定位不到具体位置。所以我需要的不是一个大模型，而是一条流水线：先把文档解析干净，再让模型在干净的文本上做审阅和追问。

这就引出了 TextIn xParse 的价值。它是一个专门做文档解析的工具，能够把 PDF、图片、扫描件里的文字、表格、版面结构提取出来，输出成结构化的 Markdown 或 JSON。相比通用的 OCR 工具，它在版面分析和表格还原上做得更细，这对答辩材料这种格式复杂的文档来说非常关键。

2.2 TextIn xParse 在流程中的角色

TextIn xParse 的核心能力是文档结构化解析。我拿一份 60 页的答辩报告做测试，里面包含正文、三线表、流程图、公式和页脚注释。用普通 OCR 跑一遍，输出的是密密麻麻的纯文本，表格变成了乱序的文字堆砌，公式直接丢失。而 xParse 的输出保留了标题层级、表格结构、甚至图片的位置标记。

这个差异在后续的 AI 审阅环节会被放大。如果输入模型的文本是混乱的，模型给出的审阅意见也会是混乱的——它可能把表格里的数据当成正文来理解，得出完全错误的结论。所以我在流程设计上把 xParse 放在最前面，作为整个流水线的“入口清洗”环节。

具体操作上，xParse 支持批量上传和 API 调用两种方式。如果只是偶尔用，网页端上传就够了；如果要集成到自动化流程里，用 API 更合适。我自己的做法是先用网页端跑一遍，确认解析质量没问题，再把 API 接进 Workbuddy 的工作流里。

2.3 Workbuddy 的审阅逻辑与追问机制

Workbuddy 在这个方案里扮演的是“审阅者”角色。它不是简单地总结文档，而是按照我预设的审阅规则，逐段检查论证链条，发现薄弱环节就追问。比如我设定的一条规则是：“如果文中出现‘显著提升’‘明显优于’这类结论性表述，必须检查是否有对应的数据支撑和统计检验。”

这个追问机制是整套方案的核心价值。通用大模型也会给建议，但它的建议往往是泛泛的“建议补充数据”，而 Workbuddy 会具体到：“你在第 3 章第 2 节提到‘该方法显著优于基线’，但文中只给出了均值对比，没有报告标准差和显著性检验结果。请补充 t 检验或 Wilcoxon 检验的具体数值。”

这种追问的质量，取决于两个因素：一是输入文本的结构化程度（xParse 负责），二是审阅规则的设定精度（我来负责）。Workbuddy 支持自定义审阅模板，你可以把导师常问的问题、评委关注的要点、学科特有的论证规范都写进去，形成一套专属的审阅清单。

2.4 OpenVINO + Qwen 的本地推理方案

把答辩材料上传到云端 API 这件事，很多人是有顾虑的。未发表的研究数据、专利申请中的技术方案，一旦上传就存在泄露风险。所以我选择用 OpenVINO 在本地部署 Qwen 模型来做推理。

OpenVINO 是 Intel 推出的推理加速工具包，它能把模型优化后跑在 CPU 或集成显卡上，速度比原生 PyTorch 快不少。Qwen 系列模型在中文理解和长文本处理上表现不错，7B 参数的版本经过 INT4 量化后，普通笔记本的 16GB 内存就能跑起来。实测下来，用 OpenVINO 加速的 Qwen2.5-7B-Instruct，在处理 5000 字左右的文档段落时，响应速度可以接受，追问一轮大概 3 到 5 秒。

这个组合的好处是数据不出本地。xParse 的解析可以在本地完成（它支持离线部署），Workbuddy 调用本地的 Qwen 接口，整个流程闭环在自己的机器上。对于需要处理敏感材料的场景，这一点比什么都重要。

3. 核心细节解析与实操要点

3.1 答辩材料的预处理：哪些内容需要特别关注

不是所有答辩材料都适合直接丢给 AI 审阅。我在实操中发现，以下几类内容需要特别处理：

扫描件和图片型 PDF：这类文档必须经过 OCR 才能变成可编辑文本。TextIn xParse 对扫描件的识别率不错，但前提是扫描质量不能太差。如果原稿是手机拍照的，有阴影、倾斜、模糊，识别错误率会明显上升。我的做法是先用扫描软件做一遍预处理——纠偏、去阴影、二值化，再交给 xParse。

复杂表格：答辩材料里的三线表、合并单元格表格是解析难点。xParse 能还原大部分表格结构，但对于跨页表格和嵌套表头，偶尔会出现列对齐错误。我的经验是，解析完成后一定要人工抽查表格部分，发现错位就手动修正，不要指望 AI 一次搞定。

公式和特殊符号：数学公式、化学式、专业符号的识别是另一个坑。xParse 对 LaTeX 公式的还原还可以，但复杂的多行公式容易出错。如果答辩材料里公式很多，建议把公式部分单独截出来，用专门的公式识别工具处理，再合并回主文档。

页眉页脚和批注：这些内容在解析时容易被混入正文，干扰后续的 AI 审阅。xParse 支持区域排除，可以在解析前框选需要忽略的区域。如果用的是 API，可以在参数里设置忽略页眉页脚的阈值。

3.2 审阅规则的编写：让 AI 问出“像评委”的问题

Workbuddy 的审阅质量，八成取决于你给的规则。我一开始只写了一句“请审阅这份答辩材料”，结果它给了一堆不痛不痒的建议。后来我把规则细化成几个维度，效果立刻不一样了。

论证链条检查：要求 AI 逐段检查“论点—论据—论证”是否完整。具体规则可以写成：“如果某段提出了一个结论，但没有给出数据来源或推导过程，标记为‘论据缺失’。如果引用了文献但没有标注具体出处，标记为‘引用不完整’。”

数据一致性检查：答辩材料里经常出现同一数据在不同章节数值不一致的情况。我设定了一条规则：“交叉比对全文中的数值型数据，如果同一指标在不同位置出现不同数值，列出所有出现位置和数值。”这条规则帮我抓到了一个表格里百分比加总不等于 100% 的错误。

术语一致性检查：同一概念在全文中是否使用了统一的术语。比如“准确率”和“精确率”是否混用，“模型”和“算法”是否指代同一对象。这种问题评委不一定当场指出，但会留下“不严谨”的印象。

逻辑跳跃检查：从 A 直接跳到 C，中间缺少 B 的推导。规则可以写成：“如果相邻段落之间缺少过渡性论述，或者结论的出现缺乏前置铺垫，标记为‘逻辑跳跃’。”

我把这些规则整理成一个审阅模板，每次审阅新材料时直接调用。模板可以迭代——每次发现新的问题类型，就补充一条规则进去。用了几次之后，这个模板就变成了一个相当全面的“评委问题库”。

3.3 本地模型的参数调优：让 Qwen 更“较真”

Qwen 模型默认的输出风格偏温和，你让它审阅，它可能先说一堆优点再轻描淡写地提两个建议。但答辩场景需要的是“较真”的审阅者，所以我调整了几个关键参数。

温度参数：默认的 temperature 是 0.7，输出比较多样但不够聚焦。审阅任务我调到 0.3 左右，让模型更倾向于给出确定性的判断，减少模棱两可的表述。

系统提示词：这是最关键的一步。我在系统提示里明确写了：“你是一位严格的答辩评委，你的任务是找出材料中的每一个论证漏洞。不要赞美，不要总结，只指出问题并追问证据。如果某个结论缺乏数据支撑，直接要求补充具体数值和检验方法。”

最大生成长度：审阅任务需要模型输出较长的分析，默认的 512 token 不够用。我调到 2048，确保它能完整地列出所有发现的问题。

重复惩罚：适当提高 repetition_penalty，避免模型反复说同一句话。实测 1.1 到 1.2 之间比较合适。

这些参数在 OpenVINO 的推理配置里都可以调整。如果你用的是 Hugging Face 的 transformers 库加载模型，对应的参数名是 temperature、max_new_tokens、repetition_penalty。

3.4 追问环节的设计：从“一次性审阅”到“多轮对话”

单次审阅只能发现表面问题，真正有价值的是多轮追问。我的做法是：第一轮让 AI 通读全文，列出所有可疑点；第二轮针对每个可疑点，让 AI 扮演“质疑者”角色，提出具体的追问；第三轮我手动回复这些追问（相当于模拟答辩现场），让 AI 判断我的回复是否充分。

这个多轮机制模拟了真实答辩的节奏。评委不会只问一个问题，他们会根据你的回答继续追问。提前演练这种“追问—回答—再追问”的循环，能大幅降低现场卡壳的概率。

Workbuddy 支持会话历史管理，每一轮的问答都会保留上下文。我在配置里设置了最大历史轮数为 10 轮，超过之后自动摘要前面的内容，避免上下文溢出。

4. 完整实操流程与关键环节实现

4.1 环境准备：从零搭建本地审阅流水线

先列一下我用的软硬件环境，方便你对照参考：

安装步骤大致如下。首先装 OpenVINO 的 Python 包：

pip install openvino openvino-genai

然后下载 Qwen 模型的 OpenVINO 优化版本。这里注意，要用 OpenVINO 转换后的模型格式，而不是原始的 Hugging Face 格式。转换命令：

optimum-cli export openvino --model Qwen/Qwen2.5-7B-Instruct --weight-format int4 qwen2.5-7b-ov

这个转换过程大概需要 10 到 15 分钟，取决于机器性能。转换完成后，用 OpenVINO GenAI 加载模型：

import openvino_genai pipe = openvino_genai.LLMPipeline("qwen2.5-7b-ov", "CPU")

Workbuddy 这边，在设置里把模型接口指向本地的 OpenVINO 服务。如果你不想写代码，Workbuddy 支持直接配置本地模型路径，它会自动调用 OpenVINO 的推理接口。

4.2 文档解析：把答辩材料变成 AI 能读懂的格式

我拿一份真实的硕士答辩报告做演示，文件是 58 页的 PDF，包含 12 个表格、8 张流程图、若干公式。第一步是上传到 TextIn xParse 的网页端。

上传后，xParse 会自动分析版面结构。这里有几个选项需要注意：

• 输出格式：选 Markdown，因为后续要喂给大模型，Markdown 的标题层级和表格结构保留得最好。
• 表格识别：开启“精确模式”，虽然慢一点，但表格还原度高很多。
• 公式识别：如果材料里公式多，开启 LaTeX 输出。
• 页眉页脚过滤：开启，避免页码和章节名混入正文。

解析完成后，下载 Markdown 文件。我抽查了几个关键位置：第 3 章的实验数据表格还原正确，第 5 章的流程图被转成了文字描述（图片本身无法转文字，但图注被保留了），公式部分基本正确，个别复杂公式有轻微偏差。

注意：解析完成后一定要人工抽查。我遇到过表格列对齐错误的情况，如果不检查直接喂给 AI，后续的审阅意见会完全跑偏。

4.3 审阅规则配置：在 Workbuddy 里搭建审阅工作流

Workbuddy 的工作流配置界面比较直观，我按以下步骤搭建：

第一步，创建新的工作流，命名为“答辩材料审阅”。第二步，添加“文档输入”节点，把 xParse 输出的 Markdown 文件导入。第三步，添加“文本分块”节点，因为 58 页的文档太长，需要切成适合模型处理的段落。我设置的分块大小是 2000 字，重叠 200 字，避免切断上下文。

第四步，添加“LLM 审阅”节点，配置本地 Qwen 模型。系统提示词我写了这么一段：

你是一位严格的答辩评委，正在审阅一份学术答辩材料。 你的任务是找出论证链条中的每一个薄弱环节。 对于每个发现的问题，你需要： 1. 指出具体位置（章节和段落） 2. 说明问题类型（论据缺失/数据不一致/逻辑跳跃/引用不完整） 3. 提出具体的追问，要求补充什么证据 不要给出赞美性评价，不要总结全文，只输出问题清单。

第五步，添加“追问生成”节点，让模型针对每个问题生成 2 到 3 个追问。第六步，添加“输出”节点，把结果导出为 Markdown 报告。

整个工作流跑一遍大概需要 8 到 12 分钟，取决于文档长度和模型速度。我一般晚上跑，第二天早上看结果。

4.4 多轮追问实录：AI 到底问了什么

第一次跑完，AI 输出了问题清单，一共 23 条。我挑几条有代表性的给你看看：

问题 1：第 3 章第 2 节提到“该方法在准确率上显著优于基线”，但表 3-2 只给出了均值，没有标准差和显著性检验结果。追问：请补充 t 检验的 p 值和效应量，或者说明为什么不做显著性检验。

问题 2：第 4 章第 1 节的样本量描述为“共收集有效问卷 312 份”，但第 4 章第 3 节的回归分析中报告的自由度为 308。追问：样本量从 312 变为 308 的原因是什么？是否有缺失值处理？缺失机制是什么？

问题 3：第 2 章文献综述引用了“Zhang et al. (2021)”的研究结论，但参考文献列表中该条目的期刊名称与正文中提到的会议名称不一致。追问：请核实该文献的准确出处。

问题 4：第 5 章结论部分提出“该方法可推广至其他领域”，但全文仅在单一数据集上进行了验证。追问：推广性的依据是什么？是否有跨领域实验或理论论证？

这些问题质量相当高，有些是我自己都没注意到的细节。比如样本量不一致的问题，我回去查了原始数据，发现确实有 4 份问卷因为关键变量缺失被剔除了，但正文里没有说明。这种细节在答辩现场被问到的概率很大。

4.5 模拟答辩：用 AI 做压力测试

问题清单整理完之后，我进入第二轮：模拟答辩。我把每个问题当作评委的现场提问，口头回答一遍，然后把回答内容输入 Workbuddy，让 AI 判断我的回答是否充分。

这个环节的提示词我改成了：

你是一位答辩评委，刚才提出了一个问题，学生给出了回答。 请判断这个回答是否充分回应了你的质疑。 如果回答中仍然缺少关键证据，请继续追问。 如果回答充分，请给出“通过”并简要说明理由。

实测下来，AI 的“追问”相当犀利。有一个问题是关于实验可重复性的，我回答说“代码已开源”，AI 追问：“开源代码的版本号是多少？是否包含随机种子设置？运行环境是否固定？”这些问题如果现场被问到，没有准备的话很容易卡住。

我把所有追问和我的回答整理成一份“答辩预演文档”，答辩前一天晚上过了一遍。第二天现场，评委问的 5 个问题里有 3 个是我预演过的，回答起来从容很多。

5. 常见问题与排查技巧实录

5.1 OCR 识别质量差怎么办

这是最常见的问题。TextIn xParse 的识别率虽然不错，但遇到低质量扫描件还是会出错。我的排查顺序是：

先看原稿质量。如果原稿本身模糊、倾斜、有阴影，任何 OCR 工具都救不了。用扫描软件做预处理——我常用的是扫描全能王或 Adobe Scan，自动纠偏和去阴影效果不错。

再看解析参数。xParse 的“精确模式”比“快速模式”识别率高，但速度慢一倍。如果材料页数不多，建议用精确模式。表格识别选项也要打开，否则表格会被当成普通文本处理。

最后做人工校对。我一般重点校对三类内容：数字、专业术语、表格数据。数字识别错误最危险，因为 AI 审阅时会基于错误数字做判断。专业术语错误会影响语义理解。表格数据错位会导致后续分析完全错误。

如果韩文、日文等非中英文内容识别不了，需要确认 xParse 的语言包是否覆盖。目前 xParse 对中英文支持最好，其他语言的支持程度不一。遇到小语种材料，可能需要换用专门的 OCR 工具。

5.2 本地模型推理速度慢的优化思路

Qwen2.5-7B 在 CPU 上跑，速度确实不如云端 API。我的优化经验有这么几条：

用量化版本：INT4 量化比 FP16 快 2 到 3 倍，精度损失在可接受范围内。如果机器内存够，用 INT8 也可以，速度介于两者之间。

开 OpenVINO 的异步推理：OpenVINO 支持异步执行，可以在等待模型输出的同时处理其他任务。在代码里设置pipe.start_async()而不是同步调用，整体吞吐量能提升不少。

限制上下文长度：答辩材料分块后，每块控制在 2000 字以内。上下文越长，推理越慢。如果发现某一块特别慢，检查是不是分块没切好，导致单块过长。

用集成显卡加速：如果 CPU 带集成显卡（Intel Iris Xe 以上），OpenVINO 可以调用 GPU 做推理，速度比纯 CPU 快 30% 到 50%。在配置里把设备设为 “GPU” 即可。

批量处理：如果有多份材料要审，不要一份一份跑，攒在一起批量处理。OpenVINO 支持批推理，吞吐量比单条推理高很多。

5.3 AI 审阅意见“太泛”怎么调

如果 AI 给出的意见都是“建议补充数据”“论证可以更充分”这类空话，说明审阅规则不够具体。我的调整方法是：

把规则从“检查论证是否充分”改成“如果某段提出了结论但没有给出数据来源，标记为论据缺失”。规则越具体，AI 的输出越有针对性。

另外，在系统提示词里明确禁止泛泛而谈。我加了一句：“不要输出‘建议补充数据’这类没有具体指向的建议。每条意见必须包含具体位置、问题类型和追问内容。”这条规则加上之后，输出质量明显提升。

还有一个技巧是给 AI 提供示例。在提示词里放一两个“好问题”的样例，让模型模仿这个风格。比如：“示例：第 3 章表 3-2 报告了均值但未报告标准差，请补充标准差和显著性检验结果。”模型看到示例后，输出的问题会具体很多。

5.4 多轮对话上下文溢出的处理

Qwen2.5-7B 的上下文窗口是 32K token，听起来很大，但多轮对话加上文档内容，很容易撑满。我的处理策略是：

第一，文档内容不要全部塞进对话历史。每次追问时，只把相关的段落摘出来放进上下文，而不是把整份文档反复传入。

第二，设置历史摘要。Workbuddy 支持自动摘要历史对话，超过一定轮数后，把前面的问答压缩成摘要，保留关键信息即可。

第三，分章节审阅。不要一次性审全文，按章节分批处理。每章审完输出报告，最后合并。这样每次对话的上下文压力小很多。

第四，如果还是溢出，降低分块大小。把 2000 字的分块改成 1000 字，虽然处理次数增加，但每次的上下文压力减小。

5.5 常见问题速查表

6. 几个容易被忽略的实操心得

6.1 审阅规则要“养”，不是一次写完

我一开始写的审阅规则只有三条，跑了几次之后发现 AI 漏掉了很多问题类型。后来每次答辩预演发现新问题，我就往规则里补一条。现在我的规则库有二十多条，覆盖了论证、数据、引用、术语、逻辑、格式六个维度。

这个“养规则”的过程本身就是一种学习。每次补充规则，都是在提醒自己：这个坑我踩过，下次要注意。规则库越丰富，AI 的审阅越像一位经验丰富的评委。

6.2 不要完全依赖 AI 的判断

AI 审阅是辅助，不是替代。它擅长发现形式上的问题——数据不一致、引用不完整、逻辑跳跃。但学术判断的核心——研究价值、创新性、方法论合理性——还是需要你自己把握。

我的做法是：AI 审阅结果作为“问题清单”，我逐条判断哪些是真问题，哪些是误报。误报的原因通常是 AI 对领域知识理解不够，把正常的学科惯例当成了问题。比如某些学科允许在探索性研究中不报告效应量，但 AI 可能会标记为“论据缺失”。

6.3 答辩预演要“出声”

模拟答辩环节，我强烈建议出声回答，而不是在脑子里过一遍。出声回答会暴露很多问题：逻辑不连贯、术语使用不当、回答过长或过短。我把自己的回答录下来回听，发现了好几个“嗯嗯啊啊”的口头禅和逻辑断层。

AI 判断回答是否充分，依据的是文本内容。但现场答辩还有表达层面的因素——语速、语气、眼神交流。这些 AI 判断不了，需要自己练习。我的做法是：AI 负责内容层面的追问，我负责表达层面的打磨。

6.4 材料版本管理很重要

答辩材料往往要改好几轮。每改一版，审阅结果就不一样。我建议用版本号管理，比如“答辩材料_v1”“答辩材料_v2_修改数据”“答辩材料_v3_补充实验”。每次审阅后，把 AI 的问题清单和修改记录对应起来，方便追溯。

Workbuddy 支持工作流版本管理，可以把每次审阅的配置和结果保存下来。如果换了新版本的材料，直接调用之前的工作流，不用重新配置。

6.5 本地部署的硬件门槛没有想象中高

很多人觉得本地跑大模型需要高端显卡，其实不是。Qwen2.5-7B 的 INT4 量化版，16GB 内存的普通笔记本就能跑。OpenVINO 对 CPU 的优化很好，没有独显也能用。如果内存只有 8GB，可以考虑 Qwen2.5-3B 或 1.5B 版本，虽然理解能力弱一些，但做基础审阅够用了。

我自己的测试机是一台三年前的轻薄本，i7-1165G7 处理器，16GB 内存，没有独显。跑 INT4 量化的 Qwen2.5-7B，处理 2000 字的分块，响应时间大概 4 到 6 秒。多轮对话时稍微慢一点，但完全在可接受范围内。

6.6 这套流程还能用在哪些场景

答辩材料审阅只是其中一个应用。同样的思路可以迁移到很多场景：

论文投稿前自查：把审稿人常问的问题写成规则，投稿前先让 AI 审一遍，能减少被拒的概率。

项目结题报告审阅：结题报告和答辩材料结构类似，同样需要论证链条完整、数据一致。

技术方案评审：把技术方案丢给 AI，让它追问“这个方案的依据是什么”“有没有考虑替代方案”“风险评估是否充分”。

合同和协议审阅：虽然领域不同，但“追问证据”的逻辑是通用的——每个条款的依据是什么，有没有遗漏关键条款。

核心逻辑都是一样的：把非结构化文档解析成结构化文本，用自定义规则驱动 AI 做针对性审阅，通过多轮追问暴露薄弱环节。工具可以换，但这个思路是通用的。

6.7 关于 TextIn xParse 和 Workbuddy 的配合细节

最后补充几个两个工具配合时的细节。xParse 输出的 Markdown 里，表格是用管道符表示的。Workbuddy 在解析这种表格时，偶尔会把长表格截断。我的处理方法是：如果表格超过 20 行，在 xParse 里先拆成多个小表格，再导入 Workbuddy。

另外，xParse 的 API 返回结果里包含每个文本块的坐标信息。如果 Workbuddy 需要定位问题在原文中的位置，可以利用这些坐标信息做映射。我在工作流里加了一个“坐标映射”节点，把 AI 指出的问题位置映射回 PDF 的页码和区域，方便快速定位。

还有一个细节是编码问题。xParse 输出的 Markdown 默认是 UTF-8，Workbuddy 读取时也要确保用 UTF-8 解码，否则中文会乱码。这个坑我踩过一次，排查了半天才发现是编码设置的问题。

整套流程跑顺之后，我审一份 60 页的答辩材料，从解析到出报告大概 15 分钟。相比人工逐页检查，效率提升明显，而且 AI 不会疲劳，不会因为看多了就跳过细节。当然，最终的判断还是在自己手里——AI 是放大镜，不是裁判。