六种 AI 产品思维：别只把模型包成一个功能

1. 分层思维：先找到是哪一层出了问题

一个生成式 AI 产品不是单点能力，而是一套栈：底层是模型，上面是 prompt，再往上是工具，旁边是检索，外面有 agent loop，最上层才是 UI。用户看到的每个问题，比如答错、太慢、编数字、不该拒绝时拒绝，都有自己的起源层。

站会上只问“是不是 AI 坏了”的团队，还没有真正拥有这个产品。更好的问题是：“这次输出是在哪一层偏掉的？” 能力不在于立刻给答案，而在于知道这些层是分开的，并且愿意在发版前把失败的层说清楚。

如果你指不出问题在哪一层，你只是在描述产品，还没有掌控它。Design Patterns 讲的就是怎样让这套栈变得可读、可调、可负责。

2. 飞轮思维：没有闭环，就不是 AI 产品

确定性软件在第 1 天和第 1000 天应该表现一致。AI 软件则应该在第 1000 天比第 1 天更好，否则它更高的运行成本就很难成立。一个真正的 AI 产品要有闭环：用户使用产品，产生信号；信号更新 eval、模型或检索索引；下一位用户获得更好的体验。

如果路线图里没有这条回路，你做的只是一个上线当天质量已经定型、之后还会随模型漂移而衰减的功能。更麻烦的是，你也放弃了最能抵消推理成本的战略资产：数据飞轮。

设计飞轮是产品工作，不只是工程实现。你要先回答三个问题：哪些用户行为算有效信号？采集这些信号的成本是什么？信号回来以后更新哪里？这些想清楚了，工程才是在铺管道。

3. 数据也是产品界面

过去几年里，很多大型 AI 事故看起来像工程 bug，本质上都是数据问题。RAG 答错，可能是分块不对；输出有偏，可能是训练集有偏；模型“忘了”，可能是内容从来没进索引。用户看到的幻觉，往往是数据缺口逃过了产品审查。

所以，数据不是上游工程的杂务，而是产品界面的一部分。索引里放什么、怎么分块、多久刷新、如何标注、freshness SLA 是多少，都是发布决策。用户不会看到你的数据管线，但会直接感受到它的质量。

能在设计阶段发现数据问题的团队，事后复盘会少很多。等到生产环境里才发现，复盘就会变成主要产出。Agentic RAG 把这个问题当成一等公民来处理。

4. 可靠性本身就是产品定义

70% 可靠是 demo，95% 可靠才开始像产品。中间这 25% 的差距，靠的是一组看起来偏工程、实际上会定义产品体验的决策：

• 这一步用哪一档模型？
• 模型返回非法 JSON 时如何重试？
• 什么时候值得切到更强的模型，换取更高延迟？
• 这个场景应该用什么 temperature？
• 模型应该拒绝时，“我不知道”要怎么呈现？

这些决策共同塑造了用户愿意把什么交给产品。如果 builder 不主动拥有它们，最终拍板的人就会顺手定义你的产品。能上线的 AI 团队，会把可靠性当成可以设计的产品质量，而不是代码写完之后剩下的运气。Production 会把这件事落到具体做法上。

5. 成本也是 UX 的一部分

单次查询成本会在两个地方显形：对用户，它变成延迟和功能上限；对公司，它变成现金消耗和定价压力。两边都重要，也都不是“工程自己处理就好”的问题。

每个 AI 产品都有一条隐藏轴：便宜但快，还是慢但强。永远选“慢但强”，产品很容易贵到无法规模化；永远选“便宜但快”，用户又会觉得它不聪明。做得好的产品会按步骤路由：难的步骤用强模型，简单步骤用便宜模型，重复步骤用缓存。这个路由方案，本质上就是一项产品设计。

能说清“这个功能每月每活跃用户花多少钱，以及为什么值得”的人，才真正拥有功能的经济模型。说不清的人，最后往往会让财务在意想不到的时候替他改路线图。

6. Evals 是发版方式，不只是质量保险

当输出是一段文字时，传统 pass/fail 测试会不够用。这也是 AI 功能常见的两种失败来源：要么没有质量门槛就上线，然后在生产里炸；要么迟迟不上线，因为没人能证明它足够好。

Eval-driven development 的答案分两半：

• 确定性检查：凡是能用 regex 或 schema 描述的，都应该自动检查，比如 JSON 合法性、必填字段、禁词、格式约束和延迟预算。这些检查便宜、稳定、适合每次提交都跑。
• 概率性检查：凡是很难写死规则的，比如是否 helpful、是否 faithful、语气是否合适，通常需要 LLM-as-judge。配合清楚的 rubric 和 ground-truth 样本，它能在规模上测量体验质量。

没有 eval，每次发版都是猜，每次回归都是意外。有了 eval，“能不能发”就能变成一个可以讨论的数字，质量线也能随时间抬高。第 2 条里的飞轮，最终也需要写回这里。Evaluation 是让前面几条真正产生复利的那一课。

加一个：先做出来，再写出来

上面六种思维可以互相加强，但还有一条更底层的习惯：开会时带着能跑的原型进去，而不是只带 spec。

Spec 描述的是未来的系统。Prototype 哪怕只跑通一条 happy path，也是当下真实存在的系统。有了 LLM、Cursor、Replit 和 Claude Agent SDK，从“我有个想法”到“我有个能跑的东西”的成本已经大幅下降。一个团队里如果一个人在做，四个人在写 spec，这个团队很快就会被重新组织。

Spec 让团队争论“应该存在什么”。Prototype 让团队面对“已经存在什么”。后一种讨论更短、更诚实，也更容易做出好产品。手里有一个能跑的东西，上面六种思维都会更容易落地。

合起来

这六种不是 checklist，而是能持续发 AI 产品的团队已经在用的思考方式：

1. 分层思维：每个输出都有起源层，先定位再调试。
2. 飞轮设计：没有闭环，就不是会变好的 AI 产品。
3. 数据也是产品界面：索引、分块、刷新、标注，用户都会感受到。
4. 可靠性定义产品：temperature、模型档位、重试、fallback，都会改变信任边界。
5. 成本也是 UX：按步骤路由，按用户度量，自己掌握经济模型。
6. Evals 是发版方式：能确定的自动检查，不能确定的用 LLM-as-judge，始终可度量。

把这些内化以后，团队就不会只争论“模型够不够好”，而会开始问“模型外面的产品系统够不够好”。多数时候，真正卡住发版的就是后一个问题。