开头先交代一下背景。这几年我以FDE功能落地工程师的身份参与了十多个和AI相关的项目最深的感受是团队里最不缺的是“我们要用AI做点啥”的冲动最缺的是一个冷静的人在动手前先问一句“这个需求是真的吗”。FDE这个岗位很多人以为是高级开发或者架构师其实不是。它的核心职责是把一个模糊的想法翻译成具体可交付的功能并负责它真正跑起来。你可以把它理解成“需求到功能之间的桥梁”桥梁一头是业务方另一头是技术团队。而AI项目的特殊性在于技术本身自带光环很容易让所有人都忽略桥梁地基是否牢固。这篇实战记录就是讲我在FDE落地过程中总结的一套需求判断方法。它适合三类人看一类是刚转型FDE、每天被各种AI需求淹没的开发一类是准备用AI做产品但还没想清楚场景的产品经理还有一类是技术负责人想搞清楚团队为什么总在“做一个没人用的AI功能”。文章不聊算法不聊提示词技巧只聊一件事在投入资源之前如何识别真需求和伪需求。1. 为什么FDE的第一课不是写代码而是判断需求很多刚入行的FDE以为这个岗位的关键是技术广度前端后端都要懂AI也要懂。我刚开始也这么想拼命补技术短板结果发现真正让我栽跟头的从来不是技术实现不了而是做出来的东西根本没人用。1.1 FDE的本质是“功能落地工程师”不是“技术专家”先把这个岗位说清楚。FDE在不同的公司叫法可能不同有的叫交付工程师有的叫全栈工程师有的干脆叫“技术产品经理”。但工作内容高度相似你要对业务目标负责而不是对代码质量负责。举个例子业务方说“我们要做个AI客服”传统开发会问“用什么模型、怎么部署、响应时间多少”FDE会先问“用户现在遇到什么问题为什么要用AI客服来解决”。这两种提问方式决定了项目结局完全不同。我不是说技术不重要。FDE当然要懂技术否则没办法评估可行性、没办法拆解任务。但技术是工具需求判断才是方向盘。方向盘偏了发动机再强车也是往沟里开。1.2 AI项目为什么最容易做出伪需求AI是典型的“技术拉动型”领域它天然带着一种“先进感”很容易让人产生“不用AI就落后了”的焦虑。这种焦虑会直接传染给需求侧于是出现了大量为了AI而AI的需求。我接触过的伪需求典型的有这几种老板在行业大会上听了某个概念回来要求团队“也要做一个”产品经理看到竞品上线了AI功能怕被比下去赶紧跟进一个技术团队觉得某个模型很酷想拿真实业务练手。这些需求的共同点是出发点不是用户问题而是“别人有我也要有”或者“这东西很酷我想试试”。再加上互联网热词里有大量“AI无禁词聊天”“无限制AI生成视频”“AI同人”这类流量型产品很多需求方被这些词刺激得跃跃欲试以为AI的落地就是套个壳、接个接口、发个网页。真正做过的人才知道这种思路做出来的东西大概率上线即死亡。1.3 判断需求本质上是“勘探地基”我经常打一个比方做功能就像盖房子需求判断就是地质勘探。地质没探清楚房子盖得越快塌得越快。AI项目尤其如此因为它前期投入大、周期长、效果不确定一旦需求判断出错沉没成本远超普通功能。有一次我接手一个AI项目需求文档写了四十多页各种功能模块规划得满满当当。结果我花了两周时间做用户访谈发现文档里描述的核心场景目标用户根本不存在。需求方只是凭想象写了一份“看起来合理”的方案。如果当时直接开干至少浪费团队三个月时间。所以我的工作习惯是接到任何需求先不讨论怎么做先讨论“这个需求值不值得做”。这一步做完后面所有事情都会顺很多。2. 用一张评估表把“感觉有需求”变成“数据上可验证”判断需求这件事听起来很虚好像全靠经验。我刚开始也是这样凭感觉跟业务方聊觉得“这个场景好像挺真实”就接了。结果被坑了几次之后我总结出一套结构化的评估方法你不需要多高深的调研能力只要老老实实回答几个问题就能过滤掉大部分伪需求。2.1 六个维度从“感觉”到“验证”的关键指标我自己总结的判断框架一共六个维度。每个维度解决一个核心问题合在一起基本能覆盖一个需求从“动机”到“持续价值”的全链路。第一个维度是需求来源。你要搞清楚这个需求是从哪里冒出来的是一线用户反馈还是管理层拍脑袋还是竞品分析得来的。来源决定需求的初始可信度一线反馈通常比高管转述更接近真实场景。第二个维度是使用场景。用户是在什么情况下需要这个功能是每天固定使用还是偶尔想起来才用。场景越具体、越高频需求越可能是真的。泛泛的“用户需要更智能的体验”这种描述在我这里直接打回。第三个维度是痛点强度。这个需求对应的用户痛点到底有多痛是“没有它也能过”还是“没有它工作完全进行不下去”。痛的程度直接决定了用户会不会真的使用你的方案。第四个维度是使用频率。一个功能如果用户一年只用一次就算它解决了问题也很难沉淀价值。我之前做过一个票据识别AI技术效果不错但用户每月只用两三次最后活跃数据非常难看。第五个维度是替代方案。你要问自己用户现在是怎么解决这个问题的。如果用户已经有了一套成熟的替代方案哪怕那个方案很笨你的AI功能也必须比它好用十倍用户才可能切换。第六个维度是付费或留存意愿。内部工具看留存商业产品看付费。用户愿意付钱或者愿意持续回来用才是需求成立的最终证明。2.2 判断需求时可参考的提问清单我每次做需求访谈都会准备好一份问题清单。这份清单不是拿给用户填的而是引导我自己去查证。问题分成六组对应上面说的六个维度。需求来源要查证的是谁提出的需求他基于什么数据或观察有没有原始用户反馈可以追溯。使用场景要查证的是用户会在什么时间、什么地点、什么状态下用这个功能你能不能用一句话描述清楚他的操作路径。痛点强度要查证的是不解决这个痛点用户会损失什么损失有多大这个损失是不是用户自己承认的。使用频率要查证的是用户平均多久遇到一次这个问题是每天都遇到还是一周一次还是一年一次。替代方案要查证的是用户现在用什么方法应对这个方法有哪些不足用户对它的不满程度如何。付费留存要查证的是如果这个功能收费用户认为值多少钱或者如果免费用户下次还会不会主动打开。这六组问题全部问完你对这个需求的判断基本就不会偏离太多。2.3 评估表使用方法和一票否决项光有问题清单还不够我还会给每个维度打分。1分到5分1分是“完全不成立”5分是“证据充分”。总分在24分以上属于高置信度需求可以进入设计阶段18到24分属于中等置信度需要补充验证低于18分建议直接放弃或者重新定义问题。打分的过程中有几个一票否决项只要命中任意一个不管总分多高我都会建议项目暂停。第一个是需求方说不清楚目标用户是谁所有描述都是“大家”“用户们”“很多人”第二个是使用场景无法在现实中复现你让需求方演示一下用户操作流程他演示不出来第三个是已有替代方案并不差用户没有理由迁移第四个是技术上完全依赖第三方黑盒连基础的数据边界都说不清楚。这套评估表不是万能的但它能逼着所有人在“哇这个AI功能好酷”的兴奋感消退之后冷静地回答一些最基础但最关键的问题。3. 两个真实案例同样喊“AI赋能”一个真需求一个伪需求纸上谈兵没有说服力我挑两个实际接触过的项目案例完整走一遍评估流程。这两个项目都挂着“AI赋能”的名头但一个被我判断为伪需求建议砍掉一个被认为是真需求最后做成了。区别在哪里看细节就明白了。3.1 案例AAI智能客服看着像真需求实际是伪需求这个项目是某公司内部IT支持部门提的。他们的诉求是员工报修IT问题太多客服响应不过来想用AI做一个智能客服自动回答常见问题减少人工压力。听起来很合理对不对我一开始也觉得这是典型的高频刚需场景。但评估表走完一遍问题就出来了。需求来源是部门主管他告诉我的数据是“每月收到上千条报修工单”。可是当我追问“这上千条工单里有多少是重复的标准化问题有多少是长尾个性化问题”他答不上来。使用场景也很模糊员工报修通常是通过企业IM直接找IT属于“有问题随手发消息”而不是专门打开一个客服页面去搜索答案。真正的致命伤是替代方案。员工现在遇到IT问题最直接的做法是问旁边同事同事不会就找IT。这个链条虽然笨但已经沉淀了多年员工形成了惯性。AI客服要改变这个习惯必须比“问同事”更快更准而当时内网知识库本身就很混乱AI答非所问的概率很高。最后我一票否决了这个需求理由就是替代方案不差、迁移成本高。这个决策当时顶着不小的压力因为IT主管已经跟领导汇报过“要用AI提升服务质量”。但三个月后隔壁团队还是硬着头皮做了个类似的AI客服上线后的数据和我预料的差不多使用率极低大部分员工还是选择直接找人。3.2 案例B内部文档问答机器人一开始被质疑最后是真需求另一个案例是面向研发团队的内部文档问答机器人。需求来源很朴素是几位一线工程师在周会上吐槽公司内部文档太多了散落在好几个平台上查东西经常要开四五个网页搜到了还不一定是最新版。我听到这个反馈的时候第一反应是这个场景太“小而美”了做成AI功能是不是有点大材小用。但评估表走完结论完全不一样。需求来源是一线使用者而且不止一个人在吐槽是多人自发提出的痛点。使用场景非常具体工程师写代码遇到问题先搜内部文档搜不到再问同事这个流程几乎每天都会发生。替代方案的反而是它的优势。现有的全文检索系统确实难用大家已经在忍受它了只要新方案检索准确率明显更好就很值得尝试。至于留存意愿研发场景下工具好不好用会直接在效率上体现出来用得好自然留得住。这个项目后来做了一个相对轻量的MVP只接入了研发最常用的两个知识库用向量检索加RAG的方式搭建。上线后两周日活跃用户就覆盖了超过六成研发人员。到第二个月已经有工程师主动在里面维护新的文档了形成了一个正向循环。3.3 两个案例对比同一个AI技术差异在需求侧这两个案例放在一起看很有意思。同样是AI能力同样是解决内部知识相关问题为什么一个失败一个成功区别就在于需求侧的证据链是否完整。AI客服那个案例痛点听起来很大但需求来源单一、场景不聚焦、替代方案牢固、用户没有表达过强烈不满。AI文档问答这个案例需求来源是一线自发的抱怨场景每天高频出现替代方案确实难用用户在主动期待新工具。我把这两个案例做成过一张对比表核心差异就两个需求是不是用户自己提出来的以及现有方案是不是真的烂到让人受不了。这两个问题问清楚AI项目至少能避开一半的坑。4. 判断完需求之后FDE还得做的几件事判断需求不是终点它只是第一步。确认了一个需求是真实的接下来还有一堆活儿要干而且这些活儿不像写代码那样有明确标准答案比的是沟通能力、拆解能力和推动能力。4.1 需求访谈要问对话不要问“要不要AI”我见过很多FDE和产品经理做访谈开口就是“你觉得AI帮你解决这个问题怎么样”用户碍于面子一般都会说“挺好的”。这种访谈得到的信息基本等于零。正确的问法是聊过程不聊解决方案。你要问用户平时是怎么做这件事的做到哪一步最烦烦的时候有没有试过其他办法最后是怎么忍下来的。把用户的工作流完整还原出来AI应该插在哪一环你心里就有数了。比如那个AI文档问答项目我访谈工程师的时候从来没问过“你想要AI搜索吗”我问的是“你上一次查不到文档是什么时候当时你做了什么”。答案五花八门有人说去问同事有人说干脆凭记忆写代码有人说换个关键词再搜。正是这些回答拼出了真实场景。4.2 最小验证法不写代码也能验证需求很多人觉得验证需求一定要做原型、做MVP其实不是。有些需求用一张表格、一个群、一段人工服务就能验证。我常用的方法是“人工模拟AI”。如果需求方说要做一个AI简历筛选工具那我先不写任何算法直接让人力同事每天手动按照预设规则筛五十份简历记录下耗时和准确率。如果人工模拟之后发现这个流程本身就没有被抱怨或者筛选结果根本就不被认可那AI化了也没用。这种验证方式成本极低但能暴露大量问题。至少比团队花一个月做完功能上线才发现没人用要划算得多。4.3 定MVP边界先做一个“很笨但能用”的版本确认需求真实之后FDE的第二个任务是控制第一个版本的规模。我见过太多项目死在“首版就想做一个完整的平台”上AI项目尤其容易犯这个毛病因为技术可能性太多了。我的原则是MVP只要能解决核心场景最痛的那一个点就够了。其他一切功能包括花哨的交互、报表、权限系统都往后放。那个AI文档问答机器人第一个版本只接入了两个知识库不支持对话追问也不显示引用来源连界面都极其朴素就是一个搜索框加答案列表。但核心的“快速找到准确文档”这个点是成立的。这个“笨版本”上线后用户虽然会吐槽界面简陋但他们会主动告诉你最需要加什么。这时候你再迭代方向就不会偏。4.4 和需求方对齐结论型汇报比过程型汇报更有效FDE经常要面对需求方的临时反馈。我发现最有用的沟通方式是每次调研或验证结束后输出一份很短的结论型汇报而不是长篇大论讲过程。结论型汇报的结构就三部分验证了什么问题、数据或证据是什么、建议下一步做什么。这样需求方不需要跟你纠结调研细节直接基于结论做决策就行。同时所有关键决策都要留档哪怕是聊天记录里的一句“确认首版不做多轮对话”也要截图保存。这个习惯能救你很多次。项目做了一半需求方突然说“这个功能当初不是这么定的”你能拿出证据来避免陷入无休止的扯皮。5. 三种经常把FDE带沟里的误判附排查清单即使有了评估表实战中还是会遇到一些迷惑性很强的误判。我把这些年踩过的坑和见过别人踩的坑总结成三种典型误判建议收藏下来每次接新需求之前对照排查一遍。5.1 把“技术有趣”当成“用户刚需”这个误判最容易出现在技术团队主导的项目里。模型能力很强生成效果惊艳开发兴奋得不行觉得用户肯定会爱不释手。但等真上线了用户冷冰冰地说一句“这功能是挺好玩但我用不上”直接浇一盆冷水。我见过团队花很大力气做一个AI写诗功能技术效果确实好什么藏头诗、五言律诗都能写。但产品里没有任何一个真实场景需要用户每天来写诗上线后自然沦为炫技页面。排查方法很简单强制团队回答这个功能解决的用户问题是什么如果回答是“让用户觉得科技感强”那基本就是伪需求。5.2 把“少数人的强需求”当成“多数人的普遍需求”做AI项目容易遇到一种情况有几位用户对某个功能赞不绝口热情非常高于是团队以为找到了金矿。但仔细算一下这几个人根本没法代表目标用户群。我自己栽过这个跟头。给一个数据平台做AI数据分析功能时有位资深数据分析师反馈特别积极说这个功能省了他很多时间。我们信了他的话大力推进这个方向。结果后来一看使用数据活跃用户里90%都是他一个人带来的测试量其他用户几乎不碰这个功能。原因很简单那个资深分析师的能力很强他能用AI做到的事情普通用户根本复制不了。解决方案是夸你的人你要看他的能力和使用条件跟目标用户是否一致。不能拿个例当普例。5.3 把“短期尝鲜”当成“长期留存”AI功能天然有新鲜感。上线第一周好奇心驱动的用户会涌进来体验数据好看得惊人。但如果需求不是真实的长期需求两周后曲线就会断崖式下跌。判断方法是盯留存不看新增。上线首月每周末都要看一遍次周留存率。如果第二周留存率不足第一周的百分之三十这个功能大概率是尝鲜型需求用户只是来逛了一圈没有形成使用习惯。我之前做一个AI聊天功能的Mini项目首周数据很漂亮我当时还有点后悔没多投点资源。结果第三周开始日活直接跌到原来的十分之一。复盘的时候才发现那个功能属于“偶尔用一次会觉得很新奇但日常完全想不到打开的类型”。这种情况数据比你的直觉诚实得多。5.4 排查清单接需求之前过一遍这几条是我整理的需求排查清单每次接新需求我都会对照着过一遍。需求是不是来自真实用户的自发反馈还是管理层转述、竞品压出来的。用户使用场景是否具体到可以拍成一段视频演示。这个问题用户现在怎么解决的解决得有多痛苦。用户遇到的频率是高是低是每天、每周还是每月。用户本人是否明确表达过改变现状的意愿。这个需求上线后团队通过什么指标判断成功。如果这六条里有三条以上回答不清楚我会主动要求延期启动先补调研而不是硬着头皮开工。磨刀不误砍柴工这句话在AI项目里比什么都重要。做FDE这几年我最大的体会是AI落地最难的部分从来不是技术选型也不是模型调优而是“做这个东西之前有没有想清楚它该不该做”。现在技术圈每天都有新模型发布隔几天就冒出个新玩法一不留神就被带着走。但用户不会因为你的功能用了最新的模型就多看你一眼他们只关心自己遇到的问题有没有被更快更好地解决。判断真需求就是帮你把精力拧到用户真正在意的方向上去。回到开头那句话别急着做AI。先把是不是真需求这件事弄清楚你再决定要不要做、怎么做、做多大。如果看完这篇笔记你在接到下一个“AI赋能一下”的需求时能多问一句“用户为什么要用”那这三千字就没白写。 
长河君 · 2026/9/8 17:10:51 · 阅读 1.2k AI项目落地前，FDE如何识别真需求与伪需求？
开头先交代一下背景。这几年我以FDE功能落地工程师的身份参与了十多个和AI相关的项目最深的感受是团队里最不缺的是“我们要用AI做点啥”的冲动最缺的是一个冷静的人在动手前先问一句“这个需求是真的吗”。FDE这个岗位很多人以为是高级开发或者架构师其实不是。它的核心职责是把一个模糊的想法翻译成具体可交付的功能并负责它真正跑起来。你可以把它理解成“需求到功能之间的桥梁”桥梁一头是业务方另一头是技术团队。而AI项目的特殊性在于技术本身自带光环很容易让所有人都忽略桥梁地基是否牢固。这篇实战记录就是讲我在FDE落地过程中总结的一套需求判断方法。它适合三类人看一类是刚转型FDE、每天被各种AI需求淹没的开发一类是准备用AI做产品但还没想清楚场景的产品经理还有一类是技术负责人想搞清楚团队为什么总在“做一个没人用的AI功能”。文章不聊算法不聊提示词技巧只聊一件事在投入资源之前如何识别真需求和伪需求。1. 为什么FDE的第一课不是写代码而是判断需求很多刚入行的FDE以为这个岗位的关键是技术广度前端后端都要懂AI也要懂。我刚开始也这么想拼命补技术短板结果发现真正让我栽跟头的从来不是技术实现不了而是做出来的东西根本没人用。1.1 FDE的本质是“功能落地工程师”不是“技术专家”先把这个岗位说清楚。FDE在不同的公司叫法可能不同有的叫交付工程师有的叫全栈工程师有的干脆叫“技术产品经理”。但工作内容高度相似你要对业务目标负责而不是对代码质量负责。举个例子业务方说“我们要做个AI客服”传统开发会问“用什么模型、怎么部署、响应时间多少”FDE会先问“用户现在遇到什么问题为什么要用AI客服来解决”。这两种提问方式决定了项目结局完全不同。我不是说技术不重要。FDE当然要懂技术否则没办法评估可行性、没办法拆解任务。但技术是工具需求判断才是方向盘。方向盘偏了发动机再强车也是往沟里开。1.2 AI项目为什么最容易做出伪需求AI是典型的“技术拉动型”领域它天然带着一种“先进感”很容易让人产生“不用AI就落后了”的焦虑。这种焦虑会直接传染给需求侧于是出现了大量为了AI而AI的需求。我接触过的伪需求典型的有这几种老板在行业大会上听了某个概念回来要求团队“也要做一个”产品经理看到竞品上线了AI功能怕被比下去赶紧跟进一个技术团队觉得某个模型很酷想拿真实业务练手。这些需求的共同点是出发点不是用户问题而是“别人有我也要有”或者“这东西很酷我想试试”。再加上互联网热词里有大量“AI无禁词聊天”“无限制AI生成视频”“AI同人”这类流量型产品很多需求方被这些词刺激得跃跃欲试以为AI的落地就是套个壳、接个接口、发个网页。真正做过的人才知道这种思路做出来的东西大概率上线即死亡。1.3 判断需求本质上是“勘探地基”我经常打一个比方做功能就像盖房子需求判断就是地质勘探。地质没探清楚房子盖得越快塌得越快。AI项目尤其如此因为它前期投入大、周期长、效果不确定一旦需求判断出错沉没成本远超普通功能。有一次我接手一个AI项目需求文档写了四十多页各种功能模块规划得满满当当。结果我花了两周时间做用户访谈发现文档里描述的核心场景目标用户根本不存在。需求方只是凭想象写了一份“看起来合理”的方案。如果当时直接开干至少浪费团队三个月时间。所以我的工作习惯是接到任何需求先不讨论怎么做先讨论“这个需求值不值得做”。这一步做完后面所有事情都会顺很多。2. 用一张评估表把“感觉有需求”变成“数据上可验证”判断需求这件事听起来很虚好像全靠经验。我刚开始也是这样凭感觉跟业务方聊觉得“这个场景好像挺真实”就接了。结果被坑了几次之后我总结出一套结构化的评估方法你不需要多高深的调研能力只要老老实实回答几个问题就能过滤掉大部分伪需求。2.1 六个维度从“感觉”到“验证”的关键指标我自己总结的判断框架一共六个维度。每个维度解决一个核心问题合在一起基本能覆盖一个需求从“动机”到“持续价值”的全链路。第一个维度是需求来源。你要搞清楚这个需求是从哪里冒出来的是一线用户反馈还是管理层拍脑袋还是竞品分析得来的。来源决定需求的初始可信度一线反馈通常比高管转述更接近真实场景。第二个维度是使用场景。用户是在什么情况下需要这个功能是每天固定使用还是偶尔想起来才用。场景越具体、越高频需求越可能是真的。泛泛的“用户需要更智能的体验”这种描述在我这里直接打回。第三个维度是痛点强度。这个需求对应的用户痛点到底有多痛是“没有它也能过”还是“没有它工作完全进行不下去”。痛的程度直接决定了用户会不会真的使用你的方案。第四个维度是使用频率。一个功能如果用户一年只用一次就算它解决了问题也很难沉淀价值。我之前做过一个票据识别AI技术效果不错但用户每月只用两三次最后活跃数据非常难看。第五个维度是替代方案。你要问自己用户现在是怎么解决这个问题的。如果用户已经有了一套成熟的替代方案哪怕那个方案很笨你的AI功能也必须比它好用十倍用户才可能切换。第六个维度是付费或留存意愿。内部工具看留存商业产品看付费。用户愿意付钱或者愿意持续回来用才是需求成立的最终证明。2.2 判断需求时可参考的提问清单我每次做需求访谈都会准备好一份问题清单。这份清单不是拿给用户填的而是引导我自己去查证。问题分成六组对应上面说的六个维度。需求来源要查证的是谁提出的需求他基于什么数据或观察有没有原始用户反馈可以追溯。使用场景要查证的是用户会在什么时间、什么地点、什么状态下用这个功能你能不能用一句话描述清楚他的操作路径。痛点强度要查证的是不解决这个痛点用户会损失什么损失有多大这个损失是不是用户自己承认的。使用频率要查证的是用户平均多久遇到一次这个问题是每天都遇到还是一周一次还是一年一次。替代方案要查证的是用户现在用什么方法应对这个方法有哪些不足用户对它的不满程度如何。付费留存要查证的是如果这个功能收费用户认为值多少钱或者如果免费用户下次还会不会主动打开。这六组问题全部问完你对这个需求的判断基本就不会偏离太多。2.3 评估表使用方法和一票否决项光有问题清单还不够我还会给每个维度打分。1分到5分1分是“完全不成立”5分是“证据充分”。总分在24分以上属于高置信度需求可以进入设计阶段18到24分属于中等置信度需要补充验证低于18分建议直接放弃或者重新定义问题。打分的过程中有几个一票否决项只要命中任意一个不管总分多高我都会建议项目暂停。第一个是需求方说不清楚目标用户是谁所有描述都是“大家”“用户们”“很多人”第二个是使用场景无法在现实中复现你让需求方演示一下用户操作流程他演示不出来第三个是已有替代方案并不差用户没有理由迁移第四个是技术上完全依赖第三方黑盒连基础的数据边界都说不清楚。这套评估表不是万能的但它能逼着所有人在“哇这个AI功能好酷”的兴奋感消退之后冷静地回答一些最基础但最关键的问题。3. 两个真实案例同样喊“AI赋能”一个真需求一个伪需求纸上谈兵没有说服力我挑两个实际接触过的项目案例完整走一遍评估流程。这两个项目都挂着“AI赋能”的名头但一个被我判断为伪需求建议砍掉一个被认为是真需求最后做成了。区别在哪里看细节就明白了。3.1 案例AAI智能客服看着像真需求实际是伪需求这个项目是某公司内部IT支持部门提的。他们的诉求是员工报修IT问题太多客服响应不过来想用AI做一个智能客服自动回答常见问题减少人工压力。听起来很合理对不对我一开始也觉得这是典型的高频刚需场景。但评估表走完一遍问题就出来了。需求来源是部门主管他告诉我的数据是“每月收到上千条报修工单”。可是当我追问“这上千条工单里有多少是重复的标准化问题有多少是长尾个性化问题”他答不上来。使用场景也很模糊员工报修通常是通过企业IM直接找IT属于“有问题随手发消息”而不是专门打开一个客服页面去搜索答案。真正的致命伤是替代方案。员工现在遇到IT问题最直接的做法是问旁边同事同事不会就找IT。这个链条虽然笨但已经沉淀了多年员工形成了惯性。AI客服要改变这个习惯必须比“问同事”更快更准而当时内网知识库本身就很混乱AI答非所问的概率很高。最后我一票否决了这个需求理由就是替代方案不差、迁移成本高。这个决策当时顶着不小的压力因为IT主管已经跟领导汇报过“要用AI提升服务质量”。但三个月后隔壁团队还是硬着头皮做了个类似的AI客服上线后的数据和我预料的差不多使用率极低大部分员工还是选择直接找人。3.2 案例B内部文档问答机器人一开始被质疑最后是真需求另一个案例是面向研发团队的内部文档问答机器人。需求来源很朴素是几位一线工程师在周会上吐槽公司内部文档太多了散落在好几个平台上查东西经常要开四五个网页搜到了还不一定是最新版。我听到这个反馈的时候第一反应是这个场景太“小而美”了做成AI功能是不是有点大材小用。但评估表走完结论完全不一样。需求来源是一线使用者而且不止一个人在吐槽是多人自发提出的痛点。使用场景非常具体工程师写代码遇到问题先搜内部文档搜不到再问同事这个流程几乎每天都会发生。替代方案的反而是它的优势。现有的全文检索系统确实难用大家已经在忍受它了只要新方案检索准确率明显更好就很值得尝试。至于留存意愿研发场景下工具好不好用会直接在效率上体现出来用得好自然留得住。这个项目后来做了一个相对轻量的MVP只接入了研发最常用的两个知识库用向量检索加RAG的方式搭建。上线后两周日活跃用户就覆盖了超过六成研发人员。到第二个月已经有工程师主动在里面维护新的文档了形成了一个正向循环。3.3 两个案例对比同一个AI技术差异在需求侧这两个案例放在一起看很有意思。同样是AI能力同样是解决内部知识相关问题为什么一个失败一个成功区别就在于需求侧的证据链是否完整。AI客服那个案例痛点听起来很大但需求来源单一、场景不聚焦、替代方案牢固、用户没有表达过强烈不满。AI文档问答这个案例需求来源是一线自发的抱怨场景每天高频出现替代方案确实难用用户在主动期待新工具。我把这两个案例做成过一张对比表核心差异就两个需求是不是用户自己提出来的以及现有方案是不是真的烂到让人受不了。这两个问题问清楚AI项目至少能避开一半的坑。4. 判断完需求之后FDE还得做的几件事判断需求不是终点它只是第一步。确认了一个需求是真实的接下来还有一堆活儿要干而且这些活儿不像写代码那样有明确标准答案比的是沟通能力、拆解能力和推动能力。4.1 需求访谈要问对话不要问“要不要AI”我见过很多FDE和产品经理做访谈开口就是“你觉得AI帮你解决这个问题怎么样”用户碍于面子一般都会说“挺好的”。这种访谈得到的信息基本等于零。正确的问法是聊过程不聊解决方案。你要问用户平时是怎么做这件事的做到哪一步最烦烦的时候有没有试过其他办法最后是怎么忍下来的。把用户的工作流完整还原出来AI应该插在哪一环你心里就有数了。比如那个AI文档问答项目我访谈工程师的时候从来没问过“你想要AI搜索吗”我问的是“你上一次查不到文档是什么时候当时你做了什么”。答案五花八门有人说去问同事有人说干脆凭记忆写代码有人说换个关键词再搜。正是这些回答拼出了真实场景。4.2 最小验证法不写代码也能验证需求很多人觉得验证需求一定要做原型、做MVP其实不是。有些需求用一张表格、一个群、一段人工服务就能验证。我常用的方法是“人工模拟AI”。如果需求方说要做一个AI简历筛选工具那我先不写任何算法直接让人力同事每天手动按照预设规则筛五十份简历记录下耗时和准确率。如果人工模拟之后发现这个流程本身就没有被抱怨或者筛选结果根本就不被认可那AI化了也没用。这种验证方式成本极低但能暴露大量问题。至少比团队花一个月做完功能上线才发现没人用要划算得多。4.3 定MVP边界先做一个“很笨但能用”的版本确认需求真实之后FDE的第二个任务是控制第一个版本的规模。我见过太多项目死在“首版就想做一个完整的平台”上AI项目尤其容易犯这个毛病因为技术可能性太多了。我的原则是MVP只要能解决核心场景最痛的那一个点就够了。其他一切功能包括花哨的交互、报表、权限系统都往后放。那个AI文档问答机器人第一个版本只接入了两个知识库不支持对话追问也不显示引用来源连界面都极其朴素就是一个搜索框加答案列表。但核心的“快速找到准确文档”这个点是成立的。这个“笨版本”上线后用户虽然会吐槽界面简陋但他们会主动告诉你最需要加什么。这时候你再迭代方向就不会偏。4.4 和需求方对齐结论型汇报比过程型汇报更有效FDE经常要面对需求方的临时反馈。我发现最有用的沟通方式是每次调研或验证结束后输出一份很短的结论型汇报而不是长篇大论讲过程。结论型汇报的结构就三部分验证了什么问题、数据或证据是什么、建议下一步做什么。这样需求方不需要跟你纠结调研细节直接基于结论做决策就行。同时所有关键决策都要留档哪怕是聊天记录里的一句“确认首版不做多轮对话”也要截图保存。这个习惯能救你很多次。项目做了一半需求方突然说“这个功能当初不是这么定的”你能拿出证据来避免陷入无休止的扯皮。5. 三种经常把FDE带沟里的误判附排查清单即使有了评估表实战中还是会遇到一些迷惑性很强的误判。我把这些年踩过的坑和见过别人踩的坑总结成三种典型误判建议收藏下来每次接新需求之前对照排查一遍。5.1 把“技术有趣”当成“用户刚需”这个误判最容易出现在技术团队主导的项目里。模型能力很强生成效果惊艳开发兴奋得不行觉得用户肯定会爱不释手。但等真上线了用户冷冰冰地说一句“这功能是挺好玩但我用不上”直接浇一盆冷水。我见过团队花很大力气做一个AI写诗功能技术效果确实好什么藏头诗、五言律诗都能写。但产品里没有任何一个真实场景需要用户每天来写诗上线后自然沦为炫技页面。排查方法很简单强制团队回答这个功能解决的用户问题是什么如果回答是“让用户觉得科技感强”那基本就是伪需求。5.2 把“少数人的强需求”当成“多数人的普遍需求”做AI项目容易遇到一种情况有几位用户对某个功能赞不绝口热情非常高于是团队以为找到了金矿。但仔细算一下这几个人根本没法代表目标用户群。我自己栽过这个跟头。给一个数据平台做AI数据分析功能时有位资深数据分析师反馈特别积极说这个功能省了他很多时间。我们信了他的话大力推进这个方向。结果后来一看使用数据活跃用户里90%都是他一个人带来的测试量其他用户几乎不碰这个功能。原因很简单那个资深分析师的能力很强他能用AI做到的事情普通用户根本复制不了。解决方案是夸你的人你要看他的能力和使用条件跟目标用户是否一致。不能拿个例当普例。5.3 把“短期尝鲜”当成“长期留存”AI功能天然有新鲜感。上线第一周好奇心驱动的用户会涌进来体验数据好看得惊人。但如果需求不是真实的长期需求两周后曲线就会断崖式下跌。判断方法是盯留存不看新增。上线首月每周末都要看一遍次周留存率。如果第二周留存率不足第一周的百分之三十这个功能大概率是尝鲜型需求用户只是来逛了一圈没有形成使用习惯。我之前做一个AI聊天功能的Mini项目首周数据很漂亮我当时还有点后悔没多投点资源。结果第三周开始日活直接跌到原来的十分之一。复盘的时候才发现那个功能属于“偶尔用一次会觉得很新奇但日常完全想不到打开的类型”。这种情况数据比你的直觉诚实得多。5.4 排查清单接需求之前过一遍这几条是我整理的需求排查清单每次接新需求我都会对照着过一遍。需求是不是来自真实用户的自发反馈还是管理层转述、竞品压出来的。用户使用场景是否具体到可以拍成一段视频演示。这个问题用户现在怎么解决的解决得有多痛苦。用户遇到的频率是高是低是每天、每周还是每月。用户本人是否明确表达过改变现状的意愿。这个需求上线后团队通过什么指标判断成功。如果这六条里有三条以上回答不清楚我会主动要求延期启动先补调研而不是硬着头皮开工。磨刀不误砍柴工这句话在AI项目里比什么都重要。做FDE这几年我最大的体会是AI落地最难的部分从来不是技术选型也不是模型调优而是“做这个东西之前有没有想清楚它该不该做”。现在技术圈每天都有新模型发布隔几天就冒出个新玩法一不留神就被带着走。但用户不会因为你的功能用了最新的模型就多看你一眼他们只关心自己遇到的问题有没有被更快更好地解决。判断真需求就是帮你把精力拧到用户真正在意的方向上去。回到开头那句话别急着做AI。先把是不是真需求这件事弄清楚你再决定要不要做、怎么做、做多大。如果看完这篇笔记你在接到下一个“AI赋能一下”的需求时能多问一句“用户为什么要用”那这三千字就没白写。