这几年的AI培训市场有个很有意思的现象：理论课越来越多，但学完能真正上手做出东西的人反而越来越少。很多人掌握了模型原理、背熟了几种算法，真让他从零做一个能给别人用的AI产品，却卡在第一步。我在AI产品创造营里接触过大量这类学员，也带过不少从选题到发布的完整项目，最深的一个感受是：AI产品经理和AI应用开发者的核心能力，从来不是“懂模型”，而是“把模糊的想法变成一个真实可用的产品”。这篇内容就是基于创造营课程资料的完整拆解，讲讲我们是怎么带学员从痛点调研一路走到产品发布的，以及这条路上最容易踩的坑和最重要的判断逻辑。
如果你是产品经理、独立开发者、想往AI方向转型的职场人，或者手里有个想法但不知道怎么落地，这篇内容应该能帮你省掉大量试错时间。我不讲模型原理，只讲做产品的实战链路。
1. 这门课到底在教什么：从选题到发布的完整链路
1.1 创造营视角与传统AI课程的最大区别
传统AI课程的编排逻辑是“按技术模块组织”——先讲机器学习基础，再讲深度学习，然后讲某个模型结构，最后布置一个分类或预测作业。这种体系适合培养研究人员，但它有一个致命问题：学完之后，学员依然不知道一个AI产品是怎么从0到1长出来的。
创造营的编排逻辑恰恰反过来，一切按“产品诞生流程”组织。你不是先学会所有技术再找应用，而是先确定一个要解决的问题，再倒推需要什么技术。结业标准也不是考卷分数，而是一个真实上线、有真实用户使用的AI产品。
这一点我印象极深。创造营第一期有位学员，本职是前端开发，完全没接触过大模型。他一开始的选题是“AI写周报工具”，理由是“这总该有人用吧”。结果做用户调研时发现，大多数上班族对周报的真正痛点不是“写不出来”，而是“不想写得像AI写的”，要的是贴合自己项目细节的个性化表达。他后来把产品方向改成了“周报素材整理器”——用户每天用语音或文字丢进去零散的工作记录，系统自动整理成周报素材库，再由用户自己决定怎么用。这个产品反而在结营后拿到了不错的种子用户。方向变了，但技术难度几乎没有增加。这就是按产品逻辑做AI和按技术逻辑做AI的区别。
1.2 课程资料的真实结构：五个阶段
创造营课程资料的整体框架，不是按照“周几上什么课”排的，而是按照项目推进的里程碑拆成了五个阶段。每个阶段都有明确的交付物、验证标准和对应工具，我列一个简要对照表：
| 阶段 | 核心任务 | 交付物 | 常见工具/方法 |
|---|---|---|---|
| P0 方向调研 | 扫描行业机会，锁定潜在痛点 | 痛点清单、竞品分析、方向候选表 | 行业报告、应用商店评论挖掘、访谈 |
| P1 场景定义 | 把痛点收敛为一个具体使用场景 | 用户画像、一句话场景描述、验收指标 | 用户访谈、5 Why分析、场景故事板 |
| P2 技术验证 | 确认现有模型能力能支撑场景 | 模型选型结果、Prompt原型、测试数据 | 各类模型API、Prompt调试工具 |
| P3 产品搭建 | 做出最小可用产品并跑通闭环 | 可演示Demo、核心交互、部署链接 | 低代码前端、函数计算、向量数据库 |
| P4 运营反馈 | 让种子用户用起来，完成首轮迭代 | 用户反馈记录、数据看板、迭代计划 | 埋点系统、反馈表单、访谈记录 |
很多人觉得第五阶段已经不属于“课程”范围了，但这恰恰是创造营特别强调的部分。一个AI产品如果在课程结束时没有真实用户用过的记录，那它本质上是个作业，不是产品。哪怕是找了20个朋友试用，记录下他们使用时的卡点和不满，也比一个精心打磨但没人用的Demo有价值得多。
1.3 适合谁、不适合谁
先说适合谁。第一类是手里有业务场景但不知道怎么用AI提效的运营、产品、业务人员；第二类是有一点编程基础、想独立做AI应用的开发者；第三类是打算在AI方向创业，但还在“想法满天飞”阶段的人。这三类人缺的都不是技术，而是一套“把想法变成产品”的思维框架和实操路径。
不适合谁也很明确：只想听理论、不想动手做的人。创造营的节奏非常快，P0阶段第一天就要去访谈用户，第三天就要给出方向，第五天就要搭出第一个原型。这个过程没法靠“认真听讲”蒙混过关。如果你希望坐在教室里被动接收知识，那这类实战型训练营大概率会让你很不舒服。但反过来说，只要你愿意动手，哪怕零基础，也能在这套机制里硬生生逼出一个属于自己的AI产品来。
2. 最重要的一课：先定义“给谁解决什么痛点”，再谈技术
2.1 大多数人做AI产品的第一个误区
我见过的AI产品失败案例，十有七八死在同一个问题上：拿技术找场景。“我会做大模型应用，所以我要做个AI助手；我能调语音接口，所以我要做语音备忘录”——这种思路看起来顺理成章，实际做出来往往没人用。
原因不复杂。任何技术能力都像工具箱里的一把锤子，如果你手上只有锤子，看什么都像钉子，但用户真正需要的可能是一把螺丝刀。AI能力是手段，不是目的。用户不会因为你的产品用了大模型就掏钱，他只会因为你的产品解决了他某个具体的麻烦而留下来。
我建议所有想做AI产品的人，在打开任何模型API之前，先强迫自己回答三个问题：
- 我的用户是谁？具体到画像，年龄、职业、使用场景。
- 他在什么时刻会用到我的产品？这个时刻有什么特征，是高频还是低频，是紧急还是从容？
- 他现在是怎么解决这个问题的？用手工、用Excel、用另一个工具，还是干脆忍了？
这三个问题如果答不上来，说明你还没找到真实需求。答不上来就先不要做产品，去访谈，去观察，去翻应用商店评论，直到能回答为止。
2.2 快速做好用户调研和场景验证
创造营课程里给了一套特别务实的调研方法，核心原则是“访谈大于问卷，观察大于访谈”。问卷只能验证你已有的猜测，访谈才能发现你不知道的问题，而直接观察用户的行为往往能发现他说不出来的需求。
举个例子，之前有位A同学想做“AI宠物医生”，一开始假设宠主最需要的是“在线问诊”，能帮他们初步判断宠物症状。但做了几轮深入访谈之后发现，真正让宠主头疼的是“不知道该不该去医院”——宠物没有明显症状，但精神状态不对，去一趟医院花几百块检查又可能什么事没有，不去又心里不安。这个需求比“在线问诊”更前置、更加真实。于是他改变了产品定位，做一款“宠物就医决策辅助工具”，通过对症状的追问和可能性评估，帮用户判断“今晚需要去医院”“观察24小时”“按经验自行处理”三个结论。这个产品方向后来在种子用户测试中留存表现非常好。
课程里推荐了一个非常简单的访谈方法，十个用户起步，不是问卷调查而是聊天式深访。每人30到40分钟，问他最近一次遇到相关问题时的完整经过、当时的情绪、尝试过哪些办法、最后怎么解决的。十个人聊完，你大概率就能分辨出哪些是“嘴上说的重要”和“行为上真的重要”的区别。
2.3 痛点分级与“伪需求”识别
不是所有痛点都值得做产品。判断一个需求值不值得做，我基本会用三个维度：痛的程度、急的程度、频的程度。真实的痛点通常至少要满足其中两个。
- 痛的程度：这个问题不给用户带来的损失大不大？是浪费几分钟，还是浪费几千块钱，或者持续消耗情绪？
- 急的程度：用户是想“有空再解决”，还是“今天不解决就受不了”？
- 频的程度：用户是每天遇到，还是一年遇到一次？
三个维度都弱的，基本就是伪需求。比如“AI帮你挑选头像”“AI帮你写年度总结”，听着有趣，但用户既不痛也不急，一年最多用一次，做出来基本就是自嗨。而“AI帮你总结会议纪要里的待办事项”“AI帮你回复客服消息中的重复问题”，这些都是高频、有真实损失、紧急程度中等的场景，适合作为切入点。
创造营里有个不成文的规矩：如果产品的核心场景不能在一句话里说清楚，而且这句话里必须包含“用户在什么情况下、遇到了什么麻烦、产品帮他解决了什么”，那么说明场景定义还没完成。千万不要带着模糊的场景进入开发阶段，这种项目大概率会在中途反复返工。
3. 课程资料里的技术选型思路：用最轻的方式验证想法
3.1 为什么一开始不碰训练和微调
很多零基础学员一听到“做AI产品”就慌，觉得自己得先学会训练模型。这完全是误解。对绝大多数AI应用产品来说，自研模型或微调模型都不是必须的，甚至不是最优解。
原因很简单，成本和收益严重不匹配。自研模型要从数据、算力、算法、部署全部打通，一个团队做半年都不一定稳定；微调模型需要准备高质量标注数据集，对数据量和数据质量要求都很高。而绝大多数产品场景用现成的模型API已经能覆盖80%以上的需求。你的核心价值应该在产品逻辑、用户体验和场景理解上，而不是重新发明一遍模型。
创造营里学员的项目，大概八CD的产品都是直接调用成熟API完成的。真正走到微调这一步的只有两种情况：一是需要模型学会特定术语或特定输出格式，且通过Prompt无法稳定实现；二是需要对生成内容做专业化的风格控制，比如写代码、写法律文书、写医疗建议等强专业性场景。如果你不属于这两种，先老老实实用API把事情跑通。
3.2 模型能力和成本对照
选模型这事，市面上的选择很多，但做产品的时候不需要追求最强，只需要追求最合适的。我给学员的核心建议是：先想清楚你的产品核心任务属于哪一类，再选对应类型的模型。
| 任务类型 | 典型场景 | 推荐方向 | 成本水平 |
|---|---|---|---|
| 通用对话 | 客服问答、闲聊陪伴、灵感助手 | 大语言模型API，通用版本 | 低到中等 |
| 结构化输出 | 信息抽取、表单生成、内容分类 | 大语言模型API，配合JSON输出能力 | 低 |
| 代码辅助 | 生成代码、解释代码、写测试用例 | 代码增强模型 | 中等 |
| 多模态理解 | 识别图片内容、OCR、图表分析 | 视觉语言模型 | 中等到偏高 |
| 私有知识问答 | 基于文档库做问答、企业知识库 | 大模型API + RAG | 中等（含向量库成本） |
选型的大原则是“够用就行、成本可控”。举个例子，如果你的产品只是让用户输入一段食材清单，生成一份菜谱，那用轻量大模型就够了，没必要上最大参数版本。大参数版本回答质量或许略好，但延迟更高、成本更贵，对菜谱这种场景来说用户根本感知不到差异。
3.3 Prompt工程是产品功能的一部分
课程资料里有一个观点对我影响很深：Prompt不是调试用的临时脚本，它就是产品功能的一部分。同一个模型，给不同用户用的时候，Prompt设计的差异直接决定了产品的体验上限。你甚至可以把Prompt当成一种后端逻辑来设计，它决定了输出内容的格式、语气、边界和兜底策略。
一份可复用的基础Prompt模板，课程里是这么教的：
角色与背景：你是{某领域的资深助手}，擅长{具体技能}。 目标：用户输入{输入内容}后，你需要输出{目标结果}。 约束： - 回答必须基于给定资料，不要编造事实。 - 输出格式必须遵循{具体格式}。 - 如果信息不足，请明确告知，并提供获取信息的建议。 示例： 用户输入：{示例输入} 你输出：{示例输出}不要小看“示例”这一段。对大模型来说，一个清晰的示例往往比十句抽象描述更有效。这也是产品调试阶段最值得花时间的地方，同一份Prompt多准备几个好例子，输出稳定性会明显提升。
另外一个容易被忽略的点是结构化输出。做产品的时候，你往往需要模型返回的不是自然语言而是JSON格式的数据，方便前端直接解析。很多模型API都支持JSON模式或者函数调用能力，用法上你要在Prompt里层层定义字段含义，同时告诉模型每个字段的取值范围。如果输出格式不稳定，不要急着换模型，先检查是不是Prompt里的格式约束不够明确。
3.4 需要了解的RAG快速入门
私有知识问答是AI产品里需求非常旺盛的方向，比如企业制度问答、文档速查、教学助手、客服知识库。这些场景有个共同特征：模型没学过你的私有知识，直接问它会一本正经胡诌。解决办法就是RAG，检索增强生成。简单说，先把你的文档切碎、向量化、存进向量数据库，用户提问时先从库里检索出最相关的几段文字，再把这些文字连同问题一起交给大模型，让它基于这些资料回答。
课程里对RAG的入门要求并不高，能跑通一个最小闭环就行，核心步骤就是下面几个：
- 把文档按段落或固定长度切分，最好带上标题信息方便定位来源。
- 用嵌入模型把每个片段转成向量，存进向量数据库。
- 用户提问时，把问题转成向量，用相似度检索出最相关的Top-K个片段。
- 把检索到的片段按顺序拼接到Prompt里，让模型引用回复。
一个比较省事的做法是，用现成的向量库。你只要关心三个参数：切分长度、检索数量Top-K、拼接后提示词的最大长度。切分长度太长，检索容易漂移；太短，上下文不连贯。我的经验是中文文档按300到500字切分比较顺手，Top-K一般取3到5个片段效果比较稳。一开始不用追求完美，跑通最小流程之后再根据用户的提问记录去调整。
4. 实战拆解：从0到1完成一个AI产品Demo的完整过程
4.1 一个真实学员案例：家庭菜谱生成器
用一个创造营里真实走完全流程的学员项目来拆解。这位B同学原本的想法是做“AI美食图片识别”，拍一道菜识别菜名和做法。但完成调研阶段后他发现，用户真正高频的需求场景不是“识别一道成品菜”，而是“冰箱里剩了一堆食材，不知道能做什么”。前者是低频猎奇需求，后者是每天都要面对的决策烦恼。
于是他把产品重新定义为一款“食材变菜谱”工具：用户输入手上有的几样食材，系统结合口味偏好、用餐人数、烹饪时间限制，生成可执行的菜谱方案。这个场景痛点清晰，频率高，而且能明显感受到模型的生成能力在这里是有价值的，用户输入的每一句话都会影响输出结果，每次输入都是不同的。
在技术选型上，他一开始就明确了不需要任何训练。调用一个通用大模型API生成菜谱文案，用极简的网页做输入和展示，全栈加起来不到两百行核心代码。开发量的大头反而花在系统提示词的反复调优上——怎么让菜谱看起来是真的能做的，而不是那种“装饰华丽的废话”风格。
4.2 最小可用版本的核心代码结构
创造营课程资料里提供了一个前后端Demo模板，B同学就是在模板基础上改的。后端逻辑很简单，接收前端传来的食材、人数、口味参数，拼接Prompt，请求模型API，把返回的JSON解析后回传给前端。前端就用一个普通的静态页面，输入框加上提交按钮，结果区域做流式渲染展示菜谱。
一个后端接口的骨架大致是这样的：
from flask import Flask, request, jsonify import openai # 这里以常见的openai接口为例 app = Flask(__name__) client = openai.Client(api_key="your_key") def build_prompt(foods, people, taste, minutes): return f""" 你是一位有十年经验的家常菜厨师。 用户手头有以下食材：{foods}。 用餐人数：{people}人。 口味偏好：{taste}。 时间限制：{minutes}分钟内完成。 请生成两套可行菜谱方案，每套菜谱包含：菜名、用料清单、制作步骤、预计用时。 要求所有食材都尽量利用，不要推荐需要额外购买过多调料的菜。 请以JSON格式返回，结构为： {{ "recipes": [ {{ "name": "菜名", "ingredients": ["用料1", "用料2"], "steps": ["步骤1", "步骤2"], "time_minutes": 30 }} ] }} """B同学的第一个版本只花了大概一天半就上线了。他没有做用户系统，没有做收藏功能，连样式都是最朴素的，但核心链路已经是通的：用户输入食材，得到一份可执行的菜谱。对一个产品Demo来说，这样就够了。
这里其实藏着创造营特别强调的一个原则：先让闭环成立，再谈体验优化。很多新手容易掉进“功能攀比”的陷阱，菜谱生成器还没跑通就想加上“食材提醒”“营养分析”“购物清单”功能，结果每个功能都做得很浅，核心场景反而没做好。正确的节奏是，第一版只保留一个最核心的MVP功能，让它能稳定为用户输出价值，然后再考虑扩展。
4.3 联调和产品打磨中的几个细节
运行起来之后，真实的问题才会冒出来。B同学遇到的最棘手问题是模型输出格式不稳定，偶尔返回的JSON格式不对，甚至会在菜谱里夹带一段“作为一个语言模型……”这种废话。解决办法是在Prompt里增加更强的约束，同时在后端加了防御性解析，解析失败时自动重试一次，再失败就返回固定兜底文案。这些看起来不起眼的细节，其实是产品稳定性的第一道保险。
另一个体验问题是生成速度。用户点击提交后，如果等了五秒才看到结果，流失率会非常明显。创造营模板里用的是流式输出，也就是一个字一个字往外蹦。虽然总耗时没有变短，但用户看到文字开始出现，等待焦虑就会大幅缓解。这个细节强烈建议所有人学走，一个简单的流式响应实现，对用户感知的提升远超你的想象。
4.4 从Demo到发布的验证取舍
Demo跑通之后，创造营会给学员留一个真实的发布窗口，要求在两天内把产品部署到线上，然后去拉30个种子用户使用。这个阶段通常是“信心粉碎机”：你觉得自己做得挺好的产品，在真实用户手里会冒出各种你想都没想过的问题。
比如菜谱生成器上线的第一天，就有用户往输入框里填了“塑料盒”，系统一本正经地生成了一道“凉拌塑料盒”的菜谱。这就是模型幻觉的典型场景，在真实用户面前被直接暴露。B同学的处理方式不是追求模型永不犯错，而是在前端加了一个“免责提示”，同时在Prompt里增加了食材合理性校验，要求模型在遇到无法确认可食用的食材时，先给出风险提示而不是硬编菜谱。
这类问题在产品迭代过程中是常态，不用害怕，更不用因此放弃。产品发布后收到的每条奇葩反馈，都是你迭代方向的免费路标。
5. 跑通之后必须补的三堂课：数据、反馈、迭代
5.1 先埋点再做功能
很多独立开发者在产品上线后最容易犯的错是把所有精力放在加新功能上，完全不看用户行为数据。创造营的课程里会强制要求学员给自己的产品打埋点，哪怕只是手动统计也行。
我只需要最关键的四个数据：
- 页面访问量：有多少人来了。
- 核心操作次数：有多少人真正用了核心功能。
- 操作成功率：有多少人走到最后一步并获得了有效结果。
- 用户流失步骤：用户是在哪一步离开的。
具体埋点实现不难，前端在关键按钮上挂一个统计事件，后端在接口调用处记一条日志。如果你的MVP只是一个小工具，直接用表格手动统计也完全够用。关键是你要养成每天都看这些数字的习惯，让产品决策从“我觉得”变成“数据显示”。
5.2 用户反馈闭环怎么建立
数据只能告诉你“发生了问题”，但没法告诉你“为什么”，这时候就需要用户访谈。创造营课程里有一个很轻量的反馈机制：每次产品更新后，至少找两到三个活跃用户聊一聊，不要问“你觉得这个功能怎么样”，而要问“你最近一次使用这个产品时，卡在哪里了”。后者能收获真实问题，前者只能收获礼貌性夸奖。
处理反馈时要学会分级。P0是核心链路完全不可用的问题，比如菜谱生成不了、页面打不开、输出乱码，这类问题必须当天修复；P1是核心链路可用但体验有损，比如生成速度太慢、返回的菜谱不贴合需求，这类问题在迭代计划内优先处理；P2是不影响使用的优化项和锦上添花的功能，可以往后放一放。
这里要说一个特别常见的坑。很多学员一收到用户反馈“我想要XX功能”就马上去做，结果做出来的功能使用率极低。用户要的不是“这个功能”，而是“这个功能解决的那个问题”。你永远要追问一句：“你打算怎么用它？你现在是怎么解决的？”很多时候你会发现问题和你想象的完全不一样。
5.3 成本、延迟和内容安全
AI产品上线之后，有三个指标会直接决定产品能不能长期活下去。
第一个是单次调用成本。用API做产品，绝对不是“反正每次几分钱无所谓”，积少成多非常可观。控制成本的思路有三种：一是对可以缓存的结果做缓存，比如相同输入直接返回历史结果；二是把Prompt精简到“够用就行”，减少不必要的token消耗；三是对低成本模型能满足的场景，尽量用低成本模型。比如菜谱生成这种任务用轻量版模型就够，不需要每次对话都调用最大参数版本。
第二个是延迟。用户能接受的等待时间远比你想象中短。如果是流式输出，三秒内出现第一个字符基本是及格线。模型调用耗时太高的时候，优先考虑缩短输入Prompt长度，其次考虑换更快的模型线路，再不行就在交互上想点办法，先把骨架文字快速渲染出来。
第三个是内容安全与合规。AI产品面向真实用户后，必须考虑两类过滤：一类是用户输入内容，要防止恶意、违规或诱导模型越狱的内容；另一类是模型输出内容，要防止生成违法、有害或可能引发误导的信息。第三方的审核过滤接口、关键词拦截、输出长度限制都是常用手段，最简单的方案是在Prompt里写清输出边界，再配合一套自动化的内容检测调用。不要觉得这是“大公司才需要做的事”，哪怕你只有几十个用户，这也是产品的基本责任。
6. 结营之后我还在用的几个工作习惯
6.1 用“最小验证”思维做任何新点子
从创造营出来后最大的一个改变是，我再也不会为任何头脑发热的想法直接投入开发。不管是做一个新工具，还是给现有产品增加新功能，第一步永远是先找十个目标用户聊天，确认“真有人要”，第二步是做一个能说服自己的原型，第三步才是动手开发。一个月的时间成本如果投入到错误方向上，比什么都贵。
6.2 建立自己的Prompt资产库
我做项目时会把每次调试好的高质量Prompt按场景分类存下来，像整理代码一样整理提示词。通用角色设定、结构输出模板、稳妥兜底模板、内容安全约束模板，这些是可以跨项目复用的资产。下次做新产品时，直接调取对应的模板作为起点，能把调试时间从几天压缩到几个小时。如果你现在刚开始做AI产品，早点养成这个习惯，越早越省力。
6.3 保持对场景的敏感度
真正做AI产品的时间越长，越会意识到最稀缺的不是技术能力，而是对真实用户处境的理解能力。同一个“帮我写方案”的需求，用户是市场专员、创业者、还是学生，他们的表述方式、使用场景、判定标准完全不同。不接触真实用户，这些洞察光靠头脑想是想不出来的。我现在只要有了新点子，第一反应不是打开编辑器，而是打开手机通讯录，去找一个可能为这个问题发愁的人聊聊。
创造营里反复核对过一件事：AI产品的门槛看似在技术，实际在判断力。判断什么场景值得做、什么反馈该采纳、什么功能该砍掉，这些判断力只能从一次次真实项目的完整循环里长出来。如果你正打算进入这个领域，我的建议很直接——别光看课，动手做，做出来，给人用，然后迭代。这个过程走完一遍，你收获的东西会比看一百篇教程都多。
