论文查重与测评系统开发

项目背景

这是一套论文测评与期刊分析报告系统，共 3 个仓库。后端为 Java API 服务，前端为 Vue 编写的 PC 端与移动端。系统覆盖论文与期刊数据的采集整理、分析指标计算，以及测评报告的自动生成与导出；报告中的指标保留可追溯信息。

客户当时的状态

学术测评类系统最容易出问题的地方，不是计算能力，是口径。同一个指标换一种算法就会得出不同的数值，如果报告里说不清用的是哪一种，被质疑时无法解释。另一处麻烦在数据：论文与期刊的数据来源分散，字段定义各不相同，先要整理成一致输入，指标才有可比性。同时报告的使用者包括评审与管理人员，查看场景从办公室电脑到移动设备都有，两端都不能缺。报告的使用者不只是技术人员，评审专家与管理人员会直接看结论，因此报告的可读性与可解释性本身也是交付要求。

我们的做法与取舍

第一个取舍是先固定指标口径再开发。每项指标的定义、输入与算法都写成文档，代码只是它的实现。代价是前期慢，收益是后续任何一次质疑都能拿出依据。

第二个取舍是让报告保留可追溯信息。报告里不只给结果，还记录指标来自哪些数据、怎么算出。这会让报告结构更重，但它是这类系统的立身之本。

第三个取舍是系统只给数据不给结论。评价标准由使用方定，结论的解释权也在使用方。系统越界给出评价，看起来更「智能」，但一旦被追责，责任边界就说不清了。

系统怎么承载这条链路

数据层负责论文与期刊数据的采集、字段统一与清洗；计算层由 Java API 服务承载指标计算与报告生成，并记录每项指标的口径；展现层是 PC 端与移动端，两端共用同一套 API，报告内容一致。

交付状态与边界

三个仓库的最后提交时间都是 2023 年 11 月，目前没有再更新的记录。边界说明：学术评价标准与权重由使用方确定，系统按既定口径计算，不自行设定评价体系；外部数据源的付费访问权限需贵方提供账号或授权，我们只做对接；报告的对外发布与结论认定由使用方负责，系统提供数据与报告能力，不代替评价判断。报告模板的调整按贵方需求配置；指标定义一旦修改，历史报告与新的口径需要区分说明，不能混在一起看。