工科论文写作逻辑与流程
前言
最近在做烟雾分割相关实验和读文献时，越来越觉得：一篇能中、能留住的工科论文，往往不是「方法堆叠」写得好，而是「问题链条」讲得通。 方法可以换 backbone、换 loss、换训练 trick，但审稿人真正关心的是：你到底在解决什么、为什么现有工作还不够、你的设计是不是冲着这个缺口去的。
这篇文章不是通用写作课笔记，而是结合计算机视觉 → 语义分割 → 烟雾分割这条线，把自己近期梳理的一套问题驱动写作逻辑记下来，方便以后开新课题、改稿子、和导师对齐 story 时对照使用。
一、核心观念：优秀论文 = 问题驱动，而不是模块驱动
在烟雾分割这类目标形态不规则、边界模糊、占比极小、场景跨度大的任务里，很容易出现一种写法：
我们把 XXX 模块嵌进 YYY 网络，在 ZZZ 数据集上 mIoU 提升了 1.2%。
这种写法的问题在于：审稿人读完不知道——这 1.2% 对应的是哪一个未被解决的痛点？ 是漏检？是误检云和雾？是半透明边缘糊掉？还是视频帧间闪烁？
我更倾向把论文的主线收成下面这条链（也是下文各节的骨架）：
1 | flowchart LR |
方法只是链条末端的一环；问题才是开头。
二、从「现场困境」到「论文问题」：逐步拆解
1. 烟雾分割在实际里到底难在哪？
先脱离网络结构，用应用/数据的语言把困境说清楚。例如（可按自己数据集与场景增删）：
| 困境类型 | 典型表现 | 若写进论文，审稿人关心的点 |
|---|---|---|
| 形态与边界 | 烟雾半透明、边缘渐变，没有清晰闭合轮廓 | 像素级 GT 本身是否可靠？边界错 1 像素算不算错？ |
| 尺度与占比 | 早期烟雾面积极小，远景几乎几个像素 | 全局 mIoU 是否掩盖「检出率」？小目标是否被背景淹没？ |
| 外观混淆 | 云、雾、扬尘、反光、水蒸气与烟雾相似 | 方法是在「分割烟雾」还是在「分割浅色絮状物」？ |
| 成像条件 | 低照度、逆光、运动模糊、压缩噪声 | 是否只在理想光照下有效？ |
| 时序与部署 | 视频闪烁、延迟要求、边缘端算力 | 单帧 SOTA 是否等于系统可用？ |
个人体会： 真正值得写进 Introduction 的，往往是「不解决就会导致系统失败」的那几条（例如早期预警漏检、误报导致频繁撤离），而不是「分割很难」这种泛泛而谈。
2. 技术上怎么定义与描述这个问题？
同一条困境，要翻译成 CV 社区能对齐的任务表述，通常包括：
- 任务形式：语义分割 / 实例分割 / 显著性 / 视频一致分割 / 弱监督 / 开集？
- 输入输出：RGB、RGB-T、多帧？输出概率图还是二值 mask？
- 评价协议：数据集划分、阈值、是否 image-level 平均、是否只报 smoke 类 IoU（我在语义分割评价指标一文里写过，烟雾场景下指标设计本身也是问题的一部分）。
- 失败模式：用 2～3 类典型 error case 命名（under-segmentation、false alarm on cloud、temporal flicker…），后文实验和图都围绕它们展开。
定义清楚的好处是：Related Work 和 Method 都在回答同一个形式化问题，而不是各说各话。
3. 有没有现有研究？缺陷是什么？
文献调研的目标不是「堆引用」，而是填一张表：
| 路线 | 代表思路 | 对烟雾困境的覆盖 | 仍存在的缺陷（要写具体） |
|---|---|---|---|
| 通用语义分割 | FCN / DeepLab / SegFormer … | 强 baseline | 未针对极小目标、半透明边界优化 |
| 小目标 / 不平衡 | 重采样、Focal、OHEM … | 缓解一部分 | 可能牺牲背景精度或误检增多 |
| 边界 / 细节 | 边界 loss、refinement | 边缘略好 | 对「无清晰边界」的烟雾是否适用？ |
| 领域专用 | 烟雾检测/分割专用网络 | 更贴任务 | 泛化、数据集规模、是否过拟合某一场景 |
写法要点： 缺陷要可验证——后文实验里最好有消融或对比对应「现有方法缺 X → 我们补 X」。
4. 若问题尚未被充分定义：如何「开新坑」？
有些烟雾相关难点在公开文献里没有被单独命名，例如：
- 「半透明区域」的标注一致性与评价方式；
- 「早期微弱烟雾」与「成像噪声」的可分性边界；
- 视频里时间一致性是否应纳入分割指标。
这时论文的贡献可以是 Problem formulation + benchmark protocol + baseline，而不必一上来就 SOTA 涨点。需要把：
- 为什么以前没人单独做（数据、标注、应用需求刚成熟）；
- 你怎么定义子任务/子集（如 early-stage smoke subset）；
- 难点是什么（人眼都难标、类间极度不平衡）；
- 最小可行解决方案（even a strong baseline + analysis）
说清楚，审稿人也会认「定义问题」本身的贡献。
5. 打算用什么办法解决？——三类来源怎么选
方法来源不必二选一，但要和问题一一对应，我会在笔记里分成三类：
| 来源 | 适用情形 | 烟雾分割中的例子（示意） |
|---|---|---|
| CV 大领域热门技术 | 困境本质是表征、注意力、基础模型能力 | 多尺度特征融合、Transformer、SAM 式 prompt、知识蒸馏 |
| 通用语义分割新进展 | 困境是分割范式、训练策略、统一框架 | 新 decoder、mask classification、更强 data augmentation pipeline |
| 老而专、极贴任务的方法 | 困境是物理/成像/数据特性 | 透射率先验、颜色空间约束、时空平滑、烟雾扩散模型启发 |
个人原则：
- 不要为了「蹭热点」硬上 ViT，若主要瓶颈是误检云雾，可能一条物理启发或后处理约束比换 backbone 更有说服力；
- 也不要只堆「领域 trick」而无泛化实验——至少要有跨场景 / 跨数据集说明不是 overfit。
论文里每一模块建议能回答：「它对应第二节表格里的哪一行困境？」
6. 实验：怎样才算「超过 SOTA」？
对烟雾分割，我会把「超过 SOTA」拆成几层，避免只报一个 mIoU：
- 公平对比：同数据划分、同输入尺寸、同训练轮数、同预训练；引用官方或复现结果（可参考指标复现与调参里的经验）。
- 主指标 + 辅指标：smoke IoU / F1，必要时加小目标子集、误检率、推理速度。
- 定性必须对齐定量：Motivation 里承诺解决的 error case，在可视化里要「一眼能对上」。
- 消融：去掉你的核心设计，缺陷是否复现——这是「问题—方法」闭环的关键证据。
- 失败案例分析：诚实展示仍失败的样本，反而增加可信度。
若主指标只高 0.5%，但早期烟雾召回或误检云雾明显改善，story 仍可能成立——前提是 Introduction 里主问题定义的就是后者。
三、图表：如何用 Motivation 图和 Method 图打动审稿人
图不是「好看就行」，而是把第二节的逻辑链压缩成 10 秒能读懂的视觉。
1. Motivation 图（建议 1 张，信息密度高）
常见有效结构：
1 | [真实场景照片] → [现有方法预测] → [GT 或理想结果] → [你的方法] |
要点：
- 选最具代表性的 2～3 列 case（小目标 / 边界糊 / 误检云），不要泛泛拼图；
- 错误区域用同色框或放大 inset标出，图注写清「(a) missed detection of early smoke」；
- 若问题驱动是「预警漏检」，可在图侧加一句系统后果（可选，别夸张）。
2. Method 框架图（建议 1 张，模块少而准）
- 从左到右：Input → 核心模块（只画 2～4 块）→ Output；
- 每个模块用一句话对应一个 sub-problem（如 「Boundary-aware refinement → 半透明边缘」）；
- 训练时/推理时分开的，用虚线框区分；
- 避免与 Motivation 重复同一信息；Framework 讲「怎么做」，Motivation 讲「为什么必须做」。
3. 实操小贴士
- 统一配色（GT=绿、Pred=彩、Error=红），全文字号 ≥ 8pt；
- 导出 PDF/矢量，避免截图糊；
- 先画故事板（纸笔排 case），再进 PPT / draw.io / Figma；
- 给导师或同学看 10 秒，问「你觉得我在解决什么问题」——答不上来就改图。
四、一套可自查的写作清单（开写前过一遍）
- 标题/摘要里能否用一句话说出「任务困境 + 技术缺口 + 我们的切入点」？
- Introduction 是否按「应用困境 → 形式化 → 现有不足 → 本文贡献」顺序，而不是先讲网络？
- Related Work 是否按问题维度分节，而非按年份堆模型？
- Method 每个模块是否标注针对哪条困境？
- Experiment 是否覆盖 Introduction 承诺的 error type？
- Figure 1 是否能在不读正文的情况下传达 Motivation？
五、补充：框架成立，但要留一点弹性
上文那条「问题驱动」链条，我认为大方向是对的，也符合审稿人和导师常强调的 story。但在实际写稿、和导师对齐时，还有几条容易走偏的地方值得单独记下来，避免把 checklist 用成教条。
1. 不是每篇论文都要「开新坑」
多数稿件的真实形态是：问题别人提过，但在某个设定下仍没解决好——例如早期微弱烟雾、某类场景泛化、某套评价协议下的盲区。这类工作的贡献往往是「把缺口写窄、写具体、用实验钉死」，而不是宣称提出了一个全新的任务。
「开新坑」适合那种：公开文献里尚未被单独命名或系统讨论的难点（如半透明区域的标注一致性、视频时间一致性是否应纳入分割评价）。此时 Problem formulation + protocol + strong baseline 本身就可以是贡献，不必一上来就全面碾压 SOTA。
2. 问题驱动 ≠ 做研究时不能从方法出发
实际科研里，完全「先问题、后方法」的理想顺序并不总成立。有时是先注意到某个可迁移的模块（新的 attention、foundation model、训练策略），再反查它可能缓解哪类 failure case——这并不丢人。
关键是成稿时必须翻回问题链：Introduction 和实验仍要回答「我们在解决什么、旧方法缺什么」；若正文读起来像「为了用某模块而硬凑动机」，审稿意见往往会集中在 story 不成立，而不是模块本身不够好。
3. 「超过 SOTA」不是唯一的成功标准
对烟雾分割这类应用导向任务，主指标涨 0.5% 但早期漏检、云雾误报没改善，story 仍可能站不住；反过来，指标略逊但明确改善了 Introduction 里承诺的那一两种错误，论文仍可能成立。
此外，以下几类工作同样有价值，不必强行套「涨点叙事」：
| 类型 | 典型贡献 | 实验重点 |
|---|---|---|
| 分析型 | 揭示某类失败模式的成因 | 可视化、统计、对照实验 |
| 协议/指标型 | 更合理的子集或评价方式 | 证明旧指标会误导结论 |
| 基准/数据型 | 新子集、划分或标注规范 | 可复现 baseline + 分析 |
写稿前先想清楚：本文的主贡献更接近「新方法」「新认识」还是「新尺子」——再决定实验章节的主线，而不是默认必须有一张全面 SOTA 对比表。
4. 图能打动人，但逻辑不能全靠图
Motivation 图和 Method 框架图是压缩，不是替代品。若 Figure 1 强调「误检云雾」，Table 里的对比、消融里却没有任何设置针对这一问题，审稿人容易认为 story 是「画出来的」。
个人习惯：每个在 Figure 1 出现的 error type，在实验章节至少有一处定量或定性证据对应（主表、子集、消融或补充材料均可）。
5. 烟雾分割方向的一句落地建议
这个领域里，标注歧义、类极度不平衡、与云/雾/尘/反光混淆几乎是常态。一篇稿子里若能只钉死 1～2 个 failure mode（例如「早期极小烟雾漏检」或「云状背景误报」），并让它们贯穿 Introduction → Method → 图 → 表，往往比泛泛宣称「烟雾很难分割」更有说服力。
也提醒一句：一篇论文最好只服务一个核心痛点；若 Introduction 里同时想解决五六个问题，方法、实验和图通常都会散，审稿人也更难记住你的贡献。
小结
对我目前在做的烟雾分割方向而言，一篇值得投的论文，主线 increasingly 清晰：
先站稳「烟雾分割在实际中卡在哪里」→ 再把它翻译成可检验的技术问题 → 用文献证明别人还没解决好 → 方法选型服务于缺口而非服务于模块名 → 用指标和图把「问题—解法」闭环做实。
写作和做实验是同一套逻辑的两面：实验设计是在验证你对问题的判断；图表是在帮审稿人 30 秒内相信这个判断。后面在具体课题里若沉淀出更细的「早期烟雾子集定义」「专用评价协议」等，会再拆成短文补充到博客。