ARTICLE · 1086449
我在学校做了一个“论文评审小助手” AI 不替老师打分,而是先帮老师把 74 个问题找出来
我在学校做了一个“论文评审小助手” AI 不替老师打分,而是先帮老师把 74 个问题找出来——一次从规则数字化、本地大模型到真实 Web E2E 的高校 AI 落地实践 本文配图包含项目架构示意图与真实开发/验收截图 如果把毕业论文评审拆开来看，会发现老师真正花时间的，并不全部是“这篇论文的学术水平怎么样”这种高价值判断。大量时间消耗在另一类事情上：标题、摘要、关键词是否完整，章节结构是否符合模板，参考文献是否规范，学校和学院规定的项目有没有遗漏，某一项要求究竟出现在论文的什么位置。 这些事情看起来并不复杂，却有一个共同特点：数量多、重复度高，而且不能不做。一篇论文往往要面对几十项检查规则。老师真正有价值的专业判断，反而被大量查找、核对、定位和重复检查包围。 所以我们做“论文评审小助手”时，最先提出的问题并不是“能不能让 AI 评论文”，而是一个更具体的问题：能不能让机器先完成第一轮检查，把真正需要老师判断的问题筛出来？ 这也决定了这个项目后面的技术路线。我们没有把它设计成一个“自动评审老师”，而是把它定位成论文 Pre-Review：机器先查，老师最终判断。 
图 1论文评审小助手的人机协作闭环 这个边界非常重要。论文小助手不是让 AI 自动给学生打分，也不是让模型直接宣布论文“合格”或者“不合格”。 我们把检查任务分成三层：规则明确、程序能够直接验证的内容，由确定性程序处理；需要理解上下文和语义的内容，由本地大模型辅助判断；存在不确定性或者需要专业判断的内容，则明确标记为 review_required，交还给教师。 换句话说，系统追求的不是“AI 什么都能判断”，而是让 AI 知道什么时候应该停下来，把决定权交给人。 这也是我越来越认同的一种高校 AI 设计方式：AI 的价值并不是替代专家，而是让专家把时间留给真正需要专业能力的事情。 做着做着我们发现，论文小助手最关键的资产其实不是模型，而是 Rule Catalog——规则目录。 过去的论文评审要求可能散落在学校模板、学院规范、Word 文件、检查清单，甚至老师的经验里。如果这些规则没有被结构化，再强的大模型也只能得到一段模糊的提示词。 因此，我们把评审规则逐步拆成可执行的规则项，并给它们稳定的 Rule ID。随后再按照执行方式分成三类。 第一类是 Deterministic Rule，也就是确定性规则。例如某个章节是否存在、摘要是否缺失、必要字段是否出现。这些事情程序能准确判断，就没有必要浪费 LLM。 第二类是 Semantic Rule，也就是语义规则。比如某一部分是否真正回答了指定问题，或者内容是否满足某个语义要求。这类判断很难只靠正则表达式，需要模型理解文本。 第三类是 Hybrid Rule，即混合规则。程序先做确定性过滤和定位，再把真正需要理解的部分交给 LLM。 这里形成了一个很朴素但非常重要的工程原则：能不用大模型解决的问题，就不要全部扔给大模型。大模型应该被用在它真正有价值的地方。 
图 2校内论文评审小助手总体架构 论文不是普通互联网文本。它可能包含学生信息、教师信息、研究数据以及尚未公开的成果。对于学校来说，这类数据是否离开校内环境，本身就是一个必须认真回答的问题。 因此，这次论文评审小助手采用本地推理方式，当前链路使用 Ollama 和 campus-qwen3-8b。论文内容在校内环境完成解析和模型推理。 更重要的是，这套系统不是简单的“Word → LLM → 一个答案”。实际链路更接近：Word → 文档解析 → Rule Catalog → 确定性/语义/混合检查 → Evidence → Finding → 教师复核。 也正因为如此，它和普通聊天机器人有明显区别。聊天机器人追求“回答”；论文小助手追求的是“依据什么规则，在什么位置发现了什么问题，以及这个问题是否需要人工复核”。 
图 3真实开发记录：Timeout 修复验证 系统进入真实论文测试后，很快遇到了一个典型问题：OllamaTimeoutError。 第一反应很容易是“模型是不是太慢了”“服务器是不是不够”“Qwen3-8B 是不是不适合”，甚至会怀疑整个架构。但我们没有直接把 timeout 随手改大，而是先做隔离诊断。 诊断结果很有意思：Ollama 在 warm、无竞争的情况下其实是稳定的。代表性请求的平均耗时大约 20 秒，测试没有出现 timeout。 真正的差异来自真实论文评审环境。一篇论文大约会触发 19 次 LLM 调用，同时还存在较长 Prompt、CPU 推理、模型冷启动以及其他请求竞争。原来的 HTTP Client 使用统一 120 秒 socket timeout，在某些真实条件下，客户端会在模型完成前先切断连接。 日志也给出了非常清楚的证据：客户端在 120 秒边界取消任务，随后论文规则被记录为 OllamaTimeoutError。与此同时，没有发现 OOM、进程重启或者 connection reset。 最终我们没有修改整个 RAG，而是只针对 Thesis Review 把 timeout 从 120 秒提高到 300 秒。原有 RAG 仍保持 120 秒，retry 仍然是 0，keep_alive 和并发参数也没有因为这个问题被顺手改掉。 因为“能跑”与“知道为什么能跑”是两件完全不同的事。 这次处理过程基本遵循了这样一条路径：问题复现 → 单独测试 Ollama → 记录每次 LLM Call → 对比 Cold/Warm → 检查并发竞争 → 确认 timeout 边界 → 做最小修改 → 回归测试。 如果一看到 timeout 就把 120 秒直接改成 600 秒，问题也许暂时消失，但我们并不知道模型是不是在泄漏资源、并发是不是失控、其他 RAG 请求是不是也会受到影响。 最后的验证结果证明，300 秒这个修改解决了论文评审链路的问题，同时没有改变已有 RAG 的 timeout 配置。 这次经历也让我更确定一件事：真正的 AI 应用工程，难点经常不是 Prompt，而是 timeout、任务生命周期、并发、日志、错误恢复、权限、审计以及如何证明修改没有破坏原系统。 完成 timeout 修复之后，我们用真实 .docx 论文跑了一次完整 Web E2E。 从用户视角看，流程很简单：Upload → Pending → Parsing → Reviewing → Completed。老师上传论文后，不需要理解后端到底跑了多少规则，只需要看到任务状态持续变化，并最终进入结果页。 一次真实测试大约用了 646 秒，也就是约 10.8 分钟。这个速度距离“秒级体验”当然还有很大优化空间，但它已经完成了从上传、解析、规则执行、本地模型判断，到 Summary、Findings 和 Finding Detail 的完整闭环。 这篇真实论文最终产生了 74 个 Findings。每个 Finding 不是一句泛泛的“这里有问题”，而是围绕 Rule ID、Rule Name、Status、Message、Evaluation Type、Evidence、Review Required 等字段组织。 这意味着教师看到的不只是一个模型结论，还能继续进入单条 Finding 查看检查依据。对于需要人工判断的项目，系统可以把它明确暴露出来，而不是假装 AI 已经确定。 对我来说，74 这个数字本身并不是重点。重点是系统开始把一篇论文从“一个完整 Word 文件”，转换成一组可以被定位、解释、复核和追踪的问题对象。 
图 4真实开发记录：阶段验收与回归验证 AI 项目特别容易出现一种错觉：现场演示成功一次，就认为系统已经完成。 所以这次我们一直保留自动化测试和基线。完成 Web UI 后，论文模块测试达到 100 passed、0 failed；全量 pytest 达到 242 passed、0 failed。 更重要的是，STEP 6 已经验证过的核心评审逻辑在 Web 阶段保持冻结。STEP 7 主要增加 Thin Web Client、路由、页面和 API 代理，没有为了做一个漂亮界面去重新修改已经稳定的评审规则。 真实 Web E2E 也不是模拟结果，而是使用论文完成 upload → create → pending → parsing → reviewing → completed → summary → 74 findings → detail。 
图 6真实开发记录：Web 层与安全约束验证 对学校内部 AI 系统来说，我认为“可验证、可回归、可追踪”应该和模型效果同样重要。因为真正上线以后，最怕的不是某次回答不够漂亮，而是你不知道一次修改究竟影响了哪些业务能力。 现在很多学校讨论 AI，第一反应是建设大模型平台、Agent 平台、知识库平台、算力平台。平台当然重要，但业务部门通常不会因为学校多了一个平台就觉得工作变轻了。 老师更关心的问题往往很直接：这个东西能不能让我少做一点重复工作？能不能少漏一个检查项？能不能让我把时间放到真正需要专业判断的地方？ 论文评审小助手就是一个典型的小切口。它的业务范围很窄，用户清楚，输入清楚，规则相对清楚，输出也能被验证。 这类 Small Agent / Vertical Agent 也许更适合成为高校 AI 的起点：小切口、高频率、规则明确、人在回路。先证明业务价值，再逐步抽象公共能力，而不是先建设一个巨大平台，再寻找它究竟应该解决什么问题。 论文助手验证的是“文档理解 + 规则引擎 + LLM”。下一步如果做报修小助手，验证的则是另一类能力：“自然语言理解 + Workflow + 业务系统”。 例如老师只需要输入“教学楼 302 的投影仪打不开”，系统就可以尝试识别地点、设备和故障类型，自动分类并生成工单，再交给后勤或者信息部门处理。 这两个 Agent 表面上完全不同，但往下看会发现，它们需要很多共同能力：身份认证、权限、模型调用、RAG、Workflow、日志、审计、任务状态以及统一入口。 这就自然产生了下一个问题：如果学校未来有十几个、几十个这样的助手，难道每一个都重新搭一套底层能力吗？ 
图 5从垂直 Agent 到学校 AI Runtime 当论文助手、报修助手、智能问数、教师一表通助手、制度问答助手逐渐出现时，学校真正需要沉淀的可能不是 100 个彼此孤立的 AI 项目，而是一套可复用的 AI Runtime。 在这个 Runtime 上，Identity、Permission、RAG、Workflow、Rule Engine、LLM Gateway、Logging、Audit 等能力成为公共基础设施；不同业务部门只需要围绕自己的规则、知识和流程构建 Agent。 入口也可以逐渐统一到企业微信、Web 或学校 App。对用户来说，他看到的是不同的业务助手；对技术团队来说，底层却是同一套受控、可审计、可维护的能力。 从这个角度再回头看论文小助手，它的价值就不只是“检查论文”。它还是一个很小的试验场：我们在里面验证规则如何数字化、AI 如何调用、人在什么位置接管，以及一套校内 AI 能力怎样逐步变成可复用的基础设施。 第一，AI 落地的最小单位不是“大模型”，而是“业务任务”。论文检查本身才是产品。Qwen、Ollama、RAG、FastAPI 都只是完成这个任务的技术手段。技术可以替换，但业务任务是否真正被解决才是最终标准。 第二，可靠的 AI 系统一定要允许 AI 说“我不能确定”。如果系统为了追求自动化率，强迫模型对所有问题给出确定答案，风险反而更大。review_required 这样的设计看似“不够智能”，实际上是对业务责任边界的尊重。 第三，高校 AI 的长期资产可能是“可执行的组织规则”。论文规范只是一个例子。培养方案、排课规则、职称评审、科研管理、数据治理、报修流程，都包含大量组织规则。当这些规则从文档和人的经验里被结构化为机器能够理解和执行的能力，AI 才真正进入学校的业务体系。 结语：我们做的不是一个会“写论文”的 AI 我们做的并不是一个会“写论文”的 AI，也不是一个准备替老师给学生下结论的“AI 评委”。 我们真正想做的，是一个懂学校规则、能完成第一轮重复检查、能够给出检查依据，并且知道什么时候应该把问题交还给老师的助手。 今天它检查的是论文。明天，它可能处理报修、制度问答、数据查询、教师业务或者更多行政流程。 当 AI 开始真正理解并执行组织中的规则，并且能够在权限、审计和人的监督下工作时，它才开始从一个“聊天工具”，变成学校数字化体系中的一种新基础能力。
01 先别谈“大模型”，先看老师每天在做什么
02 AI 不替老师打分：先把产品边界划清楚
03 真正困难的第一步，不是接大模型，而是把“规则”数字化
04 为什么我们没有直接把论文上传给公共大模型？
05 第一个真正的工程问题：不是 Prompt，而是 Timeout
06 为什么一个 Timeout，我们还要花时间做诊断？
07 一篇真实论文跑下来，系统到底得到了什么？
08 怎么证明它不是“Demo 成功了一次”？
09 做完这个小助手，我反而更不想从“大平台”开始谈高校 AI
10 论文小助手之后，为什么我想继续做“报修小助手”？
11 从“小助手”继续往下走，最终可能是一套学校 AI Runtime