写这个话题，是因为最近半年我见了不少要做提示工程相关决策的架构师——有的想给团队选一套提示词管理平台，有的想评估要不要自建评测体系，有的接了行业里的咨询项目要做市场研判。调研跑了一圈，报告写了几十页，最后评审会上被问“所以呢，我们到底要做什么”，全场安静。问题不在调研本身，而在多数人把“市场调研”做成了“邀人聊天”。受访者讲得开心，你也记了满满几页，但里面全是观点、印象、情绪，找不到一个能支撑决策的事实。这篇内容就是把我在提示工程市场调研里踩过的坑、试过错、最后验证有效的做法整理出来，给正要动手的架构师省点时间，也帮你们从源头上避开那些注定无效的访谈。
1. 先搞清楚：你到底在为哪个决策做调研
大多数访谈做废，第一个原因不是问题问得不好，而是调研目标本身模糊。你约了八个人，聊了两周，发现每位受访者说的都不是同一件事。有人以为你在选型，所以一直推荐工具；有人以为你在招人，所以大谈团队怎么组织；有人以为你在做行业分析，开口就是市场规模。这一锅乱炖汇总到报告里，架构师自己都不知道该怎么用。
1.1 提示工程调研的四种典型决策类型
结合我接触过的实际项目，提示工程相关的市场调研基本落在四种决策上。
- 技术选型决策：是否引入提示词管理平台、LLM网关、Prompt评测工具，选哪个。
- 投入评估决策：团队值不值得建立提示工程专项，预算应该花在自研还是采购上。
- 研发模式决策：提示词由谁维护、走什么评审流程、版本怎么管理、和代码发布怎么衔接。
- 市场机会决策：在提示工程服务这个方向上，是否存在值得投入的产品或解决方案机会。
同样是访谈，目标类型不同，要问的内容完全不同。技术选型要死磕场景和功能边界，投入评估要盯住成本和收益的换算关系，研发模式要关注协作流程和事故责任，市场机会要挖掘现有方案的空白和付费意愿。我见过最典型的翻车现场，是某位架构师想调研“提示词版本管理需求”，却在访谈里花一半时间和人聊模型效果。不能说完全无关，但聊得越散，报告越虚。
1.2 把调研目标翻译成可验证的假设
明确决策类型之后，下一步是把目标翻译成假设。这一步很多人直接跳过，结果访谈时只能抛出“你觉得重要吗”这种问题。
举个我自己的例子。有一次调研“提示词管理平台值不值得引入”，如果直接问团队“你们需要提示词版本管理吗”，八成得到“需要”两个字，然后对方也说不出更多。后来我把目标改成假设：如果团队一周内至少遇到10次提示词变更导致的效果回退事件，且很难定位是哪一版出了问题，那么这个团队就需要可追溯的提示词版本管理能力。
翻译之后，访谈问题就完全变了一个性质。我不再问想法，只问事件：“过去两周，你有没有遇到过提示词改了之后效果变差、又很难回到上一个可用版本的时候？具体是哪一次？”受访者会愣一下，然后开始回忆真实经历。事实证明，真实事件带来的信息量，是态度问题给不了的。
1.3 先画出“决策缺口图”，再约人
再分享一个我后来养成的习惯：约人之前，先画一张决策信息清单。左边是做出最终决策需要知道什么，中间是已经掌握的，右边是缺失的。访谈只用来补右边，其他问题直接砍掉。
比如某次判断要不要自建提示词评测体系，已知信息是团队用大模型做十来个内部场景，缺的是“这些场景的回归测试目前是怎么做的”“出问题后谁负责排查”“一个月要花多长时间”。这些缺口列出来，访谈约人、设计问题都有了靶子。没有这张图，你很容易被受访者带跑，听了一堆和决策无关的精彩故事。
2. 无效访谈的第一宗罪：选错了访谈对象
访谈对象错了，后面的所有努力都是白费。但架构师常常凭感觉约人——约的都是平时聊得来的，或者在某次技术分享上见过面的，看起来是圈内人，实际提供不了你要的信息。
2.1 布道者的话要打折扣听
技术圈里有一类人，我姑且叫“布道者”——在大会、社区、公众号里非常活跃，开口就是趋势和方法论，讲得头头是道。他们确实是很好的行业风向标，但做市场调研时，他们的信息需要打折扣。
原因很简单，布道者的信息经过了两层加工：一是高度概括，把具体细节抽成抽象观点；二是容易滞后，一个人一旦把大量时间花在对外输出上，亲自动手的时间就少了。我访谈过一位对外分享提示词工程经验的管理者，提到自家内部实践头头是道，追问到“最近一次您自己调提示词是什么时候”，他停了几秒，笑了，说那是三个多月前的事了。
不是说这类人不能访谈，而是别把他们当成一线用户，他们只能提供的是方向感，不是事实细节。遇到布道者型受访者，我会重点问三个问题：您上一次亲自动手是什么场景？那个场景里的具体数据还记得吗？团队里现在最常被问的问题是哪一个。问不出细节的部分，一律按无效信息处理。
2.2 一份可落地的访谈对象筛选清单
我后来整理了一份筛选清单，约人之前对照着打勾：
- 一线高频使用者：每天至少写或改一次提示词，对模型输出效果直接负责。
- 沉默的大多数：在用但从不发言的人，通常占了团队一半以上，最容易被忽略。
- 曾经的活跃用户：已经放弃使用，或转为使用内部封装方案的人。
- 预算决策者：负责技术投入审批的角色，关心的是成本和风险。
- 外部对标者：其他公司同岗位的人，能在合规范围内聊一聊行业通常做法。
清单背后的逻辑是：每个角色看问题的角度不一样，他们组合起来才能拼出完整的画面。架构师最容易犯的错是只约一线使用者和决策者，忘了那些“已经不用了”的人。而恰恰是后者，最清楚方案为什么失败。
2.3 为什么“放弃者”比“重度用户”更有信息量
重度用户能告诉你他们现在是怎么做的，包括哪些技巧、工具和流程。但放弃者能告诉你为什么一个方案走不下去、哪里出现了不可接受的成本、在什么条件下他们会重新考虑。对市场调研来说，这些信息往往更值钱，因为它们直接指向需求缺口。
我访谈过一位曾经重度使用提示词的研发，后来他转用内部封装好的模板。问他为什么，他没有抱怨模型不好用，而是说：“模板出错我知道找谁，自己写的提示词出错，排查一夜都不知道问题在模型还是在词上。”这个回答后来成了报告里最重要的发现。“可追责性”这个需求，如果不访谈放弃者，很难从重度用户嘴里听到。
找放弃者有一个技巧：不要只问“你用什么”，要问“你换过什么”。换过，就意味着你经历过至少两套方案的对比，你的评价是相对客观的。
3. 无效访谈的第二宗罪：问题设计全是态度题
选对了人，下一个坑就是问题设计。很多架构师写访谈提纲的时候，不知不觉写出一堆态度题。这类问题不是不能问，而是不能作为主餐，否则整场访谈都在收集“我觉得”“我认为”这类无法证伪也无法量化的信息。
3.1 态度题和事实题到底差在哪
我可以把这两类问题放在一起对比，你们感受一下就明白了。
| 问题 | 类型 | 信息价值 |
|---|---|---|
| “你们觉得提示词工程重要吗？” | 态度题 | 几乎为零，几乎没有人会说“不重要” |
| “过去两周，你手写或修改提示词的次数大概多少次？” | 事实题 | 能估算使用频率和依赖程度 |
| “你觉得现在的工具好用吗？” | 态度题 | 对方可能客气，回答没有锚点 |
| “最近一次你因为工具不好用而中断手头工作是什么时候？” | 事实题 | 有明确事件，能顺着追问具体细节 |
| “你们需要更好的评测手段吗？” | 态度题 | 大概率回答“需要”，但不知道为什么需要 |
| “上个月有没有一次效果回退花了你两个小时以上排查？” | 事实题 | 能直接量化痛点，还能引出完整事件 |
大概能看出来，事实题的好处是：有具体的时间窗口、有具体的事件、可以被追问。态度题只能回答一次，事实题能延伸出五分钟的对话。
3.2 五个“问法重构”的实战对比
重构第一组：泛问题“你们现在怎么用大模型”改成“过去两个星期，你亲自动手调过的提示词场景有哪些？挑最近的那个说说”。前者让受访者开始演讲，后者逼着对方进入具体情境。
重构第二组：泛问题“提示词工程哪些地方让你不满意”改成“最近一次你放弃手写提示词、改用别人封装好的方案是什么时候？当时卡在哪一步”。不满意三个字太抽象，卡在哪一步才是决策需要的信息。
重构第三组：泛问题“你们团队有提示词规范吗”改成“如果这周新来一个同事，你手上哪些提示词会直接给他用？怎么保证他用得对”。前者会得到响亮但可能失真的“有”，后者能让受访者拿出真实的工作习惯。
重构第四组：泛问题“你们怎么做效果评估”改成“上一次你改完提示词，怎么确认效果变好了？你是看直观感受还是有测试集”。后者大概率能暴露评测的真实状态，是好是坏都很清晰。
重构第五组：泛问题“你们支持多轮对话还是单轮”改成“最近一次你的应用因为上下文太长而出错是什么场景”。前者是需求确认，对方可能乱答；后者是事件回忆，反映的是真实场景。
3.3 四类高信息密度的追问模板
除了改造问题本身，访谈中还要学会追问。我常用的四类追问模板：
- 事件回溯：既然提到了那次效果回退，能不能把整个过程走一遍——当时输入是什么，输出哪里不对，你改了几版，每版改了哪里，花了多长时间。
- 流程走查：拿到一个新任务之后，你的第一个动作是什么？之后每一步是什么？走到哪一步最容易卡住。
- 量化频率：这类事情一个月大概发生几次？是每周都有，还是一两个月才一次。
- 反事实验证：如果现在给你一个能力，比如自动记录每次提示词的修改历史，你刚才说的那个场景会不会因此改善？会改善到什么程度。
注意，反事实问题也要挂在具体场景上。裸问“给你一个版本回滚工具，方便吗”，没人会说方便，但这不是有效信息。必须把假设代入受访者刚刚描述过的那个事件里，答案才有参考价值。
4. 无效访谈的第三宗罪：现场记录与复盘一塌糊涂
访谈做完了，信息也问出来了，但很多人栽在记录和复盘上。我一开始也是这样，访谈时靠脑子记，觉得关键信息已经记住了，回去写报告才发现，当时觉得重要的细节已经模糊了，倒是那些金句级别的观点记得很清楚。这是大脑的偏好，也是调研的灾难。
4.1 留痕：没有录音就不算做过访谈
访谈必须留痕，这是第一原则。经对方同意之后，全程录音，必要的时候录屏。不是不信任自己的记忆力，而是记忆有强烈的加工倾向——你会记住符合自己预期的部分，忽略不符合预期的部分。录音的作用不是逐字整理，而是事后核对：那位受访者当时说的到底是“这个功能很麻烦”还是“上周因为找不到上一个版本，我把一条线上提示词重新写了一遍”。前者是态度，后者是事实，这两个信息对决策的意义完全不同。
如果条件不允许录音，就带一位同事做现场记录，一个人主问，一个人主记。分工要明确：主问的人不用同时记笔记，否则节奏会断。主记的人只记客观事实，包括具体时间、频率、涉及的工具和流程节点，不记录对方的形容词。
4.2 把信息分成三层：观点、事实、情绪
复盘访谈内容的时候，我会先把信息分成三类：事实、观点、情绪。
事实有明确的时间地点、具体事件、可验证的数据。比如“上周三调了一个电商客服提示词，来回改了六版，每版都要人工测一遍”。观点是受访者的判断，比如“我觉得这类工具都不成熟”。情绪是受访者在描述过程中流露出的感受，比如提到现在的重复劳动时明显烦躁，或者提到某个方案时语气兴奋。
为什么这么分？因为三者用途不同。事实用来支撑决策，观点用来提供线索，情绪用来判断需求和动机。混在一起就会出现一个问题：你把情绪当事实用。受访者语气激烈地抱怨一个工具，你觉得这就是市场痛点，实际上那可能只是他在特定情绪下的主观反应，并没有高频发生的客观事实支撑。
4.3 用“证据表”把发现钉死在纸面上
整理访谈结果时，我建议直接用表格来组织。每一行放一条原始记录，旁边标注它的出处、信息类型、关联决策点。
| 原始记录摘要 | 出处 | 信息类型 | 关联决策点 | 置信度 |
|---|---|---|---|---|
| “上周因为版本回退，一条线上提示词重新写了四小时” | 某研发 | 事实 | 提示词版本管理需求 | 高 |
| “一句话总结就是工具太散” | 某产品经理 | 观点 | 线索，有待交叉验证 | 中 |
| 受访者提到重复测试时明显烦躁 | 某分析师 | 情绪 | 可能存在自动化评测动机 | 低 |
这张表的好处是强迫自己不偷懒。如果发现某条结论下面只有观点和情绪，没有事实，那这条结论就需要标注为“假设”。
4.4 注意“样本量少”这个伪命题
汇报调研结果的时候，总会遇到有人质疑：“你就访谈了十来个人，能说明什么？”这个问题本身不成立，但回应要讲究方法。市场调研要看调研目的：如果目标是发现模式和识别需求缺口，那关键在于样本是否覆盖了足够的角色和场景，而不在于数量。十来个人足够暴露反复出现的模式，比如有七个人独立描述了同类事件，这就已经是很强的信号。我会在报告里写清楚样本覆盖矩阵：哪些角色、哪些场景、各自多少人。只要矩阵是完整的，样本量质疑自然站不住。
5. 一套可以直接复用的调研访谈提纲
前面讲的都是方法和原则，这章给一套可以拿走的实操提纲。这套提纲我改过好几个版本，适用范围是“企业内部提示工程需求调研”或“行业侧提示工程市场调研”。字段可以根据目标微调，但结构基本稳定。
5.1 开场锚定：先让对方讲一个真实故事
访谈前五分钟决定整场质量。如果一上来就问“你们怎么用提示词的”，你会得到一个官方版本的回答。更好的开法是先让对方进入具体事件。
我通常这样开场：“今天我们主要聊提示工程落地的真实情况，没什么对错，你尽量讲具体的东西。先从最近一次你动过提示词的事情开始吧——不管是写、改、还是调试，说那次就行。”对方一旦开始叙述具体那次经历，故事的引子就出来了。后面所有的追问，都是围绕这个故事里的节点展开。
开场还有一个重要动作：说清楚这次调研的用途，并承诺匿名处理。受访者愿意讲真话的前提，是知道这些话不会被挂上名字传到领导那里去。
5.2 行为追溯问题组：把工作流走一遍
这部分是核心，目的是还原受访者真实的提示词工作流。
- “最近两周，你大概经手过多少个提示词相关的任务？其中写新的多，还是改旧的多？”
- “挑一个你最近改得最痛苦的一次，当时为什么痛？卡在哪一步？”
- “你的提示词脚本日常放在哪里？本地文件、在线文档、还是工具平台？怎么组织的？”
- “改完一个提示词之后，你怎么确认效果达标？靠肉眼试，还是有测试集？”
- “有没有过‘昨天还好好的，今天就不好’的情况？你当时是怎么排查的？”
- “如果改到一半发现效果还不如前一版，你会怎么回退？大概要花多久？”
每个问题后面都值得停留五分钟。比如“怎么回退”这个问题，很多人会被问住，然后承认“我们一般就是凭记忆把上一版的词重新写一遍”。这就是一个再典型不过的需求信号。
5.3 工具链细节挖掘：别只听工具名称，要听闭环
问工具的时候，不能只记名字。要追问这个工具在整体工作流中扮演什么角色，它和前后环节怎么衔接。
- “你用的提示词工具，是只有你一个人在用，还是团队共享？”
- “如果写完提示词要接入应用，中间是你们自己写代码，还是平台直接支持？”
- “有没有出现过提示词写好了，但接入应用时参数传错导致结果异常的情况？”
- “上下文管理这块你目前是怎么做的？有没有出现过超长上下文导致效果崩掉的事件？”
- “输出格式问题让你费过多少时间？比如模型返回的JSON格式偶尔不对，你们怎么处理？”
我比较关注“闭环”这个词。受访者的工作流只要是不闭环的，比如写了提示词无法验证、验证了无法回归、回归了无法追踪，那这个环节就是需求。不用受访者告诉你需要什么，工作流断点已经替你说了。
5.4 量化优先级：事件频率加时间代价
调研最后要排序，没有量化的排序就是耍流氓。我不问“你给这个需求打个分”，而是问事件频率和代价。
- “你说的这个问题，最近一个月出现过几次？能想起来大概数字吗？”
- “每出现一次，平均要消耗多少时间？按小时算。”
- “如果这个问题完全解决，你觉得自己的效率能提升多少？做个粗略估算就行。”
把频率乘时间，就得到一个粗略的期望值。比如“每周出现两次，每次两小时”，那就是每周四小时的浪费，优先级立刻上来了。这种量化会让报告踏实非常多。
5.5 示例访谈片段：好的访谈是什么样的
我写一段模拟对话，展示同样的话题，不同问法带来的结果差异。
受访者：“我们最近其实在用提示词这块挺多的，但效果时好时坏。” 架构师（重构后）：“效果时好时坏，你记忆里最近一次‘坏’是哪天？当时你正在做什么？”
受访者：“上周三吧，我在调一个客服意图识别的提示词，前一天用得好好的，第二天一上来就变傻了。” 架构师：“‘变傻了’具体是什么表现？输入输出有什么变化？”
受访者：“同样的输入，上周二还知道要转人工，周三直接给了一堆废话。我猜是上下文崩了或者模型更新了。” 架构师：“你后来是怎么处理的？花了多久？”
受访者：“我把代码里的历史会话日志翻出来，一遍一遍试，后来重新写了一遍提示词才恢复，大概三四个小时吧。” 架构师：“这事你能接受吗？如果有一个工具能记录上一版提示词、对比效果变化，你觉得这事还会存在吗？”
这段对话只有六个来回，但已经收获了一个完整的事件、排查路径、耗时以及反事实反馈。比问十句“你觉得重要吗”值钱得多。
6. 常见问题与排查技巧实录
最后把实际操作中容易踩的坑集中过一遍，做个速查表式的整理。
6.1 受访者全程泛泛而谈，就是不说具体事件
遇到这种受访者，要先检讨是不是问题本身太泛了。把“你们怎么用大模型”改成一个封闭式事件提问：“这周或者上周，你亲自动过的最长的一次提示词调试大概花了多久？”对方就没办法用“一般吧”“还可以”糊弄过去。如果还是含糊，可以直接说“咱们不聊整体感受，就聊最近一次你亲手动过的场景”，刻意把话题往下压。
这种打太极现象很多时候是对方对访谈目的不信任。这时候我把匿名承诺再强调一遍，并且自己也提供一条具体经验做交换。先讲一个我自己的失败案例，对方往往就会打开。
6.2 两位受访者的回答明显矛盾
矛盾不代表有人撒谎，很可能只是场景不同。某两位受访者，一位说“提示词管理工具完全不需要”，一位说“太需要了”。调查后发现前者每天只写两三条固定提示词，改完就固化，很少变化；后者要服务几十个场景，提示词频繁调整。两个人说的是同一件事，但上下文完全不同。
遇到矛盾，不要强行求同，而是把矛盾的根源找出来。我一般会列出两边的角色、使用频率、业务场景、维护模式，那个关键变量就会自己跳出来。这个变量往往也是报告里最重要的洞见。
6.3 评审会上被质疑“调研对象选择有偏差”
有人说你约的人都是“支持你的观点的人”，这个质疑实际上每个人都可能遇到。我的习惯是在约人阶段就刻意引入相反阵营：“请您推荐两位目前对提示词平台最抵触的人，我想听听他们的理由。”抵触者的声音收集到报告里，反而能提前堵住评审会的嘴。
如果报告里呈现了反对意见，评审的逻辑就从“你调研方法不行”转向“你怎么考虑这些反对声音”，这个战场好打得多。
6.4 时间不够，怎么在两天内完成有效调研
约定好的访谈时间经常会缩水，这种情况我通常做三件事。第一，把访谈提纲压缩到五个核心问题，全部是行为追溯和量化问题，删掉所有宏观话题。第二，提前给受访者发一份一分钟可以填完的背景问卷，收集角色、使用频率、工具清单这类基础信息，访谈时不再重复问。第三，给自己设定一个硬规则：访谈超过半小时还没出现一个具体事件，就换个角度切入，或者礼貌地结束这场访谈。与其等一场全程空谈，不如省下时间去找下一个人。
最后分享一个我个人的习惯：每次正式调研开始之前，我会先写下三条到五条“我对当前现状的预判”，比如“团队里提示词版本管理做得不好”“大家用的工具主要是原生的聊天界面”之类，写完锁在笔记本里。调研结束后再翻出来逐条对一遍。凡是预判被证伪的地方，往往才是这次调研最值钱的发现。访谈这件事，本质上不是用受访者的话来证明你自己想法的正确，而是用他们经历过的真实场景，去校正你的经验盲区。希望这份整理能帮你少走我走过的弯路，也祝你下一次的提示工程调研，访谈完就能直接进入决策环节。
