想象你是一家新开餐厅的老板,研发了一道招牌菜。你不会直接把菜端给所有顾客,而是会先请朋友试吃、调整配方、搞一次小规模试吃活动,对比老菜和新菜的受欢迎程度,最后才决定是否把它写进正式菜单。AI创业MVP阶段的Prompt验证,本质上就是“给Prompt试菜”的过程。 很多AI创业者凭感觉写Prompt,上线后效果时好时坏,却说不清问题出在哪。科学的Prompt验证方法,能帮你在有限资源下,用数据而非直觉来判断Prompt是否达标。本文用“餐厅试菜”这个比喻贯穿全程,教你设计验证流程、建立评估指标、做AB测试、收集用户反馈、设定通过标准,最终用一份checklist守住质量底线。

岗位关联

掌握Prompt验证方法,你就不再是“凭手感调参”的AI创业者,而是能用数据驱动决策的产品人——这正是AI创业MVP阶段最稀缺的能力。

目录
  1. 可视化演示
  2. 验证流程设计
  3. 评估指标体系
  4. AB测试方法
  5. 用户反馈收集
  6. 通过标准设定
  7. 验证清单工具
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示AI创业MVP阶段Prompt验证的完整流程,包含验证管道动画和AB测试指标对比,帮助理解科学验证Prompt效果的方法。

本节配有交互动效(进入视口后自动加载,约 3KB)。

Prompt验证流程 四阶段验证管道:设计用例→AB测试→评估指标→通过判断 每阶段含评估指标和通过标准 验证通过率 = Σ(通过指标) / Σ(总指标) 科学验证流程避免凭感觉调Prompt

验证流程设计

餐厅老板拿到一道新菜,第一件事绝不是直接上菜单,而是先想清楚三个问题:这道菜做给谁吃?在什么场合吃?怎样算“好吃”?Prompt验证的第一步同样如此。很多团队一上来就急着写Prompt、跑模型,结果测了半天也不知道“好”的标准是什么,白费功夫。

这三个问题构成了验证的“黄金三角”:目标(做给谁吃)、场景(在什么场合)、标准(怎样算好)。目标决定了Prompt要服务什么任务,场景划定了测试数据的范围,标准决定了指标如何打分。三者缺一不可,构成了完整验证流程的骨架。

有了黄金三角,验证流程就水到渠成了,可以分为四步:定目标、画场景、跑测试、定标尺。先确定业务目标(比如“客服机器人要能解答退货问题”),再收集真实场景下的用户问题作为测试集,然后用这批问题跑Prompt,最后用统一的标尺给回答打分。这四步环环相扣:目标不清,场景就散;场景不全,测试就虚;测试不跑,标尺就空。

这套流程下来,原本“凭感觉试菜”变成了“带着标准试菜”。更重要的是,它让团队有了共同语言——当你说“这个Prompt不行”时,你拿出的是一份测试数据,而不是一句“我觉得不好吃”。

验证流程=定义目标→设计场景→执行测试→评审指标\text{验证流程} = \text{定义目标} \rightarrow \text{设计场景} \rightarrow \text{执行测试} \rightarrow \text{评审指标}
这个公式说明:验证不是“跑一遍看看效果”,而是一条有始有终的流水线,每个环节都有明确的产出。
  1. 定义目标先用一句话写清楚Prompt要达成的业务目的,例如“退货问题回答率不低于85%”。
    目标=业务任务+量化期望\text{目标} = \text{业务任务} + \text{量化期望}
  2. 设计场景围绕目标收集真实用户问题,覆盖高频、典型、边界三类场景。
    测试集={q1,q2,…,qn},qi∈真实用户问题\text{测试集} = \{q_1, q_2, \dots, q_n\}, \quad q_i \in \text{真实用户问题}
  3. 执行测试将测试集批量喂给Prompt,记录每次回答的质量打分。
    评分=1n∑i=1nsi,si∈[0,1]\text{评分} = \frac{1}{n}\sum_{i=1}^{n} s_i, \quad s_i \in [0,1]
  4. 评审指标汇总评分,对照预设标准给出“通过/不通过”结论,并记录迭代方向。
    结论={通过评分≥阈值迭代评分<阈值\text{结论} = \begin{cases} \text{通过} & \text{评分} \ge \text{阈值}\\ \text{迭代} & \text{评分} < \text{阈值} \end{cases}

评估指标体系

餐厅评价一道菜,不会只看“好不好吃”这一句话,而是要拆开打分:咸淡是否合适、摆盘是否精致、上菜速度是否达标、顾客是否愿意拍照发朋友圈。Prompt评估也需要一套“记分卡”,从多个维度打分。

这套记分卡分为两类:客观指标和主观指标。客观指标能通过计算精确得出,包括准确率(回答是否事实正确)、相关率(回答是否切题)、召回率(关键信息是否覆盖全面)。主观指标则需要人的参与,核心是满意度——用户觉得这个回答“顺不顺心”。

这四个指标各有分工,准确率是“底线”——答案错了,一切都白搭;相关率是“靶心”——对但答非所问也不行;召回率是“全面性”——漏掉关键信息会让用户抓狂;满意度是“体验”——有些回答正确但冷冰冰,用户照样差评。

有了这套记分卡,“好吃”就从一个模糊感觉变成了四组数字。当你拿着这份记分卡去分析Prompt问题时,你会清晰地看到:准确率低说明知识库有问题,相关率低说明指令理解偏了,召回率低说明缺少引导细节。

Accuracy=正确回答数总测试数,Relevance=切题回答数总测试数\text{Accuracy} = \frac{\text{正确回答数}}{\text{总测试数}}, \quad \text{Relevance} = \frac{\text{切题回答数}}{\text{总测试数}}
准确率和相关率的区别在于:准确率看“对不对”,相关率看“答没答到点子上”。一道菜“能吃”不等于“好吃”,“好吃”也不等于“客人点的是这道菜”。
  1. 准确率(Accuracy)逐条判断回答内容是否事实正确,统计正确条数占比。
    Acc=NcorrectNtotal\text{Acc} = \frac{N_{\text{correct}}}{N_{\text{total}}}
  2. 相关率(Relevance)判断回答是否针对用户问题的主旨,筛掉“答非所问”。
    Rel=NrelevantNtotal\text{Rel} = \frac{N_{\text{relevant}}}{N_{\text{total}}}
  3. 召回率(Recall)核查答案是否覆盖用户问题的所有关键点。
    Recall=被覆盖的关键点数量应覆盖的关键点总量\text{Recall} = \frac{\text{被覆盖的关键点数量}}{\text{应覆盖的关键点总量}}
  4. 满意度(Satisfaction)邀请真实用户对回答打分,保留情感体验维度。
    Sat=1n∑i=1n评分i,评分i∈{1,2,3,4,5}\text{Sat} = \frac{1}{n}\sum_{i=1}^{n} \text{评分}_i, \quad \text{评分}_i \in \{1,2,3,4,5\}

AB测试方法

餐厅上新菜最稳妥的办法,不是直接换掉老菜,而是搞一场“盲测”:把老菜和新菜分别端给两桌客人,记录他们的反应。Prompt的AB测试正是这个思路——让两个版本的Prompt在同一批测试上“同台竞技”,用数据选出更好的那一个。

AB测试有四个关键动作。第一是设置对照组:A版本是旧Prompt(对照组),B版本是新Prompt(实验组),两者除待验证的差异外完全一致。第二是确认样本量:测试样本太少,结果就是随机噪声;样本越多,结论越可靠。第三是随机分流:确保两个版本面对的用户群体特征一致,避免“B组刚好遇到了好说话的顾客”这种偏差。第四是显著性检验:用统计方法判断“A比B高5%”到底是真优势,还是运气。

\text{Prompt}_A = \text{基础指令} + X, \quad \text{Prompt}_B = \text{基础指令} + X'

样本量≈(1.96×σδ)2\text{样本量} \approx \left(\frac{1.96 \times \sigma}{\delta}\right)^2
公式里的σ是得分的波动程度(标准差),δ是你希望检测到的最小差异。想要检测出1%的差异,需要的样本量远大过检测5%的差异——就像要分辨两道口味几乎一样的菜,需要的试吃次数更多。
  1. 设置对照组保持A/B两个Prompt只差一个变量,其余指令、参数、上下文完全一致。

用户反馈收集

\text{反馈闭环} = \text{收集} \rightarrow \text{分类} \rightarrow \text{改进} \rightarrow \text{再验证}

> 反馈闭环的精髓在于"回到原处":用户反馈不只是一份记录,而是要反过来驱动新的验证循环——改进Prompt后再跑一轮测试,看反馈中提到的问题是否真的消失。1. 收集:通过问卷、访谈、行为日志三类渠道获取原始反馈。$$\text{反馈} = \{ \text{问卷评分}, \text{访谈记录}, \text{行为事件} \}$$2. 分类:把反馈按问题类型归类,如"事实错误""语气不佳""答非所问"。$$\text{问题类型} = \text{argmax}_{c} \ P(\text{类别} = c \mid \text{反馈内容})$$3. 改进:针对TOP问题修改Prompt,每次只改一个点以便归因。$$\text{Prompt}_{t+1} = f(\text{Prompt}_t, \text{问题}_1)$$4. 再验证:用同样的测试集重新测评,确认反馈问题已被修复。$$\text{Score}_{t+1} \ge \text{Score}_t \Rightarrow \text{改进有效}$$"桌边问卷"看似费时,却是MVP阶段最省钱的做法。等产品正式上线再发现Prompt有问题,代价是真实的付费用户流失;而在MVP阶段收集反馈,你损失的只是几条测试消息。这笔账,怎么算都划算。

通过标准设定

餐厅决定一道菜是否能上菜单,不能靠主厨“我觉得差不多”,而要有一个明确的“及格线”:试吃评分平均不低于4分、超过80%的试吃者愿意推荐。Prompt验证的通过标准同样要提前定好,否则团队会在“到底行不行”上吵成一团。

设定通过标准有三个维度。第一是阈值设置:给每个指标划一条及格线,比如“准确率≥85%且满意度≥4.0分”。第二是基线对比:光有绝对分数不够,还要和旧版本比——新Prompt比基线版本提升多少才算值得替换?如果只提升0.5%,冒风险换版就不划算。第三是容忍度:有些指标可以适当放宽,比如“相关率从80%降到78%可以接受,但准确率绝不能低于85%”。不同指标要有不同的容错空间。

设定通过标准的核心价值,是把“好不好”这个争论不休的问题,变成了“达没达标”这个一目了然的判断题。当团队为“要不要上线”争执时,一张标尺就能终结争论——这比任何说服技巧都管用。

通过条件=⋀i(指标i≥阈值i)∧(提升幅度≥最小增量)\text{通过条件} = \bigwedge_{i} \left( \text{指标}_i \ge \text{阈值}_i \right) \wedge \left( \text{提升幅度} \ge \text{最小增量} \right)
这个公式说明:通过标准不是单一分数,而是一组"并且"关系。就像餐厅试菜,既要平均分达标,还不能有某道菜的差评率超标——多个条件同时满足才算过关。
  1. 设置阈值为目标指标各设一条及格线,短期看绝对值、长期看趋势。
    thresholdi=业务可接受的最低值\text{threshold}_i = \text{业务可接受的最低值}
  2. 确定基线以当前线上Prompt的指标作为参照物,新Prompt必须超过它。
    Δ=Scorenew−Scorebaseline≥δmin⁡\Delta = \text{Score}_{\text{new}} - \text{Score}_{\text{baseline}} \ge \delta_{\min}
  3. 划分容忍度区分“硬指标”和“软指标”,硬指标不可商量,软指标可适度让步。
    硬指标={准确率,满意度},软指标={相关率,召回率}\text{硬指标} = \{\text{准确率}, \text{满意度}\}, \quad \text{软指标} = \{\text{相关率}, \text{召回率}\}
  4. 制定迭代策略若未通过,设置“再试一轮”的期限和方向,避免无限空转。
    迭代上限=3轮⇒若仍不通过则重新设计Prompt思路\text{迭代上限} = 3 \text{轮} \Rightarrow \text{若仍不通过则重新设计Prompt思路}

验证清单工具

米其林评审检查一家餐厅,会拿着厚厚的评分表逐项打分:食材新鲜度、烹饪技巧、味道平衡、环境氛围。Prompt验证也需要这样一张“后厨检查表”,把零散的经验沉淀为可复用的清单,让每个团队成员都能按标准执行。

这张清单包含四个子清单。场景覆盖清单:检查测试集是否覆盖主流场景、典型用户和核心功能路径。边界测试清单:检查是否覆盖了空输入、超长输入、恶意输入、罕见问法等边界情况。质量检查清单:逐条核对四项指标是否都已评测并有数据记录。迭代记录清单:记录每次Prompt修改的原因、变更内容和验证结果,方便回溯和复盘。

清单让Prompt验证从“个人经验”变成了“团队流程”。新人加入团队,不需要犯一遍所有错误才能上手——拿着清单走一遍流程,质量标准就能稳定输出。这正是MVP阶段最宝贵的资产:一套可复制的验证流程。

清单完成度=已勾选项数清单总项数×100%\text{清单完成度} = \frac{\text{已勾选项数}}{\text{清单总项数}} \times 100\%
清单的价值在于"外部化":它把你脑中模糊的"应该测一测",变成白纸黑字的"这些必须测"。完成度100%的清单,是Prompt上线前的最后一道保险。
  1. 场景覆盖清单列出应覆盖的业务场景,逐一确认测试数据包含该场景。
    场景列表={s1,s2,…,sm},每场景至少5条测试\text{场景列表} = \{s_1, s_2, \dots, s_m\}, \quad \text{每场景至少} 5 \text{条测试}
  2. 边界测试清单主动构造异常输入,确认Prompt不会崩溃或产生荒谬回答。
    边界输入={∅,超长文本,乱码,罕见方言}\text{边界输入} = \{ \emptyset, \text{超长文本}, \text{乱码}, \text{罕见方言} \}
  3. 质量检查清单核对四项指标均已测评、数据可追溯、评分人无利益偏差。
    质量门禁=⋀i=14(指标i有评分记录)\text{质量门禁} = \bigwedge_{i=1}^{4} (\text{指标}_i \text{有评分记录})
  4. 迭代记录清单记录每次迭代的“原因-变更-结果”三元组,形成团队资产。
    记录=(原因,变更,结果),ΔScore=结果new−结果old\text{记录} = (\text{原因}, \text{变更}, \text{结果}), \quad \Delta \text{Score} = \text{结果}_{\text{new}} - \text{结果}_{\text{old}}

AI 应用场景

电商客服Bot的Prompt优化

阶段:Prompt工程验证(MVP产品迭代)

解决的问题:传统客服Bot的Prompt是“写完就上线”,回答经常生硬、答非所问,用户满意度只有58%。用验证方法后,团队先确定“退货流程问答”为目标场景,收集真实客服对话构建测试集,用准确率、相关率、满意度四维指标打分,定位到“Prompt缺少共情引导”这一根因,修改后满意度提升至81%。

具体案例:某电商创业团队在MVP阶段发现客服机器人的退货回答虽然流程正确,但用户投诉“太官方”。团队用本文的反馈闭环方法,邀请10位真实用户试聊,收集“态度冷冰冰”等反馈,在Prompt中增加“先表达理解,再说明规则”的引导指令,重新跑AB测试后,用户满意度从2.9分提升到了4.1分。

内容种草文案生成

阶段:Prompt评估与AB测试

解决的问题:内容团队用AI生成种草文案,但生成结果时好时坏。通过建立“卖点覆盖、种草力、真实感”三维指标体系,以及每篇文案的点赞数、收藏数作为行为数据指标,团队用AB测试对比不同Prompt模板的表现,最终沉淀出3个高质量模板,文案平均打开率提升35%。

具体案例:一个美妆电商创业团队在发布AI生成文案前,先准备了20篇测试产品文案场景,用A/B两个Prompt模板分别生成,人工盲评打分后,B模板在“真实感”维度领先,后续将B模板的做法(加入真实使用细节和感受词)复制到所有商品文案中。

知识库问答机器人

阶段:Prompt召回策略验证

解决的问题:知识库问答QA Bot的准确率不佳,但问题到底是出在检索还是Prompt上?用“控制变量”思路分别验证:先固定检索策略,对比不同Prompt的准确率;再固定Prompt,对比不同检索策略的召回率。最终定位到Prompt中缺少“引用来源格式”的指令,导致答案无法溯源。

具体案例:某企业内部的规章制度问答Bot,员工频繁投诉“找不到原始政策依据”。通过验证流程设计,团队在Prompt中新增“你必须给出对应政策编号和原文引用”的指令,并将测试集从50条扩充到200条覆盖不同部门场景,准确率从72%提升至90%。

Python 演示

python52 行
# -*- coding: utf-8 -*-"""Prompt AB测试模拟器:对比两个Prompt版本在测试集上的表现."""import random  TEST_CASES = [    ("退款多久到账?", "退款在3-5个工作日内原路返回"),    ("可以改收货地址吗?", "订单未发货前可联系客服修改地址"),    ("怎么联系人工客服?", "抱歉给您带来不便,回复\"人工\"转接客服"),]  def score_answer(answer):    """模拟评分:返回(准确率, 相关率, 满意度)三维分数."""    base = 1.0 if len(answer) > 5 else 0.6    noise = random.uniform(-0.2, 0.2)    acc = max(0, min(1, base + noise))    rel = max(0, min(1, base + random.uniform(0, 0.1)))    sat = max(0, min(1, base + random.uniform(-0.1, 0.3)))    return acc, rel, sat  def run_ab_test(prompt_a, prompt_b, rounds=30):    """跑rounds轮AB测试, 返回双方平均分."""    sum_a = [0.0, 0.0, 0.0]    sum_b = [0.0, 0.0, 0.0]    for i in range(rounds):        question, good_answer = TEST_CASES[i % len(TEST_CASES)]        score_a = score_answer(prompt_a + good_answer)        score_b = score_answer(prompt_b + good_answer)        sum_a = [s + x for s, x in zip(sum_a, score_a)]        sum_b = [s + x for s, x in zip(sum_b, score_b)]    avg_a = [x / rounds for x in sum_a]    avg_b = [x / rounds for x in sum_b]    return avg_a, avg_b  def main():    prompt_a = "简洁回答:"    prompt_b = "请用礼貌亲切的语气简洁回答, 先共情再给方案:"    avg_a, avg_b = run_ab_test(prompt_a, prompt_b, rounds=30)    print("Prompt A 平均分:", [round(x, 3) for x in avg_a])    print("Prompt B 平均分:", [round(x, 3) for x in avg_b])    diff = sum(avg_b) - sum(avg_a)    if diff > 0:        print("结论: B版本综合表现更优, 建议替换A版本")    else:        print("结论: A版本仍占优, B版本不建议上线")  if __name__ == "__main__":    main()
目的:这个模拟器演示了AB测试的核心逻辑——同一批测试问题、同样的评分标准,两个Prompt版本各跑N轮,最后对比平均分决定是否替换。
  1. TEST_CASES构造测试集,模拟“场景覆盖清单”中的真实用户问题。
  2. score_answer(answer)模拟AI回复的三维评分,返回准确率、相关率、满意度。
  3. random.uniform(-0.2, 0.2)给评分加随机噪声,模拟真实模型的输出波动。
  4. run_ab_test(prompt_a, prompt_b, rounds=30)跑N轮AB测试,每次用测试集的一端对比两个版本。
  5. sum_a = [s + x for s, x in zip(sum_a, score_a)]用zip逐维度累加分数,最终除以轮数得到平均分。
  6. diff = sum(avg_b) - sum(avg_a)用综合分数差判断哪个版本更优,体现“基线对比”思维。
  7. if __name__ == "__main__":保证模块既可被导入也可直接运行。

常见误区

误区很多人拿一两个测试用例跑一下Prompt,看到回答还不错就认为“Prompt没问题了”。这就像只让一位朋友试吃一口就说这道菜能上菜单,完全忽略了样本量不足导致的随机性。

正解Prompt的输出有随机性,同一条输入在不同轮次可能得到不同质量的回答。至少准备20-50条覆盖典型场景的测试集,每项指标计算平均值,必要时跑多轮取均值。这就像餐厅试菜要请10位食客分别打分,去掉最高分和最低分再取平均,才能反映真实水平。

为何常见:MVP阶段资源有限,人们倾向于“先跑通再说”。此外,一两个例子恰好回答得好会给人“确实没问题”的错觉,这其实是幸存者偏差在作祟。

误区有些团队把准确率作为唯一指标,认为“回答正确就够了”。但他们忽略了用户实际使用时觉得“太生硬”“不像人话”——回答都对,但用户就是不爱用。

正解准确率只是“能吃”的底线,满意度才是“好吃”的上限。一个事实正确但冷冰冰的回答,和一个略有小错但语气亲切的回答,用户往往更愿意接受后者。评估指标体系里,满意度必须和准确率并列,甚至在小部分场景中优先级更高。就像餐厅的菜再正宗,服务员态度恶劣一样会丢客。

为何常见:因为准确率容易量化、自动化计算,满意度则需要设计问卷、组织人评,成本更高,于是团队贪图省事只测准确率。

误区有人做AB测试时为了“不损失用户体验”,把流量按9:1切分:90%用户走旧Prompt,10%用户走新Prompt。结果是新版本样本太少,跑了一周也看不出显著差异。

正解AB测试的核心是“同样的样本量才能比”。流量切分不均匀会导致实验组的置信区间过宽,无法得出有效结论。MVP阶段测试流量本来就少,建议按50:50切分,用更短的周期换取更可靠的结论;如果担心风险,可以先用离线测试集跑足够的轮次,再上线小流量验证。

为何常见:创业者担心新Prompt效果不好会影响付费用户,于是“保护性”地切小流量。但这种保护恰恰让实验失去统计效力,反而拖慢决策。

误区有些团队只看新Prompt的绝对分数,看到“准确率85%”就觉得不错,却没有对比旧版本是多少。如果旧版本已经是84%,那你折腾半天只提升了1个百分点——值不值得换版就值得商榷了。

正解验证结论必须建立在“和基线对比”的基础上。阈值是及格线,解决的是“够不够好”;基线对比解决的是“值不值得换”。MVP阶段每次迭代都要明确记录旧版本分数,用提升幅度来评判新版本是否值得替换。这就像新菜要上菜单,不仅要好吃,还得比老菜好吃到值得冒风险换菜单。

误区团队收集了用户反馈,整理成文档发到群里,然后……就没有然后了。反馈躺在文档里,Prompt该什么样还什么样,下一次迭代完全不参考这些反馈。

正解反馈的价值在于驱动迭代,闭环公式是“收集→分类→改进→再验证”。每次收集反馈后,必须输出至少一条Prompt修改动作,修改后重新跑测试集验证问题是否修复。没有闭环的反馈等于没有反馈——就像餐厅记录了顾客投诉却从不改进菜品,客人不会因为你的记录本厚就再来一次。

面试题

Q1. 在Prompt验证流程中,“黄金三角”是指哪三个要素?

单选题 · mid

  • A.成本、速度、质量
  • B.目标、场景、标准← 正确答案
  • C.输入、输出、反馈
  • D.模型、数据、参数

答案:B。黄金三角是验证流程的三大支柱:目标回答“做给谁用”,场景回答“什么情况用”,标准回答“怎样算好”。成本/速度/质量是项目约束,输入/输出/反馈是系统组件,模型/数据/参数是技术要素,它们都不构成验证的黄金三角。记住“定目标、画场景、定标尺”这个口诀。

Q2. 准确率和相关率的本质区别是什么?

单选题 · easy

  • A.一个是自动计算,一个是人工打分
  • B.准确率看“对不对”,相关率看“答没答到点子上”← 正确答案
  • C.准确率针对客观题,相关率针对主观题
  • D.两者没有本质差别,只是名字不同

答案:B。准确率衡量回答的事实正确性,比如“退款3-5天”这个数字对不对;相关率衡量回答是否紧扣用户问题主旨,比如用户问“怎么退款”你却回答“退货政策是什么”就是相关率低。一道菜“新鲜”不等于“客人点的是这道菜”,这就是准确率和相关率的差别。

Q3. AB测试中样本量过少可能导致什么问题?

单选题 · mid

  • A.模型过拟合
  • B.结论是随机噪声,置信度不足← 正确答案
  • C.Prompt无法收敛
  • D.用户数据泄露

答案:B。样本量太小时,两个版本的得分差异可能在统计上不显著,你看到的“B比A高5%”只是运气。这就像只让两个人试吃就判断哪道菜更好吃,结果完全可能因个人口味偏差而失真。样本量公式的核心就是用波动程度和最小检测差异推导出所需的测试轮数。

Q4. 在AB测试中,以下哪些做法是正确的?

多选题 · mid

  • A.保持A/B两个Prompt只差一个变量← 正确答案
  • B.将用户随机分配到两个版本← 正确答案
  • C.让A组用户先测,B组用户后测
  • D.用p值判断结果是否显著← 正确答案

答案:ABD。控制变量(A对)、随机分流(B对)、显著性检验(D对)是AB测试的三大支柱。C选项“先测A再测B”引入了时间顺序的系统性偏差——随着时间推移用户群体可能变化,就像先让上午的客人试新菜、下午的客人试老菜,结果可能被“时段”而非“菜品”左右。

Q5. 召回率在Prompt评估中衡量的是什么?

单选题 · easy

  • A.回答中正确信息的比例
  • B.回答覆盖用户问题关键点的程度← 正确答案
  • C.模型响应的速度
  • D.用户点击回答的比例

答案:B。召回率衡量的是“该说的说全了没有”。比如用户问“怎么退款,需要什么材料,多久到账”,AI只回答了“3-5天到账”,没提材料要求,就是关键信息漏了。召回率低就像餐厅上菜时少给了一副餐具,菜对了但体验不完整。

Q6. 新Prompt在准确率上比旧版本提升了2%(从83%到85%),但满意度下降了0.3分(从4.2到3.9),是否应该替换?

单选题 · hard

  • A.应该替换,准确率提升说明回答质量更好
  • B.不应该替换,满意度下降可能损害用户体验← 正确答案
  • C.两相抵消,无法判断
  • D.应该替换,准确率是硬指标

答案:B。这题考察“硬指标和软指标”的划分。如果满意度被设定为硬指标(不能低于4.0),那么3.9分已经跌破及格线,即使准确率提升也不能替换。就像餐厅的新菜虽然食材更高级(准确率提升),但客人普遍觉得服务生端菜时态度变差了(满意度下降),这道菜依然不能上菜单。

Q7. 验证结果未达标时,合理的迭代策略有哪些?

多选题 · hard

  • A.无限制地继续修改Prompt,直到满意为止
  • B.设定迭代上限,如最多3轮← 正确答案
  • C.每轮只修改一个变量,确保能归因← 正确答案
  • D.全部推翻,用全新的Prompt思路重写← 正确答案

答案:BCD。B选项设定迭代上限避免无限空转,C选项控制变量确保能定位是哪处修改起了作用,D选项在连续迭代无效后换思路是合理决策。A选项“无限修改”会消耗大量时间——MVP阶段最怕在单点上无限磨,设定上限倒逼团队做减法。

Q8. 用户反馈收集的三大渠道是哪些?

单选题 · mid

  • A.问卷、访谈、行为数据← 正确答案
  • B.邮件、电话、短信
  • C.好评、差评、投诉
  • D.点赞、评论、转发

答案:A。问卷规模化收集量化评分,访谈深度挖掘痛点原因,行为数据捕捉用户无声的“用脚投票”。三源汇集成反馈闭环。邮件电话短信是触达方式而非反馈渠道设计,好评差评投诉是被动接收而非主动收集,点赞评论转发则偏向营销场景而非产品迭代场景。

Q9. 设定Prompt通过标准时,“基线对比”解决的是什么问题?

单选题 · mid

  • A.回答是否达到及格线
  • B.新版本比旧版本好多少才值得替换← 正确答案
  • C.测试集是否覆盖了所有场景
  • D.用户是否喜欢这个Prompt

答案:B。阈值回答“够不够好”,基线对比回答“值不值得换”。如果一个新Prompt只比旧版本好0.5%,替换的风险(新Bug、用户不适应)可能超过收益。就像餐厅换主厨,新主厨的菜必须明显好于旧主厨才有可能抵消换人的风波。

Q10. 验证清单工具包含哪些子清单?

多选题 · easy

  • A.场景覆盖清单← 正确答案
  • B.边界测试清单← 正确答案
  • C.硬件配置清单
  • D.迭代记录清单← 正确答案

答案:ABD。四张清单分别是场景覆盖(测了哪些场景)、边界测试(异常输入有没有覆盖)、质量检查(四项指标是否评分)、迭代记录(每次改了什么、为什么改、结果如何)。硬件配置不属于Prompt验证范畴——这就像餐厅的后厨检查表不会包含“收银台用哪个品牌的POS机”。