AI能写方案，能做分析，能生成代码。
如果你已经工作了十几年，看到这些能力，可能会冒出一个很扎心的问题：
我过去积累的经验，还值钱吗？
这个问题，最近被一个岗位重新摆到了桌上。
FDE。Forward Deployed Engineer，通常译作前线部署工程师。
它的工作，是深入客户的业务，把AI做进真实流程，让一项能力变成真正有人使用的系统。
但我认为，它带来的更大变化，是让我们重新审视一种长期被低估的能力：
你到底有多了解一件事情，是怎么真正做成的。
01｜你觉得“不用解释”的东西，恰恰最需要解释
想象一个采购比价的场景。
三家供应商，各发来一份报价。你把文件交给AI，让它找出最便宜的一家。
几秒钟，表格出来了。排序清清楚楚，理由有条有理。
但一个做了多年采购的人，可能看一眼就会问：
这家报价含税吗？运费算进去了吗？另外一家答应的交期，真的能兑现吗？那个最低价，是不是建立在一年采购量达标的前提上？
表格没有算错，采购决策却可能已经错了。
因为业务里的“便宜”，从来不只有一个数字。
它还包含付款条件、质量风险、交付能力，以及出了问题以后谁来承担损失。
这些东西，你觉得是常识。但模型不会自动知道，哪条规则在你这家公司最重要。
人和AI之间，有时候差的不是知识，而是具体到这笔业务的判断条件。
这就给了懂行的人一个机会：把过去藏在脑子里的判断，变成系统能够遵循的规则。
02｜经验不会自动升值，它需要换一种形态
不过，别急着高兴。
“我在这个行业干了二十年”，并不等于“我适合做FDE”。
同样是经验，有些是对问题的理解，有些只是对旧办法的熟练。
如果你的经验只能表现为“我们一直这么干”，它甚至可能妨碍改造。
真正有价值的经验，需要能够回答三个问题。
第一，你在判断什么？
比如决定一家供应商能不能进入采购名单，你看哪些事实，哪些是硬门槛，哪些只是加分项？
第二，你在什么时候改变判断？
同样一家供应商，平时可以用，紧急订单却不能用。这个变化依赖什么条件？
第三，怎样证明判断有效？
拿过去的案例重新跑一遍，系统能否区分正常情况与例外？面对信息缺失，能否停下来询问，而不是编一个答案？
能把这些讲清楚，经验才有机会变成规则、样本、检查清单和工具。
以后换一个员工，也能按这套方法工作；换一批数据，也能检查结果对不对。
经验的价值，会从“只有我知道”，走向“我能让更多人稳定地做到”。
这两种能力，看起来只差一步，实际差着一整段职业空间。
03｜懂业务的人有了入口，但技术这一关绕不过去
很多人听到这里，会想：我懂行业，让AI帮我写代码，不就行了吗？
可以开始，但远没有结束。
让一段代码跑起来，和让一个系统在公司里可靠运行，是两回事。
文件换个格式怎么办？数据更新怎么办？用户看到了不该看的信息怎么办？系统出错以后，工作还能不能继续？
你可以借助工具，可以和工程师合作，但不能把这些问题交给一句“AI说没问题”。
OpenAI的一则FDE招聘说明，把客户交付与平台开发同时列入岗位定位，也要求候选人具备工程或技术部署经验。衡量工作成效，则包含真实使用与可测量的流程改善。[^1]
这个要求提醒我们：行业理解提供方向，工程能力让方向成为可靠的东西。
对产品经理、解决方案顾问、业务骨干而言，过去的积累可能是很好的起点。接下来需要补上的，是亲手验证、理解系统边界，以及推动他人使用的能力。
对技术人员而言，入口则可能在另一侧：走近那些你过去觉得“需求说不清”的人，理解他们为什么会那样工作。
业务不懂技术，技术不懂业务，中间那段解释、验证和协调，往往决定一个项目有没有价值。
04｜真正值得警惕的，是你能做的事越来越容易被替换
判断自己的机会，有一个比追热点更直接的问题：
如果明天所有同事都能熟练使用AI，我还会因为什么被需要？
如果答案是“我更会写提示词”，这个优势可能维持不了太久。
如果答案是“我知道哪些需求值得做，能解释关键约束，能把方案做出来，还能证明它改善了工作”，你的能力就有了更扎实的支撑。
这也是我看待FDE的方式。
它提供了一条路径：让行业经验与新的技术能力结合起来，参与更完整的价值创造。
但头衔本身不会让人升值。
如果你始终只负责传话，始终无法验证结果，换上再新的名字，职业处境也不会自动改变。
所以，别急着问自己有没有赶上风口。
先看一件更具体的事：你最熟悉的工作里，有没有一个判断，能够被你整理成规则；有没有一段流程，能够被你改得更好。
当你能把自己懂的事情，变成别人用得上的能力，过去的经验才真正开始长出新的价值。
你所在的行业，有哪些“外行看起来很简单，内行知道处处是坑”的工作？
