在 Ema，谁做演示，谁就得把它送上生产环境

你刚演示完一个为新员工处理 IT 权限申请的智能体。会议室里的人纷纷点头，客户同意签约。周一早上，把这个演示变成真实用户依赖的系统的，还是你。到那时，演示里抄过的每一条近路都会回来找你。

在 Ema，这就是前线部署构建者（Forward Deployed Builder）的日常工作。公司的官方招聘启事描述的是一个深入客户和合作伙伴内部工作的人，并明确写道：这不是一个躲在客户团队身后的支持岗位。

一个人身兼三职：客户负责人、解决方案架构师和构建者，在欧洲、中东和非洲（EMEA）与北美之间轮换驻场。

所以核心技能不是一场精致的演示。你必须把演示当作生产环境的第 0 版来做，因为承担每个演示决策后果的人就是你自己。这项技能适用于任何前线部署工程师（FDE），哪怕所在公司把负责销售的人和负责部署的人分开。

四份工作，一个人

Ema 发布在 Accel 招聘板上的启事把工作拆成四步。第一步，拿到一个混乱的真实业务流程，在 Ema 平台上把它重新设计成清晰的智能体流程。第二步，亲手搭建一个可运行的演示，价值证明要清楚到客户再也提不出反对意见。

第三步是签单。按照启事的说法，正是构建者打消了客户对方案的疑虑，合同才得以拿下。最后一步是把签好的合同变成客户信任、并真正采用的生产级智能体工作流。

四步都落在一个人身上，原因在产品本身。Ema 把自己的产品描述为能够在 HR、IT 和财务领域规划并执行企业工作流的智能体系统，集成了 250 多个应用。在幻灯片上画一个涉及五个系统的工作流，谁都能做到；让它真正跑起来，难得多。

设计从需求调研开始

设想一家中型客户。每次有人入职，HR 给经理发邮件，经理回复“ok”，IT 在几个系统里手动开账号，没人知道哪个申请卡在哪里。这正是启事里说的那种混乱流程。

要重新设计它，写第一行代码之前先要做需求调研。Ema 另设的前线部署工程团队介绍过他们的调研工作坊，内容涵盖四个方面：大家现在怎么干活、痛点在哪里、数据怎么流转、需要哪些集成。

四个方面一个都不要跳过。然后再加一个问题，它往往最能打开话匣子：“这个流程上一次出问题是什么时候？”

这次会议的产出应该是一份简短的规格说明，具体到可以马上照着搭建：

flow: new-hire-access
trigger: HR 在 HR 系统中创建员工记录
steps:
  - read_record: 获取部门、职位、入职日期
  - propose_access: 智能体根据职位提出权限清单
  - request_approval: 发送给直属经理，等待回复
  - create_accounts: 调用每个目标系统的 API
  - report: 向 HR 和新员工发送汇总
exceptions:
  - manager_no_reply_48h: 发送提醒，然后上报给其上级
  - job_title_has_no_template: 停止，询问 IT，为新职位添加权限模板
  - api_error: 重试，然后开工单交由人工处理

价值就在 exceptions 这一节。顺利路径客户自己就想象得出来，他们需要看到的是出了问题时智能体怎么应对。

哪种演示能赢下技术之争？

设想签单会议上，客户的 IT 负责人抛出尖锐问题：“经理休假怎么办？”“智能体会不会给自己开管理员权限？”只有顺利路径的演示，恰恰会输在这些问题上。当面跑过 manager_no_reply_48h 分支的演示，答案早已摆在那里。

这也是 Ema 把技术门槛定在这个位置的原因：能写一些代码，能用智能体平台搭出真实的演示，而不只是嘴上讲讲。这个门槛不要求你是基础设施工程师，只要求你不去伪造日后交付不了的东西。

维度	一次性演示	第 0 版演示
数据	手工录入的样例记录	一条来自客户 HR 系统的真实、已脱敏记录
集成	看起来像 API 调用的模拟界面	至少真实调用一个目标系统，其余明确标注为模拟
异常	没有	至少当着客户跑一个分支
签约之后	从头重写	在演示用的同一份规格说明上扩展

右边这一列要多花几天时间。换来的是：当你留下来部署时，会议室里承诺过的每一项都已经有代码支撑。

从设计到 SLO

签约之后，别让规格说明躺在演示文件夹里。Ema 的 FDE 团队会为每个“AI Employee”编写并维护一份设计文档，指导部署从设计一路推进到服务等级目标（SLO）。这个习惯值得照搬：文档不止于一张架构图，而是以客户可以核查的数字收尾。

以上面的权限流程为例，一份最精简的设计文档可能是这样。阈值仅作示意，真实数字要在上线前与客户商定。

ai_employee: new-hire-access
scope:
  included: HR 系统（只读）、邮件、2 个提供 API 的目标系统
  not_included: 财务系统（第二阶段）
agent_permissions:
  - 只按职位模板创建标准权限的账号
  - 管理员权限一律需要 IT 审批，智能体绝不自行授予
exceptions: 保留演示用规格说明中的 3 个分支
slo:
  auto_completed: ">= 80% 的申请无需人工介入即完成"
  turnaround: "95% 的新员工在 1 个工作日内拿到全部账号"
  adoption: ">= 90% 的权限申请走该流程，而不是邮件"
measurement:
  source: 流程日志，每周与 IT 收件箱核对
  review: 上线 4 周后

注意管理员权限那一行：签单会议上的一个尖锐问题，变成了写进文档的约束。每个 SLO 也都齐备三要素：阈值、在哪里测量、何时复盘。

Ema 描述最后一步时，关键词是“adopts”：客户真正用起来。工作流在跑，HR 却又回去发邮件，那还算不上生产环境。所以 adoption 这一行和技术指标并列写在 SLO 里。

自己给自己挖的坑

最容易犯的错，是签单时承诺了演示没有证明过的东西。一个人既卖又部署，每一句“可以，我们能做到”都是一张要你自己处理的工单。稳妥的规则是：只承诺跑过的东西，其余放进后续阶段的范围。

第二个错，是调研时把终端用户排除在外。你和采购方谈，但需要改变习惯的是 HR 员工和经理。如果他们不在工作坊里，“客户信任并采用”这一环从第一天起就很难。

第三个错，是做了模拟集成却不标注。客户分不清哪些是真的，直到上线当天你才发现，目标系统的 API 需要走一套耗时数周的访问审批流程。

如何在简历上体现这项技能

浏览各家的 FDE 招聘启事时，留意“embed”“on-site”“not a support role”这类措辞，或者从演示一路写到生产环境的岗位描述。

这些信号说明岗位需要的是能扛下整条链路的人，而不是售前工程师。Ema 的启事也没有规定固定的工作年限，所以你能拿出的证明，就是你交付过的东西。

简历上别写“做过 AI 演示”。按四个步骤讲清一个项目：一开始的混乱流程是什么，演示跑了哪个异常分支，谁因为这个演示点了头，上线后 SLO 达到了多少。

如果你应聘这类岗位，准备好一个关于演示与生产环境之间差距的故事：你曾经不得不为自己做的演示还债，以及你是怎么解决的。

Ema 要的是真实的演示，而不是关于演示的空谈；还要求做演示的人一直留到客户信任为止。在这样的岗位上，好的演示只是前一半；后一半是合同签完之后，它依然在跑。