面对 AI 的冲击，数据及开发领域还有哪些真正的机会？

先同步一些特殊情况的重要说明

朋友们，我从易问/亿问离职了，以后与易问/亿问再无瓜葛，从此一别两宽，各自安好～

我决定自己独立出来做点真正自己想做的事情，比如高质量的AI & 大数据技术社区、OPCS（一人公司操作系统）、技术自媒体的持续高质量更新、Doris & StarRocks 的运维兜底以及 AI 方向的落地工程。

公司起名“元一”，寓意归元化一，不想整太复杂的东西，就是希望回归到对技术、社区、本质事务的专注和热情上来，而且通过简单的方式能把复杂的东西给大家传递的更为易于理解，而非炫技和故作高深。

包括我提出的本体化语义层等工程实践，我也会逐步的在 AI4Data 和 元一OPCS 两个账号上选择合适的受众给大家做落地方案的建议和参考，大家可以期待一手（没关注新 AI 账号的火速关注一波，避免错失高质量内容，哈哈哈）。

最后很多人会疑惑，你上面想做那么多事，就你一个人么？

非也，我决定出来干的时候，一帮信任我的行业大牛也选择了和我一起同行，我们每个方向都有很专业的选手，也希望在公司能存活下去和长久发展下去的同时，能给这个日益浮躁的圈子，带来一些些正能量，不要给大家传播焦虑了，只要是在前行，那就永远不晚。

感谢各位长久以来的支持～

引言：机会没有消失，只是从单点技能转向复合能力

过去半年，我听到很多技术同学问同一个问题：

大模型把代码、SQL、报表、文档都写得越来越快了，数据和基础开发领域接下来还有什么机会？

这个问题背后有一层真实焦虑。

过去很多岗位的护城河来自单点技能。你会写 SQL，会调数据库，会写后端接口，会做报表，会配一套数据同步链路，就可以在组织里形成稳定价值。

大模型进来以后，单点技能的价格确实会被压低。

一个初级工程师过去花半天写的 CRUD，现在可能几分钟能生成；一个分析师过去反复改的查询，现在可以由模型先写出初稿；一个产品经理过去需要排半天结构的 PRD，现在也能被 AI 托一把。

但我并不悲观。

机会没有消失，真正变化的是机会的形态。

未来时间，数据和基础开发领域最值得关注的机会，会从“我会不会某个工具”转向“我能不能把工具、系统、业务、成本、治理和 AI 协作方式一起建起来”。

换句话说，单点执行型技能会继续贬值，复合建设型能力会变得更贵。

这篇文章我想聊七类我认为真实存在、而且值得技术人投入的方向：

• • OLAP 复合专家
• • Harness 工程师
• • 本体化语义层专家
• • AI 可观测与智能运维
• • Data Agent 产品/方案架构师
• • 数据与 AI 成本治理专家
• • 连接器与执行层工程师

这些方向听起来不如“提示词工程师”那么热闹，也不如“全栈 Agent 创业”那么刺激。

但企业最终会为一类人付钱：能把 AI 能力接进生产系统、让它稳定运行、让它算得清账、让它承担责任的人。

一、OLAP 复合专家：把分析型数据库变成业务系统底座

过去提到 OLAP，很多人的第一反应还是报表、BI、数仓查询、聚合加速。

这个理解没有错，但已经偏窄了。

今天的分析型数据库正在承担更多混合型工作：实时指标、用户行为分析、日志与指标观测、搜索、向量检索、JSON 半结构化分析、湖仓加速、Agent/RAG 的检索底座。

比如 Apache Doris 现在也把场景扩展到了 customer-facing analytics、data warehousing、observability、Doris for AI 等方向，强调实时分析、搜索、日志指标分析，以及面向 AI 的向量、文本、JSON 统一 SQL 检索能力。

这背后意味着一件事：

OLAP 不再只是“分析系统的查询引擎”，它会越来越像业务系统和 AI 系统之间的高性能事实底座。

企业过去喜欢把 OLAP 放在经营分析链路的末端。业务系统写入 OLTP，数据进入数仓或湖仓，最后 BI 查询。这个链路适合离线分析，但对 AI Agent 来说经常太慢、太散、太难解释。

Agent 要回答一个经营问题，往往需要同时查指标、明细、日志、实体状态、最近事件、历史趋势、异常窗口。它需要的已经超出单纯报表库，必须是一套能支撑实时、交互、低延迟、多模型数据访问的分析底座。

所以未来真正值钱的 OLAP 专家，不能只会调 SQL。

他至少要懂五件事：

• • 数据建模：事实表、维表、明细表、宽表、事件表怎么取舍，如果是面向 AI Native 的未来基座，还一定要做四层划分么？
• • 引擎机制：分区、分桶、索引、物化视图、向量化、缓存、冷热分层。
• • 查询模式：高并发报表、Ad-hoc 分析、日志检索、半结构化查询、向量检索各自有什么代价。
• • 业务系统：哪些查询会进入用户实时路径，哪些查询只能用于后台分析。
• • AI 负载：RAG、Agent Trace、工具调用日志、训练/推理观测数据会怎样冲击存储和查询。

这类人未来会非常关键，因为企业会越来越多地把 OLAP 当成“实时事实层/语义层”来使用。

技术人的进入方式也很清晰。

不要只停留在“我会部署 Doris / ClickHouse / StarRocks”。更好的练法是围绕一个真实业务域做端到端建设：

• • 设计一套交易、履约、退款、会员、商品的分析模型；
• • 同时支撑经营看板、明细追查、异常分析和 Agent 查询；
• • 压测不同查询模式下的延迟、资源、并发和成本；
• • 把查询慢、口径乱、热点表膨胀、权限控制这些问题真正跑一遍。

OLAP 机会的本质，不在于又多了一个数据库岗位。

未来值钱的是能把分析型数据库放进业务闭环里的人。

只会调一个慢 SQL，价值会下降；能设计一套支撑经营、观测、检索和 Agent 执行的分析底座，价值会持续上升。

二、Harness 工程师：AI Coding 时代最缺的是能管住 AI 的人

AI Coding 的效率已经不用再争论。

现在真正的问题变成：如何让它在复杂工程里持续稳定地产出，避免每次靠运气。（Code 抽卡师 -_-|| ）

很多人第一次用 AI 写代码，会觉得世界一下轻松了。让它生成页面、补接口、改样式、写测试，速度确实很快。

但只要项目复杂度上来，问题立刻出现：

• • 它会改动无关文件；
• • 它会重复造已有能力；
• • 它会绕过真实测试；
• • 它会误读业务边界；
• • 它会生成看起来能跑、长期维护很痛苦的代码；
• • 它会在长任务里逐渐偏离最初目标。

所以 AI Coding 时代真正稀缺的人，不一定是手写代码最快的人。

真正稀缺的是能设计 Harness 的工程师。

这里的 Harness，指的是一整套把 AI 开发约束在工程流程里的方法：

• • 需求澄清 → spec 设计 → 可执行计划 → 任务台账 → 测试门禁 → 代码审查 → 回归验证 → 浏览器拟真测试 → 版本提交 → 失败复盘

说得更直接一点，AI 可以当执行者，但工程责任还得有人接住。

一个好的 Harness 工程师，会把 AI 的能力拆进可验证流程里。他不会简单说“帮我做一个系统”，他会先让 AI 明确：

• • 这个系统的角色边界是什么；
• • 哪些数据可以读写；
• • 哪些流程必须人工确认；
• • 哪些功能属于第一版本；
• • 哪些测试必须通过；
• • 哪些文件不能改；
• • 完成的证据是什么。

这个方向未来会很重要，因为企业很快会发现：AI Coding 提效是基础，AI Coding 失控才是成本。

过去一个工程师写错代码，影响范围通常有限。Agent 化开发开始普及后，一个错误指令可能同时改十几个文件、启动多条任务链、批量生成架构债。

这个时候，能不能写代码只是底层能力。更关键的是能不能把 AI 放进一套生产级开发制度里。

未来三年，会出现一类很有价值的工程角色：

• • 会用 AI 写代码；
• • 会拆任务；
• • 会设计测试；
• • 会建立代码边界；
• • 会做长任务追踪；
• • 会用自动化和浏览器测试验证真实交互；
• • 会把 AI 产出纳入 Git、CI、Review、Release 流程。

这类人不一定叫 Harness 工程师，也可能叫 AI 工程效能工程师、Agentic Development Engineer、AI SDLC Engineer。

名字不重要。

核心能力是：把 AI 从“会写代码的助手”，训练成“受工程制度约束的生产力”。

这件事很难被单纯模型升级吃掉，因为它处理的是工程过程质量，单次生成质量只占其中一小部分。

三、本体化语义层专家：帮 AI 看懂企业业务世界

我一直觉得，Data Agent 领域最容易被低估的方向，就是语义层。

原因很简单：语义层听起来不性感。

市场更喜欢讲大模型、多智能体、自动分析、秒级出报告、老板一句话看经营。

可是只要进入真实企业，你会发现最难的问题经常不在模型，而在业务世界本身。

什么叫收入？

什么叫有效订单？

退款发生后，GMV 怎么算？

客户、合同、订单、支付、发票、履约之间是什么关系？

一个用户问“华东最近下滑的原因是什么”，这里的“华东”是销售区域、仓配区域、门店大区，还是组织架构里的管理片区？

这些问题没有解决，模型再强也只能猜。

传统指标语义层解决了非常重要的一部分问题：指标口径、维度、时间粒度、聚合规则、权限消费。

这套能力对 ChatBI、标准报表、自助取数仍然有价值。

但 Data Agent 要往前走一步。它不只要回答“这个数是多少”，还要解释“这件业务事为什么发生”，甚至给出“接下来应该怎么处理”的建议。

走到这里，企业需要更强的语义层形态。

依旧，我更愿意称它为本体化语义层。

它关注的不只是指标和维度，还包括：

• 业务对象：客户、商品、订单、门店、合同、设备；

• • 业务事件：下单、支付、退款、发货、签约、流失、复购；
• • 对象关系：客户拥有订单、订单包含商品、合同关联回款；
• • 状态生命周期：订单从创建到支付到履约到售后；
• • 时间语义：自然月、财务月、活动期、履约周期、归因窗口；
• • 权限边界：谁能看什么字段、什么明细、什么敏感对象；
• • 动作约束：什么情况下能写回、审批、创建任务、触发补偿。

这类专家未来会非常稀缺，因为它横跨三层能力：

• • 业务理解：能把企业运行方式建模成对象、事件、状态和规则。
• • 数据建模：知道这些语义如何落到表、字段、指标、关系和查询。
• • Agent 执行：知道自然语言如何变成可验证的中间计划，再变成 SQL、API 或动作。

很多企业今天做 Data Agent，容易在两个地方掉坑。

第一个坑是直接 NL2SQL。用户问一句，模型直接生成 SQL。演示时很惊艳，进入复杂业务口径后稳定性很难保证。

第二个坑是只建指标语义层。能查指标，但一旦问题进入归因、路径、状态、跨对象分析，就会明显吃力。

本体化语义层专家的价值，在于把“机器能理解的业务世界”建出来。

如果企业希望 AI 不靠猜来回答经营问题，就必须把业务世界建成可执行、可解释、可治理的语义模型。

这类岗位未来可能出现在数据平台厂商、咨询公司、企业数据中台团队、Agent 产品团队，也可能以解决方案架构师的方式存在。

对个人来说，最好的训练方法也很朴素：不要从抽象概念开始，直接选一个业务域建模。

比如电商：

• • 用户、订单、商品、支付、退款、物流、优惠券怎么建对象；
• • 下单、支付、退款、签收、售后怎么建事件；
• • GMV、净销售额、退款率、复购率怎么定义；
• • 跨对象分析怎么走关系路径；
• • 用户问一个归因问题时，中间逻辑计划应该长什么样；
• • 最终 SQL、权限、解释、Trace 怎么落地。

能把这一整套打通的人，会比只会讲“语义层很重要”的人值钱得多。

四、AI 可观测与智能运维：看见 Agent 为什么错、贵、慢

企业上 AI Agent 以后，很快会遇到三个朴素问题：

• • 为什么错？
• • 为什么慢？
• • 为什么贵？

这三个问题如果回答不了，Agent 很难进入生产系统。

传统可观测主要看服务、接口、数据库、容器、主机、日志、指标、链路追踪。AI 系统来了以后，观测对象变复杂了。

一次 Agent 调用可能包含：

Note 用户问题、上下文选择、模型路由、Prompt 版本、工具调用、检索结果、中间推理、多轮计划、子任务分派、权限校验、结果校验、成本消耗、人工接管。

过去的 APM 很难完整解释这些东西。

所以 AI 可观测会成为未来三年的硬需求。

OpenTelemetry 已经在推进 GenAI 语义约定，把生成式 AI 的 events、exceptions、metrics、model spans、agent spans 等作为标准化观测对象来描述。这说明行业已经开始意识到：AI 负载需要自己的观测语义。

但标准只是一层起点。

企业真正需要的是一套能回答业务问题的智能运维系统：

• • 这次回答错在哪一步？
• • 是召回错了、工具错了、SQL 错了、权限错了，还是模型理解错了？
• • 哪类用户问题最容易失败？
• • 哪个工具调用最贵？
• • 哪个模型路由性价比最低？
• • 哪条 Agent 链路经常超时？
• • 哪些失败可以自动修复，哪些必须人工处理？

这类岗位很可能从传统 SRE、平台工程、数据平台运维、可观测工程师里演化出来。

但它要求补一层 AI 系统理解。

你要知道模型调用的输入输出怎么采样，Prompt 版本怎么管理，工具调用怎么打 Trace，Token 成本怎么归因，错误怎么分类，敏感信息怎么脱敏，用户反馈怎么进入回归集。

未来的 AI 运维，不只是把系统跑起来，还要把 Agent 的每一次判断变成可追踪证据。

这也是为什么我很看好“AI 可观测 + 智能运维”这个方向。

它不像应用层 Demo 那么耀眼，但所有企业级 Agent 最后都要过这一关。

五、Data Agent 产品/方案架构师：把问数推进到分析和交付

过去 ChatBI 的核心动作是问数。

用户问“本月销售额是多少”“按区域看一下订单量”“近 30 天退款率怎么样”，系统返回图表或表格。

这个能力有价值，但它只是经营分析链路里的第一步。

真实企业里，一个经营问题通常很难靠一次问答结束。

比如老板问：“为什么华东这个月利润下滑？”

一个合格的 Data Agent 需要继续往下走：

• • 先确认利润口径；
• • 拆收入、成本、费用、退款、折扣、履约等因素；
• • 看时间窗口和同比环比；
• • 定位异常区域、渠道、商品、客户群；
• • 下钻到明细和事件；
• • 给出归因假设；
• • 形成报告；
• • 分发给相关责任人；
• • 跟进后续动作。

这里面有数据查询，也有分析方法、业务理解、报告结构、协同流程和交付设计。

所以未来会出现一类很重要的角色：Data Agent 产品/方案架构师。

这类人既不能只像产品经理，也不能只像数据工程师。

他要能把一个模糊的经营场景，拆成可交付的 Agent 工作流：

• • 用户是谁；
• • 问题从哪里来；
• • 数据在哪里；
• • 口径怎么确定；
• • 分析路径怎么组织；
• • 哪些结论必须可解释；
• • 哪些节点需要人确认；
• • 最终交付物是图表、报告、任务，还是业务动作；
• • 如何验证这个 Agent 真正提高了经营分析效率。

这类机会很真实，因为企业买 Data Agent，最终买的远远超出一个聊天入口。

企业买的是一套新工作方式：让数据从“被查询”推进到“能分析、能解释、能交付、能进入流程”。

Data Agent 的产品机会，不在于把问答做得更像聊天，而在于把分析链路做得更像可复用的业务流程。

这类架构师未来会站在售前、产品、交付、客户成功和技术团队之间。

他需要懂数据平台，也要懂业务场景；需要懂 AI，也要懂企业里的责任边界；需要能画产品图，也能判断底层语义和执行链路能不能支撑。

这类人短期很难培养，因为它很难靠一门课学出来。

但如果你已经在数据分析、BI、数仓、产品、售前、解决方案里做过几年，现在正好是一个很好的转型窗口。

不要只学提示词。

去学怎么把一个经营问题拆成数据链路、语义链路、分析链路、交付链路。

六、数据与 AI 成本治理专家：企业最终会为可控成本买单

过去企业做数据成本治理，重点通常是云资源、存储、计算、任务调度、闲置集群、SQL 扫描量、冷热数据。

AI 加进来以后，成本治理会变得更复杂。

一次 AI 应用的成本，可能包含：

Note 模型输入 Token、输出 Token、推理深度、上下文长度、缓存命中、工具调用、Web 搜索、容器执行、向量检索、数据库查询、多 Agent 协作、失败重试、人工审核

如果企业只看最终账单，很快会陷入一种状态：知道贵，但不知道贵在哪里。

FinOps Foundation 已经把 FinOps for AI 单独列成技术类别，重点讨论 AI 成本复杂度、研发周期变快、支出不可预测、政策与治理需求、成本分摊、预测和优化等问题。

这个方向我非常看好。

原因很简单：AI 应用一旦进入企业，成本会从“少数研发团队的实验费用”变成“多部门、多模型、多工具、多场景的持续支出”。

没有成本治理，AI 项目很容易出现三类问题：

• • Demo 阶段看起来便宜，规模化后账单失控；
• • 每个团队各买各的工具，企业看不到总体投入；
• • 模型效果提升了一点，但成本增长超过业务收益。

OpenAI 官方 API 价格页也能看到，高阶模型、实时语音、图像生成、Web Search、容器执行、Batch、Flex、Reserved Capacity 等不同计费方式已经非常复杂。价格本身会继续变，但复杂计费结构会长期存在。

所以未来会出现一类“数据与 AI 成本治理专家”。

他不只是财务 FinOps，也不只是云成本优化。

他要能把技术路径和业务收益连起来：

• • 哪些任务可以用小模型；
• • 哪些任务必须用强模型；
• • 哪些上下文可以缓存；
• • 哪些请求可以批处理；
• • 哪些工具调用可以合并；
• • 哪些 Agent 链路应该设置预算上限；
• • 哪些模型输出需要质量抽检；
• • 哪些成本应该归属到部门、项目、用户或客户。

企业最终不会单纯为“更智能”买单，它会为可衡量、可解释、可控制的智能买单。

这个方向适合三类人进入：

• • 懂云成本和 FinOps 的人；
• • 懂数据平台和资源调度的人；
• • 懂 AI 应用链路和模型调用的人。

未来三年，谁能把“效果、延迟、成本、风险”放在同一张账本里，谁就会很值钱。

七、连接器与执行层工程师：让 Agent 进入真实系统

很多 Agent 产品最大的问题，是只能停留在聊天窗口。

它能回答问题，能写计划，能生成报告，但很难真正进入企业系统做事。

企业真实系统很复杂：

Note CRM、ERP、OA、工单系统、财务系统、数据库、知识库、IM、邮件、文档、自研后台、各种老系统和权限体系

Agent 想产生价值，最终必须接进这些系统。

所以连接器与执行层工程师会变得越来越重要。

MCP 的流行，本质上就是行业开始集中解决“模型如何连接外部工具、数据源和系统”的问题。Anthropic 在 2025 年 12 月把 MCP 捐给 Linux Foundation 下的 Agentic AI Foundation，并提到 MCP 已被 ChatGPT、Cursor、Gemini、Microsoft Copilot、VS Code 等产品采用，还出现了大量 MCP server 和基础设施部署支持。

这说明一个趋势：Agent 时代不会缺聊天入口，真正稀缺的是连接真实系统的安全执行层。

但连接器工程并不简单。

很多人以为连接器就是调 API。真实生产里，最麻烦的恰恰在 API 周围：

• • 身份认证怎么做；
• • 权限怎么继承；
• • 工具边界怎么描述；
• • 参数怎么校验；
• • 幂等怎么保证；
• • 写操作怎么审批；
• • 失败怎么重试；
• • 超时怎么处理；
• • 审计怎么记录；
• • 敏感数据怎么脱敏；
• • 调错工具怎么拦截；
• • 人工接管怎么设计。

如果这些问题没有解决，Agent 接入系统越多，风险越大。

未来，连接器与执行层工程师会是非常底层、但非常重要的机会。

这类人要懂 API，也要懂权限；懂系统集成，也要懂 Agent 行为；懂工具协议，也要懂企业安全；懂执行，也要懂回滚。

Agent 真正进入企业，不靠多一个聊天框，靠的是一层可信的连接与执行基础设施。

这也是基础开发领域很值得投入的方向。

看起来不够热闹，但每一个严肃的企业 AI 项目都会需要它。

写在最后：技术人的新护城河，是复合建设能力

回到开头那个问题：未来 3 年，数据和基础开发领域还有哪些真正的机会？

我的判断很明确。

单点技能的机会会继续变少，复合建设能力的机会会继续变多。

会写 SQL 仍然有用，但只会写 SQL 的溢价会下降。

会写代码仍然有用，但只靠手速写代码的溢价会下降。

会调一个数据库、接一个 API、写一个报表、做一个 Demo，都还会有需求，但这些能力会越来越容易被 AI 补齐。

真正难补齐的是另一类能力：

• • 能把业务问题建模成系统结构；
• • 能把 AI 生成纳入工程 Harness；
• • 能把语义、权限、执行、观测、成本一起设计；
• • 能把 Demo 推进到生产；
• • 能把单次回答推进到持续交付；
• • 能把技术能力转成组织可运营的工作流。

未来技术人的新护城河，不在某个单点工具，也不在某个热门名词上。

新护城河是复合建设能力。

你能不能把数据库、语义层、Agent、工程流程、可观测、成本治理、系统连接放在同一张图里思考。

你能不能知道模型能做什么，也知道它什么时候该被约束。

你能不能既理解业务现场，又能把它落成可执行、可验证、可审计的系统。

接下来的时间，真正值得投入的方向，大概率都在这里。

它们不一定最热闹，但会越来越接近企业愿意长期付费的地方。

好了，行文至此，来个“点赞”、“在看”和“转发”吧，这是唯一动力了～