很多人对 FDE 有一个误会：只有行业专家，才做得好企业 AI 落地。

这话只对了一半。

行业经验当然重要。但 FDE 的项目不会永远来自熟悉的地方——今天服务制造企业，明天进律所，下个月又得面对跨境电商或者一家医美机构。如果每进一个行业都要先花三年变成专家，这行的交付量就永远上不去，人也没法规模化。

所以真正要练的，是一套快速建立认知的机制：知道问谁、看什么、怎么建模、怎么用 PoC 验证你的理解。

陌生行业的信息量很大。以制造业为例，研发、采购、生产、质量、仓储、销售、售后，每个环节都有自己的角色、系统和术语。要是一上来就搜「制造业全面知识」，最后很可能收藏了几十份报告、记住了一堆名词，还是不知道这家企业到底卡在哪。

方向从一开始就错了。FDE 的行业理解要服务于三个结果：找到值得解决的问题；判断 AI 能不能解决；推动方案进到真实业务里、产生结果。

所以你要的不是一部行业百科全书，是一份最小可用行业模型：

这六项能讲清楚，你就已经具备了进场景、做方案、搞验证的基础。

30 天当然不够让你成为行业专家。但 30 天够一名合格的 FDE 干成五件事：

这就是「理解一个陌生行业」的工程化定义——不是你知道多少，是你能交付什么。

行业千差万别，但企业是怎么活的，底层结构其实很像：拿到资源、创造价值、交出去、在约束里挣到钱。

所以先把术语放下，问六个问题。

第一，客户为什么付钱。 客户表面买的是设备、法律服务或者软件，真正买的是某种结果。买工业设备，买的还包括稳定产能、运行安全和售后保障。搞不清客户买的是什么结果，你就判断不出哪条流程最要紧。

第二，价值怎么交付出去。 从客户提需求到企业收到回款，中间过了哪些环节。制造业可能是：线索—询价—选型—报价—合同—排产—生产—质检—发货—安装—售后。这条链路是研究的主干，资料、访谈、系统分析全都挂在它上面。

第三，谁在做关键决策。 老板看利润和风险，部门负责人看效率，一线员工看工作量和好不好用，IT 看安全、集成和稳定。同一个 AI 场景，在这四类人眼里的价值完全不同——这也是为什么方案只说服了老板，落地照样会翻。

第四，决策依赖什么信息。 报价要看 BOM、历史价格和利润要求；故障诊断要看设备型号、报警码、维修记录和手册。把「谁基于什么信息做什么决定」讲清楚，AI 方案的输入、输出和知识边界才会清楚。

第五，什么情况最容易出错。 AI 的价值多半藏在异常、等待、返工和不确定里。高频重复、知识分散、依赖个别老师傅、跨系统搬数据、判断口径不统一——这些都是重要信号。

第六，企业用什么指标判断结果。 没有指标就没有真正的 PoC。指标至少分三层：模型指标（准确率、召回、幻觉率）、流程指标（处理时长、一次通过率、人工接管率）、业务指标（成交率、成本、停机时间、客诉率、回款周期）。

这里有一句话要记住：只有从模型指标走到流程和业务指标，AI 项目才算真正进了企业的价值链。 停在第 93% 准确率上的项目，早晚会被问一句——所以呢，省了多少钱？

你可以读完 50 份报告、说得出 MES、ERP、PLM 各是什么，但回答不了「设备报警之后谁先处理、查什么、什么时候升级、怎么收口」——那你的知识还是撑不起交付。

真正的理解，是四张图。

第一张，行业价值图。 回答这个行业靠什么创造价值、成本压在哪、风险从哪来。至少要能填出六行：谁付钱、交付的核心结果是什么、按产品还是按项目收费、成本集中在人力还是获客还是履约、核心竞争力是价格还是效率还是合规、主要风险是质量还是交付还是政策。

第二张，业务流程图。 关键在这：不只画理想流程，还要画等待、返工、审批和异常升级。 每一个环节用五段式描述——触发条件、输入信息、执行动作、输出结果、验收标准。

举个样子：客户报障触发 → 输入设备型号、报警码和现象 → 客服判断并检索知识 → 输出建议或者升级工单 → 用响应时间和一次解决率验收。这样写下来，Agent、工作流和评测集才有的放。

第三张，业务本体图。 这是 FDE 最该补的一课。本体听着玄，其实就是一套业务语义契约：这家企业有哪些重要对象，它们之间怎么关联，又受什么规则约束。

还以设备售后为例，关键对象大概是这几组：客户、工厂、产线；设备、部件、型号、序列号；报警、故障、原因、解决方案；工单、维修人员、服务记录；手册、SOP、备件和质保合同。一台设备属于某个客户和产线，报警对应潜在故障，故障关联部件、方案和备件——这层关系决定了知识怎么切、元数据怎么标、工具怎么调。

第四张，评估模型。 把「回答得挺好」这种模糊说法，改写成能测的标准：有没有识别对设备型号和版本？引用的手册是不是真的适用这个型号？有没有漏掉安全停机条件？低置信度时会不会升级人工？

把评价标准前置，就是评测驱动开发。它能防住那件最常见的事——Demo 演示得很漂亮，一进真实场景就不可控。

顺带说一句证据分级。研究一个新行业，信息源要分四级：

规则只有一条：越接近具体方案，越只能用一级证据。

方法讲完了，讲怎么排。

第一周（第 1—7 天）：建地图。 第一周的目标不是扎进某个场景，是先把全局坐标系立起来，免得过早被某个部门或某套工具带偏。

第 1 天先定边界。别说「研究制造业」——太宽。要说「研究年营收 1 亿到 10 亿的工业设备制造商，重点看售后服务效率」，这才是能执行的范围。

第 2—3 天做桌面研究：价值链和商业模式、头部公司的产品和收入结构、政策和合规、常见系统和数据对象、招聘 JD 里高频出现的职责、公开案例里的效率与风险问题。

这里有个反直觉的做法：别一上来就让 AI「写一份完整行业报告」。更可靠的是分问题检索，要它输出证据表，把不知道的单独列出来。

第 4—5 天建行业词典和对象清单。记词典别只记定义——还要记这个词由谁用、出现在哪个流程、跟哪些对象关联、理解错了会有什么后果。

第 6—7 天画价值地图和初版流程图。

第一周结束，你手上应该有四样东西：一页行业价值地图、一张端到端业务流程图、一份行业词典、一份「已知—未知—假设」清单。

但这时候别急着宣布「我找到 AI 场景了」。桌面研究只给你进入访谈的资格，不给你答案。

第二周（第 8—14 天）：进现场，关键词是证伪。

第二周不是去验证你第一周的猜想对不对，是去找它的反例。

访谈不是请业务人员给你上课，也不是问「你们希望 AI 做什么」。后一个问题问出去，拿回来的一定是解决方案式的答案——「做个知识库吧」「做个智能客服吧」——而真正的问题被这句话盖住了。

正确的问法是围着最近一次真实事件追问：请你回忆最近一次最棘手的故障，当时发生了什么？第一条信息从哪来，谁先处理？你查了哪些系统、文档、聊天记录？哪一步等得最久？哪个判断最靠老师傅的经验？判断错了会损失什么？

真实事件比抽象观点可靠，因为它带着具体的动作、信息、判断和结果。

访谈的人至少覆盖四类：决策者（目标、预算、风险容忍度、成功标准）、部门负责人（流程瓶颈、团队指标、协作边界）、一线执行者（实际步骤、隐性经验、异常处理、工具切换）、IT 与数据（系统、接口、数据质量、权限、部署约束）。

道理很直接：只访老板，拿回的是口号；只访一线，容易陷进局部优化；只访 IT，项目会变成一张技术功能清单。

第二周结束，你应该完成当前流程图、角色地图、问题证据库、系统与数据清单，以及一份被现场修正过的业务本体草案。

第三周（第 15—21 天）：从问题池里筛场景。

不是所有痛点都该用 AI 解决。有些问题来自权责不清，有些来自系统缺失，有些只要改一张表单、加一条规则就好了。一个用流程调整就能解决的问题，硬塞进一个大模型，只会让成本和风险都变高。

筛场景看六个维度：业务价值、发生频率、AI 适配度、数据可得性、验证难度、组织可行性。

可以套一个简单评分：

场景优先级 = 业务价值 × 发生频率 × AI 适配度 × 数据可得性 × 组织意愿 ÷ 实施复杂度

这个公式不追求算得准。它的价值是逼着团队把判断依据摆到桌面上——每个分数都得有证据，缺证据就标「待验证」，不许凭感觉给高分。

第四周（第 22—30 天）：用 PoC 反过来验证你的行业理解。

PoC 不是产品的缩小版，是一个最小验证实验。它要回答四件事：企业现有的资料支不支持这个任务？模型能不能在边界内给出可靠结果？输出能不能真的进到一线的工作流里？这份业务价值值不值得继续投？

第 22—23 天定任务和测试集：从历史工单里挑 20 到 50 个有代表性的案例，覆盖高频问题、复杂问题、信息缺失问题和高风险问题，由业务专家给出期望答案、必要步骤、引用依据和升级条件。

第 24—26 天搭最小链路。以故障诊断助手为例，可能是：采集型号和报警码 → 按元数据过滤适用手册和历史工单 → 检索证据、生成分步排查建议 → 输出引用来源、风险提醒和置信度 → 信息不足或碰安全规则时转人工 → 过程和结果写回工单。

第 27—28 天做离线评测和红队测试，重点查这几件事：答案对不对、引用准不准、步骤全不全、有没有漏风险、该拒答的时候拒没拒、不同设备版本会不会串。

第 29 天让真实用户上手，别只问「好不好用」，要记任务完成时间、追问次数、人工接管的原因和错误类型。

第 30 天交决策包。30 天结束时该交的不是一份宏观行业报告，是一套能让企业做决策的材料：价值地图、关键流程和业务本体、场景机会池和评分依据、PoC 原型和演示路径、测试集和评测结果、数据与权限约束、下一步投入估算。

管理层真正关心的只有四件事：这个问题值不值得解决，方案可不可行，风险可不可控，下一步值不值得再投钱。

这份方法论还列了 FDE 在 30 天里最容易犯的七个错，我原样留着：

七个里头，第 ②、④、⑦ 三个最要命。

过早定方案，是最贵的一个。它不表现在哪里出错，它表现在一切都「很顺」——因为你只看得见支持你判断的东西。你以为自己在做研究，其实在给自己的结论收集弹药。

只研究正常流程，是最容易漏的一个。企业真正的时间成本不在标准流程里，在异常、等待、返工和升级里。而正常流程好问、好讲、好画图，异常流程得追着人问才问得出来。

用 AI 证明 AI，是最隐蔽的一个。让模型去查证模型给的事实，你会得到一份通顺、漂亮、错的报告。关键事实只有三个地方能确认：企业文档、业务数据、业务专家。

项目做完，别只留下一份 PPT。

该沉淀的是六类资产：行业地图、业务本体、访谈问题、场景卡、评测集、方案组件。下次进一个相邻行业，研究框架、建模方法和技术组件可以复用——但业务事实必须重新验证。

同样是「智能客服」，跨境电商关心的是多语言、物流和退款；工业设备关心的是型号、安全规则和专家升级。这两套东西不能互相套用。

30 天之后，你不一定还是行业专家。

但你该变成一个可靠的问题翻译器——在业务人员、管理层和技术团队之间建立共同语言，把一句模糊的「我们想做 AI」，翻译成可交付、可评估、可迭代的项目。

这才是 FDE 进入任何陌生行业时，真正的底层能力。

回到开头那句：FDE 最值钱的本事，是在不懂行的情况下也能进场。

这周先做一件事：

晚一周去问，你手上那份方案就多一周在替自己的结论找证据。