12.2 B 项目推进（4 问）

Q5：客户说不清需求，一直说「你们先做个方案给我看」，怎么办？

不要写方案，去做一个能点的东西。

客户说不清需求不是态度问题，是人类通病——面对抽象描述很难给出准确反馈，但面对具体产出立刻能说出「不对，我们这里不是这样」。这就是第 6 章「进场」那句话的含义：Demo 是唯一有效的沟通语言。

操作上：先用 WorkBuddy 搭一个粗糙但能跑的版本（专家 + 客户几份真实文档进资料库，一两天即可），拿去让客户挑错。客户挑出的每一条错，都是一条真实需求。

Q6：客户直接告诉我他要什么功能，我按他说的做就行吗？

不行，这是最危险的情况——因为它看起来最省事。

客户带着方案来，往往意味着他已经自己做了一轮问题定义，而那轮定义可能是错的。往下挖三层（第 6 章的三层下挖法）：

• 第一层 ：是流程里哪一步真的出了问题？（而不是「我们要一个 AI 客服」）

• 第二层 ：这一步现在是谁在做、每天做多少次、最烦的是哪一段？

• 第三层 ：做成什么样算成功？用什么数字衡量？谁来判定？

三层都答得上来，才可以开始做。答不上来就做，交付时必然扯皮。

Q7：一线员工不配合，觉得我是「老板请来优化岗位的人」，怎么破？

这是 FDE 现场最真实的阻力，靠开大会宣讲解决不了。三步走（第 6 章的破抵触三步法）：

1. 分别对齐预期。 和管理层谈效率与成本，和一线谈「省掉你最烦的那部分」。两套话术不是话术，是因为两方在意的东西真的不一样。

2. 建小范围对照组。 不要求全员参与，找几个愿意试的人组成 A 组。有对照数据后，说服力来自事实而不是行政压力。

3. 让 AI 对员工自己真正有用。 第一个上线的功能，选一个员工自己会主动打开的——比如替他写日报草稿、替他查制度条款。 先给收益，再谈索取 。

配套的是第 8 章「沉淀」的「信任四问」：贡献、收益、边界、安全感，四个问题你要能正面回答。

Q8：Demo 效果很好，一上真实环境就崩，为什么？

因为 Demo 通常跑在三个理想条件下，而这三个条件在生产环境都不成立：

• 数据是整理过的。 真实数据有缺失、有歧义、有历史遗留的错误格式，这部分往往是工作量的大头。

• 权限是打通的（或绕开的）。 真实环境里跨系统取数、跨部门看数据都涉及授权，权限问题常比算法问题更耗时间。

• 用户是配合的。 演示时看的是最理想的提问方式，真实用户的输入五花八门。

这就是第 7 章「交付」讲的 L1→L2 死亡谷。破法：第一天就接真实数据（哪怕只 100 条）、把权限打通排在功能开发之前、找到一个真心愿意用的种子用户。