我刚开始接触提示词那会儿，总觉得它像某种玄学咒语。后来在真实项目里反复用，才慢慢摸到门道。这一章我想把自己踩过的坑、总结出的判断标准，还有对提示词价值的理解，尽量口语化地摊开聊聊。
1.1 产品经理提示词的定义、构成与适用边界
产品经理提示词在我这里不是“让AI变魔术”的几句话。它更像一份写给聪明协作伙伴的任务说明书。我通常把它拆成几个部分：角色设定、背景信息、任务目标、输入材料、约束条件、输出格式。这几块缺了哪一块，AI给我的东西就容易跑偏。有次我让AI“分析一下用户反馈”，它洋洋洒洒写了两千字，可我真正想要的是按优先级排序的痛点列表。后来我改成“你是一位做过三年B端工具的产品经理，基于以下20条用户反馈，输出前五个高频问题，每个问题附上出现次数和典型原话”，输出就靠谱多了。
适用边界这事我踩过实实在在的坑。提示词能帮我把模糊想法整理成结构，能快速生成初稿，能帮我检查逻辑漏洞。它不能替代我去做用户访谈，不能替我拍板优先级，更不能代替我对业务结果负责。我见过同事把整份PRD丢给AI，自己连需求背景都没写清楚，产出的东西看着像模像样，一评审全是硬伤。我的边界感是：提示词负责放大我的思考效率，不负责替我思考。
1.2 从业务目标到提示词意图：需求拆解方法
我自己的习惯是先问“这次到底要解决什么业务问题”。老板说“提升新用户留存”，这是个业务目标，很宽。我不能直接让AI“写个提升留存的方案”，那样它只能给我一堆通用套话。我会拆成几个具体问题：当前留存曲线什么样、新用户第一周的关键行为有哪些、竞品怎么做的、我们有哪些资源约束。拆完这些，提示词意图就清晰了——让AI帮我对比三个竞品的新手引导流程，输出每个流程的步骤、触发条件和留存影响假设。
需求拆解我常用“目标—障碍—输入—输出”四步。目标要具体到可验证，障碍要列出已知限制，输入是我能提供的材料，输出是我希望拿到的格式。有一次我要做会员体系改版，先让AI帮我梳理“用户不愿续费的常见原因”，它给了八条。我拿着这八条去跟运营核对，发现其中三条跟后台数据对不上。这个过程让我明白：提示词意图来自业务拆解，拆得越细，AI越能给出有用的中间产物，我再去验证和修正。拆得粗，AI就只能陪着我一起模糊。
1.3 产品经理提示词的常见误区与质量评估维度
我早期犯过“角色万能”的毛病，开头永远写“你是一位优秀的产品经理”。后来发现角色设定太泛等于没设。真正有用的是“你是一位做过三年SaaS计费系统的产品经理，熟悉订阅制和按量计费”。越具体，AI的用词和判断越贴近场景。另一个误区是“一次问太多”。我试过在一个提示词里让AI同时做竞品分析、写用户故事、生成验收标准，结果每部分都浅尝辄止。拆成多轮反而更快，每轮我还能根据上一轮输出调整下一轮的方向。
质量评估我主要看四点：相关性、完整性、可执行性、一致性。相关性是输出有没有跑题，完整性是关键字段有没有漏，可执行性是拿到结果能不能直接进下一步工作，一致性是前后数据、术语、逻辑对不对得上。我通常会拿同一个提示词跑两三次，看输出波动大不大。波动大的地方往往是我约束没写清楚。有次输出格式我只写了“列表”，AI有时给编号有时给项目符号，后来我明确“用Markdown有序列表，每条不超过30字”，稳定多了。
1.4 提示词能力在产品工作流中的价值扩展
我现在把提示词当成工作流里的“加速器”，不是替代品。写周报时我用它把散落的会议记录整理成三段式进展；做用户访谈前用它生成访谈提纲初稿；评审前用它模拟挑刺，列出PRD里可能被质疑的五个点。这些场景都不大，省下来的时间我能拿去跟开发和设计对齐。价值不在提示词本身多花哨，在于它帮我从重复整理里抽身，把精力留给判断和沟通。
团队层面我也在推轻量实践。我们建了一个共享文档，按“需求分析、竞品调研、PRD草稿、评审自查”分了四类提示词，每类下面放两三个经过验证的模板，标注适用场景和已知坑。新同事来了先看这个文档，比口头教快很多。我也提醒自己别把提示词神化，它只是产品经理工具箱里的一把电动螺丝刀，拧螺丝快，但往哪儿拧、拧多紧，还是得我来判断。用得好不好，最终看的是业务结果，不是提示词写得多漂亮。
需求分析这件事，我做久了发现它其实不是一件事，是好几件挨着做。用户调研是听人说话，竞品分析是看别人怎么干，需求澄清是把一团模糊的东西捏出形状。三件事的输入输出完全不同，拿同一个提示词去套，出来的东西一定四不像。我吃过这个亏，有回偷懒，把用户访谈记录和竞品截图一股脑丢给AI，让它“综合分析一下”，结果它给我编了一段既不像访谈总结又不像竞品对比的缝合怪。
后来我学乖了，先拆场景再动笔写提示词，这一步花的时间最值。拿我之前做的一个企业知识库产品来说，用户调研这块，我真正想让AI帮我做的是把六份访谈录音转写稿里的高频抱怨拉出来，不是让它替我判断用户要什么。竞品分析我想让它对比三家竞品的文档权限模型，输出维度是角色粒度、继承规则、例外处理。需求澄清更窄，我只想让它把我跟销售聊完记下的五条零散反馈，改写成三个能被研发看懂的场景描述。拆到这个程度，每个提示词都短，每个都能在半小时内看到能用的中间产物。
我建议你也在自己常用的需求分析场景里做一次这样的切分。切得越细，提示词就越像一把专用螺丝刀，拧什么型号的螺丝就换什么头。切得粗，AI就只能给你一套通用模板，读着顺，用起来全是毛边。
2.2 产品经理需求分析提示词模板的核心结构
我现在的需求分析模板基本固定成四块：场景锚定、任务指令、材料清单、交付规格。场景锚定就是一句话告诉AI“现在是什么阶段、面向谁”。任务指令写清楚要它产出什么动作的结果，比如“提炼”“对比”“改写”“归类”，尽量用动词开头的祈使句。材料清单把我能给的数据、截图、文字整理成编号条目。交付规格定义输出长什么样，包括字段、字数、排序方式。
这块结构不是一开始就有的。我早期写的提示词是一大段话，中间夹着好几个任务，AI经常只响应最后一个。有次我让它“总结用户反馈并给出功能建议”，它上来就列建议，总结只给了两行。我复盘发现，问题出在我把两个动作写在同一段里，也没规定先后。改成两段式之后稳定多了，第一段只让它“按主题归类以下反馈，输出频次和典型原话”，第二段再让它“基于归类结果，输出三个功能建议方向，每个方向说明对应哪些反馈条目”。
模板结构的作用不是让你写得像公文，是让AI每次拿到的时候都知道“我现在站在哪个位置、手上有什么、要交出什么”。这三样齐了，输出的稳定性会明显不一样。
2.3 模板变量设计与可复用字段：角色、目标、输入、约束、输出
角色这个字段我踩过最深的坑就是写太飘。“资深产品经理”“有经验的产品专家”这种等于没写。我现在写成“你是一位做过三年B端权限系统的产品经理，熟悉RBAC模型和多租户架构”。具体到年限和领域，AI在措辞和举例时会更贴地。目标字段必须可验证，我一般写成“输出一份包含五个条目、每个条目不超过40字的清单”，不写“输出一份清晰的清单”。清晰这个词AI理解不了，人跟人的清晰标准还不一样。
输入字段我会标编号，每段材料前面加个标记，方便AI在输出里引用。约束字段我通常放三四条硬性限制，比如“不要编造访谈里没出现的原话”“竞品对比只使用我提供的三家”“每个建议必须对应至少两条输入材料”。输出字段我写得最细，因为返工成本最高，我会把格式、字段名、示例值都写上。
变量可复用的意义在于，改一个字段就能换场景。角色从B端权限换成C端会员，输入从访谈稿换成客服工单，模板骨架不用动。我自己维护了一个表格，左边是五个字段的通用写法，右边是不同场景的替换值。每次新任务来了，从表里挑着拼，比从零写快很多，也比从零写稳。
2.4 需求分析提示词模板的示例化与场景适配
拿一个我常用的用户调研类模板给你看。场景锚定写“你是做SaaS工具的产品经理，正在整理一轮针对中小团队的访谈反馈”。任务指令是“将以下12条反馈按主题归类，输出主题名、反馈条数、两条代表性原话”。材料清单列了12条编号反馈。约束写“不要合并主题，原话一字不改，条数按出现频次降序”。输出规格里我明确“用表格，三列，主题名不超过8个字”。这个模板跑三次，输出结构基本一致，我只用核对归类合不合理。
竞品分析模板的骨架差不多，变量换一下。角色换成“做过三年协作工具的产品经理”，任务改成“对比以下三家竞品的权限设置入口层级”，输入变成我手动整理的三段产品截图文字说明，约束强调“只描述界面可见的层级，不推测后台逻辑”，输出要求是“每个竞品一个段落，段落内按层级从高到低排列”。同一个骨架，换掉角色、任务、输入、约束、输出里的具体值，就能从用户调研切换到竞品分析。
场景适配的诀窍在约束字段上做加减法。调研场景我更在意“不许编”，竞品场景我更在意“不许猜”，需求澄清场景我更在意“不许写技术方案”。约束写对了，AI的越界冲动能被压下去大半。
2.5 从需求分析结果到优先级判断的提示词衔接
需求分析做完，下一步就是排优先级，这两步之间的提示词衔接我专门设计过。我不会让AI直接给优先级排序，那样它只会按“用户呼声高”或者“实现简单”这类单一维度拍脑袋。我的做法是把上一轮分析结果整理成一张结构化清单，每条需求包含“影响用户数、出现频次、涉及模块、预估工作量档位”四个字段，然后写一个衔接提示词，让它“基于以下四个维度，输出一个二维矩阵，横轴是用户价值、纵轴是实施成本，把每条需求放到对应象限里”。
这个衔接提示词的关键在于我把判断维度先定死了，AI只负责按维度摆放，不负责发明维度。有次我忘了定维度，AI自己加了“战略契合度”这个维度，排出来的结果跟我对业务的判断完全拧着。那次之后我学到一个教训：从分析到判断的这步衔接，人要把框架搭好，AI只能在框架里干活。
衔接的另一层作用是留痕。矩阵产出之后，我会把它和原始分析结果放在同一个文档里，评审的时候谁有异议，能顺着矩阵倒推回具体哪条反馈、哪个竞品动作支撑了这个位置。AI帮我把分析到判断的路铺平了，走不走、往哪走，还是我自己定。
写PRD这事我以前一直觉得是产品经理的手艺活，跟写代码一样，得自己一个字一个字敲出来才踏实。去年我们团队接了一个后台权限重构的活儿，排期特别紧，我试着把PRD前半段交给AI出草稿，结果意外地顺。那次之后我开始认真琢磨，哪些部分能交出去，哪些部分必须自己攥着。踩过的坑、翻过的车，这一章我挑几个关键的说。
3.1 AI写PRD的适用条件与产品经理把关要点
我现在的判断挺直接，PRD里“描述已有事实”和“按固定框架展开”的部分，AI先出草稿是划算的。业务背景、现状描述、模块范围、字段清单、验收标准的格式条目，这些有原始材料支撑、有固定结构可循。反过来，涉及决策取舍、资源协商、跨团队利益边界的地方，我不碰AI。有回一个支付链路的PRD，我让AI帮我写“退款异常处理策略”，它给了一套特别周全的兜底方案，看着漂亮，实际需要我们财务和风控同时签字才敢动。它不知道这背后的组织约束，写出来的方案根本落不了地。
把关要点我总结成三条，自己每次评审前过一遍。一条是业务判断，AI写的每个“建议”“优先”“推荐”我都要找到对应的依据，找不到就删掉。另一条是边界条件，PRD里凡是出现“全部”“任何”“自动”这类词，我逐个核对这些边界是不是真的穷尽了，AI最擅长把没想清楚的地方用漂亮的词糊过去。还有一条是事实核对，AI引用的数据、用户数、竞品功能，我会回到原始材料逐条对，对不上的拿红笔标出来。这三条守住了，AI出的PRD草稿能省我至少一半的初稿时间。
3.2 产品经理AI写PRD提示词的任务拆解与上下文组织
一整份PRD扔给AI让它“写一下”，出来的东西我基本没法用。我的做法是把它切成四个块，一块一块喂。背景和目标一块，范围与边界一块，核心流程和状态变化一块，验收标准一块。切块的好处是每块我都能盯着中间产物看，哪块不对当场修，修完再拼。有回我贪省事，一次性发了整份需求，AI把背景写得特别长，把验收标准压缩成三行，明显头重脚轻，我只能整份重来。
上下文组织这块我花的时间最多。写每块提示词之前，我会把这块要用到的材料先整理成一个“上下文包”：包含这部分需求的上游输入（比如调研结论、业务方原话）、接口约束（现有系统的字段和状态）、以及我想要的输出样例。样例这个尤其管用，我给AI一份我之前写过的高质量PRD片段，告诉它“照这个颗粒度和语感来”，输出质量肉眼可见地稳。给一份烂样例出来就烂，这个我试过，不用怀疑。
说白了，上下文组织就是替AI把“它不知道但我知道”的信息提前铺好。产品经理平时脑子里装着的那些隐性知识，不铺到提示词里，AI就只能靠猜，猜出来的东西十有八九要返工。
3.3 PRD生成提示词模板：背景、目标、范围、流程、验收标准
我常用的PRD生成提示词模板长这样，直接给你看骨架。开头角色锚定写“你是一位做过两年以上后台系统的产品经理，熟悉权限模型和审批流”。背景段要求写“使用以下提供的业务方原话和现状问题，输出一段不超过200字的背景描述，只陈述事实，不评价”。目标段要求“输出三条业务目标，每条包含目标描述和衡量指标，指标必须来自我提供的材料”。范围段要求“输出范围内条目和范围外条目两个列表，每条不超过20字”。流程段要求“按主流程、分支流程、异常流程三部分描述，每部分用编号步骤，步骤里出现状态变化的地方用【状态：X→Y】标注”。验收标准段要求“每条验收标准必须包含前置条件、操作、预期结果三个成分，用表格呈现”。
模板里每个字段我都刻意加了约束，没约束的字段AI放飞自我特别厉害。背景那段我专门写了“不评价”，因为AI特别爱在背景里加“当前方案存在严重不足”这种带情绪的判断。流程段的状态标注是我后来加的，起因是有回AI写的流程漏了一个“审批驳回后回到待提交”的状态回退，开发拿着PRD问我对不上，我才发现流程描述缺了状态视角。
这个模板跑熟之后，我基本上把材料贴进去，半小时能拿到一份能拿去内部讨论的初稿。初稿质量肯定到不了评审版，但骨架、字段、格式都齐了，我改起来心里有底。
3.4 多轮迭代提示词：从初稿到评审版的优化路径
我的迭代一般走三轮，每轮提示词的重点不一样。第一轮是搭骨架，用的是上面那个模板，目标就是看到完整结构，内容糙一点没关系。第二轮是填肉，我会把初稿里我自己标了“待补”的地方整理成一条条指令，比如“把范围段里关于导入导出的描述展开成三个子场景，每个子场景说明触发条件和数据流向”。这轮的提示词比较散，一条一条来，不追求一次发完。第三轮是收口，我把整份稿子发回去，让它“以评审者视角逐段挑出描述模糊、前后矛盾、缺少依据的地方，列成清单，不要直接改写”。
第三轮这个提示词是我摸索出来的，效果比我想的好。AI挑问题的时候比写内容的时候更靠谱，它能把一些我自己看顺眼了的毛病拎出来，比如某条验收标准里“正常情况下”这个说法，它问我“正常情况的定义在哪”。这种问题在评审会上被业务方问出来，比我自己现在发现要难堪得多。
还有一个小技巧，我每轮迭代都会在提示词末尾加一句“本轮只输出修改部分，未修改部分用省略号代替”。不加这句，AI每次都把整篇重写一遍，改过的没改过的混在一起，我核对起来眼睛都花。
3.5 PRD提示词输出质量检查与事实一致性校验
AI写PRD最让我警惕的是编事实，而且编得特别像真的。有回它在一份会员体系PRD里写“参考行业头部产品，续费率普遍在65%左右”，这个数字我从没给过它，纯粹是它从训练数据里捞出来的。这种句子混在PRD里最危险，评审的时候业务方看到一个具体数字，很可能就顺着往下讨论了，没人去问这个数字哪来的。
我现在的做法是每份AI产出的PRD过一遍“三查”。一查每个数字、每个引用、每个“行业惯例”后面有没有我提供的材料支撑。二查前后一致性，范围段写了“本期不做导出”，流程段里又冒出导出相关的分支，这种自相矛盾AI犯得不少。三查验收标准能不能对应回目标，每条验收标准我都问自己“这条通了，哪个目标算达成”，对不上的要么改标准要么改目标。三查过完，我会把改过的版本和AI原稿对照着放，评审的时候谁问起某处改动，我能直接说出依据。
这套检查做下来确实费时间，但比评审会上被问住、会后返工要划算。PRD这东西的可怕之处在于，它下游连着开发和测试，一处事实错了，后面跟着错一串。AI能帮我把草稿的坡度降下来，坡上的石头我得自己一块一块摸过去。
我头一年用提示词写需求文档，基本是“打一枪换一个地方”。今天在飞书文档里存一段，明天在微信收藏里翻一条，后天又凭记忆重写一遍。直到有回团队新来的产品经理问我“你上次那个需求分析的提示词能发我一份吗”，我翻了二十分钟聊天记录才找出来，发过去的还是个旧版本。那次之后我下定决心，得把提示词当代码一样管起来。
4.1 建立产品经理提示词库：分类、命名与版本管理
我现在的提示词库放在飞书多维表格里，字段不多但够用：分类、名称、版本号、适用场景、最后修改日期、备注。分类按工作流来切，需求分析、PRD生成、评审检查、用户调研、竞品拆解、数据口径整理，各占一个标签。每一条提示词都有个统一命名，格式是“场景_任务_版本_日期”，比如“需求分析_用户访谈结论提炼_v3_20240612”。这个命名规则看着有点啰嗦，救过我好几回。有次同时跑两个项目，一个用v2一个用v3，输出结果差挺多，我对着名字一眼就分清了谁是谁。
版本管理这块我吃过亏。早期我改提示词从来不记改了什么，直接覆盖原文件。后来发现某个新版本效果反而不如老版本，想回退都找不着。现在我每次改完都在表格里留一行变更说明，写清楚“加了输出格式约束”还是“删掉了角色描述”。团队里谁要用最新版，直接看版本号最大的那条。旧版本我不删，标成“归档”，留着备查。
命名和分类这两件事，本质上是给未来的自己省时间。提示词多起来之后，真正难的不是写，是找。我现在找个“B端权限模块PRD”的提示词，表格里筛一下场景和版本，十秒内能定位到。没有这套分类命名，我估计还在聊天记录里刨。
4.2 需求分析提示词模板与PRD提示词的组合工作流
单独一个需求分析模板跑出来的结论，直接拿去做PRD，中间会漏东西。我现在的做法是把两个模板串成一条流水线：需求分析模板的输出格式里固定留几个“交接字段”，包括用户画像一句话、核心痛点三条、优先级假设一条、待验证问题清单。这些字段就是给PRD提示词准备的上下文包。我跑完需求分析，把这几块内容原样贴进PRD模板的“背景与目标”段落，AI写出来的PRD初稿跟调研结论的贴合度明显高一截。
上个月做会员积分改版，我按这条流水线走了一遍。需求分析提示词先把六份用户访谈纪要压成结构化卡片，卡片里有一条“用户对积分过期提醒的敏感度高于积分兑换品类”。我把这张卡片贴进PRD模板，AI在写“目标”段的时候主动把提醒触达率写进了衡量指标。换以前一次性把访谈纪要和PRD要求混在一起发，AI经常把访谈里的情绪化表达直接搬进背景段，看着热闹但没法用。
组合工作流有个关键动作，我管它叫“锁字段”。需求分析输出里哪些字段必须原样进入PRD，哪些字段允许AI二次加工，我在两个模板的衔接处写死。锁定的字段AI不能改措辞，比如痛点描述里的原话引用。允许加工的字段AI可以重组，比如优先级假设。这么一来，调研结论在传递过程中不会走样，AI也有发挥空间。
4.3 面向不同产品场景的提示词扩展：B端、C端与平台型产品
我同时跟B端后台和C端小程序两条线，用同一套提示词模板会打架。B端产品的提示词里，我重点加三样东西：权限矩阵、审批状态机、异常回退路径。写PRD的时候我会在模板里加一句“每个功能点必须说明涉及哪些角色、每个角色的操作权限边界在哪”。C端产品的提示词更看重用户旅程和情绪节点，模板里会要求“按首次使用、高频使用、流失预警三个阶段描述体验路径，每个阶段标注用户可能的情绪状态”。平台型产品又是另一套，重点在多方角色规则和治理机制，提示词里得把“平台方、供给方、需求方”三方的关系写清楚。
我试过把B端那套权限描述直接套到C端会员体系上，AI写出来一段“会员等级变更需经两级审批”，C端用户改个昵称还要审批，明显不对劲。后来我给每个产品场景单独存了一份提示词变体，命名里带上“B端”“C端”“平台”的标签。变体之间的差异不大，核心结构一样，差别在约束条件和输出示例上。B端变体里塞的是权限表格样例，C端变体里塞的是用户旅程画布样例。
场景扩展还有一个笨办法但管用：每接一个新类型的项目，我先花半小时把旧提示词跑一遍，看哪些地方AI开始胡编，胡编的地方就是需要加场景约束的地方。做第一个平台型项目的时候，AI老把平台规则写成线性流程，漏掉多方博弈。我在提示词里补了一段“请列出至少两个角色之间的利益冲突点”，输出质量才稳住。
4.4 提示词效果评估、反馈闭环与迭代机制
提示词好不好用，我原来凭感觉。现在用三个硬指标来评：输出可用率、人工修改时长、评审会上被挑出的问题数量。可用率看初稿有多少段落能直接留用，我一般按段落数，能留用的除以总段落数。修改时长拿手机计时，从打开初稿到改完发评审，超过四十分钟的提示词我会标黄。评审问题数量更直接，每次评审会我记下跟PRD描述相关的问题条数，同一个提示词连续两次问题超过五条，进迭代清单。
反馈闭环我放在每周五下午，花二十分钟翻一遍这周用过的提示词，把当时随手记的问题归归类。问题分三种：输出结构不对、事实编造、语气跑偏。结构问题改模板字段，事实问题补上下文约束，语气问题换输出示例。改完升个版本号，变更说明写一行。这套动作看着琐碎，坚持两个月之后，我常用那七八条提示词的修改时长平均降了三分之一。
迭代机制里我特意留了一条“不迭代”的规则：某个提示词连续用五次都没大毛病，我就把它冻结成稳定版，不再折腾。产品经理最容易犯的毛病是过度优化，提示词改来改去，改到最后自己都不知道哪版好了。冻结版加个锁的标记，谁想动先找我聊。
4.5 产品经理提示词实践的合规、安全与协作规范
提示词里贴业务数据这事，我踩过一次红线。有回图省事，把一份包含用户手机号后四位的客服工单直接粘进提示词让AI总结，发出去之后才反应过来。那之后我给自己定了条死规矩：进提示词的材料先过一遍脱敏，手机号、身份证、订单号、内部成本价，一律替换成占位符。团队共享提示词库的时候，我在表格里加了一列“敏感等级”，标红的提示词禁止直接复制到外部工具，只能在内网环境跑。
协作规范我们团队磨合了两个月才定下来。共享库里谁都能看，谁都能提修改建议，但改完必须走一次“双人试跑”，两个人拿同一个任务分别跑新旧版本，对比输出差异再决定合入不合入。提示词的所有权归创建者，其他人可以复制一份改成自己的分支，分支命名加上自己名字缩写。这么定下来之后，库里的提示词从最初的十几条长到六十多条，没出现过互相覆盖的乱子。
安全这块我还多加了一道检查：提示词里不嵌外部链接，不让AI去抓取未经验证的网页内容。有回一个同事的提示词里写了“参考这个链接里的竞品定价”，AI返回的内容里混进了一段来路不明的价格表，差点被写进PRD。现在我的模板开头固定有一句“仅使用我提供的材料，不引用外部来源”。这句话挡不住所有问题，但至少让AI知道边界在哪。
这套体系跑到现在，我最大的感受是提示词管理跟产品需求管理一个道理：没有分类就会乱，没有版本就会丢，没有评估就会飘。产品经理平时最烦别人说“你先随便写写”，轮到自己管提示词，千万别随便。
