工作感悟：从技术思维到解决方案专家

从技术到解决方案的思维飞跃

前几天所里开会，重点讲了 AI4S (AI for Science) 的战略规划。简单来说，就是想办法把 AI 融入到日常科研工作中，提升效率，产出更多高质量成果。

愿景很美好，但大家私下讨论最多的，其实还是那个老生常谈的问题：这玩意儿到底怎么落地？ 具体有哪些应用场景？怎么把科研结果转化为实际的生产力？

会上领导提了一个观点，让我印象很深。他说，明确业务是核心。作为数据部门，我们的定位不应该仅仅是“处理数据的”，而应该是为科研工作者建设好“AI Ready”的数据基地。我们的任务是把最脏最累的数据整合工作做完，让科学家们能专注于科研本身，而不是把时间浪费在数据的清洗和管理上。

这让我意识到，作为数据部门，我们的核心业务场景，本身就是“数据”。只有把这个地基打牢了，上层的 AI 应用才能跑得起来。

见树木，也要见森林

这个观点也让我想起了之前参与的一个遥感解译项目。当时我的角色主要负责模型训练和调优，是一个典型的技术执行者。每天脑子里想的都是怎么设计网络结构、怎么调参、IoU 能不能再提高一个点。

直到项目验收阶段，为了写结题文档，我被迫重新梳理了整个项目的全流程。这一梳理，我才发现自己以前的视野有多狭窄：

1. 政策源头：项目的起因是广东省发布了林业保护相关的政策要求。
2. 业务需求：为了响应政策，需要对林业资源进行监测。
3. 场景细化：从宏观的林业监测，具体落到优势树种——红树林的监测。
4. 技术拆解：明确了业务场景是“红树林变化检测”后，再根据红树林的光谱和纹理特征，制定解译标准（什么是增加，什么是减少，什么是不变）。
5. 实施执行：最后，才是根据这些标准去标注数据、训练模型。

当时身在其中的我，切入点直接就是第 5 步，也就是具体的“技术工作”。对于前期的“为什么要做”、“为谁而做”、“标准怎么定”，我几乎没有关心过。

回想起来，不论是在学校帮导师做项目，还是后来参加各种比赛，我的模式大多如此：只要给我一个定义清晰的问题（赛题），我就用技术手段去解出这个题。

在比赛里，赛题背景、评价指标、数据集都是现成的，我只需要关注 Score。但在真实的工作中，如果你不理解赛题背后的业务逻辑，你甚至不知道该用什么指标来衡量模型的好坏，更别提解决实际问题了。

从“做题”到“出题”

刚入职前公司时，领导对我的期望是从单纯的技术实施人员，进一步转变为项目负责人。我尝试从业务的角度去思考问题。

以前我觉得技术很牛。后来参与项目才明白，技术只是工具，业务才是灵魂。

如果不理解业务，技术再强也可能是在做无用功。比如，与其花几周时间去优化模型这 1% 的精度，不如花两天时间搞清楚业务方真正关心的指标是什么，或者优化一下前期的解译标准，带来的收益可能反而更大。

尤其是现在的 AI 时代，技术迭代快得离谱。今天还在用的 SOTA 模型，明天可能就被新出的架构降维打击了。如果只是停留在“会调包”、“会训练”的技术层面，很容易就会变得焦虑，因为那是无论如何也追不上的。

提供解决方案

反过来想，AI 的强大其实也降低了理解业务的门槛。可以利用 AI 快速分析海量的文档、理解陌生的领域知识。

在这个背景下，对业务的深刻理解反而成了更深的护城河。

我粗浅地认为，未来工作的进阶路径，不应该是在技术的死胡同里钻牛角尖，而应该是完成从技术视角到业务视角的跨越。

不再满足于做一个“把模型跑通”的技术员，而是成为一个能够理解业务痛点，并利用技术（无论是传统的还是 AI 的）去解决这些痛点，最终提供完整解决方案的专家。