【快速入门】认识你的新伙伴

1905 人学过

一、AI到底是什么?别怕,它就是个超级实习生

01 前言

你可能听过很多关于AI的说法:
"AI要取代人类了。"
"AI比人聪明。"
"AI太难了,我学不会。"
都不对。
AI就是一个实习生。一个很特别的实习生。

02 这个实习生有什么特点?

学历逆天。 它读过整个互联网——维基百科、Stack Overflow、GitHub上几十亿行代码、无数本书、论文、帖子。论"见多识广",没有人类比得过它。 它拥有全人类所有的公开知识。
干活极快。 你说一句话,它几秒钟就交活。写一封邮件、画一个网页、解释一个概念,眨眼就完。
它读过所有关于游泳的书,但从没下过水。
它知道所有菜谱,但从没进过厨房。
它能背出所有管理学理论,但从没带过一个团队。
所以它会犯一些很蠢的错:
• 你问它一个事实,它可能一本正经地胡说八道(业内叫"幻觉")
• 你让它做一个东西,它可能自作主张加了一堆你没要的功能
• 你不说清楚要什么,它就按自己的理解交差——然后你发现完全不是你想要的
像不像你带过的实习生?

03 它能干什么?

三件事,我相信你一定都听说过。
问它问题。 打开豆包或ChatGPT,问:"用大白话解释一下什么是数据库。"——你会得到一个比百度搜索好10倍的回答。
让它写东西。 说:"帮我写一封请假邮件,语气正式一点,理由是家里有事。"——3秒出一封你改两个字就能发的邮件。
让它写代码。 说:"写一个网页,页面中间显示一个倒计时,从60秒倒数到0。"——它真的会给你一个能跑的网页。
注意:这不是三种不同的AI。这是同一个实习生的三种能力——回答、写作、编程。
就像你的实习生可能既能做PPT、又能写文档、还能跑数据一样。

04 它不能干什么?

三件事,现在就记住,后面会反复验证:
不能保证正确。 它说的话听起来都很自信,但可能是错的。你必须自己判断,或者让它给出来源。永远不要无条件相信它的回答。
不能记住上周的事。 每次你打开一个新对话,它就像失忆了一样,完全不记得你们之前聊过什么。(后面课程会教你怎么解决这个问题。)
不能替你做决定。 它可以给你5个方案,但选哪个是你的事。它是执行者,不是决策者。
想要带好AI这个实习生,有一件最重要的事需要不断学习和练习:你要学会管理AI的"自主级别"
有些简单的事,让它自己干就行;有些重要的事,必须你审完才能用。
就像管理实习生——你不会让第一天来的实习生直接去见客户,对吧?

05 所以,你和AI是什么关系?

💡
你是老板,AI是实习生。
你负责:想清楚要做什么、检查它交的活、做最终决定。
AI负责:干活、出方案、处理细节。
这门课教你的,不是"怎么写代码"——是怎么当一个好老板
一个好老板不需要自己会写代码,但需要能说清楚要什么、能判断交付质量好不好、能在它犯错的时候纠正方向。
还有一件事你必须记住:
以前在公司里,你是干活的,领导背锅。
现在反过来了——AI干活,你背锅。
AI写的代码出了bug,客户不会找AI,会找你。
AI写的文案有错误,老板不会骂AI,会骂你。
AI给的方案不靠谱,亏钱的不是AI,是你。
AI没有责任,你有。
所以"检查它交的活"不是可选项,是你的本职工作。这个实习生不要工资、不会离职、24小时在线——但它也不背锅。锅,永远是老板的。
下节课,我们就开始——给这个实习生派第一个任务。

二、初体验:10分钟,做出你的第一个网站

01 「扣子编程」

扣子编程是字节跳动推出的 AI 应用开发平台,旨在让用户无论是否具备编程背景,都能快速构建和部署 AI 应用。
在我们2025年过往几期的课程当中,我们推荐的是Vercel(海外通用工具),但是在学员配置海外上网环境的时候,遇到了比较多的麻烦。
因此,这次的基础篇,我们改用国内工具!进一步降低打开的学习门槛!
扣子编程对新手非常友好,你只需要用浏览器打开它https://coze.cn,用自己的手机号注册,即可免费使用。
特别说明
1.
扣子编程的免费账号的积分是比较有限的。你可以先用着免费的,不够用的时候,升级到付费版本,不贵,每个月十几块钱。https://code.coze.cn/subscription/manage
2.
如果你是扣子的新用户,可以点击下面的链接,免费获得额外6000积分。
来一起领取 AI 新同事【扣子】的见面礼,得免费积分礼包! https://www.coze.cn/studio?invite_code=3bbef1ebf63d4543863a87797fa84b0a,点击链接进入活动!
选择「扣子编程」
选择「扣子编程」中的「网页应用」

02 随便想一个产品idea

随便输入你想要做的内容。
我只是简单输入了
做一个 记忆力配对游戏,游戏界面是一个4x4的方格,用户需要靠自己的记忆力做配对。
关键点:要保证你描述的需求,对于任何人来说,都没有歧义。
反例:“我要做一个改变图片大小的网页”,这是一个非常有歧义的表达。“通过降低画质的方式改变图片大小”,可以理解为“裁剪图片”也可以理解为“压缩尺寸”还可以理解为“改变图片分辨率从而压缩图片文件的大小”等等。
❌ "我要做一个改变图片大小的网页"
✅ "我要做一个网页,用户上传图片后,可以拖动裁剪框选择区域,点击确认后下载裁剪好的图片"
更多反例:
“下班顺路买一斤包子带回来,如果看到卖西瓜的,买一个。”
“小明无法将奖杯放到口袋里,因为它太了。”
“小明无法将奖杯放到口袋里,因为它太了。”
上面的几句话是有歧义的。 你不妨琢磨一下歧义在哪儿。
当你构思了一句需求,不妨先找同学帮你挑挑刺,直到所有人都挑不出来歧义~~
为了你方便学习,我还为你准备了一些简单、容易实现的项目创意,方便新手进行练习。
以下列表中的项目创意,大概率没有商业化潜质,只是为了练习使用。
🎨 CSS Art 生成器
核心玩法:点击按钮随机生成由多边形、渐变、滤镜组成的抽象艺术并支持下载 PNG
Why 好玩:结果千变万化,发到朋友圈很炫
⚡️ 正能量弹幕
核心玩法:本地 JSON 存 200 句励志语,页面每 10s 随机一句从屏幕右侧飞过
Why 好玩:立刻能用于「食堂减压」场景
📝 Markdown 实时预览
核心玩法:左侧编辑 MD,右侧即时渲染 HTML,支持复制一键发布
Why 好玩:写作党 & 博主刚需
番茄钟
核心玩法:25 min 倒计时 + 5 min 休息循环,结束时桌面通知 + 音效
Why 好玩:办公桌面小助手,用着用着就留存
📂 图片压缩/改尺寸
核心玩法:拖 & 放图片 → 显示前后体积,对比下载
Why 好玩:不用上传云端,隐私友好
🧠 记忆力配对游戏
核心玩法:4×4 翻牌配对,记录用时 & 步数
Why 好玩:最经典也最带感的 JS 小游戏
极简 To-Do
核心玩法:可打勾、拖拽排序、深色模式,数据持久化到浏览器
Why 好玩:"Todo 教材"永不过时,1 分钟写完
🍱 午餐大转盘
核心玩法:输入 10 个菜名 → 转盘随机抽选,"不知道吃啥"终结者
Why 好玩:正契合你们的"决定午餐"痛点
😂 表情包生成器
核心玩法:上传图片 / 选模板,拖动文字框,导出带水印 GIF
Why 好玩:年轻用户超喜欢,容易裂变
📅 倒数日卡片
核心玩法:设置事件日期,自动显示 D-day 卡片,可生成社交海报
Why 好玩:生日/考试/演唱会… 分享率高

03 见证奇迹的时刻!

我们演示一个稍微好玩点的:末日生存游戏
在扣子编程里输入这个Prompt。
你可以直接复制,或在我基础上进行修改。
【单页应用,React + Tailwind CSS + shadcn/ui,不需要后端或任何外部API】这部分先不要改
这是我们对技术细节的要求。这一句看不懂也没关系,学到后面的课程,我们会帮助你理解它们的意思。
Markdown
创建一个中文互动故事网页应用,主题是"末日生存:你能活过72小时吗"。

要求:
1. 【单页应用,React + Tailwind CSS + shadcn/ui,不需要后端或任何外部API】

2. 故事数据用JSON对象硬编码在代码里,至少15个节点、4个不同结局(存活/英雄/黑化/死亡)
3. 每个节点包含:场景描述文字(50-100字,有画面感)、2-3个选项按钮
4. UI设计:
   - 深色主题,赛博朋克/废土风格
   - 顶部显示:生存时间进度条(0-72小时)、三个状态值(体力❤️ / 物资🎒 / 信任👥),每次选择会影响数值
   - 场景文字用打字机效果逐字显示
   - 选项按钮有hover动效
   - 背景用CSS渐变模拟不同场景氛围(白天/黑夜/危险用不同色调)
5. 到达结局时:
   - 显示结局标题 + 总结文字 + 你的最终数值
   - 一个"再来一次"按钮
   - 一个"分享结果"按钮(生成一段可复制的文字,格式如:"我在末日生存了XX小时,结局是【XXX】,体力XX/物资XX/信任XX,你能比我强吗?")
6. 加入随机事件:每3个节点触发一次随机事件弹窗(如"你发现了一个废弃超市"/"一群流浪狗挡住了去路"),选择后影响数值
7. 移动端适配,手机上体验要好
💡
试试把"末日生存"换成你喜欢的主题!比如"校园恋爱模拟器"、"创业72小时"、"密室逃脱"——只需要改主题描述和结局设定,其他技术要求保持不变。
点击发送后,就可以等待生成了。
大概3分钟以后,就制作完成!
左侧是对话窗口、对话记录,右侧点击“预览”
这个游戏是真的可以玩起来的!

04 继续打磨

我们可以在对话框中继续输入需求,进行小修小改。
💡
注意:先试试小修小改,不建议大改,因为此时我们的技能还不具备 ,不要着急。 :) 学到后面的课程,等你明白了原理,再放开手脚大改。
风格修改
我们可以先试试,修改配色
下面截图是现在的配色。你可以往上面翻,和之前的风格对比一下,是不是改动很明显?
指哪儿打哪
我们还可以试试“截图修改”,指哪儿到哪儿。从预览效果当然,只截图一部分。
例如,我对下面红框这部分不满意,希望改成实体案件风格,我们可以用任何截图工具(无论是飞书、微信或者系统自带截图),单独对它截图。
截图后,粘贴到左下角的框里,同时带上“截图” + “文字”,发送修改意见
对比一下,改好了!
看出来按钮的风格变化了吗?

05 分享给朋友,让朋友玩

看到右上角的“部署”按钮了吗?
只需要点击它,我们的产品就会自动部署,获得一个全球都能访问的URL链接!
我们保持其他全部默认,只点击“开始部署”
扣子编程会自动帮我们执行打包、构建、部署上线等操作。
💡
注意:遇到看不懂的词,比如刚才提到的“打包”“构建”,记得随时问AI哦!推荐问豆包,最方便!
3分钟后,等到看到界面变成这样,就是成功了。
你会得到一个专属的域名地址!
赶快把你的得到的域名地址,发给朋友吧!

06 理解原理

刚才发生了什么?
扣子编程的产品设计非常好,当你和他聊天的时候,它会在云端打开一台电脑,帮你写代码、运行代码。
我们回顾一下开头: 当我们第一次发送消息的时候,扣子编程的右侧,其实已经告诉我们了 —— 它正在打开一台临时电脑(云端沙箱)
我的代码在哪儿?
我们的代码都在这台临时电脑里。
我们可以点击右上角的这个按钮,查看到刚才AI为我们的所有代码。
如果你想要的话,你可以直接修改这些代码,
或者,把代码全部下载到你的自己的电脑上。
顶部的Tab是可以左右滑动的。当我们玩够了代码,可以再次点击“预览”,切换到预览界面,查看效果。

07 作业

作业一(必做):用扣子编程做一个你自己选题的互动故事,部署上线后把链接发到课程群里。
附上一句话说明:你的版本,和原版相比,改了什么,为什么更好
作业二(挑战):用扣子编程多做几个产品,选一个你自认为最能代表自己最高水平的,分享给朋友,进行炫耀。😄
下节课见

三、跟AI讨论需求:从模糊想法到清晰指令

01 你不是在跟AI聊天,你是在管理一个实习生

上一节课,你用一段话让AI做出了一个游戏。很爽。
但你有没有想过一个问题——
你刚才做的事情,到底是"写代码"还是"写需求"?
答案是:写需求
你一行代码都没写,但你做出了一个能玩的产品。真正决定产品质量的,不是代码,是你那段话写得好不好。
这就是AI时代最大的变化:你的核心技能从"写代码"变成了"写清楚你要什么"。
斯坦福有一门课专门教"现代软件开发"。他们的核心观点是:Spec(需求规格)就是新的源代码
你写给AI的那段话,就是一份Spec。
Spec写得好,AI交付就好;Spec写得烂,AI交付就烂。
跟AI的能力无关,跟你说清楚了没有有关。
很多人把AI当搜索引擎用:"帮我做一个末日生存游戏"。
然后AI交了一份作业,你一看——不对,不是我要的。
你骂AI笨?不对。你回想一下,如果你是老板,你跟一个新来的实习生说"帮我做个末日生存游戏",实习生交上来的东西大概率也不是你要的。
不是实习生笨,是你的需求太模糊。
"末日生存游戏"这六个字,可以是:
• 一个文字冒险
• 一个2D像素射击
• 一个回合制策略
• 一个选择题形式的心理测试
你脑子里想的是A,AI做出来的是B。
所以第一个认知转变是:你不是在"跟AI聊天",你是在"给实习生下任务"。
你是管理者,AI是执行者。管理者的水平,决定了执行者的产出。

02 一份好的SPEC长什么样?

我们把上节课那段Prompt拆开看,看看它到底说了些什么。
它告诉AI要做一个互动故事——不是"做个游戏"这种模糊的说法,而是精确到了:15个故事节点,4个不同结局,每个节点给用户2到3个选项。
就像你不会跟实习生说"写个报告",你会说"写一份3页的竞品分析,覆盖3个竞品,每个竞品分析优劣势"。有数字,才有边界。
它规定了视觉风格:深色主题,赛博朋克,打字机效果逐字显示,按钮要有hover动效,背景色跟着场景变化。
注意——它没有说"好看一点"。"好看"是世界上最没用的需求描述,每个人对"好看"的定义都不一样。它说的是具体的风格和具体的效果。
它设计了一套数据系统:体力、物资、信任,每次选择都会影响数值。
这一条很多人想不到,但正是这三个数值,让产品从"点点点看故事"变成了"每一步都要权衡的决策"。好的需求不只描述用户看到什么,还要描述背后有什么在运转。
它把结尾也想好了:结局页要显示标题、总结文字、最终数值,要有"再来一次"按钮,还要有"分享结果"——连分享文案的格式都替AI写好了:"我在末日生存了XX小时,结局是【XXX】,你能比我强吗?"。
没有闭环的产品就像没有结尾的故事,用户用完不知道干嘛。
最后,它还划了红线:不需要后端,不调任何外部API,故事数据硬编码在代码里。
这一条最容易被忽略,也最重要——告诉AI"不要做什么",比告诉它"要做什么"更关键。不然AI会自作主张帮你接数据库、调第三方服务,然后报一堆你看不懂的错。
就像管理实习生:你不说"不要用付费素材",他可能给你买了一堆图,回头找你报销。
你看,就这么一段话,它其实同时干了好几件事:划定了功能边界、锁定了视觉风格、设计了数据流转、想好了用户闭环、还画了技术红线
这些东西有没有套路?有。我们第5节会给你一份检查清单。
但在那之前,你先记住一个感觉:好的SPEC读起来,不像在"聊天",更像在"下达一份任务书"。

03 信息不是越多越好

斯坦福那门课里有一篇阅读材料叫《长上下文是怎么失败的》。
核心观点是:给AI塞太多信息,效果反而变差。
为什么?因为AI会被无关信息干扰,就像你给实习生发了20页参考资料,他反而不知道重点在哪了。
所以好的Spec不是写得长,而是写得准:
• ❌ 写500字描述你想要的氛围、灵感来源、参考游戏、个人偏好……
• ✅ 写5条,每条一句话,精确到可验收
少而准 > 多而杂。

04 歧义是最贵的Bug

来看几个经典歧义,这两个例子我们课程里经常提到:
"下班顺路买一斤包子带回来,如果看到卖西瓜的,买一个。"
买一个什么?西瓜还是包子?
"小明无法将奖杯放到口袋里,因为它太大了。"
什么太大了?奖杯还是口袋?
人类能靠常识猜,AI不行。
AI会严格按字面意思执行——然后给你一个"技术上正确、但完全不是你想要"的东西。
需求里的每一个歧义,最终都会变成你返工的成本。 在AI时代,返工成本虽然低(改一句话重新生成就行),但养成"说清楚"的习惯,受益的不止是跟AI协作——你跟任何人协作都会更高效。

05 写给AI的任务书:一份检查清单

斯坦福大学2025年秋季有一门课叫 CS146S: The Modern Software Developer(现代软件开发者),专门教"AI时代怎么做软件"。课程的一个核心观点是:Spec is the new source code(需求规格就是新的源代码)。
他们给学生发了一份正式的设计文档模板(Design Document Template),里面包含了 Current Context(现状)、Functional Requirements(功能需求)、Non-Functional Requirements(非功能需求)、Design Decisions(设计决策)、Technical Design(技术设计)、Implementation Plan(实施计划)、Testing Strategy(测试策略)等十几个字段。
如果你想看原版模板,可以看这里(需要能够访问海外网络):
你不需要现在就读完它。但记住一件事:你写给AI的每一段Prompt,本质上就是一份迷你版的设计文档
专业开发者写几十页的设计文档才开工,你只需要写5行就能让AI干活——这就是AI时代给你的杠杆。
它有点太专业了,我把它简化成了适合咱们新手用的版本——还记得刚才我们拆解那段Prompt时发现的规律吗?就是这五条:
检查项
问自己
问题陈述
用户要什么体验?我能一句话说清楚吗?
方案描述
功能、数量、交互、视觉,具体到数字了吗?
技术约束
技术栈写了吗?
红线
说清楚"不要什么"了吗?
交付标准
怎么算做完?手机能用吗?有闭环吗?

06 一个快速提升SPEC的技巧:和AI讨论!

我们可以让AI帮助我们!
请你复制下面的Prompt,把一句话需求改成你脑海里的想法,
找到任何一个AI(豆包、ChatGPT、扣子编程,都可以),和它讨论。
Plain Text

我要做一个:  …………这里只用一句话,把你的想法说个大概……
请你先不要写代码,你需要
1. 像苏格拉底一样,帮助我梳理需求,
2. 你需要一个问题一个问题地问,每次都给出带编号的选项
3. 直到我们能够形成一份完整的SPEC,符合以下标准
• Problem Statement(问题陈述)
• Proposed Solution(方案描述)
• Technical Constraints(技术约束)
• Non-goals(明确不做的事)
• Success Criteria(成功标准)
不过,我们最建议:就在「扣子编程」里,和AI聊需求。 因为一旦我们聊好,只需要说“开干”,它就能写代码了,不再需要切换工具。
之后的交互过程如图所示
有些问题你可能不想选,或者觉得无关紧要,那么你可以回答“你定”“你推荐”“听你的”
最终可以,大概经过10轮对话左右(复杂任务需要更多),我们可以得到完整的、规范的SPEC(下图3)。
过程中,请抱有尽量多的耐心,可不要嫌麻烦哦!
别忘了:歧义是最贵的BUG! 最大的浪费,是返工
如果你是在「扣子编程」里梳理需求,那么,梳理完需求之后,你只需要说
Plain Text
“需求已确认,开始写代码”
就可以让AI开始编程了。
这次,「扣子编程」生成的产品,就比上节课的简单例子,要强大太多了!
(从游戏性的角度来说)
💡
如果报错了,不怕
复制错误,发到聊天窗里,让扣子编程自动修

07 一个不太舒服的真相

你可能觉得:我就是想随便做个东西玩玩,有必要写这么清楚吗?
当然可以随便写。AI会给你一个"差不多"的东西。
但"差不多"和"就是这个"之间的差距,就是你花5分钟想清楚需求的价值。
这5分钟,可能帮你省掉30分钟的来回修改。
而且说实话——能把需求说清楚的人,在任何行业都是稀缺的。
大多数项目失败不是因为技术不行,是因为从一开始就没人说清楚到底要做什么。
AI只是给了你一个零成本的练习场:说错了,3秒钟重来。

🎯 作业

1.
回到上节课你做的作品,把你当时写的Prompt拿出来,用本节课的检查清单过一遍(问题陈述/方案描述/技术约束/红线/交付标准),补上缺的,重新生成一版,截图对比前后差异
2.
写一段全新的Prompt(不是互动故事,换个类型),使用本节课的方法,完成高品质的SPEC,再完成作品。

四、什么是AI产品?跟普通产品到底差在哪?

01 三种产品,三个时代

上节课你做了一个末日生存游戏。很酷,能玩,能分享给朋友。
但我得告诉你一个事实——那不是AI产品。
它是"用AI做的产品",但不是"AI产品"
这两个东西完全不一样。
这节课我们先讲清楚,什么是AI产品。
为了搞清楚什么是AI产品,我们先看看三种不同的产品:
第一种:规则型产品
手机自带的计算器、Excel表格、红绿灯、自动售货机。
它们的特点是:人写好了所有规则,机器照着执行
你按1+1,它永远给你2。
你投5块钱按可乐按钮,它就掉一瓶可乐。
输入确定,输出就确定,没有任何"理解"和"思考"。
第二种:规则 + 识别型产品
你打10086,听到"普通话请按1,English press 2";
还有早期的智能音箱,你可以用来点歌,但是也经常点错
早期的Siri,你说"明天天气怎么样",它能回答,但你稍微换个说法它就懵了。在2020年之前,没有人可以忍受和Siri连续对话3分钟,稍微多说几句,就露馅了,它们是在“装聪明”,不是“真聪明”
这类产品看起来有点"聪明",但本质上还是一棵决策树
它能"听懂"你的话,其实只是在匹配关键词——你说"余额"就跳到余额分支,你说"我想知道卡里还有多少钱"它可能就不认识了。你说一句它没见过的话,它就来一句:"抱歉,我没听懂,请再说一次。"
第三种:AI原生产品
ChatGPT、豆包、哄哄模拟器。
这类产品里面住着一个大模型——它能理解自然语言,能推理,能生成从未见过的内容。你跟它说什么都能接住,每次回答都不完全一样,因为它不是在"匹配关键词",是在"思考"。
你问豆包"用大白话解释一下相对论",它不是从数据库里查一条现成的答案——它是实时理解你的问题,然后组织语言给你解释。
AI原生产品的核心: 产品能够理解人话,并生成从未预设过的回答。
我们这门课要教你做的,就是第三种。

02 用AI做的 ≠ AI产品

回到你的末日生存游戏——
它的故事是写死在代码里的JSON。15个节点、4个结局,每一步走哪条路都是预设好的。产品跑起来之后,没有任何AI在工作
它就像一本"选择你自己的冒险"故事书——内容都印好了,你只是在翻页。
用一句话区分:
用AI做的产品:AI是你的工具,帮你写代码。但产品上线后,里面没有AI在跑。
AI产品:产品上线后,里面有AI在实时工作——在对话、在生成、在理解、在判断。
打个比方:用机器人焊接的汽车 ≠ 自动驾驶汽车。 前者是"用AI造的",后者是"AI在里面跑的"。

03 所以,怎么让你的产品变成AI产品?

让产品里"住进去"一个AI
其实没你想的那么难——你不需要自己训练一个AI,就像你不需要自己养一头牛才能喝牛奶。
下节课我们聊:预制菜思维
别人已经把AI能力做成了现成的"菜",你只需要学会怎么点菜、怎么搭配。

五、开发AI产品的核心秘密:预制菜思维 + 积木思维

01 本节一句话

做 AI 产品 = 用 AI 能力搭积木。
你不是从零发明技术,你是在“预制食材包”里选料、搭配、出品。

02 AI 产品生意,本质是创意生意

今天的 AI 能力越来越像“预制食材包”:人人都能买到、都能用到。
真正拉开差距的不是你会不会做某个 API,而是你有没有创意、会不会组合
我常常讲
AI产品生意,本质上就是创意生意
技术不是壁垒,创意和组合才是壁垒。

03 4块8的酸菜鱼预制菜包,为什么能卖48

预制菜不是一道“现成菜”,它是:
预制鱼片
酸菜
浓缩汤底
调味料
甚至锅、火、打包盒都配好
食材包很便宜,但餐厅卖的是:
菜名 + 场景 + 体验 + 稳定出品
AI 产品也一样:
调用模型/API 很便宜 ,每个人都能用
值钱的是:你把它搭成一个用户愿意掏钱的体验,并且每次都能稳定交付。

04 AI 能力积木

我们把 AI 产品理解成“积木搭建”,积木就分三类:大脑积木、感官积木、外部积木
AI产品 = 大脑积木(大语言模型) + 感官积木(图/音/视频) + 外部积木(搜索等工具)
大脑积木:大语言模型
能做什么:
对话、写作、改写、总结、生成方案、角色扮演、多轮互动
在扣子编程里常见能力(你可以直接用):
流式/非流式对话
多轮对话支持
思考模式
缓存机制
感官积木:图像 / 语音 / 视频生成能力
图像生成
文生图,支持 2K/4K
批量生成、参考图
语音
TTS:文字转语言
ASR:语言转文字
视频
文生视频 / 图生视频
类比:浓缩汤底 + 摆盘 + 上菜方式。
一旦加上图/音/视频,作品更“像产品”,也更容易传播。
外部积木:联网搜索、存储、记忆
扣子编程的联网搜索能力包括:
网页搜索
数据库
记忆
等等

05 扣子编程为什么适合新手:因为它把积木都给你配齐了

我们用扣子编程当新手入门篇教具的一个重要理由:
它让你不用到处注册第三方服务,就能直接拿到一堆可用的 AI 积木(LLM/图像/搜索/语音/视频等)。
同时你要知道它的“天花板”也很高:
coze-coding-dev-sdk 是扣子的官方 SDK:用统一 TS/Python 接口,把扣子的 LLM/图像/语音/搜索/视频能力集成到外部应用,并通过环境变量自动鉴权。
(课堂先用界面学搭积木;真要上线,再把积木接到自己的项目里。)

06 本节作业:让扣子告诉你“你有哪些积木、能搭出什么产品”

作业:盘点你手里的 AI 积木,并用这些积木生成可落地的产品点子。
请打开「扣子编程」,复制这段,开始和它对话
Plain Text
我是小白,你尽量用简单的话向我解释。
我听说,你已经内置了 coze-coding-dev-sdk  ,这为我们提供了哪些AI能力?
我们可以用这些AI能力,用刘小排老师讲的‘积木思维’,搭出哪些有趣的AI产品?
请你最后用两段清单总结:
1)我有哪些AI能力积木(按:大脑积木/感官积木/外部积木)
2)给我10个产品点子,每个点子写清楚:用到哪几块积木 + 3步 MVP。
对话之后,我相信你能得到一些启发,知道自己接下来可以玩些什么好玩的😄!
准备好了吗?
当你问完以后,请马上进入下一课!让我们动手试试!

六、马上开始!动手开发第一个AI产品:互联网黑话翻译器

01 前言

终于来到了激动人心的第一课!马上你就会有第一个AI产品了。
这节课结束后,你会拥有一个可以分享给朋友的AI产品。整个过程大约30分钟。
💡
提醒:
1.
一定要看完上一节内容,再来这里。如果忘记上一节了,先回去复习。
2.
这是实操练习课,知识点并不多,但是需要你反复花时间练习、然后搞懂其中的原理

02 构思SPEC Prompt

还记得之前的课程内容,如何跟AI讨论需求吗? 请使用那一节课的方法,完成SPEC。
你可以参考我的。不过,我建议你自己写
因为,构造SPEC Prompt的过程,才是本节课的核心!(复制和粘贴并不是)
打开扣子编程 ,粘贴进去
Markdown
我们要做一个网页版的「互联网黑话翻译器」。

## 问题陈述
互联网/职场中充斥大量黑话套话,听起来很专业,实际上什么都没说清楚。用户需要一个工具,把黑话翻译成具体、可执行的人话。

## 方案描述
用户输入一段黑话,你输出以下五部分:
1)人话翻译(50-300字,具体到谁做什么、什么时候、交付什么)
2)真实意图(1-2句,点破背后真正要你做的事)
3)需要追问的信息(1-3条,原文没说清的地方;如果已清晰则写"无需追问")
4)回复模板(三个语气各一句:礼貌版 / 强硬版 / 阴阳怪气版)
5) 知识点讲解:输入的原始黑话的个别词汇,分别是什么意思?背后有什么典故?做出知识卡片

## 技术约束
- 全程中文
- 翻译结果中禁止出现任何黑话(赋能、抓手、闭环、对齐、拉通、沉淀、打法、颗粒度、底层逻辑、方法论、心智、链路、飞轮、降维打击等)
- 语气:犀利友好,像一个看透一切但不骂人的聪明同事
- 技术栈: 使用Next.js ; 我们需要的AI能力,全部用扣子编程沙箱环境自带的。

## 明确不做的事
- 不做英文翻译
- 不做长篇分析报告
- 不评价用户的公司或领导
- 不输出原文的同义替换(要翻译成具体动作,不是换一种说法)

## 成功标准
- 用户读完「人话翻译」后,立刻知道自己该做什么
- 回复模板可以直接复制发出去
- 全文无任何黑话
在扣子编程中输入这段Prompt即可。
下面的效果演示

03 打磨产品体验

前面我们练习过打磨产品的过程了。这里请你继续练习。
你可以试试
1.
让产品体验变得更好 (请自行设计产品的界面布局)
2.
输出内容更加易读(比如,“把Markdown输出全部呈现为卡片形式 ”)
我简单调整了一下,现在是这样的。
你的长什么样?😄
功能OK了,但现在它看起来还像个毛坯房。接下来我们给它装修。

04 给产品装修

注意这里,扣子编程是自带AI生图能力的。
也就是说:我们可以让扣子编程,帮我们生成一些产品需要的图片,包括Logo、icon、装饰性图片、示例等等。
在接下来的“给产品进行装修”任务当中,我们可以刻意强调“生成图片、补充图片”。
下面是我的,你可以参考
Plain Text
接下来,我们进行产品装修任务。

你需要
1. 首页变成一个完善的产品首页,自行补充功能介绍、示例用法,设计风格要看着像是苹果公司设计的产品
2. 通过生图功能,生成Logo、示例图片、icon等等,你需要结合产品功能来设计每一张图片。
3. 整体配色要保持一致性风格。不允许用紫色。
4. 反复测试,确保图片嵌入正确。
经过几次沟通后,现在我的产品长这样。
是不是看着就正规了很多?

05 理解原理:刚才发生了什么?

恭喜你拥有了第一个AI产品。现在我们来搞懂,刚才这一切到底是怎么运转的。
第一步:你输入了 SPEC , 谁写了代码?
你写了一段自然语言的 SPEC,发送给扣子编程。
然后扣子编程背后发生了这些事:
所以:写代码的人是 LLM,不是你,也不是某个程序员。
你的 SPEC 就是 LLM 的"工作指令"。
第二步:代码写完了 → 跑在哪里?
代码不是跑在你自己的电脑上
"沙箱服务器"你可以理解为:扣子帮你租了一台云上的电脑,专门运行你这个项目。
你不需要自己买服务器、不需要配置环境,扣子编程全包了。
第三步:用户输入黑话 → 谁在翻译?
当用户打开你的产品、输入一段黑话、点击"翻译",背后发生了什么?
注意这里有两次调用 LLM:
- 第一次:扣子编程用 LLM 帮你写代码(开发阶段)
- 第二次:你的产品用 LLM 帮用户翻译黑话(运行阶段)
这是两件完全不同的事。搞清楚这个区别,你就比 90% 的人更懂 AI 产品了。
第四步:装修环节 → 谁生成了图片?图片放在哪?
你让扣子编程生成 Logo、icon、示例图片。背后发生了:
所以图片不是存在你电脑上的,它存在扣子的云端存储里,通过链接加载到网页上。
为什么扣子编程可以生成图片?
因为扣子编程内置了 coze-coding-dev-sdk,这个 SDK 集成了多种 AI 能力:
你不需要自己去注册这些服务,扣子编程已经帮你接好了。
这就是我们上节课讲的"预制菜超市"——食材包都在货架上,你直接拿来用。
用户使用产品时的数据流
当你的朋友打开你的产品链接、输入一段黑话、看到翻译结果,数据经过了这些地方:
简单说就是一个来回:
注意几个关键点:
- 你的系统提示词一直存在服务器上,用户看不到。它就像后厨的菜谱——客人只看到上桌的菜,看不到菜谱。
- 每次翻译都是独立的。LLM不会记住上一个用户翻译了什么。就像每位客人点菜都重新做,不会把上一桌的剩菜端给你。
- 用户的数据不会存下来。黑话进去、翻译出来,过程结束,没有人保存你输入了什么。(除非你未来主动加上数据库功能。)
完整流程图:从 SPEC 到产品上线
现在你知道了:你刚才用到了两块积木(LLM + 图像生成),它们各司其职,组合在一起就是你的产品。
下一课,我们会加入第三块积木:语音(TTS)。你会听到你的AI产品"开口说话"。

06 作业

部署第一款AI产品,发给你的朋友用!
根据朋友的意见(主要看负面意见),继续打磨产品,直到你好意思发朋友圈炫耀你的产品 😄

七、难度升级!第二个AI产品:哄哄模拟器(代入感增强版)

01 前言

上一课你用1块积木(LLM)做出了互联网黑话翻译器。这一课,我们加1块积木:TTS语音
做完后,你的AI产品会"开口说话"——你能听到虚拟对象用生气的语气对你说话。

02 这次有什么不同?

第一个产品(黑话翻译器)
第二个产品(哄哄模拟器)
积木数量
1块(LLM)
2块(LLM + TTS)
用户交互
输入文字 → 看结果
选择选项 → 看+听结果
产品形态
工具
游戏
体验
能用
能玩 + 能听

Section 1:自己写一份"粗糙版"SPEC

上一课你参考了老师的 SPEC。这一课,你要自己先写一份
你已经知道哄哄模拟器大概是什么了:AI扮演正在生气的对象,你要在有限轮次内把对方哄好。
如果你不知道哄哄模拟器是啥,可以随便找个AI问问。
现在请你按照第3节学过的五条检查清单,自己写一份SPEC草稿:
1.
问题陈述
2.
方案描述
3.
技术约束
4.
明确不做的事
5.
成功标准
不用完美,写出你能想到的就行。 给自己5-10分钟。

Section 2:让AI帮你打磨SPEC

你的草稿写好了?先别急着粘贴到扣子编程。
还记得第3节课讲的"苏格拉底式提问"吗?现在我们用起来。
打开扣子编程,把下面这段话 + 你写的草稿SPEC,一起发给它:
Plain Text
你是一个产品需求教练。我会给你一份产品 SPEC(草稿),请你不要直接帮我改写,而是通过提问的方式帮我完善它。

请你逐条检查以下五个维度,每个维度问我1-2个关键问题:
1. 问题陈述:我的用户是谁?他们的痛点够具体吗?
2. 方案描述:核心玩法清楚吗?有没有遗漏的关键环节?
3. 技术约束:有没有我没想到的限制?
4. 明确不做的事:有没有容易跑偏的方向我忘记排除了?
5. 成功标准:用户做完之后,怎样才算"成功"?标准够具体吗?

一次只问一个维度,等我回答后再问下一个。

这是我的SPEC草稿:
[把你写的草稿粘贴在这里]
经过几轮对话后,你的SPEC会被打磨得更完整。
这个过程本身就是最重要的练习。 你在学习如何把一个模糊的想法,变成一份可执行的产品文档。

Section 3:参考SPEC

和AI对话完后,你可以对照下面这份参考SPEC,看看自己有没有遗漏的地方。
如果你自己打磨的版本已经足够完整,可以直接用你自己的版本!
这是我的原始版本:
Markdown
## 问题陈述
情侣吵架后不知道怎么哄对方,是普遍痛点。我们做一个「哄哄模拟器」:AI扮演正在生气的对象,用户通过选择题的方式回应,在10轮内把对方哄好。选项有好有坏,减分选项要搞笑,让人玩完想分享。

## 方案描述

### 游戏流程
1. 用户选择对方性别(女朋友/男朋友)
2. 用户从预设场景中选一个,进入游戏
3. AI生成对方说的第一句话 + 6个回复选项
4. 用户选一个选项,AI根据选择动态生成下一轮对话 + 新的6个选项
5. 如此循环,直到游戏结束

### 预设场景
1. 忘记纪念日 —— 今天是你们在一起三周年,你完全忘了
2. 深夜不回消息 —— 你昨晚打游戏到凌晨三点,对方发了十几条消息你都没回
3. 被发现和异性聊天 —— 对方看到你和异性朋友的暧昧聊天记录
4. 把对方的猫弄丢了 —— 你帮对方照顾猫的时候,猫跑丢了
5. 当众让对方没面子 —— 你在朋友聚会上开了一个过分的玩笑

### 好感度系统
- 初始值:20分(满分100,最低-50)
- 胜利条件:10轮内好感度 >= 80
- 失败条件:好感度降到 -50 以下,或10轮用完好感度仍 < 80
- 分值对用户隐藏具体加减数字,只展示当前总分和进度条
- 不要通过任何方式提示用户不同选项的潜在影响

### 选项设计(每轮6个)
- 2个加分选项(+5到+20,真诚道歉/具体弥补方案/提起共同回忆等)
- 4个减分选项(-5到-30),其中:
  - 1-2个是普通减分(敷衍、转移话题、找借口)
  - 2-3个是奇葩搞笑选项(离谱到好笑,例如"要不我给你跳一段?"、"我错了,但你也有错啊你不应该生气"、"我请你吃肯德基疯狂星期四行不行")
- 选项顺序随机打乱,不要把加分项固定在某个位置
- 选项如果超过一行,需要换行显示

### 动态生成规则
- 不预设题库,每一轮都通过LLM动态生成
- 对方说的话必须和前面的对话连贯,模拟同一段连续对话
- 不能出现重复的题目和选项
- 对方的情绪要根据好感度自然变化:
  - -50到0:非常生气,冷暴力或激烈质问
  - 0到30:还在生气,但愿意听你说
  - 30到60:开始软化,嘴上生气但语气缓和
  - 60到80:快被哄好了,可能撒娇或小声说"哼"
  - 80以上:原谅了,但还要你保证不再犯

### 界面要求
- 像微信私聊界面:对方的话在左侧,用户选择的话在右侧
- 对话双方需要有头像(用SVG模拟,对方用可爱卡通头像,用户用简单头像)
- 顶部显示:好感度进度条 + 当前轮次(如 第3轮/共10轮)
- 好感度变化时有动画效果(加分绿色上升,减分红色下降)
- 适配电脑和手机浏览器,响应式布局

### 语音功能(TTS)
- 对方的每一轮回复自动生成语音,页面上有播放按钮
- 使用扣子编程内置的 TTS 能力
- 游戏开始前让用户选择对方的声音类型(温柔女声/霸道御姐/可爱软妹/低沉男声/温柔男声)
- 语音要体现情绪变化

### 游戏结束
- 成功:撒花动画 + 对方说一句甜蜜的话 + 语音播放 + "通关!分享给朋友试试?"
- 失败:心碎动画 + 对方说一句绝情的话 + 语音播放 + "再试一次?"

### 文风
俏皮、搞笑、给人轻松感。对方生气时也要带点可爱,不要真的让人不舒服。

## 技术约束
- 全程中文
- 技术栈:使用 Next.js
- AI能力:全部用扣子编程沙箱环境自带的(LLM对话 + TTS语音)
- 好感度由LLM在每轮回复中明确给出数值变化,前端负责计算和展示
- 尽可能增加动效

## 明确不做的事
- 不做自由文本输入(只用选择题)
- 不做用户注册登录
- 不做数据持久化(刷新页面重新开始)
- 不做NSFW内容
- 不做多人对战
- 不预设题库(全部动态生成)

## 成功标准
- 选完场景后立刻开始,无加载等待
- 每轮6个选项,2好4坏,坏选项里有让人笑出来的
- 对方的回复有情绪层次,和前面对话连贯
- 每轮对方的回复能播放语音
- 好感度变化有动画反馈
- 玩完后用户想截图发朋友圈或者分享链接让朋友也试试
这是我和扣子编程讨论打磨后的版本:
💡
注意:因为我是和扣子编程讨论的,扣子编程完全知道自己内置AI的能力,因此,讨论出来的SPEC多了很多技术细节,这一点非常好。
Plain Text
# 哄哄模拟器 - 项目规格说明书


---

## 1. 项目概述

### 1.1 产品定位

情侣互动游戏:AI 扮演生气的对象,用户通过选择题的方式在 10 轮内把对方哄好。

### 1.2 核心特性

- **动态对话生成**: 每轮对话和选项都由 LLM 实时生成,无预设题库
- **情绪化语音**: 使用 TTS 自动生成语音,体现情绪变化
- **趣味减分选项**: 包含搞笑、离谱的选项,增强分享欲
- **好感度系统**: 隐藏数值,通过进度条展示

### 1.3 游戏流程

```
开始界面 → 选择性别/场景/语音 → 游戏主界面 → 10轮互动 → 结束界面
```

---

## 2. 技术栈

### 2.1 核心框架

- **框架**: Next.js 16 (App Router)
- **语言**: TypeScript 5
- **运行时**: Node.js 24

### 2.2 前端技术

- **UI 框架**: React 19
- **样式**: Tailwind CSS 4
- **组件库**: shadcn/ui (Radix UI)
- **图标**: Lucide React

### 2.3 AI 集成

- **LLM**: coze-coding-dev-sdk (对话生成)
- **TTS**: coze-coding-dev-sdk (语音合成)

### 2.4 状态管理

- **方案**: React Context API
- **全局状态**: GameContext

### 2.5 开发工具

- **包管理器**: pnpm (强制要求)
- **初始化工具**: Coze CLI
- **代码规范**: Airbnb Style Guide

---

## 3. 功能需求

### 3.1 开始界面

#### 功能要求
- 选择对方性别(女/男)
- 选择预设场景(5个)
- 选择语音类型(根据性别动态显示)

#### 预设场景列表

| ID | 标题 | 描述 |
|---|---|---|
| anniversary | 忘记纪念日 | 今天是你们在一起三周年,你完全忘了... |
| late-night | 深夜不回消息 | 你昨晚打游戏到凌晨三点,对方发了十几条消息你都没回... |
| flirty-chat | 被发现和异性聊天 | 对方看到你和异性朋友的暧昧聊天记录... |
| lost-cat | 把对方的猫弄丢了 | 你帮对方照顾猫的时候,猫跑丢了... |
| public-joke | 当众让对方没面子 | 你在朋友聚会上开了一个过分的玩笑... |

#### 语音配置

| VoiceType | Speaker | Label | 适用性别 |
|-----------|---------|-------|---------|
| gentle-female | zh_female_xiaohe_uranus_bigtts | 温柔女声 | 女 |
| cool-female | zh_female_vv_uranus_bigtts | 霸道御姐 | 女 |
| cute-female | saturn_zh_female_keainvsheng_tob | 可爱软妹 | 女 |
| deep-male | zh_male_m191_uranus_bigtts | 低沉男声 | 男 |
| gentle-male | zh_male_taocheng_uranus_bigtts | 温柔男声 | 男 |

### 3.2 游戏主界面

#### 功能要求
- 对话气泡显示(对方左侧,用户右侧)
- 好感度进度条(顶部)
- 当前轮次显示(第 X 轮 / 共 10 轮)
- 6个选项按钮(支持换行)
- 语音播放按钮(仅对方消息)
- 加载动画(生成时显示)
- 错误提示和重试功能

#### 好感度规则

- **初始值**: 20
- **范围**: -50 ~ 100
- **胜利条件**: 10轮内好感度 >= 80
- **失败条件**: 好感度 < -50 或 10轮用完好感度 < 80
- **展示**: 隐藏具体数值,只显示进度条

#### 选项生成规则

每轮生成 6 个选项:
- **加分选项**: 2个(+5 到 +20)
  - 真诚道歉
  - 具体弥补方案
  - 提起共同回忆
- **减分选项**: 4个(-5 到 -30)
  - 普通减分(1-2个):敷衍、转移话题、找借口
  - 奇葩搞笑选项(2-3个):离谱到好笑

**要求**:
- 选项顺序随机打乱
- 支持换行显示
- **不提示用户选项的好坏**

#### 对话生成规则

- 与前面的对话连贯,模拟连续对话
- 不出现重复的题目和选项
- 情绪根据好感度变化:

| 好感度范围 | 情绪表现 |
|-----------|---------|
| -50 ~ 0 | 非常生气,冷暴力或激烈质问 |
| 0 ~ 30 | 还在生气,但愿意听你说 |
| 30 ~ 60 | 开始软化,嘴上生气但语气缓和 |
| 60 ~ 80 | 快被哄好了,可能撒娇或小声说"哼" |
| 80+ | 原谅了,但还要你保证不再犯 |

### 3.3 结束界面

#### 成功
- 撒花动画
- 甜蜜的结束对话
- 语音播放
- "通关!分享给朋友试试?"
- 重玩按钮

#### 失败
- 心碎动画
- 绝情的结束对话
- 语音播放
- "再试一次?"
- 重玩按钮

---

## 4. 数据结构设计

### 4.1 类型定义 (`src/types/game.ts`)

```typescript
// 性别
export type Gender = 'female' | 'male';

// 语音类型
export type VoiceType = 'gentle-female' | 'cool-female' | 'cute-female' | 'deep-male' | 'gentle-male';

// 场景
export interface Scenario {
  id: string;
  title: string;
  description: string;
}

// 消息
export interface Message {
  role: 'user' | 'partner';
  content: string;
}

// 选项
export interface Option {
  id: string;
  content: string;
  score: number; // 好感度变化值
}

// 游戏状态
export interface GameState {
  step: number;              // 当前轮次 (1-10)
  affection: number;         // 好感度 (-50 到 100)
  gender: Gender | null;     // 对方性别
  scenario: Scenario | null; // 当前场景
  voiceType: VoiceType | null; // 语音类型
  messages: Message[];       // 对话历史
  currentOptions: Option[];  // 当前选项
  gameOver: boolean;         // 游戏是否结束
  won: boolean;              // 是否获胜
}

// 常量
export const INITIAL_AFFECTION = 20;
export const MAX_AFFECTION = 100;
export const MIN_AFFECTION = -50;
export const WIN_AFFECTION = 80;
export const MAX_ROUNDS = 10;
```

### 4.2 Context 结构 (`src/context/GameContext.tsx`)

```typescript
interface GameContextType {
  gameState: GameState;
  setGender: (gender: Gender) => void;
  setScenario: (scenario: Scenario) => void;
  setVoiceType: (voiceType: VoiceType) => void;
  startGame: () => void;
  selectOption: (option: Option) => void;
  resetGame: () => void;
  addPartnerMessage: (content: string, options: Option[]) => void;
}
```

---

## 5. API 接口设计

### 5.1 对话生成接口

**路径**: `POST /api/chat`

**请求体**:
```typescript
{
  gender: Gender;           // 对方性别
  scenario: string;         // 场景标题
  messages: Message[];      // 对话历史(包含所有消息)
  affection: number;        // 当前好感度
  step: number;             // 当前轮次
  isGameOver: boolean;      // 是否游戏结束
  won: boolean;             // 是否获胜
}
```

**响应体**:
```typescript
{
  partnerMessage: string;   // 对方的回复
  options: Option[];        // 6个选项
}
```

**⚠️ 关键实现要点**:

1. **对话历史必须包含所有消息**:
   ```typescript
   // ✅ 正确:包含所有消息
   const chatHistory = messages.map(msg => ({
     role: msg.role === 'partner' ? 'assistant' : 'user',
     content: msg.content,
   }));

   // ❌ 错误:过滤掉 user 消息,会导致对话重复
   const chatHistory = messages
     .filter(m => m.role === 'partner')
     .map(m => ({ role: 'assistant', content: m.content }));
   ```

2. **Prompt 设计**:
   - 要求 LLM 根据好感度调整情绪
   - 确保每轮生成 6 个选项
   - 要求选项中有搞笑内容
   - 要求对话连贯不重复

3. **错误处理**:
   - 超时时间:30秒
   - 失败降级:返回预设的默认对话和选项

### 5.2 语音合成接口

**路径**: `POST /api/tts`

**请求体**:
```typescript
{
  text: string;      // 要朗读的文本
  speaker: string;   // 语音ID
  uid: string;       // 用户ID(用于去重)
}
```

**响应体**:
```typescript
{
  audioUri: string;   // 音频文件URL
  audioSize: number;  // 音频大小
}
```

**⚠️ 关键实现要点**:

1. **文本清理**(必须):
   - 去掉括号里的动作描述和情绪提示
   - 支持 `()` `()` `[]` 等括号
   ```typescript
   const cleanTextForSpeech = (text: string): string => {
     return text
       .replace(/([^)]*)/g, '')  // 去掉中文括号
       .replace(/\([^)]*\)/g, '')   // 去掉英文括号
       .replace(/\[[^\]]*\]/g, '')  // 去掉中括号
       .replace(/[「」『』]/g, '')  // 去掉其他标点
       .trim();
   };
   ```

2. **超时处理**:
   - 超时时间:15秒
   - 失败不影响游戏继续

---

## 6. UI/UX 设计规范

### 6.1 布局设计

#### 开始界面
- 居中卡片布局
- 表单分组(性别、场景、语音)
- 渐变背景(粉紫色系)

#### 游戏主界面
- 顶部:好感度进度条 + 轮次显示
- 中间:对话区域(滚动)
- 底部:选项区域(固定)
- 背景渐变:pink-100 → purple-50 → blue-100

#### 结束界面
- 居中布局
- 大图标 + 标题 + 结束对话
- 重玩按钮

### 6.2 对话气泡设计

#### 对方消息(左侧)
- 背景色:白色
- 圆角:rounded-bl-md(左下直角)
- 头像:粉色圆形 + "TA"

#### 用户消息(右侧)
- 背景色:blue-500
- 文字色:白色
- 圆角:rounded-br-md(右下直角)
- 头像:蓝色圆形 + "我"

### 6.3 好感度进度条

- 背景:灰色
- 填充:根据好感度变色
  - 0以下:红色
  - 0-50:黄色
  - 50-80:蓝色
  - 80以上:绿色
- **⚠️ 使用原生 div 实现**,不要使用自定义 Progress 组件
  ```typescript
  // ✅ 正确:使用原生 div
  <div className="flex-1 bg-gray-200 rounded-full h-full overflow-hidden">
    <div
      className="h-full rounded-full transition-all duration-300"
      style={{
        width: `${(affection / 100) * 100}%`,
        backgroundColor: getColor(),
      }}
    />
  </div>

  // ❌ 错误:使用 Progress 组件可能导致显示问题
  <Progress value={(affection / 100) * 100} className="flex-1" />
  ```

### 6.4 加载动画

- 跳动爱心图标
- 动态文字:"她正在思考..." / "他正在思考..."
- 位置:对话区域底部

### 6.5 响应式设计

- 手机:单列布局
- 电脑:单列布局(最大宽度 800px)
- 选项按钮:自适应高度,支持换行

---

## 7. 关键实现逻辑

### 7.1 游戏状态管理

#### 初始化流程

```typescript
// 1. 用户选择性别、场景、语音
setGender('female');
setScenario(scenarios[0]);
setVoiceType('gentle-female');

// 2. 开始游戏
startGame();  // 生成第一条对话和选项

// 3. 用户选择选项
selectOption(option);  // 更新好感度,生成下一轮
```

#### ⚠️ 闭包陷阱修复

**问题**: `startGame` 函数中读取 `gameState.gender` 等值时,可能读取到旧值(闭包陷阱)。

**解决方案**: 使用函数式更新
```typescript
// ❌ 错误:可能读取旧值
const startGame = () => {
  const gender = gameState.gender;  // 可能为空
  const scenario = gameState.scenario;  // 可能为空
  // ...
};

// ✅ 正确:从最新状态读取
const startGame = () => {
  setGameState(prev => {
    const gender = prev.gender;
    const scenario = prev.scenario;
    const voiceType = prev.voiceType;

    if (!gender || !scenario || !voiceType) {
      console.error('Missing game config');
      return prev;
    }

    return {
      ...prev,
      step: 1,
      messages: [],
      gameOver: false,
      won: false,
    };
  });
};
```

### 7.2 语音生成逻辑

#### ⚠️ 语音更新问题修复

**问题**: 第一轮对话后 `audioUri` 被设置,第二轮对话时 `audioUri` 仍然存在,不会生成新语音。

**解决方案**: 跟踪消息 ID,每轮生成新语音

```typescript
// 1. 为每条消息生成唯一 ID
const messageId = `${lastPartnerMessage.role}-${lastPartnerMessage.content}-${partnerMessageCount}`;

// 2. 检测新消息
if (currentAudioMessageId !== messageId && gameState.voiceType) {
  // 清除旧语音
  setAudioUri(undefined);
  setCurrentAudioMessageId(messageId);

  // 生成新语音
  const cleanText = cleanTextForSpeech(lastPartnerMessage.content);
  // ... 调用 TTS API
}

// 3. 用户选择选项时重置
const handleSelectOption = async (option: Option) => {
  setAudioUri(undefined);
  setCurrentAudioMessageId(null);  // 重置当前语音消息ID
  selectOption(option);
};
```

### 7.3 防重复生成

**问题**: 用户快速点击选项可能触发多次 API 请求。

**解决方案**: 使用 `useRef` 跟踪生成状态

```typescript
const isGeneratingRef = useRef(false);

const generateNextRound = async () => {
  // 防止重复生成
  if (isGeneratingRef.current || isLoading) {
    return;
  }

  isGeneratingRef.current = true;

  try {
    // ... API 调用
  } finally {
    isGeneratingRef.current = false;
  }
};
```

### 7.4 useEffect 依赖管理

**问题**: `useEffect` 依赖数组不正确导致无限循环或不触发。

**解决方案**: 精确控制依赖

```typescript
// ✅ 对话生成
useEffect(() => {
  generateNextRound();
}, [
  gameState.step,                    // 轮次变化时生成
  gameState.currentOptions.length,   // 选项为空时生成
  gameState.gameOver,                // 游戏结束时不生成
  lastGeneratedStep,                 // 避免重复生成同一轮
]);

// ✅ 语音生成
useEffect(() => {
  // ... 语音生成逻辑
}, [
  gameState.messages,                // 消息变化时生成
  gameState.voiceType,               // 语音类型变化时生成
  currentAudioMessageId,             // 检测新消息
]);
```

---

## 8. 开发规范

### 8.1 项目初始化

**必须使用 Coze CLI**:

```bash
# 初始化 Next.js 项目
coze init ${COZE_WORKSPACE_PATH} --template nextjs

# 工作目录
cd /workspace/projects
```

**⚠️ 禁止**:
- 禁止使用 `npm create` 或 `pnpm create`
- 禁止使用其他初始化方式

### 8.2 包管理

**强制使用 pnpm**:

```bash
# 安装依赖
pnpm install

# 添加依赖
pnpm add <package>

# 添加开发依赖
pnpm add -D <package>

# 移除依赖
pnpm remove <package>
```

**⚠️ 禁止**:
- 禁止使用 `npm` 或 `yarn`

### 8.3 项目运行

**开发环境**:
```bash
coze dev  # 默认端口 5000,支持 HMR
```

**生产环境**:
```bash
coze build
coze start
```

**⚠️ 注意**:
- 开发环境运行在 5000 端口
- 修改代码自动触发热更新(HMR)
- 不需要手动重启服务

### 8.4 .coze 配置文件

**初始化后无需修改**(模板已预置完美配置):

```toml
[project]
requires = ["nodejs-24"]

[dev]
build = ["pnpm", "install"]
run = ["pnpm", "run", "dev"]

[deploy]
build = ["pnpm", "run", "build"]
run = ["pnpm", "run", "start"]
```

### 8.5 目录结构

```
src/
├── app/
│   ├── api/
│   │   ├── chat/
│   │   │   └── route.ts       # 对话生成 API
│   │   └── tts/
│   │       └── route.ts       # 语音合成 API
│   ├── layout.tsx             # 全局布局
│   └── page.tsx               # 主页面
├── components/
│   ├── ui/                    # shadcn/ui 组件(预置)
│   ├── StartScreen.tsx        # 开始界面
│   ├── GameScreen.tsx         # 游戏主界面
│   ├── GameOverScreen.tsx     # 结束界面
│   ├── AffectionBar.tsx       # 好感度进度条
│   └── LoadingAnimation.tsx   # 加载动画
├── context/
│   └── GameContext.tsx        # 游戏状态管理
├── types/
│   └── game.ts                # 类型定义
└── tests/
    ├── logic.test.ts          # 逻辑测试
    ├── api.test.ts            # API 测试
    └── ...
```

### 8.6 代码规范

**命名规范**:
- 组件:PascalCase (`GameScreen.tsx`)
- 函数:camelCase (`handleSelectOption`)
- 常量:UPPER_SNAKE_CASE (`MAX_ROUNDS`)
- 类型:PascalCase (`GameState`, `Message`)

**注释规范**:
- 复杂逻辑必须添加注释
- 注释说明"为什么"而不是"是什么"
- 关键修复添加 `// ⚠️ 关键实现要点` 标记

**错误处理**:
- 所有 API 调用必须 try-catch
- 错误信息必须打印到 console
- 必须提供降级方案(默认值或重试)

---

## 9. 常见问题与解决方案

### 9.1 点击"开始游戏"无反应

**症状**: 点击按钮后没有任何反应。

**原因**: `GameContext` 的 `startGame` 函数存在闭包陷阱,读取到空的 `gameState.gender` 等。

**解决方案**:
```typescript
// 使用函数式更新
const startGame = () => {
  setGameState(prev => {
    // 从 prev 读取最新值
    const gender = prev.gender;
    const scenario = prev.scenario;
    const voiceType = prev.voiceType;

    if (!gender || !scenario || !voiceType) {
      console.error('Missing game config');
      return prev;
    }

    return {
      ...prev,
      step: 1,
      messages: [],
      gameOver: false,
      won: false,
    };
  });
};
```

### 9.2 对话重复

**症状**: 对方每次说的话都是一样的。

**原因**: `/api/chat` 接口在构建对话历史时过滤掉了用户的消息,导致 LLM 只能看到 partner 的消息。

**解决方案**:
```typescript
// ✅ 正确:包含所有消息
const chatHistory = messages.map(msg => ({
  role: msg.role === 'partner' ? 'assistant' : 'user',
  content: msg.content,
}));
```

### 9.3 进度条不显示

**症状**: 顶部进度条没走,进度条里也没显示。

**原因**: 使用自定义 Progress 组件可能存在样式冲突或渲染问题。

**解决方案**: 使用原生 div 实现进度条
```typescript
<div className="flex-1 bg-gray-200 rounded-full h-full overflow-hidden">
  <div
    className="h-full rounded-full transition-all duration-300"
    style={{
      width: `${(affection / 100) * 100}%`,
      backgroundColor: getColor(),
    }}
  />
</div>
```

### 9.4 语音未更新

**症状**: 第二次说的语音是第一次的语音。

**原因**: 语音生成的条件是 `!audioUri`,第一轮后 `audioUri` 被设置,第二轮不会生成新语音。

**解决方案**: 跟踪消息 ID
```typescript
const [currentAudioMessageId, setCurrentAudioMessageId] = useState<string | null>(null);

// 为每条消息生成唯一 ID
const messageId = `${lastPartnerMessage.role}-${lastPartnerMessage.content}-${partnerMessageCount}`;

// 检测新消息
if (currentAudioMessageId !== messageId && gameState.voiceType) {
  setAudioUri(undefined);
  setCurrentAudioMessageId(messageId);
  // ... 生成新语音
}
```

### 9.5 语音念括号内容

**症状**: 语音会念出 `(吸吸鼻子,语气软下来)` 等括号里的动作描述。

**原因**: 直接将包含括号的文本发送给 TTS。

**解决方案**: 清理文本
```typescript
const cleanTextForSpeech = (text: string): string => {
  return text
    .replace(/([^)]*)/g, '')  // 去掉中文括号
    .replace(/\([^)]*\)/g, '')   // 去掉英文括号
    .replace(/\[[^\]]*\]/g, '')  // 去掉中括号
    .replace(/[「」『』]/g, '')  // 去掉其他标点
    .trim();
};

// 调用 TTS 时使用清理后的文本
const cleanText = cleanTextForSpeech(lastPartnerMessage.content);
```

### 9.6 选择选项后卡住

**症状**: 选择选项后页面一直显示"正在思考..."。

**原因**:
1. 防重复生成逻辑不完善
2. useEffect 依赖数组不正确
3. API 请求超时

**解决方案**:
1. 添加 `isGeneratingRef` 防止重复请求
2. 优化 `useEffect` 依赖数组
3. 添加超时处理和错误重试

---

## 10. 测试要求

### 10.1 单元测试

**测试文件位置**: `src/tests/`

**必需测试**:

1. **逻辑测试** (`logic.test.ts`):
   - 好感度计算
   - 游戏胜负判定
   - 轮次递增

2. **API 测试** (`api.test.ts`):
   - `/api/chat` 接口调用
   - `/api/tts` 接口调用
   - 错误处理

3. **语音更新测试** (`voice-update.test.ts`):
   - 第一条消息触发语音生成
   - 同一条消息不重复生成
   - 新消息触发语音更新
   - 连续多轮对话每轮都有唯一语音ID

4. **文本清理测试** (`clean-text.test.ts`):
   - 中文括号内容被去除
   - 英文括号内容被去除
   - 中括号内容被去除
   - 多个括号都能正确处理

### 10.2 集成测试

**测试流程**:
1. 初始化项目
2. 启动开发服务 (`coze dev`)
3. 检查 5000 端口存活
4. 完整游戏流程测试:
   - 选择性别/场景/语音
   - 完成 10 轮对话
   - 检查好感度变化
   - 检查语音播放
   - 检查结束界面

### 10.3 构建测试

**必需执行**:
```bash
# 类型检查
npx tsc --noEmit

# 构建检查
pnpm run build
```

**⚠️ 禁止**: 绝不允许交付 Build Failed 的代码

### 10.4 接口冒烟测试

**必需测试**:
```bash
# 测试对话生成接口
curl -X POST -H "Content-Type: application/json" \
  -d '{"gender":"female","scenario":"忘记纪念日","messages":[],"affection":20,"step":1,"isGameOver":false,"won":false}' \
  http://localhost:5000/api/chat

# 测试语音合成接口
curl -X POST -H "Content-Type: application/json" \
  -d '{"text":"你好","speaker":"zh_female_xiaohe_uranus_bigtts","uid":"test"}' \
  http://localhost:5000/api/tts
```

### 10.5 端口检测

**推荐做法**:
```bash
# 检查 5000 端口是否存活
curl -I --max-time 3 http://localhost:5000

# 检查 5000 端口的进程PID
ss -lptn 'sport = :5000'
```

**禁止做法**:
```bash
# ❌ 禁止:会检测出所有包含 5000 的连接
lsof -i:5000

# ❌ 禁止:可能误检出 50001 端口
netstat -tunlp | grep 5000
```

---

## 11. 附录

### 11.1 环境变量

- `COZE_WORKSPACE_PATH`: 项目工作目录(默认 `/workspace/projects/`)

### 11.2 关键常量

```typescript
export const INITIAL_AFFECTION = 20;
export const MAX_AFFECTION = 100;
export const MIN_AFFECTION = -50;
export const WIN_AFFECTION = 80;
export const MAX_ROUNDS = 10;
```

### 11.3 超时设置

- LLM 请求:30秒
- TTS 请求:15秒

### 11.4 日志目录

- `/app/work/logs/bypass/app.log`: 主流程日志
- `/app/work/logs/bypass/dev.log`: 调试日志
- `/app/work/logs/bypass/console.log`: 浏览器控制台日志

### 11.5 相关文档

- [Bug 修复记录](./BUGFIXES.md)
- [原始需求文档](./GAME_REQUIREMENTS.md)
- [开发规范](./DEVELOPMENT_GUIDELINES.md)

---



---

**文档维护**: 本文档应与代码同步更新,确保每次修改都有对应的文档记录。

Section 4:在扣子编程中生成产品

把你的SPEC(自己打磨的版本或参考版本)粘贴到扣子编程,生成产品。
💡
特别提醒:本次需求SPEC比较复杂,国产模型可能不容易一次做对
不过没关系:每次遇到出错,你可以描述错误,继续让扣子编程修复。只要需求说得清楚,最终肯定能做好的。
遇到表现不符合预期的时候,不要着急,请当成是一个邀请:邀请你练习描述需求、排查问题
第一次生成的效果演示:
看录屏吧(记得打开声音! 里面女朋友说的话,是有声音的)
link20260211175937_rec_.mp4【在线播放】
怎么样,还不错吧?

Section 5:打磨产品体验 & 给产品装修

这一次你需要重点打磨的:
1. 选项体验:6个选项的排列是否清晰?点击后的反馈是否流畅?
2. 语音效果:试听不同的声音类型,选一个最合适的
3. 好感度动画:加分减分时的动画是否明显?
4. 对话连贯性:多玩几轮,看AI的回复是否和前面对话衔接自然
5. 搞笑选项:减分选项够不够好笑?不好笑就让AI重新生成
6. 难度:难度可以调高吗?或者调低?
装修方面:
1.
交互风格:你希望它更像一款游戏?还是更像微信等聊天工具?
2.
对话形式:你希望是只发语音吗?还是文字语音一起发?
3.
首页:首页应该长什么样?直接模拟微信消息列表如何?或者,做成功能介绍页?
你可以这样跟扣子编程说:
"减分选项不够搞笑,我要那种让人忍不住想选、选完又后悔的选项。
另外,整个界面交互,我希望模拟微信的界面,对话的时候,就像是在真实的微信里一样"
然后立即变成了微信风

Section 6:理解原理——这次多了什么?

上节课你学会了一个完整的数据流:用户输入 → 服务器 → LLM → 服务器 → 用户看到结果。
这节课,一切都没变,只是多了一条路
回顾:上节课的数据流(1块积木)
上节课的黑话翻译器,数据只走一条路:
Plain Text
用户浏览器 → 你的服务器 → LLM → 你的服务器 → 用户浏览器
  (输入)     (转发)    (思考)   (组装)     (看到结果)
简单,清晰,一条直线。
这节课新增了什么?
你的哄哄模拟器比黑话翻译器多了一个能力:对方的回复可以被"说出来"
这个"说出来"的能力,就是 TTS(Text-to-Speech,文字转语音)。
它是怎么工作的?其实非常简单:
拆开说就是五步:
1.
LLM 生成了对方的回复文字(比如"哼,你还知道回来?")
2.
你的产品代码拿到这段文字后,把它发送给扣子编程内置的 TTS API
3.
TTS API 把文字变成一段音频文件
4.
音频文件存到云端,生成一个音频链接(URL)
5.
页面上出现一个播放按钮,用户点击就能听到对方用生气的语气说这句话
注意:TTS 和 LLM 是两个完全不同的 API。LLM 负责"想"(生成文字),TTS 负责"说"(把文字变成声音)。它们各干各的,互不干扰。
完整数据流:两条路同时走
现在我们把完整的流程画出来。和上节课相比,唯一的区别是:产品代码拿到 LLM 的结果后,同时做了两件事
用文字描述这个分叉:
用户选了一个选项之后——
1.
产品代码把「用户的选项 + 前面的对话历史 + 系统提示词」打包发给 LLM
2.
LLM 返回三样东西:对方的回复、好感度变化、6个新选项
3. 产品代码收到结果后,同时走两条路
- 路线①(文字):把对方的回复显示在聊天界面上,更新好感度进度条,展示新的6个选项
- 路线②(语音):把对方的回复文字发给 TTS API → 生成音频 → 页面出现播放按钮
4. 用户既能看到对方说了什么,也能听到对方的语气
就这么简单。上节课是一条路,这节课是两条路同时走。
一个重要的问题:为什么语音让产品体验完全不同?
你可能觉得"加个语音"没什么大不了的。
但你回忆一下刚才玩哄哄模拟器的体验:当你听到对方用生气的语气说"你觉得一句对不起就够了吗?"的时候,是不是比只看到文字更有冲击力?
这就是"感官积木"的价值:
文字作用于视觉,是"看"
语音作用于听觉,是"听"
- 当用户同时"看到"和"听到",产品从"工具"变成了"体验"
你的黑话翻译器是工具——用户用完就走。
你的哄哄模拟器是体验——用户玩完想分享给朋友。
加一块积木,产品质感就升一级。这就是积木思维。
对比总结
黑话翻译器(上节课)
哄哄模拟器(本节课)
积木
1块:LLM
2块:LLM + TTS
数据流
1条路
2条路同时走
用户感知
看到结果
看到 + 听到
产品类型
工具
体验/游戏
传播性
截图分享
截图 + 语音 + 转发给朋友玩
下一课,我们再加一块积木:图像生成。你的AI产品不仅能说话,还能"发照片"。到时候你就拥有了一个三块积木的完整产品。

03 作业

1.
部署哄哄模拟器,发给你的朋友玩
2.
收集反馈:哪个场景最难哄?哪个搞笑选项最好笑?
3.
根据反馈继续打磨,直到你的朋友玩完主动转发给别人
提示:如果你的朋友玩完没有转发给别人,说明产品还不够好玩。继续打磨!😊

八、难度再次升级!从零打造"纸片人男友”并让你的闺蜜爱上他

01 前言

前两课你分别用了1块积木、2块积木做出了产品。这一课,我们集齐3块积木:LLM + TTS + 图像生成
做完后,你的AI产品不仅能聊天、能说话,还能"发自拍照片"。
提醒:
1.
一定要先完成前两节课的产品,再来这里。
2.
这是‘入门篇’中最后一个实操产品课,也是难度最高的一课。耐心跟完,你就拥有了一个完整的“Demo级AI产品”开发能力。

02 这次有什么不同?

黑话翻译器
哄哄模拟器
纸片人男友
积木数量
1块(LLM)
2块(LLM + TTS)
3块(LLM + TTS + 图像生成)
用户交互
输入→看
选择→看+听
聊天→看+听+看图
产品形态
工具
游戏
陪伴
新体验
能用
能玩+能听
能聊+能听+能看到他
三个产品,三次升级。每次只加一块积木,但体验完全不同。

Section 1:自己写一份"粗糙版"SPEC

你已经写过两次SPEC了。这一次,我不给你任何参考——完全自己写
你要做的产品是"纸片人男友":一个AI虚拟恋爱聊天产品。如果你不知道什么是纸片人男友,想想《恋与制作人》——有人设、有颜值、会跟你聊天、会给你发语音和照片的虚拟角色。
想清楚这些问题,然后写你的SPEC草稿:
1. 用户是谁? 谁会用这个产品?
2. 核心体验是什么? 用户打开产品后会做什么?
3. 角色设定怎么做? 虚拟男友是什么性格?说话什么风格?
4. 语音怎么用? 什么时候让他"说话"?
5. 照片怎么用? 什么时候让他"发照片"?这是这节课最大的新挑战。
6. 界面长什么样? 像微信聊天?像社交App?
按五条检查清单写:
1.
问题陈述
2.
方案描述
3.
技术约束
4.
明确不做的事
5.
成功标准
给自己10-15分钟。这次比前两次复杂,多花点时间没关系。
下面是一个简洁版SPEC的参考(建议你先自己写,写完再看):
Plain Text
## 问题陈述
很多人想体验虚拟恋爱聊天,市面上的AI聊天产品要么太机械,要么要付费。我们做一个免费的、有人设的「纸片人男友」聊天产品,让用户感觉在跟一个有性格的真人聊天。

## 方案描述
1. 用户从几个预设角色中选一个虚拟男友(每个角色有不同性格和外貌)
2. 进入微信风格的聊天界面,自由打字聊天
3. 虚拟男友会回复文字 + 自动生成语音消息(用户可以播放)
4. 聊天过程中,虚拟男友偶尔会主动发"自拍照片"(通过AI生图)
5. 没有轮次限制、没有输赢,就是聊天陪伴

## 技术约束
- 全程中文
- 技术栈:Next.js
- AI能力:全部用扣子编程自带的(LLM + TTS + 图像生成)
- 界面像微信聊天

## 明确不做的事
- 不做用户注册登录
- 不做数据持久化(刷新清空)
- 不做NSFW内容
- 不做多人聊天

## 成功标准
- 虚拟男友说话风格与人设一致
- 每条回复都能播放语音
- 聊天过程中能收到虚拟男友发的"照片"
- 闺蜜用完之后问你"这个男的是谁???"

Section 2:让AI帮你打磨SPEC

和上节课一样,把你的草稿 + 苏格拉底式提问Prompt一起发给扣子编程:
Plain Text
你是一个产品需求教练。我会给你一份产品 SPEC(草稿),请你不要直接帮我改写,而是通过提问的方式帮我完善它。

请你逐条检查以下五个维度,每个维度问我1-2个关键问题:
1. 问题陈述:我的用户是谁?他们的痛点够具体吗?
2. 方案描述:核心玩法清楚吗?有没有遗漏的关键环节?
3. 技术约束:有没有我没想到的限制?
4. 明确不做的事:有没有容易跑偏的方向我忘记排除了?
5. 成功标准:用户做完之后,怎样才算"成功"?标准够具体吗?

一次只问一个维度,等我回答后再问下一个。

另外请特别注意:这个产品用到3个AI能力(LLM对话 + TTS语音 + 图像生成),请帮我检查SPEC中是否把每个能力的使用场景和触发条件都写清楚了。

这是我的SPEC草稿:
[把你写的草稿粘贴在这里]
这一次打磨Prompt比上次多了一句:"请特别注意3个AI能力的使用场景和触发条件"。因为这次你用到了3块积木,每一块什么时候用、怎么触发,都需要在SPEC里写清楚。
经过几轮对话后,你会发现AI帮你补了很多你没想到的细节——比如"虚拟男友发照片的频率怎么控制?""照片里的人物怎么保持长相一致?"

Section 3:参考SPEC

和AI对话完后,你可以对照我的参考SPEC,看看自己有没有遗漏的地方。
这份SPEC比前两个产品更长、更复杂——因为你用了3块积木,需要描述的东西更多。
参考SPEC详见附件:
核心要点总结:
角色系统:
4个预设角色:温柔学长(林屿)、高冷总监(顾冽)、阳光大男孩(苏晨)、文艺音乐人(沈默)
每个角色有独立的:名字、性格、说话风格、声音、外貌描述、系统提示词
聊天界面:
微信私聊风格,自由文本输入(不是选择题)
三种消息类型:文字气泡、语音气泡(带播放按钮)、图片气泡(点击放大)
图片生成(新积木!):
角色在回复中用 [IMAGE: 图片描述] 标记来"发照片"
前端解析到这个标记后,调用图像生成API生成图片
图片描述必须包含角色的外貌特征(保持长相一致)
大约每3-5轮对话发一次图,不是每轮都发

Section 4:在扣子编程中生成产品

把你的SPEC粘贴到扣子编程,生成产品。
这次生成的过程会比前两次慢一些——因为产品更复杂了,代码量更大。耐心等待。

Section 5:打磨产品体验

这次需要重点打磨的:
1. 角色人设一致性:多聊几轮,看虚拟男友的说话风格是否始终和人设一致。如果他突然变得不像那个角色了,需要调整系统提示词。
2. 语音效果:听听语音是否和角色性格匹配。温柔学长应该说话轻柔,高冷总监应该声音低沉。
3. 照片触发:试着说"想看你"、"你在干嘛",看他是否会发照片。也要观察他是否会主动发照片。如果发图太频繁或者从不发图,需要调整。
4. 照片质量:照片里的人物是否和角色外貌描述一致?如果每次发的照片长得完全不同,需要在图片描述中强调角色的外貌特征。
5. 对话连贯性:告诉他你叫什么名字,过几轮再看他是否记住了。好的AI男友应该记住你说过的话。
你可以这样跟扣子编程说:
"虚拟男友发的照片里人物长相每次都不一样,请在图像生成的prompt中固定角色外貌描述:[把角色的外貌描述粘贴过来]"
"虚拟男友从来不主动发照片,请修改系统提示词,让他大约每3-5轮主动发一次自拍或日常照片"

Section 6:给产品装修

这次装修的重点和前两次不同:
1. 角色选择页面:每个角色卡片要好看,有头像、名字、一句话介绍。让用户一眼就想选一个。
2. 聊天界面:尽可能像微信,沉浸感要强
3. 图片消息的展示:点击能放大,加载中有占位动画
4. 整体配色:柔和、温暖,适合恋爱聊天的氛围。不用紫色。
介绍一下扣子编程的新功能:指哪儿改哪儿
在你的产品的“预览”界面,找到“编辑”按钮,如下图所示
接下来就可以“指哪儿改哪儿了”。
修改完成后,记得再次点击右上方的“保存”按钮,图标是☑️。
link20260227141513_rec_-convert.mp4【在线播放】

Section 7:理解原理——三块积木全部到齐

回顾:我们的积木之旅
课程
积木
数据流
第6节(黑话翻译器)
LLM
1条路
第7节(哄哄模拟器)
LLM + TTS
2条路同时走
第8节(纸片人男友)
LLM + TTS + 图像生成
3条路同时走
每一课加一块积木,产品体验升一级。现在我们来搞懂第三块积木是怎么接进来的。
新增的数据流:照片是怎么生成的?
和 TTS 的流程很像对吧?都是"LLM 生成内容 → 交给另一个API处理 → 返回结果展示"。
完整数据流:这次有三条路同时走
三条路各管各的,互不干扰:
文字最快,瞬间显示
语音稍慢,几秒后出现播放按钮
图片最慢,可能要10-20秒,但不影响文字和语音的展示
一个关键的设计决策:谁来决定"发不发照片"?
注意:是 LLM 自己决定要不要发图,不是你写代码去控制。
你在系统提示词里告诉 LLM:"当你提到自己在做某件事、或者对方说想看你的时候,可以用 [IMAGE: 描述] 来发照片。大约每3-5轮发一次。"
LLM 读懂这个规则后,会自己判断"这轮该不该发图",然后在回复里加上标记。你的产品代码只需要做一件事:解析回复、看到标记就调用图像生成API。
这就是"让AI做决策"的思维。 你不需要写复杂的if-else逻辑去判断什么时候发图——你只需要用自然语言告诉AI规则,它会自己执行。
这个思维非常重要。未来你做任何AI产品,很多原本需要写代码的逻辑,都可以交给LLM用自然语言去处理。
三块积木的完整对比
三块积木组合在一起 = 一个有性格、会说话、会发照片的虚拟男友。
这就是积木思维的威力。 你不需要懂图像生成的算法,也不需要懂语音合成的原理——你只需要知道这些积木"能做什么"、"怎么触发",然后用SPEC把它们组装在一起。
你已经掌握了“Demo级AI产品”开发能力
回看这三节课:
- 第6节:你学会了用1块积木做工具
- 第7节:你学会了用2块积木做游戏
- 第8节:你学会了用3块积木做陪伴产品
扣子编程内置了6种能力(LLM、图像生成、搜索、TTS、ASR、视频生成),你已经用了其中3种。剩下的3种,你完全可以用同样的方法自己探索。
100种API串2种 = 10000种可能。你现在有3种积木 × 无限创意 = 无限产品。

03 作业

1. 部署纸片人男友,发给你的闺蜜用
观察她的反应:她有没有多聊几轮?有没有截图发给别人?
如果她问"这个男的是谁"——恭喜你,产品成功了
2. 根据反馈打磨
闺蜜说"他说话太假了" → 调整系统提示词,让角色更自然
闺蜜说"照片里人长得不一样" → 在图片描述中固定外貌特征
闺蜜说"他从来不主动发照片" → 调整发图频率规则
3. 自由探索:试试做一个完全不同的产品
你已经有了3块积木。能不能做一个AI旅游导游(聊天+语音讲解+生成目的地照片)?
能不能做一个AI故事书(聊天推进剧情+语音旁白+每个场景生成插画)?
发挥你的创意。积木是一样的,产品可以完全不同。

九、入门篇总结:你已经不是那个只会用AI聊天的人了

01 入门篇知识体系回顾

到这里,你已经从零开始,你经历了三次认知层面的根本性转变。
第一次转变,是对AI的认知。很多人在接触AI之前,脑子里装的要么是"AI要取代人类"的恐慌,要么是"AI只是个聊天工具"的轻视。B1用一个极其接地气的比喻打破了这两种误解——AI是一个超级实习生。学历逆天,什么都懂一点,但缺乏实际工作经验,需要你给出明确的指令和上下文,它才能真正发挥价值。这个定位一旦建立,你和AI的协作关系就变了:你是主导者,AI是执行者,你们是搭档,不是竞争对手。
第二次转变,是对核心技能的认知。过去,"会编程"意味着会写代码。但在AI时代,SPEC(需求说明文档)才是新的源代码。能不能把一个模糊的想法转化成清晰、无歧义的指令,决定了你能不能真正驾驭AI。写好SPEC,比写好代码更重要——因为AI可以帮你写代码,但它没办法替你想清楚你到底要什么。
第三次转变,是对"如何做产品"的认知。我们引入的预制菜思维和积木思维,彻底改变了"做产品需要从零发明一切"的旧观念。AI时代的产品开发,本质上是在用现成的AI能力模块(积木)进行创意组合。技术不再是最高壁垒,你对场景的理解、对用户需求的洞察、以及积木组合的创意,才是真正的差异化所在。

02 核心技能点总结

入门篇覆盖了四项相互关联的核心能力,它们共同构成了AI产品开发的基础框架。
AI协作能力
理解AI的特点与局限,是有效协作的前提。AI的优势在于知识广博、执行快速、不知疲倦;但它的局限同样明显——它没有真实的工作经验,容易在细节处出错,也无法主动理解你没说清楚的部分。
与AI有效沟通的核心,是给足上下文,说清楚目标,定义好边界。不要问"帮我做个产品",而要说"我需要一个面向职场新人的工具,用于将互联网黑话翻译成通俗语言,输出风格要幽默但不失准确"。前者让AI无从下手,后者让AI有据可依。
SPEC写作能力
SPEC是整个AI开发流程的起点,也是质量的保证。一份好的SPEC应该包含:产品定位(这是什么、给谁用)、核心功能(要做什么)、交互逻辑(怎么做)、边界条件(不做什么、遇到异常怎么处理)。
从B3的练习中我们可以看到,从"我想做个翻译工具"到一份完整SPEC的距离,往往需要经历多轮与AI的对话讨论。这个过程本身就是在帮你把想法想清楚——很多时候你以为自己想清楚了,但一写SPEC就发现漏洞百出。这是正常的,也是必要的。
产品思维能力
我们做了一个非常关键的区分:"用AI做的产品"和"AI产品"是两回事。前者只是把AI当作开发工具,产品本身的核心体验与AI无关;后者则是把AI能力本身作为产品的核心价值交付给用户。
三种产品类型的演进路径——从传统软件,到AI辅助产品,再到以AI为核心的产品——代表了不同的产品设计思路。入门篇的三个实战项目,全部属于第三类:用户直接在和AI交互,AI的输出质量就是产品体验的全部。
积木组合能力
积木思维的精髓在于:你不需要发明积木,你只需要知道有哪些积木可以用,以及如何把它们组合成有价值的体验
目前常见的AI能力积木包括:LLM(大语言模型,负责理解和生成文字)、TTS(文字转语音,负责让产品"开口说话")、图像生成(负责视觉内容的创作)、语音识别、知识库检索等。每一块积木都有其适用场景,组合的方式决定了产品能提供什么样的体验。

03 实战项目回顾

入门篇的三个实战项目,它们是一条精心设计的渐进式学习路径
黑话翻译器:1块积木,验证核心逻辑
黑话翻译器只用了1块积木(LLM),但它验证了AI产品开发的完整闭环:写SPEC → 搭建工作流 → 调试提示词 → 完成产品。这是一个工具型产品,用户带着明确需求来,得到结果走。核心体验是"能用"——输入黑话,输出人话,简单直接。
这个项目的关键学习点在于:提示词的质量直接决定输出质量。同样是翻译黑话,提示词写得模糊,输出就干瘪;提示词写得精准,输出就生动有趣。这是对SPEC能力的第一次真实检验。
哄哄模拟器:2块积木,引入多模态体验
哄哄模拟器在LLM的基础上增加了TTS,产品形态从工具升级为游戏。用户不只是在看文字,还能听到声音——这一个积木的加入,让产品的情感浓度直接翻倍。
这个项目的关键学习点在于:不同积木的组合会产生乘数效应,而不只是加法效应。声音赋予了角色温度,游戏化的机制赋予了产品粘性,两者叠加出来的体验远超"文字+语音"的简单相加。
纸片人男友:3块积木,完整多模态陪伴
纸片人男友是入门篇的集大成之作。LLM负责对话,TTS负责声音,图像生成负责视觉形象——三块积木共同构建出一个陪伴型产品的完整体验:能聊、能听、能看。
这个项目的关键学习点在于:产品的情感价值是可以被设计的
通过精心设计角色人格(提示词)、声音风格(TTS参数)、视觉形象(图像生成提示词),你可以创造出一个有独特个性的AI角色。这已经不只是技术组合,而是真正的产品设计。

04 入门篇学习成果自检

完成入门篇之后,你应该能够做到以下几点。
如果某一项还不够确定,建议回头重温对应课程:
能用自己的话,向一个完全不懂AI的朋友解释"什么是AI产品"
能独立为一个新产品想法撰写完整的SPEC文档
能在扣子平台上独立搭建包含至少2块积木的工作流
能调试提示词,让输出结果符合预期的风格和质量
能将完成的产品部署上线,并分享可访问的链接
这几条是入门篇真正的"毕业标准"。

05 进阶篇预告

入门篇解决的是"能做出来"的问题。进阶篇要解决的,是"做得更好、更稳、更完整"的问题。
进阶篇系列将引入真正的工程化思维。
你会学到前端、后端和数据库的基础概念,理解一个完整产品的技术架构;你会接触用户认证系统,让你的产品能够识别和管理用户;你会学会使用专业IDE和GitHub进行版本管理,像真正的开发者一样工作;你还会接入API超市,把外部的各种AI能力集成到自己的产品中。
如果说入门篇教会你用积木搭出一个玩具,进阶篇要教你把玩具变成一个真正可以交付的产品。

06 作业提交说明

入门篇的结业作业,是完成全部三个课程中的练习作品,尝试做出小修改,部署上线后将链接发送至课程群。
提交时建议附上一段简短的产品介绍:这个产品是做什么的、你在开发过程中遇到的最大挑战是什么、你是如何解决的。这不只是为了让老师评分,更是在帮你自己完成一次真正的复盘。
做出来,发出来,能根据别人的反馈进行随心所欲的迭代,这才算真的学会了。

当前课程已学完

恭喜你已完成当前课程的所有内容。

下一篇

【实战进阶(1/4) 】前后端、源代码、数据库、用户认证、Next.js