├── LICENSE
├── README-zh.md
└── README.md


/LICENSE:
--------------------------------------------------------------------------------
 1 | MIT License
 2 | 
 3 | Copyright (c) 2025 Yue Zhao
 4 | 
 5 | Permission is hereby granted, free of charge, to any person obtaining a copy
 6 | of this software and associated documentation files (the "Software"), to deal
 7 | in the Software without restriction, including without limitation the rights
 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
 9 | copies of the Software, and to permit persons to whom the Software is
10 | furnished to do so, subject to the following conditions:
11 | 
12 | The above copyright notice and this permission notice shall be included in all
13 | copies or substantial portions of the Software.
14 | 
15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
21 | SOFTWARE.
22 | 


--------------------------------------------------------------------------------
/README-zh.md:
--------------------------------------------------------------------------------
  1 | _本检查表是一份主观性较强但实用的指南，用于检查计算机科学论文（特别是会议和期刊投稿）中的写作质量、结构合理性和内容呈现。尽管部分条目具有主观色彩，但其目标是提供具体提醒并指出常见问题。本项目为持续更新版，欢迎社区反馈与修订。_
  2 | 
  3 | ---
  4 | 
  5 | ## 1. 🎯 标题与摘要
  6 | 
  7 | - [ ] 1.1 标题应不超过 15 个词。避免使用通用短语（如“A Novel Framework...” 这种信息量低的表达）以及过于狭窄的主题（会减少潜在读者），目标是简洁且信息充足。
  8 | - [ ] 1.2 标题应明确体现**问题**和**解决方案**，并包含至少一个技术关键词（如 jailbreak、OOD detection、graph learning）。
  9 | - [ ] 1.3 避免使用冷僻或歧义缩写。LLM、AI、ML 这类缩写在 CS 领域是可以接受的，但 AD（可能是广告或异常检测）这类就应避免。
 10 | - [ ] 1.4 摘要应包含四个核心要素：（1）问题或任务定义，（2）提出的方法或思想，（3）主要结果，（4）广泛意义或影响（部分内容可合并）。
 11 | - [ ] 1.5 摘要避免未定义的缩写，以及模糊的形容词（例如 “important”、 “novel”、 “state-of-the-art” 等不加说明的表述）。
 12 | - [ ] 1.6 附加项：摘要中应至少包含一个具体的、可量化的结果或发现以增强吸引力。例如：“我们的方法在 jailbreak detection 上实现了 11.2 倍推理加速。”
 13 | 
 14 | ---
 15 | 
 16 | ## 2. 📚 引言部分
 17 | 
 18 | - [ ] 2.1 在前两个段落中清楚地定义研究问题或任务。
 19 | - [ ] 2.2 引言应包含真实应用背景或相关工作引用（最好两者都有）。
 20 | - [ ] 2.3 引言结尾简要介绍方法名称及其基本思想。
 21 | - [ ] 2.4 明确列出贡献（如：“(1) 首个框架..., (2) 新数据集..., (3) 大规模实验...”）。
 22 | - [ ] 2.5 每项贡献都应明确、可验证，避免使用“提供见解”、“提升理解”等模糊表述。
 23 | - [ ] 2.6 彩蛋：第一页中包含吸引人的图，如与现有工作的比较、性能亮点或核心思想示意图。
 24 | 
 25 | ---
 26 | 
 27 | ## 3. 🔍 相关工作
 28 | 
 29 | - [ ] 3.1 所有引用的工作都应与本文方法、基线或任务直接相关。
 30 | - [ ] 3.2 至少提及近年被引用次数最多的 3 篇相关论文中的一个作为 baseline。
 31 | - [ ] 3.3 相关工作部分不超过 1.5 页（除非是综述类论文）。
 32 | - [ ] 3.4 可使用 LLM 辅助检索，但所有引用必须手动验证，**切勿盲信 LLM**。
 33 | - [ ] 3.5 彩蛋：使用相关工作部分引出 baseline 算法，结合表格展示新方法的优势。
 34 | 
 35 | ---
 36 | 
 37 | ## 4. 🧪 方法部分
 38 | 
 39 | - [ ] 4.1 所有符号在首次出现时均已定义。
 40 | - [ ] 4.2 所有公式均有正文引用与解释（如 “Eq. (3) 表示...”，若未引用可考虑内联以节省空间）。
 41 | - [ ] 4.3 方法的每个模块或组件都有图示或文字描述。
 42 | - [ ] 4.4 每个小节最好与总览图中的组成部分对应，并在展开前写一个总览段。
 43 | - [ ] 4.5 总览图和伪代码无需都放正文，伪代码建议放附录。
 44 | - [ ] 4.6 本节内容应让审稿人无需查看附录或代码即可理解方法。
 45 | - [ ] 4.7 彩蛋：删除不会影响理解的内容，长数学公式 ≠ 好论文。
 46 | 
 47 | ---
 48 | 
 49 | ## 5. 📊 实验部分
 50 | 
 51 | - [ ] 5.1 使用不少于 3 个数据集（除非文章为新数据集介绍）。
 52 | - [ ] 5.2 比较不少于 3 个 baseline 方法，并说明为什么选这些方法，它们是否是 SOTA。
 53 | - [ ] 5.3 包含至少一个消融实验。
 54 | - [ ] 5.4 在合适情况下报告标准差或置信区间。
 55 | - [ ] 5.5 描述硬件环境、使用的软件库和超参数。
 56 | - [ ] 5.6 不忽略负面结果，失败案例有参考价值。
 57 | - [ ] 5.7 评估指标需定义清晰，并说明合理性。
 58 | - [ ] 5.8 图表在正文中都有引用。
 59 | - [ ] 5.9 除了“数值优于 baseline”，是否有深入分析，如为何方法有效或失败在哪。
 60 | - [ ] 5.10 彩蛋：考虑他人复现难度；若有“trick”应去除。
 61 | 
 62 | ---
 63 | 
 64 | ## 6. 🧾 写作质量与风格
 65 | 
 66 | - [ ] 6.1 所有缩写首次出现时有定义（如 ML、LLM），不重复定义。
 67 | - [ ] 6.2 无长句（>25词）不加逗号或句号。
 68 | - [ ] 6.3 无段落超过 10 行。
 69 | - [ ] 6.4 被动语态比例应低于 30%。
 70 | - [ ] 6.5 彩蛋：检查是否充斥 LLM 风格的华丽词汇（如 encompass, intricate 等）。
 71 | 
 72 | ---
 73 | 
 74 | ## 7. 🖼️ 图表部分
 75 | 
 76 | - [ ] 7.1 所有图表标题 ≥ 2 行，并包含解释内容；避免无说明地插图。
 77 | - [ ] 7.2 图中文字大小 ≥ 8pt，标签清晰不被裁剪。
 78 | - [ ] 7.3 所有配色在灰阶打印下依旧可辨别（部分审稿人会打印论文）。
 79 | - [ ] 7.4 所有方法都在图例或表格中标明。
 80 | - [ ] 7.5 图表优先放页面顶部（非硬性要求，但更清晰）。
 81 | - [ ] 7.6 无冗余图表，每张图都提供新信息。
 82 | - [ ] 彩蛋：图表为无损格式（如 PDF），**严禁使用低分辨率图片**。
 83 | 
 84 | ---
 85 | 
 86 | ## 8. 🧱 结构与排版
 87 | 
 88 | - [ ] 8.1 无 LaTeX 警告或 bad boxes。
 89 | - [ ] 8.2 小节标题符合论文结构（如 Introduction, Method, Experiments 等）。
 90 | - [ ] 8.3 正文中需明确引用附录具体章节（如 “见 Appendix B.2”）。
 91 | - [ ] 8.4 全文不得出现孤立行（orphan line），即段首或段尾仅一行。
 92 | - [ ] 8.5 不连续堆叠多个图表，中间必须有解释文字。
 93 | 
 94 | ---
 95 | 
 96 | ## 9. 📎 参考文献
 97 | 
 98 | - [ ] 9.1 引用格式符合目标会议或期刊要求。
 99 | - [ ] 9.2 所使用的数据集、工具包、模型等均已引用。
100 | - [ ] 9.3 至少引用一篇目标会议/期刊的文章。
101 | - [ ] 9.4 自引比例 ≤ 20%。
102 | - [ ] 9.5 BibTeX 已去重并检查拼写错误。
103 | 
104 | ---
105 | 
106 | ## 10. 🛑 引用真实性检查（避免 LLM 幻觉）
107 | 
108 | - [ ] 10.1 所有引用已手动验证其真实存在，标题、作者、会议与年份均匹配。
109 | - [ ] 10.2 不包含由 LLM 虚构的引用。
110 | - [ ] 10.3 若由 ChatGPT、Copilot 等生成引用，需在 Google Scholar 或 Semantic Scholar 等站点交叉验证。
111 | 
112 | ---
113 | 
114 | ## 11. 🧠 提交前的最终检查
115 | 
116 | - [ ] 11.1 PDF 可在 Overleaf/本地无警告编译。
117 | - [ ] 11.2 文件命名符合投稿要求（匿名时不可包含作者信息）。
118 | - [ ] 11.3 无任何泄露作者身份的信息（如元数据、文件名、代码注释）。
119 | - [ ] 11.4 论文总长度（包括参考文献与附录）不超过页数限制。
120 | - [ ] 11.5 论文已由非作者完整阅读一遍，且无需中途停顿查阅。
121 | - [ ] 11.6 所有合作者已列出，避免遗漏作者（真实案例屡见不鲜）。
122 | - [ ] 11.7 彩蛋：提交后，换设备换系统（如 Windows/Mac）登录检查论文显示是否正常。
123 | 
124 | ---
125 | 
126 | _本项目属于 [`cs-paper-checklist`](https://github.com/yzhao062/cs-paper-checklist)。欢迎通过 PR 提出修改建议。_
127 | 


--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
  1 | _This checklist is a practical, opinionated guide for sanity-checking the writing quality, structure, and presentation of CS papers—especially for conference (and journal) submissions. While some items are subjective, the goal is to provide concrete reminders and highlight common pitfalls. It is a living document and will continue to be updated based on feedback._
  2 | 
  3 | ---
  4 | 
  5 | ## 1. 🎯 Title and Abstract
  6 | 
  7 | - [ ] 1.1 Title is ≤ 15 words. Check for generic phrasing (e.g., “A Novel Framework...,” which conveys little information) and overly narrow focus (which may reduce the paper’s audience)—aim for concise but informative.
  8 | - [ ] 1.2 Title clearly reflects both the **problem** and the **solution**, and includes at least one technical keyword (e.g., jailbreak, OOD detection, graph learning).
  9 | - [ ] 1.3 Title avoids rare or ambiguous abbreviations. Terms like LLM, AI, and ML are acceptable in CS venues, but avoid abbreviations like AD (which could refer to advertisement or anomaly detection).
 10 | - [ ] 1.4 Abstract includes at least four key components: (1) problem/task definition, (2) proposed method or idea, (3) main results, and (4) broader impact or significance (some may be combined).
 11 | - [ ] 1.5 Abstract avoids undefined abbreviations and vague descriptors (e.g., “important,” “novel,” “state-of-the-art” without context).
 12 | - [ ] 1.6 Bonus: Abstract includes at least one concrete, quantitative result or insight to make the work stand out. For instance, “our method achieves 11.2× acceleration in test-time inference for jailbreak detection.”
 13 | 
 14 | 
 15 | ---
 16 | 
 17 | ## 2. 📚 Introduction
 18 | 
 19 | - [ ] 2.1 The main problem or task is clearly defined within the first two paragraphs.
 20 | - [ ] 2.2 Motivation includes either (a) real-world use cases or (b) citations to prior work—ideally both.
 21 | - [ ] 2.3 The introduction ends with a brief overview of the proposed method and its name.
 22 | - [ ] 2.4 Contributions are explicitly itemized (e.g., “(1) first framework for ..., (2) new dataset for ..., (3) extensive evaluation on ...”).
 23 | - [ ] 2.5 Each contribution is specific and verifiable—avoid vague claims such as “we provide insights” or “we improve understanding.”
 24 | - [ ] 2.6 Bonus: Include a compelling figure on the first page—e.g., comparison to prior work, performance highlight, or visual explanation of the core idea.
 25 | 
 26 | 
 27 | 
 28 | 
 29 | ---
 30 | 
 31 | ## 3. 🔍 Related Work
 32 | 
 33 | - [ ] 3.1 All cited works are connected to your method, baseline, or task.
 34 | - [ ] 3.2 At least one baseline from the top-3 most cited recent papers on the topic is mentioned.
 35 | - [ ] 3.3 Related work does not exceed 1.5 pages (unless survey-style paper).
 36 | - [ ] 3.4 You may use LLMs for searching the related work, but double triple check each of the paper -- do not trust LLMs!!!!
 37 | - [ ] 3.5 Bonus: use related work section to introduce baseline algorithms -- show a table for your proposal better than the existing ones
 38 | 
 39 | 
 40 | 
 41 | 
 42 | ---
 43 | 
 44 | ## 4. 🧪 Method
 45 | 
 46 | - [ ] 4.1 All symbols are defined before use.
 47 | - [ ] 4.2 Each equation is referenced with inline explanation (e.g., “Eq. (3) defines the loss over…”). If an equation is never referenced, consider making it inline to save space.
 48 | - [ ] 4.3 All modules or components of the method are illustrated or described in text or figures.
 49 | - [ ] 4.4 Each subsection ideally aligns with parts of the overview figure. Add a short summary paragraph before diving into subsections.
 50 | - [ ] 4.5 You do not need both overview figure and pseudo code in the main text -- move the pseudo code to the appendix
 51 | - [ ] 4.6 The method is reproducible without referring to the appendix or external code—reviewers should understand everything from the main text.
 52 | - [ ] 4.7 Bonus: Can anything be removed from this section without reducing clarity? Do not hesitate to cut: more math ≠ better paper.
 53 | 
 54 | 
 55 | 
 56 | 
 57 | ---
 58 | 
 59 | ## 5. 📊 Experiments
 60 | 
 61 | - [ ] 5.1 At least 3 datasets are used (unless the paper introduces a new dataset).
 62 | - [ ] 5.2 At least 3 baseline methods are compared. Are they state-of-the-art? Justify why these baselines are chosen.
 63 | - [ ] 5.3 At least 1 ablation study is included.
 64 | - [ ] 5.4 Standard deviation or confidence intervals are reported where appropriate.
 65 | - [ ] 5.5 Hardware environment, software libraries, and hyperparameter settings are described.
 66 | - [ ] 5.6 Negative results (if any) are explained, not omitted—failure cases are valuable.
 67 | - [ ] 5.7 Evaluation metrics are clearly defined and justified.
 68 | - [ ] 5.8 All figures and tables are referenced in the main text.
 69 | - [ ] 5.9 Beyond showing numbers and saying “we perform well,” at least one deeper insight or analysis is provided (e.g., why it works, where it fails).
 70 | - [ ] 5.10 Bonus: Think about how easy others can reproduce your work? If you have any "dirty tricks" -- remove them pls.
 71 | 
 72 | 
 73 | 
 74 | 
 75 | 
 76 | ---
 77 | 
 78 | ## 6. 🧾 Writing Quality and Style
 79 | 
 80 | - [ ] 6.1 All abbreviations are defined at first use (even ML, LLM, etc.) -- do not redefine them again and again.
 81 | - [ ] 6.2 No sentence exceeds 25 words without a comma or period.
 82 | - [ ] 6.3 No paragraph exceeds 10 lines.
 83 | - [ ] 6.4 Passive voice usage < 30% of the total number of sentences.
 84 | - [ ] 6.5 Bonus: Have you noticed that your paper are full of the fancy LLM words, like encompass, intricate, etc?
 85 | 
 86 | 
 87 | 
 88 | 
 89 | ---
 90 | 
 91 | ## 7. 🖼️ Figures and Tables
 92 | 
 93 | - [ ] 7.1 Each figure/table has a caption ≥ 2 lines that includes interpretation or context. Do not just place it without explanation—reviewers will get lost.
 94 | - [ ] 7.2 Font size in all figures is ≥ 8pt and all labels are fully visible (not cropped).
 95 | - [ ] 7.3 Plots use colors that remain distinguishable when printed in grayscale—some reviewers will print your paper.
 96 | - [ ] 7.4 Each method mentioned in the results appears in either the legend or table column headers.
 97 | - [ ] 7.5 Figures appear at the top of pages rather than mid-text or at the bottom (soft rule, but improves readability).
 98 | - [ ] 7.6 Figures and tables are not redundant—each provides new or complementary information.
 99 | - [ ] Bonus: All figures are in **lossless formats** (e.g., PDF for vector graphics). Absolutely no low-resolution images allowed.
100 | 
101 | 
102 | 
103 | 
104 | 
105 | ---
106 | 
107 | ## 8. 🧱 Structure and Formatting
108 | 
109 | - [ ] 8.1 All LaTeX warnings and bad boxes have been resolved.
110 | - [ ] 8.2 Section headers follow the standard paper structure (e.g., Introduction, Method, Experiments, etc.).
111 | - [ ] 8.3 All appendix sections are explicitly referenced in the main text (e.g., “Appendix B.2 shows…”).
112 | - [ ] 8.4 No **orphan lines** anywhere in the paper—avoid single-line section headers or short lines at the top/bottom of columns.
113 | - [ ] 8.5 No two figures or tables are placed consecutively without explanatory text between them.
114 | 
115 | 
116 | 
117 | 
118 | ---
119 | 
120 | ## 9. 📎 References
121 | 
122 | - [ ] 9.1 All references are in the correct format for the target venue.
123 | - [ ] 9.2 All datasets, toolkits, and models used are cited.
124 | - [ ] 9.3 At least one paper from the target venue (conference/journal) is cited.
125 | - [ ] 9.4 Self-citations ≤ 20% of total citations.
126 | - [ ] 9.5 BibTeX file has been deduplicated and spell-checked.
127 | 
128 | 
129 | 
130 | 
131 | ---
132 | 
133 | ## 10. 🛑 Citation Sanity Check (LLM-Generated Risk)
134 | 
135 | - [ ] 10.1 All citations were **manually verified to exist**—title, authors, venue, and year match a real, published paper.
136 | - [ ] 10.2 No hallucinated references from LLM tools are included.
137 | - [ ] 10.3 If a citation was generated by ChatGPT, Copilot, or similar, it has been cross-checked on **Google Scholar**, **Semantic Scholar**, or publisher sites.
138 | 
139 | 
140 | 
141 | 
142 | ---
143 | 
144 | ## 11. 🧠 Sanity Checks Before Submission
145 | 
146 | - [ ] 11.1 PDF compiles in Overleaf/TeX with no errors or bad boxes.
147 | - [ ] 11.2 File name follows the submission guideline format (e.g., no underscores or author names if anonymized).
148 | - [ ] 11.3 No author-identifying information exists in metadata, supplementary files, or file names. Check your code repository and images too.
149 | - [ ] 11.4 The paper length complies with the page limit, including references and appendices (if counted).
150 | - [ ] 11.5 The paper has been read start-to-finish by someone not on the author list, without them needing to stop for clarification.
151 | - [ ] 11.6 All co-authors are listed and properly acknowledged—this is surprisingly often overlooked.
152 | - [ ] 11.7 Bonus: After submission, log in from a different device and OS (e.g., Mac, Windows) to verify that the uploaded version renders correctly.
153 | 
154 | 
155 | ---
156 | 
157 | _This checklist is part of the [`cs-paper-checklist`](https://github.com/yzhao062/cs-paper-checklist) project. Contributions welcome via PR._
158 | 
159 | ---
160 | 


--------------------------------------------------------------------------------