AI编程时代的数据科学家复兴：工程化能力成为新核心竞争力

「数据科学家是 21 世紀最性感的職業。」哈佛商業評論曾給予這般美誉曾几何时，数据科学家这个岗位代表着高薪酬、高门槛和高度的战略重要性。随着大语言模型（LLM）API 的普及和 AI 编程工具的崛起，这个角色正在经历前所未有的重构。是时候重新定义数据科学家的价值坐标了。

被重构的岗位价值

传统的机器学习工作流程要求数据科学家全程参与：从数据清洗、特征工程、模型训练到部署上线，每个环节都需要深度介入。大型科技公司甚至将这部分工作拆分为独立的岗位 —— 机器学习工程师（MLE），让数据科学家专注于建模和实验。这种分工在监督学习时代运转良好，但 LLM 改变了游戏规则。

Foundation Model API 的兴起意味着团队可以直接调用预训练模型的能力，而无需自己训练模型。这一变化让不少数据科学家感到焦虑：如果公司不再需要我来训练模型，我的岗位还存在价值吗？这种担忧不无道理，但答案可能恰恰相反。

Hamel Husain 在近期的演讲「The Revenge of the Data Scientist」中提出了一个关键洞察：调用 LLM API 并不需要多少数据科学知识，但确保 AI 系统真正 workable—— 能够可靠地解决业务问题 —— 却需要大量数据科学技能。这些技能被掩盖在「AI 工程」的光环下，却正是数据科学家可以发挥的核心优势。

Harness 工程：数据科学的新战场

OpenAI 在关于 Codex 项目的博客文章中描述了一种名为「harness engineering」的方法论。简单来说，harness 就是一套约束 AI 行为边界的基础设施，包括测试用例、业务规格定义、可观测性栈（ logs、metrics、traces）以及评估指标。AI agent 在 harness 的约束下自主完成开发任务，超出边界时能够自我修正。

这正是数据科学家技能的用武之地。大多数 AI 工程师关注的是如何让模型输出更好的结果，却忽视了 harness 的质量。Hamel 指出，一个大型 AI 系统中，相当部分的 harness 工作本质上是数据科学：设计实验验证模型泛化能力、调试随机系统、设计合理的评估指标。这些工作并不会因为调用了 LLM API 而消失。

五大评估陷阱与工程化应对

在实际 AI 系统开发中，Hamel 观察到五个常见的评估陷阱，这些恰好是数据科学家可以提供差异化价值的领域。

第一个陷阱是通用指标依赖。许多团队直接使用评估框架提供的开箱即用指标，如帮助性评分、连贯性评分、幻觉检测评分。这些指标听起来合理，但对于诊断具体业务场景的失败原因几乎没有帮助。数据科学家的做法应该是：深入分析生产数据，探索 trace 记录，询问「究竟什么环节在出问题」，然后针对性地设计应用特定的评估指标。通用的相似度度量如 ROUGE 或 BLEU 很少适用于 LLM 输出，真正有价值的指标应该是「日历安排失败率」或「未升级给人工客服的错误率」这类业务导向的度量。

第二个陷阱是未经验证的「法官」。很多团队使用 LLM 作为判断 AI 输出质量的「法官」，但几乎没有人能回答「如何信任这个法官」这个问题。正确的做法是将 LLM 法官当作一个分类器来看待：获取人工标注数据，将数据划分为训练集、开发集和测试集，验证法官的可靠性。如果你之前做过机器学习，这套方法很无聊，但如今 AI 工程师普遍忽视了这个基本功。在报告结果时也应该使用精确率和召回率，而非简单的准确率 —— 如果某类失败模式只占 5%，准确率会完全掩盖系统的真实表现。

第三个陷阱是糟糕的实验设计。多数团队通过简单 prompt 生成合成测试数据：「给我 50 个测试查询。」结果得到的测试集缺乏代表性，无法覆盖真实场景。数据科学家的做法应该是：首先分析真实生产日志，确定哪些维度最关键，然后基于这些维度生成合成测试数据。另一个常见问题是将整个评分标准打包进单一的 LLM 调用，并默认使用 1 到 5 分的李克特量表。更好的做法是简化复杂度，将每个指标设计为可操作的二元判断（通过 / 失败），并与业务指标挂钩。

第四个陷阱是数据与标签质量。数据科学家天然对数据持怀疑态度，这是训练造成的本能。但 AI 工程师普遍缺乏这种谨慎。多数团队将标注工作委托给开发团队或外包，但数据科学家会坚持让领域专家参与标注，并持续质疑标签的准确性。更深层次的原因在于「标准漂移」现象 —— 用户需要标准来评估输出，但评估输出反过来帮助用户定义标准。人们在看到 LLM 的实际输出之前，往往不知道自己想要什么。标注过程本身就是发现业务需求的过程。

第五个陷阱是过度自动化。所有上述工作都需要人工介入，但团队总是试图将这些流程自动化。LLM 可以帮助你搭建基础设施、编写管道代码、生成评估框架的模板，但它无法替你分析数据。原因很简单：在看到输出之前，你根本不知道自己要什么。

工程化实践要点

将上述洞察转化为可操作的工程实践，需要关注以下参数和监控点。

在 trace 分析层面，建议团队建立自定义的 trace 查看器，针对特定领域的边缘情况进行优化。每次迭代后执行系统的错误分析，将失败案例分类并确定优先级。实践表明，阅读 trace 是投资回报率最高的活动，但也是最容易被跳过的环节。

在指标设计层面，优先采用应用特定的二元判断指标而非通用评分量表。每个指标应与明确的业务结果挂钩。例如，与其使用「回答质量 3 分」这样的模糊评分，不如定义「是否准确回答了用户的核心问题（是 / 否）」。这样的指标更具可操作性，也更容易追踪改进效果。

在 judge 验证层面，建立独立的开发集和测试集来验证 LLM 法官的可靠性。使用少样本示例时应从训练集中选取，并持续迭代优化法官的 prompt。保留测试集用于最终验证，避免在开发集上过拟合。

在数据标注层面，确保标注者来自业务一线而非外包团队。建立标注质量监控机制，定期进行标注一致性检验。关键是让产品经理和领域专家直接接触原始输出数据，而非仅查看汇总分数。

在生产监控层面，持续追踪应用特定指标在生产环境中的表现。设置合理的告警阈值，当关键指标下降超过预期范围时触发人工介入。记录足够的上下文信息以便事后错误分析。

新竞争力的构建路径

AI 编程工具的兴起并没有宣告数据科学家的终结，反而将这个角色推向了一个更核心的位置。工程化能力 —— 包括系统性的评估设计、严格的数据验证、科学的实验方法 —— 正在成为数据科学家在 AI 时代的新核心竞争力。

传统的建模技能依然重要，但仅靠建模能力已经不足以创造差异化价值。数据科学家的独特价值在于：能够从海量输出中识别模式，能够设计有意义的评估指标，能够验证 AI 系统的可靠性，能够将业务需求转化为可测量的技术指标。这些能力不会被 API 调用所替代，因为它们本质上是关于如何在不确定环境中做出可靠决策的元技能。

正如 Hamel 在演讲结尾强调的那样：Always look at the data。这句话既是技术建议，也是职业哲学。在这个 AI 能力触手可及的时代，真正的竞争力不在于调用多强大的模型，而在于多深刻地理解问题本身。

参考资料

• Hamel Husain, "The Revenge of the Data Scientist", Hamel.dev, 2026 年 3 月 26 日
• OpenAI, "Harness Engineering", OpenAI Blog

ai-systems