唐龙君AI实验室 | 第6期：AI 项目第一轮沟通，先别谈方案

唐龙君AI实验室 · 2026-10-24 · 九羲科技

一家制造企业的未来工厂 AI 项目，第一轮沟通，我们准备了八类问题，没准备方案。AI 项目谈崩，很少是因为技术不行，多半是因为第一轮就没对齐：目标、决策人、验收标准、数据条件，缺一个，后面全是返工。

本期是谈判期的方法稿：项目细节、场景清单、报价口径一律不公开，只讲第一轮沟通的问法。八类问题、两种场景、三道关，都是实验室在谈判桌上提炼的方法。

· · ·

八类问题，先于方案

第一轮要形成的是共识，不是方案。我们的八类问题是这么排的：

目标与节点——这个项目为什么做？要达到什么效果？时间节点卡在哪？目标不清，方案越漂亮偏得越远。决策机制——谁拍板？技术、业务、财务，话语权怎么分？找不到拍板的人，沟通永远在“再研究研究”里打转。真实需求与价值——每个场景，是真要用起来，还是“满足建设要求”？这两类，后面单说。范围与验收边界——做到什么算做完？用什么判据验收？准确率、覆盖率、还是“能用”？判据不量化，验收就是玄学。系统与数据条件——要对接哪些系统？数据在哪、什么质量、谁提供？AI 项目里，数据条件是第一约束，不是备注。技术架构与平台选型——多模型怎么接？锁不锁定单一模型？数据放哪？敏感数据出不出厂？这些是架构的红线，先画。合作方式与责任——谁做智能体开发，谁做平台，谁运维？三方项目里，责任不清等于没人负责。预算报价与启动条件——预算有没有？报价谁确认？启动的门槛是什么？“报价经确认”本身，就应该是一道显性的启动门槛。

八类问完，四项共识才有地基。顺序不能反：先谈方案，等于在没打地基的地方盖楼。

· · ·

两种场景，两种交付标准

需求清单里，场景通常分两种：一种是“满足建设要求”的，一种是“业务真用起来”的。名字像，交付标准完全不同。

前者对标的是验收——按建设要求把能力建起来，文档、演示、验收报告齐了，算交付。后者对标的是业务——工人愿不愿意用？用起来效率有没有变化？出了问题找谁？这是运营标准。

两种场景混在一起谈，报价逻辑会打架：按验收标准报，落地场景做不深；按落地标准报，验收场景嫌贵。第一轮就要把它们分开：哪些按验收交付，哪些按业务效果交付，分别用什么判据、分别怎么报价。分开谈，每一类才谈得拢。

· · ·

范围漂移的三道关

还有一类坑，叫范围漂移：需求清单写的，和报价功能清单写的，不是一个东西。我们的做法是三道关。

第一道，逐项对口径

拿需求清单的每一条，去对报价清单的交付范围和排除项。最常见的漂移长这样：需求里写了某个场景要“比对”，报价的排除项里写着“不做比对”。这种雷，必须在第一轮就让各方书面确认以哪版为准。口头“到时候再看”，就是验收时的官司。

图注：逐项对口径：三处最常见的错位——需求写法与报价写法对不上（唐龙君AI实验室制图）

第二道，演示与交付划界线

演示用的快照、模拟数据，要在沟通中明确标成“演示”，防被当成“交付承诺”。演示越像真的，这条界线越要画清楚。

第三道，数据与样本的归属

验收用哪批数据、什么环境？验收之后，数据和样本归谁、还返不返还？POC 的判据谁来定、用什么样本定？这些不落在纸面上，验收那天全是口水仗。

谈判期，项目细节不适合公开讲，能公开的是方法。方法就这三句话：第一轮先问八类问题，两种场景分开谈，范围漂移过三道关。AI 项目的第一公里，决定了收尾那一程走不走得顺。

· · ·