一个研究想法只是开始。

在计算机视觉和具身智能里，真正困难的部分往往是把一个有希望的想法变成可靠系统：

清晰的问题定义；
可复现代码；
可信的数据处理；
稳定训练；
公平 baseline；
有意义的消融实验；
清楚的论文写作。

这篇笔记主要讨论研究中的工程侧，尤其是三维感知和协同占用预测项目。

1. 研究是一个系统

以前我会把研究主要理解为想法生成。

现在我更倾向于把一个研究项目看成系统：

\[\text{idea} \rightarrow \text{formulation} \rightarrow \text{implementation} \rightarrow \text{experiments} \rightarrow \text{analysis} \rightarrow \text{paper}.\]

任何一个阶段薄弱，都会影响最终工作。

一个好 idea 可能因为代码不稳定而失败；一个聪明模型可能因为 baseline 不公平而显得没效果；一个不错实验也可能因为分析不清楚而没有说服力。

为 Ph.D. 做准备时，我希望自己不只是会提想法，也能把想法建设成完整可靠的研究系统。

2. 先定义精确问题

写代码之前，我会先把研究问题压缩成一个形式化表达。

以协同占用预测为例，一个简化形式是：

\[\hat{O}_i = f_\theta(X_i, \{M_{j \rightarrow i}\}_{j \in \mathcal{N}_i}),\]

其中：

(X_i) 是 ego agent 的观测；
(M_{j \rightarrow i}) 是邻居 (j) 发送给 ego 的消息；
(\hat{O}_i) 是预测的语义占用网格。

通信预算可以写成：

\[\sum_{j \in \mathcal{N}_i} \mathrm{Cost}(M_{j \rightarrow i}) \leq B.\]

这个定义会迫使我回答几个设计问题：

message 到底是什么？
message cost 如何度量？
哪些区域需要协同？
如何评价准确率和带宽之间的 trade-off？
当预算变化时，模型行为如何变化？

如果这些问题不清楚，实现也会变得混乱。

3. Baseline 必须诚实

研究贡献只有相对于 baseline 才有意义。

我通常会检查：

baseline 是否使用同样的数据？
输入模态是否可比？
通信预算是否相近？
evaluation script 是否完全相同？
hyperparameters 是否公平调整？
baseline 是否使用了我方法没有用的测试时信息，或者反过来？

在协同感知中，公平尤其重要，因为通信预算的微小变化就可能改变结果。

如果一个方法传 dense feature map，另一个方法传 sparse tokens，就必须同时报告准确率和通信成本。否则比较是不完整的。

4. 一开始就为可复现性设计

可复现性不应该最后再补。

我希望每个实验都能被描述成一个 tuple：

\[E = (\mathcal{D}, C, \theta_0, H, S, R),\]

其中：

(\mathcal{D}) 是数据集和划分；
(C) 是配置；
(\theta_0) 是初始化或 checkpoint；
(H) 是硬件和运行环境；
(S) 是随机种子；
(R) 是指标和日志。

实际操作中，这意味着：

使用配置文件，而不是隐藏在命令行习惯里；
尽可能记录 git commit；
保存准确的 evaluation settings；
固定 dataset split；
同时记录通信成本和准确率；
避免悄悄修改 preprocessing。

这不华丽，但能保护研究不被偶然混乱污染。

5. Debug 表示，而不只是看指标

在三维感知中，指标差可能有很多原因：

坐标变换错误；
相机标定不匹配；
voxel indexing 错误；
BEV projection 不正确；
temporal memory 不稳定；
token compression 过强；
多智能体位姿对齐误差。

所以我会尽量可视化中间表示。

对 occupancy 和 BEV 模型，有用的 debug 视图包括：

输入相机图像；
BEV feature intensity；
argmax 前的 occupancy logits；
预测 occupied 和 free-space 区域；
token importance map；
请求通信区域；
temporal memory activation；
遮挡场景下的失败案例。

当我能看见模型在哪里失败时，改进会更有方向。

6. 在最终结果之前设计消融

消融实验不应该是最后才补的东西。

完整实验跑完之前，我会先列出自己想支持的 claim。

对于一篇 token communication 论文，可能的 claim 包括：

Token communication 相比 dense feature sharing 能降低带宽。
Receiver-driven requests 比 sender-only ranking 传输更有用的信息。
Content-aware merging 比 naive compression 更能保留任务相关信息。
Temporal memory 能在部分观测下提升稳定性。
Adaptive budget allocation 能改善准确率-通信成本 trade-off。

每个 claim 都需要对应实验。

这样论文会更有说服力，因为实验围绕论点展开，而不是堆一组方便得到的数字。

7. 保留失败日志

失败实验很容易被忘记，但它们往往含有最多信息。

我会记录：

改了什么；
预期是什么；
结果是什么；
我认为为什么失败；
失败来自实现问题还是 idea 问题；
下一步该测试什么。

例如：

Experiment: Increase protected token ratio.
Expected: Better occupancy mIoU under low bandwidth.
Observed: Small gain in near regions, worse far-region semantics.
Hypothesis: Protected tokens are too concentrated around high-confidence regions.
Next: Add uncertainty-aware request weighting.

这种日志能避免反复犯同样错误，也可能在之后变成有用的分析。

8. 让代码和写作连接起来

当实现、实验和写作都服务同一个论点时，一个研究项目才会变得可发表。

我会尽早写下论文的核心 claim：

我们通过把场景信息表示为 task-aware tokens，并根据 ego uncertainty 和 bandwidth constraints 自适应选择、合并与融合这些 tokens，从而在有限通信下提升协同语义占用预测。

然后我会问：

方法部分是否直接实现这个 claim？
实验是否测量了关键 trade-off？
图是否让核心 idea 容易理解？
消融是否隔离了每个组件？
limitation 是否诚实说明仍未解决的问题？

早写作经常能暴露缺失实验。

9. 这对 Ph.D. 准备意味着什么

Ph.D. 不只是拥有好想法，也包括不断把想法转化为证据。

对我自己的准备来说，我希望研究过程越来越 disciplined：

清楚定义问题；
构建稳定代码库；
认真复现 baseline；
围绕 claim 设计消融；
诚实分析失败；
用连贯研究叙事写作。

这也是我希望个人网站呈现的样子：不是项目列表，而是我能够思考、构建、评估和表达研究的证据。

10. 总结

最好的研究系统应该是安静的。

它让实验更可信，让失败更容易理解，让写作更自然，因为证据已经被组织好了。

对三维感知和自动系统来说，这尤其重要，因为 pipeline 很复杂。数据、几何、学习、通信、时间记忆和评测都互相连接。

我的目标是让每个项目不只是一个结果，而是一台可复用的研究机器，帮助我继续提出更好的下一个问题。

从想法到可靠研究系统