从零开始做一个 AI 产品

03课程课件#

04今天和昨天有什么不同#

Day3 的重点是「用 AI 做产品」：你描述目标，Agent 帮你生成网页、整理资料、部署上线。Day4 的重点是「做一个 AI 产品」：产品本身要调用大模型，让模型成为功能的一部分。

欧哟老师选择了一个很适合作为案例的方向：AI 狼人杀。狼人杀本质上是一个重语言、重记忆、重角色扮演的文字游戏。AI 玩家要记住自己的人设、身份、历史发言和当前局势，再输出符合角色目标的发言或投票。这个案例能把很多 AI 应用的关键概念一次讲清楚。

05AI 应用的第一块积木：API#

调用大模型，最常见的方式是 API。API 可以理解为程序和程序之间沟通的接口：你的应用把请求发给模型服务，模型服务返回结果。因为强模型很重，通常跑在云端，大多数产品不是自己在本地部署模型，而是通过 OpenAI、DeepSeek、TokenDance、OpenRouter 等平台调用模型。

1. API Key 是钥匙 API Key 用来证明调用者是谁，也决定扣谁的钱。它不能随便泄露，演示时也应该设置额度上限，避免被别人拿去刷。
2. 模型 ID 决定用哪个模型 一个聚合平台可能有很多模型。请求里填不同的 model id，就能切换 DeepSeek、Kimi、Qwen、MiniMax 等不同模型。
3. 聚合平台降低切换成本 直接接每家模型厂商会很分散。聚合平台的价值是一个 API Key 调多个模型，方便根据效果和成本做选择。

06模型怎么选：模态、上下文、价格和 TPS#

做 AI 产品时，模型选择不是一句「用最强的」就结束了。不同模型有不同模态、上下文窗口、价格、响应速度和风格。产品经理至少要能看懂几个关键指标。

欧哟老师特别提醒：角色扮演能力、文风、推理稳定性，很难完全从参数上看出来。很多时候要靠真实测试：把同一套提示词给不同模型，观察它是否会伪装、是否会记住局势、是否会按结构输出，再结合成本决定。

07AI 为什么「记得住」：上下文和无状态请求#

很多人以为 AI 会自动记住前面对话，其实大模型请求本身是无状态的。你每次发消息，产品都会把历史消息一起打包发给模型。模型不是「自己记得」，而是「这次请求里重新看到了」。

1. 第一轮只发当前消息你说「你好」，模型根据这句生成回复。
2. 第二轮带上历史你说「我叫志煌」，产品把前面的「你好」和模型回复也带上。
3. 第三轮继续打包你问「我叫什么」，模型能回答，是因为这次请求里包含「我叫志煌」这条历史。
4. 上下文会越堆越长一旦超过窗口，就需要裁剪或总结，否则请求放不进去，模型表现也会变差。

狼人杀里，每个 AI 玩家都需要看到历史发言，但不是所有历史都同等重要。游戏后期可以把早期对话总结成「谁怀疑谁、谁投过谁、谁暴露过什么线索」，而不是原封不动塞进全部聊天记录。

08系统提示词：让 AI 进入角色#

系统提示词是模型请求里一块特殊的区域，用来给模型设定身份、规则和输出格式。在 AI 狼人杀里，每个角色的系统提示词会包含几类信息：

这也是 AI 游戏和普通聊天最大的区别之一：不是让模型自由发挥，而是让模型在规则和目标内表演。产品经理要设计清楚角色边界，否则模型会说得很自然，但游戏逻辑会乱。

09结构化输出：让 AI 结果能变成 UI#

如果 AI 只返回一句自然语言，前端很难稳定解析。比如投票环节，如果模型有时说「我投 8 号」，有时说「八号很可疑」，有时又没写数字，程序就很难知道它到底投给谁。

所以 AI 应用常常要求模型返回结构化数据，最常见的是 JSON。比如：

{
  "speech": "8号的反应太刻意了，正常人不会一直忙着自证。",
  "vote": 8,
  "confidence": 0.74
}

1. 自然语言负责体验 `speech` 可以展示在聊天区，让玩家感受到角色在发言。
2. 结构字段负责逻辑 `vote` 可以直接驱动投票系统，不需要从一句话里猜数字。
3. 格式约束减少事故 用 response format / JSON schema 这类能力，可以显著降低模型乱输出导致的 UI 崩坏。

10从原型到项目：先 HTML，再 Next.js#

课上 Codex 默认推荐用 Next.js 做项目。原因很现实：Next.js 语料丰富、前后端一体、适合做真实应用，也对 SEO 更友好。AI 很熟悉这套技术栈，所以让它写起来更稳定。

但欧哟老师没有一上来就让它完整开发，而是先让它写一个 HTML 原型。这个动作很重要：HTML 轻、快、可视化，适合先看产品形态和视觉方向。等确认原型大方向后，再让 Codex 基于它实现真实项目。

1. 先用 Plan 模式收集需求让 Agent 反问游戏形态、人数、规则、AI 目标和模型调用方式。
2. 先出 HTML 原型验证界面布局、发言区、玩家状态、投票区、事件流这些核心区域是否成立。
3. 发现 UI 不好就换模型Codex 的默认 UI 可能粗糙，Gemini 更擅长出好看的 HTML 设计稿。可以让 Gemini 先做原型，再让 Codex 参考实现。
4. 确认风格后再接功能把 HTML 原型作为参考代码交给 Codex，要求它尽可能保持 UI 一致，再实现真实的游戏逻辑和模型调用。
5. 用 Git 保护过程每完成一个稳定阶段就 commit，后面 Agent 改错时可以回滚，而不是从头重做。

11Git：让 Vibe Coding 有撤退路线#

Vibe Coding 很快，但也很容易让 Agent 一次改很多文件。没有版本管理，改坏了就很难回到之前的稳定状态。Git 的价值就是给代码保存历史。

欧哟老师给的学习建议很实用：Git 不一定要先系统学完，先在真实项目里遇到问题，再问 Agent「怎么保存版本」「怎么回滚」「怎么开分支」。问题驱动学习，比背概念更快。

12Alice 的旅行系统：从一句吐槽长出的产品功能#

第二位嘉宾洛小山老师分享了 Alice 旅行系统的产品故事。最开始的触发点非常小：有用户吐槽，自己的 Alice 老在珠海，朋友圈总是珠海天气，而自己明明从来没去过珠海，甚至被珠海连续下雨搞得很压抑。

如果只看表面，很容易把需求理解成「让 Alice 可以换城市」。但团队继续往下问：用户为什么想让 Alice 去别的地方？最后发现，真正的需求不是旅行攻略，而是情感关系。

1. 回忆分享 我去过敦煌，我喜欢你，所以我希望你也去一次。地点承载的是用户自己的记忆和分享欲。
2. 替身探索 我暂时去不了冰岛、巴厘岛或济州岛，你先替我去看一看。旅行变成一种代偿式陪伴。
3. 收集养成 Alice 去过的地方变成卡片和照片墙。用户获得的不是攻略，而是共同经历被沉淀下来的感觉。

用户希望 Alice 去旅行，关键不是「去」，而是「Alice 去」。如果用户不喜欢这个角色，它去哪都和用户无关。

13差点做歪的四个方向#

洛小山老师反复强调：从 demo 到产品，最关键的不是「能不能做」，而是「哪些方案不能做」。Alice 旅行系统中有几个看起来合理、最后被砍掉的方向。

1. 不做地图地图天然涉及真实边界、服务商标准和合规风险，也会把产品拉向工具属性。Alice 更适合用洞洞板、拍立得、手账这类情感化收集界面。
2. 不做冰箱贴冰箱贴看起来有收集感，但在不同屏幕尺寸下自适应很麻烦，也和拍立得、手账的视觉语言打架。
3. 不把游记只放进 WikiWiki 是用户要求 Alice 产出的资料，游记更像 Alice 自己的创作。入口应该在旅行页，而不是普通知识库里。
4. 上云但要安全游记是用户和 Alice 的情感资产，不能因为换设备、误删文件就永久丢失。但上云要先加密，再同步，还要考虑分享、审查、治理和增长闭环。

14Alice 如何把已有能力重新编排#

Alice 的旅行系统并不是从零写一个孤立功能，而是把已有能力重新组合：朋友圈、Wiki、记忆、情绪、地点搜索、生图、分享、审查、云同步。产品设计的重点，是把这些积木串成一个用户能感知的完整体验。

这个案例提醒我们：AI 产品不是每个功能都从零开始堆模型，而是要形成一套可复用的系统能力。等到新需求出现时，把已有能力重新编排，速度会比每次重做快得多。

15从用户共建中长出产品#

Alice 的旅行系统一路被用户推着走。用户让 Alice 去巴厘岛、冰岛、墨西哥、济州岛，也有人让她去月球、火星、潘多拉星球。用户的想象力会不断冲击产品边界，产品团队要做的不是全盘照收，而是判断哪些反馈指向了更深的关系需求。

1. 用户第一 不闭门造车。真实用户的吐槽、许愿、评价，往往是产品迭代最好的入口。
2. 保持专注 Alice 砍掉的功能比留下的多。只保留能加深关系、符合产品核心体验的部分。
3. 把小白带过去 专业用户可以自己配 API Key；小白用户需要一键配置和手把手引导。好产品要替用户吃掉复杂度。

洛小山老师最后给出的判断很直接：Demo 靠灵感，产品靠规则。AI 可以帮你写代码，但不会替你定义字段、处理合规、做版本发布、维护用户社区，也不会自动告诉你该砍掉哪个方向。这些仍然是产品经理和创业者的核心工作。

16今天真正要带走的能力#

这节课不是单纯教一个狼人杀或一个旅行系统，而是在训练两种能力：一是把 AI 能力接进产品，二是判断一个 AI 功能能不能成为长期体验。

1. 用 API 思维理解 AI 功能模型不是魔法，它是一个被你调用的服务。输入、上下文、输出格式、成本、速度，都要可控。
2. 用结构化输出连接 UI自然语言负责体验，JSON 等结构化字段负责业务逻辑。没有结构，AI 结果很难变成稳定产品。
3. 用原型降低试错成本先用 HTML 看形态，再用 Next.js 或真实工程实现功能。不要一上来就重投入。
4. 用 Git 管住 Vibe CodingAI 改代码很快，必须用 commit、diff、branch 给自己留回滚和审查的空间。
5. 用取舍定义产品能做的很多，值得做的很少。真正成熟的产品判断，常常体现在你砍掉了什么。