AI 时代的数据型工程师：从价值倒推能力体系

AI 时代，光会做 demo 不够。

Demo 能证明一个东西跑起来了、效果看起来不错、交互有想象空间。但企业最后关心的不是 demo，而是几个更朴素的问题：

效果提升了吗？
错误率下降了吗？
成本降低了吗？
用户真的用了吗？
业务结果变好了吗？
风险有没有增加？
后面还能不能持续优化？

所以 AI 项目的真正竞争力，不只是模型能力、Prompt 能力或工程能力，而是：

能不能把 AI 的价值说清楚、测出来，并持续优化。

这也是“懂业务的数据型工程师”的价值所在。

AI 项目真正要回答的五类问题

一个 AI 产品的数据体系，本质上要回答五类问题：

可观测关心：系统是否正常。
产品分析关心：用户是否使用。
业务分析关心：是否创造价值。
模型评测关心：AI 是否做对。
数据建模关心：这些问题能不能被数据回答。

它们不是五个孤立模块，而是一条完整链路：

AI 是否正常运行
  ↓
用户是否真的使用
  ↓
AI 是否输出正确
  ↓
业务结果是否变好
  ↓
问题是否能被数据解释
  ↓
下一步是否知道该优化什么

如果只看可观测，系统可能很稳定，但没人用。

如果只看产品使用，用户可能点了很多次，但业务没有变好。

如果只看业务指标，结果变化了，却不知道是模型、产品、运营、客群还是实验分流造成的。

如果只做模型评测，离线分数可能不错，但线上用户不采纳，成本也不可控。

如果没有数据建模，上面所有问题最后都会变成临时 SQL、口径争论和无法复盘的截图。

企业要的不是 AI 功能，而是价值

企业不会长期为“用了 AI”买单，只会为更好的业务结果买单。常见价值大致可以分成五类。

第一类是增长价值。AI 是否帮助业务多赚钱？例如销售转化率、成交金额、客单价、复购率、线索利用率是否提升。

第二类是降本价值。AI 是否降低完成任务的成本？例如人工处理时间、重复劳动、单次服务成本、模型调用成本是否下降。

第三类是提效价值。AI 是否让人和流程更高效？例如响应速度、任务完成时间、新人上手速度、跨部门流转效率是否改善。

第四类是质量价值。AI 是否让结果更稳定、更准确、更一致？例如错误率、投诉率、人工修改率、知识库命中率、幻觉率是否改善。

第五类是风控价值。AI 是否可控、可追踪、可审计？例如是否有错误承诺、隐私泄露、违规回答、不可解释决策，以及异常发生后能否回滚和追责。

这些价值不是写在汇报 PPT 里的口号，而应该反向决定 AI 项目的指标、数据模型、埋点、看板、评测和实验。

从价值倒推指标

指标不是为了看起来专业，而是为了回答业务问题。

以 CRM AI Agent 或销售话术推荐为例，如果目标是“提升销售转化”，真正要看的不是“生成了多少条话术”，而是：

推荐是否被销售看到？
销售是否点击、复制或采纳？
采纳后转化是否更高？
哪些客户场景下更有效？
是否帮助新人销售更快成长？
是否带来更高投诉或错误承诺风险？

这里至少会出现四层指标。

第一层是业务价值指标，用来回答 AI 有没有创造真实业务结果：

转化率
成交率
成交金额
会员充值率
客单价
投诉率
客户满意度
销售人均产出

第二层是产品使用指标，用来回答 AI 有没有进入真实工作流：

曝光率
点击率
采纳率
复制率
使用率
留存率
正反馈率
负反馈率
人工修改率

第三层是模型质量指标，用来回答 AI 输出到底对不对：

意图识别准确率
推荐相关性
事实一致性
幻觉率
违规率
工具调用成功率
人工标注通过率
LLM-as-Judge 评分

第四层是工程稳定指标，用来回答 AI 系统能不能稳定、便宜、快速地跑：

错误率
超时率
p50 / p95 / p99 延迟
首 token 延迟
模型调用成功率
缓存命中率
输入 token
输出 token
单次调用成本
单次有效推荐成本

AI 项目经常不是死在“模型完全没效果”，而是死在更具体的问题上：太慢、太贵、不稳定、用户不信任、无法定位问题、无法解释结果、无法回滚版本。

从指标倒推数据模型

有了指标之后，还要继续往后倒推：

这些指标需要哪些数据？
这些数据从哪里来？
用什么 ID 关联？
一行数据代表什么？
字段是否足够归因？
版本信息是否完整？

这就是数据建模。

数据建模的核心不是“建几张表”，而是确保未来的问题能被数据回答。

在 CRM AI Agent 里，常见实体包括：

销售
客户
通话
会话
推荐
意图
反馈
订单
模型调用
实验
评测样本
人工标注

对应的 ID 可能包括：

sales_id
customer_id
call_id
conversation_id
recommendation_id
intent_id
feedback_id
order_id
llm_call_id
trace_id
experiment_id
case_id

这里有一条非常朴素但重要的原则：

没有 ID，就没有关联。没有关联，就没有归因。没有归因，就无法优化。

事件也要围绕未来分析问题设计。比如一次推荐，不只是记录“生成成功”，还应该能回答它有没有曝光、有没有点击、有没有复制、有没有采纳、有没有反馈、最终是否影响业务结果。

一个推荐事件至少应该尽量带上这些字段：

user_id
customer_id
call_id
conversation_id
recommendation_id
trace_id
scene
intent
model_version
prompt_version
workflow_version
experiment_group
timestamp

这些字段决定后面能否分析：

哪个模型更好？
哪个 prompt 更好？
哪个场景效果差？
哪个销售不使用？
哪个客户类型更容易转化？
是不是延迟导致采纳率下降？

数据建模里还有一个经常被低估的概念：粒度。

粒度就是一行数据代表什么。

一行 = 一通电话
一行 = 一次推荐
一行 = 一次点击
一行 = 一次模型调用
一行 = 一个销售一天的汇总
一行 = 一个评测样本的结果

粒度不清，指标一定会乱。

比如“推荐采纳率”到底是按推荐次数算，按通话数算，按销售人数算，还是按客户数算？不同粒度下，结论可能完全不同。

一个最小但可用的数据模型

如果以销售 AI 推荐为例，一个最小可用的数据模型至少要覆盖几类事实表。

通话事实表

粒度：

一行 = 一通电话

它回答的是：这通电话发生了什么业务结果？

核心字段可以包括：

call_id
sales_id
customer_id
start_time
end_time
duration
call_result
converted
order_amount
complaint_flag

模型调用事实表

粒度：

一行 = 一次模型调用

它回答的是：模型调用是否成功、花了多久、花了多少钱？

核心字段可以包括：

llm_call_id
trace_id
recommendation_id
model_name
model_version
input_tokens
output_tokens
latency_ms
cost
status
error_code
prompt_version
created_at

反馈与标注事实表

反馈表回答的是：用户为什么觉得推荐好或不好。

标注表回答的是：AI 输出经过人工判断后到底对不对。

这两类数据很重要。没有它们，团队只能知道“采纳率下降了”，但很难知道下降是因为意图识别错、话术不相关、客户画像缺失、销售不信任，还是推荐出现得太晚。

为什么还需要分析宽表

事实表适合保留清晰粒度，但实际分析时，工程师、产品、业务不可能每次都手工 join 很多表。

所以还需要一张面向分析的宽表，例如：

ads_ai_recommendation_analysis_wide

粒度仍然是：

一行 = 一次 AI 推荐

但字段可以同时包含推荐、销售、客户、模型版本、Prompt 版本、实验分组、反馈、转化和成本信息。

这张表可以直接支持：

推荐采纳率分析
转化率分析
不同模型版本对比
不同 prompt 版本对比
不同销售团队对比
不同客户类型对比
延迟和采纳率关系分析
负反馈归因分析

很多 AI 项目后期分析困难，不是因为没有日志，而是因为日志、事件、业务结果、反馈和版本信息没有被设计成同一个可分析对象。

从看板到告警，再到归因

有了数据模型，才能做看板。一个完整的 AI 产品看板不应该只有工程监控，至少要分成四层：

业务效果看板：AI 有没有创造价值？
产品使用看板：用户有没有真的使用？
模型质量看板：AI 是否做对？
工程稳定性看板：系统是否正常？

看板用于观察，告警用于行动。

AI 项目的告警也不应该只盯错误率和延迟。推荐点击率突然下降、采纳率突然下降、负反馈率突然上升、某类意图错误率上升、违规话术率上升、采纳推荐后的成交率下降，都应该进入监控体系。

但发现问题只是第一步，真正重要的是归因。

例如：

推荐采纳率下降。

这时不能直接说“模型变差了”，而要继续拆：

是哪个销售团队下降？
是哪个客户类型下降？
是哪个意图场景下降？
是哪个模型版本下降？
是哪个 prompt 版本下降？
是否延迟升高？
是否推荐曝光减少？
是否负反馈集中在某类错误？
是否新销售更多导致整体下降？

归因的目标不是解释过去，而是指导下一步优化。最后应该能形成类似这样的判断：

本周负反馈主要集中在“客户发货少”场景。
模型容易把“发货频率低”误判为“无充值意愿”。
这导致推荐话术过度推销，销售采纳率下降。
下一步应补充该场景样本，优化意图分类，并加入回归评测。

这时数据才真正变成了工程改进的输入。

优化必须回到实验

AI 项目不能只靠感觉优化。

如果要上线一个新 Prompt，可以这样设计实验：

实验组：新 Prompt
对照组：旧 Prompt
分流单位：销售 / 通话 / 客户
主指标：推荐采纳率
辅助指标：正反馈率、意图识别准确率、采纳后转化率
护栏指标：p95 延迟、单次成本、负反馈率、投诉率、违规率

实验最终要回答的不是“新版本看起来更聪明”，而是：

新版本是否真的更好？
好在哪里？
对哪些场景更好？
有没有副作用？
是否值得全量？
是否需要回滚？

模型输出有随机性，用户场景也复杂。只靠几条 case 判断好坏，很容易把偶然样本误判成系统性提升。

数据型工程师需要什么能力

从企业价值倒推，AI 时代的数据型工程师至少需要八类能力。

第一，业务理解能力。能回答这个功能服务谁，业务目标是什么，公司真正想改善什么，用户真实工作流是什么，哪些指标代表真实价值。

第二，指标设计能力。能设计北极星指标、主指标、辅助指标、护栏指标、漏斗指标、留存指标、成本指标和质量指标。

第三，数据建模能力。能设计事件模型、事实表、维度表、宽表、快照表、评测数据表、实验分组表和指标口径文档。

第四，埋点与采集能力。能设计事件名、触发时机、必填字段、ID 关联、版本字段、实验字段、trace_id 贯穿和数据完整性检查。

第五，查询与分析能力。能用 SQL、分群分析、漏斗分析、版本对比、转化分析、成本分析和质量分析定位问题。

第六，可观测能力。能建设日志、指标、Trace、Dashboard、Alert，并支持错误率、延迟、成本和下钻排障。

第七，模型评测能力。能建设评测集、黄金集、人工标注、LLM-as-Judge、离线评测、线上评测、Prompt 回归测试、模型对比和错误分类体系。

第八，实验与复盘能力。能设计 A/B 测试、实验分流、主指标验证、护栏指标检查、分群分析、实验复盘、上线和回滚决策。

这些能力合在一起，指向的不是“会写更多代码”，而是能把 AI 从功能带到业务闭环。

成熟 AI 项目的标准产物

一个成熟的 AI 项目，不应该只有代码和接口文档，还应该有这些产物：

业务目标说明
指标体系文档
埋点设计文档
数据模型设计文档
指标口径文档
Grafana / BI 看板
LLM 评测集
人工标注规范
错误归因分类表
A/B 实验方案
实验复盘报告
版本变更记录

这些文档不是形式主义，而是 AI 项目从 demo 走向真实业务系统的标志。

最后的判断

AI 时代，工程师的价值会从“把功能做出来”继续往后延伸：

把功能做出来
  ↓
让系统稳定运行
  ↓
让用户真的使用
  ↓
让 AI 输出可靠
  ↓
让业务指标变好
  ↓
让问题可以归因
  ↓
让系统可以持续优化

所以，真正稀缺的不是单纯会写代码、会调 Prompt、会搭 Demo 的人，而是：

能把业务问题翻译成指标，把指标翻译成数据模型，把数据模型变成埋点和采集，把数据变成查询和看板，把异常变成归因，把优化变成实验，最后证明 AI 真的创造价值的人。

可观测让系统可控，产品分析让用户行为可见，业务分析让价值可衡量，模型评测让 AI 质量可判断，数据建模让所有问题可回答。

这五者合起来，才是 AI 产品真正的工程闭环。