AI产品开发：技术只是起点，用户才是终点

你所在的团队刚刚被要求”加AI”。领导说这是未来，投资人也在盯着。你投入几个月做了一个AI功能，上线后数据却惨不忍睹——用户不买账，成本控不住，合规问题接踵而来。为什么那么多AI产品倒在最后一公里？

答案很残酷：不是技术不行，而是你从来没学会”像产品经理一样思考AI”。Janna Lipenkova 的《The Art of AI Product Development》用12章的篇幅回答了一个核心问题——如何把AI从一个炫酷的技术概念，变成用户明天就离不开的产品。本文提取其中7条能立刻上手的认知和动作。

—

观点一 · AI产品失败的头号原因：技术选对了，问题选错了

AI产品失败很少是因为“模型不够好”，绝大多数是因为团队在错误的问题上浪费了最先进的技术。

书中开篇就讲了一个场景：一个金融数据分析平台，用户抱怨界面太拥挤。团队在压力下加了一个聊天机器人，让用户用自然语言查询数据。上线就翻车——训练数据由一位从未接触过用户的工程师随手拼凑，模型在真实查询下表现一塌糊涂。团队后来才意识到，他们最初的野心远超AI的真实能力，用户其实只需要几个针对性的快捷查询模板。

**【证据】**

>Many initiatives fail—not for lack of potential but because teams lack the expertise and frameworks to create these products effectively. Common pitfalls include unclear value propositions, poor data quality, unrealistic expectations, and underestimating the effort required for customization.

>

>——[Janna Lipenkova《The Art of AI Product Development》，Manning Publications，2025]

这不是孤例。根据 RAND Corporation 2024年的一项研究，超过80%的AI试点项目未能进入生产阶段，其中“与业务需求不匹配”是首要原因。技术从来不是瓶颈，定义问题的能力才是。

**【类比】**

就像你有一把瑞士军刀，但你需要的是开一瓶红酒。你当然可以用锯子锯开瓶塞——技术上“可行”，但聪明人会先去厨房找开瓶器。AI产品开发也是同样的道理：先确认你面对的是“红酒瓶”，再选工具。

**【行动】**

在写一行代码之前，先写清楚：这个AI功能解决了谁的什么具体问题？用户现在是怎么解决的（替代方案是什么）？

用“如果不用AI，这个问题还有别的解法吗？”反问自己一次——答案应该是“有，但AI更好/更快/更便宜”。

做一个“问题-方案匹配表”：左栏列用户痛点，右栏列可能的AI能力，只选匹配度最高的前三项进入下一步。

—

观点二 · 从最简单的AI方案开始，用迭代证明价值

解决同一个问题，最便宜的方案往往不是最差的。

书中有个让产品经理警醒的故事：一家电影平台用GPT-4o做评论情感分析，功能受欢迎但成本高、隐私有隐忧。几个月后，一位实习生用传统逻辑回归重写——花了一周，模型小、快、准、能私有部署。

作者由此提出了一张”AI方案空间地图”，将AI分为三大类：预测型（从数据中找规律）、生成型（创造新内容）、智能体型（自动执行任务和决策）。很多人一头扎进生成式AI，却忘了那些成熟、便宜、可靠的预测型算法已经默默支撑了Google搜索、Netflix推荐和垃圾邮件过滤几十年。

**【证据】**

书中反复强调一个原则：用最简单的方法验证假设，而不是用最强的方法证明能力。在RAG和微调之间，先用提示工程试；在提示工程和智能体之间，先用基础提示模板试。每升一级复杂度，都需要对应级别的数据、工程资源和风险承受能力来支撑。

**【类比】**

这就像出行选交通工具：去楼下便利店走路就行，去五公里外的商场打车，跨省出差才坐飞机。你不会因为飞机最快就去楼下坐飞机。但很多AI团队恰恰在这个基本判断上犯了错——一上来就调用最贵、最大的模型解决一个简单到可以用规则引擎处理的问题。

**【行动】**

做一个“方案复杂度阶梯”：任务需要分析数据→先用预测AI；需要生成文本→先用零样本提示；需要专业领域知识→再考虑RAG或微调。

每次做技术决策时，问自己：“有没有更简单的方案能达到80%的效果？”如果能，先实现那80%。

为每次AI实验设定一个明确的“毕业标准”和“回退标准”——达不到就降级方案或放弃，不被沉没成本绑架。

—

观点三 · 选语言模型，先搞清楚它“读过什么书”

很多人选模型只看榜单排名——MMLU多少分、HumanEval排第几。但书中提醒我们，对产品经理来说，一个更关键的问题是：这个模型的训练数据里有没有你的领域？

作者用了一个精准的比喻：通用大语言模型就像一个博览群书但毫无专业深度的高中生，你跟它聊什么它都能接上话，但你让它写一份符合你行业规范的合规报告，它可能写得文采飞扬但关键条款全错。如果你需要模型在你的专业领域深度输出，默认的GPT-4或Claude是不够的——你得先查它的“阅读清单”。

作者通过角色Alex——一位内容生成工具创始人——带我们走了一遍选型流程：定义目标（生成还是分析？实时还是离线？）、评估团队能力、权衡成本与精度、检查隐私约束。

**【证据】**

书中拆解了训练数据如何影响产品表现：规模和多样性决定广度但专业领域可能”广而不深”；训练数据偏见会直接复刻到模型输出；数据质量（是否包含大量未验证的网络内容）决定幻觉概率。这些榜单分数都不告诉你。

**【类比】**

就像招人一样。你不会因为一个候选人的高考总分高就招他来做心脏手术——你需要知道他有没有读过医科。选AI模型也一样：榜单排名是“高考总分”，训练数据覆盖度才是“专业背景”。

**【行动】**

选模型之前，写出你期望模型做到的三个最具行业代表性的任务，然后逐个测试候选模型的输出质量。不看通用基准，看你自己的场景。

向模型提供商或开源社区查明：训练数据是否包含你行业的专业语料？如果不包含，评估微调或RAG的必要性。

建立一个小型内部评估集（50-100条真实场景问答），用它而不是通用榜单来衡量模型是否符合你的需求。

—

观点四 · 提示工程不是“魔法咒语”，是系统工程

提示工程靠系统，不靠灵感。

很多人对提示工程的印象还停留在网上流传的”37条神级提示词”之类的清单。但书中给出了一个更务实的视角：提示工程本质上是对语言模型行为的精确描述和控制，它需要的不是灵感，而是系统化管理。

作者展示了提示工程的进化：零样本→少样本→思维链→自我一致性→反思提示。每往上一层控制力更强但更复杂。但真正升级的是系统化管理——把提示拆成组件，版本化、A/B测试，像管理代码一样管理。

**【证据】**

>As Alex starts with prompting, he makes quick progress. He sifts through many prompting guides and forum discussions to pick up the latest prompting hacks… However, it doesn’t take long for the learning curve to flatten out, and he gets bogged down in the details.

>

>——[Janna Lipenkova《The Art of AI Product Development》，Manning Publications，2025]

书中随后给出了解决方案：建立提示实验日志模板（包含实验ID、日期、任务描述、提示内容、评估结果），实行版本控制和自动评估，将有效的提示模板存入可搜索的数据库供团队复用。

**【类比】**

就像给新同事布置任务。“把这个做了”——他可能做对也可能完全跑偏。“请把这份报告整理一下，重点是第三页的数据对比，用表格呈现，周五下午5点前发我邮件，抄送王总”——结果大概率符合预期。提示工程的精进就是不断把第一种模糊指令变成第二种精确指令的过程。

**【行动】**

今天就建一个简单的提示日志：用表格记录每次提示实验的目的、完整prompt、输出结果和评分。

把你最常用的3个提示拆成组件（上下文/指令/示例/输出格式），找出哪些组件每次都必须有，哪些是可选的。

对同一个任务写两个版本的提示做A/B对比，选效果更好的作为基准版本。

—

观点五 · 让AI“翻书回答”比让它“死记硬背”更靠谱

让AI翻书回答比让它死记硬背更靠谱。

通用语言模型的知识是”冻结”在训练时刻的，而用户需要的是与当下业务紧密相关的内容。两个技术可以解决——检索增强生成（RAG）和微调（Fine-tuning），但适用场景完全不同。

RAG是在模型”作答”时动态检索外部知识库，把相关资料和问题一起塞进提示里，相当于给模型一本参考书让它翻着答。微调则是把专业知识直接“写进”模型参数里，相当于让模型去读了一个专业学位。RAG简单、灵活、可解释性好（能溯源到具体文档）；微调深度更高，但成本大、周期长、需要维护训练数据。

书中Alex的经历很说明问题：他先用RAG让客户的内部案例和行业知识融入生成内容，效果立竿见影；但当用户要求更深的行业术语和推理能力时，RAG开始吃力——这时候他才转向微调。两种技术不是“二选一”的关系，而是沿着成熟度曲线先后出现。

**【证据】**

书中给出了RAG开发和优化的完整生命周期：基础设置（选嵌入模型、建向量数据库）→离线评估（检查检索的上下文相关性和答案忠实度）→生产优化（调整分块策略、加元数据过滤、重排序、查询增强）。每一阶段都有明确的“可上线”标准。

**【类比】**

RAG就像一个高中生在考试时可以翻参考书——他没背过所有答案，但会查资料就能答对大部分题。微调则像送他去读了大学——专业知识内化了，不需要翻书也能对答如流。但读大学要四年时间和巨额学费，不是每道题都值得花这个代价。

**【行动】**

如果你的AI应用需要接入公司内部知识、最新行业动态，优先从RAG开始——它部署快、成本低、可溯源。

当你的用户抱怨模型“不够专业”“术语用得不对”“逻辑推理不深入”时，开始评估微调的投入产出比。

收集用户在真实使用中觉得“不够好”的输出案例，作为微调数据集的种子——这比凭空构造训练数据高效得多。

—

观点六 · AI会犯错不可怕，可怕的是不告诉用户它可能会犯错

AI会犯错不可怕，可怕的是假装它不会。

传统软件的行为是确定的：点按钮A就跳到页面B。但AI的输出是不确定的——同样的输入可能得到不同甚至完全错误的输出。这给UX设计带来了前所未有的挑战。

书中用了一整章的篇幅回答一个问题：如何为“不确定性”设计用户体验？核心原则是——不要假装AI不会犯错，而是把犯错的可能性和应对方式设计到体验中。具体策略包括：显示AI的置信度（让用户自己判断要不要采纳）、提供多版输出让用户选择、对AI生成的每个结论给出可追溯的来源引用、设计“撤销AI操作”的机制、在用户可能过度信任AI时主动示警。

作者通过一个企业可持续发展报告工具的设计过程，展示了如何在用户旅程的五个阶段（发现→可行性→机会→解决→完成）中，把信任校准融入每一个交互细节。

**【证据】**

书中展示了一组具体的UX设计模式：内联提示（AI检测到数据缺失时给出提示）、渐进展开（“了解更多”按钮解释AI如何生成此内容）、置信度色标（绿色高置信度、黄色需人工审核、红色不可靠）、来源引用（每个AI结论附带出处链接）。这些模式的目标不是消除不确定性——那在技术上做不到——而是让用户建立“校准后的信任”：相信AI能做好某些事，同时清楚地知道哪些事需要自己判断。

**【类比】**

就像使用GPS导航。GPS也会犯错——把你导到一条封了的路上、在立交桥上分不清第几层。但你不会因此完全放弃导航，因为它在出错时会立刻重新规划路线。你对GPS的信任是“校准过的”——你知道它大概率对，但也保持警觉。好的AI产品应该让用户处于同样的心理状态。

**【行动】**

在你的AI功能中，至少实现一种“不确定性沟通”机制：置信度、来源引用、或备选方案。

设计一个“AI出错了怎么办”的用户流——用户可以一键撤销、报告错误、或切换到人工处理。

做一轮用户测试，问用户：“你觉得这个AI输出靠谱吗？为什么？”如果用户说不出判断依据，说明你的透明度设计还不够。

—

观点七 · AI治理不是官僚主义，是你的消防系统

AI治理不是官僚主义，是你的消防系统。

很多人听到”AI治理”就觉得是法务部门的事。但书中用一个叫Sam的产品经理的教训告诉我们：治理不是开发的绊脚石，而是防止产品变成定时炸弹的最后一道防线。

Sam在一个数据分析平台做AI推荐功能。上线初期表现不错，但几个月后几个大客户悄悄停了用——原因是推荐内容彻底跑偏，物流公司收到了零售趋势建议，医疗客户看到了建筑行业分析。追查发现，训练数据被污染了。紧接着审计又发现：敏感客户数据通过模型输出泄露给了未授权方。Sam从一个乐观的AI推动者，变成了成天应付合规危机的救火队长。

书中从三个层面拆解了AI安全：数据层（防投毒、防泄露、加密与访问控制）、模型层（审查第三方组件、供应商风险管理、模型知识产权保护）、使用层（防提示注入攻击、输出验证、人工审查关键输出）。另外还覆盖了隐私设计七原则和公平性与偏见检测。

**【证据】**

书中引用了一系列合规框架：欧盟AI法案对高风险AI系统要求风险评估和透明度披露；ISO 42001设定AI治理的最佳实践标准；HIPAA和PCI DSS对涉及医疗和金融数据的AI系统施加严格的安保要求。这些不是“可选项”，而是你在相应行业做AI产品的准入门槛。

**【类比】**

就像建大楼的消防系统。平时消防通道、灭火器、烟感器看起来是占地方的累赘，但着火的时候它们决定整栋楼的人是生是死。AI治理就是你的消防系统：数据安全是防火材料，隐私保护是安全通道，偏见检测是消防检查。你不会等火着了才想起来该配灭火器。

**【行动】**

在项目启动阶段就写一份“AI风险清单”：列出你的AI系统可能出错的方式（输出错误、数据泄露、偏见歧视、被攻击利用），每种风险标上严重程度和发生概率。

确保至少有一个团队成员对AI合规负责——可以是兼任，但不能是“大家都觉得别人在管”。

如果你使用第三方AI模型或API，建立定期的供应商安全审查机制：他们的数据处理方式、模型更新策略、漏洞披露流程是什么？

—

全书速览

第1章 · Ch3 Mapping AI solution space：数据模态决定AI方案，从最简单的开始迭代。

第2章 · Ch4 Predictive AI：聚类分类时间序列推荐，选算法先看数据类型。

第3章 · Ch5 Evaluating language models：选模型先查训练数据覆盖度，不看榜单排名。

第4章 · Ch6 Prompt engineering：系统化管理提示模板，建立版本控制和A/B测试。

第5章 · Ch6 Prompt engineering：示例轮换消除顺序偏差，确保模型不受末例影响。

第6章 · Ch6 Prompt engineering：记录每次实验，ID+日期+任务+评估形成知识库。

第7章 · Ch7 Search and RAG：语义检索优于关键词，分块策略决定最终精度。

第8章 · Ch8 Fine-tuning LMs：微调数据需去重清洗，确保与模型架构对齐。

第9章 · Ch9 Agentic AI：智能体三大组件——记忆存上下文，规划拆任务，工具扩边界。

第10章 · Ch10 AI UX Designing for uncertainty：优化模型精度、决策逻辑、自动化覆盖。

第11章 · Ch10 AI UX Designing for uncertainty：选解释格式看场景，内联提示或渐进展开。

第12章 · Ch11 AI governance：数据模型使用三层防线，安全从项目启动嵌入流程。

第13章 · Ch12 Working with stakeholders：HITL高风险人机回路，HOTL自动化人工巡查。

第14章 · Ch12 Working with stakeholders：小团队1-3人快速迭代，聚焦MVP验证核心假设。

第15章 · Ch4 Further reading：预测分析算法速查，聚类分类回归场景对照。

第16章 · Ch5 Further reading：语言模型评估方法全景，从静态基准到在线A/B测试。

第17章 · Ch6 Further reading：结构化提示组件清单，上下文+指令+示例+输出格式。

第18章 · Ch7 Further reading：文档检索与LLM集成组件，查询预处理到结果后处理。

第19章 · Ch8 Further reading：微调数据创建分步检查，从目标定义到数据验证。

第20章 · Ch9 Further reading：外部工具分检索类与执行类，按需扩展智能体能力。

第21章 · Ch4 References：预测AI使用案例索引，聚类分类推荐系统论文引用。

第22章 · Ch5 References：模型部署与监控策略，持续追踪漂移与性能衰减。

第23章 · Ch6 References：提示优化常见陷阱，避免过度工程与边际收益递减。

第24章 · Ch7 References：RAG离线评估与生产监控指标，相关性+忠实度+精确率。

第25章 · Ch8 References：微调场景选择与成本评估，PEFT降低百倍训练开销。

第26章 · Ch9 References：智能体局限——有限上下文、不可预测输出、任务分解难题。

—

收敛

**一句话金句**：AI产品开发说到底不是技术问题，而是翻译问题——把用户需求翻译成技术方案，再把技术的不确定性翻译成用户能理解和信任的体验。

**如果你明天就想用上**：

1. 拿出你正在做的AI功能，用“如果不用AI，这个问题还有别的解法吗？”反问一次——如果答案是“有，而且更简单”，先做那个更简单的。
2. 为你的AI输出加一个不确定性信号——哪怕只是“本回答由AI生成，建议核实关键数据”一行小字。
3. 建一个共享文档，记录每次提示实验的目的、内容和结果——三周后你会感谢自己。

—

本书信息

书名：《The Art of AI Product Development》

作者：Janna Lipenkova

出版社：Manning Publications

出版年份：2025

ISBN：9781633437050

声明

本文为个人学习分享笔记。文中对原书内容的引用依据《中华人民共和国著作权法》第24条第（二）项作介绍、评论之用，版权归原作者及出版方所有。建议读者购买正版阅读原书，以获得完整的上下文与授权支持。