FDE岗位实务指南 · 第26篇行业会议的茶歇上你大概听过这样的开场某大行用 AI 把会议纪要效率提了十倍我们也该上了。回去搜到报道标题更漂亮数字更具体方案图配得整整齐齐。看的时候热血看完之后呢大多数人的下一步是收藏链接然后没有然后了。不是不勤奋是没人教过怎样读一个成功案例。收藏夹里那些链接承担的心理功能多半是我关注了这件事的安心感——收藏的那一刻焦虑已经缓解阅读的动力随之消失。而真正从案例里学到方法的人用的动作恰恰相反不是收藏是拆解——把一篇三千字的故事拆成一页纸的字段。拆解费脑子但它把知道了变成会了。收藏不费脑子但它只制造知道的幻觉。案例阅读也是一种岗位能力把故事里的任务、断点、动作和验证拆出来认出哪些是来源实际支持的、哪些是宣传的修辞再判断哪些方法在自己的条件下还能成立。这一篇用一个真实的对照来练这件事——两个公开案例一个来自企业一手发布一个来自厂商案例页正好覆盖你要在真实世界里遇到的两类材料。一、成功故事里哪些信息值得追问先说一个反直觉的判断成功案例的信息量不在它说了什么在它没说什么。一篇典型的成功故事包含四层信息。最外层是结果数字——效率提升十倍节省两百万第二层是方案描述——用了什么技术、连了什么系统第三层是过程信息——任务原来谁做、卡在哪、改完谁确认最内层是条件信息——组织怎么分工、权限怎么设计、投入了多少人和钱。四层的可信度和可用性正好相反结果数字最抢眼但最难用条件信息最不起眼但决定方法能不能迁移。因为结果数字属于那个特定场景的分母第 20 篇的老问题条件信息才是你复刻时的输入清单。读案例的第一课就是别被外层的亮度晃花直奔内层去问这件事成立需要哪些前置条件报道说了几条没说的有几条追问的具体动作可以列成三问谁在说企业自己、厂商、还是第三方说给谁听投资人、客户、还是公众凭什么这么说数据从哪来、口径是什么、谁核过三问过完一篇故事就从一个整体判断降维成一张可以逐条检查的清单——这正是它作为学习材料应有的形态。举个三问的实战用法某篇报道说某零售集团 AI 客服解决率提升三倍。谁在说——转载自媒体原始出处找不到说给谁听——文末挂着解决方案咨询入口凭什么这么说——解决率没定义三倍的基线没说。三问下来这句话的可引用档位就已经清楚作者推断层的转述机制可查证前不能进你的事实卡。二、先分清公开事实与宣传表达进入两个案例之前先把分类的尺子立起来。公开材料里的话至少分三档第一档企业一手发布。企业以自己的名义发布的事实性陈述可信度最高但要注意它的边界——发布者陈述的是我们认为发生了什么不等于独立审计。一手发布还有一个结构性偏置企业只发布成功。你永远不会看到我们的 Debrief 试点失败了的新闻稿所以任何一手发布都天然来自幸存者。这不妨碍你引用它的事实但要在心里给这类项目都像这样的推论留一道闸——你能看到的样本是被发布这个动作筛选过的。第二档厂商案例。厂商替客户讲的故事服务厂商的商业目标页面末尾挂着咨询销售的入口就是证据机制描述通常可靠收益数字要打问号。第三档作者推断。分析文章、行业总结里的解读可参考但引用时要归到作者名下不能混进前两档。这个分档不是要你怀疑一切是要你在引用每一句话时知道它的出处档位。下面用两个真实案例过一遍这套动作。第一个案例摩根士丹利 2024 年 6 月发布的 AI Morgan Stanley Debrief。这是企业一手发布内容说在客户同意后Debrief 为财务顾问生成会议记录和行动项会后总结要点生成一封邮件由顾问编辑并自行决定是否发送并把记录保存进 Salesforce。同一发布里还有一个容易被误引的数字98% 的财务顾问团队采用了 AI 工具——注意这个 98% 说的是此前发布的另一款产品 Assistant内部知识问答工具不是 Debrief 本身。发布里那位顾问说它每次会节省约半小时这是一位使用者的引述不是统计口径。再补一层OpenAI 后来发布了对这个合作的案例页这就降到第二档——厂商案例里面描述了评估机制部署前测试每个用例、由顾问和提示工程师对输出做准确性评分、每日用回归样本测试、为 Debrief 建了覆盖多种会议类型的评估数据集。这些机制描述有参考价值页面里的效果数字比如文档访问率从 20% 到 80%是厂商口径的引用没有底表可查。第二个案例致欧家居的 AI 质检发布方是飞书厂商案例第二档。页面描述的机制是RPA 自动采集工厂上传的包装箱标图片AI 识别文字与内部数据比对结果进看板质检从人工抽检转为系统全检。效果数字每月处理 400 万张图片、月 token 消耗约 9900 元、全年投入不足 10 万元、节省约 200 万成本、6000 工时、从 1% 抽检到 100% 全检。数字很具体但页面没有发布日期没有计算底表——200 万怎么算出来的省的人力成本口径避免的退货损失口径无法核验。两个案例摆在一起分档的用处立刻显形摩根士丹利那边你能分清机制是企业说的、98% 是另一个产品的、半小时是个人引述致欧这边你能说清机制可参考、数字是厂商口径。这个区分能力本身就是案例阅读的第一项产出。三、按任务、数据、动作与采用拆解分档之后进入正拆。拿摩根士丹利 Debrief 这个案例按四条轴拆开看。任务轴解决的真实任务是顾问在客户会议中做记录、会后整理并发送跟进邮件。注意这个任务的属性——高频、发生在顾问本来就要花时间的事上、错误后果温和邮件有顾问编辑把关。这三条属性决定了它适合 AI 介入高频给收益、错误温和给容错空间。你的任务如果低频、或者一次错误就不可承受直接照搬的理由已经没了。把任务属性三问频率、本来耗时、错误后果养成读案例的第一反应还有个附带收益它能帮你快速识别假相似。两个案例都叫会议纪要一个是顾问见客户的外部会议合规敏感、客户关系敏感一个是内部周会既无合规约束也无外部后果——名字相同属性全反方法不可互搬。判断相似永远用属性不用名字。数据与规则轴Debrief 的输入是会议音频输出是记录和摘要——中间不需要复杂的业务规则判断难的在语音识别质量和摘要的忠实度。他们的应对从厂商案例页可知是为这个用例专门建评估数据集用专家评分和回归测试守住质量。这个用例级评估数据集的做法比他们用了大模型这个事实重要一百倍——前者是方法后者只是采购。动作轴Debrief 的动作边界设计得很清楚——生成邮件草稿但发送权在顾问写 Salesforce 记录但在客户同意之后。两个设计分别对应第 17 篇的权限原则人保留对外的最终决定权和合规前提客户同意是使用录音的边界。拆到这里你发现这个案例最值得学的不是 AI 能力是它的动作边界设计——把 AI 放在起草的位置把发送留在人的手里。采用轴Debrief 发布时没有公布自己的采用率那 98% 是前一个产品的每天在用到什么程度、哪些团队在用、顾问修改草稿的比例是多少——这些都没说。没说不是罪过企业没有义务公开全部但对读者这就是未知——不能把已发布脑补成全员在用也不能因为没数字就断定是摆设。未知就记未知。四条轴拆完一个案例从成功故事变成结构化事实卡任务属性清楚、方法要点清楚用例级评估、动作分级、人工把关、未知项清楚采用深度、顾问修改率、成本。这张卡才是可以带走的形态。四、比较两个案例并找迁移条件单个案例拆完再加一个维度比较。比较不是为了排名是为了让哪些方法是通用的、哪些是场景特产显形。拿致欧的质检对比 Debrief。任务属性完全不同质检是高频、但错误后果严重页面自己讲了背景——一批箱标错误导致整批货被拒收损失数十万。于是动作设计也完全不同Debrief 是 AI 起草人发送致欧是 AI 全检但结果进看板由质检员处置——出错成本高的场景AI 站位从起草退到预警。但两个案例在方法层有两处惊人的相同。其一都把 AI 放在既有人工流程的延长线上而不是替代位Debrief 的输出进 Salesforce 和邮件这两个顾问本来就在用的入口致欧的输出进质检员本来就在看的看板——第 21 篇的入口原则大公司也一样遵守。其二都有人工环节嵌在关键位置顾问编辑邮件、质检员处置异常机器不单独对外负责。把两个不同行业、不同发布档位的案例拆到方法层发现同一套骨架——这才是可迁移方法的定义跨情境仍然成立的结构。两处相同之外两处相异同样值钱AI 的站位随错误后果移动低后果场景起草、高后果场景预警人工环节的位置随对外与否移动对外动作人把关、内部处置看板聚合。这两个随什么移动的规律比任何单点做法都更接近方法的本质——它告诉你的不是该怎么做而是在什么条件下往哪边调。迁移它的时候条件要重新核对你的任务频率和错误后果是什么你的数据质量和致欧的扫描件可比吗你的复核人力配得起全检进看板的处置量吗任何一条不成立方法就要变形而不是硬搬。还有一类信息两个案例都没给、但你做决策必需成本。致欧给了 token 费月 9900 元但没给实施投入和人力改造成本摩根士丹利完全没提成本。用第 20 篇的话说两家都只汇报了价值叙事里最亮的那一格。读到这一层你对成功案例这个文体本身的认知也齐了它天然只讲成功、只讲亮格、天然省略条件——不是作者不诚实是文体的天性。读者要做的不是抱怨是把缺的那几栏自己标出来。五、形成自己的方法卡和待查清单读完之后落一张案例阅读卡五个字段来源事实这个案例里来源实际支持的机制和行为注明发布档位方法解释我从中提炼出的做法标明是我的解读未知来源没说、决策又需要的——采用深度、成本、组织分工可迁移原则跨情境仍成立的结构比如AI 起草人发送输出进既有入口需重验条件把原则搬回自己场景时哪些前提要重新核对。这张卡和第 25 篇的资产接收单是同一种思路把一次阅读变成有边界、有出处、可复用的资产而不是一段聊天素材。攒上十几张你会发现不同案例拆出的可迁移原则开始互相印证——那就是你自己的方法库在成形。到那一步还有最后一道加工把互相印证的原则回放到自己的项目里验一遍。输出进既有入口在两个案例里成立在你上个项目里成立吗成立原则升级为你的经验不成立差异出在哪——这一问的答案往往就是你对这个方法真正的新贡献。案例库的终点不是收藏别人的成功是校准自己的判断。回头看这篇的路先立四层信息的敏感度结果亮、条件贵再给来源分档一手发布、厂商案例、作者推断然后按任务、数据规则、动作、采用四轴拆解用第二案例比较出跨情境的方法骨架最后落成案例阅读卡。全程没有一步需要你相信或反驳那个案例——你只是把它从一个故事变成了一堆有档位的事实。迁移练习留给你找一篇你最近收藏的 AI 成功报道写三条来源支持的事实注明发布方是谁、两项未知决策需要但没说的、一条有条件的方法迁移方法是什么、迁到你这里要重验什么前提。三条里如果有任何一条你分不清是企业说的还是你推断的回去把出处找出来——分不清出处的知识用的时候会一起出错。下一篇回到你自己身上读了很多、也做了一些怎样向别人证明你真的具备 FDE 的能力——作品该怎样说清你本人的贡献。