做FDE项目规划的时候我发现团队里最容易出现的问题不是技术选型而是需求还没搞清楚代码和Agent框架就开始搭了。尤其是AI应用类的功能开发模型、Prompt、工具链都太容易让人兴奋一兴奋就容易忽略一个基本问题这个功能到底有没有人真的需要、真的会用、真的愿意为它付出成本。我写这篇“FDE落地实战”就是想把我们团队在项目里总结出来的一套需求判断方法分享出来第一篇专门聊怎么在动手前识别“真需求”。1. 别让AI的兴奋感替你做了产品决策1.1 FDE的起点是功能不是模型FDE这个角色很多人一听就以为是“专门调模型、写Agent”的工程师。但我做了几轮FDE项目之后最大的感受是FDE的“F”是Feature是功能不是Fast更不是Fancy。FDE的职责是把一个业务问题转化成可落地、可验证、可迭代的功能而AI只是实现这个功能的工具之一。甚至在某些场景里AI根本不该是第一选择传统规则就能解决硬套大模型反而把简单问题搞复杂了。这就像你要给家里装一盏灯电工师傅不会一上来就问你“要2000流明的还是3000流明的”他得先问“你是在走廊装还是书房装平时几点用有没有声控需求”灯的参数是后话场景和需求才是前提。FDE的思维方式也是这个道理先搞清楚功能要解决什么问题再谈用什么技术最后才是调参、选模型、搭流程。1.2 为什么FDE团队特别容易“先动手后动脑”我观察了很多团队也复盘过自己带过的项目发现FDE团队几乎天生就带着“先动手”的基因。原因有三条第一AI领域的信息密度太高。今天LangChain更新了明天AutoGPT出了新版本后天某个开源模型评测又刷榜了。这些信息会不断冲击你的焦虑感让你觉得“别人都在落地我还在分析需求是不是太慢了”。但说实话大部分被这种焦虑驱动出来的功能最后都死在了“没有用户用”上。第二AI功能的开发门槛确实变低了。以前做个OCR识别要调SDK、要处理图像预处理现在用多模态模型几行代码就能出来一个Demo。成本低了尝试的冲动就上来了大家都抱着“反正不贵先做出来看看”的心态。但你仔细算算一次完整的功能开发从设计到联调到回归测试人力成本和时间成本一点都不低。第三AI方案特别擅长制造“看起来很美”的感觉。随便想一个需求配上大模型的通用能力都能演示出一个让人眼前一亮的Demo。但Demo和产品之间差着十万八千里真实用户的输入千奇百怪业务场景里有很多边界情况产品的交互逻辑需要反复打磨。这些在一开始都会被“模型输出惊人”的兴奋感掩盖掉。1.3 我踩过的坑花了三周做一个没人用的功能说个我自己的案例。去年我们团队想做一个“会议纪要自动生成”的功能理由是市面上所有大模型聊天工具都能轻松总结会议内容技术上行得通Leader也觉得这是AI落地的典型场景。我们就花了两周多的时间接语音转写、设计Prompt模板、做结构化输出、搭了配套的编辑界面。结果内测的时候发现真正高频使用的人少得可怜。后来我们一个个去问目标用户得到的反馈非常扎心“我开完会自己要写待办你们的纪要确实写得好但我还得从里面把待办挑出来还不如我自己边听边记。”那一刻我才意识到我们把“AI能写纪要”当成了“用户需要纪要”这就是典型的伪需求——技术上完全成立业务上没人买单。这个项目最后被砍掉了但我一直留着它当反面教材AI能力越强越容易让团队跳过需求调研因为大脑会告诉你“这么强的东西用户怎么会不用呢”但事实是用户的使用行为从来不是由技术先进性驱动的而是由“解决我当下问题的效率”驱动的。2. 判断真需求先回答三个递进问题做FDE需求判断的时候我习惯用一个漏斗式的筛查框架。这个方法不是我的原创是综合了精益创业和用户调研的常用做法但我在FDE项目里做了适配。每次需求评审我先不聊技术方案只问三个问题能全过再进入设计阶段。2.1 这个问题是不是用户正在付费解决的问题第一个问题会过滤掉一大批“自嗨型”需求。什么是真需求我个人的理解是用户为了解决这个问题已经在付出某种成本了这个成本可以是钱、时间也可以是情绪。举个例子。“帮用户自动生成周报”这个功能你要判断它是不是真需求不用找人访谈先问一个问题你的目标用户现在写周报要花多长时间如果他说“我周五下午要花半小时整理”说明他确实在花时间解决这个问题需求是存在的只是效率不高。如果他说“我们不写周报”或者“周报就是随便复制粘贴一下”说明这个问题在当前场景里根本不存在你做出来的功能再智能也没有用武之地。这就是把“用户正在付出成本”作为第一道过滤器的原因。反过来说如果一个用户完全没有为这个问题花过任何成本那它大概率是低频的、非刚需的或者干脆只是个“痒点”。2.2 这个问题在用户心里到底排第几第二个问题解决的是优先级问题。用户花钱花时间解决的问题有很多比如“我背疼”“我写的代码有Bug”“我开会太多没时间写代码”这些全是真实需求但一个人能分配的资源是有限的他只会优先解决当下最痛的那一个。FDE做需求判断的时候不能只看“用户有没有在付出成本”要追问一句“它在你的待办清单里排第几”如果目标用户说“这个问题我想了一年了一直没时间弄”那说明它的优先级很低。就算你的AI功能能解决用户也不会立刻用起来因为他连原来的问题都没腾出时间来面对。我一般会把需求分成四个等级致命级不解决就无法正常工作生活用户每天都在忍高优先级用户有明显痛点正在寻找替代方案中等优先级用户有感知但还有更重要的事在前面低优先级用户会感叹“这个功能不错”但不会主动搜索做FDE项目至少要做到“高优先级”这个档次才值得启动。如果是中等优先级除非你的解决方案能顺手被用户获取否则别碰。2.3 AI带来的改变是“提升效率”还是“改变路径”第三个问题是我最近才补上的专门用来筛掉那些“看起来刚需但AI化后反而变鸡肋”的需求。有的需求确实是真需求但AI化之后并没有改善用户的核心链路只是在某个环节上加了个“AI Turbo”。我举个例子你就明白了。“生成一个会议邀请邮件”用户原来的路径是打开邮件客户端、新建邮件、想措辞、填写时间地点、发送。如果AI只是帮你把正文写好用户还是要打开邮件客户端、还是要填写时间地点那AI带来的改善是有限的属于“提升效率”而不是“改变路径”。但如果你的功能是自动扫描用户的日历和邮件上下文在合适的时间自动生成一封带完整会议信息、自动设置提醒的邮件邀请用户只需要确认发送这就是“改变路径”——用户的核心动作从“逐条编写”变成了“一键确认”。在需求判断阶段我强烈建议你画一条用户当前完成任务的路径再画一条AI介入后的路径对比一下用户需要付出的步骤数量、认知负担、等待时间有没有量级上的变化。如果只是从8步变6步这不是FDE项目的理想标的如果能从8步变2步才值得投入。2.4 一张打分表快速给需求定级为了把这三个问题落实给团队我做了一张很简单的打分表每次需求评审的时候逐项打分得分低于一定分数线就直接劝退判断维度打分标准参考分值痛点强度用户每周至少遇到3次每次都会感到困扰0~10付费信号用户为当前解法付费或明确表达付费意愿0~10优先等级在用户核心工作流中属于前三优先级0~10路径改变度AI介入后用户操作步骤减少50%以上0~10验证成本能否在2周内完成低成本验证0~10五个维度总分50分我一般要求不低于35分才准进入技术预研。这套打分表不追求绝对的客观它的价值在于逼着团队把模糊的直觉变成可讨论的条目把“我觉得这个需求靠谱”变成“用户每周遇到三次当前解法要花二十分钟AI能压缩到两分钟”。有了这些具体信息后面做技术方案才站得住脚。3. 一次完整的伪需求鉴别过程智能选题助手前两节讲的是框架这一节我把一个真实项目的判断过程完整拆开你可以对照着看这个框架是怎么用的。这是近期我们团队做的一个“AI智能选题助手”目标是帮内容创作者快速生成选题和写作大纲。3.1 需求提案听起来很诱人当时的需求提案是这么写的内容创作者每天都要为选题发愁市面上的热点工具只能看热度不能自动生成匹配账号定位的选题建议。我们的AI助手可以结合账号历史和热点话题每天推荐5个选题并附上切入角度和参考链接。提案里附带了一份竞品分析确实有同类型产品存在数据看起来还不错。团队里几个内容平台的运营朋友也说“选题是刚需我们每天开晨会就是在对选题”。一切看起来都很完美市场有需求、技术上用RAG加大模型完全可行、我们还能比竞品多做一层账号定位分析。3.2 访谈阶段发现的第一处裂缝按照流程我们没有直接立项先做了一轮用户调研访谈了12位内容创作者有全职博主也有MCN机构的内容编辑。访谈的第一个问题就是上一节说的“你现在的选题怎么确定”我们收集到的答案高度一致看自己的评论区粉丝反馈什么就写什么监控同行账号什么选题火就跟着做刷各平台热榜结合自己的领域找角度偶尔灵感爆发存一批备选标题随时取用有意思的是访谈中几乎没有一个人提到“用工具辅助选题”。当我们拿出市面上的热点工具问他们用过没有大多数人的反应是“看过但没有持续用”。问原因答案集中在三点“出来的东西太泛跟我的领域不匹配”“我还是要人工判断省不了多少时间”“每天多一步打开工具的操作就懒得用了”。这个反馈其实已经很接近真相了对内容创作者来说选题不是不懂“什么火”而是不知道“我该从哪个角度切”。前者是信息获取问题后者是经验判断问题。AI能给的是前者而用户真正需要的是后者。3.3 用两天搭了个“假功能”做验证访谈结束后团队内部出现了分歧。乐观派的观点是用户说得不一定对很多需求是潜意识里的他们自己没意识到而且竞品数据在涨说明市场在起来。悲观派则认为访谈样本量也不大不能因为几个人的话就否定需求。为了平息分歧我们决定做一个“假功能”验证——这是FDE项目里我很推荐的一种手法比做真正的Demo还省钱。我们给已有的创作者工具加了一个“AI智能选题”的入口用户点进去会看到一句“功能即将上线点击预约获取内测资格”然后就结束了。没有真正的AI只是一个意向收集页面。同时我们在目标用户社群里发了几条使用演示动图看起来运行正常实际上背后没有任何模型推理。我们想验证的就是一件事用户会为了选题推荐这个功能主动留下自己的联系方式吗3.4 验证数据给出的清晰结论跑了五天结果是入口曝光了三千多次最终留下内测预约的只有十几个人而且其中三分之二是我们的老用户纯粹是出于好奇点开的。这个数据基本宣告了这个需求在当下的优先级不够高至少没有高到用户愿意付出哪怕一步额外的操作成本。数据摆到会上团队很快就达成了共识不是所有痛点都值得立刻做成AI功能。选题确实是创作者的真实痛点但它被“看同行、翻评论”这些常规行为覆盖了用户没有认为自己需要一个新的工具。如果非要在这个方向做得先把“自动分析账号数据、给出个性化选题角度”这个核心功能做透而不是泛泛做一个“AI选题助手”。但那样的话项目范围就完全变了。3.5 伪需求鉴别给出的真正教训这个案例最好的地方在于它展示了一个典型的过程一个需求听起来很像真需求市场也验证过但最后被证明在我们能触达的场景里优先级偏低。这个结论不是靠猜也不是靠某一个人的权威而是通过一次几乎零成本的验证实验拿到的数据。我觉得这才是FDE做需求判断应该有的样子不用把需求判断想得太复杂——判断你不一定要一次到位做一个小切口实验得到一组数据再和团队对齐一次就足够了。真正的伪需求不会因为你的PPT写得好就变成真需求但一个真需求也不会因为一次不完美的验证就被埋没。4. 把“需求验证”做进FDE项目节奏里需求判断不是项目启动前做一次就结束的事情尤其对FDE来说AI功能的不确定性更高你可以在不同阶段用不同粒度的验证来持续确认。这一节分享一下我在项目里常用的三层验证节奏。4.1 预研期的“访谈验证”在项目还没正式排期的时候做大样本访谈不现实我习惯用10到15个深度采访来代替问卷。这个过程的目标不是证明需求存在而是挖掘用户的语言和场景。注意要听用户怎么描述他的问题是用“我想”“我需要”“如果能”这类假设句式还是用“每次”“经常”“不得不”这类描述事实的句式前者说明他想象不出解决方案后者说明他正在经历真实痛点。访谈的时候有一个特别容易犯的错提问者总想展示自己对AI的理解问“如果有个功能能用AI帮你做这件事你会用吗”这种问题得到的答案几乎永远是“会”因为用户在没有成本压力下总是友善的。我把这个叫作“客气陷阱”。正确的问法是“上次你遇到这个问题具体是怎么处理的花了多长时间”得到的是具体行为而不是意向表态。4.2 原型期的“行为验证”访谈通过后项目进入原型阶段这时候不要急着做全功能AI先做一个人工模拟的“幕后模式”来验证用户行为。什么意思呢就是用户看到的是一个AI功能在自动工作的界面实际背后是运营同学或开发同学在手动填结果。我做过一个合同条款审查的FDE项目初期就是用这个方式验证的。用户上传合同页面假装分析几秒返回的报告其实是我们预先手动写好的条款问题清单。结果用户反馈的“太准了”让我们迅速确认了需求同时也收集到了真实的审查维度。后来接入真正的模型只需要对应用户反馈过的流程来设计输出结构。这种验证方式的成本远低于开发一套完整Agent流程却能提前发现交互和输出上的核心问题。毕竟用户不会因为你背后用的是真模型还是人工给你不同的反馈他们在意的只是结果有没有用。4.3 上线期的“留存验证”功能开发完上线后需求判断还没结束。我见过太多团队上线后只看PV和调用次数觉得数字不错就宣布成功。但AI功能有个指标比首用更重要那就是“次周留存”——用户这周用了下周还会不会主动来用如果你做的功能需要用户每次手动打开并输入一堆上下文哪怕第一周因为新鲜感有不错的使用量第二周留存大概率断崖式下跌。这不是需求不存在而是功能太重了没有嵌入用户的惯常工作流。反过来如果留存能稳住说明用户把功能变成了习惯。在数据上我一般会给FDE项目定一个“次周留存不低于30%”的及格线低于它就说明需求判断和实际体验还有错位需要回头找原因。5. 在团队和组织里推动“先判断再动手”的沟通方法最后聊一个现实问题需求判断这套方法道理都对但在推进的时候经常碰壁。你可能已经被老板拍过桌子问“怎么还没开始做”或者被销售同事怼过“客户都要了你还说需求不明确”。我经历了这些之后总结出几个有效的话术和操作方式。5.1 面对“别管那么多先做出来看看”的声音这种声音在组织里太常见了尤其是有客户表态“我们会用”的时候。但是根据我的经验客户说的“会用”和产品真正上线后的大规模使用之间隔着一条鸿沟。跟客户聊的时候他不用承担开发成本自然很容易说“好的好的这个有用”。我在这种时候会换个方式继续推动调研不是否定需求而是提出“缩小第一期的范围”。我会说“太好了既然客户需求明确我们能不能先选定一个最核心的场景做落地比如只覆盖某一种类型的合同我们两周内出一个定向的版本给客户试用拿到反馈再扩。”这个说法比“我建议我们先做需求调研”更容易被接受因为它看起来不是拖延而是敏捷。5.2 面对“AI什么都能做”的技术乐观主义团队里有技术热情的成员是好事但要警惕技术乐观主义裹挟需求判断。我见过不少工程师小伙伴特别想用最新框架、最新模型甚至主动提出“这个需求我们用Agent就能搞定”。这时候我不会直接泼冷水而是给他们一个展示的舞台先做技术可行性验证但必须在需求假设成立的前提下做。具体操作上我会安排技术验证和需求验证并行但明确告诉团队两条线的优先级需求假设不成立的话技术验证的产出只会进知识库不会进产品。这样一来技术热情没有被打压需求判断的严肃性也没有被稀释。5.3 用一张纸对齐所有相关方的预期需求判断阶段最怕的是相关方各说各话。销售说客户要A老板说重点做B工程师说C方案最牛最后变成大杂烩。我习惯的做法是写一份“一页纸需求判断卡”内容包括三块我们假设要服务什么人群、我们假设给他们解决什么问题、我们需要验证什么才能相信这个假设成立。这份文档不需要长但要发到项目群里让每个相关方都过目并确认。它的作用不是控制谁而是制造共识。大家今天在“客户要的是选品建议”这句话上没分歧后面的工作才不会跑偏。如果哪一天讨论突然发散我把判断卡翻出来一句“这不在我们这次要验证的范围内”就够了。5.4 被项目经理问“为什么还不开始开发”的应对模板这个场景我几乎在每一个项目里都会遇到所以放一个小模板在这里。当项目经理催进度时我会给他算一笔账假设我们预期的是一百小时开发工作量如果我直接开工最后发现需求方向错了这一百小时全部白费如果我花十小时把需求验证清楚哪怕最后否定了这十小时的产出是“我们证明了这件事不值得做”这个信息本身是有价值的而且保留了一百小时的后续投入。换句话说判断阶段花的时间不是项目进度的拖延而是项目风险的预支。一个好的项目经理其实能听懂这个逻辑怕的是你用空话回复他让他觉得你在拖。把账算明白沟通就顺畅了。6. FDE需求判断的最终检验标准每次做完一轮需求判断不管结论是继续还是砍掉我都会问自己一个问题如果今天我不做这个判断等到开发完成后再发现错了代价是什么代价越小判断可以越随意代价越大判断就必须越谨慎。对FDE项目来说开发完成后推倒重来的成本从来不低因为AI功能需要的不仅仅是写代码还有数据准备、Prompt调优、效果评测、用户反馈循环这些环节。在需求阶段花一周时间多走访几个用户、多做一个假功能验证在项目全周期里是回报率最高的一笔投入。所以我的建议是把“别急着做AI”这句话刻在项目启动的第一页。它不是说AI不好、不值得我们投入而是说AI的力量太强大强大到团队容易忘了为什么出发。先确认需求是真的再让AI发挥它的能力才是FDE落地最合理的路径。