FDE 不是一个
AI 新名词。
它本来就是一个贴着客户干活的岗位：工程师驻扎在业务一线， 边用、边改、边把需求做进产品。
FDE，Forward Deployed Engineer，前沿部署工程师。这个词被 Palantir 带火， 但做法并不神秘：工程师直接坐在客户旁边，看他们怎么干活、卡在哪一步， 然后当场把问题解决掉。
Palantir 最早给美国情报机构把散落在不同数据库里的信息拼成一张关系网。 CIA 旗下的风投 In-Q-Tel 是它第一个外部投资人；2005 到 2008 年， CIA 几乎是它唯一的客户。那段时间，工程师就是坐在分析师旁边干活的。
后来这套能力搬进商业公司，才有了 Foundry，也才有了今天大家嘴里的 FDE。 所以它从根上就不是一个技术岗位，是一个贴着业务干活的岗位。
一句话说清楚
- 我们做什么
- 到你的业务现场，把最耗人、最重复、最容易出错的流程理顺。
- 我们用什么
- 手边最简单的工具。Excel、脚本、agent 都行，你用起来顺手最重要。
- 我们交付什么
- 一个确定性的、能验收的结果——不是一份方案，也不是一个概念。
- 我们不做什么
- 不硬推 AI。你的问题不需要 AI，我们就用别的方式解决。
不是「想用 AI」，
是每天必须有人干。
痛点是真的，但不一定需要 AI。 把脏活理顺，本身就是价值。
散落的账本
进货、出货、库存、应收应付散在几张表、几个人的电脑里。月底对一次账，要花好几天，还经常对不上。
零散的客户
客户信息在微信里、在纸上、在某个人的脑子里。人一走，客户就跟着走；想跟进，又不知道从哪下手。
越堆越多的对账和库存
SKU 越来越多，平台越来越多，每天都在对账、盘点、补货。人越招越多，活还是干不完。
没人愿意干的重复活
复制粘贴、改格式、导表、发通知。不创造价值，但必须有人做，而且一做错就要返工。
诊断→驻场→交付→退出。
四步，每一步都有明确的结果。 不合适，随时可以停。
诊断
先看你现在怎么干活。哪件事最耗人、最容易出错、最没人愿意干。判断它值不值得解、能不能解。
1–2 次沟通驻场
工程师进到业务现场，跟实际干活的人坐在一起。不是访谈，是上手跟着做，边做边改。
按问题定交付
把能跑的结果交到你手上：一个 agent、一本账、一套流程，或者一个看板。当场验收，跑通为止。
以能跑通为准退出
教会你自己的人接手，文档、用法、维护方式一并留下。能退出，才说明这件事真的做成了。
交接完成交付物长什么样，
取决于痛点。
不取决于我们想卖什么。四种形态都出现过，也可能都不是。
一个 agent
把一段重复的判断和操作交给它跑，人只做最后确认。
一本账
把散落在各处的数据收成一本能对上、能追溯的账。
一套流程
把交接、审批、对账的顺序定下来，让事情不依赖某个人。
一个看板
把关键数字放在一屏里，每天扫一眼就知道哪里出了问题。
适合谁，
不适合谁。
把边界说在前面，省掉双方的时间。
适合 / Fit
- +业务已经在跑，但流程主要靠人扛，越忙越乱。
- +有明确的重复劳动、交接损耗、对账压力，你自己也说得出是哪一件。
- +愿意让工程师坐到现场，看真实的操作和数据，而不是只发需求。
- +有能拍板的人参与，问题能当场定，不用层层传话。
不适合 / Not Fit
- −只想买一个 AI 概念，用来对外讲故事。
- −业务还没跑稳，希望用 AI 先找到方向。
- −希望远程发个需求，就等着别人把结果送上门。
- −期待一套系统解决所有问题，不愿意先做一件小事。
聊聊你的业务，
先不用谈合作
第一次聊，我们只想知道三件事。聊完你再判断要不要往下走，不合适就不合适。
