把科研流程做成一套可调用的工具

2026 年 7–8 月。目标：把"选题—训练—验证—写作—画图"这条链路拆成可复用的模块，减少每次做课题都要重搭一遍的成本。

为什么要做成套件

单个课题里最容易重复的不是模型代码，而是流程性工作：数据怎么划分、实验怎么记录、判定标准什么时候定、结果怎么整理成图表、论文里怎么描述失败。这些工作在第二个课题里还会原样出现一次。所以我按"一个模块只做一件事"的方式把它们拆开，共 13 个技能模块 + 约 20 个确定性脚本，脚本部分配了 90 余项测试。

几个设计取舍

一个入口，其余按需调度。 模块多了以后，记住什么时候该用哪个本身就是负担。所以最外层只保留一个总模块：它先分析当前处在哪个阶段、缺哪些前置产物，再决定调用哪些子模块。用户只需要描述任务，不需要知道内部有几个模块。

确定性的事交给脚本，判断的事交给模型。 数据划分、指标计算、图表生成、记录模板填充这类工作，每次结果都应当一致，因此写成脚本并由测试覆盖；只有"这个方法是否值得试""这个结论能不能写"这类需要判断的环节才交给模型。

判定门槛写在实验之前。 这一步在流程里被固定成一个前置步骤：先写下判定标准并存档，再开始跑实验，完成后不因结果调整门槛。它看起来是最"形式主义"的一环，但在真实课题里救过一次——见负面结果也是一份结果。

环境约束写成规则文件。 每个项目维护一份规则文件，记录这个环境里"什么不能用、什么要转义、哪些工具是坏的"。写一次，后面所有会话都受益；不写，每次都要重新踩一遍。

用真实课题检验

套件做完之后，我用一个真实的图像分类课题端到端跑了一遍（基线 77.23%，新模块 56.78% 并中途崩坏）。结论是负面的，但流程本身经受住了检验：负面结果同样被完整归档，诊断过程沉淀成了可复用的检查方法。

一点体会

把流程工具化的收益不在于"跑得更快"，而在于让纪律变得容易执行：当"先写判定标准"是流程里的一个必经步骤时，你就不会因为赶时间而跳过它。