科研与工程的区别
工程的目标是造出能用的东西，科研的目标是产生别人不知道的、可验证的知识。本章讲两者在目标、评价、时间尺度上的差异，以及计算机科学中两者交织的特殊性——很多 CS 研究的"知识"以系统或算法的形式存在。
目标与产出：主张，而非系统
Section titled “目标与产出：主张，而非系统”工程的目标是造出能用的东西；科研的目标是产生别人不知道的、可验证的知识。两者的产出物形态不同：工程的产出是系统、功能或修复；科研的产出是可检验的主张（claim）——在什么条件下、通过什么机制、比什么更好或更差。
系统、代码、数据集在科研中只是证据。同一个 KV cache 优化，工程师问"上线后能省多少内存、会不会引入延迟"；研究者问"为什么能省、在什么负载模式下省、代价是什么、这个结论能不能推广"。前者交付一个可用系统就结束了；后者必须把观察提炼成主张，并给出证据链。
评价标准：可用性 vs 可信度
Section titled “评价标准：可用性 vs 可信度”| 维度 | 工程 | 科研 |
|---|---|---|
| 目标 | 满足需求、可靠运行 | 产生新知识、可验证 |
| 评价者 | 用户、产品、运维 | 同行评审 |
| 评价标准 | 是否可用、性能、成本 | 新颖性、证据是否支撑主张、重要性 |
| 时间尺度 | 持续迭代维护 | 一次性的完整论证 |
| 失败 | 返工、修 bug | 也是结果（排除 bug 后的负面结果可发表） |
对科研来说，"能跑"不是贡献，"为什么在什么条件下更好"才是。Demo 再炫、代码量再大，如果不指向一个可检验的主张，就不构成研究贡献——这是新手最常见的误区。
CS 的特殊性：两者高度交织
Section titled “CS 的特殊性：两者高度交织”计算机科学是少数工程与科研深度重叠的学科：很多 CS 研究的"知识"以算法、系统或数据集的形式存在。系统会议（OSDI、SOSP）的论文本身就是"造出来 + 测出来"，构建一个真实系统并诚实测量，就是合格的证据；ML 研究的许多贡献是经验性发现（"预训练数据质量比模型结构更关键"），离开大规模工程实践无法获得。
这带来两点：
- 优势：想法到验证的闭环极短。一个假设可能两周内就能实现并检验，这在多数学科不可想象。
- 风险：容易把工程量当研究贡献。"我们做了大量优化、很多行代码"不是主张；"在此约束下，瓶颈在 X，因此 Y 类优化有效"才是。写论文、评审、规划工作时都要警惕这个混淆。
三个自查问题
Section titled “三个自查问题”判断手头的工作是工程还是研究，问三个问题：
- 这项工作回答了什么之前不知道的问题？
- 证据能否支撑这个回答？
- 这个回答改变了谁的认知？
三个都答不上来，就是在做工程——工程本身没有问题，但应当自知，并决定是否要把它升级为研究（见研究空白与"增量"的边界）。
- 科研的产出是可检验的主张，系统只是证据
- "能跑"不是贡献，"为什么/在什么条件下更好"才是
- CS 是少数工程与科研高度重叠的学科