做提示工程做到第三年我最大的体会是提示词不是写出来的是跟真实用户一起“磨”出来的。今天想把这一整套思路摊开聊聊——作为提示工程架构师我是怎么把用户参与研究User Participation Research嵌进提示优化流程里并实打实把效果做上去的。这个内容适合所有正在做大语言模型应用、需要搭建提示体系、或者被“评测集都过了但用户就是不满意”卡住的人。如果你是刚入行只写过几条提示词也能从这里看到一套完整的、可以抄作业的迭代方法论。1. 提示工程架构师到底在做什么为什么绕不开用户参与研究先说说角色本身。很多人以为提示工程架构师就是“写提示词写得好的人”实际上完全不是。我的日常工作里提示词的撰写大概只占三成。剩下的时间在搭建评测集、设计版本迭代流程、分析线上用户输入日志、协调产品经理和技术团队的定义对齐。换句话说这个角色的核心职责是“让提示体系在一个真实业务场景里稳定、可控、可迭代地运行”而不是写出一条金光闪闪的咒语。1.1 提示词本质上是“产品语言与用户心智的接口”想明白这一点就明白为什么要用户参与研究了。提示词表面上是给大语言模型看的指令但它最终服务的对象是端上用户。用户看不到提示词只能感受到“这个系统懂不懂我”。提示工程如果只盯着模型侧的表现忽略用户侧的实际使用习惯就会掉进一个经典陷阱开发者以为自己在做一款聪明助手用户却觉得是个答非所问的复读机。举个我踩过的真实例子。某团队做了一个文档摘要工具初始提示词里写的是“请生成一份高质量的摘要包含核心论点、关键论据、以及潜在的应用价值”。这个提示词在评测集上跑出了挺高的分数但上线后用户投诉不少说“摘要太官方了我要的是给我一句话说清楚这文档能不能解决我的问题”。问题出在哪用户心智里的“摘要”是“帮我判断要不要读这篇东西”研发团队理解的“摘要”是“结构化提炼全文重点”。两者根本不是同一个任务。这件事让我明白提示词的含义只有放在真实用户的使用语境里才有意义。1.2 离线评测集再漂亮也填补不了用户行为的缺口我见过很多团队花大量时间堆评测集把正确率从85%调到90%但用户满意度反而在下降。原因是评测集是技术人员自己设计的里面的问题天然带有“正确答案”的假设。而真实用户会怎么提问、会用什么语气、会输入什么样的残缺信息这些行为侧的细节很难离线预判。用户参与研究解决的就是这个缺口。它把真实用户拉进提示设计的迭代闭环里通过访谈、行为观察、反馈打分、对照测试等方式让提示词的设计依据从“我猜用户会这么用”变成“用户确实这么用”。这一套做法不是学术界的概念炒作而是工程落地上非常实操的方法论。下面我把整个流程拆开讲。2. 怎么搭研究框架从提示基线到用户参与实验提示优化如果没有基线就没有对比。我接手任何项目的第一件事都是建立清晰的提示版本管理然后围绕版本做小规模用户研究。2.1 第一步把提示词当代码一样管版本提示词必须是可追踪的。我在内部用一套很朴素的命名规则V0.1初版提示通常是产品经理和工程师凭直觉商量出来的V0.2内部专家评审后的修订版V1.0通过内测、准备面向用户验证的候选版V1.1、V1.2根据用户研究反馈进行的小幅迭代每个版本都固定核心变量。比如“摘要”类任务我会把V0.1和V1.0的差异限定在提示结构上段落组织、示例个数、语气词而不是同时改模型参数、改上下文长度、改后处理逻辑。一次只动一个变量后面分析研究结果时才不会扯皮。这样做的原因是用户参与研究里最容易出现的乌龙就是用户反馈变好了但你不知道是提示词起了作用还是因为某次并发低、模型响应更快产生了安慰剂效应。版本控制能帮你在复盘时锁定变量。2.2 第二步确定研究维度和指标用户参与研究不能只问“你觉得好不好用”要有可量化的维度。我一般固定看四个维度任务成功率用户是否一口作答就得到了想要的结果还是需要多轮追问答案可用性输出内容是否直接能拿来用还是需要大量二次加工交互成本用户为了得到答案付了多少输入/纠偏动作信任与满意度用户愿不愿意把系统推荐给同事是否认可答案权威性这四个维度对应不同的提示优化动作。成功率低说明提示的任务定义边界不清楚可用性低说明输出格式和用户工作流不匹配交互成本高说明提示缺少主动澄清机制信任度低往往是语气、措辞太“机械”或太“讨好”。2.3 第三步小样本最小化实验设计用户参与研究不追求大样本。我常用的是每组 8-12 名目标用户把版本 A旧提示和版本 B新提示分给两组做对照。人数少没关系关键是被试者必须来自真实目标人群而不是内部同事。有一回我犯过这个错找了一群研究团队内部的人做体验反馈多为“挺不错的”。结果上线后真实用户完全不买账。原因很简单内部人天天看提示词设计文档潜意识里已经知道系统想干什么而真实用户第一次看到答案是懵的。所以我后来严格规定被试尽量来自真实业务的典型用户至少也得是“对该领域很熟悉但完全不了解内部实现”的人。用户不理解的反馈往往价值最高。3. 用户参与研究的实操流程访谈、日志、评分三件套框架搭起来之后真正的重头戏是执行。我的标准流程是三件套并行半结构化访谈、行为日志埋点、满意度量表打分。这三样东西各有侧重缺一不可。3.1 半结构化访谈问出用户脑子里的“任务模型”访谈的目的是搞清楚用户带着什么目标来、他以为系统能做什么、他怎样判断答案好坏。我会准备一份半结构化提纲但每次会根据实际情况临时追问。常用的问题包括你最近一次使用这个功能的场景是怎样的想解决什么问题你第一眼看到回答时脑海里的第一反应是什么这次回答里哪些地方符合你的预期哪些地方完全出乎意料如果你能重新设计这个工具你希望它第一步先做什么你刚才输入时为什么用了这种说法而不是另一种这些问题的共同逻辑是把用户的行为追溯到他脑子里的“任务模型”。比如用户输入“帮我写个方案”他脑子里的“方案”可能是“给上级看的三页PPT大纲”但提示词里假设的“方案”可能是“两千字的项目计划书”。任务模型一旦错位后面怎么做都别扭。我实际访谈中经常出现一个现象用户说不清“哪里不好”但能很生动地描述“我本来想干什么”。这就是最有价值的线索。3.2 行为日志埋点记录用户真实的输入足迹访谈只能覆盖用户愿意说出来的部分行为日志补充的是用户连自己都没意识到的部分。我会在系统侧记录如下字段原始输入文本脱敏后输入长度字符数是否在回答后继续追问追问内容与首轮输入的语义距离是否有修改输入后重试的行为从提问到停止使用的总耗时这些日志能反映出很多反直觉现象。我之前在一个智能客服问答项目里发现回访用户都表示“系统可以”但日志显示有 63% 的用户在首轮问完后会立刻追加一句“我不是这个意思我想问的是……”这说明首轮提示完全没有把用户带入正确意图轨道只是用户比较有耐心愿意纠正系统。你想想看如果只看满意度问卷这个系统评分可能是 7 分但加上行为日志就会知道 7 分背后有大量隐性纠偏成本。提示优化的着力点一下子就清楚了应该让首轮交互更精准而不是让后续纠偏更顺滑。3.3 满意度与信任感量表给主观感受一个数值锚点主观感受必须变成数值才有办法横向对比。我常用的是一张极简量表大约10道题5分制混合正反向表述“整体而言我对回答满意”正向“我需要花额外精力才能理解回答”反向“回答的风格像真人而非机器”正向“如果有疑问我会继续追问该工具而不是换一个渠道”正向“回答给了我不必要的细节”反向量表的价值不在于得到一次性的绝对值而在于跨版本对比。比如V1.0的统计均值是3.8V1.1优化了提示中的语气设定后涨到4.3这时候你就有信心说“语气调整对满意度有正向作用了”。有一点要提醒量表题别设计得太绕。用户参与研究的样本本身不大量表太复杂容易填出无效数据。我踩过的坑是设计了 26 道题的量表结果被试到第 18 题开始全选“3”后面的数据全是噪声。4. 从研究结果到提示重构的关键动作收集完研究数据就要进入真正的“工程”环节把发现翻译成提示结构上的改动。这一步我总结为四个动作按优先顺序排列。4.1 用“用户心智模型”重写提示结构所谓用户心智模型就是用户脑子里“这个系统正在怎么工作”的认知。提示词必须跟这个认知对齐否则再精确的措辞都是对牛弹琴。我用之前文档摘要工具的例子来讲。研究后发现用户使用场景分两大类一类是“帮我把这份长报告浓缩成我能转给同事的摘要”另一类是“我想快速判断这份竞品方案值不值得细读”。前者要信息密度后者要结论倾向。老版提示词没有区分这两个场景所以输出总是一锅烩。重构后的提示结构改成两段式如果你是用户的文档助手请先判断用户意图 如果用户希望“浓缩内容”则输出核心论点的分点摘要。 如果用户希望“评估文档”则输出文档的结论倾向、关键依据、最长三句话。 输出后给用户一个明确的追问按钮选项需要我展开哪个部分这个新版提示没有增加任何花哨技巧核心改动是让回答的结构跟着用户脑子里的任务类型走。结果同名用户访谈里“第一眼觉得答到点子上”的比例明显上升。4.2 把错误示例做成“降级处理”而不是硬反例提示工程里大家都喜欢写反例比如“不要说空话”“不要啰嗦”。但用户参与研究让我发现硬反例效果有限。因为用户根本看不到提示词反例写得再好也只是模型层面的参数信号。真正有效的是“降级处理”。具体做法是当输入不符合预期时不是强行纠正用户而是给出一个最低可用答案同时附上可选的深入方向。举个例子。某教学辅助系统里用户会直接粘贴一个错误答案问“这样对吗”。模型如果回答“不对正确答案是X”用户挫败感很强。研究显示用户其实希望看到“你的思路方向是对的但这几个地方有误区”。于是我把提示改成若用户给出的输入有明显错误先指出输入中相对正确的部分再以提问方式引导用户自查 “你的方案中有一点很有意思但它隐含了一个假设你发现了吗” 若用户表示不想自查则直接给出修改建议并附一个正确示例。这一版提示上线后用户的二次追问率显著下降而“学到东西”的主观评价上升了。原因很简单用户要的不是被否定而是在一个安全的空间里被引导。4.3 识别提示中的“过度承诺”表述这是我从用户访谈里意外发现的高频问题。提示词里如果带有“我可以帮你做任何事”这类过度承诺的表达模型会输出一些超出能力范围的自信错误用户试一次没成功信任就崩塌了。在某个数据问答系统里老版提示开头写着“我是一个专业的数据分析助理可以回答各类业务数据问题”。结果用户来问“为什么上周转化率下降”模型自信地给了五条原因其中三条纯属编造。用户访谈里有人说“它说得那么笃定我差点信了后来发现根本不靠谱我整个上午都在核对。”重构时我把提示改成“我可以根据你提供的数据和图表进行统计分析在信息不足时会明确告诉你”并将“回答不了时如何表态”直接写进提示。这种降低期待的处理反而在后续评分里提升了信任感。4.4 参数化设计“用户可以调的表述粒度”一个提示很难同时满足所有用户那就把部分控制权交给用户。做法是在提示里植入几个可自然理解的选项而不是强迫用户适应输出模板。具体来说我会要求模型输出时自带一个“调整粒度”的提示行。比如“以上是详细版如果你想听精简版请直接回复精简”“我按严谨风格写了如果你想要更口语化的版本请回复聊家常”“如果需要按领导汇报的格式重新组织请回复汇报版”内置用户可操控的指令词能大幅降低改输入、重新组织话术的交互成本。这个设计不是新鲜概念但在项目里落地后用户满意度均分从3.9提升到4.3效果非常直接。5. 双重评测体系自动化评测与用户复测闭环用户参与研究不是一次性动作而是持续运行的数据源。但当项目规模上来之后不可能每次迭代都拉一批用户回来重新访谈所以我把评测体系分成两层一层是自动化评测集一层是低成本的用户复测机制两者互为补充。5.1 分层构建评测集核心场景、硬负例、长尾输入我的评测集不是单一大杂烩而是按三个子集来分。核心场景集约60%的比例覆盖最常用的任务类型每次提示迭代必须保证这些场景不回流。这里的基线参考直接从用户访谈和日志归纳出来的典型问题。硬负例集约30%的比例专门放入历史上模型答错但用户反应强烈的案例。比如上文提到的“用户误以为系统能回答因果类问题”就是一个硬负例。这个集合的存在是为了防止模型在功能增强后依旧自信地跑偏。长尾输入集约10%的比例来自真实用户日志中那些奇奇怪怪的输入。这些输入可能语法很不完整比如“帮我弄个图片不要太大最好带表格”。评测时如果主提示处理不了就要考虑是否在提示里加一层“输入补全”指令。构建评测集时有一点要提醒避免“测试集污染”。不要反复把同几道用户问题放进去模型跑多了会产生记忆效应表面得分很好看遇到新变体就垮。我会定期从用户日志里抽样替换20%的长尾用例。5.2 A/B对照实验怎么判断“新提示赢过旧提示”用户参与研究的核心输出之一就是新旧版本的对比判断。我的做法很简单取同一批任务各跑一遍新旧提示再由一个不参与提示设计的评估者按四个维度打分。具体判断标准是旧版某项得分显著优于新版则新提示在这项上回退需要重新调整新版大多数维度持平且至少一个维度显著提升则值得合并新版总评分未提升但行为日志显示交互次数下降了这仍然是正向信号因为减少了一次无效交互不要迷信单次均值差异。样本量小的时候0.2 分的差异可能是噪声。我会至少观察两批独立用户的复测数据再做上线决定。这也是提示工程架构师必须有的克制宁可慢一点也不要反复横跳。5.3 低成本用户复测机制把反馈通道嵌进产品里完整访谈成本高不可能月月做。我设计了一套低成本复测机制核心是把用户反馈收集嵌进产品常态使用中。具体做法是在回答底部增加一个轻量评级区域“这个回答有用吗”用户点击后追加一个可选填的“哪里不满足”下拉项包含“太笼统”“太啰嗦”“没get到重点”“格式不对”等标签。数据自动汇总到提示迭代看板每周复盘一次。这套机制有个额外好处用户不需要额外跳转步骤反馈成本极低回收率远高于事后问卷。我们那边上线后每周大概能攒下 300-500 条有效反馈成为提示优化的“实时雷达”。6. 常见问题与排查技巧实录走到最后我想把你实际运行中大概率会遇到的坑一次性讲透。以下几个问题是我接触过几乎所有提示优化项目都会撞上的类型。6.1 用户就是不按提示模板走怎么调都没用这是最高频的抱怨。现象是提示里写了“请输入您的需求描述”用户却只发来一个词“合同模板”。排查思路不要继续加更多指示语那只会让提示更臃肿。先去看行为日志确认用户到底习惯怎么输入。如果大量输入都是极短词那提示就要加入“输入扩展”机制——把极短输入自动补全为完整任务描述直接按多种意图分支处理不要等用户把话说完整。我在合同场景的做法是收到“合同模板”时模型先反问三类问题“适用方是谁甲方/乙方”“合同类型倾向劳务/采购/服务”“是否需包含保密条款”再输出对应模板骨架。这样用户没有增加输入负担反而被引导到更精确的结果上。6.2 修复了场景A场景B表现反而变差了提示词是全局的改一个地方极容易伤及无辜。我见过某团队为了压制输出啰嗦在系统提示里写了“保持简洁”结果所有的解释性内容全被砍掉用户反而看不懂了。应对办法是把指令作用域限定清楚不要用全局语气词。比如不是写“保持简洁”而是写“在输出每条建议时最多三句话附一个简短原因”。同时把评测集里的多场景当强约束每次修改后全量跑一遍不允许任何一个核心场景回流超过5%的差距。6.3 高频反馈与产研观点冲突以谁为准用户研究经常会出现“用户想要A但产研觉得该做B”的矛盾。比如用户反复要求“多给点模板示例”产研却认为模板会限制用户创造力。这种情况下我的原则是从用户任务出发找折中方案。既然用户的真实目标是“减少从空白页开始的痛苦”那么折中可以是“首轮给骨架示例同时允许用户回复‘自由发挥’进入无模板模式”。这样既满足用户降低启动成本的需求也守护了产品方对创造力的追求。6.4 只看“成功/失败”会让你瞎掉要看“勉强成功”用二分法判定回答质量和提示优劣势是我早期最常犯的错。后来我在日志里增加了一个“挣扎度”指标用户得到最终正确答案之前进行了多少次多余交互。比如用户问了三次、改了两次说法最终成功拿到答案。表面看成功率是100%实际上体验是灾难级的。我会把这类“勉强成功”单独标记优先级甚至高于“直接失败”。排查时这样用如果失败率不高但“勉强成功”很多说明提示的任务边界太模糊。如果“勉强成功”比例正常但失败率高说明提示的能力上限不够需要补充专业领域知识。两种情况的修法完全不一样。结尾最后分享一点我个人操作上的实在体会用户参与研究这件事真正难得的不是研究方法本身而是愿意把用户的行为反馈当成第一性输入来重构提示。做提示工程这几年来我越来越确定一件事提示词的每个字都应该有出处——要么来自基准评测要么来自用户事实。还有一个小技巧也是我一直在坚持的每次优化提示之前先把最近一周真实用户的原始输入截图贴到团队共享文档里让大家“浸泡”在用户原话中再动手改。比起看抽象统计指标这种方式往往能更快地建立起对提示优化方向的一致判断。如果你也在做类似的提示工程工作建议先从一条提示开始认真做一轮包含访谈、日志、量表的小规模用户研究。做完你会很惊讶原来真实用户和你想的差这么远。