1.1 产品需求拆解提示词的定义、目标与价值：从模糊需求到可执行任务
我做产品这些年，最怕听到的一句话就是"这个需求很简单，你看着办"。看着办三个字背后藏着多少坑，只有真正拆过需求的人才懂。产品需求拆解提示词，说白了就是我写给AI的一套"翻译说明书"，把老板嘴里那句"做个智能推荐"翻译成研发能看懂、测试能验收、运营能上手的任务清单。它不是魔法咒语，更像是一份结构化的沟通契约，告诉AI你是谁、你要什么、边界在哪、交付物长什么样。
我理解它的核心目标就一个：把模糊性压缩到最低。需求从人脑里出来的时候天然是毛茸茸的，带着情绪、带着省略、带着"你懂的"这种默契假设。提示词要做的事情，是逼着我把这些毛茸茸的东西一条条捋清楚，用AI能执行的格式固定下来。价值也体现在这儿，我不用再靠开会扯皮来对齐理解，一份好的拆解提示词本身就是对齐的结果。
从另一个角度看，这东西的价值还在于可复用。我团队里有个做电商后台的哥们，他第一次写拆解提示词花了四十分钟，后面同类需求直接改几个变量就能跑，省下来的时间够他多喝三杯咖啡。这种效率提升不是线性的，是随着模板沉淀越来越明显。我自己统计过，用成熟的拆解提示词跑一遍，需求遗漏率能降一半以上，当然这个数字因团队而异，别拿它当KPI。
1.2 关键词关系拆解：产品需求、需求拆解、提示词模板与AI示例的关联
这几个词老有人混着用，我刚开始也绕进去过。产品需求是原材料，是一堆待加工的矿石。需求拆解是加工工艺，是把矿石炼成零件的动作。提示词模板是模具，规定了这次加工用什么形状、什么精度。AI示例是样板件，让我看看这套模具跑出来的成品长什么样。四者是一条流水线上的不同工位，缺了哪个环节都会出问题。
我画过一张关系图贴在工位上，中间是"需求拆解"这个动词，左边箭头来自"产品需求"，右边箭头指向"任务清单"，上面压着"提示词模板"当控制面板，下面垫着"AI示例"当参照系。这么一摆就清楚了：需求本身决定拆解的深度，模板决定拆解的稳定性，示例决定拆解的可预期性。有次我拿一份没有示例的模板去跑，AI给我的输出格式五花八门，返工率特别高，从那以后我坚持每个模板至少配两个示例。
我还想强调一点，这四个词的关系不是静态的。产品需求变了，模板得跟着调；AI模型升级了，示例也得更新。我吃过亏，一个模板用了大半年没动，结果模型能力变了，输出的颗粒度跟团队预期严重脱节。后来我养成了每月review一次模板和示例的习惯，花不了多少时间，但能避免很多暗坑。
1.3 典型适用场景与不适用边界：需求澄清、功能拆解、验收标准与优先级判断
适用场景我总结成四类，都是踩坑踩出来的。需求澄清排第一，原始需求像团雾的时候，用提示词逼AI追问几个关键问题，能把雾吹散不少。功能拆解排第二，一个大功能拆成子任务、子任务再拆成开发项，AI干这个比人快，尤其是拆到第三层第四层的时候。验收标准排第三，我让AI按"给定-当-那么"的格式写，比我自己憋快多了。优先级判断排第四，这个稍微特殊一点，AI给的是参考排序，最终拍板还得靠人。
不适用边界我也得说清楚，不然容易走火入魔。涉及商业机密或者未公开战略的需求，我不会往公有模型里扔，这个没得商量。需求本身还在剧烈摇摆、一天变三次的时候，拆解提示词跑出来的结果大概率是废纸，不如先等需求稳定。还有那种强依赖行业隐性知识的拆解，比如某些传统行业的合规细节，AI给的东西看着像模像样，实际一用就露馅，这种我建议人工主导、AI打辅助。
有个判断标准我常用：如果这个需求拆错了，代价是什么？代价小、试错成本低的，放心让AI拆。代价大、牵一发动全身的，我宁可自己多花半小时手拆。这个标准帮我省了不少返工时间，也避开了几次可能的事故。
1.4 高质量产品需求拆解提示词的构成要素：角色、上下文、输入、约束、输出格式与验收标准
我理想中的高质量拆解提示词有六个要素，像六根柱子撑起一个棚子。角色是让AI知道自己是谁——是资深产品经理还是技术架构师，视角完全不一样。上下文是给背景，业务阶段、用户画像、历史包袱都得交代。输入是把原始需求原封不动贴进去，别自作聪明做摘要。约束是划红线，哪些不能碰、哪些必须遵守。输出格式是定形状，表格还是列表、字段有哪些。验收标准是定质量线，什么算合格、什么算不合格。
这六个要素里，我踩坑最多的是"约束"。早期我老忘写约束，AI就放飞自我，给我加一堆我没要的功能，美其名曰"建议拓展"。后来我学乖了，每次都在约束里写明"不要超出输入范围发挥""不确定的地方标注待确认"，输出质量立马稳定很多。输出格式也一样，不写清楚AI就按自己的审美来，有时候给我整一大段散文，我还得手动转成表格。
验收标准这个要素容易被忽略，但它是闭环的关键。我会写类似"每条子任务必须包含负责人角色和预估工时""验收标准必须可测试、不含主观形容词"这样的要求。有了验收标准，AI输出完我扫一眼就知道合不合格，不用逐字逐句抠。这六根柱子缺一根，棚子就漏雨，我自己的经验是宁可多花五分钟写全，也别省那五分钟事后返工。
1.5 常见误区与使用原则：避免需求遗漏、过度拆解与提示词堆砌
误区这东西，我犯过的比听过的多。需求遗漏排第一，提示词写得漂亮，但原始需求里的边缘场景没覆盖到，拆出来的任务清单看着完整，一上线就出问题。我现在的对策是让AI先复述一遍它理解的需求范围，我确认没漏再往下走。过度拆解排第二，一个三天能做完的功能拆出四十个子任务，研发看了想打人。拆解深度得跟团队规模和迭代节奏匹配，小团队拆到开发项就够，别拆到函数级。
提示词堆砌是个隐蔽的坑。我见过有人写拆解提示词写了两千字，角色设定写了五段，约束列了二十条，结果AI被绕晕了，输出反而不如简单提示词稳定。提示词不是越长越好，每一条都得有存在的理由。我自己的原则是能删就删，删完还成立就说明本来就不该有。有次我把一个模板从一千二百字砍到四百字，输出质量没降反而升了，因为干扰信息少了。
最后一条使用原则我想说：提示词是工具不是目的。我见过团队花大量时间打磨提示词模板，却忘了最终要的是能落地的需求拆解结果。模板够用就行，把精力留给需求本身的理解和跟研发的沟通。我自己的做法是模板稳定后就不再频繁改动，除非遇到明确的失败案例才迭代。工具服务于人，别反过来被工具牵着走。
2.1 通用模板结构：背景、目标、用户、范围、约束、输出格式与质量要求
上一章我提过拆解提示词的六根柱子，落到实际写模板的时候，我一般会把它们排成七个槽位。多出来的那个是“范围”，单独拎出来写，因为我踩过太多次亏。背景、目标、用户、范围、约束、输出格式、质量要求，这七块凑齐了，一个模板才算能拿去跑。我自己的习惯是先写个空壳子，每个槽位留两三行提示语，用的时候往里填内容，省得每次从白纸开始。
空壳子长这样，我给团队新人看的版本简化过：
【背景】业务阶段、现有系统、历史包袱
【目标】这次拆解要解决什么问题，交付什么
【用户】需求的使用者是谁，他们的核心诉求
【范围】包含什么，明确不包含什么
【约束】技术、合规、时间、资源的红线
【输出格式】表格/列表，字段清单，层级深度
【质量要求】可测试、可追溯、无歧义
这份壳子看着朴素，真正管用的是“范围”和“质量要求”这两栏。我见过太多模板只写背景和目标，AI输出一大堆看着热闹的东西，仔细一查全在范围外。
“约束”这一栏我吃过血亏。有回做一个会员体系的需求拆解，我忘了写“不要新增付费等级”，AI给我设计了三个新等级还配了价格策略，会上被运营总监当场问住。从那以后我写约束都会把“不做清单”列出来，哪怕显得啰嗦。输出格式同理，不写清楚，AI可能给你散文、可能给你嵌套五层的列表，全看它心情。
2.2 分阶段模板设计：需求澄清、用户故事、功能拆解、验收标准与优先级排序
把五个阶段塞进一个模板里，我试过，效果不好。AI会贪心，每个阶段都给你一点，每个阶段都不深。后来我改成拆开做，一个阶段一个模板，跑完一轮再跑下一轮，中间我人工看一眼。这种做法慢一点，但返工率低很多。
需求澄清阶段的模板最特殊，我要求AI只提问、不出方案。提示词里明确写“你的任务是列出不超过八个澄清问题，按重要性排序，不要给出任何解决思路”。这么限制之后，输出干净多了。澄清问题我一般关注三类：边界在哪、异常场景怎么处理、成功的衡量标准是什么。
用户故事阶段我让AI按“作为……我想要……以便……”的格式写，每个故事附一个优先级初判。这里有个小技巧，我会把用户角色清单一起喂进去，不让AI自己编角色，编出来的角色往往跟真实用户差十万八千里。
功能拆解阶段是重头戏，我要求拆到三层：模块、功能点、开发任务。三层封顶，再往下拆属于研发自己的事，产品别越界。验收标准单独一个模板，用“给定-当-那么”的格式，每条必须能被测试用例覆盖。优先级排序我放在最后跑，用MoSCoW做初排，AI给的是参考，拍板还是人。
有一回我偷懒，想用一个模板把五个阶段一次跑完，结果AI给的澄清问题像功能列表，用户故事里混着技术方案，看着挺全，实际哪块都用不了。那次之后我彻底放弃“一站式模板”这个念头，分阶段跑虽然多几步操作，脑子反而轻松。
2.3 AI产品需求拆解提示词示例：智能客服、推荐系统、生成式功能等场景
AI类产品的需求拆解跟传统功能不太一样，模型行为、数据依赖、兜底策略这些都得单独考虑。我拿三个跑过的场景说说。
智能客服的拆解，我会在提示词里特别强调“意图识别边界”和“转人工条件”。模板片段大概这样写：背景是现有客服每天承接三千会话，目标是把常见问题自助解决率提到六成，范围包含售前咨询和售后查询，不包含投诉工单。输出要求里我加了一条“每个意图必须写明置信度阈值和降级路径”。AI跑出来的结果里，意图清单、话术配置、知识库更新任务、人工接管规则这几块会比较完整。它容易漏的是多轮对话里的上下文继承，我一般会在约束里补一句“考虑用户中途切换意图的情况”。
推荐系统的拆解，我关注的是冷启动、召回、排序、重排这几段。提示词里我会把现有数据规模写清楚，比如“日活十万，物品池两万，用户行为稀疏”。AI给的拆解通常在特征工程和离线评估上比较细，在线AB实验的设计容易一笔带过。我的对策是在质量要求里写明“每个策略必须配实验方案和回滚条件”。还有个坑，AI默认推荐系统是给电商做的，做内容推荐的时候得在背景里点明场景，不然它给的指标全是GMV相关的。
生成式功能的拆解最考验提示词功底。做一个文案生成工具，我会把输入类型、输出长度、风格约束、审核环节全列进去。提示词里我常写一句“列出至少五类失败输出及其处理方式”，逼AI想兜底。它给的结果里，内容安全审核、生成失败重试、用户反馈闭环这几块经常被弱化，我得手动补。这三个场景跑下来，我的体会是AI产品的拆解提示词必须比传统功能多写“不确定性处理”这一章，模型行为本身就是不确定的，拆解不能假装它确定。
2.4 产品需求拆解提示词模板的变量化与复用：团队模板库、参数替换与版本管理
模板写多了，散落在各人的文档里，用的时候找不到，这是团队常态。我推动过一次模板库的整理，做法不复杂：建一个共享目录，按业务域分文件夹，每个模板文件头部写清楚适用场景、维护人、最后更新时间。文件名带版本号，比如智能客服_拆解_v2.3.md。看着像小事，实际省下的沟通成本很可观。
变量化是复用的关键。我把模板里会变的部分抽成占位符，双大括号包起来，像{{业务域}}、{{用户角色清单}}、{{拆解深度}}、{{输出格式}}。用的时候替换掉就行，不用改主体结构。参数替换听起来机械，实际有讲究，{{拆解深度}}我一般只允许填“模块级”“功能级”“任务级”三个值，填别的AI容易理解偏。
版本管理我吃过教训。有段时间三个人各自改同一个模板，改完互相不知道，输出风格飘来飘去。后来定了规矩：模板改动走简单的变更记录，写清楚改了什么、为什么改、影响哪些场景。版本号用主次两级，主版本变了说明输出结构有大调整，次版本变了只是措辞优化。团队模板库这东西，维护成本主要不在建，在持续保鲜。我的做法是每季度过一遍，把三个月没人用的模板标灰，半年没人用就归档。
2.5 示例对比分析：弱提示词与强提示词在拆解完整性、可执行性和一致性上的差异
光说结构有点空，我拿真实跑过的两组提示词对比一下。需求是“给内容平台做一个AI摘要功能”。
弱提示词版本就一句话：帮我拆解一下AI摘要功能的需求。AI给回来的东西洋洋洒洒，有功能列表、有技术建议、有运营方案，看着挺丰富。仔细看，摘要长度没定义，多语言支持没提，失败重试没写，验收标准一条没有。这种输出拿去评审，研发会问一堆问题，等于没拆。
强提示词版本我写了这些：
【背景】内容平台，日更文章两千篇，现有用户阅读完成率偏低
【目标】拆解AI摘要功能，输出可进入开发评审的任务清单
【用户】普通读者、内容编辑、运营
【范围】包含：摘要生成、长度控制、多语言、失败兜底
不包含：个性化摘要、摘要分享
【约束】单篇摘要生成耗时不超过三秒，成本控制在每篇一分钱内
【输出格式】三层结构表格：模块/功能点/开发任务，每条附验收标准
【质量要求】验收标准必须可测试，不确定项标注“待确认”
两组输出放在一起对比，差距主要在三个维度上。完整性上，强提示词版本覆盖了多语言、超时兜底、成本约束这些边缘项，弱版本全漏了。可执行性上，强版本每条任务都带验收标准，研发能直接估工时，弱版本的任务描述像功能愿望。一致性上更明显，强版本我换三个不同时间跑，输出结构基本一致，弱版本每次跑出来的组织方式都不一样。
我自己的观察是，提示词强弱的分水岭不在字数，在有没有把“边界”和“验收”写进去。弱提示词给AI留了太多自由发挥的空间，它就会往“全面”上靠，全面往往等于不聚焦。强提示词把该锁的锁死了，AI反而能把精力放在拆解深度上。这个道理我讲给团队新人听，他们一开始不信，跑两组对比就服了。
3.1 线性工作流：从原始需求输入到拆解结果评审与落地
我自己的跑法没什么花哨的，从拿到原始需求到拆解结果落地，大概就是一条线走到底，中间卡几个检查点。原始需求进来，我先做一轮人工预处理，把能问清楚的先问清楚，问不清楚的标上“待确认”再往下走。这一步不能省，我试过直接把业务方发的语音转文字扔给AI，出来的东西偏得离谱，因为里面夹杂着大量口头语和前后矛盾的信息。预处理完我才把需求粘进澄清模板，让AI出问题清单，我拿着问题清单再去找业务方或者研发确认一遍。
澄清结果回来之后，我按顺序跑用户故事、功能拆解、验收标准、优先级排序，一个模板一个模板来，中间不跳步。跑功能拆解的时候我会停下来做一次人工重排，AI给的模块划分有时候太粗，有时候又太碎，得按团队的实际开发节奏调一下。验收标准跑完我会单独抽检，专挑那些“看起来没问题”的条目看，幻觉往往藏在这种地方。
最后一步是评审。我把拆解结果整理成一份文档，拉上研发、测试、运营过一遍，重点看三件事：有没有漏掉异常分支、有没有研发看不懂的任务描述、优先级跟当前迭代目标冲不冲突。评审完的版本存进项目库，标注版本号。这套流程跑顺了之后，我一般能把拆解环节控制在半天以内，比纯手工快不少，但脑子确实也累，因为每个检查点都得认真看，糊弄不过去。
3.2 与产品方法结合：JTBD、用户故事、MoSCoW、验收标准与需求追溯
提示词不是孤立用的，我一般会把它嵌在平时用的产品方法里。JTBD我常用在澄清阶段，提示词里会写“从用户想要完成的任务角度列出场景”，AI会给出一批“当……我想……”的句式，我挑几个有代表性的拿去跟用户访谈，比泛泛问“你想要什么功能”好使。不过JTBD那套话术AI掌握得一般，经常把任务和功能混着说，我一般只拿它当访谈提纲的素材来源，不当作最终输出。
用户故事和MoSCoW基本是连着用的。用户故事跑完一批，我直接喂给优先级模板，让AI按MoSCoW做初排。这里有个坑，AI做优先级判断的时候容易把“技术上容易实现”当成“重要”，排出来的Must常常是一堆容易做的小功能，真正跟业务目标挂钩的大块反而进了Could。我现在的做法是在提示词里把业务目标写死，明确告诉AI“跟本季度留存目标无关的不要放进Must”，这样能压住不少偏差。拍板当然还是人，但初排结果拿来做讨论底稿挺省事。
验收标准我坚持用“给定-当-那么”格式，每条必须能被测试用例覆盖。这不是我较真，是吃过亏。有回验收标准写得太虚，测试同学直接来找我，说这条没法测，最后返工重写。需求追溯的链条我一般靠命名规则串起来，功能点编号对应验收标准编号，验收标准再对应测试用例编号，断了一环就能看出来。追溯这件事AI帮不上太多忙，得靠人盯，但提示词里我会要求它给每个功能点打上来源标记，标明是从哪个用户故事或哪个原始需求拆出来的，这样后面核对的时候省点翻找的功夫。
3.3 评估指标与常见失败模式：完整性、可执行性、一致性、可追溯性与幻觉风险
评估拆解结果好坏，我主要看五个维度。完整性看有没有漏掉异常分支、边界条件、非功能需求，我一般拿一个检查清单对着过，清单不长，十几条，但每次都能逮到几条漏网的。可执行性看研发能不能直接拿去估工时，标准很简单，随便抽三条任务描述读一遍，读不懂就是不可执行。一致性看同一份需求隔几天再跑一遍，输出结构有没有跑偏，跑偏太多说明提示词约束不够。
可追溯性和幻觉风险是绑在一起看的。AI特别喜欢编一些看起来合理但不存在的细节，比如凭空造一个接口名、假设一个不存在的系统能力、或者把行业惯例当成既定事实写进去。我做抽检的时候会专门标记那些“写得很具体但来源不明”的条目，逐条核实。有一回AI在拆解里写“现有系统已支持消息队列”，我拿着去问架构师，人家说根本没这回事，差点闹笑话。从那以后我要求AI在输出里对假设性内容统一标注“假设”，不标注的一律当幻觉处理。
失败模式里最常见的还是过度拆解和需求遗漏这两头。过度拆解的特征是任务粒度太细，细到研发觉得你在他工位上盯着他干活。需求遗漏的特征是模块之间衔接处没人管，比如登录和支付之间的状态同步，AI默认两边各自管好自己就行，实际上一联调全是坑。这两个毛病我现在靠两个土办法对付：拆解深度在提示词里锁死三层，不许多拆；模块交界处单独列一栏“跨模块依赖”，强制AI填。
3.4 迭代优化与团队协作：提示词评审、版本管理、知识库沉淀与跨角色协同
提示词这东西不迭代就是废物，因为业务在变，团队在变，AI模型自己也在变。我团队里每两周会花半小时过一遍最近用的拆解提示词，重点看三件事：哪些提示词跑出来的结果被人工改得最多、哪些输出格式最近老出问题、有没有新场景需要补模板。改得最多的提示词优先优化，这个信号最直接，说明AI没理解到位。
版本管理我沿用了上一章说的那套规矩，主版本号和次版本号分清楚，改动必须留记录。评审环节我拉过一次研发和测试一起参加，让他们当面说哪条拆解看着就烦、哪条看着靠谱，反馈比产品自己闭门造车强太多了。测试同学尤其有发言权，他们看验收标准最准，哪条没法测他们一眼就能挑出来。
知识库沉淀说白了就是踩过的坑别踩第二遍。我弄了个简单的文档，按场景记录“提示词原文—AI原始输出摘录—人工修正内容—修正原因”四栏，攒了快上百条。新人进来先翻这个文档，比看什么教程都管用。跨角色协同上我有个不成熟的经验，别指望业务方和研发主动来看提示词，让他们看结果就行，把结果评审会开好，比逼他们学提示词写法现实得多。
3.5 合规与风险控制：敏感信息处理、需求偏差校正与AI输出的人工复核机制
敏感信息是我最不敢马虎的一块。原始需求里经常带着用户数据样例、内部系统截图、未公开的营收数字，这些东西往AI工具里粘贴之前必须脱敏。我的做法是定了一份敏感字段清单，手机号、身份证号、真实用户名、金额数据、内部系统名称都在清单上，粘贴前过一遍，该替换的替换成占位符。团队里有人嫌麻烦，我就拿真实案例说话，有个同行把用户数据粘进去跑拆解，后来发现工具端留存了记录，折腾了好一阵子。
需求偏差校正是另一层保险。AI拆解出来的东西会悄悄偏离原始需求，偏的方式还特别隐蔽，比如把“提升用户满意度”偷换成“提升功能使用率”，听着差不多，实际是两个方向。我的办法是在评审时专门安排一个环节，拿原始需求原文逐条对照拆解结果，看语义有没有漂移。这个环节花不了十分钟，但每次都有人惊呼“这还是我当初提的那个需求吗”。
人工复核机制我是这么定的：AI输出必须经过至少一次人工过目才能进入下游环节，关键项目要两次，一次产品内部看，一次跨职能评审看。复核人不是走过场签字，得真的逐条看，我要求复核人在文档里标出自己改过的每一处。这个要求一开始被吐槽烦，后来大家发现改了哪些地方有记录，回头追责的时候反而省事。复核环节我自己的定位是兜底用的，不指望它把AI输出变完美，但至少保证进入开发的东西不会离谱到没法收拾。
