重要前提
安装AI Skills的关键前提是:必须科学上网,且开启TUN模式,这一点至关重要,直接决定安装能否顺利完成,在此郑重提醒三遍:科学上网,科学上网,科学上网。查看完整安装教程 →
paper-rebuttal by evoscientist/evoskills
npx skills add https://github.com/evoscientist/evoskills --skill paper-rebuttal收到同行评审反馈后撰写回复的系统性方法。目标不是为每一点辩护——而是通过解决真正影响分数的关切来提升分数。
如需进行提交前的自我审阅,并在问题成为审稿人意见前发现弱点,请使用
paper-review技能。
在写下第一个字之前,先回答:"为什么这位审稿人给出这个确切的分数?" 不是他们写了什么——而是驱动分数的原因。大多数研究人员会跳过这一步,平等地回应每一条意见。这是一个错误。
对于每位审稿人,问:"什么能促使这位审稿人从当前分数转向接受?"
| 分数范围 | 典型情况 | 你的策略 |
|---|---|---|
| 7+ | 已经是你的支持者 | 为他们提供讨论阶段的"弹药" |
| 5-6 | 处于摇摆状态,有1-2个顾虑阻碍他们 | 识别并解决这些特定的顾虑 |
| 3-4 | 根本性反对 | 判断该反对意见是否可解决;如果不能,则专注于其他地方 |
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
通读每份审稿意见,并为每条评论标注颜色:
| 颜色 | 含义 | 行动 | 预算 |
|---|---|---|---|
| 红色 | 驱动分数的关切——这是分数低的原因 | 优先处理,投入最大努力和证据 | 60% |
| 橙色 | 可解决的关切——可以处理 | 用具体数据或修订来回应 | 30% |
| 灰色 | 次要或表面问题 | 简要承认,确认已修复 | 10% |
| 绿色 | 正面评价或赞扬 | 记录下来,作为支持者的"弹药" | — |
每一条审稿人意见背后都有一个未言明的问题。像"基线方法过时了"这样的评论,真正想问的是:"这个方法与当前方法相比真的具有竞争力吗?" 要解决隐含的问题,而不仅仅是表面的要求。
| 类别 | 回应策略 |
|---|---|
| 误解 | 通过具体引用论文来澄清;重述关键点 |
| 缺少实验 | 如果可行,在回复中提供该实验;否则诚实地解释限制 |
| 缺少基线 | 添加比较,或精确解释为何该基线不适用 |
| 写作清晰度 | 承认并提供修订后的文本 |
| 根本性关切 | 用技术论证和额外证据直接回应 |
| 次要问题 | 感谢审稿人并确认已修复 |
如果多位审稿人提出相同的关切,这几乎肯定是一个真正的弱点。将这些整合到一个"共同回应"部分——这可以节省字数,并表明你理解了其中的模式。
你回复的真正受众不是持负面意见的审稿人——而是持正面意见的那位。
你的支持者会在AC讨论中为你辩护,通常会使用你的原话。撰写回复时要武装他们:
完整的18条战术规则请参见 references/rebuttal-tactics.md。
针对每个关切点,遵循这个三部分结构:
可在 assets/rebuttal-template.md 使用可填写的模板。
提交前,找一个没读过你论文的人,只阅读审稿意见和你的回复。问:"你能看出这些关切是否得到了解决吗?" 如果不能,就重写。
即使分数极端,也要提交回复。 一份分数为3/8/8的论文,其机会比你想象的要大。在讨论过程中,持负面意见的审稿人可能会意识到自己是少数派。但前提是你提交了回复——没有回复,AC就无从着手。
在小处让步,在大处获胜。 承认一个次要弱点("我们同意表2可以为了完整性而包含数据集X")会使你对主要观点的辩护更具可信度。零让步的纯粹辩护读起来会显得不客观。
一个新实验胜过三段解释。 审稿人被训练得对论证持怀疑态度。他们没有被训练得对数据持怀疑态度。一个直接解决关切的小型新实验,其价值超过任何数量的推理。
最好的回复是在提交前就写好的。 在撰写论文时,就草拟对可能攻击的回应("预反驳")。有两个好处:你常常会意识到攻击是有效的并修改论文;如果攻击真的来了,你已经有了一个现成的、打磨好的回应。
不要平等地为每一点辩护。 平均分配精力表明你不知道哪些点重要。根据颜色标注来分配你的字数预算:红色60%,橙色30%,灰色10%。当你处理好大问题时,审稿人会注意到。
为这些频繁出现的关切准备好回应。有准备好的回应并不意味着逐字照抄——要根据你的具体论文和审稿人的具体表述进行调整。
| 常见关切 | 回应策略 |
|---|---|
| "新颖性有限" | 阐明具体的见解;展示先前工作无法做到的地方;缩小并强化你的主张 |
| "改进幅度小" | 强调其他优势(速度、泛化性、简洁性);添加具有挑战性的测试案例 |
| "缺少消融实验" | 在回复中提供消融实验表格 |
| "缺少基线" | 添加比较,或精确解释为何不适用 |
| "不可复现" | 添加实现细节;承诺在特定时间线内发布代码 |
| "评估有限" | 添加多样化的数据集或指标;如果不可行,诚实地解释资源限制 |
| "未讨论局限性" | 在修订版中添加局限性部分;承认这是疏忽 |
| "结果夸大" | 弱化具体主张以匹配证据;展示修订后的措辞 |
| "不公平比较" | 使用标准评估协议;添加通常报告的基线 |
| "方法是工程,不是研究" | 指出设计背后的科学见解;解释为何该选择并非显而易见 |
| "指标与主张不匹配" | 将每个主张与特定指标对齐;如果可行,添加缺失的指标 |
| "相关工作不完整" | 添加缺失的参考文献;解释其与你的工作的关系 |
需要为回复运行新实验吗? 使用
experiment-craft技能进行针对性调试,或使用experiment-pipeline进行完整的新实验阶段。
此技能承接 paper-review 结束后的工作。如果你在提交前使用了 paper-review,以下产物对回复尤其有用:
| 来自 paper-review 的产物 | 如何帮助回复 |
|---|---|
| 拒绝优先模拟 | 你已经预见到了可能的攻击 |
| 主张-证据审核表 | 快速验证审稿人对无证据支持的主张的关切是否有效 |
| 预反驳草稿(第6阶段) | 针对常见批评的现成回应模板 |
| 信任度计分卡 | 识别你可以主动承认的弱点 |
| 主题 | 参考文件 | 何时使用 |
|---|---|---|
| 18条战术规则 | rebuttal-tactics.md | 关于结构、内容、语气的详细写作指导 |
| 回复模板 | rebuttal-template.md | 开始撰写新的回复文档 |
每周安装次数
63
仓库
GitHub 星标数
105
首次出现
10 天前
安全审计
安装于
cline63
gemini-cli63
kimi-cli63
codex63
cursor63
opencode63
A systematic approach to writing rebuttals after receiving peer review feedback. The goal is not to defend every point — it's to move scores by addressing the concerns that actually drive them.
For pre-submission self-review and catching weaknesses before they become reviewer complaints, use the
paper-reviewskill.
Before writing a single word, answer: "Why did this reviewer give this exact score?" Not what they wrote — what drove the score. Most researchers skip this and address every comment equally. That is a mistake.
For each reviewer, ask: "What would move this reviewer from their current score to acceptance?"
| Score Range | Typical Situation | Your Strategy |
|---|---|---|
| 7+ | Already your champion | Arm them with ammunition for the discussion phase |
| 5-6 | On the fence, 1-2 concerns holding them back | Identify and resolve those specific concerns |
| 3-4 | Fundamental objection | Determine if the objection is addressable; if not, focus elsewhere |
Read through each review and mark every comment:
| Color | Meaning | Action | Budget |
|---|---|---|---|
| Red | Score-driving concern — this is why the score is low | Address first, maximum effort and evidence | 60% |
| Orange | Addressable concern — can be resolved | Respond with concrete data or revision | 30% |
| Gray | Minor or cosmetic | Acknowledge briefly, confirm fix | 10% |
| Green | Positive comment or praise | Note as ammunition for your champion | — |
Behind every reviewer comment is an unspoken question. A comment like "The baselines are outdated" really asks: "Is this method actually competitive with current approaches?" Address the invisible question, not just the surface request.
| Category | Response Strategy |
|---|---|
| Misunderstanding | Clarify with specific references to the paper; restate the key point |
| Missing experiment | Provide the experiment inline if feasible; otherwise explain constraints honestly |
| Missing baseline | Add comparison or explain precisely why the baseline is not applicable |
| Writing clarity | Acknowledge and provide revised text in the rebuttal |
| Fundamental concern | Address directly with technical arguments AND additional evidence |
| Minor issue | Thank the reviewer and confirm the fix |
If multiple reviewers raise the same concern, it's almost certainly a real weakness. Consolidate these into a "Common Response" section — this saves word count and demonstrates that you understand the pattern.
Your rebuttal's real audience is not the negative reviewer — it's the positive one.
Your champion argues on your behalf in the AC discussion, often using your exact words. Write your rebuttal to arm them:
See references/rebuttal-tactics.md for the full 18 tactical rules.
For each concern, follow this three-part structure:
Use a fillable template at assets/rebuttal-template.md.
Before submitting, have someone who hasn't read your paper read only the reviews and your rebuttal. Ask: "Can you tell whether the concerns were addressed?" If not, rewrite.
Submit a rebuttal even with extreme scores. A paper with scores of 3/8/8 has better odds than you think. The negative reviewer may realize they are an outlier during discussion. But only if you submit a rebuttal — without one, the AC has nothing to work with.
Concede something small, win something big. Acknowledging a minor weakness ("We agree that Table 2 could include dataset X for completeness") makes your defense of major points more credible. Pure defense with zero concession reads as unobjective.
One new experiment beats three paragraphs of explanation. Reviewers are trained to be skeptical of arguments. They are not trained to be skeptical of data. A small new experiment that directly addresses a concern is worth more than any amount of reasoning.
The best rebuttal is written before submission. Draft responses to likely attacks while writing the paper ("prebuttal"). Two benefits: you often realize the attack is valid and fix the paper, and if the attack comes, you have a polished response ready.
Don't defend every point equally. Equal effort signals you don't know which points matter. Allocate your word budget according to the color-coding: 60% red, 30% orange, 10% gray. Reviewers notice when you nail the big issues.
Prepare responses for these frequent concerns. Having a prepared response doesn't mean copying it verbatim — adapt to your specific paper and the reviewer's specific framing.
| Common Concern | Response Strategy |
|---|---|
| "Limited novelty" | Articulate the specific insight; show what prior work cannot do; narrow and sharpen the claim |
| "Marginal improvement" | Emphasize other advantages (speed, generalizability, simplicity); add challenging test cases |
| "Missing ablations" | Provide the ablation table inline in the rebuttal |
| "Missing baselines" | Add the comparison or explain precisely why it's not applicable |
| "Not reproducible" | Add implementation details; commit to code release with a specific timeline |
| "Limited evaluation" | Add diverse datasets or metrics; if infeasible, explain resource constraints honestly |
| "No limitation discussed" | Add a limitation section in the revision; acknowledge this was an oversight |
| "Overclaimed results" | Weaken specific claims to match evidence; show the revised wording |
| "Unfair comparison" | Use standard evaluation protocols; add commonly reported baselines |
| "Method is engineering, not research" | Identify the scientific insight behind the design; explain why the choice is non-obvious |
| "Metrics don't match claims" |
Need to run new experiments for the rebuttal? Use the
experiment-craftskill for targeted debugging, orexperiment-pipelinefor a full new experiment stage.
This skill picks up where paper-review leaves off. If you used paper-review before submission, these artifacts are especially useful for rebuttal:
| Artifact from paper-review | How It Helps Rebuttal |
|---|---|
| Reject-first simulation | You've already anticipated likely attacks |
| Claim-evidence audit table | Quickly verify whether a reviewer's concern about unsupported claims is valid |
| Prebuttal drafts (Phase 6) | Ready-made response templates for common criticisms |
| Trust scorecard | Identifies weaknesses you can proactively concede |
| Topic | Reference File | When to Use |
|---|---|---|
| 18 tactical rules | rebuttal-tactics.md | Detailed writing guidance for structure, content, tone |
| Rebuttal template | rebuttal-template.md | Starting a new rebuttal document |
Weekly Installs
63
Repository
GitHub Stars
105
First Seen
10 days ago
Security Audits
Gen Agent Trust HubPassSocketPassSnykPass
Installed on
cline63
gemini-cli63
kimi-cli63
codex63
cursor63
opencode63
实验恢复工具:自动恢复暂停的AI研究实验,从断点继续优化
472 周安装
| Align each claim with a specific metric; add the missing metric if feasible |
| "Related work incomplete" | Add the missing references; explain the relationship to your work |