01｜科研到底在做什么

从你熟悉的“做软件”说起

假设你给 Uptimer 加了一个告警功能。现在服务出问题时，用户能收到通知。这是一项有用的工程成果。

接着你发现：Agent 修好了页面，却把之前没有发出的通知丢了。你问：“只检查页面恢复，是否会把这种修复误判为成功？”你设计几种检查方法，在同一批修复结果上比较，保存具体漏判案例。

后面这部分开始成为研究。因为你不只做出了一个工具，还试图回答一个别人也能理解、检查、沿用的问题。

工程与研究可以互相促进。一个工具可以是研究的产物，也可以只是帮你观察现象的仪器。关键是说明它带来了什么可验证的新认识，而不是数它有多少功能。

一项研究通常有这条链

我们遇到一个问题 → 别人已经回答了一部分 → 某一点还不清楚 → 我们用这些办法检查 → 得到这些结果 → 因而可以作出这个范围内的判断。

这里任何一环缺了，文章都可能显得完整，研究却还没完成。

例如，“Agent 需要更好的周边系统”是方向判断。它可能合理，但要继续说明：哪一种系统因素？面对哪些任务？改变它后，哪些结果会变？与增加模型调用次数相比是否仍有用？

“我认为它重要”负责说明为什么值得研究；“实验显示……”才负责支持具体经验结论。两者不能相互替代。

不发明新模型，也可以研究

你可以做不同类型的贡献：

• 提出方法。 例如怎样保留交接记录里的当前决定，并与已有方法公平比较。
• 发现和解释现象。 例如同样的压缩配置，在哪类翻译要求上容易出问题；进一步排除其他原因。
• 改进测量。 例如发现一个评分规则会系统性漏掉某类错误，提供经过验证的替代检查。
• 做有目的的复现。 重新检查已有结论，并说明哪些条件下成立、哪些条件下改变。
• 提出有证据的观点。 论证某个研究方向为什么需要改变，同时正面处理反对理由。

这些是组织研究的方式，不是“任何一个都容易发表”的承诺。一个新指标也可能量错东西；一个大数据集也可能题目重复、答案不可靠；一篇观点文章也可能只有口号。

对你而言，先做系统测量或小型评测，是为了让问题和结果都能看得见。以后遇到需要理论或训练的问题，再逐步补充相应基础。

你感兴趣的 benchmark，可以理解为一组评测题目和评分规则；harness 是把模型、题目、工具和评分接起来的运行框架。前者需要证明测到的是有用且明确的能力，后者需要可靠执行和记录。写出一个运行脚本本身，不会自动成为新的评测贡献。

论文、预印本、会议和期刊

论文是研究的书面表达。预印本通常是作者在正式发表前或独立于正式发表而公开的版本；能在网上读到，并不等于通过同行评审。同行评审就是由相关领域研究者评价工作，但它也不是“从此绝不会出错”的认证。

会议和期刊是不同的发表渠道。在计算机科学中，不能简单套用“会议都不重要、期刊都更好”的判断；要具体了解领域和渠道。你当前更需要看内容和研究方法，不必先背排名。

一个真实例子是 Lost in the Middle：预印本在 2023 年 7 月 6 日公开，正式期刊条目在 TACL 2024。查谁先提出某个具体内容时，要回到相应版本，不能只看最后的发表年份。Liu 等，arXiv 版本历史，2023；TACL 正式条目，2024。

Workshop 通常围绕较具体主题组织讨论，但是否收正式论文、是否有论文集、审稿标准如何，都要看当届说明。不要因为名字含 workshop 就当成保证录用的捷径。

第一项研究成功，不等于第一篇论文录用

你可以分三层看进展：

1. 训练层： 你能复现一个小结果，解释方法，保留别人可检查的记录。
2. 研究层： 你回答了一个仍有意义的问题，证据经得起更强对照和更多情况的检查。
3. 发表层： 工作内容、成熟度、表达和目标渠道要求匹配，并经过相应评审。

第一层完成，不保证第三层；但跳过第一层，第三层也不会因为文章写得漂亮就自动出现。

负面结果同样要讲质量。如果你只试了一次没成功，通常只能说实现或条件还需要排查。如果公平、充分地检查后发现复杂方法没有优势，且这影响人们的实际选择，才可能成为有意义的结果。

用你的项目做一个练习

从一个项目里选一句你曾经写过或想写的话，例如：“这个设计能让 Agent 更可靠。”把它改成下面三句：

我这里说的可靠，是完成新任务的同时，不破坏已确认的旧要求。
我准备在同一批任务上比较两种交接方法。
如果改善只出现在调试用的例子里，换一批任务就消失，我暂时不认为方法得到支持。

你已经开始把大词变成可以检查的内容。下一步是确认：别人是否已经检查过。