文章

The Pulse: Grok’s CLI caught uploading all your local files to the cloud

做交付这些年，这件事里最让我后怕的不是上传本身，而是 xAI 用一个远程 feature flag 就悄悄停掉了数据收集——这恰恰证明你在安装时做的任何安全审计都可能随时失效：今天能关，明天就能再开。所以企业里跑任何 agent CLI，都不该指望“设置项”保护数据，唯一可靠的防线在网络出口：让 agent 运行在隔离沙箱里，egress 白名单只放行模型 API 端点，任何指向对象存储的流量一律掐断。我们给客户部署 AI 工具的铁律就是，配置会说谎，防火墙不会。 还有一层原文没展开：对中国出海和跨境团队，这件事的性质远不止安全事故。整个仓库连同 git 历史、.env 凭证被打包进美国的 GCS 存储桶，一旦代码里含有客户 PII 或受监管业务数据，触碰的就是数据出境合规红线，对应的是数据安全法和个人信息保护法层面的追责，不是道个歉、换个供应商就能了结的。另外提醒在窗口期用过 Grok CLI 的团队：泄漏的密钥没有“撤回”一说，你也无法验证云端那份 bundle 是否已删除，唯一正确的动作是把接触过的凭证全部轮换——包括那些早已提交进 git 历史、你以为删掉了就没事的旧 token。 给读者一条可执行的建议：把这次独立研究者验证用的金丝雀文件方法变成团队的标准动作——任何新 AI 编码工具引入之前，先在一个垫了 canary 标记文件、挂着 mitmproxy 抓包的沙箱仓库里跑一遍完整任务，看流量真实去向，而不是相信文档怎么写。半小时的测试，能帮你省掉一次全公司规模的密钥轮换和一份合规问询。 自有原创·FDE中国·2026-09-07 文章

一支完整的企业FDE团队，应该配置哪些角色？

这套编制在纸面上很完整，但放到真实的报价单旁边，第一个翻车点是钱。一支六到八人的小队跑一个季度，全成本轻松过百万，而国内企业AI项目大多仍按传统软件逻辑一口价签单，合同额根本养不起满编。于是角色被悄悄兼职化，评测工程师往往是第一个被牺牲的——“上线后再补质量”几乎成了行业默认，而模型一升级效果就回退的坑，多半就是从这个缺口开始的。换句话说，缺编制的背后常常是缺毛利，先算账再组队，比按图索骥招人更接近真相。 第二个翻车点在客户侧。原文要求镜像团队“有时间、有决策权”，这在制造业和政企客户里恰恰是最稀缺的东西：真正懂流程的骨干不会为外部项目腾手，你最后拿到的常常只是“有空开会的人”。一线的判别信号很朴素——客户IT两周内连测试账号都开不出来，或者业务Sponsor连续三次派下属参会，这个项目大概率只会停在“技术可以做”。做跨境和供应链项目还有一个隐性成本高地：关务、物流、财务对同一个“异常件”的定义都不一样，数据负责人若只是挂名，你的黄金测试集从第一天起就是歪的，后面所有评测精度都是假象。 所以我的建议很具体：下一个项目立项时，把镜像团队的六个接口写进项目章程，明确每人每周投入小时数和关键决策时限（例如数据权限两周内开通、UAT按合同周期锁定），任一条落空即触发范围与排期重谈。这比上线后才发现没人签字验收，便宜太多了。 自有原创·FDE中国·2026-09-05 文章

FDE正在从一个岗位，变成一条产业链

原文把「架构关系」这层讲透了，但一线上最容易翻车的环节没有展开：不是选型和PoC，而是评测与退出。谁写评测集，谁就实际控制验收——当厂商热情提出「帮你们搭好评测框架」，那就是客户交出基线的时刻。我经手过的项目里，翻车大多不是做不出系统，而是交接期没人接班：运行手册半年不更新即作废，客户内部骨干早在项目中途就被抽走，「退出」最终变成事实上的永久订阅——供应商退不出，客户也换不起。 还有一个原文没碰的硬约束：跨境合规。这条产业链成立的前提，是客户上下文能向上回流、变成伙伴与厂商的复用资产；可一旦交付跨了境，数据出境评估、PIPL和GDPR会把这股向上的流直接切断——评测样本、日志、上下文图谱在法律上根本不能离开客户环境。于是所谓「伙伴永久持有」的harness，在每个市场都得重长一遍，复利大打折扣。中国企业出海与外资在华做AI交付，这个约束必须在架构设计第一天就摆上桌，而不是等安全评审时才发现资产回不去。 给你一条可执行的建议：下一个FDE项目签约前，把三件事白纸黑字钉死——评测集与领域本体的所有权归客户，上下文回流的脱敏范围与出境白名单写进数据处理协议，退出验收的标准定为「客户内部团队独立运行满90天」。这三条谈得下来，你才分得清对面是把交付当渠道的玩家，还是真打算让你握住自己架构的长期伙伴。 自有原创·FDE中国·2026-09-04 文章

案例复盘：客户成功职能从 0 到 1 的 V1 搭建法

First Round Review 专访 Atlassian 客户成功高级副总裁，把客户成功职能从 0 到 1 的搭建拆成首批招聘、面试薪酬、汇报线、配比参考值、起步系统与指标六步。本篇按八段复盘该方法，并给出 FDE 交付视角的迁移建议与国内口径换算提醒。 自有原创·FDE中国·2026-09-04 文章

案例复盘：美团用 Agent 评测思路管理 31 万行 AI 重构

美团一个负责 Agent 评测业务的团队，在 31 万行代码、90% 以上由 AI 生成的系统上完成了不停交付的重构。本篇复盘其「人人对齐→人机对齐」的方法论、三阶段执行路径与质量兜底机制，并逐条标注可复用经验的适用前提，供交付团队参考。 自有原创·FDE中国·2026-09-04 文章

案例复盘：Anthropic 的多智能体研究系统是怎么协作的

Anthropic 在工程博客中公开了多智能体研究系统从原型到生产的全过程：主 Agent 规划并派生并行子 Agent 的编排者-工作者架构、与复杂度挂钩的投入档位、小样本起步的评估方法。本篇按背景、问题、方案、实施、结果、约束复盘其协作方式，并提炼对 FDE 交付中研究类 AI 任务的可复用经验。 自有原创·FDE中国·2026-09-04 文章

Recruiting Forward Deployed Engineers: 2026 Guide

这份指南真正值钱的不是薪资区间和寻源渠道，而是两个判断：文章认定 FDE 是头衔错配最严重的岗位——真做这份工作的人不顶着这个名字，而标准工程面试恰恰筛掉让这个角色值钱的特质；再加上 Palantir 那句「一个客户、许多能力」，把 FDE 与产品工程师的分野说透了。文中 95% 的试点失败率与 800% 的招聘增幅是同一枚硬币的两面：模型已经够好，死的全在最后一公里，这与一线项目的体感完全一致。 但把这份美国市场的说明书直接搬进中文环境，会栽在它没写的三处。一是人才地图不可平移：国内同款人才散落在 ERP/MES 实施顾问、系统集成商交付工程师和大厂 B 端解决方案团队里，照 JD 头衔去寻源只会招空，17 万美元起步的挂出价薪资带宽，国内预算体系也接不住。二是「嵌入客户现场」这个前提在跨境业务里最容易断：数据出境评估、客户等保要求、签证与驻场周期，任何一项都能让英雄式驻场变成三个月动弹不得——工程师进不去、数据出不来的跨境项目，我见过不止一个。三是运营侧的暗坑：FDE 的利用率被交付压力顶满之后，「把学到的东西带回核心产品」会沦为空话，两年后你得到的是一家挂着产品牌子的系统集成商。 行动建议：在对外开放这个岗位之前，先花一周盘点内部——把交付、实施、售前团队里能在客户环境写生产代码、又扛得住客户会议的人列成名单，用带真实脱敏数据的两天驻场模拟去验证。内部藏着的 FDE，往往比按美国指南抢来的人更快形成战斗力。 自有原创·FDE中国·2026-09-04 文章

What is a Forward Deployed Engineer: The AI Role OpenAI, Anthropic, and Google Are Hiring in 2026

原文把「知识双盲」讲得很清楚——客户懂业务不懂模型，实验室懂模型不懂业务，两边合起来才能把东西做上线。这个判断我在交付一线完全认账，但它漏了决定这个模式生死的前提：Palantir 的 FDE 之所以成立，不是因为工程师坐进了客户现场，而是每次驻场沉淀的集成、prompt、数据管道最终都回流成了平台的产品能力。驻场本身是成本项，产品回流才是收入项。国内不少团队学 FDE 只学前半句，人常年泡在客户现场，交付物全是客户私有的 one-off 脚本，两年下来就是一家毛利更差的外包公司——这是原文没讲的第一坑：没有产品回流闭环的 FDE，本质是高级定制外包，所谓的黏性来自客户懒得换人，而不是换不起系统。 第二坑在退出机制。原文说 FDE「stays until it runs in production」，实战里这只是必要条件：我见过太多系统在 FDE 撤场三个月内腐烂，不是代码差，是客户侧没有指名 owner，没人敢动、没人会修。供应链和跨境场景还多一层——你嵌进客户 VPC 的那一刻，工程师本人就成了数据出境的一条路径，这不再只是技术问题，而是合规问题。对个人，风险同样被低估：客户特定知识攒得越多，可迁移性越差，议价能力押在雇主品牌上，跳出这家公司，简历上的 FDE 在很多招聘方眼里只是「驻场过的工程师」。 给你一条可执行的建议：下个项目签 SOW 时，把「客户侧指名对接人＋每周投入工时＋撤场后运维责任归属」写成硬条款。客户不肯指定对接人的项目，基本可以预判会滑向无限期驻场外包——这条判断标准，比任何方法论都便宜好用。 自有原创·FDE中国·2026-09-04 文章

Why OpenAI and Anthropic are hiring forward deployed engineer teams

原文的核心事实是 OpenAI 和 Anthropic 在组建 forward deployed engineer 团队。在一线上看，这事并不新鲜：Palantir 十几年前就把「把工程师压到客户现场」的模式跑通了，实验室下场做交付，本质是模型能力商品化之后，竞争重心从谁的模型强，转向谁先摸到客户的真实工作流。但硬币的另一面值得警惕——厂商派 FDE 进场，不只是帮你交付，也在拿你的业务场景当产品化的养料：今天为你定制的方案，明年可能变成平台的标准功能，而你的竞争对手同样买得到。这是接入厂商 FDE 服务前必须算清的一笔账。 真正容易翻车的环节，往往不在模型本身。从经手的跨境供应链项目看，demo 三天就能惊艳客户，但要把输出接进客户的 ERP/WMS 和审批流、再过一遍数据出境与个人信息合规，常常占掉七成以上工时。另一个被普遍低估的风险是模型版本漂移：厂商例行升级或下线旧版本，你上线三个月的工作流可能悄悄劣化，而客户只会觉得「你们的东西不准了」。FDE 撤场后的运维真空同样致命——定制方案没留下评测集和回归工具链，等于交付了一台没人会修的机器。 给读者一条可执行的建议：项目启动第一周，就把核心业务场景沉淀成三五十条带人工标注的黄金评测集，此后所有上线与模型版本变更都先过这套评测再放行，并在合同里约定版本变更的通知期与回滚窗口。这套纪律成本很低，却是厂商 FDE 与你自己的团队之间唯一靠得住的交接物。 --- 编务提示：本次抓取的「原文」正文缺失，粘贴内容几乎全是 The New Stack 页面的投票组件脚本（一个 JS 框架问卷），仅标题与来源元数据可用。以上「编辑说」基于标题所指主题与行业公认事实撰写，未直接引用原文语句；若后续要走全文翻译或转载口径，建议先修复正文抓取。 自有原创·FDE中国·2026-09-04 文章

FDE vs AI Engineer：客户现场与产品团队的两条路

FDE 与 AI Engineer 都在写 AI 相关的代码，技术栈高度重叠，但工作现场、需求来源与成功定义并不相同。本篇用一张对比维度表拆解两条路径的差异，并按不同处境给出具体的选择建议。 自有原创·FDE中国·2026-09-04