如果只把它叫做“投稿助手”，其实已经有点说窄了。

我现在这个项目更接近一个学术工作流助手：它不是只回答“这篇论文投哪”，而是想把研究者从选刊、看前沿、记截稿、管投稿，到做 AI 预审这一整条链路尽量串起来。

这篇文章就顺着这个思路，介绍一下我现在的项目到底在做什么，以及我为什么会把它做成现在这个样子。

1. 这个项目现在是什么

从代码结构上看，它已经不是单端 App，而是一个多端并行的项目：

  • iOS 端用 SwiftUI，目录在 AcademicSubmission/AcademicSubmission/
  • Android 端用 Flutter，目录在 academic_submission_flutter/
  • 微信小程序端用 UniApp + Vue3，目录在 academic-submission-uniapp/
  • AI 预审后端在 deep_research_review_v2/，走的是一条独立的深度评审链路

其中，iOS 端已经不只是一个静态展示壳了。
从 ContentView.swift 可以看到，当前主界面已经围绕四个核心入口组织起来：

  1. 期刊会议
  2. 前沿论文
  3. 学术社区
  4. 我的

同时还有一个悬浮的 AI 助手入口。
这意味着它的产品定位已经从“查期刊信息”逐渐转成了“围绕科研决策的日常工作台”。

2. 这个项目现在在解决什么问题

我自己理解，当前最核心的不是“做一个聊天机器人”，而是解决科研过程中几个重复出现的问题。

2.1 选刊信息太散

科研里一个很常见的低效环节是：

  • 去官网看会议截稿日期
  • 去各种论坛看投稿经验
  • 去分区表查期刊等级
  • 再自己手工比较几个候选 venue

这个项目首先做的是把这部分信息结构化。

从现有实现看，期刊会议模块并不只是一个简单列表，而是已经围绕这些能力在组织：

  • venue 数据加载与缓存
  • 学科归一化
  • 按等级、方向、类型筛选
  • 截稿日期解析
  • 会议信息展示
  • 收藏与最近访问

小程序端的数据层里还有一个我觉得很实用的细节：
对于会议截稿日期，系统会做一个自动年份滚动。也就是说，旧年份的 deadline 不会直接失效，而是会自动推到下一年度去计算“距离截稿还有多少天”。这类细节看起来小，但很符合真实使用场景。

2.2 前沿信息更新太碎

只解决“投哪”还不够，因为很多时候更早的问题其实是：

最近这个方向在发生什么？
哪些顶会顶刊开始密集出现某类主题？
我该持续追哪些作者、哪些 venue？

所以项目里又单独做了一条“前沿论文”主线。

从 PaperFeedService.swift 和 PaperStore.swift 看，这部分已经不是静态 demo，而是有一套相对清晰的数据流：

  • 拉取 arXiv / HuggingFace 等前沿论文源
  • 拉取顶会顶刊索引和分片数据
  • 做去重、合并、缓存
  • 结合用户关注主题、关注作者、已读记录做推荐
  • 支持方向统计和定时提醒

也就是说，它已经在往“学术信息流 + 个性化订阅”的方向走，而不只是一个投稿工具。

2.3 投稿过程缺少统一记录

很多论文一旦投出去，后面的状态就很容易散落在邮件、备忘录和聊天记录里。

这部分你已经做成了完整的投稿状态流：

  • 准备中
  • 已投稿
  • 审稿中
  • 大修 / 小修
  • 已接收 / 已拒稿
  • 已发表

而且这不是只停留在文案层。
从 iOS 的 DataManager+Persistence.swift、小程序的 submissions.js 这些实现看，投稿记录、AI 审稿结果、任务状态都已经进入了本地持久化体系。

这意味着产品已经开始有“个人科研资产管理”的味道，而不是一次性工具。

2.4 论文预审不应该只是一次聊天

我觉得这个项目里最有意思的一条线，其实不是选刊，而是 AI 预审。

很多“AI 审稿”产品的问题在于，它们本质上只是：

  1. 把 PDF 丢给模型
  2. 让模型返回一段看起来像审稿意见的文本

这种方式能做 demo，但很难做成真正可信的科研工具。

你现在这套实现，已经明显在往更严肃的方向走了。

从 AIReviewWorkflowService.swift、AI_REVIEW_BACKEND_FLOW.md 和 deep_research_review_v2/runtime/graph.py 可以看出，这条链路大致是：

  1. 创建审稿任务
  2. 上传 PDF
  3. 解析全文
  4. 抽取 claims
  5. 生成 research plan
  6. 检索相关文献与证据
  7. 做维度打分
  8. 合成 review
  9. 导出报告与可追踪 artifact

更重要的是，它不是一口气生成一段总评，而是拆成了多个显式节点：

  • extract_claims
  • plan_research
  • run_retrieval
  • build_evidence
  • score_dimensions
  • synthesize_review
  • export_artifacts

这背后的区别很大。

前一种做法是“让模型写一篇像审稿的作文”。
后一种做法是“把审稿过程拆成若干可检查的中间步骤”。

而且现在这套 runtime 还会落地：

  • deep_research_report.json
  • ai_review_report.json
  • trace.jsonl

也就是说，这部分已经在往“可追踪的 AI 评审流程”靠，而不只是“生成一段点评”。

3. 我觉得这个项目最像样的地方

如果让我自己总结，我会觉得它目前最有价值的地方，不是功能数量，而是三个产品判断。

3.1 它不是单纯的聊天入口

项目里当然有 AI 聊天能力，但它没有把所有问题都粗暴收敛到一个对话框。

相反，它把不同任务拆开了：

  • 聊天问答是一条链路
  • 论文预审是一条链路
  • 前沿发现是一条链路
  • 投稿管理是一条链路

这件事很重要。
因为科研场景不是“问一句，答一句”就结束的，真正有价值的是把任务嵌进工作流里。

3.2 它在认真处理“本地优先”和“远端增强”

从现有代码看，这个项目不是完全在线，也不是完全离线，而是两者混合：

  • venue、投稿记录、AI 审稿历史等数据尽量本地化
  • 前沿论文、顶会顶刊数据走远端同步
  • AI 预审走远端任务流
  • 聊天能力又允许切到兼容接口的多提供商配置

尤其是 iOS 这边，AIProviderConfigStore.swift 已经支持：

  • OpenAI
  • OpenRouter
  • DeepSeek
  • 硅基流动
  • 自定义兼容接口

并且把 API Key 放进 Keychain，而不是简单塞到普通配置里。
这一层说明项目已经开始考虑“真实可用”，而不是只为演示写死一个模型。

3.3 它开始具备“科研工作台”的雏形

如果只看功能名，很多人会把它理解成几个模块的拼接：

  • 期刊库
  • 论文流
  • AI 助手
  • 投稿管理

但把这些模块连起来看，逻辑其实已经很明确了：

  1. 先通过前沿论文看方向
  2. 再通过 venue 数据确定投稿目标
  3. 用 AI 做选刊、比较和预审
  4. 最后把投稿过程管理起来

这就是我为什么更愿意把它叫做“学术工作流助手”，而不是“投稿查询工具”。

4. 现在还缺什么

当然，这个项目还远远没有到“完成态”。

如果从产品成熟度看，我觉得现在还有几块明显的工作没彻底闭环。

4.1 多端能力还需要继续统一

iOS、Flutter、UniApp 现在都已经有各自实现，但功能演进速度并不完全一致。

这很正常，多端项目一旦拉开，就一定会出现：

  • 某一端先试新功能
  • 某一端还保留旧交互
  • 数据层一致，但体验层不完全同步

后面如果继续做，我觉得最重要的不是“每端都做得更多”，而是先把主流程收敛成真正一致的产品能力。

4.2 社区和协作能力还在早期

项目里已经有学术社区、评价、经验分享这些入口，但从整体重心看，当前真正最扎实的主线还是：

  • 选刊数据库
  • 前沿发现
  • AI 预审
  • 投稿跟踪

社区这条线后面能不能做起来，关键不在页面数量，而在于能不能形成稳定的高质量内容沉淀。

4.3 AI 预审的可信度还可以继续往上做

虽然现在这套预审链路已经比“直接让模型写一段评论”认真得多，但如果真想把它做成硬核能力，后面还会继续碰到几个问题：

  • 检索证据的覆盖率够不够
  • 不同学科的评审维度能不能泛化
  • 结果解释是否足够可追踪
  • 用户是否真的会把它当作投稿前的一次有效预检查

不过至少从架构上看，你已经没有走那种最短平快但很难扩展的路子了。

5. 为什么我还会继续做这个项目

因为它解决的问题是真实的，而且很高频。

科研里有太多时间，并没有花在真正的研究思考上，而是花在这些琐碎但必须做的事情里：

  • 查 venue
  • 看 deadline
  • 比较期刊
  • 追前沿
  • 管投稿
  • 改稿前先做一轮自查

如果这些动作是散的，研究体验就会一直被打断。
如果它们能被组织成一个工作流，哪怕每个环节只提升一点效率，整体体验都会好很多。

所以对我来说，这个项目最有意思的地方不是“做了一个 AI 页面”，而是尝试把科研日常里那些分散的动作，慢慢收拢成一个连续系统。

6. 总结

如果要用一句话概括我现在这个项目，我会这么说：

它已经不只是一个学术投稿信息查询工具，而是在朝着一个真正的学术工作流助手演化。

它现在已经有了几个比较清楚的骨架：

  • 多端前台
  • 本地优先的数据管理
  • 前沿论文发现
  • venue 与 deadline 组织
  • AI 问答与多提供商配置
  • 基于任务流的 AI 预审后端

后面要做的，不是再堆很多零散功能，而是继续把这几条主线收紧，让它从“能展示很多能力”，慢慢变成“真的能陪研究者完成一段完整流程”。

这件事如果做成，我觉得它的价值会比“做一个会聊天的学术 App”大得多。