IEEE 论文最难的不是润色英文，而是让审稿人相信你的证据链 - 日日和的文章 - 知乎
https://zhuanlan.zhihu.com/p/2061193970449921615

作者实现了一个

ieee-skills

GitHub：

<a href='https://github.com/CloudWave818/ieee-skills' class='card-link'>ieee-skills.git</a>

一句话介绍：

普通润色工具帮你改句子，ieee-skills 更关心 IEEE 审稿人会不会买账。

为什么要做这个？

因为我发现 IEEE 论文写作里，很多问题不是“英文不够漂亮”，而是论文没有把工程证据链讲清楚。

很多文章看起来什么都有：

有方法 有实验 有图表 有 Related Work 有 conclusion

但审稿人还是会问：

你到底解决了什么工程问题？ 这个问题在哪个工况下严重？ 为什么你的方法适合这个系统？ 实验有没有证明你的 claim？ baseline 选得公平吗？ 图表双栏缩放后还能看清吗？ 复杂度、延迟、鲁棒性有没有交代？

这些问题，普通润色工具很难真正帮你检查。

我理解的 IEEE 论文核心逻辑

IEEE 论文和普通“写得像论文”的文本不太一样。

它更看重工程对象、工况约束、方法依据和实验验证之间的闭环。

我把它概括成一条链：

对象 -> 工况/约束 -> 工程危害 -> 现有方法局限 -> 方法依据 -> 实验证据

也就是说，一篇 IEEE 风格论文最好能回答清楚：

研究对象是什么？ 在什么工况下有问题？ 这个问题有什么工程危害？ 现有方法为什么不够？ 为什么你的方法适合？ 哪些实验能证明你说的是对的？

如果这条链断了，就很容易出现这些审稿意见：

The motivation is not sufficiently clear. The novelty is incremental. The experiments are insufficient. The comparison is not convincing. The presentation should be improved.

这些话是不是很眼熟。

ieee-skills 是干什么的

ieee-skills 是一组面向 IEEE 论文工作流的 Codex Skills。

目前包含 9 个：

ieee-writing
ieee-polishing
ieee-reviewer
ieee-experiment
ieee-figure-table
ieee-response
ieee-latex
ieee-citation
ieee-paper-reader

它不是单纯帮你“润色英文”，而是按 IEEE 论文的实际流程来拆问题。

1. 写作：别只写“提出了一种新方法”

很多摘要和引言的问题是太泛。

比如：

In this paper, we propose a novel method...

这句话本身没错，但审稿人更想知道：

对象是什么？
工况是什么？
问题为什么重要？
你的方法解决了什么具体限制？

所以 ieee-writing 更强调：

对象 + 方法 + 工况 + 证据

可以这样用：

Use $ieee-writing 把我的问题背景和贡献点改成 IEEE 风格 introduction。

2. 润色：不是把句子改高级，而是别夸大 claim

很多论文润色后句子是顺了，但 claim 变大了。

比如：

significantly outperforms
highly robust
efficient and effective

这些词如果没有实验支撑，反而容易被审稿人抓住。

ieee-polishing 会更关注：

有没有空泛表达
claim 有没有过大
方法优势有没有限定工况
结果描述有没有证据

可以这样用：

Use $ieee-polishing 润色这段摘要，但不要夸大 claim。

3. 预审：先让它像 IEEE 审稿人一样挑刺

自己看自己的论文，很容易自动脑补。

但审稿人不会帮你脑补。

ieee-reviewer 可以从 IEEE 审稿人的角度看：

scope 是否合适
novelty 是否清楚
方法依据是否充分
实验是否支撑 claim
baseline 是否公平
图表是否专业
格式和表达是否有风险

可以这样用：

Use $ieee-reviewer 把我的论文当成 IEEE Transactions 审稿人预审一遍。

4. 实验：实验多，不等于实验够

这是 IEEE 论文里非常常见的问题。

作者做了很多实验，但审稿人还是说：

The experiments are insufficient.

原因往往不是实验数量少，而是实验和 claim 没对上。

比如你说：

方法更鲁棒
方法复杂度更低
方法适合实时部署
方法泛化能力更好
每个模块都有贡献

那就应该有对应实验：

robustness test
runtime / complexity analysis
cross-condition validation
ablation study
baseline comparison

ieee-experiment 会帮你做 claim-evidence matrix。

可以这样用：

Use $ieee-experiment 检查我的实验是否支撑摘要里的 claim。

5. 图表：IEEE 图表是证据，不是装饰

很多人低估了图表第一印象。

审稿人打开 PDF，通常会先扫：

标题
摘要
图表
实验表格

如果图表出现这些问题：

字体太小
图例遮挡
坐标轴没单位
线条重叠
双栏缩放后看不清
caption 只描述现象，不说结论

第一印象会很吃亏。

所以我重点升级了 ieee-figure-table。

它现在不只是审图，还能做 IEEE 风格图表重画和示例生成。

比如这几个典型图：

SNR 鲁棒性曲线
Accuracy-latency Pareto 图
消融实验表

它们分别回答：

低信噪比下还稳不稳？
精度高的同时能不能部署？
每个模块到底有没有贡献？

可以这样用：

Use $ieee-figure-table 看看这张图双栏缩放后会不会被审稿人嫌弃。

6. 返修：不要只解释，要给修改和证据

很多 rebuttal 或 revision response 的问题是：

我们认为...
实际上我们已经...
原文中已有说明...

但审稿人真正想看到的是：

你改了哪里？
补了什么实验？
新结果是什么？
论文哪一页哪一行？

比较稳的回复结构是：

感谢意见 -> 修改动作 -> 新证据 -> 稿件位置

ieee-response 就是按这个思路来组织回复。

可以这样用：

Use $ieee-response 按“修改动作 + 新证据 + 稿件位置”回复这些审稿意见。

这个项目适合谁

我觉得它比较适合这些场景：

正在写 IEEE conference / journal / Transactions / Letters
摘要和引言总是写得很泛
实验很多但不知道够不够
投稿前想模拟审稿
图表总觉得不像正式论文
返修时不知道怎么回复审稿人
LaTeX 和 BibTeX 经常出问题
想精读 IEEE 论文并提取写法

它不是“用了就能中”的工具，也不能替代导师、合作者和目标期刊要求。

但它可以帮你在投稿前多问几遍：

我的对象、方法、工况讲清楚了吗？
我的实验真的证明了 claim 吗？
我的 baseline 有说服力吗？
我的图表双栏缩放后还能读吗？
我的审稿回复有没有给出具体修改和证据？

这些问题提前解决，论文会稳很多。

开源地址

GitHub：

https://github.com/CloudWave818/ieee-skills

项目页：

https://cloudwave818.github.io/ieee-skills/

这是一个非官方项目，不属于 IEEE，也不代表 IEEE 官方意见。使用时仍然要以目标期刊、会议、Transactions 或 Letters 的最新 author instructions 为准。

后面我会继续补充 IEEE 写作、实验设计、图表、LaTeX、引用和审稿回复方面的规则。如果你也在写 IEEE 论文，欢迎试用，也欢迎提 issue 一起完善。