企业官网建设流程全解析

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

每年到了答辩季，我身边总有一批人处于一种很微妙的状态：PPT 改了七八版，讲稿背得滚瓜烂熟，但心里始终没底。不是怕讲不好，而是怕被问倒。答辩这件事的本质，从来不是“你做了什么”，而是“你能不能证明你做了什么”。评委老师一句“这个数据哪来的”，就能让准备不充分的人当场卡壳。

我这次做的事情，说白了就是把自己关在书房里，把整套答辩材料——讲稿、PPT 备注、附录里的数据表、参考文献——全部丢给一套 AI 工具链，让它扮演一个极其挑剔的评委，逐条审我的论证链条。结果它真的开始追着我要证据。哪句话没有出处，哪个数据没有原始记录，哪个结论的推导过程跳步了，它一条条列出来，比我导师还狠。

这套流程里用到的核心工具是TextIn xParse和WorkBuddy，配合OpenVINO加速的Qwen模型做本地推理，底层还涉及OCR文字识别。整套方案解决的是一个很具体的问题：非结构化材料的结构化审校。你的答辩材料可能是扫描件、截图、PDF、手写批注混在一起，传统方式只能靠人眼一条条对，效率低且容易漏。而用 AI 做这件事，核心价值不在于“帮你写”，而在于“帮你查”——查逻辑漏洞、查证据缺失、查表述歧义。

适合谁来参考这套方法？我认为三类人最受益。第一类是正在准备答辩的研究生和本科生，尤其是材料多、数据杂、时间紧的；第二类是经常要做项目汇报、结题报告的职场人，材料审校是刚需；第三类是对 AI 工具链感兴趣、想找一个真实场景练手的开发者，这个场景足够复杂，能跑通 OCR、文档解析、本地推理、工作流编排一整条链路。

我先把整体思路讲清楚，再拆细节。整个流程分四层：材料摄入层负责把各种格式的答辩材料统一转成可处理的文本；结构解析层用 TextIn xParse 把文档拆成章节、段落、表格、图注；审校推理层用 WorkBuddy 编排工作流，调用 Qwen 模型做逐条审查；证据追溯层把每一条审查意见关联回原文位置，方便你快速定位修改。这四层里，最容易被低估的是第一层，很多人以为 OCR 就是“扫出来就行”，实际上答辩材料里的公式、表格、手写批注，才是真正考验工具的地方。

2. 材料摄入与 OCR 识别：别让扫描件成为第一道坎

2.1 答辩材料的格式乱象与统一策略

我自己的答辩材料就是一个典型的“格式灾难现场”。正文是 Word 导出的 PDF，附录里的实验数据是 Excel 截图，参考文献有一部分是知网下载的 CAJ 转 PDF，还有几页是导师手写批注后拍照发我的。这四种东西混在一起，你让任何一个 AI 模型直接读，它都会懵。所以第一步不是急着上模型，而是先把材料“洗干净”。

我的处理策略是分而治之。纯文本 PDF 直接用解析库提取，这一步不需要 OCR，因为文字层是完整的。扫描件和照片必须走 OCR，这里我用的是 TextIn xParse 内置的识别能力，它对中文排版和表格结构的还原度比我试过的几个开源方案都稳。Excel 截图这种半结构化内容，我会先手动裁掉无关区域，只保留数据表部分，再送进 OCR，这样识别准确率会明显提升。

提示：不要试图用一套参数处理所有材料。扫描件和照片的预处理逻辑完全不同，扫描件重点去噪和纠偏，照片重点做透视校正和光照均衡。

这里有个细节值得展开。TextIn xParse 在解析 PDF 时，会同时输出版面分析结果和文本内容。版面分析结果里包含了每个文本块的位置坐标、类型（标题、正文、表格、图注）以及阅读顺序。这个信息非常关键，因为后面做证据追溯时，你需要知道“这句话在原文的哪一页哪个位置”。如果只拿纯文本，你就丢失了空间信息，追溯就无从谈起。

2.2 OCR 识别的参数调优与常见坑

OCR 这件事，说简单也简单，说坑也多。我踩过的第一个坑是分辨率。手机拍的照片默认可能是 4000x3000，直接送 OCR 会非常慢，而且因为噪点多，识别率反而下降。我的经验是把长边缩放到 2000 像素左右，既能保留文字细节，又能控制处理时间。第二个坑是对比度。有些扫描件背景发灰，文字和背景的对比度不够，OCR 会把标点符号识别成乱码。这时候用简单的图像增强，把对比度拉高，识别率能提升一大截。

第三个坑最隐蔽：表格里的合并单元格。答辩材料里的数据表经常有跨行跨列的合并单元格，OCR 如果按行切分，会把合并单元格的内容重复识别或者错位。TextIn xParse 在这方面做得比较好，它会先做表格结构识别，再填充内容，输出的表格是结构化的 HTML 或 Markdown，合并关系保留得很完整。我实测下来，一张 10 行 6 列、带 3 处合并单元格的数据表，识别后的结构还原度在 95% 以上。

# 以 TextIn xParse 的 Python SDK 为例，展示一个典型的解析调用 from textin_xparse import XParseClient client = XParseClient(api_key="your_key") # 解析本地 PDF，开启表格识别和版面分析 result = client.parse( file_path="./答辩材料.pdf", options={ "table_recognition": True, "layout_analysis": True, "ocr": True, "language": "chinese" } ) # result 中包含 pages 列表，每页有 blocks，每个 block 有 type 和 bbox for page in result.pages: for block in page.blocks: if block.type == "table": print(block.to_markdown())

这段代码的关键在于options里的三个开关。table_recognition决定是否把表格还原成结构化数据，layout_analysis决定是否输出版面坐标，ocr决定是否对图片区域做文字识别。三个都打开，你拿到的就是一份“带空间信息的结构化文档”，这是后续所有审校工作的基础。

2.3 手写批注与公式的特殊处理

手写批注是 OCR 里最难的部分，没有之一。导师的字迹如果比较潦草，通用 OCR 基本抓瞎。我的做法是把手写区域单独裁出来，用专门的 handwriting 模型处理，或者干脆手动转录。这里不要追求全自动，因为手写批注往往是最关键的修改意见，识别错了比不识别更危险。

公式的处理是另一个维度。答辩材料里的公式如果是以图片形式嵌入的，OCR 只能识别出符号，丢失了数学结构。这时候需要用公式识别模型，把图片转成 LaTeX。我用的方案是先定位公式区域，再调用公式识别接口，最后把 LaTeX 嵌回文档流里。这样 Qwen 模型在审校时，才能理解“这个公式的推导是否成立”，而不是只看到一堆乱码符号。

注意：公式识别和普通 OCR 是两条不同的技术路线，不要混用。普通 OCR 对公式的识别率极低，强行用只会得到一堆无法理解的符号串。

3. 用 TextIn xParse 做结构解析：把文档拆成可审校的单元

3.1 为什么需要结构解析而不是直接丢给模型

很多人会问：现在的大模型上下文窗口都很大，为什么不直接把整份 PDF 转成文本丢进去？我试过，结论是效果很差。原因有三个。第一，长文本里信息密度不均匀，模型容易“中间迷失”，前面看过的证据后面就忘了。第二，没有结构信息，模型无法区分“这是正文”和“这是图注”，审校时会把图注当成论据来质疑。第三，证据追溯需要精确的位置信息，纯文本流里你无法定位“这句话在第几页”。

TextIn xParse 的结构解析解决的正是这三个问题。它把文档拆成章节树，每个节点有类型、内容、位置和层级关系。这样我在审校时，可以按章节逐段送进模型，每次只处理一个逻辑单元，模型的注意力集中，审查质量明显提升。同时，每个单元都带着原文坐标，模型给出的每一条意见都能映射回具体位置。

3.2 章节树与逻辑单元的划分原则

结构解析的核心产出是一棵章节树。根节点是文档，一级子节点是章，二级是节，三级是段落或表格。划分原则我总结为三条：按标题层级划分、按语义完整性划分、按审校粒度划分。前两条是文档本身的结构，第三条是我根据审校需求做的调整。

举个例子，答辩讲稿里“研究方法”这一章下面有“数据采集”“预处理”“模型选择”三个小节。按标题层级，这是三个独立单元。但审校时我发现，“数据采集”和“预处理”之间的逻辑衔接很关键，如果拆开审，模型看不到衔接问题。所以我把这两个小节合并成一个逻辑单元，让模型一次性审完，它就能发现“采集时说的样本量”和“预处理后剩下的样本量”对不上。

# 基于 xParse 的输出构建章节树，并按自定义粒度合并逻辑单元 def build_review_units(parse_result, merge_rules): units = [] current_unit = {"title": "", "content": [], "bbox_list": []} for block in parse_result.blocks: if block.type == "heading": # 遇到新标题，先保存当前单元 if current_unit["content"]: units.append(current_unit) current_unit = {"title": block.text, "content": [], "bbox_list": []} else: current_unit["content"].append(block.text) current_unit["bbox_list"].append(block.bbox) if current_unit["content"]: units.append(current_unit) # 按 merge_rules 合并相邻单元 return apply_merge_rules(units, merge_rules)

这段代码的关键是merge_rules，它决定了哪些相邻单元需要合并审校。我的规则是：如果两个单元的标题层级相同，且内容主题相关（比如都涉及数据），就合并。这个规则不是固定的，你可以根据自己材料的逻辑关系调整。

3.3 表格与图注的独立处理策略

表格和图注在答辩材料里扮演的是“证据”角色，审校时对它们的要求和正文完全不同。正文要求逻辑通顺，表格要求数据自洽，图注要求描述准确。所以我把它们从正文流里抽出来，单独处理。

表格的处理重点是数据一致性检查。比如正文里说“准确率达到 92.3%”，表格里对应的数值是不是 92.3？表格里各列加总是否等于总计？这些检查如果靠人眼，很容易漏。我把表格转成结构化数据后，写了几条简单的校验规则，让脚本自动跑，跑完再把异常项送给模型做二次确认。

图注的处理重点是描述与内容匹配。图注说“图 3 展示了三种方法的对比”，但图里其实有四种方法，这种错误很常见。我的做法是把图注文本和图片的 OCR 结果一起送给模型，让它判断描述是否准确。这里 OCR 的作用是提取图里的文字标签，比如图例、坐标轴标签，这些信息对判断图注准确性很关键。

4. WorkBuddy 工作流编排：让 AI 追着你要证据

4.1 WorkBuddy 的核心能力与选型理由

WorkBuddy 在这个流程里扮演的是“调度中心”的角色。它负责把前面解析出来的逻辑单元，按顺序送给 Qwen 模型，收集模型的审查意见，再把意见关联回原文位置。我选它而不是自己写脚本，主要原因是它的工作流编排能力和状态管理做得比较成熟，省去了大量胶水代码。

具体来说，WorkBuddy 支持定义节点和边。节点可以是“读取单元”“调用模型”“解析输出”“写入结果”，边定义节点之间的流转条件。比如我可以定义一个节点“检查证据引用”，如果模型输出里包含“缺少证据”的标记，就流转到“标记待补充”节点，否则流转到“通过”节点。这种条件流转用脚本写也不难，但 WorkBuddy 把它可视化了，调试起来直观很多。

另一个选它的理由是缓存机制。审校一份答辩材料，模型调用次数可能上百次，如果每次调试都重新跑，时间和成本都受不了。WorkBuddy 会把每个节点的输入输出缓存下来，修改下游节点时，上游节点直接读缓存，不用重跑。这个特性在迭代审校规则时特别有用。

4.2 审校工作流的节点设计与参数配置

我的审校工作流一共设计了七个节点，按执行顺序排列：

1. 材料加载节点：读取 TextIn xParse 的输出，构建逻辑单元列表。
2. 单元预处理节点：对每个单元做清洗，去掉页眉页脚、页码、重复的格式符号。
3. 证据提取节点：从单元内容里抽取所有“声称有证据支持”的陈述，比如“根据实验数据”“如表所示”“参考文献[3]指出”。
4. 证据核验节点：对每条陈述，检查是否有对应的表格、图注或参考文献条目。
5. 逻辑审查节点：调用 Qwen 模型，审查单元内部的逻辑连贯性，找出跳步、矛盾、歧义。
6. 意见汇总节点：把前两个节点的输出合并，按严重程度排序。
7. 结果输出节点：生成审校报告，每条意见附带原文位置和修改建议。

其中最关键的是证据核验节点和逻辑审查节点。证据核验节点不调用大模型，而是用规则匹配，因为“有没有对应证据”这件事是确定性的，用规则更快更准。逻辑审查节点才调用 Qwen，因为逻辑问题需要理解语义，规则搞不定。

# WorkBuddy 工作流定义示例（伪代码，展示节点配置思路） workflow = Workflow(name="答辩材料审校") workflow.add_node( name="evidence_check", type="rule_based", config={ "claim_patterns": ["根据.*数据", "如.*所示", "参考文献.*指出"], "evidence_sources": ["table", "figure_caption", "reference"], "match_threshold": 0.8 } ) workflow.add_node( name="logic_review", type="llm_call", config={ "model": "qwen2.5-7b-instruct", "backend": "openvino", "prompt_template": "你是一位严格的答辩评委，请审查以下内容的逻辑连贯性...", "temperature": 0.3, "max_tokens": 1024 } ) workflow.add_edge("evidence_check", "logic_review", condition="always")

这里temperature设为 0.3 是有讲究的。审校任务需要模型稳定输出，不能太有创造性，温度太高会导致模型“脑补”出原文没有的问题。0.3 是我实测下来比较平衡的值，既能发现隐性问题，又不会过度解读。

4.3 提示词工程：如何让模型真的“追着要证据”

提示词是这套流程的灵魂。我前后改了十几版，才让模型从“泛泛而谈”变成“追着要证据”。核心技巧有三个。

第一个技巧是角色设定要具体。不要只说“你是一个评委”，要说“你是一位以严谨著称的答辩评委，你的职责是找出论证链条中的每一个薄弱环节，尤其是那些没有明确证据支持的断言”。角色越具体，模型的审查风格越贴近你的需求。

第二个技巧是输出格式要约束。我要求模型按固定格式输出：[问题类型] 原文片段 -> 问题描述 -> 修改建议。这样我可以用脚本解析输出，自动生成审校报告。如果不约束格式，模型会写一大段散文，后续处理很麻烦。

第三个技巧是给例子。我在提示词里放了两三个“问题-意见”的示例，告诉模型什么样的审查意见是好的。这个技巧叫 few-shot prompting，效果非常明显。加了例子之后，模型给出的意见从“这句话表述不清”变成了“这句话声称‘显著提升’，但前文没有给出显著性检验的结果，建议补充 p 值或删除‘显著’二字”。

提示：提示词里的示例要覆盖你关心的所有问题类型，比如证据缺失、逻辑跳步、表述歧义、数据矛盾。示例越全面，模型的审查覆盖面越广。

5. OpenVINO 与 Qwen 本地推理：速度、成本与隐私的平衡

5.1 为什么选择本地推理而不是云端 API

审校答辩材料这件事，对隐私的要求其实不低。材料里可能有未发表的数据、导师的批注意见、甚至一些内部项目的细节。走云端 API 虽然方便，但数据出了本地，心里总是不踏实。所以我把推理放在本地，用 OpenVINO 加速 Qwen 模型。

本地推理的另一个好处是成本可控。审校一份材料，模型调用次数上百次，如果走云端，按 token 计费，一次审校下来成本不低。本地推理只有电费和硬件折旧，边际成本几乎为零。而且本地推理没有网络延迟，交互体验更流畅。

当然，本地推理也有代价。你需要一块还不错的显卡，或者至少是支持 AVX-512 的 CPU。我的设备是一台带独立显卡的工作站，跑 7B 参数的 Qwen 模型，量化后显存占用在 6GB 左右，速度可以接受。如果你只有轻薄本，可能需要考虑更小的模型或者云端方案。

5.2 OpenVINO 加速 Qwen 的配置要点

OpenVINO 是 Intel 推出的推理加速工具链，它能把模型转换成针对特定硬件优化的中间表示，从而提升推理速度。我用的是 OpenVINO 的 Python API，配合 Qwen2.5-7B-Instruct 的量化版本。

配置的关键步骤有三步。第一步是模型转换，把 Hugging Face 格式的 Qwen 模型转成 OpenVINO 的 IR 格式。这一步用optimum-intel工具可以一键完成。第二步是量化，把 FP16 转成 INT8 或 INT4，减少显存占用。我用的是 INT8 量化，精度损失很小，速度提升明显。第三步是推理配置，设置线程数、批大小等参数。

from optimum.intel import OVModelForCausalLM from transformers import AutoTokenizer # 加载 OpenVINO 优化后的 Qwen 模型 model = OVModelForCausalLM.from_pretrained( "qwen2.5-7b-instruct-ov", device="GPU", compile=True, use_cache=True ) tokenizer = AutoTokenizer.from_pretrained("qwen2.5-7b-instruct-ov") # 推理 inputs = tokenizer("请审查以下答辩材料的逻辑连贯性：...", return_tensors="pt") outputs = model.generate(**inputs, max_new_tokens=512, temperature=0.3) print(tokenizer.decode(outputs[0], skip_special_tokens=True))

这里device="GPU"指定用显卡推理，compile=True开启图编译优化，use_cache=True开启 KV 缓存加速。这三个参数对速度影响很大，建议都打开。如果你的设备没有独立显卡，把device改成"CPU"也能跑，只是速度慢一些。

5.3 推理性能实测与调优经验

我实测了一组数据，供你参考。在同一台工作站上，用 Qwen2.5-7B-Instruct 模型，输入长度 512 token，输出长度 256 token，不同配置下的推理耗时如下：

从数据看，GPU 加 INT8 量化是性价比最高的组合，速度比 FP16 快接近一倍，精度损失在审校任务里几乎感知不到。INT4 更快，但我发现它在处理长逻辑链时偶尔会“断片”，所以最终选了 INT8。

调优过程中我还发现一个细节：批处理对吞吐量影响很大。如果你有多个逻辑单元要审，不要一个一个送，攒成一批一起送，GPU 利用率会高很多。但批大小也不是越大越好，太大显存会爆。我的经验是批大小设为 4 到 8 之间比较稳妥。

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

6.1 OCR 识别不准的排查路径

OCR 识别不准是最常见的问题，排查路径我总结成一张表：

这张表是我踩坑踩出来的。最开始我遇到文字缺失，以为是 OCR 引擎不行，换了好几个工具都没解决，后来才发现是图片分辨率太低。所以排查问题要从最简单的可能性开始，不要一上来就怀疑工具。

6.2 模型审查意见质量不稳定的应对

模型审查意见质量不稳定，表现为有时候很准，有时候胡说。我遇到过的典型情况有三种。第一种是提示词漂移，同一个提示词，模型在不同批次的输出风格不一致。解决办法是固定temperature和seed，减少随机性。第二种是上下文过长，逻辑单元太长，模型看到后面忘了前面。解决办法是拆分单元，控制每个单元在 800 字以内。第三种是示例不匹配，提示词里的示例和当前材料类型不符。解决办法是根据材料类型准备多套示例，动态切换。

注意：模型给出的审查意见永远需要人工复核。它的价值是“帮你发现可能的问题”，而不是“替你做出判断”。我自己的做法是，模型标出的问题，我逐条确认，确认属实的才修改，误报的直接忽略。

6.3 工作流调试的效率技巧

WorkBuddy 工作流调试，最耗时的不是写节点，而是反复跑全流程。我的效率技巧有三个。第一，用缓存，前面说过，WorkBuddy 自带缓存，改下游节点时上游不重跑。第二，缩小测试集，不要一上来就跑全量材料，先拿两三页做测试，跑通了再扩。第三，日志分级，把日志分成 DEBUG、INFO、WARN、ERROR 四级，调试时只看 WARN 和 ERROR，减少信息干扰。

还有一个技巧是版本化提示词。提示词改来改去，很容易忘记哪版效果好。我把每版提示词都存成文件，文件名带日期和版本号，工作流配置里引用文件路径。这样回滚很方便，也方便对比不同版本的效果。

7. 证据追溯与报告生成：让每条意见都能定位

7.1 位置信息的保留与映射

证据追溯的前提是位置信息不能丢。TextIn xParse 输出的每个文本块都带bbox，也就是在页面上的坐标。我在构建逻辑单元时，会把每个单元的bbox_list一起存下来。模型给出审查意见后，我根据意见里引用的原文片段，在单元内容里做字符串匹配，匹配到之后，取出对应的bbox，就能定位到原文位置。

这里有个细节：模型引用的原文片段可能和原文有细微差异，比如多了个空格或者标点不同。所以匹配时不能要求完全相等，要用模糊匹配。我用的是编辑距离，阈值设为 0.9，也就是相似度 90% 以上就算匹配成功。实测下来，这个阈值能覆盖绝大多数情况。

7.2 审校报告的结构与呈现方式

审校报告我设计成三层结构。第一层是概览，列出问题总数、按类型分布、按严重程度分布。第二层是问题列表，每条问题包含：问题类型、原文片段、原文位置（页码和坐标）、问题描述、修改建议。第三层是原文对照，把原文和修改建议并排展示，方便直接对照修改。

报告格式我用的是 Markdown，因为方便后续转成 PDF 或网页。每条问题的原文位置，我做成可点击的链接，点击后跳转到原文的对应位置。这个功能在浏览器里看报告时特别方便，不用手动翻页找。

7.3 从审校意见到实际修改的闭环

审校的最终目的是修改。我在报告里给每条意见加了一个状态字段：待处理、已修改、已忽略。修改时，我逐条过，改完一条标记一条。全部过完之后，再跑一遍审校，看之前的问题是否解决，有没有引入新问题。这个闭环跑两到三轮，材料质量会有明显提升。

我自己的体会是，第一轮审校发现的问题最多，可能有几十条。第二轮会少很多，因为大部分明显问题已经改了。第三轮基本就是查漏补缺，问题数量个位数。到第三轮之后，再改就是过度打磨了，收益递减，可以停手。

8. 我踩过的坑与实操心得

8.1 不要追求全自动，人工介入是关键

我一开始的想法很美好：把材料丢进去，AI 自动审完，我直接拿报告改。实际跑下来发现，全自动的审校质量远不如“AI 初审 + 人工复核”。原因很简单，AI 不懂你的研究背景，有些在它看来“缺少证据”的陈述，其实是你领域内的常识。所以我的建议是，把 AI 定位成“初审助手”，它负责筛出可疑点，你负责判断哪些是真问题。

8.2 材料预处理的时间不能省

我最初为了赶时间，跳过预处理，直接把原始 PDF 丢进去。结果 OCR 识别出一堆页眉页脚和页码，模型把这些当正文审，给出了一堆莫名其妙的意见。后来我老老实实做预处理，去掉无关元素，审校质量立刻上了一个台阶。预处理花的时间，后面会加倍省回来。

8.3 提示词要跟着材料类型走

不同学科的答辩材料，论证风格差异很大。理工科重数据和公式，文科重文献和逻辑。我一开始用同一套提示词审所有材料，效果一般。后来针对理工科和文科分别写了两套提示词，理工科强调“数据一致性”和“公式推导”，文科强调“文献引用”和“论证链条”，效果明显提升。

8.4 本地推理的硬件门槛要提前评估

本地推理虽然好，但对硬件有要求。我在一台老笔记本上试过，跑 7B 模型慢到无法忍受，最后只能换设备。所以如果你打算走本地推理路线，先评估一下自己的硬件。如果硬件不够，可以考虑用云端 API，或者换更小的模型。不要为了本地而本地，工具是为人服务的。

8.5 审校报告要可操作，不要堆砌问题

我第一版审校报告列了 80 多条问题，看得我头皮发麻，根本不知道从哪改起。后来我加了严重程度分级，把问题分成“必须改”“建议改”“可选改”三档，先改必须改的，再看建议改的。这样改起来有优先级，效率高很多。报告的价值不在于问题多，而在于问题可操作。

9. 后续可以怎么扩展这套流程

这套流程跑通之后，我发现它的适用场景远不止答辩材料。项目结题报告、论文投稿前的自查、甚至商业计划书的审校，都可以用类似的思路。核心逻辑是一样的：把非结构化材料结构化，用 AI 做初审，人工做复核，最后生成可操作的修改清单。

扩展方向我想到几个。一是多模型对比，用不同的模型审同一份材料，对比它们的意见，取交集和差集，提高审查覆盖面。二是领域微调，用自己领域的材料微调 Qwen 模型，让它更懂领域内的论证规范。三是实时审校，把流程集成到写作工具里，边写边审，而不是写完再审。这几个方向我还在探索，有进展再分享。

最后分享一个小技巧：审校之前，先让模型把材料的“论证结构”画出来，也就是列出主要论点和支撑证据。这个结构图能帮你快速发现“哪个论点没有证据支撑”，比逐条审效率高得多。我现在的习惯是，先跑结构提取，再跑逐条审校，两步走，效果最好。