进入现场
理解一线人员如何工作、问题在哪里发生，以及谁承担业务决策。
前置部署工程 · FDE
FDE：把业务理解与工程交付放在同一岗位上。
Forward Deployed Engineer 直接进入企业真实流程，贯穿业务澄清、工程实现、评测和上线交接。
FDE 做什么
理解现场，写生产代码，把结果交到业务手里。
角色本质 · 01
业务上下文、生产代码与交付责任的交叉点。
FDE 不等待一份完美需求文档，而是在现场理解流程和约束，用工程交付验证判断，再把经验沉淀为可复用能力。
亲手构建
写生产代码、接数据与权限、处理异常，而不是只把方案交给另一支团队。
按约交付
先建立业务基线、交付范围和上线标准，再用评测与运行记录判断是否达标。
沉淀复利
把连接器、评测集、工作流和方法变成后续项目可以复用的能力。
角色对比 · 02
差别不在“离客户多近”，而在承担哪一段责任。
| 角色 | 常见目标 | 是否写生产代码 | 参与上线验收 | 常见终点 |
|---|---|---|---|---|
| 战略咨询 | 方向与路线 | 通常不 | 有限 | 报告与建议 |
| 解决方案 / 售前 | 证明产品适配 | 原型为主 | 交接后减弱 | 方案与签约 |
| 软件外包 | 按需求实现 | 是 | 按合同范围 | 功能验收 |
| FDE | 从现场问题到生产交付 | 通常是 | 通常贯穿 | 达到约定上线条件并移交 |
为何现在 · 03
当 AI 开始调用系统，工程边界随之扩大。
AI 开始读取企业数据、调用工具和改变工作流后，权限、评测、异常、责任与采用不再是上线后的附属工作，而是产品本身。
01
需求无法预先写完
只有进入真实任务，才能发现隐性规则、例外情况和真正的价值路径。
02
系统需要上下文
高质量结果来自业务数据、工具、权限和反馈机制的共同设计。
03
质量需要持续评测
模型与数据都会变化，生产系统必须具备可观测、可回归、可接管的能力。
FDE 常见问题
关于 FDE 的几个直接答案。
FDE 一定要长期驻场吗？
不一定。高密度发现、联调和上线阶段适合现场，其他工作可以混合进行。
FDE 是一个人还是一支团队？
复杂企业项目通常更适合小队。由一名 FDE 负责人贯穿业务与技术，再组合应用工程、数据、集成和安全能力。
企业什么时候不需要 FDE？
需求高度标准化，成熟 SaaS 可以直接解决，或者企业内部已经具备完整的业务发现与 AI 工程能力时，不需要 FDE。
适配判断
先说清当前流程，再判断是否需要 FDE。
标准产品能解决就用标准产品，复杂流程再考虑前线部署。
提交项目简报 ↗