MDPI AG 2025.11 - 至今

MDPI投稿系统 - SuSy

SuSy(Submission and Process Handling System)是MDPI的核心稿件处理系统,服务全球数万名编辑,日均处理稿件 2000 篇以上。

AI 推荐审稿人 · 技术预检 · 业务流程 · 前后端分离 · HTML 邮件

70% AI 推荐采纳率
80% 优质审稿报告占比
3 分钟/篇 预检耗时缩短
500+ 预检覆盖期刊

Background

SuSy 同时支持500+期刊,服务全球数百万名作者和编辑,每天要处理 2000 多篇投稿。系统里的很多小问题,放到这个量级都会被放大。

多期刊

不同学科、期刊的审稿标准和编委结构都不一样,同一套流程很难完全通用。

多角色

作者、编辑、审稿人、编委都在同一篇稿件上操作。任何一环卡住,审稿周期就会变长。

高时效

每天2000多篇投稿。人工环节多花一分钟,一天加起来就是两千多分钟。

AI 推荐审稿人

过去要从审稿人库里找出方向匹配且available的审稿人,依靠手动搜索。

技术预检

每篇新投稿,要先过几十项技术检查。规则不全篇、触发节点混乱,没有统一的流程。

这两件事占据了编辑每天80%以上的时间和精力

案例一:AI 推荐审稿人

以前编辑靠关键词和主页找人,现在系统先按语义相似度排一遍,再把判断依据摆到编辑面前。

当时的痛点

规模压力

每天 2000 多篇投稿,每篇都要找多位审稿人。编辑大量时间花在搜索和筛选上。

规则失效

原系统按研究方向关键词召回。关键词对得上,不代表研究内容真的接近。跨学科或者方法不同的稿件,经常被漏掉,或者推来的人不对口。

候选池偏窄

规则能召回的人有限。编辑还是得自己搜,逐个点开主页看,推荐没有省掉多少事。

推荐是怎么排出来的

1

语义召回

先把稿件的 title 和 abstract 向量化,和文章库比语义相似度,取最相关的前 X 篇。文章的作者进入候选池。

2

规则过滤

再按规则剔除有利益冲突、机构或合作关联、伦理争议,以及当前不可用的候选人。

3

相似度重排

剩下的人里,再算他们历史文章和当前稿件的余弦相似度,进行rerank。

4

人工确认

编辑看到的是排序后的列表,加上每个人的信息卡片。确认或邀请由编辑点,系统不会自动发。

编辑看到什么

AI 推荐审稿人界面:左侧候选列表,右侧审稿人信息与历史邀请记录
左侧是排好序的候选列表,右侧是选中审稿人的研究方向、h-index 和邀请记录。

卡片里有研究方向关键词、过往投稿和审稿记录、h-index、编委过往决定,还有个人主页。

结果

70% 推荐审稿人最终邀请占比
80% 优质审稿报告占比

下一步

  • 比较和优化 embedding 模型
  • 历史文章的加权方式对比:最新的、最相似的、X篇平均值
  • 投稿文本先用 LLM 重写一遍再拿去匹配,看召回能不能更贴近真实研究方向。
  • 做「首次邀请」的响应率模型,再试一个模型识别大概率会回信的学者,用它调整邀请顺序。
  • 按学者所在时区的历史活跃时间(审稿、投稿、接受),挑出现在适合邀请的人,并在界面上高亮。这条目前对回复率的影响最大。
  • 把推荐理由直接写进卡片,而不是只给一个相似度分数。

案例二:技术预检

在特定节点触发技术预检,根据业务需要和资源设定同步检查和异步检查,生成技术预检报告

当时的问题

重复劳动

每天 2000 多篇稿子,每篇几十项技术检查。很多检查靠人一项项看,标准/稳定性都不可保障

规则能做的有限

格式、完整性可以写规则。期刊匹配度、英语水平、疑似 AI 生成这些,规则判不了,只能人工看

缺少统一视图

检查结果散在不同地方,编辑很难一眼看完。漏看一项,就容易引起学术诚信问题

预检是怎么跑的

1

多节点异步触发

作者提交成功后,系统在后台建一个解析+预检任务,无需在线等待。每当revision时自动触发,保证实时性

2

规则 + AI 检查

多项标准检查和三项 AI 检测(期刊匹配度、英语水平、疑似 AI 生成)分开跑。一项失败,不影响其他项出结果。

3

错误处理机制

每类任务有自己的错误处理规则,界面清晰,保留手动重试入口,不静默跳过,也不影响其他检测项目。

4

统一报告

汇总成一张静态的技术预检报告,由内部编辑决定报告的最终形态,可留言,可修改,用于编委决定送审、退回还是人工复核。

预检报告

技术预检报告:注意事项与通过项分组展示
需要人工关注的项排在前面,通过项单独分组;每项都带编辑留言的位置。稿件信息和作者已做遮挡。

结果

3 分钟/篇 人工检查耗时缩短(抽样)
500+ 覆盖期刊
2000+/日 投稿处理量

限制

  • AI检测的规则对外黑盒,信任度待培养
  • 密集计算对设备和资源有较高的要求
  • 检测项目的必要性和业务价值缺少可量化的评估标准

做完之后,我更确定的两件事

先看业务,再判断用不用AI

接到一个 AI 需求,我第一个问题通常不是它能不能做,而是这件事原来是怎么做的。谁在做、做一次要多久、弄错了谁收拾。这几句说不清楚,需求本身就没成立,只是把“我们也该用 AI”换了个说法。

这两年见过不少“我们也要接大模型”的提案,往下追问三层就卡住。技术上都做得出来,可做出来解决的往往不是真问题,最后只是多一个没人点开的入口,和一份要一直维护的调用成本。

判断标准其实很朴素:这件事是不是已经到了人做不完,或者不同的人做出来结果不一样的程度。如果现在的做法还凑合,省下来的那点时间,通常撑不起一个 AI 项目的成本和风险。

这个岗位的名字大概留不住

AI 产品经理这两年热门,是因为大模型刚落地那阵,懂一点模型能力和完全不懂的人,做出来的东西差得很远。等这些能力沉到基础设施那一层,差距会收窄。今天没人把“懂数据库”写进产品经理的岗位名称,AI 大概率也会走到这一步。

我自己的理解是:以后的 AI 产品经理,是做 AI 产品的产品经理,不是精通 AI 能力的产品经理。前者要想的是这个产品该不该有这个能力、给了之后谁来兜底;后者想的是这个能力怎么实现。后者是加分项,前者是本职。

所以我不觉得这是个能干十年的头衔,但它是个很好的观察位置。