如果你把 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 dataclassfrom typing import List, Dict, Optionalimport statisticsdataclassclass TestResult:单个测试结果的数据结构prompt_version: str # A 或 Buser_satisfaction: int # 用户满意度 1-5retry_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 Bdef print_report(analysis: Dict) - None:打印可读的 A/B 测试报告print( * 60)print(RUNOOB Prompt A/B 测试报告)print( * 60)if error in analysis:print(f错误: {analysis[error]})returnprint(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 Bprint(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 表现更好 按测试用例细分: 邮件写作: A3.50, B4.50 (B更好) 摘要生成: A3.50, B3.50 (A更好) 代码解释: A3.50, B4.50 (B更好)AI 功能原型设计在投入大量开发资源前先用低成本方式验证 AI 功能是否真的有用。用 Claude/ChatGPT 快速原型最简单的原型直接用大模型聊天界面模拟产品功能。比如你想做一个面试问题生成器写一个提示词描述你想要的功能然后输入一些测试用例看看输出质量。这个阶段的目标是验证第一AI 能不能做这件事第二输出质量够不够好第三用户会觉得这个功能有用吗不需要写代码不需要设计界面就用纯文本对话测试核心价值。如果这个阶段效果不好要么改进提示词要么重新考虑这个功能是否值得做。Figma 中的 AI 原型组件确定核心功能有价值后下一步可以做高保真原型。Figma 是做这个的好工具。你可以设计用户如何输入AI 输出如何展示用户如何调整和编辑关键是模拟真实的交互流程而不只是画静态界面。可以用 Figma 的交互功能让用户点击按钮时生成不同的内容你提前准备几个示例结果。这样用户可以感受到哦原来这个产品是这样用的。低代码 AI 应用工具如果需要更真实的体验可以用低代码工具快速搭建可工作的原型。这类工具可以让你不用写后端代码就能把大模型接入到一个真正的网页应用里。好处是用户可以真实操作而不只是看演示。你可以收集真实的使用数据和反馈。验证成功后可以把这个原型作为开发的参考。原型的目标是学习不是完美。用最快的速度验证想法发现问题然后迭代。评估 AI 输出质量如何判断 AI 输出好不好需要定性和定量结合的评估体系。定性评估人工 Review有些东西只能靠人来判断。比如回答有没有帮助语气是否合适逻辑是否通顺人工 Review 的做法第一设计一个评分维度表——比如相关性、准确性、有用性、安全性。第二让多个评审者独立打分减少个人偏见。第三把评分和评语整理成可操作的改进建议。人工 Review 很重要但它慢、贵、难以规模化。所以需要结合自动化评估。定量评估自动化评测用程序来评估 AI 的输出。常见的自动化评估方法方法做法适用场景基于规则的检查检查关键词、格式、长度、是否包含敏感内容基础质量控制LLM 自评用另一个大模型来评估输出质量开放式任务语义相似度比较输出和参考答案的语义接近程度有标准答案的任务用户行为指标统计重试率、完成率、满意度评分上线后的持续监控自动化评估不能完全替代人但它可以第一快速过滤明显有问题的输出。第二在版本迭代时做回归测试——这次修改有没有让某些场景变差。第三监控线上服务质量及时发现问题。黄金测试集构建收集一组高质量的测试用例每次修改提示词或模型时都在这个集合上跑一遍。这就是黄金测试集。好的测试集应该第一覆盖典型使用场景——常见的用户请求类型。第二包含边界情况——极端的、容易出错的输入。第三有标准答案或评分标准——知道什么是好的输出。第四规模适中——几十到几百个足够有代表性但又不会跑得太慢。黄金测试集就像一张安全网你可以放心地迭代不用担心意外破坏了重要场景的效果。AI 产品的商业化路径有了好产品如何让它产生收入AI 产品有几种常见的商业化模式。模式做法典型例子优势挑战订阅制按月/按年付费使用ChatGPT Plus收入稳定可预测需要持续提供价值按量计费按使用量付费每次调用或 tokenOpenAI API用户门槛低可按需使用用户可能担心成本免费增值基础功能免费高级功能付费Notion AI容易获取用户把握好免费与付费的边界嵌入企业产品把 AI 能力卖给企业客户客服机器人、文档助手客单价高决策周期长需要销售和客户成功团队选择哪种模式取决于你的产品定位和目标用户。对普通消费者免费增值或订阅制比较常见。对企业客户按用量付费或定制化方案更合适。但无论哪种模式核心都是用户要能实实在在地感受到价值。案例分析优秀 AI 产品拆解让我们看看几个做得好的 AI 产品学习它们的设计思路。ChatGPT对话式交互的典范ChatGPT 的成功不仅仅是技术的成功也是设计的成功。它的核心设计决策第一用对话形式——用户不需要学习新的交互方式就像和人聊天一样。第二流式输出——字一个一个蹦出来用户感觉 AI 在思考。第三上下文记忆——你可以说把刚才那段改得更短一点它记得刚才那段是什么。第四简单的重试——不满意点重新生成就好。第五对话历史管理——你可以回去看之前的对话继续之前的话题。这些设计看起来简单但组合起来创造了流畅的体验。GitHub Copilot把 AI 嵌入工作流Copilot 没有试图替代程序员而是增强程序员。它的设计智慧第一不打断——AI 在后台工作你写代码时它主动提供建议不干扰你的思路。第二低承诺——你可以看 AI 的建议觉得好就按 Tab 接受不好就继续打字。第三上下文感知——它看你写的代码、注释、文件名理解你想做什么。第四多选项——它会给几个建议你可以挑一个最符合你意图的。Copilot 的成功说明最好的 AI 产品是让用户感觉不到 AI 的存在只感觉自己变厉害了。Notion AIAI 作为写作副驾Notion AI 没有做一个独立产品而是把 AI 能力嵌入到已有的笔记工具里。它的设计亮点第一上下文就是你的文档——你不需要复制粘贴AI 就在你写的地方工作。第二预设模板——继续写、总结、改得更正式常用操作一键触发。第三可以混合编辑——AI 生成的内容你可以随时修改AI 也能接着你的修改继续写。这种设计让 AI 成为创作过程的一部分而不是一个独立的工具。从这三个案例可以看出好的 AI 产品不是炫技而是真正解决问题让用户的工作更容易。
如果你把 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 dataclassfrom typing import List, Dict, Optionalimport statisticsdataclassclass TestResult:单个测试结果的数据结构prompt_version: str # A 或 Buser_satisfaction: int # 用户满意度 1-5retry_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 Bdef print_report(analysis: Dict) - None:打印可读的 A/B 测试报告print( * 60)print(RUNOOB Prompt A/B 测试报告)print( * 60)if error in analysis:print(f错误: {analysis[error]})returnprint(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 Bprint(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 表现更好 按测试用例细分: 邮件写作: A3.50, B4.50 (B更好) 摘要生成: A3.50, B3.50 (A更好) 代码解释: A3.50, B4.50 (B更好)AI 功能原型设计在投入大量开发资源前先用低成本方式验证 AI 功能是否真的有用。用 Claude/ChatGPT 快速原型最简单的原型直接用大模型聊天界面模拟产品功能。比如你想做一个面试问题生成器写一个提示词描述你想要的功能然后输入一些测试用例看看输出质量。这个阶段的目标是验证第一AI 能不能做这件事第二输出质量够不够好第三用户会觉得这个功能有用吗不需要写代码不需要设计界面就用纯文本对话测试核心价值。如果这个阶段效果不好要么改进提示词要么重新考虑这个功能是否值得做。Figma 中的 AI 原型组件确定核心功能有价值后下一步可以做高保真原型。Figma 是做这个的好工具。你可以设计用户如何输入AI 输出如何展示用户如何调整和编辑关键是模拟真实的交互流程而不只是画静态界面。可以用 Figma 的交互功能让用户点击按钮时生成不同的内容你提前准备几个示例结果。这样用户可以感受到哦原来这个产品是这样用的。低代码 AI 应用工具如果需要更真实的体验可以用低代码工具快速搭建可工作的原型。这类工具可以让你不用写后端代码就能把大模型接入到一个真正的网页应用里。好处是用户可以真实操作而不只是看演示。你可以收集真实的使用数据和反馈。验证成功后可以把这个原型作为开发的参考。原型的目标是学习不是完美。用最快的速度验证想法发现问题然后迭代。评估 AI 输出质量如何判断 AI 输出好不好需要定性和定量结合的评估体系。定性评估人工 Review有些东西只能靠人来判断。比如回答有没有帮助语气是否合适逻辑是否通顺人工 Review 的做法第一设计一个评分维度表——比如相关性、准确性、有用性、安全性。第二让多个评审者独立打分减少个人偏见。第三把评分和评语整理成可操作的改进建议。人工 Review 很重要但它慢、贵、难以规模化。所以需要结合自动化评估。定量评估自动化评测用程序来评估 AI 的输出。常见的自动化评估方法方法做法适用场景基于规则的检查检查关键词、格式、长度、是否包含敏感内容基础质量控制LLM 自评用另一个大模型来评估输出质量开放式任务语义相似度比较输出和参考答案的语义接近程度有标准答案的任务用户行为指标统计重试率、完成率、满意度评分上线后的持续监控自动化评估不能完全替代人但它可以第一快速过滤明显有问题的输出。第二在版本迭代时做回归测试——这次修改有没有让某些场景变差。第三监控线上服务质量及时发现问题。黄金测试集构建收集一组高质量的测试用例每次修改提示词或模型时都在这个集合上跑一遍。这就是黄金测试集。好的测试集应该第一覆盖典型使用场景——常见的用户请求类型。第二包含边界情况——极端的、容易出错的输入。第三有标准答案或评分标准——知道什么是好的输出。第四规模适中——几十到几百个足够有代表性但又不会跑得太慢。黄金测试集就像一张安全网你可以放心地迭代不用担心意外破坏了重要场景的效果。AI 产品的商业化路径有了好产品如何让它产生收入AI 产品有几种常见的商业化模式。模式做法典型例子优势挑战订阅制按月/按年付费使用ChatGPT Plus收入稳定可预测需要持续提供价值按量计费按使用量付费每次调用或 tokenOpenAI API用户门槛低可按需使用用户可能担心成本免费增值基础功能免费高级功能付费Notion AI容易获取用户把握好免费与付费的边界嵌入企业产品把 AI 能力卖给企业客户客服机器人、文档助手客单价高决策周期长需要销售和客户成功团队选择哪种模式取决于你的产品定位和目标用户。对普通消费者免费增值或订阅制比较常见。对企业客户按用量付费或定制化方案更合适。但无论哪种模式核心都是用户要能实实在在地感受到价值。案例分析优秀 AI 产品拆解让我们看看几个做得好的 AI 产品学习它们的设计思路。ChatGPT对话式交互的典范ChatGPT 的成功不仅仅是技术的成功也是设计的成功。它的核心设计决策第一用对话形式——用户不需要学习新的交互方式就像和人聊天一样。第二流式输出——字一个一个蹦出来用户感觉 AI 在思考。第三上下文记忆——你可以说把刚才那段改得更短一点它记得刚才那段是什么。第四简单的重试——不满意点重新生成就好。第五对话历史管理——你可以回去看之前的对话继续之前的话题。这些设计看起来简单但组合起来创造了流畅的体验。GitHub Copilot把 AI 嵌入工作流Copilot 没有试图替代程序员而是增强程序员。它的设计智慧第一不打断——AI 在后台工作你写代码时它主动提供建议不干扰你的思路。第二低承诺——你可以看 AI 的建议觉得好就按 Tab 接受不好就继续打字。第三上下文感知——它看你写的代码、注释、文件名理解你想做什么。第四多选项——它会给几个建议你可以挑一个最符合你意图的。Copilot 的成功说明最好的 AI 产品是让用户感觉不到 AI 的存在只感觉自己变厉害了。Notion AIAI 作为写作副驾Notion AI 没有做一个独立产品而是把 AI 能力嵌入到已有的笔记工具里。它的设计亮点第一上下文就是你的文档——你不需要复制粘贴AI 就在你写的地方工作。第二预设模板——继续写、总结、改得更正式常用操作一键触发。第三可以混合编辑——AI 生成的内容你可以随时修改AI 也能接着你的修改继续写。这种设计让 AI 成为创作过程的一部分而不是一个独立的工具。从这三个案例可以看出好的 AI 产品不是炫技而是真正解决问题让用户的工作更容易。
![[C++]内存管理：串顺序存储的内存回收](http://pic.xiahunao.cn/yaotu/[C++]内存管理：串顺序存储的内存回收)
