小公司做AI产品，有个尴尬的现实：你没有自己的模型，也不太可能训一个。你面对的是一个局部市场，付费能力有限，没法在模型调用上敞开花钱。但你又得做出让用户觉得"这东西有用"的产品体验。
这三件事凑在一起，就是小公司AI产品经理要解决的核心矛盾：用有限的模型预算，做出足够好的体验。
大厂AI产品经理思考问题的方式是"什么模型最强"。这个思路对大厂没问题，因为他们有规模效应摊薄成本。但小公司如果也这么想，很容易掉进两个坑：要么全线用贵模型，预算撑不住；要么全线用便宜模型，体验一塌糊涂。
我觉得小公司AI产品经理应该换一个问题：哪里的体验最值得花预算？
听起来很简单，但想清楚这件事，需要一层一层往下拆。
不是所有环节都需要好模型
任何一个AI产品，拆开来看都有多个环节。比如一个AI备课工具，从用户输入"帮我生成一节二次函数的课"到最终输出教案，中间至少经历：理解意图、检索相关知识、生成教案、格式化输出。
这四个环节对模型能力的要求完全不一样。"理解用户意图"这件事，判断用户是要生成教案还是要生成课件，一个轻量模型就能做到。"格式化输出"也类似，把生成的内容塞进标准模板里，不需要模型有多聪明。
真正需要强模型的是"生成教案"这个核心环节——它需要理解教学逻辑、编排教学活动、设计层次递进的问题。但如果你在前面几个环节也用了强模型，那些钱就白花了。
所以小公司AI产品经理的第一课，是建立分层意识：对每个环节做成本-收益判断，把预算集中花在用户最能感知到质量差异的那个环节上。便宜模型负责搭台，贵模型负责唱戏。
这个判断没有公式可套，它取决于你对具体场景的理解深度。在AI备课的场景里，"生成教案"是核心环节，所以值得用强模型。但如果是AI客服，可能"理解用户意图"才是核心——理解错了，后面的生成再好也没用。场景不同，分层策略就不同。
用产品设计弥补模型能力
好模型能一步到位给出好结果。便宜模型可能给出七十分的结果，有时六十分，偶尔不及格。
但如果在产品流程上做文章——加一个中间确认步骤、提供模板让用户微调、设计一个质检环节过滤掉明显差的结果——七十分也能变成可接受的用户体验。
这不是偷懒，这是工程思维。我最近研究了一个开源项目叫 Claw-ED，一个美国教师做的 AI 备课工具。它有一个设计特别值得借鉴：生成教案之后，不直接展示给用户，而是先过一道质量门控——12 条基于教育学原理的规则检查，比如"教学目标是否可衡量""课堂导入是不是又在让学生回忆上节课""分层教学方案是不是只写了'给更多时间'这种废话"。
检查不通过，自动重新生成一次。用户无感，但系统在内部帮他把住了质量底线。
这套质量检查全是规则引擎，不调模型，成本几乎为零。但它让便宜模型的输出稳定性大幅提升。
这就是"用产品设计弥补模型能力"的典型做法。你承认模型不完美，然后在流程上加保险，让最终的交付物达到及格线以上。小公司没有大模型的预算，但有的是打磨产品流程的耐心。
小市场窄场景，反而是护城河
很多人觉得小市场是劣势，但做 AI 产品，小市场可能是优势。
原因是：场景越窄，你越不需要强模型。
一个面向全国所有学科所有年级的 AI 备课产品，它的 prompt 和 RAG 必须覆盖极宽的范围，任何一个环节薄了都会在某个学科上暴露问题。这种产品的模型成本天然就高——因为窄场景下好用的 prompt 技巧，一旦扩展到全学科就失效了。
但如果你只做初中数学的备课，甚至只做人教版的初中数学备课，情况就完全不同了。你的 RAG 知识库可以做得非常深：每一节的知识点、课标要求、教材编排、典型例题、常见学生错误、优质教案范例——这些内容极其结构化，量也不算太大，完全可以用便宜模型配合精心设计的 prompt 做到很好的效果。
大公司做不到这么窄。他们要规模化，要覆盖全学科全学段，必须用强模型来弥补 prompt 无法兼顾所有场景的问题。这恰恰是小公司的错位竞争优势——我比你更懂这个具体场景，所以我不需要那么强的模型。
深耕一个局部市场，把那个场景里的知识库和 prompt 打磨到极致，然后用便宜的模型稳定产出。这个路径走得通。
Prompt Engineering 和 RAG，具体怎么搭
讲了这么多思路，落到执行层面，核心就是两件事：让模型在调用之前就知道足够多的上下文，让模型在生成的时候被约束在足够窄的范围内。
前者靠 RAG，后者靠 Prompt Engineering。
RAG：四类数据源
在 AI 备课这个场景里，模型生成之前，你应该帮它准备好四类东西。
课标和考纲。 模型不知道"二次函数的图像"这一节在新课标里的具体要求是什么，也不知道本地区考试对这节考到什么深度。你把这些信息存进知识库，生成之前检索出来直接塞进 prompt。这样哪怕是最便宜的模型，也知道这节课该讲到什么程度。
教材原文。 人教版八年级上册的数学，二次函数是怎么编排的——先讲什么后讲什么，例题选了哪道，习题是什么难度。大模型可能记不住这些细节，便宜模型更记不住。但你存进 RAG 里，检索出来喂给它，它就能生成和教材逻辑一致的教案。
优质教案范例。 这个最容易被忽略，但效果最好。如果知识库里有一批同课题、同年级、被教研组打磨过的真实教案，生成时先检索出来作为范例喂给模型——便宜模型在有范例的时候，表现会接近贵模型。这不是猜测，这是被反复验证过的事实。
学情数据。 如果你有班级学生的做题数据——哪些知识点错误率高、哪些题做对了但用时过长——这些数据注入到生成流程里，模型就能自动在教学重难点上做针对性调整。这不是模型自己能推断出来的，是你通过 RAG 喂给它的。
Prompt Engineering：三个窄场景技巧
强约束输出结构。 不要让模型"自由发挥写一份教案"，而是给它一个严格定义的输出模板——教学目标、教学重难点、教学过程（导入/新授/巩固/练习/拓展）、板书设计、作业布置——每个字段都有明确的填写要求和示例。这看起来限制了创造力，但对便宜模型是救命的：它减少了模型的搜索空间，降低了出错概率。
精选 Few-shot 范例。 一份好的范例比十行指令有用。但范例不能随便塞——必须和当前生成的课题、年级、教材版本匹配。而且最好有标注，说明"这个范例好在哪里"，让模型不光看到内容，还理解设计意图。
分步生成。 不要让模型一步到位生成教案+课件+练习题的完整包。便宜模型在长上下文里很容易"前半部分很好，后半部分开始糊弄"。更聪明的做法是拆成多步：先生成教案大纲，用户确认后再生成课件，课件确认后再生成练习题。每一步 prompt 更短更聚焦，模型出错的空间更小。虽然多几次 API 调用，但每次用更便宜的模型，总成本可能反而更低。
这四个 RAG 数据源加上三个 PE 技巧叠加在一起，就能用中等甚至偏弱的模型，在一个足够窄的场景里，稳定输出还不错的结果。
怎么知道自己的 Prompt 和 RAG 有没有搭好？
这里有个实际问题：你改了一版 prompt，感觉应该更好了，但真的更好了吗？人肉对比几十份生成结果很痛苦，而且判断标准会漂移——上午觉得好的案例下午看又觉得一般。
我的建议是：用强模型当质检员，但只在两个固定时间窗口用。
第一个窗口是开发调优阶段。 你在调 prompt、换 RAG 策略、改检索逻辑的时候，在标准评估集上批量跑，用强模型打分。比如准备 50 个典型课题的测试集，每个课题有一个教研组认可的"标准教案"。每次改动后在这 50 个课题上跑一遍，让强模型按统一的评分维度（课标对齐度、环节完整性、语言自然度等）打分。改一版 prompt 平均分从 3.2 升到 3.8，这就是客观的改进信号。
这个阶段你一天可能跑几百次强模型调用，但都是你主动触发的，本质上就是测试费用。就像软件开发的 QA 成本，不省这一块，后面上线出问题亏更大。
第二个窗口是上线后的定期抽检。 每天随机抽 10-20 条生产环境的真实输出，跑一遍强模型打分，看质量有没有漂移。这个量很小，一天可能就几毛钱。但它能给你一个持续的质量信号——prompt 没改，RAG 没动，但模型提供方悄悄升级了底座，输出质量可能就掉了。没有这个抽样你根本不知道。
关键区别：强模型的调用是固定成本，不是可变成本。它不随用户请求量增长，可以在预算里算死。它只在开发和质检环节出现，生产环境里每一条用户请求都只走便宜模型。
还有一个注意事项：生成和评判不要用同一个模型。如果 A 模型既负责生成又负责评分，评分会有偏差——它倾向于给自己风格的输出打高分。A 模型生产，B 模型质检，这样评分才有参考价值。
写在最后
回到开头那个矛盾：小公司没有本地模型，面对的是付费能力有限的局部市场，模型预算很紧。
但换个角度看，这些约束反而逼着你走上了一条更务实的路。你不需要追求"最强的模型"，你只需要追求"在特定场景下足够好的体验"。RAG 知识库的一次性建设成本，prompt 设计的打磨时间，质量门控的工程投入——这些是小公司最不缺的东西。把它们做好，便宜模型也能发挥出远超其价格的表现。
大公司的优势是算力和模型能力。小公司的优势是对具体场景的理解深度，以及在约束条件下做工程优化的耐心。
把这个想透了，小公司做 AI 产品，不丢人。