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