本篇判断：真正跑起来的AI项目，第一步不是把AI请进来，是把AI从主角位上请下来——同一个需求落在哪一档技术位置，预算和验收就是两本不同的账；立项会缺的不是模型能力清单，是把「我们想要什么」翻译成「在哪一档动手、用什么验收」的翻译层。
本篇解决读者的什么问题：立项会上，业务部门说得出「我要库存不断货」，技术团队答得出「模型行不行」，中间那句「这活到底该落在哪一档、拿什么验收」没人回答——本篇用三个已上线现场把这句话拆开，给你一张定档表、三个会上能直接问的问题，和这套问法什么时候失灵的边界。
适用边界：三个案例出自2026年9月发布的《FDE案例100》首批24案——同一个访谈编选工程的访谈整理稿，不是24个对照实验，所有效果只说到案例作者自述为止；「技术位置分档」和「需求落位三问」是我们做跨案拆解时用的框架，不是任何一家案例公司的自述，更不是客户验证结果。本篇回答「找到了之后落在哪」，不回答「该找什么损失」——那是前一半，文末交代。
三个现场，同一个反常
一家十几人的跨境电商团队找到案例作者，需求说得非常简单：能不能把这个SaaS和飞书打通（NO-22 txt L21-22）。照字面接，这就是个API集成的活儿。项目做完，方案里最反直觉的一条，是把客户自己的补货公式原样保留、一行没改——「我们没有重新发明一套库存算法」（NO-22 txt L49）。
第二个现场更反常。消费品企业的包装审核项目里，模型看起来最擅长的事——算数——恰恰是被没收的那件：NRV计算被固化成确定性代码，「让模型只做解释和补录建议」（NO-19 txt L133-134）。
第三个现场才真正让AI写东西。一家做抖音本地生活代运营的公司，短视频文案产线，是三个案子里唯一把生成式当地盘的。而它进场前的背景，恰恰是客户先试过直接让AI写、连本地部署DeepSeek都上了，失败收场（NO-15 txt L66）。
三个现场摆在一起，是同一个反常：真正跑起来的AI项目，第一步是把AI从主角位上请下来。
先交代证据的成色。这三个案子出自上个月发布的《FDE案例100》首批24个案例——同一个访谈编选工程的产物，不是24个对照实验，下面所有效果只能说到「案例作者自述」为止。但正因为是访谈里的小故事，钱花在哪一格、由谁决定、失败时谁来兜底，反而藏不住。
花钱花错档也不是个案。2025年8月，Fortune转引过一份MIT报告，按报告口径，企业的GenAI试点只有约5%实现了快速营收，其余对损益表没有可测量影响；同时超半数GenAI预算投向销售和营销，报告认为最大的回报机会却在后台自动化。钱没少花——花的位置不对。
一个补货公式，一行没改
先看清这家客户的处境。十几人的团队，做东南亚市场，主营服装（NO-22 txt L16）；服装每个颜色、每个尺码都是一个独立SKU，按照访谈中的估算，每个季度新增500～800个SKU，全年大概2500～3000个——案例作者的原话，这个量级对一支10～15人的团队「已经不低了」（NO-22 txt L17-19）。
工具其实不少：聚合库存SaaS、飞书、Excel，还有Google和TikTok的广告后台，全都在转。最累的，是那个在各个工具之间来回搬数据的人（L43-44）。工厂发货靠拍照，员工人工看照片、填数据、追物流单号（L27-29）；补货要从SaaS扒数据、填进计算表、按自家公式算，再把结果誊进另一个模板、生成PDF发供应商（L30-32）；广告在另外的平台上跑，库存见底了它还在烧钱（L33-34）。每件事单独看都不重，连成一串，人一天就钉死在「看、抄、填、核对」上（L55-56）。
案例作者进场后的关键判断，不是换掉这套打法，而是先认账：工作人员看SKU过去三个月的销售、结合自己的预测逻辑算补货，「这套逻辑是成立的，问题在于它被埋进了一条需要人工反复搬数据的流程里」（L47-48）。所以第一刀落在管道上——「客户原来的补货逻辑可以继续保留，我们要做的，只是把其中机械、重复、跨系统的动作交给机器」（L49-50）。
四步，每步都有人守着。
第一步修数据。SaaS的API开放程度很低（L74），Key还有失效机制、一个Key不能被多个团队同时使用（L153-155），最后加了一层开源云端数据库Supabase做中转，数据先进中间库、再同步进飞书（L74-76）。作者后来把这类墙总结成一句话：「AI本身可能已经能做了，但数据根本拿不出来，还是落不了地」（L157-159）。
第二步让Agent识别物流照片、回填数据，人只做最后的检查（L86-87）。
第三步回到那个公式：Agent按原来的补货规则算，筛出要补的SKU、给出预计补货周期和数量，人工审核之后才生成PDF订单——「人工的角色从『计算员』变成了『审核员』」（L92-94）。
第四步在立项需求里根本不存在。数据通了之后，「客户又自然产生了下一层需求」（L98）：库存反过来影响广告——某个SKU库存下降到一定程度，先调低、甚至暂停对应广告（L101-102）。作者把这个项目最看重的一步说成：业务「开始从单点自动化走向了流程之间的联动」（L126-127）。
结果只能说一半。时间效率是当事人自述：物流照片处理从每人每天约4～5小时压到1小时以内，补货从至少2～3小时变成主要看一眼、验证一下（L116-120）——没有系统日志和对照明细，从这里推算不出省了多少钱。更硬的边界在后头：交付结束，「客户把我们的团队权限移除了，后续的营收、广告成本和利润数据，我们没有拿到完整的」（L114-115），作者自己承认「这个案例的效果跟踪还有不足」（L128）；访谈最后他留了一句「交付之后，效果归因也是FDE工作的一部分」（L212）——这句的展开正文收在下一案提取件的开头（印刷页p227，NO-23 txt L4-15），第一句就是「这个案例最大的遗憾，就是我们当时交付完以后，没有把后续效果完整追踪下来」（L4），还说「如果让我重新做一遍这个项目，我可能会在一开始就设计好一套『效果基线』」（L11），给补货、广告、订单这些关键环节事前定可量化指标（L12-13）。机制建成了，账没算完——作者自己知道账没算完，项目就停在这。
这个案子看明白，AI的位置就清楚了：它不负责聪明，负责搬运和执行。公式没错，错的是公式被埋进了人工搬数据的流程——这不是模型问题，是管道问题。
模型被明令禁止算数
第二家的账，从一句模糊的话开始：「一年可能要做100多个SKU」（NO-19 txt L24，原文口径即模糊，照录）。产品从需求、口味配方研发，到包装、合规、中试、渠道上线，中间隔着一长串角色（L24-26）；真正影响判断的上下文，大量存在产品经理、研发和渠道人员的脑子里，系统里留下的只有结果（L36-40）。SKU一多，包装审核开始堆积、排队（L64-65）。
案例作者把「包装审核」这个环节拆开，里面至少装着四种判断：设计师查错别字，法务查食品法广告法这类硬性要求，渠道查自己的规范——比如渠道Logo和品牌Logo的大小关系，产品经理判断包装有没有正确表达产品本身（L69-73）。过去，这四种判断全堆给审核人员。
进场方式先记一笔。作者不拿成品方案进场（L86），先让一个Agent在业务群里待了两三周，只收集上下文、不急着解决问题，最后「Agent自己从真实业务沟通中定位到了包装审核这个问题」（L97-101）。顺带一个提醒：原文没提群成员是否知情，这个手法抄之前先解决授权边界。然后是最有组织味的一步——给AI写「岗位说明书」：「如果过去公司要招一个人来做包装审核，HR会给他一份岗位说明书。那么现在我们希望AI承担这部分工作，AI同样应该拥有一份『岗位说明书』」（L111-112）。写说明书的必须是业务自己——完全让外部的人定义Skill，「依然容易变成『外行指导内行』」（L109-110）。
工程上最锋利的一刀，落在算数上。包装图上有密集文字、NRV能量计算表格和艺术字，先按视觉模块分别配OCR和VLM，再把固定规则脚本化，把热量表和NRV的计算逻辑固化成确定性代码，「让模型只做解释和补录建议」（L131-134）。作者举的例子很具体：蛋白质2.9g、每份40g、NRV5%对不对这类问题，「从此实现可复现地验证」（L134-135）。每个模块的审核结果带来源置信度、每个结论能追溯到原始数据，「人类员工接手时，清楚该信什么、该查什么」（L136-137）。最后接进产品生命周期系统：设计稿一提交，Skill自动跑一轮预检，合规问题、NRV计算、数字矛盾，在设计师交给下游之前就拦下来（L141-142）。
结果口径：预检已经嵌进日常流程、常态运行（拆解卡判级：已上线，效果为当事人自述、无量化对照）。当事人自述的变化有三层——法务和产品经理的时间被重新分配（L166-170，无数字）；个人经验「有机会变成组织经验」（L175-176）；作者把整体效果理解成降本增效、决策质量、组织能力三层（L186-188，自述框架）。全部没有前后对照的分母。留白也在这：预检拦错了谁纠、审核规则谁有权改、例外谁来批，原文一个字没提。
这个现场立起来的判断是：能写成代码的判断，不交给模型——模型算的数每次都可能不一样，而审核要的是可复现。 模型不是被砍掉了，是被安排到了它该在的位置：解释、补录建议、给判断供上下文。
唯一让AI真写的项目，进场券也不是模型
第三家的量压在高峰上：抖音本地生活代运营，客户以餐饮商户为主、覆盖多个城市（NO-15 txt L30-31），最高峰一天要产出两三百条文案（L37，当事人自述）。内部不缺会写的人，缺的是复制——「一个人可能写得很好，却不可能一个人每天稳定处理几十甚至上百条内容」（L34-36）。
客户不是没试过AI。「直接让AI写，包括本地部署DeepSeek，但效果并没有达到预期」（L66）。作者的诊断：AI味很大程度上来自一种「固定范式」——给AI一套固定模板，让它不断模仿；单个案例里可能有效，跨商户、跨题材就机械重复（L70-72）。这家公司面对的商户差异恰恰最难糊弄：高端酒店、连锁餐厅、独立小店，主打菜品、活动、老板表达方式、目标客群全都不一样（L44-46）。模板应付不了这种差异。
真正的路径走了五步。先把业务看懂：现场沟通、观察每天实际怎么干活——谁负责什么、新客户怎么进场、怎么判断一条文案好不好（L95-102）。再把人的经验拆成业务字段：客户是谁、门店类型、主推菜品、活动、卖点、内容方向（L110-113）。作者对这一步的概括，是整篇里最值得抄的一句：「把一个优秀运营人员脑子里的经验，变成可以被系统调用的业务逻辑」（L114-115）。
然后承认一个事实：「单纯一个Prompt或一个Skill是不够的」（L119）——「写出一篇文案」和「稳定地生产可以使用的短视频脚本」是两回事（L120）。所以第三步是把提示词、Skill、业务参数和校验、审计机制组合成一条生产流程（L121-122）。第四步定人机边界：AI负责大部分标准化工作，「人负责最后的审核和判断」（L133）；某个节点AI做得不好，就把节点交还给人（L134）。第五步是熬：周期性给客户交付新版本，拿平台数据反馈调——提示词、流程顺序、甚至模型选型都可能动（L139-142），因为文案这件事像「语感」，「很难一开始就被定义成一套绝对标准」（L143）。
结果口径：工作流已上线，新客户的进场方式变了——提前把门店、菜品、活动参数规划好，系统持续生成，作者称之为「削峰填谷」（L159-163，自述）。「从客户的使用反馈来看，效果非常明显」（L147）——注意，这是当事人自述转述，没有产能前后数字、没有脚本通过率、没有按商户分层的分母。
判断落在地盘上。变化表达确实是生成式的地盘——没有公式可保，没有数值可算。但「扔给模型就赢」在这家客户那里已经被证伪过一次，字段、校验、回退这套下限就是被那次失败逼出来的。生成式的地盘，进场券是字段、校验和回退，不是模型本身。
立项会上没人回答的那个问题
把三个现场按同一句式重排，错档就显形了。
业务部门说得出来的，永远是要的结果。NO-22的案例作者总结过客户语言的形状：「客户告诉你的往往是一个结果」——「我希望库存不要断」「我希望补货不要这么麻烦」「我希望广告不要浪费钱」（L180-182）。他还有一句更准的：「其实客户通常知道自己想要什么，他们只是不会用技术语言描述」（L189）；他不知道API怎么接、不知道哪些流程适合自动化、也不知道库存和广告其实可以联动（L190-191）。技术团队答得出的，永远是模型行不行。两头都对，中间没人。
中间缺的那个问题，三个现场都是案例作者一个人补上的。NO-22里他先判断这个需求值不值得照单全收（L23-24、L67），NO-19里他先让业务自己拆解岗位说明书的输入输出（L113-115），NO-15里他先看懂业务再拆字段（L95-102）。作者给这个动作起过名字：「FDE的价值，是先把客户要的结果拆开，看清它背后对应哪条业务链路，再判断技术该插在哪一段」（L183-184）。这句话里最贵的词不是FDE，是「先拆开」——这个动作在任何一家公司的立项会上都该有人做，而大多数公司的会上，这个位置空着。
我们的拆解把技术位置粗分成几档：优化、数据治理、确定性计算、系统联动、生成——这是我们对24案做机制对照时用的分档，不是任何一家的自述（跨案研究§二）。同一句「我想让AI帮忙」，落在哪一档，预算和验收是不同的账：
| 档 | 这档的活长什么样 | 验收看什么 | 花错档的样子 |
|---|---|---|---|
| 优化 | 有限容量里选组合、排顺序（装车、裁切、排程） | 装得下、可行、现场能执行 | 把「装不满」翻译成大模型聊天 |
| 数据治理＋系统联动 | 规则已成立，数据到不了位、环节互不通气 | 数据到位＋阈值触发 | 为已经可用的公式重新训练模型 |
| 确定性计算（识别） | 字段要从图里提，数值必须可复现 | 算得对、算得稳、可追溯 | 让模型算数——花钱买一个每次都可能不一样的答案 |
| 生成 | 表达每次都要不一样 | 基础水平稳定＋人守终审 | 套固定模板——花钱批量生产AI味 |
识别提取通常和确定性计算、数据治理同单出现，像NO-19那样。
三个现场对号入座（我们的拆解；各案事实只取自本案源文本与拆解卡）：
| NO-22 跨境电商补货 | NO-19 包装审核 | NO-15 短视频文案 | |
|---|---|---|---|
| 客户进场那句话 | 「能不能把这个SaaS和飞书打通」 | 审核堆积排队，没人提AI | 「直接让AI写……效果并没有达到预期」 |
| 落在哪一档 | 数据治理＋系统联动 | 识别＋确定性计算 | 生成 |
| 规则的状态 | 公式已成立，缺的是数据准时到达 | 字段在图里，数值必须可复现 | 没有公式，每次都要不一样 |
| 验收 | 数据到位＋阈值触发 | 算得对、算得稳、可追溯 | 下限稳定＋人守终审 |
| 花错档长什么样 | 为已有公式训练模型 | 让模型算数 | 给变化表达套固定模板 |
一个必须钉死的边界：这张对照表不构成互斥分类，一行需求可以同时占好几格——NO-19自己就同时有识别、计算和预检联动。NO-15尤其是必要的异类：它面对的是变化表达，不能为了回应装箱那类优化问题就硬塞进优化模型，也不能反过来因为生成解不了装箱就说它不务正业。错档的错，从来不是「选了低级技术」，是跨格挪了预算。
开头那份MIT报告反过来读，就是错档的规模：钱没少花，花在了格子外面——超半数投进销售营销，报告认为回报最大的后台自动化反而没人管。
AI立项会缺的不是模型能力清单，是把「我们想要什么」翻译成「该在哪一档动手、用什么验收」的翻译层。这层能力不在技术团队，也不在业务部门，在两者的接缝上。
给立项会的三个追问
怎么把「先拆开」变成会上能执行的动作。我们的拆解给出三个追问，按顺序问，问完才有资格谈模型：
第一问：这活的正确规则是否已经存在？
存在——那这就不是AI项目，是数据项目。修管道、保公式、加联动；验收＝数据准时到达＋阈值触发。NO-22是这一问的答卷：公式保留、Supabase中转、库存联动广告，四步里没有一步在训练模型。
第二问：其中的判断，哪些是确定性计算？
是——脚本化，并且明令模型不许算、只做解释。验收＝可复现、可追溯。NO-19把NRV固化成代码，还顺手做了分层：错别字、法规、渠道规范、产品表达，不同判断进不同格子（L69-73、L126-127）。
第三问：剩下的是不是「每次都不一样的表达」？
是——这才进生成式，且必须带三件套：业务字段、校验审计、节点级回退。验收＝内容下限稳、人守终审。NO-15过的是这一关。
两条边界。其一，三问是给预算定档的检查顺序，不是分类学——一行需求可以三问各占一部分，答案不互斥。其二，问完三问，才轮到「用什么模型」；NO-22案例作者的原话：「所以做方案选择时，我会先问，这个问题到底需不需要AI」（L168）、「能用简单自动化解决的，就不要为了追热点强行用Agent」（L169-170）。
它什么时候失效
三问不是万能钥匙，四种情况下它会失手，先说在前面。
一是规则本身错了。第一问的隐含前提是「规则正确」——NO-22里「这套逻辑是成立的」是案例作者进场判断后的结论，原文没给逐单对照的验证过程。规则若错，三问会把错误原样固化进管道，自动化只是让错得更快。
二是格子会挪。确定性计算和生成的边界不是永久的。NO-19里渠道反馈就是活的例子：「不同渠道每一次的反馈积累下来，沉淀成标准后交由AI完成预审」（L76-77）——昨天必须人判断的，明天可能可以标准化。三问要按期重答，不是立项时答一次管五年。
三是痛点根本不在技术位置。数据拿不出来、流程改不动、没人有权限拍板——三问答得再准也落不了地。NO-22的Key失效机制就是这种墙（L153-155、L157-159）；同一案例，交付后权限被移除、效果账断线（L114-115、L128），定位再对，也不能代替验收。
四是损失本身没找对。本篇只回答「找到了落到哪」，不回答「该找什么」。那半趟在《先找损失，再谈AI：场景发现不是技术选型》里：先审计损失，再谈落位，顺序不能反。落完位之后组织能自己运营到哪一档，是另一把尺子的事，见《AI落地分六档：从H0到H5，你家在哪一档》。
最后收一句。预算花错档的公司，缺的从来不是一张模型能力清单，是那个在会上把「我想要」翻译成「在哪一档动手」的位置。这个位置现在大多空着——空着的每一天，预算都在替你做决定。
来源与口径备注
- 案例来源：Datawhale《FDE案例100》首批24案，2026年9月发布，L1访谈整理稿（同一编选工程，非24个独立因果实验）；本篇只用NO-22、NO-19、NO-15三案（NO-23仅取其开头承接NO-22的续文段L4-15），各案事实只从本案源文本与拆解卡取，不跨案挪用。
- 引文锚点：文中（NO-XX txt L行号）＝
sources/fde-cases/pdf-text/NO-XX-*.txt提取件物理行，全部逐条实核；页码用印刷页（印刷页＝PDF物理页−1）——NO-19「已上线常态运行」判级见拆解卡p193，NO-15「上线后改变新客户进场方式」见p154，NO-22案件正文实际p219-p226。 - 数字口径随文标注：NO-22「十几人／季度500～800 SKU／全年2500～3000」＝访谈估算自述；「4～5小时→1小时以内」「2～3小时→看一眼验证」＝当事人自述、无系统日志与对照明细，全文未由其推算省钱金额；NO-19「100多个SKU」＝原文模糊口径照录；NO-15「高峰两三百条」＝当事人自述，「效果非常明显」＝自述转述。NO-19、NO-15已上线但均无量化前后分母，全文无「已验证」表述。
- 框架署名：技术位置五档（优化／数据治理／确定性计算／系统联动／生成）与「需求落位三问」均为我们的拆解（跨案研究§二），一行需求可含多种技术、不构成互斥分类；未冒充原案自述或客户验证结果。
- MIT锚点：以「按报告口径／Fortune转引」限定（Fortune 2025-08-18转引MIT NANDA《The GenAI Divide: State of AI in Business 2025》）。
- 地域口径：NO-22＝东南亚市场跨境电商；NO-15＝抖音本地生活代运营；NO-19＝消费品企业（原文未标国别）——未统一说成中国企业。
这个系列下一篇换一类现场：体制内。前台早就数字化了，后台还是人——最不敢错的几个现场，交出的落地闭环反而最完整；AI进那种现场交的第一份产出，不是效率报告，是审计报告。
相关阅读：《先找损失，再谈AI：场景发现不是技术选型》补本篇的前一半——损失没审计，「落在哪一档」无从谈起，顺序不能反；《AI落地分六档：从H0到H5，你家在哪一档》补后一半——落完位之后组织能自己运营到哪一档，是另一把尺子的事；「先拆开」这个动作在客户现场通常由驻场的那个角色做，他的商业模式另有一篇专讲：《FDE驻进客户现场以后，怎样避免永远出不来？》。