FDE入行六条硬标准：Agent一刻钟部署实录

什么是FDE，为什么值得关注

FDE（Forward Deployed Engineer，前沿部署工程师）是在AI应用落地浪潮中愈发热门的一个岗位。简单来说，FDE就是被派到客户现场、直接帮客户把系统跑起来的工程师。这个岗位的门槛并非空泛的简历项，而是要求你亲手交付过真实可用的项目。

本文所依据的素材，来自一位实践者对「FDE入行六条硬标准」的逐条自测记录。有意思的是，这六条标准并非作者本人所立，而是行业中有人「翻遍四个城市的FDE岗位」后总结出来的量尺。作者用自己让AI Agent做的一个补货看板项目来逐条量了一遍——最终六条过了四条，挂了两条。

这份「挂了两条也照实摆出来」的诚实记录，恰恰比一份完美通关的展示更有参考价值。

六条硬标准：一次真实交付的完整拆解

这六条标准衡量的核心，是「你亲手做的项目够不够格算一次真实交付」。它们不是考察你会不会写代码，而是考察你交付的东西是否真的在现实世界中运转起来。

第一条：数据必须真实

第一条就把作者的项目挂住了。他的补货看板用的是造出来的演示数据，「这盘子是造出来的，这没得变」。

这条标准直指AI项目落地最常见的陷阱：Demo里数据漂亮、逻辑通顺，但一旦接入真实业务数据，各种脏数据、边界情况、格式不一致就会让系统露怯。用真实数据跑通，才算迈出交付的第一步。

值得说明的三条：产品的完整性

过掉的四条里，有三条作者认为「不用多讲」，但它们共同勾勒出一个成熟产品的样貌：

• 用户无需与AI对话：用看板的人不用跟AI说话，看建议、点按钮就完了。这意味着AI能力被封装进了产品交互中，而非暴露一个聊天框让用户自己琢磨。
• 建议、日志、复盘小报三样齐全：产品不仅给出建议，还留下操作日志，并能自动生成复盘小报。「效果好不好，翻开小报就能说清」——这是可衡量、可追溯的交付。

这三条的共同点是：产品闭环，用户拿到的是能直接用的成品，而不是半成品加使用说明书。

从「挂」到「过」：一刻钟完成公网部署

真正精彩的部分在第四条——「部署在服务器上，而不是只能在本机运行」。

这条标准第一次量的时候是挂的，因为看板只能在本机跑。但作者给Agent装上了「会部署的skill」，让它把看板搬上公网。

AI Agent部署的能力边界

作者的实验清晰划出了AI Agent的能力边界。Agent几乎把所有事都做完了：配置写好、代码改好、本地验证也通过，「能做的他全做完了，就差人来按最后的确认」。

但在部署过程中，Agent替你跨不过去的只有三件事：

1. 注册账号
2. 录入支付信息
3. 按下最后那个确认键

这三件事之所以AI跨不过去，是因为它们涉及身份、金钱和法律责任——这恰恰是人机协作中「人」必须在场的关键节点。除此之外，「剩下的，一句话交给他」。

Cloudflare Workers 是 Cloudflare 提供的无服务器（Serverless）边缘计算平台，代码运行在全球分布的边缘节点上，无需管理传统服务器。它的部署模型极为轻量：开发者只需提交代码，平台自动处理运行时环境、扩容和网络路由。正因如此，一次标准化的 Workers 部署在流程上高度可脚本化——CLI 工具 Wrangler 可以完成从构建到发布的全部步骤，这恰好落在 AI Agent 能够自动执行命令的能力范围内。文中「9秒部署」的本质，是无服务器架构把传统部署中最耗时的环节（服务器配置、依赖安装、进程管理）统统消除后，剩余操作被 Agent 一次性执行的结果。

中途换云与9秒部署

过程中出现了一个真实的转折：作者原本选定了第一朵云，但预检后弹出「想建服务，先去录支付信息」的提示。盯着这行提示，他改了主意，换成平时一直在用的那朵云。

换云意味着要给Agent换上对应的部署skill，重新授权一次。授权之后，「剩下的路，他一口气跑到底」。而最关键的那一下部署——只用了9秒。从改主意到公网上能点开，前后不过一刻钟。

「9秒那一下，我是真愣住了。刚才还卡在支付信息上，一转眼，他已经在公网上转起来了。」这种从卡壳到上线的落差感，正是AI Agent在部署自动化上带来的真实体验。这里的目标云是Cloudflare Workers，其无服务器架构让部署环节被极大压缩。

上线不是终点：公网验证与最后一条

拿到公网地址后，作者没有就此收工，而是「在公网上真点了一轮」。

他测试了一个关键功能：拒绝一条建议时，弹窗会逼着你选原因，整页刷新后记录一条都不丢。

说个细节，「拒绝必须写原因」这条改进，正是上一轮项目复盘里排在第一位的改进项。这次不光做了，还是在公网上验证完成的。这体现了一种良性的迭代闭环：复盘发现问题 → 下一轮实现改进 → 在真实环境中验证。

唯一未闭环的第五条

即便公网地址有了、功能验证通过了，第五条依然挂着——「至少有一个不是你的人在使用」。

作者坦言这条不打算演：「找一个真实的人，把地址交给他用上一周，这是整套东西里唯一还没闭环的事。」

这条标准是整个「真实交付」定义里最难、也最本质的一环。技术能力可以靠工具补齐，但「有真实用户在用」这件事，无法伪造，也无法靠Agent代劳。它检验的是产品是否真正解决了别人的问题。

「真实用户验证」在产品开发方法论中对应的是可用性测试与产品-市场契合度（PMF）验证的早期阶段。即便功能完整、技术无误，产品依然可能因为信息架构不直观、术语陌生或流程摩擦而让真实用户放弃。FDE 岗位之所以把「至少一个非自己的人在使用」列为硬标准，正是因为工程师本人对系统过于熟悉，会产生「知识的诅咒」——他们在演示中自动跳过了真实用户会卡住的每一步。这条标准本质上是在用最低成本的方式逼迫项目经历第一次真实的市场摩擦。

给正在做项目的你：拿六条量一量

这份实录的价值，不在于展示一次完美交付，而在于诚实地摆出了「过了四条、挂了两条」的真实状态。

从中我们可以提炼出几个对AI应用开发者有普遍意义的判断标准：

• 你的数据是真实的，还是造出来的Demo？
• 你的产品是否让用户无需理解AI就能直接用？
• 你的系统跑在公网服务器上，还是只能在本机演示？
• 有没有一个不是你的人，真正在用它？

同时，这次实验也给出了一个务实的人机协作范式：把注册、支付、确认这三件涉及身份与责任的事留给人，其余的一句话交给Agent。当部署这类繁琐工作被压缩到9秒级别，工程师的注意力就能真正回归到「交付什么」而非「怎么交付」上。

如果你手里也有一个做了一半的项目，不妨拿这六条量一量，看看能过几条。