AI转型?95%的公司都招错了人——来自Palantir和麦肯锡的桥接者实践
原创不易，点赞、推荐、关注，您的支持是我创作最大动力
前两天写了篇 “桥接者” 的文章
AI转型的断层：业务和技术之间，缺一个“翻译”
阅读量不少，大家都很关心，很多人说：“这种人上哪找？怎么判断是不是对的人？“
今天这篇，就来填这个坑。不聊“为什么要翻译”，直接上 怎么区分Delta和Echo、怎么选拔、怎么避坑。
——来自Palantir和麦肯锡的实战框架。
白板左边是业务术语——”客户满意度”、”交付周期”、”库存周转”。 右边是技术黑话——”F1-score”、”向量数据库”。 两拨人各说各话，中间空着一把椅子，没人知道该坐谁。 一位制造业高管曾跟我吐槽：”我们花500万招了一个’既懂业务又懂技术’的架构师，结果他只会画PPT，既推不动业务签字，也说服不了技术团队。” 我回他：”你招错人了。这把椅子要坐的不是’会写代码的业务员’，而是敢对客户CEO说’你定义的问题错了 ‘的人。” 在Palantir，这把椅子有两个名字：Forward Deployed Engineer（FDE，内部代号Delta） 负责”在时间压力下把解决方案代码化”。 Deployment Strategist（内部代号Echo） 负责”发现真正有价值的问题”。大多数公司的问题是：他们以为招的是Delta，其实需要的是Echo。 一个典型场景是：产品经理说”用户想要更智能的推荐”，算法工程师问”‘更智能’是什么指标？点击率还是GMV？” 业务觉得技术”听不懂人话”，技术觉得业务”说不清楚需求”。两边说的都对，就是搭不上。 Gartner数据显示，仅48%的数字化项目达到业务目标，而麦肯锡说最大的瓶颈不是算法，是“翻译者”的短缺 。 但大多数人没意识到：翻译者不是传声筒，而是重新定义问题的人 。
二、Palantir的发现：Delta与Echo的双轨制
2003年，Palantir成立，服务美国情报界。 他们遇到一个难题：客户不会告诉你需求——因为情报人员不会透露工作内容。没法做用户调研，没法写PRD。 工程师Shyam Sankar（后来成为CTO）想了个反常识的办法：把工程师派到客户现场，跟情报人员坐在一起，看他们怎么工作，然后当场写代码。 这就是Forward Deployed Engineer（FDE，内部代号Delta） 的起源。 但Palantir很快发现，光有工程师还不够。有些问题不是代码能解决的——需要有人理解客户的战略、组织动态、甚至内部政治。 于是他们又加了Deployment Strategist（内部代号Echo） ——通常是领域专家（前军官、前医生、前金融从业者），真正”懂行”但又觉得”现状不够好”的人。 Bob McGrew（Palantir早期Delta、后来OpenAI首席研究官）说得直接：
“客户要的，不一定是他们真正需要的。更容易的失败是：你做了客户要求的功能，而不是他们真正需要的功能。”
这就是Echo的价值——不是”听话”，而是敢在客户现场重新定义问题 。 他们帮企业做分析转型，发现数据科学团队很强，但业务就是不买单。为什么？因为中间缺了一个”翻译”。 麦肯锡给这个角色起了个名字：Analytics Translator（分析翻译者） 。 因为最难培养的能力——对业务领域的深度理解——是内部人员的”母语”。 你可以教一个业务专家理解技术边界，但很难教一个工程师理解供应链的痛点。 麦肯锡甚至给出了数据：采用这种”翻译者”模式的组织，数字化项目成功率从48%提升到71% 。 a16z数据显示，2025年FDE职位暴增800%，薪资开到35-55万美元。但Flybridge研究指出：95%以上公司错误引入了FDE模式 ——他们把售前工程师重新贴牌为”Delta”，让初级通才既写代码又做客户管理，结果两头不靠。 我见过太多企业用Delta的JD招Echo的活儿：招来的人能画架构图，但推不动业务签字；能写Demo，但解决不了组织阻力。 实际上，大多数企业缺的不是Delta（技术执行），而是Echo（问题定义）。 只要你的AI转型涉及模糊需求、组织变革、跨部门阻力，你就需要Echo。 但市场连这个名字都还没有，只好用”AI产品经理”凑合招错人。 这正是机会所在 ——当大家还在用Delta的预算招错人时，率先明确”我需要的是能定义问题的Echo”的企业，将获得更高的转型成功率。而我正是以Echo的身份在践行这个角色：不懂如何调优模型参数，但能帮企业把“供应链稳定性” 转化为“跨越企业边界的环境感知网络” ，把“断供预警” 转化为“上游依存条件的因果链监测” ，并推动上下游接受这种打破传统甲乙方边界的新协作方式。 我以Echo身份帮企业做AI转型时，曾踩过三个坑： 总想先把所有场景画成一张完美蓝图——业务流程图、技术架构图、数据流向图，什么都想清楚再动手。 结果项目还没开始就卡住了。业务等不及，技术不知道从哪开始。 后来才学会：先找一条”砾石路”（gravel road）跑通 。哪怕只是一个单点场景（如”预测成交时机”或”单一物料的预警机制”），先让业务看到价值，再扩展。 帮业务打通了数据，仪表盘做得花团锦簇，实时刷新、多维度下钻。 我才意识到：Echo交付的不是报表，是可行动的建议 。业务不需要知道”协作网络密度下降了0.3″，他们需要知道”裁掉这个人会导致哪三个项目延期”； 不需要知道”供应商风险指数”，需要知道”下周哪三家供应商可能断供，该启动哪家备选”。 技术觉得我太业务——”你说的不够精确”；业务觉得我太技术——”我听不懂你在说什么”。 后来我设计了一套AI卡牌 ，把AI能力分成七类，让业务和技术能用极低的成本启动第一轮对话。 工具只是起点。比工具更重要的是组织里有人愿意做翻译这件事 。 AI项目失败的最常见原因，不是技术不可行，而是业务团队”说不清”需求、技术团队”听不懂”问题 ，中间缺了一个敢重新定义问题的人。 如果坐着的是只会画PPT的”顾问”，或者只会写代码的”工匠”，你可能需要一位Echo ——那个敢对客户CEO说”你定义的问题错了”的人。 如果你也站在业务与技术的巴别塔之间，觉得两边都说着力不从心的外语——来聊聊。 也许我们可以一起定义，什么才是值得你投入500万去解决的真问题 。 十三年组织与人才发展实战经验，韧性与敏捷型组织转型操盘手，历经咨询、地产、互联网、新能源汽车、新式茶饮行业。 桥接者工具包（Delta vs Echo 双轨版）
Echo (Deployment Strategist)
核心职责
关键产出
必须能
必须懂
典型背景
适用场景
自检
高代理性
模糊性舒适度
领域叛逆者
数字舒适度
创业者心态
录取线：总分≥15分，且”高代理性”+”模糊性舒适度”单项≥4分
夜雨聆风
