金融AI产品的合规审核智能化之路，远比想象的复杂。当团队试图用3个月打造MVP时，从需求调研到架构设计步步惊心：用户给出的功能清单背后是未被识别的深层痛点，历史工具的失败案例揭示了数据验证的关键性，而访谈信息的结构化提炼则直接决定了产品生死。本文将揭示从"功能堆砌"到"精准狙击"的蜕变过程，以及AI产品需求分析中不可忽视的铁三角——用户痛点×数据可获得性×技术可行性。
我之前在做金融AI产品，团队4-5人，给了我3个月要上线MVP。公司的广宣合规审核完全是人工在做，4个合规人员日均审50条物料，高峰期翻4倍到200条，单张海报审8-10分钟，复杂研报审半小时到一小时。近2年出了3次监管警示函，罚款加间接损失超200万，公司分类评级还被下调了。领导说：你们搞AI的，能不能把合规审核智能化？
我当时心想，这不就是个内容审核的事嘛，搞个敏感词过滤加AI识别就行了呗。结果很快就翻车了。
刚开始做需求调研的时候，合规团队给了我一堆他们想要的”功能清单”：
你看这张清单，是不是觉得每条都合理、每条都该做？我当时也这么觉得，甚至已经开始画PRD了，心想MVP阶段先做前5条，后面的迭代再说。
但我忘了最根本的一条：需求是问题，不是答案。
你想想福特的例子——用户说”我要一匹更快的马”，听起来合理吧？但用户的真实需求是”更快地到达目的地”，马只是他已知方案。同样的道理，合规团队给的每一条”要能XXX”，都是他们在现有认知下拼凑的解决方案，不是真正的需求。
我后来用Y模型重新拆了一遍才想明白：
– 用户表面诉求：要一堆审核工具功能
– 用户真实痛点：4个人扛不住翻4倍的审核量，图片里的隐性违规肉眼根本看不出来，监管新规月月更新但知识传递跟不上，审完一条物料平均返稿2.3次来回扯皮
– 深层人性需求：安全——不想因为漏判被罚；效率——不想把时间耗在机械重复的事上；尊重——不想新人永远依赖老员工、离职就断层
说直白点，他们不是”要一个审核工具”，而是”要一个能替他们挡风险、扛工作量、沉淀知识的东西”。这完全是两回事。
这个坑直接导致我第一版方案差点做成一个”功能堆砌型”产品——什么都有，但什么都不深。你想想，如果真的按那张清单逐条落地，MVP要做多少功能？3个月根本搞不完，就算搞完了，每个功能都是浅浅一层，核心痛点一个没解决。
踩坑总结：拿到用户需求的第一步不是画原型，而是把”要什么功能”翻译成”到底要什么结果”。 用Y模型从用户方案→用户痛点→人性需求逐层拆解，你才能判断哪些需求是真需求、哪些是伪需求、哪些是锦上添花。
想通了需求本质之后，第二个问题来了：10条需求都拆清楚了，先做哪个？
我一开始用的是最朴素的方法——凭感觉排。觉得”敏感词过滤”最基础就排第一，觉得”图片审核”很难就往后放。结果合规负责人一句话把我打醒了：
“你先做敏感词过滤？我们之前那个工具就是只做敏感词过滤，用了3周准确率就下降，最后整个系统停用废弃了。你做这个有什么意义？”
这句话让我意识到：需求定级不能凭直觉，得有量化依据。
我后来用了需求分析三阶段的定级方法：
阶段一：需求理解和转化——把每条需求转化成可量化的指标。比如”图片审核”转化成”隐性违规识别准确率”，”法规溯源”转化成”法规条款匹配召回率”，”自主维护规则库”转化成”新规更新落地周期”。指标体系是产品的帮手，产品好不好是指标决定的，不是感觉决定的。
阶段二：可行性和价值分析——估算每条需求的商业价值和实现难度。商业价值=用户价值+收入价值+战略价值。拿我这个项目举例：
阶段三：需求定级和决策——商业价值÷开发量=性价比，决定先做哪个。
用这个方法排出来的优先级，和我凭感觉排的完全不一样。凭感觉排的话，我会把最简单的”敏感词过滤”放第一，但实际上它的性价比极低——因为历史工具已经验证了这条路走不通。反而是”文案+图片多模态审核”这个看起来最难的需求，性价比最高，因为它是用户核心痛点的直接解决方案。
最终我用MoSCoW法则定了MVP范围：
– Must Have：文案违规审核+海报图片多模态审核+法规溯源+修改建议生成+基础知识库搭建+企微ChatBot入口+AI标识标注+审核记录可溯源+OA留痕
– Should Have：PDF/PPT批量审核+短视频/直播审核+多品牌规则配置+数据看板
– Could Have：二次对比审核+培训知识库+宣发平台打通
踩坑总结：需求定级的本质是算性价比，不是排难度。 先算商业价值（用户价值+收入价值+战略价值），再算开发量（人天×风险系数），最后用价值÷开发量排序。AI产品还要额外评估数据质量可行性和算力延迟可行性——没有数据、模型跑不动，再高价值的需求也是0。
前面两个坑让我学会了拆需求和定优先级，但还有一个坑差点让我在架构设计上走弯路——用户访谈的信息提炼。
我做了2人的线下面谈，聊了合规审核负责人和资深审核专员，拿到了很多原声。但刚开始我只是把原声原封不动记下来，没有做结构化提炼，导致设计架构的时候凭印象做决策。
后来我按5个维度重新提炼访谈信息，才发现很多关键细节被我忽略了：
你看这个对比，提炼前全是模糊描述，提炼后全是量化数据。模糊描述让你觉得”差不多是这样”，量化数据让你发现”原来是这样”。
比如”核心漏判场景”这一条，提炼前我只知道”人工有死角”，提炼后才发现最关键的漏判不是文本违规（这个其实好抓），而是图片里的隐性违规和监管新规更新后的新增类型——这两个直接决定了我的架构必须做多模态解析智能体和自主更新知识库，而不是只做一个文本审核智能体。
再说一个访谈里差点被我忽略的原声：
“原来的工具用了3周准确率就大幅下降，最后弃用了。核心顾虑是系统不能过度依赖人工运维，需具备自动化更新能力，避免因人员变动导致系统瘫痪。”
这句话表面上是抱怨历史工具不好用，但深层需求是：知识库必须支持自主维护，否则再做一遍也是烂尾。 这直接影响了我把”合规团队自主维护规则库”从Should Have提到Must Have。
踩坑总结：用户访谈不是录音机，是提炼器。 每条原声都要追问三个问题：表面诉求是什么？背后痛点是什么？对我产品设计意味着什么？不做结构化提炼，访谈就是浪费时间。
上线后跑了灰度测试，以下是核心指标前后对比：
有一点要特别说明：96%的准确率不是一上来就达到的。第一个版本准确率只有88%，主要问题出在图片隐性违规的识别上——金融海报里那些字号极小的风险提示语、藏在角落里的合规标语，OCR容易漏识别。后来专门优化了物料解析智能体的OCR能力，加了金融场景的字号和位置特征检测，才把准确率拉到96%。
1. 需求是问题，不是答案
用户给你的永远是方案，不是需求。Y模型的核心价值就是帮你从”用户说要什么功能”跳到”用户到底要什么结果”，再跳到”人性层面要什么”。只有拆到人性需求这一层，你才能判断哪些需求值得做、哪些是伪需求。马斯洛需求金字塔不是教科书里的理论，是实战中判断需求层级的工具——你是解决生存刚需（安全不被罚），还是满足尊重需求（不被新人拖累），完全决定了产品方向。
2. 需求定级算性价比，不是排难度
商业价值÷开发量=性价比。看起来简单的需求不一定先做，看起来难的需求不一定后做。金融合规审核这个项目里，多模态图片审核比敏感词过滤难10倍，但性价比高5倍——因为历史已经验证了敏感词过滤这条路走不通。AI产品还要额外评估数据可行性：没有数据支撑的需求，价值就是0。
3. 用户访谈要做结构化提炼，不是录音
访谈原声不是产品需求，提炼后的量化信息才是。每条原声追问三层：表面诉求→背后痛点→对产品设计意味着什么。不做提炼，访谈就是走流程；做了提炼，访谈才是产品决策的依据。
4. AI需求=用户痛点×数据可获得性×技术可行性
这个公式我踩坑后才真正理解。没有用户场景就没有痛点，没有数据模型跑不起来，技术上做不到也是白搭。三者缺一个，需求就不成立。MVP阶段宁可砍掉50%的Should Have，也要确保Must Have三要素齐全。
5. 知识库自主维护能力是AI产品的隐形刚需
访谈里合规团队一句话点醒了我：”原来的工具因人员变动彻底停更废弃。”AI产品如果过度依赖技术团队维护知识库和规则库，就是给未来的烂尾埋伏笔。把知识库的编辑维护权交给业务方，技术团队只负责底层架构——这个决策直接决定了产品的可持续性。
说白了，需求分析这件事的核心就是一句话：别急着画原型，先把”用户要什么功能”拆成”用户到底要什么结果”，再用数据算出性价比排优先级，最后用结构化提炼把访谈信息变成产品决策依据。 三步走完，你的MVP才不会变成功能堆砌的半成品。
做AI产品需求分析，比传统产品多了一个维度——数据可行性。没有数据、模型跑不动、算力撑不住，再好的需求也是空中楼阁。把”用户痛点×数据可获得性×技术可行性”这个公式刻脑子里，你就不会在MVP阶段做一堆看起来合理但落地不了的功能。
欢迎评论区交流，如果你也在做金融AI或者合规审核类的产品，特别想听听你们的需求分析是怎么做的。
本文由 @Keating 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。