如果你把 AI 功能当成普通软件功能来设计,结果很可能会让用户失望。

普通软件是确定的——你点保存,它就保存,每次都一样。
AI 产品是概率的——你让它写文案,它这次写得很好,下次可能就不行。
普通软件出错时,会报错提示,AI 产品出错时,可能会一本正经地胡说八道,让你以为它是对的。
这种本质差异,决定了 AI 产品设计需要一套全新的思路。
传统产品设计追求零缺陷,用户每次都得到相同的结果。AI 产品设计要接受 概率输出 ,帮助用户理解和应对结果的不确定性。
要设计好 AI 产品,先得理解 AI 的独特性,以及它会给用户带来怎样的心理变化。
大模型的输出本质上是概率抽样,同样的问题,每次问可能得到不同的答案,有时好,有时坏,有时平庸,这通常不是异常,是 AI 的特性。
对设计师来说,这意味着几个关键原则:
| 设计原则 | 具体做法 | 为什么重要 |
|---|---|---|
| 提供重试机制 | 让用户可以"再生成一次" | 不满意时,给用户第二次机会 |
| 展示多个选项 | 同时生成 3-5 个版本供选择 | 增加用户找到满意结果的概率 |
| 允许编辑修改 | AI 生成的内容要易于编辑 | 用户可以修正不完美的地方 |
| 设置质量预期 | 告诉用户"结果可能需要调整" | 避免用户期望过高 |
优秀的 AI 产品不会试图掩盖这种不确定性,而是把它转化为一种优势。
用户对 AI 的期望经常在两个极端之间摇摆:要么期待太高,要么完全不信。
第一次用 ChatGPT 的人,常常会惊呼太神奇了,觉得 AI 无所不能。
等到 AI 犯了一个低级错误,又可能立刻转向 AI 也就那样。
产品设计师的任务,是 把用户的期望引导到一个合理的区间 。
怎么做?
第一,明确告诉用户 AI 能做什么、不能做什么。
第二,当 AI 犯错时,不要试图隐瞒,而是坦诚面对。
第三,给用户控制权——让用户可以调整、编辑、否决 AI 的输出。
好的 AI 产品会让用户觉得:AI 是我的助手,不是我的老板。
AI 产品的失败方式和传统软件很不一样。
传统软件要么能用,要么不能用——崩溃了、报错了、功能不工作了。
AI 产品的失败更微妙:
| 失败模式 | 表现 | 应对策略 |
|---|---|---|
| 幻觉 | 编造不存在的事实、引用、数据 | 增加事实核查、提供来源标注、允许用户验证 |
| 对齐失败 | 回答的内容与用户意图不符 | 提供澄清问题、让用户确认意图、多轮对话优化 |
| 输出质量不稳定 | 有时很好,有时很差 | 提供多个选项、允许重试、让用户评分反馈 |
| 过度自信 | 用肯定的语气说错话 | 添加置信度显示、用更谨慎的表述、鼓励质疑 |
| 上下文丢失 | 忘记之前对话的关键信息 | 显示上下文摘要、允许引用历史、提供对话记忆管理 |
理解这些失败模式,是设计好 AI 产品的第一步。
三个核心原则:渐进式披露、用户可控、透明告知。
不要把所有功能都堆在用户面前。
理想的流程是:先给用户一个简单的起点,然后根据需要逐步展示更多选项。
比如,用户写邮件:
第一步:输入主题或关键词,AI 生成初稿。
第二步:用户看了初稿,可以调整语气、长度、风格。
第三步:如果需要,可以进一步修改特定段落,或者让 AI 提供几个不同版本。
这种设计的好处是:
新手不会被复杂的选项吓倒,专家又能找到足够的控制能力。
| 阶段 | 用户看到 | 用户操作 |
|---|---|---|
| 初始界面 | 简洁输入框 | 输入基本需求 |
| 生成后 | 结果 + 基础调整选项 | 选择"更正式"、"更简洁"等 |
| 展开高级选项 | 详细参数控制 | 调整温度、角色、格式等 |
用户需要感觉到,他们是最终的决策者。
提供控制旋钮,而不是"要么接受要么离开"的一次性结果。
常见的控制维度:
| 控制维度 | 典型选项 | 适用场景 |
|---|---|---|
| 风格/语气 | 正式、随意、幽默、专业 | 写作、邮件、文案 |
| 长度 | 简短、中等、详细、长篇 | 摘要、文章、报告 |
| 复杂度 | 简单易懂、中等、专业深度 | 解释、教程、技术文档 |
| 创造性 | 保守、平衡、大胆创新 | 头脑风暴、创意写作 |
| 格式 | 列表、段落、表格、大纲 | 笔记、规划、文档 |
更高级的控制:让用户直接编辑 AI 的提示词,或者保存自己常用的提示词模板。
让用户知道他们在和 AI 交互,这不仅是伦理问题,也是产品体验问题。
用户如果以为是真人写的,发现是 AI 后会有被欺骗的感觉。
如果一开始就说明是 AI 生成,用户反而会更宽容,也更愿意参与改进。
透明度的几种做法:
第一,明确标识——用视觉元素区分 AI 内容和用户内容。
第二,展示过程——让用户看到 AI 是如何生成结果的(比如显示思考过程、检索到的来源)。
第三,解释局限——告诉用户 AI 可能会犯什么类型的错误,以及如何识别。
透明度建立信任。用户知道这是 AI,就会用正确的方式使用它——参考而非盲目信任。
AI 产品有几个关键的体验节点:加载状态、错误处理、反馈机制。
大模型生成内容需要时间。让用户干等 10 秒,体验会很差。
最好的做法是 流式输出 ——内容一个字一个字地出现在屏幕上。
为什么好?
第一,用户感觉系统在工作,没有死机。
第二,用户可以提前开始阅读,看到一半就知道是不是想要的方向。
第三,如果方向错了,可以随时打断,不用等全部生成完。
除了流式输出,还可以:
显示进度指示器——"正在思考"、"正在检索"、"正在生成"。
给出预估时间——"大约需要 10 秒"。
提供取消按钮——让用户可以随时停止。
AI 一定会犯错。好的产品设计让错误不那么可怕。
当 AI 输出明显有问题时:
第一,给用户一个简单的"不满意"或"重试"按钮。
第二,提供替代方案——"要不试试这个角度?"。
第三,允许用户轻松回滚到之前的状态。
更严重的错误(比如模型完全不工作):
要有降级方案。比如,当 AI 不可用时,提供一个模板库让用户手动选择。
| 错误程度 | 用户表现 | 产品应对 |
|---|---|---|
| 轻微问题 | 结果有点瑕疵,但能用 | 提供编辑功能,让用户微调 |
| 中等问题 | 结果不对,需要重生成 | 提供重试按钮,或建议调整输入 |
| 严重问题 | AI 完全不工作 | 提供降级方案,比如模板库 |
用户的反馈是改进 AI 产品的宝贵资源。
但反馈功能不能做得太复杂,否则用户不愿用。
简单有效的反馈设计:
第一,点赞/点踩——一键表达满意或不满意。
第二,简短的多选——"哪里不好?"(太长、太短、跑题、事实错误……)。
第三,可选的文本框——让用户可以详细说明问题,但不是必填。
第四,告诉用户反馈有什么用——"你的反馈会帮助我们改进"。
反馈收集后,最好在界面上给用户一个确认——"感谢你的反馈,我们收到了"。
好的提示词是 AI 产品的核心竞争力。把提示词从"魔法"变成可管理的产品功能。
普通用户不需要知道什么是"系统提示词"。
他们只需要知道:点击这个按钮,就能得到正式邮件的草稿。
所以,设计师的工作是把复杂的提示词封装成简单的功能按钮。
举个例子:
原始提示词可能很长:
你是一个专业的邮件写作助手。请帮用户写一封正式、礼貌、简洁的商务邮件。要求:1. 开头要有合适的称呼;2. 正文表达清晰;3. 结尾要有礼貌的结束语。语气要专业但不生硬,友好但不过分随意。
产品化后,用户看到的只是:
一个按钮——"写商务邮件"。
几个简单选项——"正式/中性/友好"、"简短/详细"。
这就是提示词产品化的核心: 复杂留给自己,简单留给用户 。
提示词不是写好就完事了,它需要持续迭代。
你可能发现:新版本的提示词对场景 A 更好,但对场景 B 变差了。
所以,提示词需要像代码一样做版本管理。
关键做法:
第一,给每个版本一个编号或名称——"v1.0"、"v1.1"、"实验版-更友好"。
第二,记录每个版本的变更——"改了什么、为什么改、预期效果"。
第三,可以同时运行多个版本做 A/B 测试。
第四,可以快速回滚到之前的版本。
提示词迭代时,永远保留回滚的能力。新版本可能带来意想不到的问题。
两个版本的提示词,哪个更好?不要猜,用数据说话。
A/B 测试的思路:
一部分用户用版本 A,一部分用户用版本 B。
看哪个版本的用户满意度更高、重试率更低、完成率更好。
下面是一个简单的 Python 脚本,演示如何做 Prompt 的 A/B 测试分析:
# ============================================# Prompt A/B 测试分析脚本
# 用于比较两个版本提示词的效果
# ============================================
from dataclasses import dataclass
from typing import List, Dict, Optional
import statistics
@dataclass
class TestResult:
"""单个测试结果的数据结构"""
prompt_version: str# "A" 或 "B"
user_satisfaction: int# 用户满意度 1-5
retry_count: int# 用户重试次数
task_completed: bool# 任务是否完成
time_spent_seconds: int# 花费时间
test_case_id: str# 测试用例标识(比如不同的查询类型)
def analyze_ab_test(results: List[TestResult]) -> Dict:
"""分析 A/B 测试结果,返回对比统计"""
# 按版本分组
group_a =[r for r in results if r.prompt_version=="A"]
group_b =[r for r in results if r.prompt_version=="B"]
ifnot group_a ornot group_b:
return{"error": "需要至少两个版本的测试数据"}
def calc_stats(group: List[TestResult]) -> Dict:
"""计算单个组的统计数据"""
satisfaction_scores =[r.user_satisfactionfor r in group]
return{
"sample_size": len(group),
"avg_satisfaction": statistics.mean(satisfaction_scores),
"median_satisfaction": statistics.median(satisfaction_scores),
"avg_retry": statistics.mean([r.retry_countfor r in group]),
"completion_rate": sum(1for r in group if r.task_completed) / len(group),
"avg_time": statistics.mean([r.time_spent_secondsfor r in group]),
}
stats_a = calc_stats(group_a)
stats_b = calc_stats(group_b)
# 比较关键指标
comparison ={
"satisfaction_diff": stats_b["avg_satisfaction"] - stats_a["avg_satisfaction"],
"retry_diff": stats_b["avg_retry"] - stats_a["avg_retry"],
"completion_diff": stats_b["completion_rate"] - stats_a["completion_rate"],
}
# 也可以按测试用例细分(比如不同类型的查询)
by_test_case ={}
test_case_ids =set(r.test_case_idfor r in results)
for case_id in test_case_ids:
case_results =[r for r in results if r.test_case_id== case_id]
case_a =[r for r in case_results if r.prompt_version=="A"]
case_b =[r for r in case_results if r.prompt_version=="B"]
if case_a and case_b:
by_test_case[case_id]={
"a_score": statistics.mean(r.user_satisfactionfor r in case_a),
"b_score": statistics.mean(r.user_satisfactionfor r in case_b),
}
return{
"version_a": stats_a,
"version_b": stats_b,
"comparison": comparison,
"by_test_case": by_test_case,
"winner": _determine_winner(stats_a, stats_b),
}
def _determine_winner(stats_a: Dict, stats_b: Dict) -> Optional[str]:
"""根据统计数据判断哪个版本更好"""
# 综合考虑满意度、完成率、重试次数
a_score =(
stats_a["avg_satisfaction"] * 0.5 +
stats_a["completion_rate"] * 10 * 0.3 +
(5 - stats_a["avg_retry"]) * 0.2
)
b_score =(
stats_b["avg_satisfaction"] * 0.5 +
stats_b["completion_rate"] * 10 * 0.3 +
(5 - stats_b["avg_retry"]) * 0.2
)
# 差异太小则不确定
ifabs(a_score - b_score)<0.1:
return"tie"# 平手
return"A"if a_score > b_score else"B"
def print_report(analysis: Dict) ->None:
"""打印可读的 A/B 测试报告"""
print("=" * 60)
print("RUNOOB Prompt A/B 测试报告")
print("=" * 60)
if"error"in analysis:
print(f"错误: {analysis['error']}")
return
print(f"n版本 A (基准):")
print(f" 样本量: {analysis['version_a']['sample_size']}")
print(f" 平均满意度: {analysis['version_a']['avg_satisfaction']:.2f}/5")
print(f" 完成率: {analysis['version_a']['completion_rate']:.1%}")
print(f" 平均重试次数: {analysis['version_a']['avg_retry']:.2f}")
print(f"n版本 B (新方案):")
print(f" 样本量: {analysis['version_b']['sample_size']}")
print(f" 平均满意度: {analysis['version_b']['avg_satisfaction']:.2f}/5")
print(f" 完成率: {analysis['version_b']['completion_rate']:.1%}")
print(f" 平均重试次数: {analysis['version_b']['avg_retry']:.2f}")
print(f"n对比结果:")
diff = analysis["comparison"]
print(f" 满意度变化: {diff['satisfaction_diff']:+.2f}")
print(f" 完成率变化: {diff['completion_diff']:+.1%}")
print(f" 重试次数变化: {diff['retry_diff']:+.2f}")
winner = analysis["winner"]
if winner =="tie":
print("n结论: 两个版本效果相当,需要更多数据或调整")
else:
print(f"n结论: 版本 {winner} 表现更好")
if analysis.get("by_test_case"):
print(f"n按测试用例细分:")
for case_id, scores in analysis["by_test_case"].items():
better ="A"if scores["a_score"]> scores["b_score"]else"B"
print(f" {case_id}: A={scores['a_score']:.2f}, B={scores['b_score']:.2f} ({better}更好)")
# ============================================
# 使用示例
# ============================================
if __name__ =="__main__":
# 模拟一些测试数据
test_data =[
# 版本 A 的测试结果
TestResult("A",4,0,True,15,"邮件写作"),
TestResult("A",3,1,True,25,"邮件写作"),
TestResult("A",5,0,True,12,"摘要生成"),
TestResult("A",2,2,True,40,"摘要生成"),
TestResult("A",4,0,True,18,"代码解释"),
TestResult("A",3,1,False,35,"代码解释"),
# 版本 B 的测试结果
TestResult("B",5,0,True,12,"邮件写作"),
TestResult("B",4,0,True,18,"邮件写作"),
TestResult("B",4,0,True,10,"摘要生成"),
TestResult("B",3,1,True,25,"摘要生成"),
TestResult("B",5,0,True,15,"代码解释"),
TestResult("B",4,0,True,20,"代码解释"),
]
# 分析并打印报告
analysis_result = analyze_ab_test(test_data)
print_report(analysis_result)
运行这个脚本,你会得到一个清晰的 A/B 测试报告,知道哪个版本的提示词效果更好。
============================================================RUNOOB Prompt A/B 测试报告============================================================版本 A (基准): 样本量: 6 平均满意度: 3.50/5 完成率: 83.3% 平均重试次数: 0.67版本 B (新方案): 样本量: 6 平均满意度: 4.17/5 完成率: 100.0% 平均重试次数: 0.17对比结果: 满意度变化: +0.67 完成率变化: +16.7% 重试次数变化: -0.50结论: 版本 B 表现更好按测试用例细分: 邮件写作: A=3.50, B=4.50 (B更好) 摘要生成: A=3.50, B=3.50 (A更好) 代码解释: A=3.50, B=4.50 (B更好)
在投入大量开发资源前,先用低成本方式验证 AI 功能是否真的有用。
最简单的原型:直接用大模型聊天界面模拟产品功能。
比如你想做一个面试问题生成器:写一个提示词,描述你想要的功能,然后输入一些测试用例,看看输出质量。
这个阶段的目标是验证:
第一,AI 能不能做这件事?
第二,输出质量够不够好?
第三,用户会觉得这个功能有用吗?
不需要写代码,不需要设计界面,就用纯文本对话测试核心价值。
如果这个阶段效果不好,要么改进提示词,要么重新考虑这个功能是否值得做。
确定核心功能有价值后,下一步可以做高保真原型。
Figma 是做这个的好工具。
你可以设计:
用户如何输入?
AI 输出如何展示?
用户如何调整和编辑?
关键是 模拟真实的交互流程 ,而不只是画静态界面。
可以用 Figma 的交互功能,让用户点击按钮时"生成"不同的内容(你提前准备几个示例结果)。
这样用户可以感受到:哦,原来这个产品是这样用的。
如果需要更真实的体验,可以用低代码工具快速搭建可工作的原型。
这类工具可以让你不用写后端代码,就能把大模型接入到一个真正的网页应用里。
好处是:
用户可以真实操作,而不只是看演示。
你可以收集真实的使用数据和反馈。
验证成功后,可以把这个原型作为开发的参考。
原型的目标是学习,不是完美。用最快的速度验证想法,发现问题,然后迭代。
如何判断 AI 输出好不好?需要定性和定量结合的评估体系。
有些东西只能靠人来判断。
比如:回答有没有帮助?语气是否合适?逻辑是否通顺?
人工 Review 的做法:
第一,设计一个评分维度表——比如相关性、准确性、有用性、安全性。
第二,让多个评审者独立打分,减少个人偏见。
第三,把评分和评语整理成可操作的改进建议。
人工 Review 很重要,但它慢、贵、难以规模化。所以需要结合自动化评估。
用程序来评估 AI 的输出。
常见的自动化评估方法:
| 方法 | 做法 | 适用场景 |
|---|---|---|
| 基于规则的检查 | 检查关键词、格式、长度、是否包含敏感内容 | 基础质量控制 |
| LLM 自评 | 用另一个大模型来评估输出质量 | 开放式任务 |
| 语义相似度 | 比较输出和参考答案的语义接近程度 | 有标准答案的任务 |
| 用户行为指标 | 统计重试率、完成率、满意度评分 | 上线后的持续监控 |
自动化评估不能完全替代人,但它可以:
第一,快速过滤明显有问题的输出。
第二,在版本迭代时做回归测试——"这次修改有没有让某些场景变差?"。
第三,监控线上服务质量,及时发现问题。
收集一组高质量的测试用例,每次修改提示词或模型时都在这个集合上跑一遍。
这就是 黄金测试集 。
好的测试集应该:
第一,覆盖典型使用场景——常见的用户请求类型。
第二,包含边界情况——极端的、容易出错的输入。
第三,有标准答案或评分标准——知道什么是"好"的输出。
第四,规模适中——几十到几百个,足够有代表性,但又不会跑得太慢。
黄金测试集就像一张安全网:你可以放心地迭代,不用担心意外破坏了重要场景的效果。
有了好产品,如何让它产生收入?AI 产品有几种常见的商业化模式。
| 模式 | 做法 | 典型例子 | 优势 | 挑战 |
|---|---|---|---|---|
| 订阅制 | 按月/按年付费使用 | ChatGPT Plus | 收入稳定,可预测 | 需要持续提供价值 |
| 按量计费 | 按使用量付费(每次调用或 token) | OpenAI API | 用户门槛低,可按需使用 | 用户可能担心成本 |
| 免费+增值 | 基础功能免费,高级功能付费 | Notion AI | 容易获取用户 | 把握好免费与付费的边界 |
| 嵌入企业产品 | 把 AI 能力卖给企业客户 | 客服机器人、文档助手 | 客单价高,决策周期长 | 需要销售和客户成功团队 |
选择哪种模式,取决于你的产品定位和目标用户。
对普通消费者,免费+增值或订阅制比较常见。
对企业客户,按用量付费或定制化方案更合适。
但无论哪种模式,核心都是: 用户要能实实在在地感受到价值 。
让我们看看几个做得好的 AI 产品,学习它们的设计思路。
ChatGPT 的成功不仅仅是技术的成功,也是设计的成功。
它的核心设计决策:
第一,用对话形式——用户不需要学习新的交互方式,就像和人聊天一样。
第二,流式输出——字一个一个蹦出来,用户感觉 AI 在思考。
第三,上下文记忆——你可以说"把刚才那段改得更短一点",它记得"刚才那段"是什么。
第四,简单的重试——不满意?点"重新生成"就好。
第五,对话历史管理——你可以回去看之前的对话,继续之前的话题。
这些设计看起来简单,但组合起来创造了流畅的体验。
Copilot 没有试图"替代程序员",而是"增强程序员"。
它的设计智慧:
第一,不打断——AI 在后台工作,你写代码时它主动提供建议,不干扰你的思路。
第二,低承诺——你可以看 AI 的建议,觉得好就按 Tab 接受,不好就继续打字。
第三,上下文感知——它看你写的代码、注释、文件名,理解你想做什么。
第四,多选项——它会给几个建议,你可以挑一个最符合你意图的。
Copilot 的成功说明: 最好的 AI 产品是让用户感觉不到 AI 的存在,只感觉自己变厉害了 。
Notion AI 没有做一个独立产品,而是把 AI 能力嵌入到已有的笔记工具里。
它的设计亮点:
第一,上下文就是你的文档——你不需要复制粘贴,AI 就在你写的地方工作。
第二,预设模板——"继续写"、"总结"、"改得更正式",常用操作一键触发。
第三,可以混合编辑——AI 生成的内容,你可以随时修改,AI 也能接着你的修改继续写。
这种设计让 AI 成为创作过程的一部分,而不是一个独立的工具。
从这三个案例可以看出:好的 AI 产品不是炫技,而是真正解决问题,让用户的工作更容易。