开头先交代一下背景。这几年我以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 案例A：AI智能客服，看着像真需求，实际是伪需求
这个项目是某公司内部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赋能一下”的需求时，能多问一句“用户为什么要用”，那这三千字就没白写。
