业界 FDE 案例：24 个真实落地，按六端标注

问题

零部件的材料配比、参数调整和设备处理方式直接决定产品质量，其中很多经验只在老师傅身上，操作手册写不全。老师傅生产任务重，又有人临近退休，企业担心经验随人流失。FDE 进场后要先弄清：新人到底卡在哪些知识上，这些知识藏在哪里，怎样在用到时找得到。

做法

1. 访谈之外，陪着员工把一天的工作走下来，看他们在哪里卡住、向谁求助、哪些问题反复出现。
2. 与主管一起梳理产线和新人培训流程，统计高频问题、易错知识和只有老师傅掌握的隐性经验，汇成知识地图。
3. 导入已有文档做解析和 RAG 检索，同时把老师傅的隐性经验提炼成可被检索的知识。
4. 把调研得到的高频问题用作测试集，以文档解析约 95%、召回片段准确率 80% 以上作为小范围测试的参考线，达标才算跑通。
5. 把知识能力接入企业原有的培训平台，做成课程打卡：新人看自己的进度，带教师傅随时查看，每节课用问答验收。
6. 上线后陪跑接近两个月，持续打磨页面、学习流程和问答效果；项目从立项到陪跑大约半年，实际投入大约四个月左右。

效果

• 老师傅脑中零散的经验被系统梳理出来，企业首次较完整地掌握哪些经验不能因退休而断档。 原书第 11 页
• 老师傅从重复答疑中抽身，精力转向跟进新人的学习进度和解决疑难问题。 原书第 11 页
• 培训进度变得可追踪：新人的学习进展和掌握程度在平台上清楚可见，不必全凭师傅观察。 原书第 11 页

给 FDE 的经验

• 从企业每天怎么干活出发，而不是从想做什么 AI 出发；业务 SOP 清楚，就能逐个环节判断哪里适合 AI。
• 先盘点客户已有的技术栈、平台和模型，能复用就复用，不必用最复杂的方案证明自己。
• 前期调研发现的问题要直接转成测试集和验收标准，检验的是能否解决真实业务问题，而不只是技术指标好不好看。
• 知识库能答题只说明技术通了；新人愿意学、师傅愿意看、结果能验收，才算进入业务，这往往要靠上线后的陪跑。

问题

群众在线提交的身份证、发票、合同、营业执照等材料基本是照片，质量参差，工作人员要逐张打开肉眼核对，再手工录入。单件业务审核下来大约 15 分钟，人眼疲劳，办件量也提不上去。审核产能还牵动驻点快递合作方的人力成本，关系到整个网办服务模式能否持续。

做法

1. 借运维驻场长期观察网办后台，把人工审核拆成看图、认材料种类、提取关键字段、判断合规、填数据和在系统间搬运几类动作。
2. 按动作配技术：看和读用机器视觉与 OCR，复杂合同的信息抽取逐步引入大模型，重复录入和跨系统流转交给 RPA。
3. 围绕大约 9 类图像材料，反复收集真实样本、标注、训练、上线观察，把异常样本补进正负样本，研发迭代前后约半年。
4. 把识别、审核、填单和后续流转串成一条链，用 RPA 联动原有的多个 Web 系统和上级统一业务系统；正常件自动完成，只有异常件转人工。
5. 前期自担部分售前成本，先在部分场景做出效果，借持续的运维交付积累信任，再走报告、立项、预算等正式流程。

效果

• 单件业务全流程审核从约 15 分钟缩短到三五分钟。 原书第 20 页
• 日均办件量由约七八百件增至 1100 件左右，过去被审核产能卡住的群众需求得到承接。 原书第 20 页
• 材料识别率在迭代中由 70% 多升到 98% 左右。 原书第 19 页
• 工作人员从看图录入中腾出时间，更多投入群众咨询、新增业务和需要人工判断的沟通。 原书第 21 页
• 驻点合作方人手没有增加甚至有所减少，办件量仍稳中略升，经营压力有所缓解。 原书第 21 页
• 项目通过验收后，客户继续交来新业务，双方还合作设立 AI 创新实验室并持续驻点研发。 原书第 21 页

给 FDE 的经验

• 先请客户列出经营中最重要的十个问题，再按是否高频、是否影响效率收入成本或服务、业务方有无意愿和预算，判断哪些值得用 AI。
• 小切口进场同样有价值：一个运维项目让 FDE 长期待在现场，看到会议室里看不到的需求。
• 让 AI 成为流程里的执行环节：识别之后数据能否自动流转、异常由谁处理，比单点识别更重要。
• 技术是基本功，沟通、协调、需求分析和对组织利益的理解更决定成败；涉及业务规则的取舍要交给业务负责人。

问题

一个商事诉讼案件常有数十类材料、上千页内容，律师光整理材料就可能花 3 到 5 个工作日，十几个当事人的案件仅理清人物关系就要两三天。把当事人的大白话提炼成法律要件全凭个人功底，新手与资深律师之间效率可差 3 到 5 倍。诉讼周期往往长达数月，甚至一年以上，律师每次回到案件都要重新找回之前的分析思路。

做法

1. 持续驻场观察律师从早到晚的真实工作，旁听案件讨论会，带回脱敏资料研究，并高频访谈合伙人，弄清哪些可交给 AI、哪些律师不放心。
2. 保留律师原来的做事方式，在案件流程中找出 AI 可以嵌入的环节，形成 7 个标准模块。
3. 大模型承担语言理解、材料摘要和初步推理；案件知识图谱、法条的结构化检索与判例匹配交给专业系统；最终判断和专业责任归律师。
4. 把优秀律师常用的思维框架，例如请求权基础分析和证据链构建规则，转成系统可执行的流程节点。
5. 根据现场反馈把入口从聊天框改为案件工作台：先上传材料建案，系统自动构建案件图谱，律师再用专业语言直接提需求。

效果

• 一个涉及 14 个被告的案件，过去把全部被告的请求权基础梳理完要 2 到 3 天，借助系统一个晚上完成。 原书第 30 页
• 一位律师距开庭只有 3 天、材料超过 100 万字，借助系统一天内完成整体梳理，包括人物、法律关系与案件脉络，并据此制定开庭策略。 原书第 30 页
• 与纯人工相比，材料整理效率提升约 70%。 原书第 30 页
• 律师从阅读、整理、检索等执行性工作中脱身，把精力放到客户沟通、判断案件方向和制定策略上。 原书第 31 页
• 优秀律师的方法被工程化沉淀，团队里更多律师能获得稳定的辅助，交付质量不再过度依赖个人经验。 原书第 31 页

给 FDE 的经验

• 从谁在用、为什么用、真实流程如何出发定义需求，而不是从模型能力出发，否则容易只做出一个法律问答工具。
• 进入现场，与真正懂业务的行业专家一起定义问题，专家的思维框架是系统设计的核心输入。
• 落地细节比模型能力更关键：用户愿不愿用、流程是否自然、成本能否接受、结果能否直接交付。
• 把每个项目的做法提炼成可以复用的方法和模块，避免每次都从头定制。

问题

一次选址或潜力用地研判，要叠加总体规划、道路、水务、市政等约 10 个部门的判断，既有业务数据，也有空间坐标关系，各部门还各有工具、术语和规则。领导一句研判需求，背后要翻资料、找数据、跑空间分析、反复讨论，才能形成报告。真正的难点是让业务规则、数据、空间关系、专业工具和不同部门的人协同起来。

做法

1. FDE 先把自己变成半个规划师：到各部门弄懂术语、指标含义、空间计算方式和工作流程。
2. 主动收敛范围：从全市缩到一个区，再缩到一个具体的小单元，只挑两条清晰的业务流程做验证，一期只治理试点部门真正需要的数据。
3. 夯实数据、知识、报告三块底座：关键数据来自真实数据和专业计算，规划规则通过检索增强找到依据，各部门报告模板归纳成通用结构。
4. 分工上，理解与分析交给模型，事实与计算交给专业 GIS 工具，拍板留给人；高频且规则明确的任务固化成工作流，开放的研判问题交给 Agent 调度工具。
5. 界面以地图为中心：筛选与工具在左，地图居中，Copilot 在右，分析结果直接画回地图。

效果

• 在已跑通的试点流程中，跨部门规划报告从 3 至 5 天缩短到大约 10 至 20 分钟，得到一份可继续推敲和交付的稿子。 原书第 41 页
• 单个部门过去约一个小时完成的分析和表格，如今约需 5 至 10 分钟。 原书第 41 页
• 一期约 10 个部门参与，大概有 20 至 30 名专员在使用。 原书第 41 页
• AI 有时会给出原流程之外的分析因子，例如建议参考停车场闸机数据、房屋空置率等信号判断区域经济活跃度，为规划师提供新视角。 原书第 41 页
• 部分部门开始自己把筛选和计算候选地块的流程封装成 Skill，学着搭建自己的 AI 工作流。 原书第 42 页

给 FDE 的经验

• 先进入业务，必要时把自己变成半个业内人，才分得清哪些交给模型、哪些交给工具、哪些留给人。
• 不要一上来做大，先选一个范围小、贴近真实、能闭环的场景跑通，再逐步扩大。
• 不迷信技术先进性，硬编码、工作流、Agent、传统算法按任务选；真正决定能否上线的是评估和兜底：数据错了谁发现，计算能否追溯，谁对决策负责。
• FDE 的角色会随项目变化：先当学习者，再参与重新定义问题和流程，等客户会自己做 Skill 时转为架构顾问。

问题

TAP 在商家和达人之间牵线，负责找达人，并推动达人接品、拿样、创作直到履约。业务做大后，运营要在 TikTok 上逐个寻找达人，从上万个商品里凭经验配货，每天翻表催进度，从合作到履约平均要一个月左右。数据散在 TikTok、Excel 和财务系统里，老板看不清一个达人从建联到产生 GMV 的全过程。

做法

1. 从老板、部门负责人到各小组负责人逐一访谈，画出达人进入、建联、选品匹配、拿样、创作、履约到数据复盘的链路，逐环节判断由谁来做。
2. 依据商品信息、达人标签和内容属性筛出匹配度高的达人名单交给 BD，发消息、谈合作仍由人完成。
3. 提取商品卖点并与达人内容属性匹配，AI 先筛，人再确认。
4. 结合达人特点、商品卖点和爆款内容参考，为达人生成几个可选的拍摄脚本，解决拿到样品不知道怎么拍的卡点。
5. 按履约状态自动找出需要跟进的达人，系统先提醒，仍未履约再转给运营；同时把建联、履约、商品和 GMV 数据放进统一的业务视图。

效果

• 试运行后，配合达人的平均履约时间从约一个月缩短到约 18 天。 原书第 52 页
• 运营不再把时间耗在找达人、配商品和翻任务上，精力转向与达人沟通、维护关系和处理复杂商务，高价值达人上尤其明显。 原书第 52 页
• 管理者能围绕达人、履约和 GMV 看到较完整的业务链路，团队从管表格转向管链路。 原书第 52 页
• 据客户访谈反馈，达人对 AI 生成拍摄脚本的接受度较高。 原书第 51 页

给 FDE 的经验

• 先问业务怎么跑、谁在跑、哪里最浪费时间、哪个指标最影响结果，再决定 AI 放在哪里；FDE 首先要会识别价值。
• AI 接手高频、重复、规则清楚的工作，高度依赖信任和判断、需要经营关系的工作留给人。
• 能用业务的话讲清技术，并对业务结果持续负责，一期问题解决后往往会自然出现二期需求。
• 深耕少数垂直场景，把经验、工作流和行业理解沉淀下来，同类项目做得越多，每次的成本越低。

问题

跨境公路运费按方计算，以约 110 方的货车为例，老师傅手工装满一车通常需 5 个小时，可装 95 至 98 方，而 98 方就是保本线，每多装 1 立方米可多收 100 美元运费。车厢实际可用空间常比提供的理论数据少 5% 至 8%，多车型、多规格货物一起安排时，人工经验很难找到最优解。更关键的是，算法算出的最优方案，现场工人未必能照着执行。

做法

1. 进入装车现场，把流程拆成测量车厢真实尺寸、整理货物、计算方案、多车调度、出装车指导、现场装车和反馈几步，规划和计算交给 AI，执行回到人。
2. 大模型负责理解业务人员的问题、解析任务、调用装箱算法并解释结果；三维空间计算交给 Python 算法，包括贪心放置、遗传算法等方法。
3. 放弃让工人在手机或电脑上看三维可视化，改为输出装车指导图，标出每件货的编号、朝向、所在截面和装车先后。
4. 用一辆内净约 108 方的真实车型和 11 种规格的电动车产品目录做模拟装载，完成原型验证。

效果

• 原型测试中，不需要老师傅参与，系统就能稳定装到约 99 方，越过 98 方保本线并接近车厢容积上限。 原书第 63 页
• 原本依赖老师傅凭经验花约 5 小时、结果起伏不定的装车规划，被压缩到分钟级，并成为可重复使用的标准方案。 原书第 63 页
• 按预计，装一车的时间可由约 5 小时降到约 2 小时，装车效率约提升 100%，相同工时内能装的车次接近翻倍。 原书第 63 页
• 多出的车次和方数由三方分享：工人按车次的收入增加，物流公司周转加快，货主每车多装的方数直接增收。 原书第 63 页

给 FDE 的经验

• 业务方说装不满时要继续拆：是空间数据不准、规划效率低，还是执行流程有问题。
• 让大模型做理解和调度，确定性计算交给专业算法，各用所长。
• 要算清经济账：运费按方算、98 方是保本线、超出部分每方多收 100 美元，这些机制决定了优化的价值落在哪里。
• 把增量分给相关各方，让工人、物流公司和货主都从多出来的车次和方数里受益，项目更容易推进。

问题

研发人员已经各自在用不同的 AI Coding 工具，个人效率提高了，但工具、方法和对 AI 能力边界的认识都不统一，谁也不愿换掉自己顺手的工具。管理层希望把散落在个人电脑里的效率变成团队能力，并重新设计研发分工和流程，却没有现成路径可循。

做法

1. 先按角色拆需求：老板关心转型能否发生，研发关心工具是否真能提效，产品经理关心流程怎么变，HR 关心每天的培训收获。
2. 交付载体是为期五天半的线下培训，但按完整的转型实践来设计，从为什么转型讲到工具如何进入流程、角色怎么变、方法怎么沉淀，边讲边观察边调整。
3. 不把前期调研当定论，靠现场实操、快速做原型和面对面交流来判断团队的实际水平。
4. 针对多文档协作，从 0 到 1 设计一套面向 AI Coding 的 Spec 文档，分步抛出、与客户确认、按反馈修改。
5. 前后做了三期：第一期摸清现场，第二期据此调整，后续业务人员和产品经理也加入，从研发培训扩展为组织转型。

效果

• 基金公司没有提供可以公开的完整 ROI 数据，但企业已开始统一 AI Coding 工具和研发协作方式，AI 开始成为团队共用研发流程的一部分。 原书第 74 页
• 过程中整理出的 Spec 文档与方法被保留下来，不再依赖某个人现场演示，可在企业内部复用。 原书第 74 页
• 在另一家制造业客户，三个小组采用这套方法和模板后，几天内的内部统计显示写代码时间节省约 1/3、写文档时间节省一半多，测试时间基本持平；FDE 提醒这只是短期反馈，不能当作长期 ROI 结论。 原书第 74 页

给 FDE 的经验

• 先弄清企业要解决的是个人效率、团队效率，还是研发流程重构，目标不同，方案完全不同。
• 少依赖问卷式调研，尽快做原型、跑真实流程；先拿七八十分跑起来，也胜过把方案打磨到 100 分才开始。
• 接受持续迭代：在变化很快的领域，没人能保证第一版就是最优。
• 用老板、研发、产品经理、HR 各自的语言沟通，把通用 AI 能力转化为团队真正用得上、跑得通、留得住的工作方式。

问题

小到手套、螺丝钉，大到卡车、机械臂都要录进同一套 ERP，几乎所有部门都抱怨它不好用。深挖后发现症结在数据不干净和搜索太弱：员工找不到其实已存在的物料就重新录入，重复数据越积越多，最终买错、买重，错买的物品在仓库一放几年，最后按规则处理掉。企业知道存在浪费，却从没算清它到底损失了多少。

做法

1. 前期用数月访谈 ERP 和与它打交道的上下游团队，并坐在业务人员身边看实际操作，把 ERP 不好用拆成大约 15 个可处理的功能点。
2. 沿业务链一路追问损失从哪来：搜索困难引发重复录入，进而污染数据，造成错误或重复采购，库存积压直至报废。
3. 召集各部门负责人和代表逐项确认功能价值和先后顺序，并让业务部门投票；FDE 内部再从七八个维度评估每个用例，包括能否取数、能否写回、AI 是否可行、技术难度和用户是否愿意采用。
4. 先清洗和标准化历史数据，去掉重复和不一致，再用语义检索把同一物料的不同叫法对上；买不买、买多少仍由业务人员决定。
5. 从几个星期甚至两周左右就能看到初步结果的场景起步，过程中发现问题定义不对或范围过大就退回调整。
6. 以历史数据建立基线，再用小规模实验逐步扩大，逐阶段检查重复数据、数据清洁度以及因脏数据导致的错买是否减少。

效果

• 业务人员能找到库里已有的物料，意在源头上少录重复数据，从而少买错、少买重。 原书第 83 页
• 过去不显性的采购浪费变成可以发现、干预和持续衡量的经营问题，节省的金额要经客户业务人员确认才算成立。 原书第 84 页

给 FDE 的经验

• 不要拿着 AI 找问题，先进现场找问题，再判断这个问题适合传统机器学习或生成式 AI，还是根本不该用 AI。
• 不停在用户的表面抱怨，一路追问到能和财务损失挂钩的根因。
• 优先选能快速证明价值的用例，并在项目开始就定义 ROI：怎么算、数据从哪来、最后由谁确认。
• 先沉淀可复用的方法，包括问题发现、根因分析、用例判断、ROI 定义和小规模实验，而不是急着做标准产品。

问题

员工报一张发票，财务要先判断费用性质、归哪个项目、记什么科目，还得去翻出差申请、审批意见和所属部门，这些信息分散在不同流程里。科目体系复杂，付款对象还涉及供应商和保证金。业务量越大，财务人员和本该专注科研的人员越多地被重复判断和填表占用。

做法

1. FDE 到现场陪业务人员一起办单，把老员工习以为常的判断逐条拆出来。
2. 员工在钉钉里告诉机器人要报销并发送发票；AI 识别发票，自动调取出差申请、审批意见、部门和项目信息，按财务规则给出科目与项目归属。
3. 安排执行、监督、风险识别几个 AI 角色互相把关；确定的单据直接流转，几个模型判断后仍不确定的进入风险监控，由人重点处理。
4. 判断完成后由 RPA 打开浏览器进入集团系统，自动建单、填写并提交。
5. 先挑一个痛点明显、实现可控、回报看得见的小场景做破冰，业务方尝到甜头后再扩展。

效果

• 原本要半个月甚至一个月的财务处理，用 AI 加 RPA 跑完整个流程大约只需一天、两天 原书第 92 页
• 项目共上线 10 个 AI 相关应用场景，逐步覆盖财务各个环节 原书第 92 页
• 科研人员的操作缩减为在钉钉里把发票交给机器人，信息关联、规则判断和系统录入都转到后台 原书第 92 页

给 FDE 的经验

• 先进业务再谈技术。跟着做一遍，能发现业务人员自己都说不全的隐性判断。
• 第一个项目要同时满足痛点真实、实现可控、回报快，它的作用是为后续拿到预算、资源和组织层面的支持铺路。
• 让业务方共同承担结果，条件允许时把 AI 改造与业务部门的考核目标挂钩。
• FDE 要从技术实现走向业务结果，并把交付经验沉淀为 SOP，再提炼成可复制的产品。

问题

门店收银系统和商场结算各有一套数据，资金由商场结算后再转给企业，因此每到结算周期都要把两边重新对一遍。店员或店长拿着纸质单据或扫描件人工比对，对不上就反复确认，一个周期要耗掉一两个人天。对得不彻底会漏收钱，还挤占了背着销售指标的门店人员做生意的时间。

做法

1. 客户同时提了对账、自动客服、竞品分析等需求，按哪个最快见到业务正反馈排序，先做价值最直接的对账。
2. 用 OCR 加视觉能力识别纸质和图片单据并自动比对，按结算周期定时运行。
3. AI 只接手规则清楚、重复量大的第一轮核对，先筛出已能确认的部分，剩下的差异交给人。
4. 从一开始就拆成两个阶段：第一阶段尽量轻，用现成的 Agent 客户端加本地电脑就能跑；扩到更多门店时，第二阶段再补后端数据和容错冗余。
5. 结果直接交到员工手里，不要求他们多录数据或另学一套系统。

效果

• 一个周期的对账从一两个人天缩短到几个小时，人只需处理真正要判断的差异 原书第 102 页
• 过去被放过的差异浮出水面：部分门店差异为一两个百分点，部分达两三个百分点，既有少收也有多收，需按净差异计算 原书第 102 页
• 员工把它看作有人先替自己做完了第一轮对账，接受度较高 原书第 100 页

给 FDE 的经验

• 第一单要选对：在价值是否显性、正反馈快慢、牵涉人数、流程清晰度、用户投入和技术成本之间权衡，没有样样完美的任务。
• 第一版只解决边界清楚的问题，先跑出正循环、建立信任，再逐步扩大。
• 在第一天就讲清技术路线、资源投入和扩展边界，别做到一半才提出要买服务器、加人或改流程。
• 把省下的人力转到更有价值的工作上，不要把 AI 落地做成裁员，否则会让员工站到对立面。

问题

多年积累的产品图、设计稿、参考图和模板散落在不同电脑和文件夹里，需要时常常找不到，其中大量是比文字更难整理的图片。老板希望一句话就能让 AI 找出某个客户用过的模板，还想让 AI 看国际站关键词、给网站发文章、把产品自动套进海报模板。更深的障碍是：资料之间的关系没人理清，现场缺少能让 AI 跑起来的环境，老板也还看不出 AI 和自己的生意有什么关系。

做法

1. 先在现场解决一个真问题：把客户给的、带一排不规则刻度的产品照片交给 AI 去查，当场弄清产品来源和刻度含义，赢得老板信任。
2. 修好线路杂乱的内网和各台电脑的环境，让 Agent 有稳定的内网访问和工具权限。
3. 把分布在多台电脑里的资料重新组织，标明每份文件属于哪个客户、产品和项目，让 AI 能理解和检索。
4. 数据留在企业：把框架、规范、原则和示例打成任务包，装进客户自有的 Codex，由它在客户电脑上继续开发；前期搭框架花了几十个小时，客户侧又跑了大约 40 个小时。
5. 测试日志由客户侧 AI 整理回传，据此修改规范再适配；同时逐步沉淀文档、Skill、Agent 和工作流。

效果

• 老板原以为要研究一两天的刻度尺问题，AI 大约 10 分钟就查清了产品来源和刻度代表的角度，随后又当场做出矢量图 原书第 115 页
• 最初只拿一个小问题试水，看到交付成果后，老板随即提出了十几到二十个新需求 原书第 116 页
• 项目仍处在第一阶段，交付尚未全部完成，暂时给不出效率提升的百分比 原书第 115 页
• 老板看待 AI 的方式从买一个工具，转向重新思考公司如何运作 原书第 117 页

给 FDE 的经验

• 从老板正在为之付出时间和成本的小问题切入，当场解决一个真问题，比讲 Agent 概念更能建立信任。
• 交付的重点是企业今后能自己处理新问题，而不是留下一个孤立的工具。
• 要接受大量工作并不是 AI：修网络、配 Windows 环境、理文件命名、开权限、催测试，这些决定了 AI 能否进入业务。
• 不要把自己当成 AI 外包，否则只能和更成熟的软件外包公司比价。

问题

SKU 多、上新快，每个新品都要配主图、详情素材，如今还要挂车视频，内容需求随 SKU 不断放大，企业长期养着一支不小的设计运营团队。员工各自开 AI 账号、自己写提示词，操作成本没少，效率也没有质变，出图质量全看个人水平。素材还散在设计师的个人电脑里，人一走就可能断档，投入成本做出的内容没有沉淀成公司资产。

做法

1. 先在现场识别老板、管理者和一线员工各自的关切，观察员工怎么协作、时间耗在哪里，先替他们解决写长提示词、去水印这类小麻烦。
2. 通过数据采集、流程梳理和访谈挖出真需求，用 AI 快速做 Demo 给客户看，按调研、Demo、使用、反馈的节奏迭代，意见记进固定文档。
3. 把生成能力接进商品、素材和原有生产流程，生成的图片和视频沉淀为公司级素材资产，商品纳入统一管理。
4. 把人物、服饰和场景的一致性写进验收标准，AI 先做初检，再由人工判断合不合品牌调性、能不能用。
5. 核心功能完成后进入 POC，推动内部员工真实使用，再按反馈迭代。

效果

• 项目处于 POC 测试和内部试用阶段，验收依据从项目组的自我感觉变为设计师是否真正用起来 原书第 127 页
• 素材的生成、管理和复用逐步走进统一流程，内容由个人手里的产出转为企业资产 原书第 127 页
• 验收项包括还原度、画质、视频能否商用以及一致性，产出质量不再取决于个别人的能力 原书第 127 页

给 FDE 的经验

• 先判断值不值得做、有没有延展性，再决定接不接；FDE 要对结果负责，按时交付功能只是其中一环。
• 很多需求在会议室问不出来，要到现场看员工的时间究竟花在哪里。
• 把 AI 嵌进流程而不是多发几个账号：想清楚哪步可以取消、哪步自动完成、哪些信息要沉淀、谁做最后判断。
• 每个项目都问一句能否复用到同行业，持续积累可复用的方法、组件和经验，让下次交付起点更高。

问题

老板只能靠定期汇报了解一线：哪些项目维保到位、哪些客户的消防隐患还没处理、影响回款的记录放在哪里，都看不清。维保人员大量时间耗在填纸质表、整理 Excel、打印归档和反复沟通上，有时一个表格就要占去半天。检查、维修、客户和设备信息分散在纸面、表格、个人微信和文件夹里，满足了存档要求，却查找困难、支撑不了管理决策。

做法

1. 不只听管理层，逐一和维保、人事、行政、财务人员沟通，现场看他们如何填检查表、如何交接资料、哪一步最让人头疼。
2. 发现企业已在使用监管部门要求的软件流程，且对外不开放接口，原计划的完整业务平台会让员工两边重复操作，于是改为在现有流程上做最轻的改造。
3. 第一阶段把纸质表和 Excel 里流转的数据搬到线上，先让企业有自己的数据底子。
4. 第二阶段只在有真实成本的环节引入 AI，例如月检表里每月重复的异常描述，由 AI 调用历史记录辅助生成。
5. 分工上，流程记录和数据沉淀交给系统，AI 处理非结构化信息和重复劳动，消防专业判断由人做；工具依托飞书等现有能力，小模块迭代。

效果

• 企业开始积累自己的数据资产，管理者能看到项目执行进度和风险所在，管理盲区减少 原书第 135 页
• 现场调研发现一套约 10 万元的外部业务系统与行业监管流程和现场做法脱节，上线后用不起来，这笔采购及时停了下来 原书第 135 页
• 项目仍在推进，尚未出现大规模指标变化；靠数据积累和标准化流程，原本依赖个人经验的能力开始转为组织能力 原书第 135 页

给 FDE 的经验

• 先找流程里真正花钱、费时的环节，再问要不要用 AI；简单的流程优化能解决的，不必上 AI。
• FDE 必须下一线：老板讲不清细节，员工在会议室里也未必说真话，本案正是靠现场观察及时纠正了方案方向。
• 从 Demo 到日常使用，要靠真实用户测试和快速调整，同时控制系统复杂度和成本。

问题

管理层只提出要在数字化基础上再往 AI 走一步，需求很模糊。深挖后发现：业务在增长，但编制有限、懂电商的人才也难招；合规要求严，法务、财务、纪检这类内控岗位的压力随业务扩张而加大，法务团队只有两个人却要面对大量合同。企业真正想要的，是把依赖个人经验的工作变成可复用的能力。

做法

1. 第一年以技术人员为主搭知识库、模型和 Agent 并接入现有系统，结果员工没用起来，团队随之调整做法。
2. 每个场景先看价值和可行性：技术上做不好的不硬做，价值太低的也不做。
3. 引入知识萃取师，请业务人员讲清怎么做、为什么这样做、有哪些例外、什么时候必须人工判断。
4. 坚持先梳理流程再做 Agent：加工和管理知识库，把依赖经验的岗位工作拆成明确步骤。
5. 为相关部门开 AI 通识课，项目从 IT 牵头的技术项目延伸为人事牵头的组织转型项目。
6. 把 Agent 定位为助手：重复工作交给 AI，确认、签字和担责仍由人完成。

效果

• 法务场景中，AI 参照过往合同和业务资料先筛出关键条款和风险点，法务不必再从头看到尾，最后由法务确认 原书第 143 页
• 客户原本至少还要再招一个法务，有了 AI 法务助手后这个编制省了下来，现有两个法务工作状态也较正常；按人数折算相当于一人年的综合成本 原书第 143 页
• 全员培训后，负责行政物品的员工自己用提示词，借数据中台的 MCP 能力做了补货 Agent：员工在 IM 里问库存，缺货时提醒行政补货，补完再通知领用人 原书第 144 页

给 FDE 的经验

• 先判断问题再选 AI，不为用 AI 而找场景；价值和可行性缺一不可。
• 谈 Agent 之前先把岗位流程讲清楚，业务人员习以为常的经验和判断必须拆出来交给 AI。
• 在中大型企业，AI 落地是一号位工程，人事、业务负责人都要参与，只交给 IT 很容易失败。
• 最终目标是让企业员工自己发现问题、拆流程、用 AI 解决；现阶段 FDE 团队也需要咨询、知识萃取、培训和开发的分工。

问题

业务高峰时一天要出两三百条短视频文案，能写好的运营靠的是个人经验，这种能力很难复制放大。餐饮商户之间差别很大，高端酒店、连锁店和小店的菜品、活动、老板风格和客群各不相同，按固定模板生成的内容容易雷同、机械。

做法

1. 先默认 AI 能做，用小 Demo 与客户原有成稿对比，做不好、不稳定的环节再交还给人。
2. 和老板及核心成员面谈后，到现场观察新客户怎么接、要提前准备什么、运营怎样判断一条文案好坏。
3. 把经验拆成输入字段：客户是谁、门店类型、主推菜品、活动、卖点和内容方向，并融入优秀文案人员的写法和参考案例。
4. 将业务参数、提示词、Skill 与校验和审计循环组合成一条生产线，产出兼顾拍摄节奏和声画配合、可直接使用的脚本框架。
5. 标准化的部分大多交给 AI，人负责最终审核；哪个节点 AI 做不好，就把它退回人工。
6. 定期提供不同版本，结合平台留存数据和团队反馈，调整提示词、流程顺序乃至模型选型。

效果

• AI 承接了相当一部分重复的生成和适配工作，运营不必每条从零写起 原书第 154 页
• 整体内容的平均质量上升，AI 先把多数内容拉到稳定的基础线，再交给人筛选和打磨 原书第 154 页
• 新客户进来时可提前规划门店、菜品和活动参数，由系统持续生成，原本扎堆在某一天的人力需求被提前消化 原书第 155 页

给 FDE 的经验

• 凡是能在电脑、手机上规模化完成的工作，都先交给 AI 试，再看业务效果决定它承担多少。
• 让 AI 稳定地负责流程中的某个节点，比员工各自拿 AI 写文案更能产生企业级价值。
• 把老板、运营负责人和优秀员工的隐性经验沉淀成流程、参数与评判规则，同类客户通过调参即可复用。
• AI 项目没有开发完成的一天，真正持续的投入在前期需求对齐和后期的测试、反馈与优化。

问题

要回答哪个基站坏了、为什么坏、影响多大，分析师得自己写 SQL、建模型、整理报告，一个新需求往往要一两个人甚至两三个人一起投入。几百行的 SQL 容易出错，曾出现看似正确实则取错数据的情况。仪表盘只能回答事先定义好的问题，实际分析却需要围绕数据不断追问。

做法

1. 先厘清客户给什么输入、要什么输出、中间到底发生了什么。
2. 把原有分析过程拆成细粒度组件，逐一确定方法和结构，再重新组装，使输出符合客户要求的结构与质量标准。
3. 按可反复运行的业务系统而非聊天助手来设计，每一步都检查数据对不对、过程可不可靠、格式合不合规、重复执行结果是否一致。
4. 分析师可能有几十甚至上百个，把 Agent 部署到云端统一控制和监督，让多用户积累的数据和经验经记忆、语义层回流到系统。
5. 不改用户习惯，支持网页、Teams、Slack 等方式调用，本案保留聊天式使用。

效果

• 过去一个新分析问题要一个人甚至两三个人按天投入，现在不少分析能在分钟到小时级别完成，再由人做最后的质量确认 原书第 164 页
• 分析师不必从零做起，可以接着 Agent 的初步结果往下判断 原书第 164 页
• 人工分析中一些常见错误减少，交互方式也从看预设仪表盘变成围绕数据持续追问 原书第 165 页

给 FDE 的经验

• 先弄清客户的真实痛点，以及哪些该自动化、哪些不该自动化。
• 同时懂 AI、数据、云和基本的软件工程，按问题挑工具，而不是因为熟悉就硬套某个工具。
• 能跑不等于能落地：生产就绪意味着稳定、可重复、成本可控、能进入原有工作流，并支持对几十、上百个用户集中管理、监督和迭代。
• 不必迷信 FDE 这个名称，关键是真正用过这些工具，并在真实场景里解决过问题。

问题

非标订单的报价不是简单算个价：先要读懂客户发来的 PDF、CAD 等图纸，再拆需求、选材料、定工艺、核成本。这条链路几乎全压在少数懂工艺的技术骨干身上，询价一多就排队；报高了会丢单，报低了会吃掉利润，报得慢订单也会流失。

做法

1. 进场先去车间跟一张订单从图纸走到交付，翻阅一批历史报价单，并分别和业务员、老师傅聊清谁看图、谁拆需求、谁定价，以及彼此怎么交接。
2. 用多模态能力从 PDF、CAD 等格式不一的图纸中抽取材料、尺寸和结构要求，并整理成结构化数据，供后面的环节使用。
3. 模型不直接给价：结构化后的需求进入企业内部的物料库、供应商资源和报价规则做匹配，由垂类 Agent 把各环节串起来。早期试过端到端直接出价，数字常与真实成本对不上，才改成这样。
4. 建立人工校准和回填机制：业务员修正 AI 结果，修正内容写回数据和向量库，让老师傅的经验一点点沉淀为企业自己的数据。
5. 边做边改，用 Demo 和阶段性成果帮客户澄清需求；系统能跑后先请关键人员用真实订单试用，随后业务小组试运行 1 到 2 个月，最后才部署、培训并推广到整个部门。

效果

• 上线后经过前两个月的磨合和微调，相关工作量减少 50% 以上。 原书第 176 页
• 这项工作原来要 3 到 5 个人参与，系统接手部分重复劳动后，实际要投入的人手明显变少。 原书第 176 页
• 企业没有借此裁人，而是让业务人员把省下的时间用于联系客户、谈项目和接单，并相应调整了岗位 KPI 和职责。 原书第 177 页

给 FDE 的经验

• 选场景先看它是否占用了企业最稀缺的人。知识密集、有可用的历史数据、存在明确瓶颈，这三个条件要同时满足，普通自动化能解决的就不必上 AI。
• 不要只盯一个 AI 功能。图纸识别做得再好，后面的拆需求、匹配和报价接不上，业务价值依然有限。
• 数据清洗、规则还原和经验沉淀本身就是项目工作，不能当作交给客户的前置准备。
• AI 改变流程后必然牵动岗位、KPI 和组织，这些需要一把手出面推动，乙方无法独自完成。

问题

企业想推进 AI 转型，但销售这条线的数据和系统还没准备好。客户关系握在销售个人手里，业绩和提成靠 Excel 手工统计，管理层看到的大盘常常滞后 1 个月以上；培训一个新人要接近两个月，老销售还常被拉去参与招聘面试。

做法

1. 逐个部门访谈并到现场看流程、系统和数据，用 4 维模型挑出最值得先做的试点场景，先从离收入最近、痛点最集中的销售切入。
2. 不把所有问题都当 AI 问题：提成计算本质是信息化问题，先协助企业选型采购 CRM，把客户、订单和绩效数据收进系统，再结合数仓分阶段汇总。
3. 在 CRM 和数仓之上用 BI 搭出销售大盘，再让 AI 结合销售日报周报和拜访记录，分析各大区销售涨跌背后的原因。
4. 把新人培训做成 AI 陪练加电子化考试的闭环，并按新人通过率持续调整；招聘端用 AI 筛简历、打分，自动化一面也在试点。
5. 第一阶段结束后，FDE 建议董事长扩编内部团队，并参与招聘和搭建团队框架，避免企业长期依赖外部。

效果

• 新人培训周期从接近两个月缩短到大约 3 周。 原书第 185 页
• 据测算，老销售每月约有 3-4 个人天花在筛简历和面试上；引入 AI 筛选和打分后这部分时间基本省下，每人由此可多拜访 1-2 个客户。 原书第 185 页
• 管理层不只看到结果数字，也能更快弄清各大区走势和涨跌原因，经营调整更及时。 原书第 185 页
• 企业后续计划自持算力和行业小模型，FDE 协助企业完成 20 个岗位的招聘和组队。 原书第 187 页

给 FDE 的经验

• 先看清企业的数字化走到了哪一步。信息化欠账还没补完时，做 AI 的团队也不该跳过这些基础工作。
• 筛场景时综合看痛的程度、发生频率、牵涉人数、对收入或成本的影响，以及 AI 是否已经擅长这件事。
• 业绩计算交给 CRM 和 BI，AI 用在趋势归因、陪练和简历筛选这些它擅长的地方；知道哪里不该用 AI 同样是能力。
• 工具变了，绩效、职责和产出要求也要跟着变，否则系统做出来没人愿意用；大企业的转型还要帮客户建立自己的 AI 团队。

问题

消费品从需求、配方研发到包装、合规、中试和渠道上线，链条长、角色多，关键判断和经验多半只在个人脑子里。已有 SaaS 只留下结果，留不住“为什么这样做”的上下文。SKU 增多后包装稿在审核环节越积越多，而包装审核其实混着错别字、法规、渠道规范和产品表达至少四种视角的检查。

做法

1. 不带现成方案进场：在业务群里放一个 Agent，静默收集两三周上下文，再让它总结问题和机会，最终由它定位到包装审核。
2. 借用 HRBP 写岗位说明书的思路，请一线审核人员自己拆解输入、输出、可直接执行的规则和需要判断的环节，由懂业务的人来定义 AI 怎么干活。
3. 把审核按确定程度分层：错别字、法规条款、能量计算这类有确定答案的问题由 AI 先查；渠道反馈逐次记录、沉淀成标准后由 AI 预审；包装是否讲清产品留给人判断。
4. 工程上把包装图拆成不同视觉模块，分别挑选 OCR 和 VLM 方案；热量表与 NRV 计算改由确定性代码完成，模型只给解读和补录提示；每条审核结论标注置信度并能回查原始数据。
5. 把审核接进包装开发全流程，设计师提交稿件时自动先跑一轮预检；另建包装管理系统沉淀过往上线样本、驳回记录和整改闭环，作为评估新稿的上下文，提前提示容易踩的坑。

效果

• 合规审核人员少花时间在低级错误和返工上，精力集中到需要专业判断的地方；产品经理有更多余力判断包装是否讲清了产品。 原书第 196 页
• 蛋白质 2.9g、每份 40g、NRV5% 是否正确这类数值核对，变成可以复现验证的确定性检查。 原书第 194 页
• 每次决策、渠道反馈和审核经验开始被记录沉淀，个人经验有了转为组织经验的途径。 原书第 196 页
• 业务人员开始自己动手搭工作流：客户内部组织了一场黑客松，做出电商视频编导、考勤自动清洗等工具。 原书第 196 页

给 FDE 的经验

• 人的问题排在技术问题前面。FDE 既要像 HRBP 一样弄清组织里谁在做什么、哪些经验该沉淀、哪些事交给 AI，也要像架构师一样把知识库、Skill 和 Agent 接进真实流程。
• 从公司战略和价值创造（面）到价值链（线）再到每个岗位的输入输出（点）逐层梳理，AI 该放在哪里会自然清楚。
• 模型、架构、知识库和 Skill 这些底层能力可以复用，但每家企业的人、流程和决策方式都要重新理解。

问题

订单、生产、采购、库存、发货和回款数据都在 ERP 里，却没有按老板的经营逻辑串起来。老板想知道订单走到哪一步、采购有没有多订、要付的钱对应哪些订单，只能挨个问人。ERP 的标准逻辑也表达不了“货已到但数量不足”这类真实情况。

做法

1. 不问老板想要什么 AI 功能，改问他日常最怕出什么事、哪些环节放心不下、哪类异常需要马上知道，把诉求收敛为订单流转透明、数据能对上、异常能被发现。
2. 保留原有 ERP 继续承担业务功能，只读同步需要的数据，再按老板关心的经营环节重新组织。
3. 让 AI 接手过去由人来做的数据比对和核验，例如把某笔应付给供应商的款项对应到供应商订单、客户订单和库存签收。
4. 在关键节点设判断标准，如单价是否偏离、库存是否异常、应付款能否与业务单据对应；出现异常就用飞书卡片通知到相关的人，正常时系统自行流转。

效果

• ERP 里有数却看不清的情况开始被还原：供应商应发 5000 个扳手、实发 4980 个时，原 ERP 可能无法入库，现在能向老板呈现库存实际已增加 4980 个。 原书第 205 页
• 财务应付款变得可追溯：每笔应付款能追到对应的客户订单和上游采购，也能看出这笔钱为何产生。 原书第 205 页
• 在老板最初提的目标里，让企业尽量自动运转、出现异常及时通知，这些已具备基础功能；减少重复订货等效果，以及利润、成本等指标的量化提升，还要再跑一段时间才能看出来。 原书第 205 页

给 FDE 的经验

• 转型的起点应是老板最在意的经营问题，不要为了用 AI 而用 AI。访谈者举过一个反例：一家金融机构花钱本地部署了 AI 做图系统，图却用不上，业务部门最后还是回去找设计师。
• 最好由老板或对业务指标负责的人牵头，并给业务部门配足资源和权限；IT 要参与，但不能变成 IT 为完成转型任务而推动。
• 刚上线的项目不要包装成已经带来巨大收益，已经解决了什么、哪些效果还待验证，都要如实说明。
• 不急于做完美的标准化产品：先在一个真实场景里把问题解决，积累几个项目后再提炼共性，判断哪些值得标准化。

问题

设计人员要依据建筑 CAD 图纸，对照消防规范逐个空间布置喷淋、消火栓、灭火器和管线。大量时间花在相似空间的重复布置和逐条核对规范上，核对往往比画图还费时；建筑方案一调整，施工图就得人工逐处跟着改。

做法

1. 先观察设计人员在 CAD 里怎样逐项对照规范、怎样为调一个参数反复返工，找出最耗时的环节。
2. 自研专用模型解析 CAD 图纸，识别墙体、门窗、空间标注和面积等信息，还原建筑空间结构。
3. 把消防规范条文转成规则引擎：按空间类型确定危险等级，再由危险等级决定喷头 K 值、间距和保护面积，生成时只按规则走、不自由发挥。
4. 确立 AI 生成、人来决策的分工：常规空间用默认参数一键生成，特殊空间由设计人员调整危险等级、K 值、喷头间距和布置方式，AI 产出只作为可用初稿。
5. 关键节点设人工确认，最终方案须经设计人员审核；同时把好输入关，确保建筑图纸信息准确。

效果

• 据项目方反馈，大型项目的消防施工图过去要画上数天，现在约 30 分钟就能出初稿，再由设计人员修改确认。 原书第 214 页
• 设计人员原来约 70% 的工作内容是画图和查规范这类执行工作，30% 是专业判断；如今执行部分交给系统，角色转为审核者和决策者。 原书第 214 页
• 投标阶段能在短时间内拿出更完整的消防方案，不必再因时间紧只交粗略方案。 原书第 215 页
• 规范要求和设计经验被做进系统，团队整体出图能力更稳定可控。 原书第 216 页

给 FDE 的经验

• 需求要到现场看出来，而不是凭想象；只有看清设计人员的时间耗在哪里，才知道哪些环节值得用 AI。
• 划清 AI 的角色边界：规则化的绘制和检查交给 AI，最终专业判断和责任留给设计人员。
• 落地细节常常比模型能力更关键。用户愿不愿意用、流程要改多少、图纸格式合不合设计院的交付规范，任何一项没处理好，内容再准确也用不上。

问题

服装的每个颜色、尺码都是独立 SKU，团队每季度要上新 500～800 个，全年约 2500～3000 个。库存在多平台聚合 SaaS 里，新品和业务信息在飞书里，两边不通；物流靠拍照后人工看图回填，补货靠人从系统取数进 Excel 计算，库存见底的 SKU 广告还在继续花钱。

做法

1. 不把“打通两个系统”直接当成接口项目，花了大约一周、三四轮沟通，请客户录屏演示实际操作，看清从订单、库存到物流、补货、供应商下单和广告的整条链路。
2. 先打通数据：聚合 SaaS 的接口开放度低，Key 也满足不了多个团队共享，于是加一层开源云数据库做中转，再同步到飞书，让团队在熟悉的环境里看实时库存。
3. 让 Agent 识别物流照片并回填数据，人只做最后核对。
4. Agent 按客户原有补货公式计算，筛出需要补货的 SKU 并给出周期和数量，人工确认后直接生成 PDF 采购单发给供应商。
5. 把库存和广告联动：库存跌到一定水平时，由 Agent 判断是否下调广告额度或暂停投放，避免缺货时广告费白白消耗。

效果

• 物流照片和数据处理原来一个人每天要 4～5 个小时，现在 AI 先识别回填、人做最后核对，整体压缩到 1 小时以内。 原书第 224 页
• 补货原本要从多个系统取数、核对、填表计算再整理成订单，至少 2～3 个小时；现在由 Agent 算出结果，工作人员核验确认后即可生成订单。 原书第 224 页
• 补货、库存和广告不再各自决策，库存变化开始直接影响广告投放。 原书第 224 页

给 FDE 的经验

• 客户通常知道自己要什么结果，只是说不出技术方案；FDE 要把结果拆到具体业务链路，再决定技术插在哪一段。
• 关键节点留给人：识图结果有人核，补货单有人批，广告是否调整也结合库存由人判断，不以全自动为目标。
• 长期深耕一个行业，表格怎么设计、哪些环节常出错、Agent 该放在哪等经验都能复用，交付成本才降得下来。
• 效果归因也是交付的一部分。本案交付后客户移除了团队权限，后续的营收、广告花费和利润数据没能完整拿到；重来的话应在上线前记录人工耗时作为基线，上线后持续跟踪。

问题

老板既是唯一的销售也是唯一的调度，精力只够照顾大客户。按访谈中的说法，营收 3000 万时，其中 2500 万可能出自几个大客户，其余 500 万来自大量小客户；行业下行时，这部分长尾收入随时可能流失。小订单报价要综合车型、操作员、油费、距离、运输成本和作业类型，很难靠固定规则算清。

做法

1. 先梳理获客、询价、报价到调度的整条链路，把抖音、快手、小程序等获客入口一起考虑；入口要轻，用小程序接单，不指望客户为了问个价去装 App。
2. 订单分层：大客户价格不透明、单值高，继续由老板判断；相对标准化的小订单由系统收集需求，按车型、操作员、油费、距离、作业类型算出报价区间。
3. AI 在区间内与客户沟通，判断能否快速成交；客户不接受或订单较复杂时，直接放弃或转人工。
4. 方案不纠结是否“纯 AI”，把模型和 Prompt、传统业务规则以及运筹方法混合使用。
5. 适配原有使用习惯：前端尽量简单，必要时加入语音或微信 Bot，不要求一线员工换工具、改习惯。

效果

• 项目还早，相关业务才做了一个多月；客户已明显感到效率提升，并愿意在此基础上继续推进。 原书第 233 页
• 小订单的需求收集、报价区间测算和前期沟通先交给系统，只有值得老板出面的客户才转给他。 原书第 233 页
• 过去顾不上的长尾订单开始被承接，带来新增收入；双方讨论了按年收取系统维护费加增收分成的合作方式，但增收难以量化，商业模式仍在探索。 原书第 233 页

给 FDE 的经验

• 先找业务问题而不是找 AI 场景，传统数字化能解决的就用传统数字化。
• 缺少品牌背书和咨询溢价的小团队，先挑一个小而具体、能很快见效的问题，用结果换取信任，再谈更大的路线图。
• 像销售 Agent、非结构化检索、报价系统这类底层工程框架可以沉淀复用，业务方案则保留一定定制，标准化不等于跨行业原样照搬。
• AI 带来的变化远不止减少人手，还会改变员工怎么干活、企业怎么管理、能接多大的业务；FDE 必须懂客户的生意才能看到这些。

问题

总部只看得到卖给经销商的货（Sell In），看不到消费者最终买走多少（Sell Through）。经销商通过 Excel 和邮件回报销售，中间还要语言转换和人工整理，数据往往滞后几周，各方对“销售情况”的理解也不一致。市场费用审核主要靠人工，材料一多就难以细看。

做法

1. FDE 贴身观察总部销售运营团队日常收数、对数和开会的过程，并远程摸清经销商那边怎么填报数据；在此基础上厘清哪些数据能自动拿到、哪些必须人工确认，从源头统一口径。
2. 分工：AI 负责从各类 PDF、图片和表格里抽取信息并清洗、转换格式、标出异常；专业系统管存储、权限和流程；人做最终判断，处理复杂决策和异常。
3. 放弃另建海外数据平台的设想，在总部已有的管理系统上叠加 AI 能力；经销商改按统一字段报数，AI 先把能识别的字段填好，经销商只做确认和补充。
4. 第一版范围收得很窄：只覆盖中国市场的一条产品线，只回答这条线的投入是否划算；端到端跑通后再接入越南。
5. 业务人员可以用大白话提问，但答案要落到原始数据行上，数字可点开查看出处；追溯不到来源的问题不让模型回答。

效果

• 过去市场费用主要靠人工审核，只能查出不到 10% 的问题；AI 辅助后能发现约 30%，最终仍由人工确认。原文说明这些数字做过脱敏，量级准确。 原书第 242 页
• 周会不再花前一个小时核对数字，开会直接讨论要不要调整预算。 原书第 243 页
• 提问方式从索要整份报告，变成直接追问某个 SKU 为何下滑、是价格、铺货还是渠道的问题，说明业务人员开始信任这套数据。 原书第 243 页
• 判断数据异常、费用是否合理的经验从个人沉淀到企业，今后进入更多国家、对接更多经销商时，数据治理的做法可以复制过去。 原书第 243 页

给 FDE 的经验

• 不要从技术出发，先找业务最痛、最耗时、最依赖个人经验的环节；客户最终是为解决问题的价值付费。
• 按 FDE 团队自己的说法，技术只占约 20% 的难度，真正的难点在数据、信任和流程。
• 交付按诊断、数据审计、窄 MVP、嵌入、扩展的顺序推进，理解业务放在技术选型之前，赢得信任后再扩大范围。
• 衡量项目成败，看客户做决策的方式有没有改变，演示效果只是次要的。