Aitishiku.com我花1小时劝退客户别做知识库，他反而谢我
企业AI转型顾问申悦在服务一家头部OTA公司时，面对20万份文档知识库项目，没有急于出方案，而是通过四个理由劝退客户，并引导其聚焦核心问题。本文以真实案例揭示FDE在需求诊断中的关键价值，值得每位产品人深思。
本周最大的“成就”，是劝退了一名客户。
别人都是客户说啥是啥，巴不得马上签单，我是建议客户先放弃现在的想法，别急着开始做方案。
20万份文档，想做成”智库顾问”
事情是这样的，本来我的合作伙伴，帮我拉来了一家国内头部OTA公司的AI项目机会。对方是公司组织发展负责人，过去几年，他们一直在推动员工使用内部在线文档工具沉淀工作内容，截止现在，满打满算积累了接近20万份文档——工作记录、周报、项目复盘、优秀案例，什么都有。
其中质量最高的，是过去三到五年晋升季里积累的晋升复盘文档，大概四五万份。
“能参与晋升的员工，他们写的复盘质量是不错的，不会瞎写。所以我们就在想，这些文档能不能做成一个东西，让员工去调用。”
他给我描述了一个最终画面：
“给每个员工配一个智库顾问——顾问背后的支撑，是那些优秀同学在过去几年里做的非常不错的case里总结出来的经验和方法论。”
他们这么想过，也尝试找内部研发做过Demo，可几个智能体用下来，都觉得不满意，也一直没找到真正想要的产品形态。于是想让我基于过去做知识库的经验，给他们出个方案。
问题好解，难的是提出真问题
这次交流，对方也是带着问题来的，他说目前遇到了四个卡点：
- 术语不统一——A部门这么讲，B部门那么讲，表达的意思是一样的，但AI怎么知道大家说的是一回事？
- 知识分类难定——知识库应该按部门分？按族群分（产品/技术/商务通道）？还是按业务线分？目前没有特别好的想法。
- AI生成内容能否回流——员工和AI讨论出一个不错的方案，能不能回传知识库复用？
- 文档质量怎么评估——以后员工自己提交的文档，怎么判断够不够格入库？
听到这里，很多人可能会直接进入“解题模式”——跟他讨论术语库怎么建、分类逻辑怎么设计、回流机制怎么搭。
但这不是FDE该做的事。FDE要看的不是”问题怎么解”，而是“这些问题背后，真正的问题是什么。”
先给糖，再给药
我当时开口的第一句话是：
“您提到的那几个问题都不难，行业都有成熟的解决方案”
客户明显放松了一下，接下来我一一给他做了拆解：
- 术语不统一？建术语库，持续积累映射表就行。
- 知识库怎么分类？其实怎么分都行。真正的问题不是怎么分，是分完后谁来维护。
- AI内容回流入库？技术上就是文档化→入库→解析→切片，不复杂。
- 文档质量评估？用代码初筛+AI二评+人工终审，建一套流程即可。
他提到的四个问题，都有技术上的解法，但我却还不知道这个知识库到底要解决什么问题。
因此每个问题拆完，我都会补一句追问：
术语库谁来维护？分类谁负责更新？回流入库的内容质量谁把关？评估流程建起来谁去执行？
最后，也表达了那个最大的疑惑：
你们想让谁，在什么情况下，查询这几万份历史复盘？查完后，希望他完成什么事情？
客户没说话。我知道他在想。
于是我说出了这场会议最关键的一句话：
“坦率说，您的诉求，我不太建议用知识库方案来做。”
空气瞬间安静了。
实话说，这句话说出口前，我心里也在打鼓。客户花了三五年攒下来的这些文档，我一句话让他别做了，他会不会觉得我这顾问不专业，水平不行？
但无论如何，这问题得有人指出来。
四个”劝退理由”
接下来我花了差不多二十分钟，给客户讲了四个劝退理由。
理由一：知识库没人维护，项目必死。
这是我一直反复强调的点：
“如果没人维护知识域，谁来确保答案的准确性？”
企业知识库不是建完就完了。文档更新、分类调整、回答质量纠偏——每件事都要专人跟进。这些事对不齐，最后做出来的助手，员工问得越多、错得越多。
组织上的支持，一定要比技术落地先行。
理由二：模型幻觉没人兜底，项目必跑偏
“内容通过大模型做润色整理和输出，绝对会有幻觉，避免不了。”
然后我抛了个灵魂拷问：“万一员工问历史案例，返回的数据错了，或者某个关键方法论它解释偏了，谁来对这个结果负责？”
当然，技术上可以用提示词约束强制引用来源，很多知识库工具也提供溯源能力，能把幻觉率降下来。但在企业场景里，如果组织层面没人兜底，一条被当成正确答案的错误方法论，代价可能是一整个项目方向跑偏。
理由三：没人给知识建模，项目必不准
“量级越大的知识库，在检索时越可能会找不准。”
做知识库项目，为确保准确度，一般要把内容做严格的分层分级。几万份文档，库要分好几层，每个文档都要打标签做精准过滤。体量越大、分片越碎，检索越容易串——这时候你连问题出在“源文件、解析、标签还是检索”都很难判断。
而且，如果用户问“订酒店的订单转化策略，过去在哪些项目里用过、哪个效果最好”，系统不仅要找到文档，还要关联“项目”、“转化策略”、“业务场景”、“结果指标”和“信息来源”——这已经超出向量检索的能力，需要引入知识图谱。但图谱也不能自动判断哪个项目效果最好，指标口径、对比基准、统计周期，还得业务统一定义。
更现实的是：四五万份晋升复盘，是几千个不同的人写的。他们写的时候就没想过“我的内容要被AI检索调用”——那是为晋升答辩写的，不是为知识库写的。没有统一口径做治理，AI拿什么给你做标准答案？
理由四：没有高频使用的场景，项目上线必闲置。
这是我过去做知识库项目踩过的最大的坑。很多项目花了大量精力搭起来，上线之后一个月访问一两次，团队自己也说不清当初的预期是什么。
“我们可能在初期就没想清楚到底谁会去用，谁会去高频地用。最后做出来的东西没人用，这个项目就没必要投入这么大的精力。”
一个好信号：问题开始从全公司收敛到某个人群
听完我的理由，客户沉默了几秒，说了让我觉得这会没白开的三句话：
第一句：
“确实申老师分享了这些东西之后，我好像也要对我们做这件事的目的，去做进一步澄清和讨论。”
第二句：
“要把这些文档丢给AI，然后AI再去跑，再满足员工的问答，我也觉得这事不现实。”
第三句，他开始主动提出更聚焦的方案：
“如果说我们只是针对某一个人群，比如说某一个岗位人群……这个部分的操作难度会不会更小一些？”
从“全公司所有员工”收敛到“某一类人群”，从“5万份文档全丢进去”到“先聚焦某个可控场景”——这一个小时的成果，体现在了客户最终的这三句话里。
FDE在需求沟通阶段最核心的产出，不是给方案，是帮对方把真问题找出来。
站在客户的视角，他更关注的是卡点怎么解。但我会帮他看清楚：该不该做、为谁做，以及做到什么程度算有用。
不能只说”不行”，还要说”怎么行”
当然，否定完客户的方向，不能就拍拍屁股走人。会上我给了他们三条替代路径：
第一条，自底向上重新做知识审计。
先把四五万份文档做一轮分类盘点，看看这些文档能分成哪些类型，哪些是项目复盘，哪些是最佳实践，哪些属于公共资料，哪些受业务权限限制。分完后，再看每类内容可能对谁有用。
第二条，自顶向下做需求调研。
找几类可能的用户，问问他们做项目时会不会主动找历史材料？通常去哪里找？找不到时问谁？哪些任务经常重复？哪些信息每次都要重新搜？
调研结果出来的优先级，可能跟之前想象的完全不一样。不要被现有的资源绑架了应该做什么。
第三条，和公司战略对齐。
今年的战略目标里，最重要的业务方向是什么？哪些跟知识资产积累相关？哪些能力值得被优先复制？
员工很想要的东西，未必值得公司投入。公司着急推动的事情，现有资料也未必能支持。三边能接上的地方，才有机会做成第一批场景。
再加上一个核心原则：聚焦一个足够小的场景，先跑通，再扩散。 哪怕是”员工晋升助手”一个单一功能，只要能证明有人高频在用、效果可衡量，就比一个大而全但没人用的知识库有价值10倍。
会议最后，方向清楚多了
客户自己也意识到，也许可以先聚焦员工入职后三到六个月的成长。这个阶段的人群明确，学习内容相对集中，效果也容易观察。或者先选某个重要岗位，工作流程清楚、知识密集、存在高频重复任务，先找出AI适合介入的环节，再决定需要什么知识。
这个方向就清楚多了。
尽管很遗憾，会上没定下最终方案，对方说要回去讨论，先把自己想要的东西弄清楚。
但我倒觉得这一个小时没白聊。帮客户看清一个不该做的方向，是FDE的另一面：在需求沟通阶段，敢于做出”不可行”的判断。
FDE需求诊断三件事
会后，我把这场沟通里最核心的判断逻辑，提炼成了三个问题：
第一问：谁会每天用？
不能只是“我想给人用”，而是“有人不用这个就没法干活儿”。如果回答不出来，说明需求还没成立。
第二问：谁负责维护？
知识库不是建完就完了。文档更新、答案校对、效果调优，必须有人专职做。没有人维护的知识库，上线之日就是死亡倒计时的开始。
第三问：先跑通哪一块？
选最小场景，一个月内能上线、验证、迭代。别一上来就想做个通用企业知识大脑——那是愿景，不是项目。
这三个问题，本质上都是把视角从“AI能做什么”，转向“我们需要什么。”
网上很多FDE的文章，都在讲选什么模型、用Codex还是WorkBuddy，也会讲怎么写Skill、搭工作流、手搓智能体，但那些只是FDE做执行的一面。而识别什么问题是真问题，洞察到客户需求的本质，从而找到更优的解决思路，这项能力才是FDE区别于驻场外包的关键一环，也是AI最替代不了的部分。
如果你也在评估知识库项目，可以先拿这三问自测：
- 你团队里，谁会每天打开它？答不上来，先别做。
- 文档更新和答案校对，谁负责？没人，先别做。
- 最小场景是什么？一个月内能不能上线验证？不能，先别做。
本文由人人都是产品经理作者【申悦】，微信公众号：【互联网悦读笔记】，原创/授权 发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议
