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

> 合同里卖的方案很少符合真实数据，IT 里的怀疑者最清楚哪里会出问题，应尽早让他们共同负责。

原文: https://fdetimes.net/zh/guides/client-it-team-fde-allies/

设想你到客户现场的第一周。你需要订单数据库的读权限，但三天前提的工单至今无人回复。技术会议上，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 的文章同样建议，一开始就为所有权移交做设计，让客户团队能够运维和扩展系统。

**要点:** IT 团队不需要你变得没那么能干。他们需要确定，这个系统最终会归他们所有。

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

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

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

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

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

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

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

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

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

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

```text
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 交接指南设定的目标：客户团队不依赖你，也能运行和扩展系统。

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

**本周动手试试:**

- 与当前客户的 IT 负责人约一个 30 分钟的会，只问真实系统与需求梳理阶段的描述有哪些不同。这次会上不要申请权限。
- 在共享仓库中建立决策日志，记下最近三个设计决策及其理由，并邀请一位客户工程师评论。
- 为当前项目写一页数据流说明（读什么、写什么、日志存在哪、谁有权限），在下次演示前发给安全团队。

## 信源

- [Forward Deployed Software Engineer (Palantir, Lever)](https://jobs.lever.co/palantir/98b81271-9e15-40b7-8dce-0c62f24702f9)

- [How to Hand Off a Forward Deployed Build So It Does Not Rot](https://www.simpliaxis.com/resources/fde-handoff)

- [Forward-deployed engineering in the age of agentic AI: From vibe coding to governed autonomy](https://www.cio.com/article/4202404/forward-deployed-engineering-in-the-age-of-agentic-ai-from-vibe-coding-to-governed-autonomy.html)

- [ElevenLabs — Meet our Forward Deployed Engineers](https://www.elevenlabs.io/blog/forward-deployed-engineers)

- [So You Want to Hire a Forward Deployed Engineer](https://review.firstround.com/so-you-want-to-hire-a-forward-deployed-engineer.md)

- [What are Forward Deployed Engineers, and why are they so in demand?](https://newsletter.pragmaticengineer.com/p/forward-deployed-engineers)