ARTICLE · 1272459
AI交付怎么变轻?从跨境工具到一份业务诊断报告
AI交付怎么变轻?从跨境工具到一份业务诊断报告在上一篇创业复兴 AI 项目路演：台上谈可能性，台下算另一笔账，我看见了一号数字员工团队的处境：智能体能替人处理不少重复工作，交付给客户时却仍要靠人深入业务。 这让我想到自己做 FDE 时常遇到的问题。客户的业务各有不同，接到一个新项目，就得重新了解流程、整理数据、配置工具。AI 写代码越来越快，这些前后的工作，仍然很占时间。 我还是很困扰：是不是只要客户的问题不标准，FDE 就注定得从头跟到尾？ 但就在最近两周跟朋友的交流里，我碰到了两个值得琢磨的做法。一个把原来要教客户安装、配置的东西，提前装进了垂直产品里；另一个不急着承诺包办落地，而是先把业务摸排和诊断做成一项能单独交付的服务。它们都在尝试减少一部分反复发生的交付工作。 吴江老师在路演中说，技术只是解决用户需求的路径，创业者要明确用户是谁，找到真实需求的落地场景。他还提到，有些人手里有技术方案，却找不到愿意买单的客户；有些人有客户，却找不到合适的解决方案。 这句话放到 FDE 服务里，问题就更具体了。客户通常不是缺一个 AI 工具，而是不知道这个工具应该接进哪条业务流程、由谁使用，以及怎样判断它真的解决了问题。FDE 要做的，正是把技术方案和客户的真实业务接起来。 上周做跨境电商的朋友和我聊到稳卖 AI，我们拿它和自己做的工具比较：我已经做好了 卖家需求洞察、商品上架文案、经营数据报表、TikTok 达人开发这几个场景 skill，具体功能也可以根据客户需求调整。但真要交给企业使用，对方还得装通用工作台，再把 Skill 技能包、工具接口配好。 稳卖走的是另一条路，它做了一个面向跨境电商的集成入口，把调研、内容生产等工作所需的能力放了进去，说白了就是电商版的 Codex，技术做法不算创新，但客户不必先学会配置工作台、Skill、MCP，才能开始处理业务。朋友试用一份调研报告时，也会在意消耗了多少积分、值不值那个价；但至少他讨论的已经是一次具体工作的成本和结果，而不是如何把工具装起来。 我以前容易把 “功能能不能完成” 放在前面，但这次让我意识到，客户拿到功能之前走过的那些步骤，也是交付的一部分。我能做四个场景工具，不代表一个不熟悉 AI 工作台的电商老板能把它们用起来。稳卖把通用工具、界面和电商任务先接好，相当于由产品方提前做了一部分原来需要 FDE 逐家讲解、配置的事。 当然，产品方也得维护这个入口，跟着模型和工具的变化更新。公司里由谁来用，原来的分工怎么调整，也还要有人推动。朋友聊到，如果老板不推动，员工未必会主动把新工具放进日常工作。 这给了我一个很实际的取舍：定制的 Skill 更灵活，能针对具体客户改，但如果只交付 Skill，安装、学习和组合的负担就还是留给了客户；把这些负担都做进产品，又要投入时间维护一个稳定的入口。 这些成本得提前算进去，才知道软件和陪跑分别该怎么卖。 这周一和朋友聊企业 AI 落地，他介绍了一种已经有人在用的做法：借助工具访谈、梳理部门与流程，先给企业一份诊断报告，再谈内训和系统实施。还特别提到，客户拿到报告之后，后续实施也可以找别的人做。 “也可以找别人做” 这个细节很高明。FDE 项目常常一开始就要谈整套交付，可这时候客户连问题在哪个环节、值不值得改、该先改哪个部门都未必清楚。双方容易对 “做成” 有不同理解：客户以为买了一个结果，交付方发现前面还有大量没被算进报价的调研和梳理工作。 如果把这段工作单独拿出来，至少可以先谈清楚一个更小的交付物。只想解决上架内容或经营报表的问题，就先做一次 “专科” 诊断；想弄清财务、供应链、运营和推广之间的数据怎么流转，再做跨部门的 “全科” 诊断。诊断以后，客户可以只拿报告回去安排团队，也可以继续购买实施、内训。每往下一步，都重新确认范围、负责人、验收方式和费用。 诊断单独拿出来，双方就有机会先把问题谈明白。工具可以辅助记录和整理，关键岗位有没有问到、实际流程和数据有没有看过、哪一步值得投入，仍然要靠懂业务的人判断。 吴江老师还提到，每一次和外界的接触，都可能成为下一次开发和迭代的节点。对 FDE 来说，和客户沟通不只是为了收集需求，也是在判断：哪些问题值得解决，哪些问题可以沉淀成下一次还能复用的方法。 这套交付设计我们还在梳理。它最吸引我的地方，是把 “了解一家企业” 也变成可以积累方法的工作：访谈要问什么，业务怎样拆，报告怎样组织，下一次都能继续用。 虽然每家企业的答案不同，但问问题的方法可以越做越熟。 把这两个例子放在一起看，交付变轻不是再多做几个智能体，也不是把所有服务都改成订阅制。更具体的变化是：把一次次交付中反复出现的步骤拆出来，判断哪些应该变成产品，哪些应该变成诊断，哪些仍然需要人深入参与。 产品解决的是 “客户能不能开始用”。 诊断解决的是 “客户到底应该先解决什么问题”。 实施解决的是 “方案能不能接进真实业务”。 内训解决的是 “客户团队能不能自己持续使用”。 这四件事可以由同一个团队提供，但不能混在一个模糊的 “AI 解决方案” 里一起报价。不同环节需要投入的人不一样，交付周期不一样，客户最后拿到的东西也不一样。 FDE 这类服务很难像 SaaS 订阅那样自然形成持续收入。它往往是一阶段一阶段地解决问题，客户到了新的业务阶段，才会产生新的需求。对做交付的人来说，更现实的问题是：在这一阶段的项目里，能不能把范围谈清楚，把不该免费承担的工作算进去，把已经做过的事情沉淀下来。 对 FDE 来说，效率提升也不只是少用几个 Token，或者让模型多写一些代码。更重要的是，做完一个项目之后，能不能留下下一次还用得上的东西：一套访谈问题，一份业务梳理模板，一个已经配置好的工具入口，一种素材管理方式，或者一套明确的验收标准。 这些东西不能替代对客户业务的理解，但可以减少每次从零开始的部分。项目做得越多，真正应该增加的，不只是收入，还有自己的判断速度和交付效率。 我现在更愿意把一笔 FDE 生意看成两本账：这一单能留下多少利润，下一单能少做多少重复工作？ AI 越来越会干活，我们做交付的人，也应该把每次项目留下来的东西，变成自己的生产资料。 #最近的观察#我在观猹学AI
