提示工程的需求挖掘，听起来像个“伪命题”。我刚接触AI应用项目那阵，团队里经常说“提示词嘛，多试几轮就出来了”，可真到上线前，业务方突然抱怨“这答案不对味儿”，技术同学却觉得“指标明明都达标了”，两边一对照，才发现问题从来不出在提示词本身，而是一开始的需求就没被挖明白。这几年我陆陆续续参与过不少提示词开发项目，慢慢摸出一个结论：提示工程真正难的不是写提示词，而是把团队里每个人脑子里的“隐性需求”变成大家都认的“显性需求”。这篇文章就是想把我实操下来的协作技巧整理出来，给正在做提示工程落地、或者带团队做AI功能需求的同学一些能直接抄的作业思路。
1. 提示工程的需求挖掘，难点到底在哪
1.1 “提示词很简单”造成的需求错觉
先说一个真实场面。某次项目启动会上，业务负责人说得很轻松：“我们就是想做一个自动回复客户问题的机器人，你们用提示词把话术调好就行。”技术负责人也接得很快：“没问题，给点样例我们就开始。”结果呢？开发三天后，业务方拿自己真实聊天记录去测，发现机器人回答的腔调太“机器味”，宁可不用。这时候两边坐下来复盘，业务方说“我要的是客服那种热情又专业的感觉”，技术方说“你之前给我的样例里没体现热情”。问题就出在这——大家都拿“提示词很简单”当默认前提，根本没把需求挖到可执行颗粒度。
提示词是否简单，取决于你看它的角度。单看一条指令，确实就是几行自然语言。但把它放进真实业务流，它就是模型行为的“控制面板”，背后牵扯的是模型能力边界、输入格式、输出规范、异常兜底、风格偏好、安全边界一大堆因素。团队一旦把提示词当成“人人都能写两笔”的简单物件，需求挖掘阶段就会集体偷懒，默认对方听懂了自己的意思。这是第一个难点。
1.2 传统需求挖掘方法为什么会失效
传统软件工程里，需求挖掘讲究的是PRD、用例图、业务流程图，强调逻辑完整、边界清晰。这套方法论放到提示工程里不是完全没用，但有一个致命错位：提示工程的需求，很多不是“功能”层面的需求，而是“语义交互”层面的需求。比如你要做一个内容摘要工具，“支持输入长文本、输出摘要”是功能需求；但“摘要语气是冷静客观还是活泼轻快”“字数上限是多少”“遇到矛盾信息怎么处理”“用户故意输入乱码怎么办”，这些全是语义交互需求，你很难用流程图把它们画出来。
我在实践中发现，用传统方式挖需求，最典型的结果是需求文档写得非常厚，真到了写提示词的人手里，能落地的却只有寥寥几行。原因在于传统方法擅长描述流程，但提示词需要的是“样例+反例+边界约定”，这个载体完全不同。如果团队还用老一套去开会、写文档、评审，需求挖掘就变成了形式主义，会上都说听懂了，测试时全露馅。
1.3 团队协作中被掩盖的“信息断层”
还有个容易被忽视的点，是信息切断。提示工程需求挖掘实际牵扯四类角色：业务方（懂用户和场景）、产品设计（懂交互路径）、技术开发（懂模型调用和系统约束）、测试或评测人员（懂验收标准）。奇怪的是，很多项目里这四类人从头到尾没在同一个页面同步过。
比如业务方告诉你“要专业”，他心里想的专业是“引用数据时要严谨”；产品设计的专业是“回复里要有明确结构”；技术同学的专业是“模型输出必须稳定可解析”。同一个词，三套解释。如果不通过协作机制把这种信息断层补上，提示词写得再好，也总有人觉得不对。所以我要说的协作技巧，关键词不是“文档模板”，而是“让对的人在对的环节，用对的方式，把隐性信息挤出来”。
2. 一套适合团队的协作框架：三段式需求挖掘
我后来在团队里逐渐形成了一套自己的需求挖掘框架，一共三段。很多朋友问过我有没有现成模板，我的回答是模板不重要，重要的是每一段解决什么问题、产出什么东西。
2.1 第一段：从业务目标到使用场景
第一段做的工作，是逼着业务方把“想当然”变成“场景描述”。具体做法很简单，开会时不问“你想要什么功能”，而是问“用户在什么情况下会用到这个东西、打开时他正在经历什么、他手上有哪些材料、他期待得到什么结果”。
举个例子。某回我们做一个行业问答助手，业务方最初给的需求是“回答用户关于行业政策的问题”。这种需求没法写提示词。我们就带着问法聊了一轮，挖出来的场景是：用户多为一线业务人员，遇到政策变动时想快速确认“这事儿现在能不能办、需要什么材料”；他们没耐心读长回答，希望直接得到“可以/不可以”加简单理由；他们有时连准确的问题都描述不清，只能输入一个模糊关键词。到这一步，需求就具象了：提示词需要引导模型识别意图，先判断用户是来查政策的还是来办事的，再决定回答结构。
这一段的产出物，建议是一张“场景清单”，包含：触发场景、用户状态、输入形态、期望输出形态、典型情绪。这张清单不需要很正式，但每个条目都要能说出具体情境，而不是抽象形容词。
2.2 第二段：从场景样例到输入输出约定
第二段是整段需求挖掘里最容易出成果，也最容易被跳过的环节：把典型场景写成至少10组（输入，期望输出）样例。为什么要10组？因为模型行为需要从样例里归纳，团队沟通也需要从样例里建立共同语言。理想大于等于10组，太少体现不出边界，太多团队整理成本又高。
操作上我习惯把所有样例分成三个桶：典型正向、边缘情况、典型反例。典型正向样例是告诉团队“正常情况下我们要什么”；边缘情况是“输入不完整、输入过长、输入包含情绪化表达”这些场景；典型反例则是“我们希望模型绝对不要输出什么”。
这里有个很关键的技巧：反例一定要和正例成对出现。团队挖需求时最容易犯的错是只有正例，没有反例。比如做客服问答，正例是“客户问退货流程，回答退货规则”，听起来没问题。但反例是什么？是“客户发泄情绪时，模型不应该生硬回复规则，而应该先安抚再提供帮助”。这类需求，你不在提示词里写明边界，模型大概率会用“理性但冷漠”的方式翻车。我每次把反例列出来，业务方都会愣一下，说“对，这个我没想到”。这就是协作挖掘的价值——互相激发。
第二段的产出物是一份“输入输出约定”，本质上就是一组可测试的样例集。它既当开发依据，也当验收基线。
2.3 第三段：从演示版到评测基准
前两段做完，团队通常会觉得自己已经“很懂需求了”。第三段才是整个框架里最反直觉的：放弃“一次性做到完美”的想法，先快速做出一个只有正向样例支撑的初版提示词，拿来当靶子，然后再用第二段积累的边界反例去“打靶”。
为什么要把评测基准放在最后而不是最前？因为团队在没有看到真实模型行为之前，对“好”的定义永远是模糊的。初版提示词哪怕很简单，只要能把正向样例跑通，大家就有了一个共同参照物。接下来，拿着反例一个一个去测，每测挂一个，需求就多冒出来一条。有次我陪某团队做方案推荐助手，初版相当能打，业务方都准备确认了，结果把“用户在夜里11点问‘今天还来得及预约吗’”这个边缘样例抛进去，模型完全没考虑营业时间因素，愣是按照通用流程回答了。这一个样例，直接逼出了一整条“时间感知”需求。
第三段的产出物是一套“评测基线”：至少包含20到30个覆盖正向、边缘、反例的评测用例，每一类都要责任人确认过“这样可以接受”或“这样不能接受”。我发现一旦到了这一步，团队之间的讨论就不再是“我觉得不行”这种主观争论，而是“用例编号7这个情况，模型没做到，我们现在要调整提示词还是接受？”
2.4 为什么这三段顺序不能乱
有团队想把顺序倒过来，先做演示版再挖需求，觉得更敏捷。我的经验是：为了“快速看到东西”，可以先用最粗的提示词做出演示版，但正式的需求挖掘流程，一定得按场景->样例->评测的顺序走。一旦先有演示版，业务方容易被第一印象锚定，后面你再问他场景，他会在演示版基础上做残缺修补，而不是从用户视角重新梳理。顺序这件事，本质上是保护需求挖掘的完整性。
3. 协作中我用过的五个实用技巧
框架讲完，说几个更落地的技巧。这些内容不是教科书里写的，是我在一次又一次需求挖偏、返工、救火之后攒下来的实操经验。
3.1 让业务方先“演示”而不是先“描述”
需求会议上最经典的低效场景，就是业务方坐在那里凭记忆描述用户行为：“用户可能会输入一句很长的话，然后希望我们给他一个准确的判断。”这种描述抽象、有水分，听完你根本没把握到底长什么样。
我的办法是，需求会议开场先不发问，让业务方把自己印象最深的三段真实用户交互录屏或聊天记录投屏出来，大家一起看一遍。看完再问：这里面哪些地方让用户满意、哪些让用户放弃了、哪些是你们产品现在回答不了的。只有看到实际的用户输入，团队才会意识到“原来真实输入这么短”“原来用户真的会夹杂很多情绪词”“原来有人会把手机号写在句子里”。这种直观信息比任何需求文档都扎实。
如果业务方拿不出现场记录，退而求其次，请他现场模拟用户演一遍也可以。要求是必须带语气、带场景、带输入原文，不许用“比如用户可能说…”这种概括句式。我发现只要这个环节做得认真，后面聊到样例时，业务方明显有实物可依，效率翻倍。
3.2 把提示词草稿搬到会议桌上看
传统需求评审会上，大家看的是PRD；提示工程项目的评审会，我会额外要求把当前版本的提示词草稿直接投屏出来，逐字过一遍。这个动作看着很简单，效果却很惊人。
提示词草稿一旦暴露在所有人面前，每个角色都能在不同位置给出反馈：业务方看到的是表达口吻是否符合品牌调性，产品注意到的是输出结构是否包含必要字段，开发看到的是模型输入长度限制和系统提示一致性，测试人员则关心每一处约束条件是否具备可检查性。曾经有回，一段提示词里写了“回答要亲和”，业务方觉得OK，测试的同学却问“亲和怎么界定？能不能加个判断标准，比如鼓励性语气、适当使用感叹词”。这一问，直接让“亲和”从一个主观感受变成一个可写进评测用例的具体标准。
所以多花20分钟把草稿摊开看，能省掉后期大量“我觉得不自然”的返工。这里的注意点是，别让团队去逐字推敲润色措辞，会议焦点是找需求盲区，不是做文案优化。
3.3 定义清楚“停止条件”，防止无限迭代
提示工程天然具备“可无限优化”的特征，团队很容易迷失在迭代里。今天调一下温度参数，明天修改开口句，后天觉得示例顺序不对，大后天业务方又提了新点子，项目周期就这样被拖垮。
我现在的做法是在需求挖掘阶段就同步定“停止条件”。说白了就是和业务方约定：当前版本做到什么水平，就算达到第一阶段上线标准，可以投入使用了。停止条件通常包含三个维度：正向样例达标率（比如95%样例通过）、关键反例零容忍（出现即阻断）、极端情况的可说明性（无法处理时能不能给出兜底话术）。
有了停止条件，团队在需求评审时就会围绕“这次迭代目标是什么”来讨论，而不是谁嗓门大就听谁的。曾经一位业务负责人反复提出新增追问逻辑，我直接把停止条件摆出来，说“这个需求很有价值，但它属于第二阶段的扩展目标，如果现在加进去，第一阶段无法按期验收”。需求挖掘最怕的不是需求多，而是分不清优先级，停止条件就是为了解决这个问题。
3.4 用提示词版本记录回溯“为什么改”
团队协作到后期，高频踩坑之一是：提示词被改来改去，但没人记得每次改动的真实原因。结果就是优化在循环，问题在顽固重复。
我现在逼着团队养成一个习惯：每次修改提示词，提交记录里必须写清楚“触发修改的用例编号”和“期望解决的模型行为偏差”，禁止只写“优化提示词”这种废话。这个习惯刚开始会被嫌麻烦，但坚持两轮迭代之后，价值特别大。比如你在排查一个回复问题时会发现：步骤3展示的约束条件来自第17号用例的补充；如果这个约束条件导致另一个新问题，你可以顺着记录找到当初加约束的讨论上下文，判断是完整回退还是局部调整。
更进一步，这个版本记录在团队换人时是救命稻草。提示工程项目人员流动很常见，新同学接手时最怕面对“天书提示词”。有了记录，等于把隐性需求重新摊开在眼前，上手速度能快好几倍。
3.5 分组访谈与集中对齐穿插进行
很多人以为团队协作挖掘需求就是大家一起开会。我的经验是，全体大会不适合做深挖，只适合做对齐。真正深度的需求挖掘，需要按角色分组做小访谈。
业务方和一线用户一组，他们聊的是真实场景和痛点；技术和评测一组，他们聊的是能力边界和验收可行性；产品作为中间人，把两边的语言翻译成结构和样例。每组访谈完，再集合到一起过一轮。这样做的原因很简单：业务方和技术方在人群里的表达意愿和信息密度完全不同，把两边放在一起，容易变成“技术方主导发言、业务方被动点头”的假性对齐。分组访谈能先把各侧的完整信息逼出来，集中对齐时更高效，也不容易遗漏。
有一次我们做营销内容生成工具，业务方在访谈里透露了一个重要信息：文案的最终审核者往往是合规部门，有些话术风格上没问题但过不了合规。如果没有单独访谈，这个信息大概率被淹没在会议上，而这恰恰是提示词需求里最核心的约束条件——生成内容必须可解释、可溯源、避免绝对化表达。
4. 跨角色协作中的典型摩擦及应对
4.1 业务方要“像人”，开发方要“可测”
先说最常见的一组摩擦。业务方和开发方之间的视角分歧，几乎每次都会出现。业务方的判断方式是“整体感官”：读一遍模型回复，觉得自然就通过，觉得机械就驳回；开发方的判断方式是“局部指标”：看格式解析是否成功、看有没有漏字段、看命中率多少。
这两种标准天然冲突。感官判断缺乏可以复现的基准，指标判断又容易忽略真实体验。我在协作里用的调和方式是把它拆开：感官层的问题，用反例评测来收敛；指标层的问题，用结构化输出来解决。具体来说，我会请业务方把“不像人”的具体表现逐条列出来，是太长了？是太正式了？是每次开头都一样？然后针对每条表现设计一个评测用例，变成技术可以执行的检查项。当业务方抱怨“机械感”时，评测单里可能多一条“连续三次回复的开头句式不得重复”。这样一来，“像人”就从玄学变成了可测规范，两边协作就顺畅了。
4.2 产品要体验，算法要边界，怎么平衡
另一组摩擦发生在产品设计和算法开发之间。产品同学倾向于要求“所有场景都要覆盖”，擅长列举各种可能性；算法同学则会强调“模型能力存在边界”，提醒团队不要期待太高。
这类冲突不能靠某一方让步解决，而是要引入“兜底方案”这个共同目标。当产品提出一个新场景时，技术不必急着说“不行”，而是说“这个场景我们可以尝试，但要约定一个兜底策略——如果模型的输出质量不稳定，是回退到通用回答，还是一次没成功就转人工？”聊兜底，就是给双方找台阶，也是给需求增加场景边界。
我在某内容审核辅助工具项目里深有体会。产品坚持要让模型支持“用户自定义规则的灵活解析”，技术认为自由输入会导致不可控，两边僵持。后来我们约定了一个折中方案：支持用户选择几个预置模板+自由输入补充，但自由输入部分需要经过一个关键词匹配校验，匹配不上的时候提示“无法理解规则，请重新表述”。这个方案既保住了产品体验，又划清了能力边界。需求挖掘的时候多花半小时讨论兜底，比开发到一半再补兜底省太多事。
4.3 需求泛化的判断：哪些不做，比哪些要做更重要
团队协作过程中，还会出现一种非典型摩擦：需求增量方不是业务，而是技术本人。技术人员在试模型的时候发现“这个模型能做到某件额外的事”，就会顺手加进提示词里，让功能越做越宽。这种情况看着积极，其实是需求失控的前兆。
我的应对方式是给团队立一条规矩：凡是新增需求，必须回答三个问题——用户会主动用它吗？它和既有需求主路径冲突吗？它是否能作为独立阶段交付？三个问题有一个不过，就先砍掉。比如某次做合同信息抽取，技术同学发现模型顺带可以生成合同摘要，想直接加进去，结果我一问“用户会主动要求摘要吗”，团队沉默了。实际用户就是来抽取关键字段的，摘要没有明确使用场景，后来砍掉，反而让主功能更聚焦。
这种“做减法”的讨论需求挖掘里尤其重要。大部分团队合作失败，不是做得太少，而是做得太杂。定期对需求池做一次“废物检测”，是避免范围蔓延的有效动作。
4.4 摩擦的正面转化：把分歧变成需求清单
说了这么多摩擦，我想特别提一个认知：跨角色协作中的分歧不是坏事，而是需求挖掘最大的“情报源”。业务方和技术方的每一次碰撞，背后都藏着模型行为、用户习惯、系统约束的隐含信息。分歧出现时，我最常做的是把它们全部记录下来，转成“待验证问题清单”。
比如“这个场景会不会出现？”“这么回答算不算安全？”“用户能接受多长的等待时间？”——这些问题不一定马上有答案，但它们每一个都对应一个潜在评测用例。等清单攒到一定量，拿去让团队逐条讨论，很快就能建立一套非常扎实的评测基线。所以团队协作时要刻意营造一种氛围：分歧可以被表达，但表达完必须落到清单上，不能停留在互相不服。
5. 落地案例：某客服问答机器人需求的协作全过程
光讲方法论容易飘，我拿一个最近参与的项目做完整复盘。某团队要做智能客服问答机器人，覆盖售前咨询和售后问题处理两个场景，要求回复风格亲和、不能答错关键售后政策。这个项目不大，但正好踩遍了前面说的各种坑。
5.1 项目背景与团队角色
团队成员组成为：两位业务侧同事（一位懂产品规则，一位直接接一线客服反馈）、一位产品设计、一位后端开发（负责调用模型和搭建接口）、一位测试（负责整理评测）。这个项目没有专职的提示词工程师，所以核心提示词工作由我和后端开发共同完成，业务方负责提供经验和验收，产品负责组织和文档沉淀。
启动前，我先组织了一次40分钟的“需求挖掘机制对齐会”。目的不是挖需求，而是让所有人知道接下来我们要用什么方式协作。会上只定了三件事：样例来源是什么（真实聊天记录）、评测用例怎么产生（业务侧提正向、测试侧补边界）、每周多久同步一次（两次，节奏要快）。这个启动环节很多人会跳过，我强烈建议别省，因为它是在给所有人安装同一个“协作大脑”。
5.2 需求挖掘流程的推进过程
第一轮我们做的是场景访谈，约两小时。业务方调出过去三个月的客服聊天记录，把用户问题分成两大类：一类是“价格、发货时间、优惠怎么用”；另一类是“退换货、维修、投诉”等售后问题。看完记录我们发现，售后类问题用户的情绪普遍更激动，对“推卸责任感”非常敏感，回复稍冷就容易被判定为“机器人敷衍”。这个发现，直接成为后面提示词设计的核心约束。
第二轮做样例整理。我们花了三个下午，把聊天记录梳理成16个正向样例、12个边界样例、7个反例。边界样例包括：用户提问里带着错别字、用户一句话问了多个问题、用户在夜间非工作时间提问、用户直接用语音转文字导致内容破碎。反例来自真实的笨拙回复：有客户问“你们是不是不想管了”，如果直接回复售后政策，不仅不解决问题，还会激化情绪。基于这些反例，我们在提示词里加入了一层“情绪识别先行”的规则：先判断用户情绪是否有明显负面倾向，如果是，回复必须先表达理解，再进入问题处理。
第三轮是做初版提示词和靶子测试。初版只覆盖了正向样例，结果边界样例里“一句话问多个问题”直接挂掉，模型只回答了最后一个问题。这个失败让团队确认了一条新需求：“多意图识别并分别作答”。我们又发现“语音转文字”场景下，输入里会有大量断句和语气词，模型被干扰后答非所问，于是提示词里明确要求忽略语气词干扰，抓住核心意图。这些需求如果不通过样例测试，是永远不可能在需求讨论会上被拍着脑袋想出来的。
5.3 上线前我们是如何验收的
验收阶段我坚持所有评测用例都过一遍自动跑测，虽然这个项目做了简化版的批量调用脚本，但价值非常明显：原来业务方验收靠“感觉”，现在变成了看一份用例通过率报告。报告上四列：用例编号、期望行为、实际行为、是否通过。任何不通过项，当场决定“改提示词重新测”还是“暂时豁免并说明原因”。
这里要提醒一句，不要追求100%通过。我们要做的是关键路径高通过率（正样达标率95%以上）加反例零容忍；边缘样例允许一定比例不通过或走兜底话术。如果每个边缘用例都死磕，项目成本会失控。
上线后的两周内，我们又迭代了两轮，因为真实流量暴露了一个测试集没覆盖到的场景：用户会输入非常短的内容，比如“人工客服”“投诉”这种关键词，模型在缺少上下文的情况下容易过度发挥，给出不够稳妥的长篇回复。于是提示词里增加了一个约束：识别到用户明确转人工意图时，不要展开回答，直接提供转人工路径并结束会话。这个需求如果硬靠闭门想象，很难想到用户的输入会这么简短而极端。
5.4 复盘时我们做对了哪几件事
项目收尾复盘时，团队达成了几个共识。第一，需求挖掘没有停留在“讨论感觉”阶段，而是被样例和评测用例一步步逼出来的。第二，协作流程里的每个角色都贡献了关键信息：没有业务方提供聊天记录，我们不可能知道情绪敏感点；没有测试同学追问“亲和怎么量化”，我们不可能把指标落到评测用例上；没有后端开发参与提示词审阅，我们也不会提前发现模型输入长度限制问题。第三，明确的停止条件让我们在两周内上线了最小可用版本，没有被“再优化一下”带偏。
这给了我一个很深的认识：提示工程的需求挖掘，本质上是一场跨角色的信息转化游戏。谁掌握了足够多的场景信息，谁就能写出更稳的提示词；谁能让团队高效地贡献和共享这些信息，谁就能在项目中持续掌握主动权。
6. 把协作技巧沉淀成团队习惯的几点建议
最后，再补充一些长久维护协作水平的心得。需求挖掘不是某一次项目的临时工作，它应该成为团队做AI功能时的默认机制，否则下一次新需求进来，又会退回到各说各话的老路。
6.1 沉淀“提示词需求资产库”
我建议团队在完成每个项目后，把评测用例、提示词版本记录、场景访谈纪要分类归档，形成一个不断生长的资产库。这个资产库的价值在于每一次新项目都可以直接复用里面的评测思维和边界样例。比如客服项目的“情绪识别先行”思路，迁移到教育行业问答场景时也适用，只是表达方式不同。没有资产库，这些积累就只存在于团队成员的个人记忆里，人员一换就断档。
6.2 让“需求挖掘协作”成为一种轻量仪式感
我不赞成搞特别重的流程，但建议固定三个轻量动作：启动时的机制对齐会、迭代中的样例打靶会、收尾时的复盘会。三个动作平均每次不超过一小时，却能持续提醒团队“需求还没挖完，不要急着写最终版提示词”。轻量仪式的意义，是让协作不至于随性散漫，又不至于官僚化。
6.3 技术负责人和业务负责人都需要“翻译能力”
到最后你会发现，团队协作技巧里最难练的不是过程管理，而是翻译能力。技术方要能把模型行为翻译成业务方可理解的结果，业务方要能把用户感受翻译成技术可执行的约束。这种能力不是一天能养成的，但如果团队里有意识地去练习，每次需求会议都是一次训练场。遇到好翻译，需求挖掘效率能翻倍。
我自己在项目里持续感受到，提示工程需求挖掘做得好不好，跟团队里有没有“能人”关系不大，跟协作机制够不够通透关系很大。只要场景信息能被高效地收集、翻译、验证、沉淀，哪怕是模型能力有限的小团队，也能做出稳定好用的AI功能。
