HoRain云--AI 产品设计
2026/7/10 7:57:03 网站建设 项目流程

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

  • 普通软件是确定的——你点保存,它就保存,每次都一样。

  • AI 产品是概率的——你让它写文案,它这次写得很好,下次可能就不行。

普通软件出错时,会报错提示,AI 产品出错时,可能会一本正经地胡说八道,让你以为它是对的。

这种本质差异,决定了 AI 产品设计需要一套全新的思路。

传统产品设计追求零缺陷,用户每次都得到相同的结果。AI 产品设计要接受概率输出,帮助用户理解和应对结果的不确定性。


AI 产品思维

要设计好 AI 产品,先得理解 AI 的独特性,以及它会给用户带来怎样的心理变化。

概率性输出

大模型的输出本质上是概率抽样,同样的问题,每次问可能得到不同的答案,有时好,有时坏,有时平庸,这不是 bug,是 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 内容和用户内容。

  • 第二,展示过程——让用户看到 AI 是如何生成结果的(比如显示思考过程、检索到的来源)。

  • 第三,解释局限——告诉用户 AI 可能会犯什么类型的错误,以及如何识别。

透明度建立信任。用户知道这是 AI,就会用正确的方式使用它——参考而非盲目信任。


用户体验设计

AI 产品有几个关键的体验节点:加载状态、错误处理、反馈机制。

Loading 状态设计:流式输出

大模型生成内容需要时间。让用户干等 10 秒,体验会很差。

最好的做法是流式输出——内容一个字一个字地出现在屏幕上。

为什么好?

  • 第一,用户感觉系统在工作,没有死机。

  • 第二,用户可以提前开始阅读,看到一半就知道是不是想要的方向。

  • 第三,如果方向错了,可以随时打断,不用等全部生成完。

除了流式输出,还可以:

  • 显示进度指示器——"正在思考"、"正在检索"、"正在生成"。

  • 给出预估时间——"大约需要 10 秒"。

  • 提供取消按钮——让用户可以随时停止。

错误处理与降级方案

AI 一定会犯错。好的产品设计让错误不那么可怕。

当 AI 输出明显有问题时:

  • 第一,给用户一个简单的"不满意"或"重试"按钮。

  • 第二,提供替代方案——"要不试试这个角度?"。

  • 第三,允许用户轻松回滚到之前的状态。

更严重的错误(比如模型完全不工作):

要有降级方案。比如,当 AI 不可用时,提供一个模板库让用户手动选择。

错误程度用户表现产品应对
轻微问题结果有点瑕疵,但能用提供编辑功能,让用户微调
中等问题结果不对,需要重生成提供重试按钮,或建议调整输入
严重问题AI 完全不工作提供降级方案,比如模板库

反馈机制

用户的反馈是改进 AI 产品的宝贵资源。

但反馈功能不能做得太复杂,否则用户不愿用。

简单有效的反馈设计:

  • 第一,点赞/点踩——一键表达满意或不满意。

  • 第二,简短的多选——"哪里不好?"(太长、太短、跑题、事实错误……)。

  • 第三,可选的文本框——让用户可以详细说明问题,但不是必填。

  • 第四,告诉用户反馈有什么用——"你的反馈会帮助我们改进"。

反馈收集后,最好在界面上给用户一个确认——"感谢你的反馈,我们收到了"。


Prompt 产品化

好的提示词是 AI 产品的核心竞争力。把提示词从"魔法"变成可管理的产品功能。

将 Prompt 封装为产品功能

普通用户不需要知道什么是"系统提示词"。

他们只需要知道:点击这个按钮,就能得到正式邮件的草稿。

所以,设计师的工作是把复杂的提示词封装成简单的功能按钮。

举个例子:

原始提示词可能很长:

你是一个专业的邮件写作助手。请帮用户写一封正式、礼貌、简洁的商务邮件。 要求:1. 开头要有合适的称呼;2. 正文表达清晰;3. 结尾要有礼貌的结束语。 语气要专业但不生硬,友好但不过分随意。

产品化后,用户看到的只是:

  • 一个按钮——"写商务邮件"。

  • 几个简单选项——"正式/中性/友好"、"简短/详细"。

这就是提示词产品化的核心:复杂留给自己,简单留给用户。

System Prompt 的版本管理

提示词不是写好就完事了,它需要持续迭代。

你可能发现:新版本的提示词对场景 A 更好,但对场景 B 变差了。

所以,提示词需要像代码一样做版本管理。

关键做法:

  • 第一,给每个版本一个编号或名称——"v1.0"、"v1.1"、"实验版-更友好"。

  • 第二,记录每个版本的变更——"改了什么、为什么改、预期效果"。

  • 第三,可以同时运行多个版本做 A/B 测试。

  • 第四,可以快速回滚到之前的版本。

提示词迭代时,永远保留回滚的能力。新版本可能带来意想不到的问题。

A/B 测试 Prompt

两个版本的提示词,哪个更好?不要猜,用数据说话。

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"]

if not group_a or not group_b:
return {"error": "需要至少两个版本的测试数据"}

def calc_stats(group: List[TestResult]) -> Dict:
"""计算单个组的统计数据"""
satisfaction_scores = [r.user_satisfaction for 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_count for r in group]),
"completion_rate": sum(1 for r in group if r.task_completed) / len(group),
"avg_time": statistics.mean([r.time_spent_seconds for 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_id for 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_satisfaction for r in case_a),
"b_score": statistics.mean(r.user_satisfaction for 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
)

# 差异太小则不确定
if abs(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 功能是否真的有用。

用 Claude/ChatGPT 快速原型

最简单的原型:直接用大模型聊天界面模拟产品功能。

比如你想做一个面试问题生成器:写一个提示词,描述你想要的功能,然后输入一些测试用例,看看输出质量。

这个阶段的目标是验证:

  • 第一,AI 能不能做这件事?

  • 第二,输出质量够不够好?

  • 第三,用户会觉得这个功能有用吗?

不需要写代码,不需要设计界面,就用纯文本对话测试核心价值。

如果这个阶段效果不好,要么改进提示词,要么重新考虑这个功能是否值得做。

Figma 中的 AI 原型组件

确定核心功能有价值后,下一步可以做高保真原型。

Figma 是做这个的好工具。

你可以设计:

  • 用户如何输入?

  • AI 输出如何展示?

  • 用户如何调整和编辑?

关键是模拟真实的交互流程,而不只是画静态界面。

可以用 Figma 的交互功能,让用户点击按钮时"生成"不同的内容(你提前准备几个示例结果)。

这样用户可以感受到:哦,原来这个产品是这样用的。

低代码 AI 应用工具

如果需要更真实的体验,可以用低代码工具快速搭建可工作的原型。

这类工具可以让你不用写后端代码,就能把大模型接入到一个真正的网页应用里。

好处是:

用户可以真实操作,而不只是看演示。

你可以收集真实的使用数据和反馈。

验证成功后,可以把这个原型作为开发的参考。

原型的目标是学习,不是完美。用最快的速度验证想法,发现问题,然后迭代。


评估 AI 输出质量

如何判断 AI 输出好不好?需要定性和定量结合的评估体系。

定性评估:人工 Review

有些东西只能靠人来判断。

比如:回答有没有帮助?语气是否合适?逻辑是否通顺?

人工 Review 的做法:

  • 第一,设计一个评分维度表——比如相关性、准确性、有用性、安全性。

  • 第二,让多个评审者独立打分,减少个人偏见。

  • 第三,把评分和评语整理成可操作的改进建议。

人工 Review 很重要,但它慢、贵、难以规模化。所以需要结合自动化评估。

定量评估:自动化评测

用程序来评估 AI 的输出。

常见的自动化评估方法:

方法做法适用场景
基于规则的检查检查关键词、格式、长度、是否包含敏感内容基础质量控制
LLM 自评用另一个大模型来评估输出质量开放式任务
语义相似度比较输出和参考答案的语义接近程度有标准答案的任务
用户行为指标统计重试率、完成率、满意度评分上线后的持续监控

自动化评估不能完全替代人,但它可以:

  • 第一,快速过滤明显有问题的输出。

  • 第二,在版本迭代时做回归测试——"这次修改有没有让某些场景变差?"。

  • 第三,监控线上服务质量,及时发现问题。

黄金测试集构建

收集一组高质量的测试用例,每次修改提示词或模型时都在这个集合上跑一遍。

这就是黄金测试集。

好的测试集应该:

  • 第一,覆盖典型使用场景——常见的用户请求类型。

  • 第二,包含边界情况——极端的、容易出错的输入。

  • 第三,有标准答案或评分标准——知道什么是"好"的输出。

  • 第四,规模适中——几十到几百个,足够有代表性,但又不会跑得太慢。

黄金测试集就像一张安全网:你可以放心地迭代,不用担心意外破坏了重要场景的效果。


AI 产品的商业化路径

有了好产品,如何让它产生收入?AI 产品有几种常见的商业化模式。

模式做法典型例子优势挑战
订阅制按月/按年付费使用ChatGPT Plus收入稳定,可预测需要持续提供价值
按量计费按使用量付费(每次调用或 token)OpenAI API用户门槛低,可按需使用用户可能担心成本
免费+增值基础功能免费,高级功能付费Notion AI容易获取用户把握好免费与付费的边界
嵌入企业产品把 AI 能力卖给企业客户客服机器人、文档助手客单价高,决策周期长需要销售和客户成功团队

选择哪种模式,取决于你的产品定位和目标用户。

对普通消费者,免费+增值或订阅制比较常见。

对企业客户,按用量付费或定制化方案更合适。

但无论哪种模式,核心都是:用户要能实实在在地感受到价值。


案例分析:优秀 AI 产品拆解

让我们看看几个做得好的 AI 产品,学习它们的设计思路。

ChatGPT:对话式交互的典范

ChatGPT 的成功不仅仅是技术的成功,也是设计的成功。

它的核心设计决策:

  • 第一,用对话形式——用户不需要学习新的交互方式,就像和人聊天一样。

  • 第二,流式输出——字一个一个蹦出来,用户感觉 AI 在思考。

  • 第三,上下文记忆——你可以说"把刚才那段改得更短一点",它记得"刚才那段"是什么。

  • 第四,简单的重试——不满意?点"重新生成"就好。

  • 第五,对话历史管理——你可以回去看之前的对话,继续之前的话题。

这些设计看起来简单,但组合起来创造了流畅的体验。

GitHub Copilot:把 AI 嵌入工作流

Copilot 没有试图"替代程序员",而是"增强程序员"。

它的设计智慧:

  • 第一,不打断——AI 在后台工作,你写代码时它主动提供建议,不干扰你的思路。

  • 第二,低承诺——你可以看 AI 的建议,觉得好就按 Tab 接受,不好就继续打字。

  • 第三,上下文感知——它看你写的代码、注释、文件名,理解你想做什么。

  • 第四,多选项——它会给几个建议,你可以挑一个最符合你意图的。

Copilot 的成功说明:最好的 AI 产品是让用户感觉不到 AI 的存在,只感觉自己变厉害了。

Notion AI:AI 作为写作副驾

Notion AI 没有做一个独立产品,而是把 AI 能力嵌入到已有的笔记工具里。

它的设计亮点:

  • 第一,上下文就是你的文档——你不需要复制粘贴,AI 就在你写的地方工作。

  • 第二,预设模板——"继续写"、"总结"、"改得更正式",常用操作一键触发。

  • 第三,可以混合编辑——AI 生成的内容,你可以随时修改,AI 也能接着你的修改继续写。

这种设计让 AI 成为创作过程的一部分,而不是一个独立的工具。

从这三个案例可以看出:好的 AI 产品不是炫技,而是真正解决问题,让用户的工作更容易。

需要专业的网站建设服务?

联系我们获取免费的网站建设咨询和方案报价,让我们帮助您实现业务目标

立即咨询