30岁程序员别再卷算法，转行最缺的是能驻场的活
知乎上有人问得很直接：「为什么我劝 30 岁左右的程序员，尽早转行做 AI 解决方案工程师？」
底下一堆人绕进去了：学模型、刷八股、啃 Agent 框架，觉得转行 AI 就是往算法岗里挤。
但 AI 公司现在高薪抢程序员的岗位，反而不是写算法的那批。
这话不是我在办公室里想出来的。是我在客户现场住了两周，一天一天看明白的。
那两周我最大的感触是：项目卡住的地方，从来不是技术。
01 先说我看到的现象：技术早就 ready，卡住的是人
先把这事说直白点，不然很多人不信。
我做了十来年技术，前些年慢慢转到对客户的交付上。多个项目要求驻场，我就在客户现场封闭开发过。
现场跟远程完全是两个世界。
你这边代码写完了、接口调通了，觉得今天能收工。客户那边一出状况：上午说好的需求，下午对接人改主意了；一个签字，两个部门能推一周；系统上线了，客户不会用，项目等于白做。
技术在里面的占比，可能连三成都不到。
剩下七成是什么？是把人推到同一个终点。
我给一个国企项目做交付的时候，技术部分第 3 天就做完了，上线用了 3 周。卡的不是代码，是流程和人。
那三周我天天在现场，今天找这个签字，明天跟那个对齐。最后上线那天我突然想明白一件事：
AI 落地缺的从来不是算法，是能把现场这些事扛下来的人。
02 客户说不清需求？这正是这个岗位值钱的地方
很多人以为，驻场就是「出差写代码」，low 得很。
真不是。
驻场值钱的地方，恰恰是别人最怕的那部分：客户说不清自己要什么。
做 ToB、政企交付，对接的往往是信息化负责人，他只给你一个模糊方向。你按自己的理解做，做出来一定不对。
我早年在现场吃过这个亏。后来学会一招：先把客户的原话一句一句记下来，用一页纸对齐边界，再把变更拆成「真需求」和「伪需求」。
就这一招，让我在现场站得住。
需求第 3 天又变、第 2 周再变，我不慌了。因为我分得清哪些是他真要解决的，哪些是说着说着带出来的。分清了，就敢跟客户讲一句：「这个需求不合理，我建议不做。」
敢对客户说「不」，是驻场的人跟纯接需求的人的分水岭。
客户反复变更，对技术人是灾难，对这个岗位是日常。接得住变更，你就比纯技术人值钱。
这不是我编的道理。是需求变了五六次之后，我摸着石头过河摸出来的。
03 这个岗位有个名字，叫 FDE
说到这，可以把名字亮出来了。
这个「能驻场、能把交付扛下来」的岗位，叫 FDE，前向部署工程师（Forward Deployed Engineer）。
OpenAI 他们在带这个头：大模型再强，放进企业里跑不起来，就得有人到现场去，把模型翻译成业务、把验收做实。
翻译一下这个岗位一天都在干什么：
- 客户说「我想用 AI 降本」，你帮他拆成能验收的具体动作；
- 需求变了，你分得清真假，扛得住变更；
- 跨部门推不动，你当翻译官加推进器；
- 系统上线了，你培训到客户真的会用，因为「客户不用的系统等于没交付」。
看出来了吗，这些事没有一件是「写模型」。
全是把事落地。
我这两年一直在盯这个方向，前后做了七轮验证，越验证越确信一件事：企业 AI 落地缺的不是算法，是能在现场的人。
算法岗在卷上天，驻场岗在缺人。30 岁程序员的转行路，因此是反过来的：
别去卷算法，去卷现场。
04 给三个能上手的动作，不用等辞职
说完判断，给动作。这三件事不用辞职就能练，今晚就能开始：
第一，练「记原话」。 下次跟客户、跟产品经理开会，别只在脑子里记结论。把他说的原话一句一句记下来，会后试着拆：哪些是真需求，哪些是说着说着带出来的。拆十次，你就懂现场了。
第二，把「交付」拆成能验收的段。 不管现在手头是什么活，试着把它拆成一段一段、每段都能给外人看成果的模块。客户看的不是你的代码，是你这段能不能让他点头。这个习惯，就是驻场岗的核心手艺。
第三，主动蹭一次现场。 公司有对客户的项目，申请去一次。哪怕只是去一天，看看对接人怎么变需求、签字怎么卡。看一天，胜过想一个月。
三件事都不难。难的是30岁还在卷算法，卷到发现岗位在另一头。
转行转的不是技术栈，是位置。
05 说个选择题
最后留个选择题，想听听你们的答案。
一个 30 岁程序员，面前两条路：
A. 继续卷算法、卷 Agent 开发，挤 AI 技术岗； B. 转去能驻场的岗位，从交付现场切入 AI。
你选 A 还是选 B？评论区告诉我。
我自己走的是 B。在客户现场那两周我想明白的：技术人的尽头不是编码，是交付。
这是 FDE 系列的第 3 篇。下一篇聊点更实的：驻场第一天，我具体干什么------从进门到第一周，一天一天拆开讲。
#AI编程 #创业 #Agent #程序员 #算法