夜雨聆风
这节课最重要的判断只有一句：AI 产品经理最容易不是不懂技术，而是不知道自己该在哪一层负责、在哪一层拍板、在哪一层别乱伸手。
很多人第一次接 AI 项目，会下意识把它理解成一个技术题。
于是很容易走向两个极端：要么把自己做成需求传话筒，要么把自己做成半吊子算法 PM。
但 AI 产品项目真正更常见的问题，不是没人干活，而是角色站位全乱了。业务在提愿望，技术在讲限制，老板在催结果，而产品经理没有把中间那条主线拎出来。
如果第 1 课解决的是 这个需求值不值得做 AI，这一课解决的就是：一旦决定做，你作为产品经理，到底该管哪几层，在哪几层拍板，在哪几层拉人协同，在哪几层守住边界。
这是《AI产品经理转型扫盲营》的第 2 课。它解决的不是模型怎么调，而是先帮你建立一张角色地图：一个 AI 产品到底分成哪几层，你作为产品经理到底站在哪。
认知打破
先讲一个真实翻车现场。
一个制造业知识助手项目，上线前最后一次评审会上，老板问了一句：为什么一线员工不用这个系统。产品经理当场拉出一张模型效果对比表，说召回率已经从 72% 提到了 85%，准确率也在持续优化。老板听完沉默了三秒，说：我问的不是模型准不准，我问的是为什么没人打开它。
会后复盘才发现：入口挂在一个二级菜单深处，员工遇到问题时根本不会专门切过去问；资料版本混着三年前的旧制度，答出来的东西一线不敢信；而产品经理过去两个月最投入的工作，是每周跟算法团队开模型效果评审会。
这不是个例。这是 AI 项目里最典型的一种翻车：产品经理把自己站到了模型层，却把语料层和产品层同时丢掉了。方向没错，层次站错了，结果一样会输。
周三项目会，老板问一句：这个知识助手什么时候能上。
业务说：我们最想解决的是一线找资料慢。
技术说：现在资料版本乱、权限还没梳清。
设计说：是不是先出个聊天界面。
如果这时产品经理只会追问模型效果，项目主线就会立刻散掉。
因为这个场子里，真正该由产品经理先说清的，不是模型名词，而是下面 4 件事：
•
这项目现在到底卡在哪一层
•
当前该先补哪一层
•
哪一层是产品经理必须拍板的
•
哪一层必须拉业务、技术、数据一起协同
企业级 AI 项目最常见的错位，往往长这样：
•
该你定义业务目标时，你在问模型选型
•
该你切边界时，你在抄业务原话
•
该你拍入口和路径时，你在听技术解释术语
•
该你算价值时，你在展示 Demo 体验
最后的结果通常是：
•
业务觉得产品不懂场景
•
技术觉得产品不懂边界
•
老板觉得大家都在做事，但看不见主线
为什么这种误判在 AI 项目里特别高频。
因为 AI 项目天然横跨好几套不同视角：业务视角、数据视角、模型视角、产品视角、商业视角。传统产品经理做普通软件，更习惯盯流程、页面、交互和功能闭环；一切切到 AI，就容易误以为自己得把整套技术栈都补上。
其实不是。
真正成熟的 AI 产品经理，不是每一层都懂到最深，而是知道：
•
每一层在解决什么问题
•
每一层最容易卡在哪里
•
自己在哪一层必须拍板
•
哪些层必须拉别人一起把事情串起来
我见过一个能源行业知识助手项目，产品经理前期最关心的是：到底用哪家模型，参数怎么配，效果会不会更强。
这位产品经理做了什么呢。每周一开模型效果评审会，周三盯算法团队跑 benchmark，周五催技术出新一轮对比报告。Prompt 改了十几版，向量维度讨论了三轮，召回策略换了两套。听起来非常努力，进度表也很满。
就这样做了六周。项目离上线遥遥无期，老板开始追问。
产品经理一拉进度，才发现真正拖住项目的，根本不是模型那一层。卡点全在更土、更不性感的地方：
•
文档权限没理顺，很多资料谁都说能看，真接时谁都不敢放。光协调权限就来回拉了三个部门，两周没结论。
•
同一制度有 3 个版本，没人能说清线上该用哪一个。技术问产品以哪版为准，产品问业务，业务说你们先用着。
•
产品入口挂在一个没人主动打开的二级页面里。一线员工遇到问题时，根本不会专门切过去问助手。
•
最后触发警觉的，是一次现场走访。产品经理发现一线工程师遇到设备问题，第一反应是打电话问老师傅，第二反应是翻微信群历史消息，没有一个人会去找那个系统。
这时候产品经理才意识到：自己花了六周盯的那一层，从来不是项目的卡点。真正的问题一头在语料层（版本混乱、权限不通），一头在产品层（入口挂错、没嵌进真实动作链），而自己一直站在中间那层最像 AI 的地方，把首尾两端真正决定成败的东西全漏掉了。
AI 产品经理不是去抢算法的活，也不是只写一页需求的人，而是把业务目标、数据底座、产品路径和商业结果真正串起来的人。
核心方法
我把这套看清边界的方法叫做 AI 产品四层责任图。
任何一个 AI 产品，你都先别急着看页面，也别急着看 Demo。先拆成 4 层去看：
•
语料层
•
模型层
•
产品层
•
商业层
它存在的目的，不是把事情讲复杂，而是帮你先回答 4 个更关键的问题：
•
项目真正卡在哪一层
•
哪层是你当前最该盯的主战场
•
哪层需要你主动拉别人协同
•
哪层如果不先补，后面再努力都只是空转
它不是一张讲给新人听的技术结构图。
它更像一张 产品经理的站位图。
你拿到一个 AI 需求，不要先问：
•
能不能做个助手
•
能不能做个聊天框
•
能不能接个大模型
你要先问：
•
资料到底能不能接、敢不敢接
•
模型到底该做哪类任务、边界卡在哪
•
能力到底嵌进哪一步真实流程
•
上线以后到底替谁省了什么
为什么必须是这 4 层，少一层都不行。
•
没有语料层，你喂什么都不稳，后面做得越复杂，错得越稳定
•
没有模型层，你会把想象当能力，把热词当方案
•
没有产品层，能力落不到真实动作里，最后只剩一个悬空对话框
•
没有商业层，项目就算上线，也很难长期活下去
所以这套方法真正帮产品经理解决的，不是我是不是要懂技术，而是：
我先看哪层、我主盯哪层、我在哪层拍板、我在哪层只盯边界。
AI 产品四层责任图的本质，不是把 AI 项目拆得更细，而是帮产品经理先找准自己真正该下手的那一层。
方法拆解
第一步：先看语料层
这一步到底在判断什么
这一步判断的，不是你有没有一堆资料，而是你有没有 可用、可信、可接入、可持续更新 的语料底座。
很多团队一说数据够不够，脑子里想的是：我们不是有很多文档吗。
这句话往往没什么意义。
真正有意义的是：这些资料从哪来、谁维护、哪个版本当前生效、权限能不能过、格式能不能接进系统。
你在这一层到底负责什么
你不是去亲自做数据治理，也不是亲自写抽取脚本。
但你必须负责把几个关键问题拍清：
•
哪些资料是这个场景真正该用的正式依据
•
哪些资料只是历史材料、讨论稿、不能直接进模型
•
当前版本口径到底以谁为准
•
权限边界如果不过，这项目就不能假装能上
换句话说，语料层里你不替技术做实现，但你必须替项目守住资料边界。
最常见的误判是什么
以为只要有一堆文档，就算有数据底座。
其实不是。
企业里很多所谓有数据，本质上只是有资料堆。
资料堆和语料底座，中间差的是：来源清不清、版本稳不稳、权限能不能过、格式能不能接。
很多项目不是模型不聪明，而是你喂进去的东西根本没有统一世界观。
你现在可以怎么判断
直接回答 4 个问题：
•
数据到底从哪来
•
谁维护
•
多久更新一次
•
哪些资料不能进模型
如果这 4 个问题里有 2 个以上答不清，那先别急着讨论模型。
第二步：再看模型层
这一步到底在判断什么
这一步判断的，不是模型强不强，而是这个任务到底是不是模型擅长的任务。
很多团队最危险的地方，不是不懂模型，而是太爱把模型想成万能员工。
模型更像一种能力组件。
你得先说清，它到底是在做抽取、总结、问答、分类、生成，还是多步任务协调。
如果任务类型本身都没定义清，再讨论模型就很容易漂。
你在这一层到底负责什么
你不是算法工程师，不负责调参数，也不负责替团队拍最终技术方案。
但你必须负责把任务边界切清：
•
模型这一段到底替业务做什么
•
不做什么
•
什么结果只能给草稿，不能给结论
•
什么输出一定要人工确认
你在模型层最重要的价值，不是技术深度，而是任务定义深度。
最常见的误判是什么
把模型当万能员工。
产品经理一旦这样想，后面就很容易出现这类话：
•
它能不能顺便判断风险等级
•
它能不能顺便给整改建议
•
它能不能顺便自动下结论
最后不是模型不行，而是你把一个能力组件，幻想成了一整套业务方案。
你现在可以怎么判断
把需求改写成一句任务定义：
它到底是抽取、问答、分类、总结，还是生成。
如果你连一句都改写不出来，说明你还没定义任务，只是在描述愿望。
第三步：再看产品层
这一步到底在判断什么
这一步判断的，是怎么把模型能力嵌进真实业务流，而不是做一个悬空页面。
很多团队真正做错的，不是能力不够，而是放错地方。
把一个还算有用的能力，做成一个没人会主动打开的新页面，基本就已经输了一半。
你在这一层到底负责什么
这一层是最像传统产品工作的地方，也是你最不能丢主导权的地方。
你必须负责拍清：
•
用户原来在哪一步最累
•
AI 应该替掉哪一段动作
•
入口到底放在哪个真实节点
•
上下文怎么自动带上
•
输出以后下一步怎么接回流程
•
出错时怎么兜底，怎么不给用户添乱
你不是在设计一个会说话的界面。
你是在设计一条让 AI 真正被用起来、被接回去、被承担结果的业务路径。
最常见的误判是什么
把 AI 产品理解成一个对话框。
但真正的产品工作，不是做一个能说话的入口。
真正的产品工作，是把 AI 藏进用户最累、最重复、最容易卡住的那一步动作里。
你现在可以怎么判断
直接问自己：
•
用户原本在哪一步最累
•
AI 应该替掉哪一段动作
•
输出以后，下一步该点哪里
如果答不上这 3 句，说明你看到的还只是界面，不是业务链。
第四步：最后看商业层
这一步到底在判断什么
这一步判断的，是这个项目最后到底替谁省了什么、值不值这笔钱。
企业里很多 AI 项目死得很安静。
不是技术做不出来，也不是体验太差，而是上线后没人能回答一句最现实的话：这东西到底替公司省了什么。
你在这一层到底负责什么
你不是财务，也不是老板。
但你必须负责把价值链路说清：
•
替哪个岗位省时间
•
替哪个流程降成本
•
替哪个环节减少返工或风险
•
为了这点价值，要多付出多少模型费、人审费和维护代价
很多 AI 项目做着做着就死掉，不是因为没人喜欢，而是因为没人能替它继续辩护。
而这个辩护材料，很多时候就是产品经理要先准备好的。
最常见的误判是什么
把上线当成完成。
企业项目不是功能跑通就结束。
很多时候，真正决定项目能不能活下去的，不是前面的发布会，而是后面的那张账。
你现在可以怎么判断
先写一句，不超过 20 个字：
这个功能最后到底替公司省了什么。
如果这句都写不出来，这层大概率还没立住。
开会时，四层分别怎么说
如果你在会上需要按层推进，每层只用记住一句最锋利的话：
•
语料层： 这个项目现在最卡的不是模型，而是资料还没到能被稳定调用的程度。
•
模型层： 先别把有 AI 当方案，我们先定义它到底替你做哪一类任务。
•
产品层： 这件事最危险的不是能力做不出，而是入口放错后没人用。
•
商业层： 这个功能最后到底值不值，不看 Demo 漂不漂亮，要看它替谁省了什么。
为什么这张图对入门者尤其重要
因为前 10 课要帮你建立的，不是企业级 AI 项目的全部深水能力，而是最先不该站错的位置。
你先知道自己站在哪，后面学概率思维、技术语言、RAG、需求翻译、交互、指标和 ROI，才不会学成一堆散知识。
换句话说，这一课不是让你直接变成技术负责人，而是先让你别再做一个只会转述需求、追着术语跑的普通 PM。
实战模板
AI 产品四层责任画布
下面这张画布，不是拿来显得专业的，而是你开第一轮判断会时可以直接用的工作模板。
•
业务目标： 这件事真正想解决什么问题
•
当前痛点： 用户原来最累、最慢、最容易错的是哪一步
•
语料层： 数据从哪来、谁维护、版本怎样、权限怎样
•
模型层： 要做什么任务、边界是什么、不能做什么
•
产品层： 入口在哪、上下文怎么带、输出后怎么应用
•
商业层： 节省什么、花多少钱、看什么指标
•
当前最卡层： 现在最该先补哪一层
•
你来拍板的层： 哪些问题必须由产品经理定下来
•
要拉谁协同： 业务、技术、数据、安全分别谁要进来
•
如果不做 AI： 更稳、更快的替代动作是什么
•
如果做 AI： 第一轮最小验证范围是什么
快速判断法
你还可以直接用这 4 句判断一个项目当前到底有没有站稳：
•
没语料，别急着谈问答
•
没任务定义，别急着谈模型
•
没业务入口，别急着谈交互
•
没价值落点，别急着谈上线
填写示范 1：做错层的需求
需求：做一个智能问答页面，回答设备问题
•
业务目标：让员工遇到设备问题能快速找到依据
•
语料层：资料来源不清，版本混乱
•
模型层：任务定义模糊，既想问答又想给建议
•
产品层：新页面悬空，入口不在业务流里
•
商业层：说不清到底替谁节省了什么
•
当前最卡层：语料层和产品层
•
你来拍板的层：先定资料范围、任务边界和入口位置，而不是先催页面
结论：先别做页面，先清语料和入口。
填写示范 2：层次清楚的需求
需求：在维修工单页做设备知识辅助
•
业务目标：减少工程师翻资料时间
•
语料层：设备手册、历史工单、FAQ 已分层
•
模型层：只做检索增强问答，不拍板
•
产品层：入口挂在工单详情页，自动带设备信息
•
商业层：目标是缩短查资料时间、减少切系统次数
•
当前最卡层：语料接入和引用准确性
•
你来拍板的层：边界只到引用式问答，不越到维修结论
结论：可以进入预研。
开会时怎么说
很多产品经理不是不会判断，而是不知道怎么把先别急着做说出口。
你可以直接用这 3 句：
•
对老板说： 我们不是先选模型，而是先把项目到底卡在哪层看清。
•
对技术说： 我不抢模型方案，但需要你明确边界、代价和当前最卡层。
•
对业务说： 先别着急催页面，先把数据和入口理清，不然做出来也没人用。
案例说明
反面案例：为什么知识助手先做页面会翻车
业务方原话
做个企业知识问答助手，员工自己问就行。
产品经理为什么不能直接接
因为这句话里只有一个结果想象：
好像只要做出一个问答入口，员工自然就会问，自然就能用，自然就能提效。
但这句话里真正关键的问题，一个都没定义：
•
问的到底是什么知识
•
资料有没有统一版本
•
谁能看哪些内容
•
入口挂在哪个真实场景里
•
答完以后到底替员工省了哪一步
如果产品经理直接接，团队很容易立刻冲向最显眼、也最容易出成果的那层：做页面。
这正是这个项目最危险的地方。
四层责任图怎么判断
第一层：语料层稳吗？
不稳。
资料版本不统一，很多还是旧制度，历史 FAQ 和正式制度混在一起。
第二层：模型层清吗？
不清。
想让它既答制度，又答设备，还能顺带给建议，任务边界明显漂了。
第三层：产品层对吗？
不对。
想单独做一个入口，但员工真正有问题的时刻，往往不在专门来问 AI 的页面里，而是在工单、处理单、审批和现场问题发生的那个节点上。
第四层：商业层立得住吗？
立不住。
说不清到底节省了什么，是减少培训成本，还是减少查资料时间，还是减少错误回答风险。没有明确价值落点。
最危险的点在哪
最危险的点不是做不出一个问答框。
最危险的是：
团队先冲着产品层去做了，结果做完才发现前后两头都没准备好。
前面语料没统一，后面价值没定义，中间只剩一个看起来像 AI 的页面。
为什么最后结论是先别做页面
因为问题根本不在有没有一个问答入口，而在：
•
知识来源没盘清
•
版本没统一
•
入口放错了
•
价值说不明
这种项目如果硬做，最常见的死法不是事故，而是：做出来了，没人真正依赖它。
如果不做 AI，更合理的产品动作是什么
•
先盘点高频知识来源
•
先统一制度版本和生效口径
•
先把高频问题塞回员工真实工作流里的入口
•
先优化原搜索和知识导航
如果一定要做 AI，最合理的边界是什么
先别做全局知识助手。
更合理的边界是：
先在工单详情页里做设备知识辅助检索 + 引用式问答，只回答和当前设备、当前处理场景直接相关的问题。
第一轮先验证什么
•
员工是不是愿意在原页面里用
•
引用资料是否准确
•
是否真的减少查找时间
•
是否减少切系统和翻手册次数
正面案例：为什么维修工单页内嵌知识辅助值得做
业务方原话
维修工程师开工单时最耗时的是翻资料、找历史案例。不是不会修，是找依据太慢。
产品经理为什么也不能一听就开做
不能直接开做，不是因为这个需求不行，而是因为这类需求特别容易被做成一个万能聊天框。
一旦做成万能聊天框，边界就会糊：
到底是在做知识问答、历史案例推荐、维修建议，还是故障判断。
产品经理必须先把层次切开。
四层责任图怎么判断
第一层：语料层稳吗？
相对稳。
设备手册、历史工单、FAQ 都能拿到，而且能按设备和场景分层。
第二层：模型层清吗？
清。
只做检索增强问答，不做最终维修判断，不让 AI 拍板。
第三层：产品层对吗？
对。
入口直接挂在工单详情页，自动带设备信息，不要求工程师切出去重新问。
第四层：商业层立得住吗？
立得住。
目标非常明确：减少工程师翻资料时间，缩短处理前的查找动作。
最危险的点在哪
最危险的点是，不要让 AI 直接给维修结论。
一旦它从找资料、给参考越过到告诉你应该怎么修、该不该停机，项目风险就完全变了。
为什么最后结论是可以进入预研
因为这个需求同时满足了 4 个条件：
•
语料有基础
•
模型任务边界清晰
•
产品入口贴着真实流程
•
商业价值能说清
这种项目不是应该直接全量开发，而是很适合做小范围预研验证。
如果不做 AI，更合理的产品动作是什么
就算不做 AI，也应该先补两件事：
•
工单页里的知识入口前置
•
高关联资料按设备和故障类型重新组织
因为这些底座不补，AI 体验也会打折。
如果要做 AI，最合理的边界是什么
最合理的边界不是万能助手，而是：
只在工单详情页内提供当前设备相关资料 + 历史案例 + 引用式问答，不给最终维修结论，只给参考依据。
第一轮先验证什么
•
是否真的减少查资料时间
•
工程师是否愿意在原页面里用
•
引用资料是否准确
•
草稿或建议是否真正被采用
误区提醒
误区一：我只要懂技术一点，就等于会做 AI 产品
不是。
懂一点技术当然有帮助，但真正决定你是不是 AI 产品经理的，不是你能不能跟着说术语，而是你能不能把任务边界、入口路径、协同关系和价值落点讲清。
误区二：既然 AI 项目很复杂，那我就每层都得自己管
也不是。
你需要看懂四层，但不等于你要替四层所有角色干活。
真正成熟的站位，是看得懂全景图，但只在该拍板的地方拍板。
误区三：把系统结构讲明白了，就等于角色边界讲清了
不等于。
系统结构是这个东西怎么组成的。
角色边界是出了问题该谁先判断、谁先定边界、谁来拉人协同。
这两件事不是一回事。
带走什么
如果你只带走这一课一个能力，那就带走这个：
以后再接 AI 项目，你不要一上来就问模型、问参数、问选型，也不要只会把业务原话转给技术。
你先把项目拆成语料层、模型层、产品层、商业层，再逼自己回答：
•
现在到底卡在哪层
•
哪层是你必须拍板的
•
哪层该协同别人
•
哪层如果不先补，后面做什么都白费
当你开始先找自己的站位，再看项目往哪推进，你就已经不再是普通写需求的人，而是在进入 AI 产品经理真正的角色。
行动清单
1.
今晚就拿一个你手头的 AI 项目，按四层拆成一页纸
不要只写名词。每一层后面都补一句：现在最卡什么。
2.
在四层后面各补一句：这一层你负责拍什么板
这一步很关键。它会逼你分清，哪些是你要定的，哪些是你要拉人协同的，哪些不是你该假装自己能拍的。
3.
只找出当前最卡的一层，不要四层都说一点
如果你四层都说，等于哪层都没判断。你必须逼自己写出：这个项目现在最该先补哪一层。
4.
把你当前方案里所有像智能化升级、体验更聪明这样的空话，改写成层次问题
比如把做知识助手改成：语料来源不清、入口挂错、价值没定义。
5.
再补一句：如果今天不做 AI，更稳的替代动作是什么
这句会逼你看清，你到底是在做 AI，还是在逃避基础产品工作。
如果你今天真把这 5 件事做完，你已经不是在围着 AI 热词打转，而是在做真正的项目判断。
这节课学会的标志是什么
你不再把 AI 产品理解成一个对话框，也不再一上来就问模型、问参数、问选型。
你会先把项目拆成语料层、模型层、产品层、商业层，再判断：
•
现在到底卡在哪层
•
哪层是你必须拍板的
•
哪层该协同别人
•
哪层如果不先补，后面做什么都白费
更重要的是，你开始知道：自己不是工程师、不是算法，也不是只会转需求的人。
你是那个负责把项目主线拎出来、把边界切清、把协同拉起来的人。
当你开始先看站位，而不是先看热词，这节课才算真的学会。
这节课最关键的一句话
AI 产品经理最怕的不是不懂技术，而是看不清自己该在哪一层负责、在哪一层拍板。
后面几课会继续讲什么
前两课到这里，先把最容易站错的两步补上了：先判断值不值得做，再看清做了以后你到底该站哪。
下一课会继续往前走一步。
就算你已经看清层次，做 AI 产品时还有一个更大的思维切换：你不能再按传统软件那种确定性逻辑设计产品了。你要开始学会管理概率、设计容错和兜底。
这也意味着，前面这两课解决的还只是入门判断。
真正更深的企业级落地链路，还在后面的课程里。
