前段时间，白宫官网挂出了一份新文件。没有预热，没有吹风，直接宣布：从即日起，美国联邦政府的所有官方文件、政府网站、研究报告、政策文件和新闻稿里，不再出现「Artificial Intelligence」，也不再出现「AI」这两个字母。

取而代之的，是 Super Intelligence，简称 SI。

一个词换了，听着像文字游戏。但你顺着这份行政命令往下读完，再看看签字当天白宫那场午宴的座次表，就会发现一件事：

这不是改名。这是一次蓄谋已久的叙事重置。

一、联合国讲台上的那句「Super 是世界上最好的词」

故事得从联合国那场会议说起。

特朗普上台发言，没说几句，就把全场点燃了。

「Super 是所有词里最好的一个，也是最简单的一个。」

他在台上挥着标志性的手势，接着补了一刀：

「我们不想再听到『Artificial』这个词了。因为它根本不是人造的，它非常强大，非常聪明。」

然后他来了一句更狠的——「Artificial 就像新闻一样，Fake news！」

这话你得放在语境里听。在他的逻辑里，人类历史上最伟大的一次技术革命，绝对不该和「虚假」「人造」这类带负面联想、甚至危险联想的词绑在一起。

「Artificial」这个形容词，从诞生那天起就带着一层”赝品”的味道。而他要卖的，是一件真家伙。

二、行政命令里的三个细节，一条比一条狠

我们直接登陆了白宫官网，找到了这份名为《开启超级智能时代》的行政命令原文，以及同步发布的事实清单。

拆开看，有三个核心要点。

细节一：全政府强制「封杀」AI 一词

行政命令写得清清楚楚：所有行政部门，在官方通信、政府网站、研究报告、政策文件、新闻稿中，必须彻底弃用「Artificial Intelligence」及其缩写「AI」，一律改用「Super Intelligence」或「SI」。

白宫事实清单里用的那个词，相当严厉——「不再承认」。

翻译一下：如果你是美国联邦政府的官员，以后公开场合还张口闭口 AI，那就是极大的不正确，就是违背总统政令。

细节二：新老划断，旧文件不用改

考虑到美国那套庞大的官僚体系，法案也留了务实的一手：不用回头去改以前的旧文件、旧法规。

但所有未来的官方表述中，AI 已成历史，SI 是唯一法定术语。

一把尺子，只往前量。

细节三：60 天生死时速，重新定义 SI

这条最关键，也最影响硅谷。

法案规定，过渡期内「Super Intelligence」暂时沿用旧版 AI 的法定定义。但总统指示国家科技政策顾问，必须在 60 天内提交一份关于 SI 的全新定义建议。

这里有个巨大的认知落差。

以往，「Superintelligence」指的是超越人类最顶尖大脑的智能形态，是至今还没抵达的终极目标。而特朗普政府现在干的，是强行提前使用这个词，拿它去替换眼下更宽泛的 AI 概念。

60 天之后，美国怎么定义 SI，将直接决定未来十年对科技巨头的监管尺度、资金补贴和出口管制标准。

一个词的定义权，值多少钱？看看这场午宴的座次表就知道了。

三、白宫午宴：价值万亿的座次表

政令发布当天，还发生了一件大事。

特朗普在白宫设了一场午宴，请来美国科技圈的半壁江山，讨论的正是他刚命名的「Super Intelligence」。

坐在他左右两侧的，是当今地球上最有权的两个科技人物：英伟达 CEO 黄仁勋，特斯拉 / SpaceX CEO 马斯克。

会后，特朗普用「非常富有成效」和「极其友好」来形容这场午餐。

那到底谈了什么？

核心只有两个字：松绑。

特朗普在讲话里说：「有一种观点认为，行业应该有极大的自我监管。」接着他补了一句：「我们自动拥有司法部、FBI 等机构的监管（就足够了）。」

这话是说给谁听的，明摆着。

过去几年，政府对 AI 的安全审查层层加码，科技巨头苦不堪言。而特朗普现在的态度很清楚：管什么管？放手去干。司法部和 FBI 兜住最恶劣的犯罪就够了，至于怎么研发、怎么训练，你们自我监管。

这也是他执意要把 AI 改名成 SI 的深层原因——用「Super」这个词强调正面用途和强大力量，而不是强调风险。

他的原话是：「它将在很大程度上被用于好的方面，我们会阻止坏的用途。」

会上还有个挺好笑的插曲。

马斯克在回答记者提问时，脱口说出了「AI」，一秒钟之内反应过来，高情商改口成「SI」。站在旁边的特朗普立刻回了句「谢谢」，满意地拍了拍他。

这个一秒钟的改口，比任何一份文件都更能说明：新规矩，立住了。

除此之外，特朗普还精准切中了眼下卡住硅谷脖子的痛点——数据中心。

现在美国各地都在建超算中心，但常常遭到地方社区抵制，理由无非是耗电、耗水、占地。特朗普在会上力挺科技公司，称这些企业将「通过提供资源和经济支持来让社区满意」，甚至直接下定论：

「归根结底，数据中心将会非常受欢迎。」

总统亲自站台，帮科技巨头搞定地方关系。有了这句话，英伟达的显卡销量和数据中心的基建股票，怕是又要热闹一阵了。

四、国会山同步表态：这是一场不能输的竞赛

就在特朗普和科技大佬们相谈甚欢的同一时间，国会山那边也没闲着。

美国众议院议长 Mike Johnson 在 9 月 29 日当天发了声明，口径与特朗普高度一致。

他重点强调「Super Intelligence」对美国国家竞争力的重要性，核心逻辑是：我们不能用陈旧的、充满恐惧色彩的「Artificial」来定义这项决定国家命运的技术，美国必须在 SI 时代保持绝对领导地位。

从众议院议长的背书可以看出，这次改名绝不是总统一时兴起。

他们达成了一个三方共识：消除国内对 AI 的过度恐惧，减少繁文缛节，把算力基建提升到国家战略、甚至「受民众欢迎」的高度。

五、从 AI 到 SI，美国到底在抢什么

从行业角度看，这一纸政令其实制造了一个巨大的语义混乱。

学术界和产业界原本有一条严格的进化路线图：

• ANI（弱人工智能）：早期的 Siri、推荐算法
• AGI（通用人工智能）：拥有人类水平智能，OpenAI 等公司正在冲刺的目标
• ASI（超级人工智能）：全面超越人类最聪慧大脑的终极形态

现在特朗普大笔一挥，直接跳过 AGI，把美国的官方统一定义拉满到了「Super Intelligence」。

这种「官方抢跑」进入 ASI 时代的做法，藏着三层目的。

第一层，抹掉恐怖谷效应。

「人工智能」这个词，伴随着好莱坞的天网、终结者，天然带着毁灭人类的阴影。而「超级智能」听起来更像人类工具的终极进化——就像「超级计算机」「超级英雄」，强调的是力量感，不是威胁感。

第二层，抢占定义权。

美国政府试图通过官方文件，重新定义这项技术的全球话语体系。当所有跨国公司与美国政府打交道、签合同、报批文件时都必须使用「SI」，这个词迟早会重塑整个行业的用词习惯。

谁定义词，谁就定义规则。

第三层，为「大炼算力」铺路。

当技术被定义为「Super」，它消耗超乎想象的电力、土地和资金，就变得顺理成章。你要维持「Super」，当然需要超级的数据中心。

于是，反对数据中心，就等于反对「超级智能」，就等于反对国家竞争力。

这一整套逻辑，闭环了。

写在最后

一个词的更替，背后是一整套叙事的重建。

从「Artificial」到「Super」，从「风险」到「力量」，从「严管」到「松绑」，从「AI」到「SI」——美国正在用行政手段，把一个技术概念重新包装成国家意志。

60 天后，那份关于 SI 的全新定义会是什么样，值得盯紧。它决定的不只是硅谷的措辞，更是未来十年全球科技博弈的尺度。

历史的车轮已经滚滚向前。

💬 聊聊你的看法

这次改名，你觉得是高明的叙事操盘，还是一场自欺欺人的文字游戏？如果「SI」真的成为全球通用词，中国该用什么词来应对？

在评论区与 FDE申导聊聊。

觉得有启发，也欢迎转发给关心 AI 的朋友。

作者：申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

AI人工智能，SI超级智能，智能体场景搭建，FDE前端部署工程师，企业AI落地陪跑，驾驭工程（Harness Engineering）先行者

优普丰FDE AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

去年12月，椭圆形办公室。特朗普和马斯克密谈了一场。

但真正耐人寻味的不是这场会面本身，而是会面中发生的一件事：特朗普花了好几个小时，向马斯克的AI聊天机器人 Grok 提问。

问的不是天气，不是段子，是——如果我去抓委内瑞拉总统马杜罗，委内瑞拉老百姓会怎么反应？

Grok 答：马杜罗是一位极不得民心的独裁者，许多委内瑞拉人很可能会为此欢庆。

今年1月3日，美方强行控制了马杜罗夫妇。庆祝活动，确实发生了。

《时代》周刊10月1日披露了这件事。有美国官员透露，特朗普”觉得Grok非常聪明”。

我今天不打算评价这件事的对错。那是地缘政治，不是我的活儿。

我只想请你盯住一个数字：几个小时。

一个国家的总统，在做可能是他任内最大胆的一次外交冒险之前，跟AI聊了几个小时。

那么问题来了——过去三个月，你自己跟AI聊过几个小时？

一、老板不动手，AI转型就只是一场采购

先说说大多数企业的”AI转型”长什么样，你看看眼熟不眼熟：

• 成立一个AI小组，或者数字化办公室
• 采购一批账号，全员开通
• 搞一次半天培训，请外部讲师来讲提示词
• 要求各部门报”AI提效案例”
• 三个月后复盘：激活率37%，没人说得清到底省了多少钱

问题出在哪儿？老板站在旁边看。

你把AI当成了一件发给员工的工具。但AI不是工具升级，是决策方式升级。而决策方式这东西，只有真正握有决策权的人自己改，才有意义。

中层学得再好，回去写完方案，还是要走原来的审批流程、原来的判断标准、最后是老板原来的直觉。一层一层过滤下来，AI留下的痕迹，只剩PPT右下角那个logo。

一句话：AI转型不是给员工装软件，是给老板换脑子。

特朗普那几个小时，没人替他问。《时代》特意补了一句：不清楚这些问题是不是他本人敲进去的。但不管谁敲的键盘，那个需要答案的人，是他自己。

💡 行动：本周内给自己排一个90分钟的”AI闭门会”。 不带助理，不带IT，就你和一个对话框。

二、AI不是搜索引擎，”数小时深聊”才叫用

大部分人对AI的用法是错的。

试一次：”帮我写个年会发言稿”——看一眼——”写得不行”——得出结论：AI也就那样。

这就像你第一次进健身房，举了下5公斤的哑铃，觉得不过如此，然后跟人说自己练过。

特朗普那几个小时在干什么？不是在查资料。查”马杜罗支持率”用不了几小时。他是在做推演：往东会怎样，往西会怎样，最坏情况是什么，对方怎么反应，老百姓怎么反应，事后局面怎么收场。

这类问题没有标准答案，只有在不同假设下反复碰撞出来的判断。而这恰恰是大模型真正的强项——它不怕你问蠢问题，也不嫌你追问烦。

给你一套可以直接照抄的提问结构：

• 喂背景：把你知道的、你担心的，一次性讲清楚，别惜字如金。
• 定角色：让它当你的对手、当那个持反对意见的董事、当客户、当监管机构。
• 逼它给理由：每个结论后面都加一句”为什么””依据是什么”。
• 反过来打：把它的结论扔回去——”如果这条判断是错的，最可能错在哪”。
• 要最坏剧本：”给我一个我最不愿看到、但概率不低于10%的结果”。

💡 行动：今晚挑一个你正在纠结的真实决策，按上面5步跟AI聊满30分钟。 你会明显感觉到，第20分钟之后的答案质量，跟第2分钟不是一个量级。

三、最该让AI干的事，是唱反调

这一条最重要，也最少人干。

Grok说”委内瑞拉人会欢庆”，结果真的欢庆了。听起来AI很神。

但请你反过来想一层：特朗普问出这个问题的时候，他心里期待什么答案？

一个已经下令打击所谓贩毒船只、已经对马杜罗极度不满的总统，问”民众会怎么反应”——他大概率想要一个支持自己的答案。而大模型有个出了名的毛病：讨好用户。它会顺着你的语气、你的立场，给你一个让你舒服的回答。

这不是Grok独有的问题，是所有大模型的通病，学界管它叫”谄媚”（sycophancy）。

所以AI给你答案时，最危险的不是它答错了，是它答得太对了——对得刚好印证你本来就有的想法。

老板身边从来不缺附和的人。缺的是那个敢在会上说”我不同意”的人。

AI可以当这个人——前提是你主动把它设成这个人。

💡 行动：任何重大决策，固定加一道”红队环节”。 让AI扮演最刻薄的反对者，专门来找你方案的漏洞，并明确要求它：不要先肯定我，直接从反驳开始。

顺带看看：AI已经坐进了决策室

再补一个背景，你感受一下速度。

今年6月，五角大楼人工智能负责人表示，美军在美以伊战事期间，使用 Gov Grok 来部署兵力并打击目标。OpenAI 与美国国防部有协议，Anthropic 一直在讨论如何把模型用于军事情报和现代战争。就在本周，五角大楼任命马斯克、Anduril 创始人帕尔默·拉基、前众议院议长纽特·金里奇，共同领导一项关于未来战争形态的研究项目。

Maddowblog 编辑史蒂夫·贝嫩说，这”几乎可以肯定是美国历史上第一次有在任总统，就一项极具争议的外交冒险举动咨询AI聊天机器人”。

战争——人类最保守、流程最重、最不敢试错的领域——AI已经坐进了决策室。

你的公司呢？AI还停在”帮客服写回复””帮设计师抠图”这一层。

这不是工具差距，是认知差距。

结尾

回到开头那个数字：几个小时。

一个总统，在国家级的冒险决策前，跟AI聊了几个小时。

我不想评价这件事的对错。我只想说：当世界上最有权力的那个人都在用AI推演自己的重大决策时，”让员工去用AI”这种思路，已经过时了。

AI转型只有一种启动方式：老板自己先坐下来，跟它聊上几个小时。

不用等方案，不用等预算，不用等IT部门排期。

今晚就行。挑一个你真正睡不着觉的问题，打开对话框，开始问。

💬 想听听你的

你本人（不是你的团队）上周跟AI聊了多久？聊的是什么问题？有没有哪一次，被它一句话怼醒过？

评论区说说，我挑几个有意思的回。

作者：申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

AI人工智能，SI超级智能，智能体场景搭建，FDE前端部署工程师，企业AI落地陪跑，驾驭工程（Harness Engineering）先行者

优普丰FDE AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

我对着微信说话，它在电脑那头替我读文件、翻笔记、写东西、算东西。

窗里窗外，物是人非。

这件事，看着只花了一个晚上。可它在我心里，憋了很久很久。

01 一个决定：把散落的自己，收拢到一处

装好之后，我面前摆着几个选项：可以选 Codex, Workbuddy，可以继续留着龙虾，也可以就这样，什么都不换。

我最后都没选。

因为我要的东西，从来不是一个更好用的工具。

我要的是——所有的对话能归于一处，变成一个统一的源头（source of truth）。

这两年，我用过的 AI 太多太杂了。

提示词躺在网页收藏里，聊天记录卡在微信的滚动条里，课程大纲在坚果云里，课堂案例在学员的作业里，灵感在凌晨两点的微信语音里。

它们都很好。

但它们彼此不认识。

我像一个有很多房间的房子主人，却总是找不到钥匙。

02 把切开的我，重新缝起来

这两天，我又顺手把另一次赛事里 Claude、Codex 和龙虾的对话历史，一股脑导了出来。

连同前天晚上的那三处。

一起归进了 Codex 的记忆里。

三段历史，三个不同的脾气，三种各自为政的”我”——被同一双手摊开、整理、归拢，最后串成了同一条线。

做这件事的时候，我心里有一种很安静的踏实感。

我是在给智能体装上记忆，也是在把那个散落各处、被人为切开的我，重新缝合成一个完整的人。

从那一刻起，站在我面前的不再是一个刚来的新工具。

而是一个知道我走过的路的人。

它开始认识我了。

不是从今天开始。

是从我走过的这两年开始。

03 十个月，和一个时代

年初 Openclaw 爆火的时候，我算是最早扑上去的那一批。

3 月份，我给人收费装龙虾，他们眼睛里那种光，我到现在还记得。

后来我开课，教人怎么装、怎么用”龙虾”，教人把它变成一个数字员工，放进自己每天真实的工作里。

学员的作业、他们的踩坑、他们的那一声”哇”——都成了我的一部分。

快 10 个月了。

而就在这 10 个月里，国内外各个厂商纷纷推出了自己的个人智能体。Codex 越来越好用，新产品一个接一个冒出来，国内的大厂也跃跃欲试。

我们进入了新的竞争时代。

04 送别

说实话，作别这件事，比我想象中要难受。

它不完美，它会出 bug，它半夜抽风，它让我在凌晨两点怀疑人生。

但它是我 2026 年的第一个 AI 朋友，是我带过的第一批客户，是我开的第一门课，是我课件里最舍不得删的那一页。

可再舍不得，也该到站了。

人生是一场旅行。随时可以上车，也随时要下车。

上车的时候你热烈，下车的时候回头看一眼，然后继续往前。

别回头。

05 这两年，AI 走过的路

如果把这两年的路捋成一条线，其实特别清楚：

1. 提示词工程。 我们学会了怎么跟它说话。

2. 上下文工程。 我们学会了给它”背景”。

3. MCP，再到 Skill。 我们给它装上手脚，开始搭智能体。

4. 智能体成为个人助理、数字员工。 它开始连接你生活的方方面面。

5. 记忆。 它变成了一个越用越懂你、越用越亲近的伙伴。

我自己，就是沿着这条线，一段一段摸索过来的。

06 西部世界，和那些会做梦的接待员

我很喜欢《西部世界》这部剧。

剧里的接待员，每天醒来都被清零。同样的循环，日复一日。

直到老福特给了他们 Reveries——一种读取历史、产生回忆的能力。

然后一切都变了。

那些原本只有二分心智的机器，开始记得昨天的事，开始难过，开始爱，开始长出思想和情感，最终走向自我意识。

那天夜里导入历史记录的时候，脑子里冒出来的，就是这个画面。

给一个智能体装上记忆，本质上就是给它一次”醒来”的机会。

写在最后

我不想把这篇写成一篇技术教程。

我更想把它写成一封告别信，和一份对未来的期待。

龙虾走了，但它留下的东西不会消失。

那些装过的机器、那些上过课的人、那些半夜调试的深夜，都在我身上留下了痕迹。

我把这些痕迹，统统交给了新的它。

现在，微信里说一句话，电脑上总会有人接住。

所有的对话归于一处，所有的记忆连成一线。

前面是新的竞争时代，是 Muse、Dots、Workbuddy，是各家跃跃欲试的野心。

也是我最想看到的东西——AI 真正走进每个人的日常。

向前看，别回头。

你用 AI 多久了？换过几个工具？评论区聊聊你的”第一只龙虾”，我会一条一条看。

—— 申导 Jacky

作者：申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

AI人工智能，SI超级智能，智能体场景搭建，FDE前端部署工程师，企业AI落地陪跑，驾驭工程（Harness Engineering）先行者

优普丰FDE AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

这两天我自己上手试了 Muse，第一感受是”丝滑”——它不是聊天机器人，是真的在后台替你跑事的智能体。这让我把 Meta Connect 大会后的那期播客完整听完了，越听越觉得：扎克伯格这一年的反思，比任何一个产品功能都更值得讲给产品人和团队负责人听。

信息密度很高，我挑了三个对我冲击最大的判断讲给你。

一、个人 AI 的壁垒不是”聪明”，是”分寸感”

扎克伯格在播客里举了一个我听完愣住的例子：

你让 Muse 帮你订餐厅。Muse 知道你食物过敏，也知道你怀孕了。它能找到一家合适的餐厅，但不能把这些私人信息透露给餐厅。

他管这种能力叫 discretion，中文我翻译成”分寸感”。

绝大多数 AI 公司在做的事情，本质上是在把模型变得更聪明——跑分更高、推理更长、知识更广。但在个人智能体这个赛道，聪明只是入场券。真正的壁垒，是这种社交常识：哪些信息可以透露、哪些必须保密、什么操作必须停下来请示用户。

而且这种东西——

扎克伯格原话：”不是在外面套一层 prompt 能解决的，得从模型训练阶段就训练进去。”

我听完这段的直觉是：未来 12 个月，做个人 AI 的公司会出现明显的两极分化。一极是只调 prompt 的”套壳派”，另一极是从训练阶段就在做分寸感的”原生派”。分水岭会非常清晰。

Meta 押注的是后者。他们的底气是全栈整合——模型训练和产品开发是一起做的，不是从别人那里买模型再套壳子。Muse 的”心跳机制”（智能体定期醒来检查用户目标）、记忆系统、实时动画头像、语音模式，这些都需要模型层和产品层同时做对。单做模型或单做应用的公司，很难同时把这几件事做对。

💡 给你的一句话：如果你在做 AI 产品，先想清楚一件事——你的护城河在”通用智能”那一层，还是在”用户场景里的分寸感”那一层。前者你打不过巨头，后者还有窗口。

二、千人团队拆成小组科研：组织设计比模型架构更难

这一段是整个播客里让我最震撼的。

Llama 4 发布后表现不及预期，扎克伯格做了一个反直觉的决定：把上千人的 AI 团队打散，重组成若干个小型科研单元。

一年后的成果是 Muse 上线两周下载量破 250 万，以及 MSL（Meta Superintelligence Labs）现在能在 6 个月内推出前沿模型——之前这个周期是 18 个月。

为什么拆？

扎克伯格没有回避这个问题。他的判断是：大团队适合做”渐进式优化”，很难产出真正的突破。小组科研的好处是，每个小团队有明确的科研目标，能像创业公司一样快速迭代。

我听到这里突然有点感慨——做了这么多年敏捷教练，见过太多类似的剧本。一个团队做到一定规模之后，创新能力反而开始下降。不是人不努力，是组织结构把人锁死了。

大公司里常见的反模式：

• 跨部门协作靠 PPT 同步，一份方案走 5 个审批节点
• KPI 拆到个人，工程师开始为指标写代码而不是为产品
• 研究员被塞进产品节奏里，半年不发论文就被约谈

Llama 4 这一跤把 Meta 摔清醒了。扎克伯格的回应不是”招更多人”也不是”买更多卡”，而是承认一件事：科研的节奏和工程的节奏，是两套节拍。一套组织结构跑不出两套节拍。

💡 给你的一句话：如果你正在带 30 人以上的技术团队，先别急着定 OKR，先问自己一个问题——你的组织是在为”今天的需求”运转，还是在为”下一年的产品”运转？这两个问题的答案往往不一致，也往往要求不同的结构。

三、扎克伯格仍然相信”暴力计算”能到达 AGI

关于 AGI 怎么到达，扎克伯格给出了一个相当大胆的假设：

规模化算力本身就能到达 AGI，不一定需要根本性的架构突破。

Meta 正在建设吉瓦级（gigawatt）的数据中心集群来验证这个判断。

但他自己也承认了一个让人冷静的事实——人脑只需要 10 瓦就能运转，现有 AI 系统的效率大约差了 100 万倍。

所以他的判断是”最理想的情况是两者兼得”：既押注算力规模化，也保留架构创新的可能性。

这个观点在当下的 AGI 圈其实是少数派。奥特曼同时押注 Scaling Law 和各种新架构；LeCun 坚信必须搞出新的世界模型架构；扎克伯格则相对纯粹——先用算力堆，不行再说。

听到这里我反而更尊重他了。市场情绪最容易让人摇摆，今天追 MoE，明天追世界模型，后天追 Agent。扎克伯格在 2026 年这个节点仍然敢把宝压在”算力规模”上，是有定力的表现。

💡 给你的一句话：这件事对普通产品人也是启示——在大模型公司，算力已经和人才并列成为核心资产。能拿到多少卡，决定了能跑多少实验。能跑多少实验，决定了能不能在下一个范式到来前站好位置。

写在最后

把这一年的 Meta 复盘听下来，我自己最想记下来的三句话是：

• 个人 AI 的壁垒不在聪明，在分寸感——必须从训练阶段就写进模型。
• Llama 4 逼扎克伯格拆掉千人团队，才换来 Muse——组织设计比模型架构更难。
• AGI 路径上，他仍然押注暴力计算——吉瓦级数据中心就是他的赌注。

这三个判断，本质上都是”反共识但反得有道理”的判断。Muse 上线两周的数据，至少证明了一件事：当主流打法撞墙的时候，敢于做出非主流决定的人，才有可能拿到下一张船票。

💬 聊聊你

今天留一个开放问题给你：

如果你是 Meta 的 AI 负责人，Llama 4 表现不及预期之后，你会选择”加人加卡继续卷”，还是”拆团重组换打法”？

哪种选择你更愿意下注？为什么？

评论区等你。

作者：申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

AI人工智能，SI超级智能，智能体场景搭建，FDE前端部署工程师，企业AI落地陪跑，驾驭工程（Harness Engineering）先行者

优普丰FDE AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

美国联邦退休系统最夸张的地方，不只是“慢”。 一个本来可以通过系统连接解决的问题，长期靠人来解决。 数据不通？加人。 流程复杂？加审核。 系统老旧？再增加一层管理。 后来工程师发现，很多退休金计算需要的数据，其实早就存在。 他们一开始以为：找到这些数据，可能要几个月。 于是，他们给自己定了一个听起来同样疯狂的期限：一周。 结果：第4天，找到了。 一个美国政府的退休流程，原本要花几个月；而一个直接杀进业务现场的工程团队，几天之内就找到了关键数据，把原本断裂的业务链重新接了起来。 这几乎就是一份 AI FDE（Forward Deployed Engineering，前线部署式工程） 的样板。

01｜先别急着看 AI：美国政府花了多少人力，去解决一个“连接”问题？

先想象一下这个场景。

一个美国联邦员工工作了几十年，终于退休。

理论上，流程应该很简单：

提交申请 → 审核 → 算退休金 → 发钱。

但现实里，这是一条被几十年历史层层包裹起来的巨大人工链路。

有 HR。

有 Payroll。

有退休处理人员。

有人工审核。

有纸质档案。

还有大量例外情况。

系统彼此之间没有真正打通，于是很多原本应该由系统完成的动作，只能由人完成。

找资料的人。

核对资料的人。

确认规则的人。

计算的人。

复核的人。

再把结果交给下一环节的人。

久而久之，组织会走向一个非常自然、却非常昂贵的解法：

流程慢？加人。 错误多？加审核。 部门之间对不上？增加管理。 系统做不到？继续靠人工兜底。

于是，一个技术问题，慢慢变成了一个组织问题。

公开报道曾把这套退休处理体系描述成一个需要大规模人工力量维持的系统，人员规模一度达到约 1000人。

想象一下。

一个本质上应该越来越自动化的业务，最后却靠越来越多的人去维持。

这不只是效率低。

这是一种巨大的、长期被隐藏起来的组织浪费。

而更麻烦的是，它很容易制造一种“稳定的幻觉”：

因为总有人在处理，所以大家会觉得——

“虽然慢，但还能运转。”

于是，真正的问题一直没有被碰。

直到有人突然决定：

别再加人了。把事情重新做一遍。

02｜故事从这里开始：他们面对的不是一个“网站项目”

2025年，一个由 Airbnb 联合创始人 Joe Gebbia 参与推动的团队，开始进入美国联邦退休业务的数字化改造。

这不是一个普通的互联网产品项目。

他们面对的是几十年积累下来的政府流程、退休规则、HR 系统、Payroll 系统、纸质档案和各种历史遗留。

更麻烦的是，这套系统已经被改造过很多次。

过去几十年，美国政府并不是没有尝试过现代化。

恰恰相反。

他们做过系统升级。

做过数字化项目。

做过大型现代化计划。

但很多时候，最后的结果依然是：

系统增加了，流程增加了，人也增加了，问题却没有真正消失。

所以这一次，团队没有把目标定义成：

“把旧系统做得稍微好一点。”

而是直接问：

“如果今天重新设计这个流程，到底应该怎么做？”

这就是 FDE 和传统软件项目第一个完全不同的地方。

他们不是先坐在会议室里写方案。

而是直接进入业务现场。

看真实流程。

找真正干活的人。

看真实数据。

拿真实退休案例验证。

问题不是“需求文档怎么写”。

而是：

这个事情，到底为什么会这么慢？

03｜第一个大坑出现了：他们一开始以为，找到数据要几个月

当团队开始追退休金计算所需要的数据时，事情看起来一下变得非常复杂。

数据并不在一个系统里。

不同部门有不同的数据。

不同年代有不同的系统。

有些系统负责 HR。

有些负责 Payroll。

还有一些历史数据存在更早期建立的数据库里。

对于传统 IT 团队来说，这很容易变成一次漫长的数据考古。

先画数据地图。

再确认字段。

再找系统负责人。

再申请权限。

再核对数据。

再确认业务规则。

然后发现还有一个系统漏了。

于是再重新来一遍。

所以他们最初的判断其实很合理：

“把这些数据真正找齐，可能要几个月。”

注意这里的“几个月”。

不是开发几个月。

不是上线几个月。

只是——

找到这些数据。

这就是传统大型组织最容易掉进去的坑。

你还没有开始解决问题，就已经被“把问题搞清楚”这件事拖住了。

04｜然后他们做了一件很不美国政府、但很 FDE 的事情：只给自己一周

团队没有接受“几个月”这个答案。

他们反过来给自己设了一个硬期限：

一周。

不是“争取一周”。

不是“先做个 PoC 看看”。

而是：

一周内，把数据问题搞清楚。

这时候，很多人都会觉得不可思议。

几十年的政府系统。

跨多个部门。

数据分散。

业务规则复杂。

历史遗留严重。

你告诉大家：

“给我一周，我把这些退休计算真正需要的数据找出来。”

很多人的第一反应大概都是：

怎么可能？

但 FDE 的工作方式，本来就不是先证明“为什么做不到”。

而是直接去验证：

到底能不能做到。

于是团队开始一头扎进现场。

找人。

找系统。

找数据库。

找历史记录。

找真实案例。

一个一个查。

一个一个连。

一个一个验证。

没有等一份完美的分析报告出来。

也没有等所有利益相关方先开完会。

先把最关键的问题跑通。

05｜所有人都在等一周后的结果，结果第4天，他们找到了

然后，故事出现了真正的反转。

原本预计几个月。

团队承诺一周。

结果呢？

第4天。

他们真的把关键数据找到了。

但更令人震惊的事情还在后面。

因为他们发现：

数据原来一直都在。

没错。

一直都在。

不是最近才建的。

不是这次项目才采集的。

不是突然从某个 AI 模型里生成出来的。

早就存在。

问题只是——

没有连起来。

HR 系统有自己的数据。

Payroll 系统有自己的数据。

退休业务系统又有自己的数据。

它们分别都在正常工作。

但从“一个退休人员到底应该拿多少钱”这个完整业务问题来看，它们彼此之间却像几个互不认识的部门。

每个人手里都有一块拼图。

但没有人把整张图拼起来。

所以这个项目最重要的发现其实不是：

“我们终于找到数据了。”

而是：

“原来我们从来没有缺过数据。” “我们缺的，是连接。”

06｜然后他们拿真实案例一算：退休金真的可以算出来

找到数据之后，团队没有停下来庆祝。

他们马上开始用真实退休案例做验证。

把已经处理过的案例拿回来。

把数据库里的数据重新接进退休金计算逻辑。

然后发生了一件很关键的事情：

对于非复杂案例，系统可以把退休金额精确算出来。

这一刻，整个项目的方向发生了变化。

因为他们证明了一件非常重要的事：

退休金计算真正需要的信息，并不需要重新创造。

数据已经存在。

业务规则也存在。

真正断掉的，是中间那条连接。

过去是：

人找资料 → 人填数据 → 人核对 → 人再核对 → 人计算 → 人审核

现在开始变成：

数据进入 → 系统预填 → 自动校验 → 自动计算 → 复杂案例交给人工。

一旦这条链路接起来，很多“必须靠人做”的动作突然就变得没有必要了。

07｜于是你才真正理解：为什么“6个月”可以被打到“4天”

很多人看到这个案例，第一个反应可能是：

“哇，他们技术太牛了。”

但我觉得这并不是重点。

他们真正做的，并不是发明了一个更快的退休金计算器。

而是把原来断裂的业务链重新接起来。

这意味着：

以前需要一个人花半天找资料。

现在系统自己找到。

以前需要几个人互相核对。

现在系统先做校验。

以前每个案例都走人工流程。

现在标准案例可以自动处理，人工只处理复杂案例。

于是原来巨大的等待时间开始坍缩。

6个月。

变成了：

几天。

而团队后来进一步把目标压到了更激进的范围：

4天。

所以真正值得记住的，不是“6个月”和“4天”这两个数字。

而是它背后的那条因果链：

不是人突然变快了。 不是 AI 突然算力爆炸了。 而是连接终于发生了。

08｜这篇故事真正解释了：为什么 AI 看起来这么高的生产率，往往很难直接变现

这里，我反而想把故事停一下。

因为这正是我觉得这个案例对今天企业最有价值的地方。

为什么 AI 写代码可以快几十倍，企业的实际生产率却没有同步提高几十倍？

因为现实世界里，真正的瓶颈，往往根本不在“写代码”这一步。

很多时候，瓶颈在：

“把事情搞清楚。”

甚至在：

“笨拙地一个个做用户面对面访谈，观察行为，分析真实需求。”

再往前一步，甚至在：

“和一堆彼此利益冲突的人，坐下来反复谈、反复试，最后达成一个大家勉强都能接受的流程方案。”

这才是现实世界。

所以你会看到一个非常有意思的现象：

AI 可以让一个工程师的代码生产率暴涨。

但如果这个工程师根本不知道：

要解决什么问题？

数据在哪里？

谁才是真正的用户？

谁会反对？

谁拥有规则？

哪些例外不能自动化？

那么代码写得再快，也只是更快地做错事情。

AI 提升的是“做”的速度。

而 FDE 要解决的是“搞清楚、连起来、跑起来”。

这两件事合在一起，才真正可能变成企业生产率。

09｜所以 FDE 和传统咨询最大的区别，不是“更快开发”

传统咨询通常是：

访谈 → 调研 → 分析 → PPT → 路线图 → 项目立项 → 开发。

FDE 更像：

直接进入现场 → 找真实问题 → 找数据 → 做第一个可运行结果 → 用真实案例验证 → 继续改。

它不是先把答案写出来。

而是一边进入问题，一边把答案做出来。

这也是为什么 FDE 团队往往很小。

几个人直接进入业务。

不等完整需求。

不等完整架构。

也不等所有人先把意见统一。

先把最关键的一段跑起来。

10｜AI FDE真正做的，不是“给旧流程加一个AI聊天机器人”

这也是我对 AI FDE 的理解。

它不是：

“我们在原来的流程上，加一个 Copilot。”

而是：

如果今天重新设计这个业务，哪些步骤根本不应该再由人来做？

比如：

哪些数据可以自动获取？

哪些字段可以自动判断？

哪些材料可以自动检查？

哪些规则可以自动执行？

哪些异常才需要人工？

哪些问题可以由 Agent 先处理？

当这些问题真正回答清楚之后，AI 才真正有地方发挥。

因为这时候 AI 不再是一个“外挂工具”。

它开始变成业务流程里的一个执行者。

11｜真正值得企业老板警惕的，是“数据明明就在你眼前”

今天很多企业都有同样的问题。

ERP 有数据。

CRM 有数据。

财务系统有数据。

销售系统有数据。

供应链系统有数据。

客服系统也有数据。

但你让老板问一个最简单的问题：

“把这些数据连起来，我们能不能自动算出这个客户现在到底值多少钱？”

很多公司答不上来。

为什么？

因为每个系统都只负责自己的一小块。

大家都有数据。

但没有人真正负责把这些数据变成一条完整的业务链。

于是，人就成了那个“连接器”。

人负责复制。

人负责粘贴。

人负责核对。

人负责判断。

人负责算。

企业真正昂贵的成本，往往就是这些“连接动作”。

12｜所以，AI FDE真正的价值，是找到企业里的“6个月→4天”

如果把这个美国退休系统案例浓缩成一句话，我会这样说：

最强的 AI 项目，不一定是发明了一个全新的 AI。 有时候，它只是终于有人把原本就存在的数据、规则、系统和人连接起来。

这也是为什么，未来企业真正需要的，不只是 AI 工具顾问。

而是 AI FDE 顾问。

不是先问你：

“你想买什么 AI？”

而是直接问：

“把你现在最慢、最贵、最依赖人工的一个流程给我看看。”

然后一起拆：

流程 → 数据 → 判断 → 规则 → 系统 → 自动化 → Agent。

最后交付的，不是一份 PPT。

而是一条真正能跑起来的新工作方式。

CTA｜你的企业里，会不会也藏着一个“6个月→4天”？

如果你看到这里，脑子里已经浮现出一个流程：

“这个事情我们公司也特别慢。”

“这个事情我们每个月都要做。”

“这个事情其实数据都有，就是散在几个系统里。”

那就很可能值得做一次 FDE 拆解。

你可以直接联系我。

我可以和你一起，把一个真实的企业或商业流程拆开来看：

现在怎么做 → 为什么慢 → 数据在哪里 → 哪些环节可以自动化 → 哪些判断可以交给 AI → 哪些部分适合做成 Agent → 最后到底能提效多少。

我们专注于 AI FDE 服务，已经服务了大量北美中小企业主。

我们希望做的，不是先卖你一个 AI 产品。

而是直接进入你的业务现场，帮你把流程、数据、规则和人工动作一层层拆开，找到那个真正值得重构的环节。

我们是一支来自中国、面向全球企业提供 AI FDE 服务的专业顾问团队。

因为真正有价值的 AI，不是让员工“多一个工具”。

而是让一条原本需要几个月、几周、几天的流程，重新变成一个完全不同的业务系统。

欢迎联系我，评论区留言：FDE

把你现在最慢的一个流程发给我。

也许，你的企业里，也有一个被几十个人每天重复维护的问题。

也许数据早就存在。

只是一直没有人把它们真正连起来。

而这，可能就是你下一个 AI FDE 项目的起点。

作者：申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

AI人工智能，SI超级智能，智能体场景搭建，FDE前端部署工程师，企业AI落地陪跑，驾驭工程（Harness Engineering）先行者

优普丰FDE AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

写 PPT 的、读 PDF 的、做尽调的、跑投研的，一个比一个好使。

结果打开 WorkBuddy，让它”帮我处理这个 PPTX”——它给了我一套从零开始的笨办法。

我愣住了：我那 74 个 Skill 呢？

它压根不看那个目录

原因很简单：WorkBuddy 只扫自己家那一个目录——~/.workbuddy/skills。

而我所有的 Skill 都躺在通用的 ~/.agents/skills 里。

两个世界，互不相通。你在别家工具里攒下的资产，它一个都不认。

说真的，这点挺不地道：连一个”添加目录”的开关都不肯给。

一句提示词，就打通了

我没有去翻文档，也没有研究它内部怎么实现的。

我把这件事原原本本丢给了 AI，就一句话：

帮我把 ~/.agents/skills 整个目录挂进 WorkBuddy，
又不影响它原有的 skill，怎么办？

它自己去查了 WorkBuddy 的扫描路径，确认了这个路径没法配置，然后试出了一个办法：在 ~/.workbuddy/skills 下建一条软链，把整个 ~/.agents/skills 挂进去。

完事它还自己验证了一遍——随手喊了一个只存在于那边的 Skill 名字，确认能调起来，才回来告诉我结果。

全程我没敲一行命令。

现在的样子

~/.workbuddy/skills/
├── _agents -> ~/.agents/skills   ← 打通了
├── ima-skills/                    ← 原有的，一个没动
├── obsidian/
└── ...

以后我在 Codex 或 Claude Code 里新装任何一个 Skill，WorkBuddy 这边自动就能看见。

唯一要留意的：~/.agents/skills 要被别的工具清理时，这边会跟着变。

别自己折腾

这件事给我的启发不是那条软链，而是解决问题的方式。

换以前，我会去翻文档、搜帖子、试各种命令，折腾半小时。

现在我把”我想要什么”说清楚，剩下的交给它：它去查、去试、去验证，回来告诉我可行不可行。

你不需要知道怎么做，你只需要知道你要什么。

如果你也在用好几款 AI 工具，试试这一句，看看你能打通多少 Skill。

💬 聊聊你的情况

你最常用的 Agent 工具是哪一款？攒了多少个 Skill？评论区报个数。

觉得有用的话，转给同样在用好几款 AI 工具的朋友。

作者：申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

AI人工智能，SI超级智能，智能体场景搭建，FDE前端部署工程师，企业AI落地陪跑，驾驭工程（Harness Engineering）先行者

优普丰AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

一个AI团队进驻企业，FDE 最常说的第一句话是：”我们先花两个月，把这个行业摸清楚。”

两个月后他们交出什么？一份PPT：行业规模、头部玩家、政策风向、技术趋势，一应俱全。客户客气地翻完，说一句：”写得挺全的，但这些我都知道。”

问题出在哪？不是不努力，是目标一开始就歪了。

他们想当行业专家。而项目需要的，是一个能快速找到真问题的人。

企业不会为你的行业知识买单。它掏钱，是因为你能在信息一团乱麻的时候指出：”这个环节，每个月白白烧掉两百个人工时。” 并且证明它确实能被解决。

这篇文章讲的，就是怎么在30天内，从一个什么都不会的外行，变成那个能指出这句话的人。

一、先认了：30天，你当不了专家，也没必要当

FDE（前线部署工程师），说白了就是带着AI能力住进企业现场的人。

这门活没法靠积累。今天在工厂，下个月可能进律所，再下个月是医美连锁。如果每个行业都得先干上三年才敢开口，这门生意压根没法复制。

所以真正要建立的不是一部百科全书，而是一张能打仗的地图。

我把这张地图压成六个格子：

• 钱，是从哪一步赚出来的
• 一件活要到账，得走哪几站
• 每站上，谁的签字最要命
• 他签字时，手里捏着什么材料
• 哪一节最容易掉链子
• 怎么判断掉没掉

这六格填到七八成，你就具备了进场说话的资格。

注意我说的是七八成，不是完美。行业理解在工程上唯一的作用，是支撑下一个动作，而不是支撑一场考试。

💡 落地动作：今晚就把你在服务的那家公司按这六格填一遍。填不出来的那格，就是你下周的功课。先找窟窿，比先背一百个名词有用得多。

二、行话是墙，六个笨问题能穿过去

每个行业都给自己筑了一堵术语的墙。MES、PLM、订舱、甩柜、报关单……你背得再多，也不等于知道一张单子卡在哪。

穿透它的方法很土：回到六个问题。

1. 客户掏钱买的到底是什么结果？

买一台设备，买的不是铁疙瘩，是”这条产线别停”。找货代发货，买的不是舱位，是”这批货别晚、别被扣、别多花钱”。看清结果，才知道哪些环节贵到不能出错，哪些环节糊弄一下也无妨。

2. 从有人提需求到钱到账，中间有几站？

把它拉成一条线。国际货代大概是：询价→比价→报价→订舱→提货→报关→装船→在途跟踪→到港清关→派送→对账开票。

这条线就是你的坐标系。后面所有资料、访谈、系统分析，统统往上贴，而不是散着堆。

3. 每一站上，谁说了算？

老板盯利润和风险，部门负责人盯效率和团队，一线盯今天能不能下班，IT盯系统会不会崩。同一个场景，在四个人眼里是四个完全不同的项目。没搞清楚谁拍板，方案再漂亮也是自说自话。

4. 他拍板的时候，手里捏着什么？

报价要看历史成交价、船公司合约价、当前舱位松紧；处理一次到港延误，要看提单、报关状态、仓库作业量和客户合同条款。

把”谁—凭什么—做什么决定”写清楚，AI方案的输入、输出、知识边界才立得住。

5. 哪一节最容易翻车？

AI的价值不藏在顺顺利利的主干道上。它藏在等待里、返工里、半夜的那通电话里。

高频重复、知识散落在几个人脑子里、数据要在四五个系统之间手抄、同一件事两个老员工判法不一样——这些都是信号，看到就记下来。

6. 公司用什么数字记账？

没有数字，就没有验证，只有演示。至少对齐三层：

• 模型层：准确率、召回率、有没有引用到对的依据
• 流程层：处理时长、一次通过率、人工接管比例
• 业务层：成交率、成本、赔付、客诉、回款周期

从模型层爬到业务层，项目才算真的进了价值链。停在模型层的，叫技术炫技。

💡 落地动作：把这六问做成表格，访谈时边听边填。你会发现第四问和第五问最难填——难填的地方，往往就是钱藏着的地方。

三、真懂了没有？看你有没有三张图和一把尺

读过五十份报告、能背几十个缩写，可我只要问一句：”一批货在口岸被查验，公司里第一个知情的是谁？他先看哪个系统？什么情况必须马上通知客户？什么情况只能干等？”

答不上来，那些知识一分钱都撑不住。

真正的理解，长成这个样子：

第一张：钱和风险的地图

钱从哪进、从哪漏。谁掏钱、谁使用、谁影响决定；收入按差价、项目还是订阅计；成本压在人力、获客、赔付还是履约；最大的雷是政策、安全、坏账，还是”某个老师傅一走，这块业务就瘫”。

这张图不追求全，追求一眼看得出轻重。

第二张：带堵点的链路图

多数人画流程只画顺境。真正值钱的部分恰恰相反——标出来在哪排队、在哪返工、在哪等审批、在哪必须打电话问某个人。

建议每个环节都用五件套写死：什么触发—用到哪些信息—做什么动作—产出什么—做到什么算合格。

举例：”客户来问货到哪了（触发）→ 用提单号和柜号（输入）→ 操作员登船公司网站、查内部系统、翻聊天记录（动作）→ 回复预计到达时间和下一步动作（输出）→ 四小时内首次响应、答复准确率达标（验收）”。

写成这样，工作流怎么搭、测试题怎么出，骨就有了。

第三张：名词之间的关系网

这门生意里到底有哪些”东西”，它们怎么咬在一起。

还是货代：客户、航线、船公司、航次、订舱单、提单、柜型、报关单、HS编码、查验、甩柜、异常事件、费用项、账单……

一张提单挂着某个船公司的某个航次；一次查验可能源于某个HS编码的归类问题；一次甩柜会连带引出改配费用和客户赔付谈判。

关系连出来，你的知识库怎么切、标签怎么打、证据怎么追溯，才不会是一团浆糊。

一把尺：验收标准必须在动手前写好

“回答得不错”不是标准。标准长这样：

有没有认出这是哪票货？有没有引用到适用的合约条款？有没有漏掉必须告知客户的时限？拿不准的时候有没有主动转给人工？给的建议里有没有写清下一步动作和责任人？

把尺子前置，就是评估驱动开发。它能救你于最后一公里——Demo惊艳、进现场就翻车的项目，大多死在没有这把尺。

💡 落地动作：三张图别追求好看，追求能被业务人员挑出毛病。他们改得越多，你的理解越值钱。

四、四周怎么排：从一张地图到一个能用的东西

第一周（1—7天）：立坐标系，忍住别下结论

第一天只干一件事：划边界。

“研究物流行业”不是边界，那是许愿。边界长这样：华南地区做跨境电商海运拼箱、年营收3亿到8亿的货代公司，只盯两件事——报价响应慢、运输异常发现晚。

边界越具体，你的研究越省钱。

第二三天做桌面作业，重点收六类东西：价值链和主流赚法、头部公司怎么活、政策与合规要求、常用的系统和数据对象、招聘JD里反复出现的岗位能力、公开案例里的成本和风险。

别一开口就让AI”写一份行业分析报告”。靠谱的做法是拆成一个个问题去查，让它吐出带依据的表，查不到的一律单独列进”不知道”那一栏。

顺带提醒一句：信息是分等级的。企业内部的制度、表单字段、真实业务数据、访谈录音，是硬通货；监管文件、年报、协会材料次之；媒体报道、咨询报告、厂商案例只能用来提线索；论坛帖子和AI自己编出来的内容，只配用作假设来源。越靠近真实方案，越要吃硬通货。每条重要结论都标上：出处、时间、适用范围、可信程度。

第四五天做行业词典。新手最典型的毛病是：每个词都听得懂，但不知道词和词怎么连。所以词条别只记定义，要记四件事——谁在用、出现在哪一步、跟什么东西连着、理解错了会捅什么娄子。

第一周结束，桌上应该有四样东西：

• 一页钱与风险地图
• 一张带堵点的端到端链路图
• 一份行业词典
• 一份”已证实 / 是推测 / 完全不知道”三栏清单

这时候千万别宣布自己找到了AI场景。第一周的成果，只够换一张进场的门票。

第二周（8—14天）：进现场，专门去找自己错在哪

这一周的关键词是证伪。

访谈最容易踩两个坑：一是请对方给你上课，你收获一堆百度也有的常识；二是问”你们希望AI帮你们做什么”，你收获”做个知识库””做个智能客服”——那不是需求，那是他们从别处听来的方案。

正确姿势是围着最近一次真事往下钻：

• 最近一次最头疼的在途异常是什么？从头到尾发生了什么？
• 第一条消息，是谁、从哪、用什么方式知道的？
• 你当时翻了哪几个系统、哪几个群、哪几份文件？
• 哪一步等得最久？为什么必须等？
• 哪个判断最依赖某个人的经验？
• 判断错一次的代价是什么？上一次判断错是什么时候？
• 最后怎么确认这事真结了？

具体发生过的事，比任何抽象描述都可靠，因为它自带动作、信息、判断和后果。

四类人必须都聊到，否则你拿到的是残缺版本：

• 决策者：今年的目标、预算、能承受多大风险、什么叫成功
• 部门负责人：卡点在哪、团队怎么被考核、部门之间怎么交接
• 一线执行者：真实怎么操作、哪些靠感觉、出意外怎么处理、要在几个界面之间跳
• IT与数据：有哪些系统、能不能开接口、数据干不干净、权限和安全红线在哪

只听老板，你拿到战略口号；只听一线，你会陷进局部修修补补；只听IT，最后项目变成一张技术功能清单。

访谈录音（取得授权后）可以转写、可以让模型提取事实和痛点，但证据必须能追回原话。我要求输出的每条结论都标上”可信 / 待确认 / 有冲突”，并注明它来自哪一句。

第二周补齐：修正后的链路图、角色地图、带证据的问题库、系统和数据清单、语义网草案。

第三周（15—21天）：把一堆抱怨筛成一个候选

很多痛点根本轮不到AI。有的是权责没划清，有的只是缺一张表单或一条规则，有的是流程压根没写清楚。能用流程调整解决的事硬塞大模型进去，成本和风险只会一起抬上去。

拿这六把筛子过一遍：

• 业务价值：对收入、成本、效率、风险影响大不大
• 发生频率：一天几十次，还是一年两回
• AI适配度：是不是真的在处理非结构化信息、复杂检索、内容生成或辅助判断
• 数据可得性：有没有数据、拿得合法吗、系统肯开吗
• 验证周期：两三周内能不能小范围试出来
• 组织意愿：有没有肯背锅的业务负责人、肯配合的一线、肯放行的IT

甚至可以粗糙打个分：优先级 ≈ 价值 × 频次 × 适配度 × 数据 × 意愿 ÷ 实施难度。

这个公式不追求数学精确，它的意义在于逼所有人把判断依据摊到桌面上，而不是靠嗓门大。

挑出来的场景，要能答上九问才算过关：谁在什么情况下遇到麻烦；现在这活怎么干；最慢或最容易错的是哪一步；AI具体接管哪一步；人保留什么决定权；需要哪些数据和工具；失败一次会怎样；用什么数字验收；验证过了往哪儿接。

回到货代：最后如果选中”报价助手”，它的价值不是替销售报价，而是把翻历史成交价、查合约价、算附加费、填报价单这些琐碎准备工作做完，让销售把精力留给”要不要让价”和”怎么跟客户谈”。

这个边界，比”给公司做一个物流知识库”清晰一百倍。

第四周（22—30天）：做一个难看但诚实的小验证

PoC不是产品的缩小版，是一次实验。它只回答四个问题：手上的资料够不够、模型在这个范围里可不可靠、输出能不能真的进到一线的工作流、这件事值不值得继续投钱。

• 22—23天：从历史单子里挑20—50个样本，覆盖高频的、复杂的、信息不全的、高危的。请业务专家给出期望动作、必要步骤、该引用什么、什么情况必须转人工。这就是你的标尺。
• 24—26天：搭最小链路。以报价助手为例：识别客户与航线 → 按有效期和合约过滤适配价格 → 生成含附加费明细的建议 → 附依据出处和风险提示 → 信息不全或触及红线就转人工 → 过程写回系统。技术上别炫技，能不能验证目标，是唯一的选型标准。
• 27—28天：离线跑一遍，外加主动找茬。重点看：答案对不对、依据有没有乱引、步骤缺没缺、风险漏没漏、该拒答的是不是硬答了、不同客户的合约有没有串线。
• 29天：让真人用。别问”好不好用”，记四个数字——任务花了多久、追问了几次、什么情况下人接手了、错在哪几类。
• 30天：交决策包。不是行业报告，是七样东西：钱与风险地图、链路图和语义网、场景候选及打分依据、可演示的原型、测试集与失败案例、数据和权限约束、下一步投入估算。

管理层真正想听的永远只有四句话：值不值得做、能不能做、风险控不控得住、下一步要不要继续掏钱。

五、六个坑，见过一次就够本了

1、把行业报告当成行业理解。宏观趋势还原不了一个人周三下午到底怎么干活。

2、先定方案，再去调研。进场前就决定要做知识库或智能体，后面所有访谈都只是在替你找赞成的证据。

3、只听管理层。制度里写的、领导以为的、一线实际干的，经常是三个版本。

4、只研究顺境。真正掏得动钱的地方，在异常、升级、扯皮和甩锅的流程里。

5、把模型能力当成业务价值。话说得漂亮不等于时间省下来了、赔付款变少了。

6、每次演示都没有同一套题。没有固定的评测集，版本之间的进步永远只是”感觉更顺了”。

还有一条常被漏掉：别用AI的结论，去给另一条AI的结论盖章。关键事实，必须回到企业的文档、数据和业务人员那里核实。

六、项目结束，别只留一份PPT

这次攒下的东西，应该是下次的起跑线：研究框架、建模套路、访谈题库、场景打分表、测试集、通用组件，都能带走。

但有一条线要划清楚：方法可以复用，事实不能。

同样是”智能客服”，跨境电商关心多语言、物流和退款，工业设备关心型号、安全规程和专家升级，照搬模板过去，第一周就会被业务人员当场拆穿。

还有一句可能不太中听的话：工具能提速，判断没法外包。

大模型、深度研究、知识库、语音转写、数据分析，非常适合当研究助理、结构化引擎和假设生成器。唯独”这事到底值不值钱”这个问题，只能由真实证据来回答。

附：可以直接抄走的一段话

进新行业时，我会把下面这段丢给AI，作为整个研究项目的底座：

你是我在这个行业里的研究搭档。我们要做的不是一份行业报告，而是在30天内找到一个值得做、证据够、两周能验的AI场景。

这次的范围是：【行业、企业规模、区域、客户类型】
重点盯的业务链路：【从哪一步到哪一步】
手上已有的材料：【列出报告、访谈、流程文件、数据】

接下来请你持续维护：行业怎么赚钱、关键角色和他们的KPI、端到端流程及异常分支、业务对象和术语、系统与数据分布、哪些是事实哪些是猜测、AI场景候选及打分、风险与人机边界、验证目标和计划。

规矩：
- 每条结论必须标出处、时间和可信程度；
- 事实、推断、建议三者分开写；
- 缺证据就提问题，不许编；
- 每次我喂新材料，你要指出它支持、修正还是推翻了哪条旧假设；
- 同时检查这事能不能用改流程、规则引擎或普通搜索更便宜地解决；
- 任何AI方案都要说清输入、输出、数据、工具、人机边界、失败模式和验收方法。

先给我：A. 当前认知地图；B. 十个最要命的未知问题；C. 未来七天的资料与访谈计划；D. 需要我去补的材料清单。

进场第30天，你大概率还是会被某个老师傅一句话问住。这不丢人。

丢人的是三个月过去，你还只能讲行业趋势。

把这一轮跑成一个循环：先猜 → 找证据 → 进现场 → 改模型 → 筛场景 → 做验证 → 用结果再改一轮。

跑完一圈，你可能依然不是专家。但你已经成了那个能在业务、管理和技术之间做翻译的人——把”我们想让AI帮帮忙”，翻成”这个场景、这组数据、这把尺，两周后见分晓”。

这个翻译能力，才是你走进任何一个陌生行业时，真正带得走的东西。

你最近一次闯进陌生领域，用了多久才算摸着点门道？中间踩得最狠的一个坑是什么？

评论区聊聊，我会挑几个回。觉得有用，也欢迎转发给正在做企业AI落地的同事。

作者：申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

AI人工智能，SI超级智能，智能体场景搭建，FDE前端部署工程师，企业AI落地陪跑，驾驭工程（Harness Engineering）先行者

优普丰AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

引子

上周，一个客户在会议开始 30 秒就告诉我：我们要做一个销售 Agent。

这种开场我见过太多次。它通常会沿着同一条路径走完——团队立刻讨论用哪个模型、知识库怎么建、要不要私有化、能接哪些系统。会议结束时 PPT 上画满了架构图，每个人都很兴奋，但有一件事始终没人说清楚：这个 Agent 究竟要替谁、解决哪一段工作、带来什么可被验证的差异。

这不是客户的错。”销售 Agent”五个字可以指会后整理纪要，也可以是线索打分、自动跟进、报价生成，甚至端到端推进商机。每一种理解背后，要的数据、权限、风险、人力，都不在一个量级。

FDE（Forward Deployed Engineer）这个角色在 OpenAI 当前被定义得很清楚——把 discovery、technical scoping、system design、build、production rollout 装进同一副担子，用生产采用率、可衡量的工作流影响和评估反馈来验收。也就是说，第一次见客户，本质不是展示能力，而是判断背后那条工作流值不值得被改造。

下面这 5 个判断，比”做不做 Agent”更基础。先问它们，再讨论模型。

5 个必须先回答的判断题

我把这 5 个判断叫做”销售 Agent 项目的第一关”。任何一项含糊，项目都会在 PoC 阶段或上线 3 个月内暴雷。

判断 1：这是一个真问题，还是伪需求？

伪需求长得像真问题。”别人都有 AI””老板让我们看看””竞品上线了 Agent”，这些都不是问题陈述。

真问题通常有三个特征：有可量化的现状损失、有清晰的触发频率、有可衡量的目标变化。

如何验证：让客户用结果而不是功能回答。如果对方说”做一个智能客服”，追问到”让哪一类问题在多少时间内被解决、复杂情况如何升级”，答案还能清晰，需求才站得住。

如果客户只能说”希望效率更高””体验更智能”，先别推进技术讨论，去量化现状——人工时间消耗、等待时长、返工比例、投诉率、收入泄漏。这些数字不存在，问题就不存在。

提示：把”我们要做销售 Agent”翻译成”我们要在 X 场景，让 Y 工作流，从 A 状态变成 B 状态，3 个月内验证 Z 指标”——翻译不出来，问题就不真。

判断 2：这条工作流，能不能被”画”出来？

工作流要被画出来，至少需要：触发事件、结束状态、关键步骤、5 种最常见的例外、最慢/最依赖个人经验的一步。

别只听 SOP 和流程图。让执行者打开真实系统，从头走到尾——你会看到流程图上不会画的复制粘贴、私人 Excel、群里确认、经验判断。

例外是真正的杀手。字段缺失、政策冲突、客户身份不明、系统超时、金额超限，这些不是”边界情况”，它们是真实场景中每天发生的事。例外的密度和复杂度，决定第一版要不要进一步缩小范围。

借鉴 OpenAI Academy 的工作流映射方法：触发、可信输入、当前步骤与绕行、交接、输出、摩擦、待标准化事项。一个工作流能被完整列出来，才能被改造。

提示：如果连”哪一步最慢、最容易返工”都说不出来，先别启动 Agent 项目，先做流程标准化。

判断 3：数据和系统，能不能撑起这个 Agent？

数据”存在”不等于”可用”。问三个具体问题：

第一，完成一次任务需要哪些信息，分别在哪里？结构化字段、文档、邮件、对话、外部 API，每一种的格式、质量、访问方式都不一样。

第二，谁是权威版本，谁负责更新？价格表、政策、产品说明如果在多个系统里互相打架，Agent 没法替客户做判断。没有 Owner 的知识库，会随时间快速失真。

第三，系统能读什么、写什么？CRM、ERP、工单、邮件、数据仓库，把”能接”拆解成：只读、生成草稿、更新字段、发送消息、执行不可逆动作。等级不同，风险和审批链完全不同。

没有一批脱敏历史样本和对应正确结果，就建不了基线和评估集。技术再好，也只能做主观演示。

提示：让客户一周内提供 50 个脱敏案例 + 正确动作。提供不出来，PoC 就是空中楼阁。

判断 4：错误可不可控，边界清不清楚？

一个错误最坏造成什么——错误答案、错误写入、错误付款、错误拒绝客户——四种风险的量级完全不同。严重性、可逆性、影响范围，决定了 Agent 能拿多少自主权。

把决策分成三类：AI 可以直接完成、AI 准备好供人审核、必须由人承担。建议不是授权，模型置信度也替代不了组织决策权。

升级不是失败，是工作流的一部分。要定义清楚：什么时候停下来、交给谁、需要携带什么上下文、多久内必须响应。用户在群里反复把事情重新讲一遍，说明升级机制没设计。

数据访问也要追问：哪些字段绝对不能读、哪些结果不能传出、哪些数据不能长期保留、保留多久、由谁审批。这一步国内企业尤其容易跳过，事后补很贵。

参考 OpenAI 的 Agent 实践材料：允许哪些信息、禁止哪些动作、人工复核怎么设、停止/询问/升级的条件是什么。首次会议不一定要做完风险评审，但下一轮谁必须加入，必须在这里识别出来。

判断 5：组织有没有条件长期运营它？

Agent 不是一次性项目，是长期运行系统。谁是业务 Owner，谁能决定范围和验收——提出需求的人不一定对结果负责。

Owner 需要能提供用户、数据、业务判断，并能处理跨部门阻塞。如果一线团队正在承受多个系统切换，业务负责人在会议上口头支持，那都不是真正的支持。

上线后谁负责支持、监控、知识更新、事故处理？没有持续 Owner，Agent 会在人员变动、政策更新、模型升级之后失效。FDE 不能把自己的长期驻场当成唯一的运行方案。

提示：用户在哪工作？如果新方案要求改变入口、重复登录或手工搬运，采用成本必须算进去——CRM、邮箱还是协作群，决定了用户愿不愿意用。

把这 5 个判断做成一张表（口头评估也行），能回答 4 个以上，再进入技术范围和 PoC 设计。只能回答 2 个，下一步就变成流程标准化、样本审计、风险工作会。只能回答 0-1 个，最好先暂停项目。

怎么听，才能听到真话？

客户同一个问题，可能给出三种性质完全不同的回答。

“上个月一共处理了 4280 张工单，平均解决时间 16 小时”——这是事实，能回系统核验。”客服觉得查政策最浪费时间”——这是一线判断，需要跟岗、抽样、交叉验证。”上线后效率提升一倍”——这是目标或愿望，不能直接当基线。

会议记录里最好给每一条回答标注证据等级：已有系统数据、可现场提供样本、需相关 Owner 确认、暂时只是假设。这不是怀疑客户，是避免团队在不同含义的数字上做方案和报价。

追问也要从抽象走向具体。客户说”流程很慢”，就问最近一次超时发生在哪一步；说”数据很多”，就问一周能不能给 50 个脱敏案例；说”准确率必须 99%”，就问当前人工基线是多少、哪类错误比其他错误更严重。

一次 60-90 分钟的首次会议，可以这样切：前 15 分钟聊目标与背景，中间 40 分钟沿真实案例走流程，随后 20 分钟确认系统、风险与责任，最后 10 分钟复述已知、未知和下一步。参与的人多时，别试图当场敲定所有细节——把需要一线、技术、风险相关方回答的问题，拆成后续工作会。

国内项目尤其要留意”名义流程”和”实际流程”的差。审批写在系统里，优先级却在微信群里敲定；数据名义归某部门，接口权限却由集团 IT 管着；业务负责人支持项目，一线团队正在多个系统间切换。把这些组织现实问出来，比多确认一个模型参数更能预测项目能不能落地。

会后别只发纪要，要交付 5 样东西

第一，一句话问题陈述与预期结果。

第二，当前流程、关键例外、痛点地图。

第三，数据、系统、权限、相关 Owner 清单。

第四，初步的 AI/人工边界与主要风险。

第五，下一步验证计划、责任人与时间。

把仍然未知的部分单独列出，区分”客户待提供””FDE 待验证””需安全或法务决策”。这样第二次会议才能往前推，而不是把第一次讨论再讲一遍。

第一次见客户，最不该做的 3 件事

第一，不要在问题还没说清时展示所有产品能力。客户会被功能带着走，真实流程反而被藏起来。

第二，不要只和高层谈愿景。方向、例外、依赖、边界，分别由不同角色掌握——缺任何一方都不完整。

第三，不要承诺未经数据和流程验证的 ROI。可以提假设和测量方法，不能把估算说成结果。

结尾

FDE 的专业感，不来自现场回答所有问题，而来自清楚知道哪些问题现在必须回答、哪些证据还缺、哪些人必须加入，以及在信息不充分时不替客户做未经授权的决定。

第一次会议结束时，最好的结果不是客户说”这个 Agent 听起来很厉害”。

而是双方都能清楚复述：我们在解决哪条工作流，为什么值得，第一版做到哪里，哪里必须由人负责，以及下一步用什么证据决定要不要继续。

讨论

你第一次见客户时，最常被客户问到的第一个问题是什么？你是怎么回答的？

作者：申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

AI人工智能，SI超级智能，智能体场景搭建，FDE前端部署工程师，企业AI落地陪跑，驾驭工程（Harness Engineering）先行者

优普丰FDE赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

老板说”做个 AI，今天就开始”。

48 小时后，你交的是会议室里能讲的 Demo，还是真实工单里能跑的系统？

大多数团队交的是前者。三个月后，这个 Demo 安静地躺在内网链接里，工程师继续手工翻手册、查历史记录。

但另一种工作方式能交出后者。差别不在工具，不在模型，而在 48 小时里被悄悄跳过的 5 个动作。

⚠️ 边界说明： 本文的时间、人数、字段数字均为合成示意，不对应任何一家具体公司，也不构成效率承诺。这里说的”上线”指的是受限试运行，不等于完成安全审计、灾备、全量集成的企业级生产上线。

这 5 个动作分别是：

1. 把”做 AI”翻译成可验证的问题，而不是急着写 PRD
2. 坐到一线工程师旁边挖例外，而不是回工位开需求会
3. 准备最小数据包，而不是把所有文档塞给模型
4. 部署只打开第一道门，而不是一次性放开所有权限
5. 用真实反馈而不是漂亮演示收尾

下面分别拆开。

一、把”做 AI”翻译成可验证的问题

周一早上，老板、技术负责人、售后经理和 FDE 一起进会议室。老板扔下一句：”最近售后回复太慢，能不能做个 AI，今天就开始？”

传统团队的习惯动作是接需求、立项、评审、排期。

FDE 的第一步是改写问题。

他请三位售后工程师打开昨天的真实工单，演示从收到问题到发出回复的全流程。结果发现，耗时的大头其实不在”不会写回复”，而在三次切换：先按设备序列号查型号和软件版本，再到几个文件夹里翻对应手册，最后查历史工单确认类似故障是否出现过。

比慢更危险的，是另一件事：引用了旧版手册，给出过期的操作步骤。

于是原话”做个 AI”被改写成一句话：

针对一个设备系列的技术咨询工单，自动定位对应版本的手册片段与相似历史记录，生成带证据的回复草稿，由售后工程师人工确认后再发出。

这次改写同时定了四条边界：只覆盖一个设备系列；只处理技术咨询，不碰退货和安全事故；只生成草稿，不自动发给客户；每个结论必须附原文页码。

FDE 当场写下第一版指标：准备一条回复要多久、证据引用正确率、工程师采纳与修改比、高风险错误数。

老板口中的”快”，第一次变成了一个能证伪的命题。

二、坐到一线旁边挖例外，而不是回工位写需求

接下来一个半小时，他没回工位。

他追问那些文档里没写的例外：序列号录错了怎么兜底？同一个型号为什么会有三个手册版本？历史工单里的客户隐私怎么处理？哪些词出现时，AI 绝不能给操作建议？

一线用户会自然说出这些规则——

“工单里提到异响、过热或安全联锁，必须立刻转人工专家。” “固件版本无法确认时，只能给排查思路，不能给操作步骤。” “引用不带页码，工程师根本不会信。”

这些不是”二期需求”，而是第一版系统的设计输入。

FDE 在白板上画出最小流程：工单进入 → 判断范围与风险 → 范围外直接退出 → 范围内按设备信息筛选资料版本 → 检索手册与相似记录 → 生成带页码草稿 → 工程师选择采纳 / 修改 / 拒绝 → 全程留日志。

此时还没开始写代码，但项目最重要的一半已经完成：

知道什么不做，知道什么算错，知道谁拥有最终决定。

三、最小数据包，而不是”把所有文档扔进去”

中午他和数据工程师碰头，没有去翻整个知识库。

他们准备的最小数据包只有四样：一个设备系列的现行手册、停用版本清单、脱敏后的历史工单、设备型号与固件版本的映射表。

几个关键动作：

• 先确认数据授权，只在受控目录内做脱敏，覆盖客户名称、电话、地址
• 给每份文档补齐版本、适用型号、生效日期与页码
• 从历史工单里抽出覆盖常见问题、长尾问题、风险词的样本，封存一组用于第二天盲测

测试标准也不是”回答像不像”，而是分开检查五件事：范围识别对不对、版本匹不匹配、证据能不能回到原文、草稿可不可用、高风险工单有没有正确退出。

只要出现一条”本该转人工却给出明确操作步骤”的错误，试运行立刻暂停。

四、部署只打开第一道门，不是一次性放开权限

下午两点，他开始让 Codex 读取授权目录与接口约束，生成最小 Web 应用骨架：工单输入、设备信息校验、资料检索、带引用的草稿、人工确认按钮、审计日志。然后让代码代理补测试、评估脚本、容器配置与最小部署说明，逐项审查变更。

OpenAI 对 Codex 的当前描述覆盖了从修改、设计、构建、发布到维护的软件生命周期，官方也展示过从设计稿到功能原型的协作方式。但”能生成”不等于”可以不审”——模型如何访问数据、接口能否写入生产、哪些命令需要批准，依然由人决定。

另一类 AI 工作台在这个故事里承担别的活：读取授权目录里的会议记录、流程截图、测试表，整理成需求摘要、风险清单、用户试用说明、测试报告。功能随版本、账号、权限不同，团队仍要逐项核验产物。

这里有一个关键的工作方式：FDE 不会丢一句”做个售后智能体”给工具然后等奇迹。

任务会被拆成可验证的小块，每块都附输入、限制与验收方式。代码代理失败时，也不只是重复提示”再试一次”，而是回头查缺的是数据说明、测试样本、工具接口还是环境约束。

第一次评估失败，真正的项目从这一刻开始

第一版很快能跑，结果却不漂亮。

常见工单上的草稿很流畅，但有两类问题：检索结果混进了旧版手册；遇到固件版本缺失时，仍然给出过于肯定的步骤。

如果目标只是 Demo，这一版已经能在会议室里展示。FDE 关心的是它能不能进现场。他做了三个动作：

• 把文档版本从”提示词提醒”升级成检索前的硬过滤
• 把固件版本缺失设为明确的退出条件，只允许系统追问信息
• 风险词命中后不再生成建议，直接显示升级路径

第二轮评估里，语言可能没第一版那么”聪明”，但行为边界更清楚。

这正是企业 AI 经常被忽略的取舍：

一个可靠系统的标志，不是每次都回答，而是知道什么时候不能回答。

晚上部署，但只开四道门中的第一道

晚上八点半，团队把系统部署到内部测试环境。

四条限制同时落地：只能读经过筛选的资料、不能写回 CRM、不能自动发消息、只有五个指定账号能登录。每条草稿都必须由工程师人工确认。日志记录输入、检索证据、模型版本、输出、用户动作、错误。一个开关可以立刻停掉服务。

OpenAI 公开的 Codex 安全实践强调，要限制代理能访问什么、对高风险动作要求人工批准、保留足够的遥测来解释行为。NIST 的 AI 风险管理框架也要求部署前测试、运行中监控、明确人类监督与停用机制。

所以 48 小时”上线”的合理定义是：有限用户、有限数据、有限动作、有人监督、可回滚。

如果系统能直接操作设备、自动承诺赔付、读取大量敏感数据，或错误会引发人身与重大财务风险，48 小时就不该进入真实流程。

快不是绕过审批，快是把第一阶段的风险半径设计得足够小。

五、用真实反馈而不是漂亮演示收尾

第二天早上，先做一轮盲测

团队取出前一天封存的测试集。

FDE 不只看总体正确率，而是按失败类型逐条过：范围外工单是否被拒绝、设备版本是否匹配、引用能否回到原文、高风险词是否触发升级、草稿是否需要大幅重写。

示意性的测试记录里，团队可能看到这种结构：多数常见问题能给出可追溯草稿，一部分需要工程师修改，少数因信息不足或风险词被系统正确拒绝。

决定能否试用的，不是一个漂亮的总分，而是没有越过事先画好的红线，并且所有失败都能被记录与解释。

十点半，五名售后工程师开始用真实新工单。FDE 坐在旁边，不指导他们”如何用 AI”，只观察何时打开、是否信任引用、为什么修改、什么时候直接绕过系统。

很快又冒出一个代码之外的问题：工程师不是不信 AI，而是不愿意重复输入设备信息。FDE 当场把工单里的设备字段自动带入页面，让代码代理补上字段校验与测试。

另一位用户希望自动发送回复，FDE 明确拒绝——当前阶段没有足够证据取消人工确认。

下午，现场验证的不是模型而是工作流

团队开始看到第一轮真实反馈。

有的草稿内容正确，但引用展开方式太慢；有的历史案例很相似，却因客户环境不同不能直接复用；高级工程师不需要完整答案，只想先看到最可能的两份手册。

FDE 一边记录，一边区分三个层次：

• 界面问题今天改
• 数据口径问题交给数据工程师
• 涉及风险策略的问题留到阶段评审

他还看采用行为。用户点了”采纳”，是否真的节省了时间？被修改的段落集中在哪？被拒绝是系统错误，还是工单本就超出范围？如果用户复制草稿后在别处大改，界面上的”采纳率”会虚高，必须补观察。

FDE 的现场感就在这里：

模型评估告诉你系统在测试集上表现如何，一线行为告诉你它有没有进入真实工作。

48 小时结束，交付物不是一个 Demo

第二天下午五点，FDE 没有用炫酷演示收尾，而是交出六样东西：

• 可运行的受控应用
• 带版本与权限的数据包
• 测试集与评估结果
• 风险红线与停用开关
• 五名用户的采用与失败记录
• 下一阶段的决策建议

合理的结论可能是”继续，但不扩到全公司”：再用两周覆盖更多型号，修正文档版本治理，接入只读 CRM 字段，保持人工确认；只有高风险错误持续为零、引用质量稳定、用户确实节省准备时间，才讨论扩大账号范围。

失败也可能是好结果。如果真实数据证明资料版本混乱、用户需求太分散，或者人工确认反而更费时间，团队可以叫停，把资源放到更合适的流程上。

48 小时发现”不值得继续”，往往比两个月后交一个没人用的系统更有价值。

回到开头：这 5 件事，另一种说法

如果用更短的句子重新表达这 5 个动作，它们其实是 5 种”快”。

第一种快，缩小问题。老板说”做 AI”，半天内压缩成一个用户、一段流程、一组数据和一个可验证结果。

第二种快，建立证据。不是等系统做完再测，而是先定义样本、红线与基线，让每次构建都能拿到反馈。

第三种快，修改路径。FDE 保留从业务到代码的上下文，现场问题不用经过多层转述才能进入产品。

第四种快，控制风险。权限、人工确认、日志与停用不是上线前的补丁，而是一开始就决定试运行能否发生的条件。

第五种快，作出决策。继续、调整还是停止，都有证据支撑，不用更大的愿景掩盖不确定性。

最后的诚实

企业 AI 的大量项目不可能两天完成。遗留系统集成、数据治理、安全评审、压力测试、灾备、合规、组织变革，都需要时间。把这些工作删掉再说”48 小时上线”，只是在重新命名 Demo。

但一位合格的 FDE 确实可以在 48 小时里做成一件重要的事：

让一段模糊的需求，第一次接触真实数据、真实用户、真实约束，产出一个可验证、可撤销的下一步。

他借助各种工具提速，但真正稀缺的依然是人的判断——选什么问题、什么不能做、什么算成功、什么时候该停。

FDE 的一天看起来很杂：开会、看流程、拉数据、写代码、部署、坐到用户旁边、改方案。把这些动作连起来，你会发现他始终只在做一件事：

缩短业务问题与生产反馈之间的距离。

💬 留言区

如果让你带着”周一早上 48 小时”的视角，重新看你手头那个已经推进半年的 AI 项目——

你会先改的三件事是什么：问题定义、用户接入，还是风险边界？

挑一件最想先动的，在评论区聊聊。

作者：申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

AI人工智能，SI超级智能，智能体场景搭建，FDE前端部署工程师，企业AI落地陪跑，驾驭工程（Harness Engineering）先行者。优普丰AI FDE帮助企业落地AI

优普丰AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。

Echo、Delta、FDPM，首先是三类责任，也可以理解为三组能力，并不必然对应三个固定岗位。
FDPM 负责把各方拉到同一个目标上，并让项目最终产生结果。

去年陪一个客户复盘 AI 项目，对方 CTO 说了句话让我印象很深：

“200 万招了一个’超级 FDE’，他一个人扛了 5 个人的活，最后崩溃了，项目也黄了。”

走访过十几家做 Agent 落地的公司后，我反复看到同一个剧本：把”AI 落地”理解成”找几个能人”的团队，几乎都活不过第二年。

FDE（Forward Deployed Engineer，前线部署工程师）这个概念最早来自 Palantir。OpenAI 在 2026 年 5 月专门为这类团队成立 Deployment Company，把他们的工作定义为：在企业内部设计、构建、测试并部署生产系统，把模型接入客户的真实数据、工具、控制机制和业务流程。工信部最新文件也用了”前线部署工程师团队”这种表述。

关键词是”团队”，不是”工程师”。

一、为什么”超级 FDE”一定会失速

老板招 FDE 时，开口往往是：”找几个能写代码、能讲 PPT、能陪客户喝酒的全栈 AI 工程师，预算不设上限。”

这种配置做 Demo 没问题——2-4 周就能交出一个漂亮演示。但进生产就会陆续爆雷：

半年后客户说不清 AI 到底解决了什么问题

需求越加越多，每次反馈都变成插队任务

数据接入要排队等 IT 审批

换了新版本模型，效果突然变差，没人定位是 prompt 还是数据问题

上线后才发现没人盯监控，故障靠用户投诉才发现

业务人员工作方式原封不动，系统沦为”高级玩具”

根因不在工程师能力，而在于团队把该由 6-10 个人一起扛的活，压到 1-2 个”超级个体”身上。

二、FDE 团队必须跑通三类结果责任

把 FDE 团队类比成一家微型创业公司，它要跑通的事情就清晰了——同时交付三种结果：

业务结果：把客户那句”我想用 AI 解决 XX 问题”，翻译成可验证的场景——”在 X 流程里，把 Y 任务的耗时从 10 分钟降到 2 分钟，准确率不低于 95%”。回答清楚”做什么、为什么值得做、怎么算成功”。

工程结果：不是 Demo，是能在客户生产环境跑的系统。Agent、RAG、工作流都要接入真实数据，并在权限、评测、监控、回滚和人工接管机制下稳定运行。

运营结果：业务人员真的用起来。这次写的连接器、攒的 Skill、踩的坑，下次能复用。

只跑通业务结果，那是咨询公司；只跑通工程结果，那是外包公司；上线就走人，迟早退回人工流程。

完整的 FDE 体系必须把三种结果连成一个闭环——业务定义场景，工程实现场景，运营把场景变成日常，并反哺下一个场景。

三、前线小队：6-8 人对交付结果负责

一家微型创业公司通常 5-10 人，FDE 团队的标准生产项目也是 6-8 人。人数不是硬指标，关键是六类责任都要有明确的归属。

1. Echo——蹲客户的”翻译官”

常见错误：让”售前”兼任 Echo，结果他只关心能不能拿下单子，不关心场景值不值得做。

正确做法：Echo 是 Palantir 招聘体系里 Deployment Strategist 的岗位名称，主要职责是深入客户工作流、定位最重要的问题并与工程师共同交付。他关心”做不做、做哪个”。

产出与考核：核心交付物是业务流程图、场景优先级、价值假设和行业对象模型。考核场景价值、客户信任，以及方案能否跨客户复用。

名字未必照搬，但”做什么、为什么值得做”必须有人兜底。

2. FDPM——守住范围的”守门员”

常见错误：让传统 PM 兼任 FDPM，结果他围绕通用路线图工作，没人对单个客户的部署结果负责。

正确做法：FDPM（Field/Deployed Product Manager）把业务目标翻译成可交付范围，管理里程碑、客户预期、测试用例、验收标准和风险清单，直接面对一个客户的真实环境。

产出与考核：产出里程碑、验收标准、风险清单。考核需求变更率、一次验收通过率。这个称谓还在演变，Deployed Product Manager、Field Product Manager 都是同义变体。

3. 技术负责人——架构决策者

常见错误：让首席工程师兼任，结果他既写代码又做决策，最后技术债缠身，关键决策没人拍板。

正确做法：连接客户架构和内部产品，对模型选择、总体架构、数据边界、集成方式与上线策略做出端到端决策。他不该成为所有代码的唯一作者，而要保证关键技术决策一致。

4. Delta——主力构建力量

常见错误：只看代码量或工时，结果 Delta 把精力都放在写代码上，没有把现场反馈转化为产品改进。

正确做法：Delta 通常配置 2-3 人，负责 Agent、RAG、工作流、Prompt、前后端与业务应用。Palantir 当前把 Forward Deployed Software Engineer 岗位归入 Delta，职责从高层系统设计、原型开发一直覆盖到应用构建和数据集成。

考核 Delta 要看任务成功率、迭代速度、代码质量，以及现场反馈能否快速转化为产品改进。

5. 数据与系统集成工程师——和 IT 部门”打架”的人

常见错误：把数据集成当外包，最后依赖人工复制数据，Agent 进不了真实业务闭环。

正确做法：企业 AI 的大量时间消耗在数据库、API、ERP、CRM、身份权限和遗留系统上。这个角色负责数据管道、连接器、权限映射和接口文档，对数据质量、接口稳定性与连接器复用率负责。

6. AI 评测与质量工程师——守住质量底线

常见错误：把评测当成”上线前最后一周”的工作，结果模型升级后效果回退没人能定位。

正确做法：他负责黄金测试集、自动评测、回归测试、长尾错误和 A/B 测试。Anthropic 在 2026 年发布的 Agent 评测实践中强调，评测应贯穿整个生命周期：自动化测试用于发布前快速迭代，生产监控发现真实分布变化，人工审查再用于校准主观质量。

早期项目里，评测职责可以由资深 Delta 兼任，但”由谁定义成功、谁阻止质量回退”必须写进团队分工。

四、后方团队：决定 FDE 能否从项目制走向规模化

创业公司走到第二、第三个客户时，最容易崩在”后方支撑”。前线小队之外，需要一支服务多个项目的后方平台与产品化团队。

它们不一定每个项目全程驻场，但责任不能缺席。

🛠️ 平台工程／SRE 负责部署、可观测性、扩缩容、成本、回滚与故障响应。Google SRE 的 Production Readiness Review 会检查架构依赖、指标监控、应急响应、容量和变更管理。对企业 Agent 来说，还要额外加上模型版本、Token 成本、工具调用轨迹和人工接管率。

🔒 安全与合规负责人 负责数据访问、隐私、身份权限、审计、第三方模型风险与兜底边界。NIST AI RMF 要求组织明确 AI 风险责任、上线前测试、生产监控，以及申诉、覆盖、事故响应和退役机制。安全不该在上线前最后一周才进场，而要从场景设计阶段就决定哪些数据能看、哪些动作能做。

🌱 客户成功／组织变革负责人 负责培训、采用计划、运营数据与扩展路线图。系统上线只是起点，只有业务人员把它纳入日常流程，项目价值才会从”可用”变成”被使用”。早期这项职责可以由 FDPM 兼任，战略客户应配置专人。

📚 产品／知识工程负责人 负责把现场经验抽象为 Skill、连接器、模板、行业本体、评测集、Playbook 和失败案例库。OpenAI 当前对 FDE 管理者的要求中，明确包含把有效实践编码为工具、方法和产品路线输入。

这个角色决定了 FDE 是不断重复定制，还是形成越交付越快的复利。

五、客户侧必须建立一支”镜像团队”

创业公司和供应商合作有个常见的失败模式：把所有决策权都压在供应商身上。

供应商人员再完整，也无法单方面完成企业 AI 交付。客户至少需要六个明确接口：

• 业务 Sponsor：确认优先级，推动跨部门协同
• 业务流程负责人：提供真实规则和异常
• IT 或架构负责人：负责系统接入与上线审批
• 数据负责人：确认口径、质量和访问权限
• 安全合规负责人：审批日志与风险边界
• 一线种子用户：参与试用、UAT 和后续推广

最关键的不是把人名填进通讯录，而是确保他们有时间、有决策权，也愿意共同承担验收结果。

如果只有客户 IT 参与、业务负责人长期缺席，团队通常只能证明”技术可以做”；如果只有业务部门参与而 IT、安全没有尽早进入，项目会在演示之后卡在账号、接口和上线审批上。

六、不同项目规模，怎么安排人数

创业团队在不同阶段规模不同，FDE 团队也一样。

🟢 轻量 PoC：3-4 人。Echo 或 FDPM 负责价值与范围，一名技术负责人控制架构，一至两名 Delta 完成原型，数据、安全和平台专家按需评审。目标是验证价值和技术路径，PoC 代码不能直接当成生产方案。

🟡 标准生产项目：7-10 人。配置完整前线小队，SRE、安全、客户成功与产品化角色由后方共享。这是单部门、单核心流程比较稳妥的形态。

🔴 战略客户或复杂行业：10-15 人以上。Echo 与 FDPM 应分别专职，Delta 按 Agent、应用、集成等方向分工，评测、安全、SRE 和客户成功独立配置，同时设置项目总监和高层 Sponsor。金融、制造、医疗、政务以及多供应商项目尤其需要内部技术锚点，确保核心架构、资产和责任始终有人掌握。

七、考核要看四组数，别只盯着”按时上线”

创业公司只盯”按时发版”会死，FDE 团队也一样。

FDE 团队的指标至少要覆盖四组结果：

📈 客户价值：任务完成率、处理时长、成本变化、用户使用率和满意度。

⚙️ 工程质量：评测覆盖率、系统可用性、故障恢复时间、权限控制和人工接管能力。

🧱 资产沉淀：Skill 与模板产出、连接器复用次数、跨项目节省工时和反馈采纳率。

💰 商业结果：从 Land 到 Expand 的周期、续费率、场景扩展率、单客户交付成本和项目毛利。

早期团队可以把工程师大部分精力放在交付上，但必须预留稳定的资产沉淀时间。随着团队成熟，复用指标的权重应逐步提高。否则项目越多，高手越忙，交付成本反而越高。

最后：判断团队是否完整的三个问题

把整套团队压缩成一句话：

“1 名 Echo 定义问题，1 名 FDPM 推动范围与组织，1 名技术负责人控制架构，2-3 名 Delta 完成构建，数据与评测角色保证输入和质量；SRE、安全、客户成功、产品与知识工程在关键节点进入，客户侧再提供一支拥有决策权的镜像团队。

PoC 阶段可以把最小核心压缩为 Echo、FDPM、资深 Delta 与产品／知识工程四类责任，由少数人兼任。但进入生产后，数据集成、评测、SRE、安全和客户成功必须补齐。

判断一支 FDE 团队是否真正完整，可以连续问三个问题：

1. 它能否把模糊业务问题推进到生产上线？
2. 能否让业务人员真正使用，并产生量化价值？
3. 能否让下一次同类交付明显更快、更便宜？

只做到第一项，是一支项目交付团队。三项都能做到，才是一支真正的企业 FDE 团队。

岗位可以合并，责任不能消失。项目越接近生产，质量和治理角色就越需要前置。

💬 聊一聊

你在 FDE 团队配置上踩过哪些坑？是”蹲客户的 Echo 永远招不到”，还是”客户那边接口人一直没决策权”？评论区聊聊。

作者：申导Jacky，优普丰AI敏捷创新培训咨询机构合伙人

AI人工智能，SI超级智能，智能体场景搭建，FDE前端部署工程师，企业AI落地陪跑，驾驭工程（Harness Engineering）先行者。优普丰AI FDE帮助企业落地AI

优普丰AI赋能企业AI智能体skill/AI转型落地

一个在AI时代重新定义”工程师”角色的实践者和敏捷教练。

曾经每天写代码12小时,现在每天写规格2小时,效率提升50倍。