客户 IT 团队视你为威胁，但你离不开他们

设想你到客户现场的第一周。你需要订单数据库的读权限，但三天前提的工单至今无人回复。技术会议上，IT 负责人双臂交叉，对每个问题都回答“我们需要确认一下”。

他们并不是无礼。换位想想：高层请来一个陌生人，做的事按理说本该由他们自己的团队来做。

Palantir 把前线部署软件工程师（Forward Deployed Software Engineer）的工作比作初创公司的 CTO：团队小，端到端负责，而且常常驻扎在客户现场。职责如此，你做的恰恰就是属于 IT 团队的那部分工作。

即便客户喜欢你，也仍把你当外人。First Round Review 讲过一个故事：一家 Fortune 100 公司的总法律顾问亲切地把 Ironclad 派来的工程师称为“背包客”（The Backpacks）。这个称呼听着友好，言下之意却是：背着包来的人，也会背着包走。

为什么离开他们就做不成事？

你可以绕开 IT 团队，请高层的项目发起人去施压。但这很快会适得其反。一位前 Palantir 前线部署工程师（FDE）招聘官对 First Round Review 说，你在现场看到的情况，会和合同里卖的东西大不相同。

OpenAI 前线部署工程负责人对 The Pragmatic Engineer 说的也差不多：客户在需求梳理阶段描述的情况，往往与真实的数据和系统对不上。

清楚差距在哪的人，比如哪张表里全是脏数据、哪个任务凌晨 2 点运行并锁表，几乎都在 IT 团队。

把他们挤出去，你失去的正是最需要的信息来源。

所以问题不是怎么绕过 IT 团队，而是他们在怕什么，你又该如何回应这种担忧。

换个说法：你是来离开的

IT 团队通常怕两件事：一是被取代，二是被丢下一个看不懂的系统，半夜出故障时由他们来扛。这两种担忧，答案是同一个。

Simpliaxis 上一篇关于 FDE 项目交接的指南定下了明确目标：客户团队必须能运行和扩展系统，而无需联系你。

文章还把常见看法反了过来：让自己变得可有可无，并不会降低你的价值，反而证明了你的价值。CIO.com 一篇讨论智能体 AI 时代 FDE 的文章同样建议，一开始就为所有权移交做设计，让客户团队能够运维和扩展系统。

在第一次会面时把这一点说出来，并照此行事，你就不再是来抢位置的人，而是帮他们接手一个新系统的人。

示例：库存 Agent 与四人 IT 团队

假设你要为一家零售商部署一个回答库存问题的 Agent。它需要读取一套 ERP 系统的数据，这套系统由一个四人 IT 团队管理。要做的事有三件，按顺序来。

第一步：写代码之前，先开 30 分钟的会。 不要一上来就要权限，先问真实的系统情况：“库存表是批量更新还是实时更新？上次数字出错，原因是什么？系统上有没有你们不希望任何人碰的东西？”最后一个问题最重要，因为它把划定边界的权利交给了他们。

会议结束时做出承诺：“项目结束时，你们团队应该能自己修改和扩展这个 Agent，不需要找供应商。整个排期都会围绕这个目标来设计。”

第二步：第一周就请安全团队参与。 CIO.com 的文章强调，智能体 AI 的治理不能是最后一步才勾选的合规清单。ElevenLabs 写道，对其 FDE 团队来说，安全、数据管控和监管合规从一开始就是必选项。

所以带上一页数据流说明：Agent 对哪三张表有只读权限，日志存在哪里，提示词里是否含有客户数据。

让安全团队随意删改。第一周提出的修改只需几个小时；如果拖到最后一周，可能直接卡住上线。

第三步：一起设计，一起写代码。 Simpliaxis 的指南给出了三项具体做法：邀请客户工程师参与设计决策，开发过程中与他们结对编程，边做边讲清你的思路。ElevenLabs 描述其 FDE 与客户技术团队并肩工作，就在客户自己的基础设施里。

放到库存示例里，就是在共享仓库中维护一份决策日志，再加上每周两次结对，每次与四人团队中的不同成员搭档。一条日志可以简短到这样：

D-03：库存查询结果缓存 15 分钟
原因：避免 Agent 每次回答都直接调用 ERP
否决方案：实时直接读取库存表
共同决定人：[客户工程师姓名]
如需修改：编辑缓存配置文件，IT 团队可自行完成

“共同决定人”这一行最有价值。它把你的决定变成了双方共同的决定，也告诉日后的读者，你离开后该去问谁。

Simpliaxis 的指南解释了这样做为什么有效：与客户团队一起开发的工程师，在整个项目中持续交接，所以最后的交接量很小。到了最后一周，已经不需要再办三天的“交接培训”。

什么样的措辞能让 IT 团队放下戒备？

大部分防备心理，源于你开口的方式。你仍然可以提出所需的一切，只是换个说法：

不要说	改成
“给我 ERP 的管理员权限，这样我能快点。”	“我只需要这三张表的只读权限。你觉得有哪张应该排除吗？”
“这部分我来搞定，你们不用操心。”	“这部分我们结对来做吧，以后维护它的是你们团队。”
“周五给领导演示。”	“周四先和 IT 团队预演一遍，周五一起向领导展示。”
“安全的事可以放到后面的阶段。”	“这是数据流图，能不能请安全团队在开发前先评审一下？”

让盟友变成阻碍的五个错误

最常见的错误是，IT 一回复慢就通过项目发起人走捷径。你赢了一张工单，却失去了整个团队。第二个错误是申请超出所需的权限，这恰好印证了安全团队最担心的事。

第三个错误是给领导演示却不邀请 IT 团队，让他们从别人那里听说一个跑在自己基础设施上的系统。

第四个错误是写只有自己看得懂的代码：没有决策日志，没有运维手册，一切都在你脑子里。第五个错误是把安全留到最后，而这正是 CIO.com 和 ElevenLabs 都提醒要避免的。

这项能力怎么写进简历？

阅读 FDE 岗位描述时，留意“work side-by-side with technical teams”“handoff”或“enablement”这类说法。出现这些词，说明公司看重的不只是开发，还有向客户交接。

面试时，准备一个把心存戒备的团队拉进工作的故事。讲具体：第一次会面问了什么，什么时候请安全团队参与，和谁结对。

简历上写交接的成果：客户团队有多少名工程师，你离开多久后他们就能独立运行系统，他们自己加了哪些功能。

这些数字必须是你的真实数据。它们正好对应 FDE 交接指南设定的目标：客户团队不依赖你，也能运行和扩展系统。

最终的衡量标准很简单：在你背起背包离开之后，系统依然在运行，而维护它的，正是第一次会面时双臂交叉的那位负责人。