【快速入门】认识你的新伙伴
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.
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:在扣子编程中生成产品
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:给产品装修
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 作业提交说明
入门篇的结业作业,是完成全部三个课程中的练习作品,尝试做出小修改,部署上线后将链接发送至课程群。
提交时建议附上一段简短的产品介绍:这个产品是做什么的、你在开发过程中遇到的最大挑战是什么、你是如何解决的。这不只是为了让老师评分,更是在帮你自己完成一次真正的复盘。
做出来,发出来,能根据别人的反馈进行随心所欲的迭代,这才算真的学会了。
当前课程已学完
恭喜你已完成当前课程的所有内容。