1. 投稿系统里那串缩写到底在说谁
第一次投 SCI 或者顶会，点进投稿系统看到状态栏里蹦出 ADM、EIC、AE、TE、ED 这几个词，很多人第一反应是懵的。我见过最典型的场景：稿子投出去三天，状态从 Submitted 变成 "Awaiting Admin Processing"，作者开始慌，以为被拒了，其实只是编辑部在分配稿件号。还有人收到一封署名 "TE" 的信，以为是审稿人，回信语气特别客气，结果对方是编辑部的执行编辑，只负责流程。
这些缩写不是随便起的，它们对应投稿系统里一条完整的角色链路：作者提交 → 编辑部执行编辑（ADM）做格式与材料检查 → 主编（EIC）分派 → 副编辑（AE）找审稿人 → 审稿人打分 → AE 汇总建议 → EIC 拍板。TE 和 ED 则是这条链路上两个容易被混淆的节点，一个偏向"投给谁"，一个偏向"谁在编"。
这篇面向初次投稿、或者投了几次总被退回的研究者，把 AE、EIC、ADM、TE、ED 五个角色的职责边界、流转顺序、以及它们对应的系统状态讲清楚。后半段会给一份可复制的角色速查表和状态对照清单，并用 TaoToken 的统一 Key 搭一个记录投稿系统 API 调用日志的配置骨架，方便你逐项核对角色权限和状态变更记录。适合谁：正在准备投稿、已经投出但看不懂状态、或者想用脚本追踪多篇稿件进度的研究者。
2. 先把 TaoToken 的 Key 和调用入口准备好
投稿系统本身大多不开放公开 API，但很多研究组会用自建脚本去轮询稿件状态、记录状态变更时间戳，或者把多个期刊的投稿记录汇总到一张表里。这类脚本需要一个统一的模型调用入口来做状态文本解析、邮件摘要、角色识别。TaoToken 在这里的角色是提供统一的 API Key 和兼容接口，让你不用为每个模型单独配一套鉴权。
官网地址是 https://taotoken.net/?utm_source=taotoken_aicg_blog_end&utm_medium=csdn&utm_campaign=rewrite&utm_content= ，API 入口是 https://taotoken.net/api ，注意 API 地址不带 UTM 参数。你需要先去控制台创建一个 Key，控制台入口在 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite ，Key 管理页面在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite 。
拿到 Key 之后，建议先做一次模型对话验证，确认 Key 可用，入口在 https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=models&utm_campaign=rewrite 。如果你打算长期跑投稿状态追踪脚本，或者用 Agent 自动整理审稿意见，可以看一下 Coding Plan，入口是 https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite 。接入文档在 https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite ，Claude Code 相关的配置参考 https://taotoken.net/claudecode?utm_source=taotoken_aicg_blog_end&utm_content=claudecode&utm_campaign=rewrite 。
这一步的核心不是"注册"，而是把 Key 和 base_url 固定下来，后面所有脚本都复用同一套配置，避免每个期刊写一份鉴权逻辑。
3. 五个角色的职责边界与流转顺序
3.1 ADM：编辑部里和你打交道最多的人
ADM 是 Administrator 的缩写，中文一般叫执行编辑或管理编辑（Managing Editor）。你在投稿系统里收到的系统信、格式退回通知、稿件号分配通知，大概率都是 ADM 发出的。ADM 的核心动作有三个：分配稿件号（Edit the manuscript ID number）、修改投稿状态和日期、做初步的材料完整性检查。
ADM 不判断你的学术质量，只判断你的稿子"能不能进入审稿流程"。比如缺伦理声明、图片分辨率不够、作者贡献声明没填，这些都会被 ADM 拦下来。所以状态停在 "Awaiting Admin Processing" 不代表被拒，只代表流程还没走完。
3.2 EIC：最终拍板的人
EIC 是 Editors In Chief，主编。在投稿系统里，EIC 的权限最大，可以代理其他用户执行操作（can "proxy" or perform tasks on behalf of another user）。EIC 不直接找审稿人，而是把稿件分派给合适的 AE，最后根据 AE 的建议做录用决定。
凡是见刊的论文都要经过 EIC 裁定，所以 "Awaiting EIC Decision" 这个状态是最熬人的。EIC 的决定通常分五档：Accept、Accept after minor revision、Reconsideration after major revision、Reject and resubmit、Reject。其中 minor revision 如果标注 without re-review，就不需要再送审；major revision 一般要再走一轮审稿流程。
3.3 AE：终审环节的关键建议者
AE 是 Associate Editor，副编辑。AE 出现在审稿的终审环节，主要工作是在综合外审专家意见的基础上，对论文做整理和考量，然后给 EIC 一个建议。这个建议非常重要，是 EIC 判断能否录用的决定性因素之一。
AE 还负责邀请审稿人。状态 "Awaiting Reviewer Assignment" 就是 AE 或 EIC 在选审稿人、等审稿人回复是否同意审。如果审稿人 decline，AE 要重新邀请。所以这个状态持续一周以内算正常，超过两周可以考虑写信询问。
3.4 TE 和 ED：两个容易混的节点
TE 是 To Editor 的缩写，字面意思是"投给编辑"，通常出现在投稿动作或投稿信语境里，表示稿件被提交给某位编辑处理。ED 是 Editor 的简写，泛指编辑角色，可能是 AE，也可能是 EIC，具体看系统上下文。
这两个词本身不是独立角色，而是流程中的动作标记和泛称。你在状态栏里看到 "Submitted to Editor" 或者 "With Editor"，本质是稿件已经进入编辑处理环节，接下来要么分派 AE，要么直接由 EIC 处理。
3.5 完整流转顺序
把五个角色串起来，投稿顺序大致是：Authors Submit → Admin Checks Passes → EIC Assigns → AE Invites Reviewers → Reviewers Score → AE Makes Recommendation → EIC Makes Decision。会议场景里，AC（Area Chair）对应 AE，PC（Program Chair）对应 EIC，角色链路是一致的。
4. 可复制的角色速查表与状态对照清单
4.1 角色速查表
| 缩写 | 全称 | 中文 | 核心职责 | 对应状态关键词 |
|---|---|---|---|---|
| ADM | Administrator | 执行编辑 | 分配稿件号、改状态和日期、材料检查 | Awaiting Admin Processing |
| EIC | Editors In Chief | 主编 | 分派 AE、最终裁定录用 | Awaiting EIC Decision |
| AE | Associate Editor | 副编辑 | 邀请审稿人、汇总意见、给建议 | Awaiting AE Recommendation |
| TE | To Editor | 投给编辑 | 投稿动作标记 | Submitted to Editor |
| ED | Editor | 编辑泛称 | 泛指处理稿件的编辑 | With Editor |
4.2 状态对照清单
投稿后常见状态按时间顺序排列，你可以逐项核对：
Submitted to Journal 是上传完成后的自然状态。With Editor 表示稿件到了编辑手里，如果投稿时没选编辑，会先到 EIC 再分派。Editor Assigned 是编辑已分派，Editor Declined Invitation 是编辑拒绝邀请，这时 EIC 会重新分派。
Reviewer(s) Invited 表示编辑已接手，正在邀请审稿人。Under Review 表示审稿人已接受、正在审稿，这个阶段通常一个月左右。Required Review Completed 表示审稿结束、等编辑处理。Decision in Process 表示编辑开始考虑给修改还是拒稿。
另一套状态体系是：Awaiting Admin Processing（3-4 天后安排主编）、Awaiting Reviewer Assignment（一周以内）、Awaiting Reviewer Scores（审稿限期，可申请延长）、Awaiting AE Assignment（1-3 天）、Awaiting AE Recommendation（期限最后一两天出结果）、Awaiting EIC Decision（3-4 天）。如果是 communication 类稿件，通常没有 AE Assignment 和 AE Recommendation 这两步。
4.3 用 TaoToken 记录状态变更日志的配置骨架
下面这段 Python 骨架用统一 Key 调用模型，把状态文本解析成结构化字段，并记录时间戳。你可以把它接到自己的轮询脚本里。
import os import time import json import requests from datetime import datetime TAOTOKEN_API_KEY = os.environ.get("TAOTOKEN_API_KEY", "sk-your-key-here") BASE_URL = "https://taotoken.net/api" LOG_FILE = "submission_status_log.jsonl" ROLE_MAP = { "ADM": "执行编辑", "EIC": "主编", "AE": "副编辑", "TE": "投给编辑", "ED": "编辑泛称", } def parse_status_with_model(raw_status: str) -> dict: headers = { "Authorization": f"Bearer {TAOTOKEN_API_KEY}", "Content-Type": "application/json", } payload = { "model": "gpt-4o-mini", "messages": [ { "role": "system", "content": "你是投稿系统状态解析器。把输入状态解析为 JSON，字段包括 role（ADM/EIC/AE/TE/ED/UNKNOWN）、stage（admin/review/decision）、action（描述动作）。只输出 JSON。", }, {"role": "user", "content": raw_status}, ], "temperature": 0, } resp = requests.post(f"{BASE_URL}/v1/chat/completions", headers=headers, json=payload, timeout=30) resp.raise_for_status() content = resp.json()["choices"][0]["message"]["content"] return json.loads(content) def log_status(manuscript_id: str, raw_status: str): parsed = parse_status_with_model(raw_status) record = { "manuscript_id": manuscript_id, "raw_status": raw_status, "parsed": parsed, "role_cn": ROLE_MAP.get(parsed.get("role"), "未知"), "timestamp": datetime.utcnow().isoformat() + "Z", } with open(LOG_FILE, "a", encoding="utf-8") as f: f.write(json.dumps(record, ensure_ascii=False) + "\n") return record if __name__ == "__main__": sample = "Awaiting AE Recommendation" result = log_status("TNNLS-2024-001", sample) print(json.dumps(result, ensure_ascii=False, indent=2))这段代码的关键点：base_url 固定为 https://taotoken.net/api ，鉴权用 Bearer Token，模型返回强制 JSON 便于落库。每次状态变更写一行 JSONL，方便后续用 pandas 或 jq 做时间线分析。
5. 验证请求与成功结果
5.1 先验证 Key 可用
在跑上面的脚本之前，先用一条最小请求确认 Key 和 base_url 没问题：
curl -s https://taotoken.net/api/v1/chat/completions \ -H "Authorization: Bearer $TAOTOKEN_API_KEY" \ -H "Content-Type: application/json" \ -d '{ "model": "gpt-4o-mini", "messages": [{"role": "user", "content": "回复 OK"}], "temperature": 0 }'如果返回里有 choices 字段且内容包含 OK，说明 Key 和入口都正常。如果返回 401，检查 Key 是否复制完整；如果返回 404，检查 base_url 是否写成了带 UTM 的地址，API 入口不带参数。
5.2 再验证状态解析
把脚本里的 sample 换成你实际看到的状态文本，比如 "Awaiting EIC Decision"，运行后应该得到类似输出：
{ "manuscript_id": "TNNLS-2024-001", "raw_status": "Awaiting EIC Decision", "parsed": { "role": "EIC", "stage": "decision", "action": "等待主编做最终决定" }, "role_cn": "主编", "timestamp": "2025-01-15T08:30:00Z" }成功结果的特征是：role 字段落在 ADM/EIC/AE/TE/ED 五个值里，stage 落在 admin/review/decision 三个值里，timestamp 是 UTC 时间。如果 role 返回 UNKNOWN，说明状态文本不在常见集合里，需要扩充 system prompt 里的映射规则。
5.3 逐项核对角色权限
验证动作建议按这个顺序做：先核对 ADM 阶段的状态是否都有稿件号，再核对 EIC 分派后是否出现 AE 名字，然后核对 AE Recommendation 之后多久出现 EIC Decision。把每次状态变更的时间戳记进 JSONL，跑一周就能看出这本期刊的平均处理节奏。
6. 本篇常见错排查
6.1 把 ADM 当成审稿人
最常见的误解是收到 ADM 的信以为进入了外审。ADM 只做流程和材料检查，不评价学术内容。如果状态停在 Awaiting Admin Processing 超过一周，先检查投稿材料是否齐全，而不是催审稿意见。
6.2 把 TE 当成独立角色
TE 是 To Editor 的动作标记，不是一个人。你在投稿信里写 "Dear Editor" 没问题，但不要在状态栏里找 "TE 是谁"。ED 同理，是泛称，具体是谁要看系统里显示的编辑姓名。
6.3 状态长时间不动的误判
Awaiting Reviewer Scores 持续一个月以上是常态，因为审稿人可能申请延期。这时候可以写信给 AE 或 ADM 询问，但不要频繁催。如果状态从 Under Review 退回 With Editor，可能是审稿人 decline 了，编辑在重新邀请。
6.4 API 调用报 401 或 404
401 一般是 Key 没带对，检查 Authorization 头是不是 "Bearer " 加 Key。404 一般是 base_url 写错，确认用的是 https://taotoken.net/api 而不是带 UTM 的官网地址。如果返回 429，说明请求频率过高，投稿状态轮询建议间隔 6 小时以上，没必要分钟级轮询。
6.5 JSON 解析失败
模型偶尔会返回带 markdown 代码块的 JSON，导致 json.loads 失败。稳妥做法是在解析前先 strip 掉json 和标记，或者在 system prompt 里明确要求"只输出 JSON，不要 markdown 代码块"。
7. 把角色链路用起来
角色速查表和状态对照清单的价值不在于背下来，而在于你收到状态变更时能立刻判断"现在卡在谁手里、下一步该等多久、要不要写信"。ADM 卡材料、EIC 卡决定、AE 卡审稿人邀请，这三类延迟的应对方式完全不同。
如果你打算长期追踪多篇稿件，建议把上面的 JSONL 日志按 manuscript_id 分组，用 pandas 算每个阶段的停留时长，跑几个月就能摸清目标期刊的真实节奏。需要统一 Key 做状态解析或邮件摘要的话，从 API Keys 页面创建，接入方式参考接入文档；想先验证模型解析效果，可以直接在模型对话里贴状态文本试；如果要把这套逻辑做成长期跑的 Agent，Coding Plan 里有对应的配置说明。
