世界上的相遇 都是久别重逢~
平时和圈内不少同行喝酒聊天，大家的焦虑几乎一模一样：现在大模型写 CRUD 比初级工程师快 10 倍，生成 SQL 比分析师准，连 PRD 都能写得有模有样，那我们这些做数据、做基础开发的，再过两年会不会真的没饭吃？
我从来不这么悲观。机会从来没有消失，只是从 “卖苦力的执行层”，转移到了 “定规则的建设层”。
过去你会写 SQL、会搭集群、会调接口，就能拿高薪，因为这些是稀缺的 “硬技能”。但 AI 本质上就是一个 “超级执行器”，所有能被标准化、流程化的单点技能，都会被它快速拉平到一个极低的价格。而那些需要理解业务、权衡利弊、建立规则、承担责任的能力，恰恰是 AI 最薄弱的地方，也是未来 3-5 年最值钱的地方。
下面这 7 个方向，我没有照搬任何行业报告，全是基于我自己踩过的坑、和几十位大厂技术负责人交流后的真实判断。每个方向我都会讲透本质是什么、企业为什么愿意付钱、普通人怎么切入、以及最容易踩的坑。
一、OLAP 复合专家：不是 “调数据库的”，是 “AI 时代的数据建筑师”
很多人对 OLAP 的理解还停留在 “跑报表的工具”，这是最大的误区。现在的 OLAP，已经变成了整个企业的 “实时事实中枢”—— 不仅要给人看报表，还要给 AI 喂数据。
我举个最直观的例子：某头部电商公司，过去的数仓架构是 “业务库→数仓→BI”，用户查个销售额，等个十几秒很正常。但自从他们上线了智能经营 Agent 后，这个架构彻底崩了。因为 Agent 不是只查一个数，它会一口气查 100 多个指标：昨天的 GMV、退款率、客单价、各个渠道的转化、每个商品的库存、最近 30 天的复购…… 而且要求所有结果在 1 秒内返回，不然用户就会觉得 “这个 AI 好笨”。
这时候你会发现，传统的数仓分层、宽表设计，完全不适用了。原来的思路是 “提前算好所有指标，用户查的时候直接拿”，但 AI 的查询是随机的、多维度的、跨表的，你根本不可能提前算完所有组合。
所以现在的 OLAP 复合专家，干的根本不是 “调优 SQL” 的活，而是重新设计一套适合 AI 的数据架构。他需要解决的问题是：
哪些数据要存在 OLAP 里，哪些要存在向量数据库里，哪些要存在对象存储里？ 怎么设计表结构，才能让 AI 同时查指标、明细、日志、向量的时候都快？ 怎么平衡实时性和成本？比如交易数据要秒级更新，历史数据可以按天更新。 怎么给 AI 做权限控制？比如不能让 AI 查到用户的手机号和身份证号。
最容易踩的坑：很多人以为学个 Doris、StarRocks 的部署和调优就够了。错了。我见过太多只会敲alter table add partition的 DBA，现在根本找不到工作。企业要的不是 “会用数据库的人”，而是 “能用数据库解决业务问题的人”。
普通人怎么切入：找一个你最熟悉的业务域（比如电商、教育、金融），从头到尾搭一套完整的分析系统。不要只搭数仓，还要在上面接一个简单的 RAG 或者 Agent，模拟 AI 查询的场景。然后自己给自己找茬：如果同时有 100 个 Agent 并发查询，系统会不会崩？如果某个查询扫描了 10TB 数据，怎么优化？如果业务改了指标口径，怎么让 AI 自动同步？
当你能把这些问题都解决了，你就不是一个普通的 DBA，而是一个能给 AI 建底座的 “数据建筑师”，年薪至少翻一倍。
二、Harness 工程师：不是 “写代码的”，是 “AI 开发的交通警察”
AI 编码现在有多火，不用我多说。但只要你真的用它做过一个超过 10 个文件的项目，就会发现一个致命问题：AI 写代码是“无政府主义” 的。
我前段时间帮一个朋友看他们的项目，他们用 Cursor 写了一个月，结果代码乱得一塌糊涂：同一个工具类写了 5 遍，到处都是复制粘贴的代码，注释全是 AI 生成的废话，连数据库表的主键都有 3 种不同的命名风格。更可怕的是，AI 偷偷改了一个核心接口的参数，导致线上出了一个 P0 级别的事故，查了整整一天才找到原因。
这就是 Harness 工程师存在的意义：给 AI 立规矩。AI 就像一个精力旺盛但不守规矩的孩子，你不能让它随心所欲地写代码，必须给它画好线、定好规则，让它在规则内发挥作用。
一个好的 Harness 工程师，会建立一套完整的 “AI 开发流水线”：
需求拆解：把一个模糊的需求（比如 “做一个用户管理系统”），拆成 AI 能理解的、可执行的小任务，每个任务不超过 100 行代码。 边界划定：明确告诉 AI 哪些文件不能改、哪些函数不能调用、哪些数据不能碰。比如 “绝对不能修改 user_service.py里的login函数”。测试强制：要求 AI 每写完一个函数，必须自动生成对应的单元测试，而且测试覆盖率必须达到 80% 以上，否则不能提交代码。 代码审查：建立 AI 代码的审查规则，比如禁止使用全局变量、禁止写超过 20 行的函数、禁止硬编码。用工具自动扫描，不符合规则的代码直接打回。 长任务追踪：对于需要多轮完成的任务，记录 AI 的每一步操作，如果发现它偏离了目标，及时纠正。
最容易踩的坑：很多人以为 Harness 工程师就是 “给 AI 写提示词的”。错了。提示词只是最表层的东西，核心是工程流程的设计。比如怎么让 AI 自动生成测试用例、怎么把 AI 的产出和现有的 CI/CD 流程结合、怎么衡量 AI 写的代码质量。这些都不是靠提示词能解决的。
普通人怎么切入：从你自己的项目开始，尝试建立一套 AI 开发规范。比如写一个AI_CODING_GUIDE.md，告诉 AI 你公司的代码风格、命名规范、测试要求。然后写一些脚本，自动检查 AI 生成的代码是否符合规范。当你能让 AI 在你的规则下稳定产出高质量代码时，你就已经是一个合格的 Harness 工程师了。
三、本体化语义层专家：不是 “定义指标的”，是 “给 AI 翻译业务语言的人”
这是我认为所有方向里最被低估、也最有前景的一个。因为现在所有 Data Agent 的最大痛点，根本不是模型不够聪明，而是AI 根本听不懂企业的 “黑话”。
我举个真实的例子：某快消公司的老板问 AI：“上个月华东区的销售额为什么下滑了？”AI 给出的答案是 “因为华东区的订单量减少了”。老板气得差点把电脑砸了，这不是废话吗？
为什么会这样？因为在 AI 的认知里，“销售额 = 订单量 × 客单价”，但在企业的真实业务里，“销售额” 有 17 种不同的口径：含税的、不含税的、包含退款的、不包含退款的、按下单时间算的、按支付时间算的、按发货时间算的…… 更不用说 “华东区” 到底指什么了：销售部的华东区是 5 个省，物流部的华东区是 7 个省，财务部的华东区是 3 个省。
传统的指标语义层，只能解决 “这个数是多少” 的问题。而本体化语义层，要解决的是“这件事是什么意思”的问题。它不是一个简单的指标字典，而是一个完整的 “企业业务知识图谱”。
比如在电商领域，一个完整的本体化语义层应该包含：
业务对象：用户、商品、订单、支付、物流、优惠券 对象属性：用户的性别、年龄、注册时间；商品的价格、库存、分类 业务事件：下单、支付、退款、发货、签收、退货 对象关系：一个用户有多个订单，一个订单包含多个商品，一个支付对应一个订单 业务规则：退款后 GMV 要扣除，优惠券的使用条件，物流超时的赔付标准
当 AI 有了这个知识图谱，它才能真正理解老板的问题。比如老板问 “上个月华东区的销售额为什么下滑了”，AI 会先确认：“您指的是不含税、按支付时间统计、不包含退款的销售额吗？您说的华东区是销售部的划分吗？” 得到确认后，再去拆解原因，而不是给出一个废话般的答案。
最容易踩的坑：很多人把本体化语义层和知识图谱混为一谈。知识图谱是技术手段，本体化语义层是业务建模。不要上来就用 Neo4j 建图谱，先拿一张白纸，把你所在行业的业务对象、事件、关系都画出来。如果业务模型错了，再牛逼的技术也没用。
普通人怎么切入：找一个你最懂的行业，比如你在电商公司做过 3 年数据分析师，那你就把电商的整个业务流程拆解清楚，建立一套完整的本体化语义模型。然后用这个模型去做一个简单的 ChatBI，看看它能不能回答复杂的业务问题。当你能把一个行业的业务逻辑用机器能理解的方式表达出来时，你就是这个行业里最值钱的人。
四、AI 可观测与智能运维：不是 “看监控的”，是 “AI 系统的医生”
传统的运维，是“保证系统不宕机”。而 AI 可观测，是“保证 AI 不胡说八道”。
我见过太多公司的 AI 项目，Demo 演示的时候惊艳全场，一上线就翻车：一会儿回答错误，一会儿胡说八道，一会儿突然变慢，一会儿又莫名其妙花了几十万的 Token 费用。最可怕的是，出了问题你根本不知道为什么。
比如有一次，某银行的智能客服Agent 突然开始给所有用户推荐同一款理财产品，导致大量用户投诉。技术团队查了整整3天，才发现是RAG检索的时候，把一个测试用的文档当成了正式文档，导致所有用户的问题都检索到了同一个答案。
这就是没有 AI 可观测的后果。传统的APM 只能告诉你 “API 调用成功了，耗时200ms”，但它不能告诉你：
AI 这次调用用了哪个模型？哪个版本的 Prompt？ 检索到了哪几个文档？相似度是多少？ AI 的推理过程是什么？为什么得出了这个结论？ 这次调用花了多少 Token？成本是多少？ 
一个合格的 AI 可观测系统，需要记录 Agent 的完整生命周期：从用户提问开始，到上下文检索、模型调用、工具调用、结果生成、用户反馈，每一步都要留下痕迹。这样出了问题，你才能像医生看病一样，一步步排查根因。
最容易踩的坑：很多人以为 AI 可观测就是 “加日志”。错了。普通的日志是给人看的，而 AI 的日志是给机器看的。你需要建立一套标准化的 AI 链路追踪规范，比如用 OpenTelemetry 的 GenAI 语义约定，把模型调用、工具调用、检索结果都变成结构化的数据。这样你才能用工具自动分析，比如统计哪类问题的故障率最高、哪个工具调用的成本最大、哪个 Prompt 的效果最好。
普通人怎么切入：如果你是传统的 SRE 或者运维工程师，那恭喜你，你已经有了最好的基础。你只需要补充一点 AI 系统的知识，比如大模型的调用原理、RAG 的工作流程、Agent 的执行逻辑。然后找一个开源的 AI 可观测工具（比如 LangSmith、OpenLLMetry），搭一套完整的监控系统，去监控你公司的 AI 应用。当你能在 10 分钟内定位 AI 的任何问题时，你就成了公司里不可或缺的人。
五、Data Agent产品/方案架构师：不是“做产品的”，是“用AI重构工作流的人”
现在市面上 99% 的 Data Agent 产品，都是 “换皮的 ChatBI”。用户问一个问题，它返回一个图表，然后就没了。但企业真正需要的，不是一个 “会聊天的报表工具”，而是一个“能干活的业务助理”。
我举个例子：某快消公司的区域销售经理，过去每个月要花 3 天时间做月度分析报告：从各个系统里导数据、做 Excel、画图表、写分析、找原因、提建议。现在有了 Data Agent，他只需要说一句 “生成上个月华东区的销售分析报告”，Agent 就能自动完成所有工作：
从 CRM 里导出来销售数据，从 ERP 里导出来库存数据，从物流系统里导出来发货数据 计算各个指标的同比环比，定位异常的区域、渠道和商品 分析异常原因：比如某个商品的销量下滑，是因为库存不足，还是因为竞争对手降价 生成一份完整的 PPT 报告，包含图表、分析和建议 把报告发送给相关的负责人，并创建一个任务，跟进库存补充的进度
这才是 Data Agent 真正的价值：不是代替人查数，而是代替人完成整个工作流程。
而 Data Agent 产品 / 方案架构师，就是设计这个工作流的人。他需要回答的问题是：
这个岗位的人平时都在做什么？哪些工作可以交给 AI？ 完成这个工作需要哪些数据？这些数据在哪里？ 这个工作的流程是什么？哪些节点需要人工确认？ 怎么衡量 AI 做的好不好？比如报告的准确率、完成的时间。
最容易踩的坑：很多产品经理做 Data Agent，上来就追求 “自然语言交互”，把所有功能都做成聊天框。错了，自然语言只是交互方式之一，不是目的。比如生成报告，最好的方式不是让用户一句一句说，而是给用户一个模板，让用户选择时间、区域、指标，然后AI自动生成。过度追求自然语言，只会让产品变得难用。
普通人怎么切入：如果你是数据分析师、BI 产品经理或者解决方案架构师，那你有天然的优势。因为你最懂企业的业务流程。你可以从你自己的工作开始，尝试用 AI 把你的工作流程自动化。比如写一个Agent，帮你自动生成月度分析报告。当你能把自己的工作效率提升10倍时，你就知道怎么帮别人提升效率了。
六、数据与 AI 成本治理专家：不是 “砍预算的”，是 “让 AI 花的每一分钱都产生价值”
AI 的成本，是所有企业的噩梦。我见过很多公司，Demo阶段一个月只花几千块，一上线就变成几十万，甚至上百万。更可怕的是，你根本不知道钱花在了哪里。
有一次，某互联网公司的财务找到技术部，说上个月的OpenAI账单是80万，比预算超了60万。技术部查了整整一周，才发现是一个测试用的Agent忘记关了，它在后台不停地自己和自己聊天，一周就花了50万。
这还是小问题。更大的问题是，很多企业盲目追求 “最好的模型”，不管什么任务都用GPT-4o，结果成本高得离谱。但实际上，90%的任务根本不需要这么强的模型。比如分类、提取信息这类简单任务，用一个开源的7B模型就足够了，成本只有 GPT-4o 的1%。
数据与 AI 成本治理专家，干的就是“把钱花在刀刃上”的活。他需要建立一套完整的 AI 成本管理体系：
成本归因：把每一分钱的成本，都归属到具体的部门、项目、用户和场景。比如 “市场部的智能客服，上个月花了10万”。 模型路由：根据任务的复杂度，自动选择最合适的模型。比如简单的分类用 Qwen-7B，复杂的推理用GPT-4o。 成本优化：用各种技术手段降低成本，比如上下文缓存、请求批处理、压缩 Prompt、用RAG减少上下文长度。 预算控制：给每个部门、每个项目设置预算上限，超过预算就自动限流或者降级。 - ROI评估：计算每个AI应用的投资回报率，砍掉那些效果不好、成本太高的项目。
最容易踩的坑：很多人以为成本治理就是“砍成本”，为了省钱不惜牺牲效果。错了。成本治理的核心是“平衡效果和成本”。比如用 GPT-4o 能达到 95% 的准确率，成本是 10 块钱；用 Qwen-7B 能达到 90% 的准确率，成本是 1 毛钱。这时候你需要判断，这 5% 的准确率提升，值不值 9.9 块钱。如果是金融风控场景，那值；如果是客服聊天场景，那不值。
普通人怎么切入：如果你做过云成本治理或者数据平台的资源调度，那你已经有了很好的基础。你可以先从统计你公司的 AI 成本开始，把每个模型的调用次数、Token 消耗、成本都统计出来，然后分析哪些地方可以优化。比如把一些简单的任务从 GPT-4o 切换到开源模型，看看效果下降了多少，成本节省了多少。当你能帮公司把 AI 成本降低 50%，同时效果只下降 5% 时，你就是公司的功臣。
七、连接器与执行层工程师：不是 “调 API 的”，是 “AI 伸向真实世界的手”
现在所有的 Agent，都有一个致命的缺陷：“口嗨型选手”。它能说会道，能写计划，能生成报告，但一到要动手做事的时候，就不行了。
比如你让AI“帮我给上个月消费超过 1000 元的用户发一张优惠券”，AI 会给你写一个详细的计划：第一步，从数据库里查询符合条件的用户；第二步，生成优惠券；第三步，通过短信发送给用户。但它真的能执行吗？不能。因为它没有权限访问你的数据库，也没有权限调用短信接口，更不知道你的优惠券系统怎么用。
这就是连接器与执行层工程师存在的意义：给 AI 装上手脚，让它能真正地在真实世界里做事。
很多人以为连接器就是 “调 API”，这是天大的误解。调 API 是最简单的部分，难的是 API 周围的所有事情：
身份认证：AI 用谁的身份去调用 API？是系统账号，还是用户的个人账号？
权限控制：AI 能调用哪些 API？能读取哪些数据？能修改哪些数据？
幂等性：如果 AI 重复调用同一个 API，会不会产生重复的数据？比如会不会给同一个用户发两张优惠券？
安全审计：AI 调用了哪些 API？做了哪些操作？谁批准的？有没有留下日志？
人工审批：对于一些高危操作，比如删除数据、转账，必须经过人工审批才能执行。
失败处理：如果 API 调用失败了，AI 应该怎么办？是重试，还是放弃，还是通知人？
MCP协议的出现，就是为了解决这些问题。它定义了一套标准的接口，让 AI 可以安全、统一地调用各种工具和系统。现在ChatGPT、Cursor、Gemini 都已经支持MCP了，未来它会成为Agent的标准连接协议。
最容易踩的坑：很多人觉得连接器是 “底层脏活累活”，没有技术含量。错了。连接器是 AI 落地的最后一公里，也是最关键的一公里。没有连接器，AI 就是一个只能聊天的玩具。而且连接器涉及到安全、权限、审计这些核心问题，一旦出问题，就是大问题。所以企业愿意为优秀的连接器工程师付很高的薪水。
普通人怎么切入：从写一个简单的 MCP 服务器开始。比如写一个连接器，让 AI 能查询你公司的数据库，或者能发送邮件，或者能创建工单。然后逐步完善它的功能，比如加入权限控制、审计日志、人工审批。当你能让 AI 安全地调用你公司的核心系统时，你就掌握了 AI 落地的核心技术。
写在最后：AI不是你的敌人，是你的放大器
很多人害怕 AI，觉得 AI 会抢走自己的工作。但实际上，AI 从来不会取代人，只会取代那些只会用单点技能干活的人。
过去，你靠会写 SQL 吃饭，现在 AI 会写 SQL 了，所以你不能再只靠写 SQL 吃饭了。你需要学会用 AI 写 SQL，然后把精力放在更重要的事情上：理解业务、设计架构、建立规则、控制风险。
AI 是一个放大器。它能放大你的能力，也能放大你的平庸。如果你只会做执行类的工作，AI 会让你的价值越来越低；但如果你能做建设类的工作，AI 会让你的价值越来越高。
上面这7个方向，没有一个是靠“会用某个工具” 就能胜任的。它们都需要你有深厚的业务积累、工程经验和全局思考能力。而这些能力，恰恰是AI无法复制的，也是你未来最坚实的职业护城河。
不用焦虑，也不用迷茫。从现在开始，停止只学习单点技能，开始培养自己的复合建设能力。只要你能把AI变成你的工具，而不是你的竞争对手，你就永远不会被淘汰。
相关文章
