他们聊了一个半小时，从老板为什么要买 AI，聊到制造业怎么查一批积压的物料，最后聊到派去客户现场的人得会些什么。我一边听，一边在想自己的工作。一个功能我做出来了，演示的时候也能跑通。然后呢？我怎么知道它让业务变好了？
其实「这个功能怎么做」是个我比较熟悉的问题。需求拿过来，能顺着往下拆，做完也有个东西可以交。但要问「这个功能为什么值得做」，我就得去看用它的人了。他原来怎么做这件事？卡在哪？我把结果给他以后，他手上那件事会有什么变化？
这个问题我觉得蛮值得记下来。以后 AI 会往哪里走，我肯定说不准。不过从我现在的实习往外多看一点，我大概能知道，自己还有哪些事没学会。
王自如把企业数字化分成四步，信息化、流程线上化、数据化、智能化。四个词连在一起，听着都挺熟的。拿工厂排产一比，中间两步其实差得挺远。
工厂已经把计划排好了，客户突然插个单，碰巧又有台机器坏了，那就得改。假如各部门拿到一份 Excel，各改各的，最后汇总一版发到产线。第二天有人来问，昨天是谁先改的，为什么改，哪个工序因此等了两个小时？这时候手上只有一张最终版的表，事情就很难讲清楚。
当天按哪版生产，和中间为什么改了三版，这两种数据都有用。前者能对经营结果，后者能让计划员下次少踩同一个坑。现在让 AI 来排，它可能几秒就给出一份新计划。但要是系统连改过什么、为什么改都记不下来，出错以后我还是不知道去哪里找原因。
反过来，节目后面举了电商的例子。平台已经把商品、交易和流量记好了，一家不大的商家也可以很快做经营分析。所以我现在再听到「这家企业准备好用 AI 了吗」，会想先问一句，具体是哪件事？一家公司可能有的业务已经攒下几年能用的数据，有的还在到处找最新版的 Excel。
帆软提到，他们见过有资源自建模型、愿意先试几个方向的大公司，也见过想等同行跑通再买的中型企业。有些小公司问得就特别直接，能不能多带来点客户，能不能提高转化，客服成本到底能降多少？我听到这里会觉得，换成我自己掏钱，好像我也会这么问。毕竟每家企业能等的时间不一样。
哪怕在一家公司里，老板、IT 和业务同事也各有各的账。老板看投入产出，IT 要想接上之后怎么维护，最后每天坐在电脑前点那些按钮的是业务同事。节目里一位嘉宾说先看企业的总体价值，另一位说如果只能挑一个，他会先把业务部门服务好。我觉得可以把这两句话放到同一个项目里想。老板告诉你这笔钱为什么要花，业务同事能告诉你花了以后，有没有一件具体的事变好做了。
他们说有些老客户已经用了很多年报表，指标和数据相对齐，挑一个场景就能开始。碰到基础薄一点的新客户，他们会先挑一件做成之后有人用的事，再一边试用、一边把缺的那部分数据补上。这个叫「以用促治」。我觉得这个说法好懂，假设现在要做的是客服助手，可以先看它能不能少转几次人工。要是它十次都答得很顺，但同事每次还要去原来的系统核对一遍，那就知道下个版本该先改哪了。 王自如发布的数据治理切片
节目里有个质量分析的案例。一线员工先取数据画图，看到一点异常，再回去取数据画下一张。客户想让 AI 把同样的动作做一遍。帆软拆了一下，发现照着走得反复调用工具，花不少 Token，分析还有可能越跑越偏。后来他们换了一个问法，业务到底想看到什么？其实是想知道哪里异常，下一步去查什么。那能一次准备好的数据，就可以先拿齐，没必要叫模型兜同样的圈子。
个人 Agent 就比较好理解。我拿它整理录音、写个文档，有问题我自己看得出来，也可以自己改。可如果它算的是下个部门要拿去用的经营数字，别人怎么知道它查过哪张表、有没有权限、用的又是哪套算法？节目里说的 Harness，落到这里就是一些很具体的事。允许查什么，算完怎么校验，证据不够时怎么把问题交还给人。
假如我用 AI 半小时就写完一份报告，接手的同事还得花一小时查里面的数字，我这边确实快了，他那边反而多了点活。节目里讲 HR 检查答辩材料，我觉得就挺具体的。让 AI 先提示材料缺了什么，评委有更多时间追问这个人实际做过什么。这半个小时省下来以后，最终拿去干什么，还是公司要自己做的决定。有的老板想到的是减人，有的会把时间给原来顾不过来的工作。
王自如讲过一个很有意思的事。他以前做制造业的数字化，遇到一个问题，物流的「在途时间」到底是装完车开始算，还是车辆驶出厂区才开始算？
乍一听，这能差多少？但旺季的时候，车装完以后可能还要在厂区排两三个小时。这两个小时算进去，运费结算和考核结果就会变。两边各拿一套数字过来，可能各自都算得挺对。最后得有人把相关部门找齐，商量这两个小时到底算谁的，然后把这个定义写下来。王自如说他们当时做了一份指标口径的白皮书。平时大家未必天天翻，但吵起来的时候，知道当初是怎么定的。
他们顺着这件事聊到，企业里面是不是得有个能协调各部门的「孙悟空」。另一个案例是一家涂料企业，老板想让销售别光看卖了多少，也看看赚了多少。财务就把公司原来那套经营分析拆到每个人身上，再让 AI 按月出报告。销售看得到自己的收入、差旅费和回款，才有机会发现有些单子签得挺热闹，实际赚得很少。
这个项目里，老板先想清楚想改什么，财务知道这笔账该怎么算，技术再想办法把这件事做到几千人身上。真到了现场，也许有一个特别强的人能把几边都拉齐。也可以是几个人各管一段，把自己那一段接住。只要有一段没人做决定，最后就可能多出来一份报告，问题还在那儿。
节目里聊到什么场景可能有比较高的回报，嘉宾举的是归因分析。比如新能源车企仓库里有一批物料迟迟用不掉。报表能告诉你压了多少钱，接下来才是最麻烦的，先找谁？是设计改了以后旧料没消化，还是采购和生产计划没对上？你找到的人不同，接下来处理的事也不同。
要把这个问题查下去，设计、计划、采购、生产和仓库的记录得对得起来。设计系统按零件和版本记，仓库按物料和批次记。单看哪一个系统，数据都在。可你要找的是，某次设计变更之后，哪一批采购进来的料就再没被用过。中间有一处连不上，模型就只能猜。
王自如把从大量数据里挑出这一回真正有用的记录叫「抓中药」。我觉得这个词还挺好懂的。你给系统一句话，它可以帮你找有关的表、跑已经定义好的计算，再把理由和依据交出来。要是我在现场，我还会想去看看那个人拿到分析以后先查了哪一批料，到底省了几次来回。节目里甚至聊到按效果付费。真要这么付，那得先讲清楚，积压少了多少是因为这次改动，多少可能是刚好赶上了订单变化。账算不明白，收益讲得再热闹也很难落到合同上。
陈炎提了个我觉得很现实的问题。软件卖给客户，再做一大笔实施，项目收入当然好看。可企业明年战略改了，连调整几个指标都得重新请原来的团队过来，这个项目客户接住了吗？帆软说他们会看场景选做法，通用的用标准产品，复杂一些的用几个产品拼起来，到了行业里走得很靠前的客户，再一起试原来没有做过的东西。试完如果发现好几个客户都缺同一块，就有机会把它做进产品里。
他们讲早期做 ChatBI 也蛮有意思。那时用小模型，出结果很快，但你得把指标名字说准。有人把毛利率和利润率叫混了，工具就很难给到他要的答案。等大模型对口语和意图的理解好了一些，他们才重新做企业数据智能体。想想也合理。既然用户本来就不熟那些字段，要求他先把数据库里的说法背下来，他可能还不如去找原来那个懂数据的同事。
节目里也过了一遍帆软的产品。企业本地部署时，可以用 FineDataLink 接不同系统，用 FineBI 做指标和分析，再在 Dora 上构建数据智能体。云上的 FineBI Cloud 更适合电商这类数据接口和口径相对标准的场景。听到这儿，我比较容易理解为什么有的客户想自己建，或者要求把模型和数据都放在自己那边。它要看数据能交给谁、内部规则有多特别，还有改了以后谁负责养着这套系统。 帆软产品说明
节目里讲高速收费员转去做设备运维。给大家发培训视频，然后考试，效果不太好。后来他们把设备照片、历史工单和排查步骤放到工具里。现场碰到一台不认识的设备，拍张照就能查型号。报修时先问问灯亮不亮、重启以后机箱有没有声音，再把这些写进工单。维修的人出门前看一眼，大概就知道该带哪些备件。我觉得这比说「把老员工的经验变成数字资产」容易懂多了。就是新人站在设备前犯难的时候，他真的能找到下一步怎么做。
还有一个医药零售的例子。AI 帮忙出运营方案，总部看策略，区域看本地情况，门店看手头的库存，一开始三处都要检查。节目里说，等同类方案反复跑过、反馈也收到了，如果越来越少被否决，人就有机会少查几个中间步骤，改为验收一段结果。这就是他们说的从 human in the loop 到 human on the loop。
我听到这里会有个疑问。否决次数变少了，是 AI 做得更好了，还是门店每天太忙，看一眼就放过去了？如果要我决定能不能少一次审核，我会去翻几份已经通过的方案，看看最后执行有没有出问题。后面聊到让一个 Agent 协调多个专业 Agent，我想每多交一棒也得问同样的问题。上一步交出来的东西对不对，下一步看得出来吗？
FDE 是前线部署工程师。帆软的做法是让一支小队直接去客户那里，先把问题弄清楚，然后做方案、写代码、跟交付。几家客户反复碰到的问题，还要带回公司，看看能不能让产品以后就支持它。他们招人也确实挺全的。要能和客户沟通，懂一个行业或者业务环节，懂 Agent，能写代码，会管项目，还得熟悉帆软自己的产品。连 Java 都专门提了，因为有时候客户需要的东西，现成产品里就没有，去了得自己写。
他们愿意花挺多时间在现场聊需求，最后只挑一小部分往下做。我听到这儿就想到，需求交到我手里的时候，前面其实已经有人想过一轮了。那个人当时看到了什么，为什么会说这件事比旁边那件急？我其实很想学他是怎么判断的。
我之前在《写在走出大学之前》里写过，我的几段实习都和 AI 应用有关。现在回头想，我还是很喜欢写代码和解决具体问题。但我接下来想多懂一点业务，可能就从听懂需求评审上那些话开始。比如有两个人对着一个数争半天，我能不能跟过去看看，他们各用的是什么口径？如果我要做一个 Agent，我能不能先拿到几次之前真实出错的情况，看看它遇到缺数据、超时的时候，能不能交出一个同事接得住的结果？这些事以前可能有人替我想过了，我也想试试自己能不能想明白。
至于怎么知道自己有进步，我想先做一件小事。下回手上的功能交出去，过一阵我去问问用它的人，最近用过吗？原来哪一步最烦，现在那一步还在不在？要是他说没用过，或者用完还是得回老系统查，我就再去看一眼为什么。
我现在也不知道答案是什么。但我觉得，这次问到的东西，可能比我把那段代码写完的时候更能告诉我，接下来该学什么。
]]>可能是本来只想记下一个问题，写着写着却觉得它得像一篇完整的文章。接着还要想标题、找配图、调排版。每一件事单独看都不难，叠在一起，就容易把原本十分钟能写完的笔记留到明天。
所以我想先把每一期压到三件事：写下今天的问题，给出暂时的判断，再留一句什么证据会让我改变判断。写完是一份 Markdown，想发的时候就发布。
我可以用接下来七次写作检验这个判断。每次只记一笔：最费时间的是找问题、把判断写明白，还是整理格式和发布？
如果主要时间都花在找问题上，继续优化网站的发布流程帮不了太多。我会试着在白天把遇到的疑问先记下来，早上从里面挑一个。等七次都做完，再回来补上结果。
]]>