2025 回顾

2026 跨年时流行一句话：“2026 是一个世纪的夏天。”这句话对我格外有吸引力。 我从小在长沙长大，本科在北京生活了几年。2024 年 8 月 19 日，我结束了在北京的实习来到杭州；2025 年，我在杭州完整生活了一年。回头看，杭州很巧合地融合了长沙的城市气质与北京的发展速度，更巧合的是：它也像是把两座城市的气候“取了个均值”：不像长沙那样长期潮湿，也不像北京那样动辄干到起皮；雨会下，但不至于下到让人心态发霉。

对长沙来说，夏天意味着终于可以绕开春季那段黏腻的梅雨季：衣服永远晾不干，路面永远湿哒哒，连人的情绪也像被水汽裹住。对北京来说，夏天反而是我最舒服的季节之一：日照时间长、空气干爽，走在路上会有一种“世界被调亮了”的感觉。北京的春天倒也不算讨厌，只是偶尔会遇到沙尘暴——它有点像你让 GPT 帮你写点代码时，它会往代码里塞一堆 try/except，让本来清爽的逻辑突然变得臃肿。好消息是，这类“尘土”大多好清理；坏消息是，如果你把衣服晾在阳台上忘了收，就会留下痕迹——就像你把 GPT 生成的内容原封不动堆进代码库里，短期不影响跑通，但回头维护时处处是泥点子。而对于杭州来说除了冬天没有暖气似乎就没有太大的气候劣势了，最关键的就是不时常下雨的同时并不干燥。

而长沙的梅雨季带来的心理影响，更像我在 2025 年做研究时遇到的一段状态：迷茫、困惑、潮湿。说它严重？倒也不至于；说它能忽略？似乎也很难。就像梅雨季里打一把伞似乎遮不住多少雨；不打伞似乎也不会淋得太湿。但这恰恰是最消耗人的，你无法用“这事很大/这事很小”去简化它，更无法完全忽视它。 2025 年，有一篇工作从春天一路投稿到冬天，最终还是 rejected。更准确地说，它并不是那种“明显不行”的失败，就是那种梅雨季给人带来的粘稠感的失败，你总觉得差一点点就能过去，但又总过不去。在3月份基本idea就已经完全成型，于我而言代码实现更是简单，但是当时的代码并非由我完成也没做仔细地检查，导致最终临近截稿的时候的效果与我的构思完全不同，真是硬着头皮写完了Paper投稿了，说来也奇怪当时居然会存在有侥幸心地投稿，结果可想而知；到了7月我重新将代码实现了然后再次投稿了，但是还是被拒了。在11月再次Rolling了一次，结果依旧如此。 这段过程里，“打伞还是不打伞”经常变成一种真实的心理拉扯：继续加码，明知方向不对；及时止损，却又不甘心觉得差的并不多了。现在回头看，它更像一个提醒。 当然，长沙的春天也不只有阴雨。2025 上半年我去了纳什维尔参加CVPR，下半年国庆节又去日本旅行了一趟。

回到研究本身，2025 的技术氛围在我体感里并不像前两年那么“热火朝天”，就像北京的春天短暂地过去了。图像生成模型的发布节奏变得非常克制，在下半年有一个小高潮，尤其是Z-Image的出现，视频生成倒是在 2025 又迎来一波明显推动：比如 Wan 的开源确实给人不少惊喜，但是当实际运行起来才会感受到这或许才刚刚起步。只是站在我自己的研究路径上，变化更剧烈的反而是另一件事：随着 GPT-Image、Nano Banana 这类更通用的生成/编辑能力出现，我过去两年投入较多的 personalized generation 这类更偏应用的任务，在“任务边界”上被重新划了一次线。 这不是说它没有价值。相反，它仍然有产品价值、也有应用价值。但我越来越清楚：如果一个方向高度 data-driven，且优势主要来自数据与规模，那么在学术语境里，它很容易被更强的通用模型直接覆盖。 23–24 年 SD1.5 / SDXL 与开源社区的繁荣给了很多缓冲窗口，我们可以在“能力缺口”里做出相当漂亮的工作；但当缺口缩小甚至消失时，研究贡献就必须从“效果更好”转到“机制更清楚、变量更可控、成本更可解释”。这件事情也是20205年第二个需要反思的点。

也正因此，从 2025 年 6 月开始，我刻意调整了科研重心。方向是否值得投入，我给自己加了更严格的门槛：一是可评估性：是否存在公认的 benchmark，或至少能建立稳定、可复现的评估闭环；二是可抽象性：问题是否触及更底层的规律，而不是依赖某个数据集或某个特定模型配置的红利。 这可能也算一种 research taste 的训练：学会判断“什么东西即使模型更强了，依然值得研究”。如果说过去的我容易被短期结果牵着走，缺乏对背后原理的拆解与抽象，那么 2025 下半年的转向，是我第一次比较认真地把选择标准写清楚，并且执行得更严格。还有一点转变：开始主动警惕“training-free ≠ 更优雅”。通过改推理流程获得提升当然诱人：不用训练、成本低、迭代快，paper 写起来也顺。但只要它不能做到真正的 model-agnostic，它就很容易把研究带进模型偏置里：你必须深入理解某个模型，才能找到它的“可利用结构”；可你利用的结构，往往也正是这个模型的局限。结果就是方法看似在解决问题，实际在适配一个特定模型的世界观。中国的古话说“治标不治本”，我现在更愿意把精力投向那些不依赖某个模型红利、即使模型换代也仍然成立的规律。

好 idea 很重要，但对大多数普通人而言，稳定地产生“足够好”的 idea 本身就是困难的，计算资源有限、时间有限、智力也有限。相反，工程能力是少数可以靠训练持续积累的优势：你能不能把问题定义得更准确，能不能建立可信的评估闭环，能不能把变量锁住，把实验做成可复现、可诊断、可迭代的系统。很多所谓“缺 idea”的时刻，本质上是因为系统太脏、噪声太大，导致无法确认自己到底在解决什么问题。2026 我希望自己更坚定地走这条路：把研究做清楚，把工程做干净，把精力投向那些更本质、也更能长期成立的东西。 同时我也给自己加了一个更具体的衡量标准：一篇工作完成后，是否能沉淀出一份可直接复用的 handbook/guideline，讲明白相关研究的发展历程，把关键设置、数据处理、评测脚本、以及主要 baseline 尽可能集成到同一个仓库中。这样做的意义并不只是“代码开源”，而是为后续研究提供一套稳定、可控、可持续迭代的评价工具：别人可以复现，你也可以在同一套基准上快速验证下一次改动到底是在进步还是在自欺。