2026 AI 产品经理实战指南｜附提示词
这份发在入行之路，写法是教学稿：给正在学产品、或者刚接手第一个需求的同学用。目标不是背流程，而是练四个动作——摊开、标出处、写变更、填验收，每个动作后面配一个练习。
所有例子都是虚构示意，用来练格式。真实项目里把内容换成你自己的。
先说清楚这门课在解决什么
你现在大概率已经会让 AI 写 PRD、生成原型页面了。单点确实快。
真正接不上的是环节之间：AI 给的材料你分不清哪句是事实、哪句是它补的；它列出的一堆规则你不知道该留哪几条；评审改完的结论只留在纪要里，下次让它分析同一个功能，它还照着第一版往下推。
这四个动作就是接口。学会了，你在团队里的输出才是别人能接着用的东西。
动作一：摊开（不要一上来就写文档）
场景（示意）：产品里有个「导出记录」列表，客户回访说了一句「导出失败太难查了，能不能改好一点」。
如果直接让 AI「写一份需求文档」，你大概会拿到一份看起来很完整、但没人对得起的文档：哪句是客户说的、哪句是它补的，分不出来。
第一步是摊开：
背景：产品里有一个「导出记录」列表。客户反馈原话是「导出失败太难查了」。我目前只有这一句，另外有一条研发口径：批量导出如果逐条重试，代价很高。 先不要写需求文档。把你认为可能相关的改动列成一行一条，每条写明：它解决什么情况、不做会怎样、依赖什么前置条件，以及这条是客户说过的，还是你补出来的。不要合并，也不要替我排优先级。
练习 1：拿你现在能接触到的任意一个产品（哪怕是你常用的 App），自己编一句用户抱怨，按上面这段跑一次。注意三处替换：模块名换成那个产品里真实存在的模块；抱怨那句标明是你的「模拟反馈」，不要写成真实用户原话；「另外有一条研发口径」这半句，如果你手上没有研发资料，就填「暂无」或整句删掉，不要沿用示例里那条批量重试的口径。跑完看它给你列出几条。
动作二：标出处（这是整份表里最值钱的一列）
它列出来的候选项，要填进一张四列表：候选改动 / 依据来自哪 / 还要确认什么（问谁）/ 草案建议。
举两行（示意）：
- 失败记录显示失败原因｜客户只说「难查」，「显示原因」是 AI 补的解法｜客户要的是知道哪几条失败，还是要知道为什么失败？问客户运维负责人｜建议本期，先确认口径
- 导出历史保留 90 天｜「90 天」是 AI 给的数字｜现在实际存多久（问运维）；客户一般回查多久前的记录（问客户）｜数字定下来之前不写进需求
重点讲第二行。90 天是 AI 补出来的合理猜测，客户从没提过。这类数字一旦被当成客户口径写进文档，后面的原型、测试用例、验收标准都会拿它当前提，一路往下错，而且每一环看起来都很自洽。
第三列也不能空。「待确认」不是砍掉，它是一个有对象的动作。没有对象的待确认，到了评审还是一片空白。
练习 2：把练习 1 的结果填成这张四列表。填完数一下：有几条的「依据来自哪」写的是「AI 补的」？这一列里标「AI 补的」那几条，就是你接下来必须回去确认的部分。
动作三：写变更（改了什么、为什么改、影响哪几份文件）
评审之后方案还会变。进了研发更会变。变化必须回到项目里，不能只写一句「改了」。
模板（示意）：
2026-10-08 研发方案变更｜原方案：对单条失败记录发起重试｜新方案：对该批次重跑，只处理其中的失败项｜原因：导出任务按批次生成，单条无法脱离批次执行｜影响：PRD 3.3 改写重试范围，原型按钮提示改为「重跑本批失败项」，验收标准同步改为「其余成功记录不重复导出」｜确认人：产品负责人、后端负责人
六段：时间、原方案、新方案、原因、影响、确认人。团队的系统里已经记了时间和确认人的，引用过去就行。
「原因」和「影响」这两段不能省。漏了原因，几个月后没人说得清当初为什么改；漏了影响，需求池改了、PRD 没改，两份文件下次就开始互相打架，而你不能指望有人或有工具一定会先提醒你。
练习 3：回想你最近一次「方案临时改了」的经历（课程作业、实习任务都行），照六段补一条记录。隔一天再打开，看它能不能回答「当初为什么改」。
动作四：填验收（只写「功能正常」，依据就丢了）
验收记录要两列：期望、实际。
（示意）需求 3.2 失败原因展示｜构造一条缺少「客户编号」的导出｜期望：状态为失败并显示缺失的字段名｜实际：状态为失败，原因栏显示「未知错误」，没有出现字段名｜未通过
（示意）需求 3.3 失败项重试｜测试数据：同一批次 3 条失败、5 条成功｜期望：只重跑失败项，其余记录不重复导出｜实际：查测试执行日志，3 条失败记录各新增一次执行，5 条成功记录没有新增执行记录｜通过
三个必须记住的点：
第一，「实际」写你观察到的东西。写成「符合」或「功能正常」，别人只能再回来问你一遍凭什么判通过。这一栏的内容必须来自一次真实执行；如果只是练格式的模拟，就逐条标明「虚构示意」，别让模拟结果看起来像实测。
第二，判通过要有依据，而且依据要跟这条的验收标准对得上。第一条看页面上的字段展示，直接观察就能判；第二条要证明后台没有重复执行，靠的是测试执行日志——页面上时间没变只能算旁证。拿不到这类证据或相应工具，就只能先记「待核验」。
第三，第一条按已写进 PRD 的标准就是未通过。如果讨论后决定接受「未知错误」这种兜底文案，那是改了验收标准，要记一条变更、重新确认，不是在测试群里口头放行。
如果要让 AI 参与验收，前提是：工具确实支持相关操作能力，只在测试环境，且只在你已有的账号和数据授权范围内使用。这三条不能省——别拿生产环境练手。
练习 4：分两种情况。
- 练习 2 里留下的需求如果还没有实现可测，就做模拟练习：照上面的格式写记录，「实际」那栏写你假设的观察结果，并在每条开头标「虚构示意」。这是练格式，不是验收结论。
- 如果你手上有真实任务里已经实现的功能，就按实际执行填：期望写标准里的要求，实际写你这次真的观察到的东西。没有实现可测就写「未执行」，有实现但拿不到证据就写「待核验」。
不用凑成一条通过、一条未通过，结论按实际情况写。
最后：这些记录要有地方放
上面四个动作的产物都需要一个固定落点，否则又散回纪要和聊天里。
跑项目初始化需要一个能读写本地文件的 AI 工具。先新建一个空目录，不要直接对着已有项目执行——对着现有项目跑，可能改动或覆盖里面的文件。把提示词里的「我指定的空目录」换成这个目录的完整路径，或者先在工具里把工作目录切到它；执行前打开看一眼，确认里面是空的。
请在我指定的空目录中，为「[产品名称]」建立一个产品协作工作空间。
先列出你打算创建的文件和目录方案，等我确认后再创建，不要改动其他位置。
按用途分开存放：协作规则、原始资料、产品事实、规划与决策、需求池、
单项需求、版本计划、评审与验收记录、共享素材、归档。
请准备好这几份文件：
- 总入口 README：说明从哪里开始读，各目录分别放什么。
- 来源登记表：记录每份材料的出处、日期、版本和存放位置。
- 需求池：记录需求内容、来源、状态、优先级依据和目标版本。
- 协作规则：约定命名方式、工作顺序、状态流转和信息归属。
工作约定：
每类信息只在一处维护，其他地方引用，不重复抄写。
原始材料保留原貌，修改另存新版本。
明确区分事实、推断和待确认内容。
先登记资料，再分析需求，评审确认后才进入实施。
已批准的内容发生实质变化，要记录原因并重新评审。
没有经过上线验证的，不标记为已上线。
不要自行批准草稿。敏感凭证不写入任何文件。
完成后列出：入口文件位置、还缺哪些资料、建议的下一步。
本次只做初始化，不生成业务需求，不开始开发。
跑完必须做一个核对动作：对照它先前列出的方案，看目录和文件是否一致、有没有动到别处。这一步不能省。
学习路径建议
不用一次把四个动作全上。按这个顺序练：先练摊开和标出处（这两个是同一件事的两半），熟练之后再加变更记录，最后加验收回填。手上还没有真实任务的，用明确标注为模拟的练习也可以，只要每条都标清楚是模拟。
什么时候算练会了，有三条可以自己检查：表里每一条你都说得出依据来自哪；每条「待确认」都有具体的人可以问；验收记录里的「实际」写的是你真的观察到的东西，模拟的部分标了出来。
再加一条外部检查：把你写的那张表或那条记录交给一个没参与过这个需求的同学，他能不能看懂这条是谁提的、接下来该问谁。