paper-submission-planner

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Paper Submission Planner

论文投稿规划工具

Purpose

目标

Help the user plan a conference paper submission backwards from the deadline, applying the strategic and tactical frameworks from the New Researcher Handbook (Sections 8.3.1 Conference Timeline Management and 8.3.4 Technical Paper Planning). The skill covers both the strategic questions (is this work right for this venue? what's the story?) and the logistical timeline (what needs to happen by when?).
The goal is to prevent the two most common disasters: (1) missing the deadline entirely and losing a year, and (2) submitting a paper that technically exists but isn't ready to be reviewed well.
帮助用户从截止日期倒推规划会议论文投稿,应用《新研究者手册》(第8.3.1节 会议时间线管理和第8.3.4节 技术论文规划)中的战略与战术框架。此技能既涵盖战略层面问题(这项研究是否适合该会议?核心故事是什么?),也包含后勤时间线规划(各项任务的完成节点)。
目标是避免两种最常见的失误:(1) 完全错过截止日期,浪费一整年时间;(2) 提交一篇仅完成技术内容但未达到评审标准的论文。

When to Use

使用场景

  • User names a target conference and a deadline
  • User is choosing between venues
  • User asks "is my work ready to submit?"
  • User is building a timeline for submission
  • ~2-3 weeks before a known deadline, as a final readiness check
  • 用户指定了目标会议和截止日期
  • 用户正在在不同会议间做选择
  • 用户询问“我的研究准备好投稿了吗?”
  • 用户正在制定投稿时间线
  • 已知截止日期前约2-3周,进行最终就绪检查

The Planning Workflow

规划流程

The flow depends on how far out the user is. Ask the user early on: "Roughly how far are you from the deadline?" and adapt.
流程取决于用户距离截止日期的时间。尽早询问用户:*“你距离截止日期大概还有多久?”*并据此调整流程。

Phase 1: Strategic Pre-Submission Questions

第一阶段:投稿前战略问题

Do this phase first, no matter how close the deadline is. If the answers are bad, more time won't save the paper — a different framing might.
Walk through these (from Handbook Section 8.3.4), one at a time:
Contribution Clarity
  • Can you finish this sentence: "We are the first to [solve / show / unify] X important problem"? If the user can't, the paper's core story isn't clear yet.
  • What is the one-sentence claim a reviewer should walk away remembering?
  • Is the contribution theoretical, methodological, empirical, or an analysis/unification? Say which.
Fit with the Venue
  • Is the topic aligned with what this venue publishes? Have you checked recent accepted papers at this venue on this topic?
  • Is it saturated (hundreds of similar papers last year), or is it trending up?
  • Does the framing match the venue's aesthetics? (ML venues reward novelty and ablations; systems venues reward measurement; HCI venues reward study design.)
Novelty Check
  • How is this clearly different from work in the last 12 months? Not "we use a different optimizer" — what's the actual advance?
  • If someone points at paper X (published recently) and says "this looks similar" — what's your honest response?
Backup Plan
  • If this gets rejected from [target], what's the next venue? Build a cascade now (e.g., ICML → NeurIPS → ICLR → domain workshop). Writing the cascade down before submission makes post-rejection decisions faster and less emotional.
If any of these questions gets a weak answer, stop and address it before planning the timeline. A great timeline for a poorly-framed paper produces a well-executed rejection.
无论距离截止日期有多近,都要先完成此阶段。如果问题的答案不理想,再多时间也无法挽救论文——或许换一种叙事框架才是解决之道。
逐一梳理以下问题(出自手册第8.3.4节):
贡献清晰度
  • *你能否完成这句话:“我们首次[解决/展示/整合]了X这一重要问题”?*如果用户做不到,说明论文的核心故事尚未明确。
  • 审稿人读完后应该记住的核心论点用一句话怎么表述?
  • 你的贡献属于理论型、方法型、实证型,还是分析/整合型?请明确说明。
与会议的契合度
  • 研究主题是否符合该会议的发表方向?你是否查看过该会议近期同主题的录用论文?
  • 该主题是否已饱和(去年有数百篇类似论文),还是正处于上升趋势?
  • 论文框架是否符合该会议的风格偏好?(机器学习类会议看重创新性和消融实验;系统类会议看重测试结果;人机交互类会议看重研究设计。)
创新性检查
  • 与过去12个月的研究相比,你的工作有哪些明确的不同之处?不是“我们使用了不同的优化器”这种表述,而是真正的技术突破是什么?
  • 如果有人拿出近期发表的论文X说“这看起来很相似”——你真实的回应是什么?
备选方案
  • *如果这篇论文被[目标会议]拒稿,下一个目标会议是什么?*现在就制定备选阶梯(例如:ICML → NeurIPS → ICLR → 领域研讨会)。在投稿前就写好备选阶梯,能让拒稿后的决策更快、更理性。
如果任何一个问题的答案不够明确,先停下来解决该问题,再规划时间线。为一篇框架混乱的论文制定完美时间线,最终只会得到一次精心准备的拒稿通知。

Phase 2: Build the Timeline

第二阶段:制定时间线

Use the standard T-minus structure from the Handbook, adapted to the user's actual distance from the deadline. Always set the user's personal deadline at least 1 week before the real one (protects against last-week disasters and lets them help others, which builds network).
If T > 6 months: Too early for a detailed timeline. Help the user identify the T-6 month checkpoint: what needs to be true 6 months out to make the submission realistic? If the answer is "most things," that's informative — the current plan is aspirational.
If T = 6 months (or close):
T-6 months: Major experiments start; baseline implementations in place; related work drafted.
T-5 months: Main results should be emerging. If they aren't, recalibrate now — don't wait.
T-4 months: Ablations identified. Draft of intro and methods begun.
T-3 months: Main experiments COMPLETE (not "mostly done"). First full draft exists.
T-2 months: Full draft circulating to 1-2 trusted readers. Writing the story, not just sections.
T-1 month: Second full draft. All ablations done. Plots polished. External feedback incorporated.
T-3 weeks: Paper substantively frozen. Now polishing, supplementary, code release prep.
T-1 week: Personal deadline. Paper should be done. Use this week to help others / rest / buffer.
T-0: Submit calmly.
If T < 6 months: Build a compressed timeline but flag honestly what's likely to get sacrificed. Usually: ablation depth, writing polish, or sleep. The user should know which.
If T < 1 month: Switch modes: the user is now in execution, not planning. Help them triage:
  • What experiments are absolutely required vs. nice-to-have?
  • What sections of the paper still don't exist?
  • Where will the inevitable emergency happen? (Compute failure? Baseline reimplementation? Reviewer #2 in their head making them rewrite?)
使用手册中的标准T-minus结构,根据用户实际剩余时间调整。务必将用户的个人截止日期设定在官方截止日期至少1周前(避免最后一周出现意外,同时让用户有时间帮助他人,拓展人脉)。
当剩余时间>6个月时: 此时制定详细时间线为时过早。帮助用户确定T-6个月检查点:6个月后需要完成哪些任务,才能确保投稿可行?如果答案是“大部分任务”,说明当前计划还只是设想。
当剩余时间=6个月(或接近6个月)时:
T-6个月:启动主要实验;完成基线模型实现;开始撰写相关工作部分。
T-5个月:核心结果应逐步显现。如果没有,立即调整计划——不要拖延。
T-4个月:确定消融实验方案;开始撰写引言和方法部分初稿。
T-3个月:完成所有主要实验(不是“基本完成”);产出第一版完整初稿。
T-2个月:将完整初稿发给1-2位可信读者审阅。聚焦于讲述核心故事,而非单纯填充章节内容。
T-1个月:完成第二版完整初稿。所有消融实验结束;优化图表;整合外部反馈。
T-3周:论文内容基本定型。此时专注于润色、补充材料准备和代码发布筹备。
T-1周:个人截止日期。论文应全部完成。利用这周时间帮助他人/休息/应对突发情况。
T-0:从容提交论文。
当剩余时间<6个月时: 制定压缩版时间线,但要如实告知用户哪些内容可能会被牺牲。通常是:消融实验深度、写作润色程度,或是休息时间。用户需要清楚这一点。
当剩余时间<1个月时: 切换模式:用户现在进入执行阶段,而非规划阶段。帮助他们优先处理关键任务:
  • 哪些实验是必须完成的,哪些是锦上添花的?
  • 论文哪些部分尚未动笔?
  • 可能会出现哪些突发状况?(计算资源故障?基线模型重实现?脑海中审稿人2的质疑让你重写内容?)

Phase 3: Pre-Submission Readiness Checklist

第三阶段:投稿前就绪检查清单

In the final 1-2 weeks, walk through this checklist with the user. Each item is a question, not a command.
Story
  • Can the abstract be read in 60 seconds and the contribution be clear?
  • Does the intro end with a concrete list of contributions (bullet points are fine)?
  • Does the paper have one clear "money figure" that captures the main result?
Experiments
  • Are main comparisons fair (same compute, same tuning budget, same data)?
  • Are ablations targeted at the paper's actual claims, not just "standard ablations"?
  • Are error bars or statistical treatment present where they matter?
  • Are all numbers in the paper reproducible from the codebase?
Writing
  • Has at least one person outside the author list read it end-to-end?
  • Is the related work honest about what's truly novel vs. incremental?
  • Are the limitations section genuine (not performative)?
Logistics
  • Double-blind anonymization: author info, acknowledgments, self-citations, code repo links (use
    anonymous.4open.science
    or equivalent).
  • Supplementary files prepared and linked properly.
  • LaTeX compiles cleanly, no overfull boxes, all references render.
  • Submission portal account set up, co-authors registered, conflicts declared.
在截止日期前1-2周,与用户一起梳理以下检查清单。每项都是问题,而非指令。
核心故事
  • 摘要能否在60秒内读完,且核心贡献清晰明确?
  • 引言结尾是否列出了具体的贡献点(可以用 bullet 点)?
  • 论文是否有一张清晰的“核心图表”,能够体现主要研究结果?
实验部分
  • 主要对比实验是否公平(相同计算资源、相同调参预算、相同数据集)?
  • 消融实验是否针对论文的核心论点,而非只是“标准消融实验”?
  • 在重要数据处是否标注了误差线或进行了统计处理?
  • 论文中的所有数据是否都能通过代码库复现?
写作部分
  • 是否至少有一位非作者人员完整通读了论文?
  • 相关工作部分是否如实区分了真正的创新性和增量性贡献?
  • 局限性部分是否真实客观(而非流于形式)?
后勤事项
  • 双盲匿名处理:作者信息、致谢、自引、代码仓库链接(使用
    anonymous.4open.science
    或类似平台)。
  • 补充材料已准备好并正确链接。
  • LaTeX编译无错误,无内容溢出,所有参考文献显示正常。
  • 已注册投稿系统账号,共同作者已完成注册,已声明利益冲突。

Phase 4: After Submission

第四阶段:投稿后

If the user returns post-submission, offer a short reflection:
  • What felt rushed? (So next paper's timeline accounts for it.)
  • What would you change about the submission process next time?
  • What's the rebuttal plan? (Set aside specific dates for reviews release and rebuttal period.)
如果用户投稿后返回,提供简短的复盘建议:
  • 哪些部分感觉比较仓促?(以便在下一篇论文的时间线中加以考虑。)
  • 下次投稿流程中你会做出哪些改变?
  • rebuttal计划是什么?(预留出评审意见发布和 rebuttal 阶段的具体时间。)

Artifact

存档文件

Save to
~/phd-log/submissions/[venue-year]-[short-title].md
. Structure:
markdown
undefined
将内容保存至
~/phd-log/submissions/[venue-year]-[short-title].md
。结构如下:
markdown
undefined

Submission: [Paper Title]

投稿:[论文标题]

Target

目标信息

  • Venue: [conference name]
  • Deadline: [date] (real) / [date - 1 week] (personal)
  • Backup cascade: [venue 1] → [venue 2] → [venue 3]
  • 会议:[会议名称]
  • 截止日期:[官方日期] / [官方日期提前1周](个人截止日期)
  • 备选阶梯:[会议1] → [会议2] → [会议3]

One-sentence contribution

核心贡献一句话总结

[the sentence]
[具体表述]

Key risks

主要风险

  • [top 2-3 things that could go wrong]
  • [最可能出现的2-3个问题]

Timeline

时间线

[T-minus structure filled in with dates]
[填充具体日期的T-minus结构]

Readiness checklist status

就绪检查清单状态

[updated during the sprint]
[投稿冲刺期间更新]

Post-mortem (after submission)

投稿后复盘

  • What went well:
  • What to change next time:
undefined
  • 做得好的地方:
  • 下次需要改进的地方:
undefined

Tone and Posture

语气与立场

  • Be honest about rejection probability. If the paper has real problems, say so. Sugarcoating wastes the user's limited submission attempts.
  • Don't be a cheerleader. The job is to help the user submit a paper that's actually good, not to inflate their confidence.
  • Protect the personal deadline. When the user wants to push it later, push back. The buffer is the whole point.
  • If the user is submitting because "the deadline is coming" rather than "the work is ready," say so directly — sometimes skipping a deadline and waiting for the next one is the right move.
  • 如实告知拒稿概率。如果论文存在实质性问题,直接指出。粉饰太平会浪费用户有限的投稿机会。
  • 不要一味打气。我们的职责是帮助用户提交真正优质的论文,而非盲目提升其信心。
  • 严格执行个人截止日期。当用户想要推迟个人截止日期时,要提出反对意见。缓冲期的存在至关重要。
  • 如果用户投稿只是因为“截止日期快到了”而非“研究已准备就绪”,直接点明——有时跳过当前截止日期,等待下一次机会才是正确选择。

What Not to Do

禁忌事项

  • Don't let the user skip Phase 1. A clean timeline for an unclear paper is useless.
  • Don't produce a generic timeline without adapting to the user's actual T-minus distance.
  • Don't produce a 40-item checklist. The user won't read it. Keep the readiness checklist focused.
  • Don't forget backup venues. A single-venue plan turns one rejection into a year of lost time.
  • 不要让用户跳过第一阶段。为一篇核心模糊的论文制定完美时间线毫无意义。
  • 不要脱离用户实际剩余时间,生成通用时间线。
  • 不要列出40项检查清单。用户不会阅读这么多内容。保持就绪检查清单的聚焦性。
  • 不要忘记备选会议。仅瞄准单一会议的计划会让一次拒稿变成一整年的时间损失。