引言部分写作
客观的
构建面向审稿人的漏斗：有意义的任务 -> 未实现的目标或失败案例 -> 根本技术瓶颈 -> 提出的解决方案 -> 为什么有效 -> 证据和贡献。
向后规划问题
在写作之前先回答这些问题：
- 解决了什么技术问题，为什么没有既定的解决方案？
- 到底什么是新的：任务、指标、管道、模块、设计选择、发现或洞察？
- 为什么这个贡献要解决瓶颈？
- 后来哪些实验或分析支持主要承诺？
前部角色
| 角色 | 所需内容 | 故障信号 |
|---|---|---|
| 任务/申请开放 | 定义任务或应用程序价值和目标要求 | 以一般重要性打开，但没有任务边界 |
| 先前工作限制 | 按机制和局限性总结代表性方法 | 无技术原因的逐篇论文列表 |
| 技术瓶颈 | 陈述未解决的挑战和根本原因 | 差距是一种营销主张，而不是一种机制 |
| 建议的解决方案 | 通过图形锚点（如果存在）介绍管道或关键见解 | 方法在挑战明确之前出现 |
| 为什么它有效 | 用有限的术语解释技术优势 | 声称新颖但没有机制 |
| 证据/贡献 | 预览实验并列举贡献 | 贡献不会映射到后来的证据 |
介绍模式
使用一种与论文匹配的图案：
- 任务优先：针对利基任务；在应用程序之前定义输入/输出。
- 先应用：用于熟悉的任务；打开用例和目标要求。
- 一般到具体：用于熟悉区域内的新设置。
- 带着挑战开始：当未解决的失败案例可以立即理解时。
反模式
不要将故事写成“存在一个幼稚的基线，然后我们修补它”。这使得贡献看起来很明显。相反，解释先前的方法系列仍然无法解决的真正技术瓶颈。
声明-证据结案
每个贡献句都应该向前映射：
text
Intro promise -> Method mechanism -> Experiment evidence -> Conclusion answer如果贡献没有相应的实验或分析，要么标记缺失的证据，要么削弱主张。