feat(docs): integrate version2 curriculum and stage-3 updates

概要
- 将 version2 分支的课程结构重构、第三阶段章节新增、示例资源迁移、高级 RAG 文档与 Vercel 部署配置等整合为 main 上的一次汇总提交

内容导航与 README 调整
- 更新 README 的总体介绍文案,引入“第零阶段 + 第一到第三阶段”的完整学习路径描述
- 将原先的“三阶段实战路径”说明替换为新版分阶段描述,突出从小游戏到跨平台复杂应用的学习节奏
- 删除已过时的“第二次更新将在分支 version2 合并到主分支”的提示,改为直接以 main 为主线
- 统一 README 顶部标题和排版风格,保证中英文导航、徽章展示等视觉结构一致

课程结构与章节导航更新
- 调整 docs 目录下的学习阶段导航结构,使 README 中的导航表与各 stage 实际目录对齐
- 补全并创建 stage-3 相关章节入口文件,用于承载高级阶段的课程内容
- 新增或更新以下章节入口:
  - 高级核心技能:
    - docs/stage-3/core-skills/3.1-mcp-claudecode-skills/index.md
    - docs/stage-3/core-skills/3.2-long-running-tasks/index.md
  - 多平台开发:
    - docs/stage-3/cross-platform/3.3-wechat-miniprogram/index.md
    - docs/stage-3/cross-platform/3.4-wechat-miniprogram-backend/index.md
    - docs/stage-3/cross-platform/3.5-android-app/index.md
    - docs/stage-3/cross-platform/3.6-ios-app/index.md
  - 个人品牌:
    - docs/stage-3/personal-brand/3.7-personal-website-blog/index.md
- 保持 stage-0、stage-1、stage-2 既有章节结构不变的前提下,对导航表格进行排版和链接校正,使整体课程地图清晰、可点击

示例与图片资源重组
- 将原先位于 docs/examples/example1/images/ 下的微信小程序示例图片,整体迁移到 stage-3 的正式课程路径中:
  - 目标路径:docs/stage-3/3.3-how-to-build-a-wechat-miniprogram/example1/images/
- 通过 rename 方式保留 git 历史关系,避免图片资源被视为完全新增,从而方便后续追踪
- 为微信小程序示例新增 index 页面:
  - docs/stage-3/3.3-how-to-build-a-wechat-miniprogram/example1/index.md
- 使该示例在“高级三:多平台开发:如何构建微信小程序”章节中有清晰的入口,对应实际实战内容

高级 RAG 与 AI 进阶文档
- 新增一篇系统介绍 RAG 的高级文档:
  - docs/stage-3/ai-advanced/3.a1-rag-introduction/extra5-what-is-rag-and-how-does-it-work-and-future.md
- 覆盖内容包括:RAG 的基本概念、典型架构、工作流程以及未来演进方向,为第三阶段的复杂应用提供知识检索基础
- 配套引入多张插图,帮助读者从架构图和流程视角理解 RAG:
  - docs/stage-3/ai-advanced/3.a1-rag-introduction/images/image1.png ~ image15.png

部署与工程配置
- 新增 vercel.json 配置文件,为项目在 Vercel 上的部署提供基础配置
  - 明确文档构建产物的输出路径和静态站点托管方式
  - 为之后的一键部署和自动化预览打下基础

依赖与锁文件更新
- 调整 package.json 中与新版文档结构和部署相关的配置,保持脚本和依赖与当前课程形态同步
- 更新 package-lock.json,以反映最新的依赖树和版本锁定状态
- 保证在执行 npm install / npm run build 时,依赖环境与 version2 中的实际使用情况一致

兼容性与行为说明
- 该提交通过 npm run build 验证,确保在整合 version2 内容后,VitePress 构建过程正常完成
- main 分支上的历史被压缩为一条有语义的“第二次大更新”提交,详细的开发过程仍保留在 version2 分支,用于后续需要时回溯
This commit is contained in:
sanbuphy
2026-01-12 12:21:35 +08:00
parent 307a37cdb9
commit a4b583b13f
632 changed files with 18082 additions and 8092 deletions
+122
View File
@@ -0,0 +1,122 @@
# 从创意到 AI 产品
我们正身处由大语言模型(LLM)推动的人工智能应用爆发期。与以往AI开发高度依赖算法研究不同,**当前行业的重心已转向如何有效利用现有强大模型,构建具有实际价值的应用。**这一转变大幅降低了AI开发的门槛,将焦点从"从零开始构建模型"转移到"将AI能力封装为可落地的解决方案"。
对大多数人而言,如今最大的机遇并非发明新算法,而是学会如何借助AI编码工具快速实现想法。
AI coding的出现正在改写传统编程学习的规则。你不再需要花费数年时间精通某门语言的每个细节,而是可以通过与AI协作,**以"vibecoding"的方式将创意直接转化为可运行的代码**。会使用大模型生成代码片段只是起点。
当前真正的挑战在于:如何引导AI生成高质量、可维护的代码?如何将前后端代码组装成完整应用并成功部署上线?在AI时代,如何将文本生成、图像处理、语音识别等AI能力集成到你的应用中?本课程正是为应对这些挑战而设计。
我们不空谈理论,聚焦于AI辅助编程的端到端实战——**从利用 AI IDE 等工具快速构建原型,到将想法落地为真实可用的产品**。你将学会如何与AI高效协作编码,如何利用vibecoding思维快速迭代,如何调用常见的AI功能(文本生成、图像处理等)为应用赋能,以及如何完成从开发到上线的完整闭环。
# 为什么要学这个?它将如何帮助我的未来?
本课程专为初级水平的学生设计,侧重于 AI 原生应用的实际开发和创新思维培养。通过三个循序渐进的学习阶段,你将从零基础逐步成长为能够独立开发和运营 AI 应用的全栈开发者。
## 三个阶段的成长路径:从“会用 AI”到“会做 AI 产品”
**第零阶段:体验 AI 编程的魔力**
通过贪吃蛇等小游戏,你将第一次体验到 AI 辅助编程的能力与边界。这个阶段不需要任何编程基础,只需要你愿意动手尝试——看着 AI 在几分钟内帮你生成一个可玩的游戏,你会直观感受到 vibecoding 的强大。
**第一阶段:掌握产品开发的完整闭环**
学会使用 AI IDE(如 Cursor、Claude 等工具)将想法转化为可运行的 Web 应用原型。你将学习如何拆解需求、设计多页面应用、接入 AI 能力(文本生成、图像处理等),并用模拟数据完成一个完整的产品 demo。这个阶段结束时,你能独立完成一个像“霍格沃茨画像”那样接入 AI 能力的前端应用。
**第二阶段:成为能上线产品的工程师**
这是质的飞跃。你将学习现代 Web 开发的核心技能:从 Figma 设计稿到组件化前端实现,从 Supabase 数据库到 API 接口开发,从 Git 版本管理到 Zeabur 部署上线。更重要的是,你将学会集成支付系统(如 Stripe),让你的应用具备真实的商业价值。通过 Dify 等工具,你还将掌握知识库与工作流的构建,为应用注入更强的 AI 能力。
**第三阶段:构建跨平台的复杂应用**
掌握多平台开发能力,将同一个应用部署到 Web、微信小程序、安卓等多个平台。学习 MCP 等高级工具扩展 IDE 能力,深入理解 RAG 原理并使用 LangGraph 等框架设计复杂的 AI 工作流。这个阶段你将具备高级工程师的思维方式和工具链。
## 你将获得的核心能力
通过这个完整的学习路径,你将获得:
- **Vibe Coding开发能力:** 熟练使用 vibecoding 思维和 AI 编码工具,将开发效率提升数倍。不再需要死记硬背语法,而是学会如何引导 AI 生成高质量代码。
- **全栈开发技能:** 从 UI 设计到前端实现,从数据库设计到 API 开发,从本地开发到云端部署,掌握现代 Web 应用的完整技术栈。
- **AI 能力集成:** 学会调用各类多模态 AI API,将文本、图像、语音等 AI 能力无缝集成到你的应用中,并通过 RAG 等技术构建智能化产品。
- **产品思维与运营能力:** 从用户研究到需求拆解,从 MVP 设计到产品迭代,从支付集成到用户管理,形成完整的产品开发与运营闭环。
# 第一阶段学习目标
本阶段本质上是一套“AI 产品经理 Vibe Coding 能力培训课程”,主要面向希望进入 AI 产品方向、但编程基础较弱或几乎为零的同学,目标是在 AI 的帮助下完成一个“能跑、能展示”的 Web 应用原型。
```
## 模块一:AI 时代,会说话就会编程
- 1.1 普通人的困境与机会?
- 1.2 AI 能帮你做到什么程度?
- 1.3 动手:你的第一个 AI 原生应用
## 模块二:认识 AI IDE 工具
- 2.1 写代码需要什么环境和工具
- 2.2 什么是 IDE,为什么需要 IDE
- 2.3 AI IDE 和普通 IDE 有什么不同
- 2.4 界面上每个按钮是干什么的
- 2.5 怎么跟 AI 说话才有效
## 模块三:动手做出原型
- 3.1 把需求变成代码的过程
- 3.2 从一个单页面开始
- 3.3 遇到报错了怎么办
- 3.4 做多个页面的应用
- 3.5 把原型做得像那么回事
## 模块四:给原型加上 AI 能力
- 4.1 什么是 AI 能力接入(API 调用)
- 4.2 如何接入文生图能力
- 4.3 如何接入视频生成能力
- 4.4 其他常见 AI 能力的接入方法
- 4.5 成本控制和错误处理
## 模块五:完整项目实战
- 5.1 制造模拟数据让原型看起来真实
- 5.2 收集反馈并快速调整
- 5.3 展示你的成果
## 大作业
- 做一个完整的 Web 应用原型并展示
## 附录A:产品思维补充
- A.1 什么是好的产品想法
- A.2 如何发现用户真正的需求
- A.3 功能优先级怎么排
- A.4 MVP 思维:最小可行产品
## 附录B:常见报错及解决方案
- B.1 页面显示空白或不加载
- B.2 数据保存不成功
- B.3 样式显示不正常
- B.4 点击按钮没反应
- B.5 API 调用失败
- B.6 如何把报错信息有效地反馈给 AI
```
# 为什么要用项目制来训练?
原因其实很简单:按照大多数同学现在的状态,直接走入职场,很可能会在真实项目和老板 / 客户的“社会毒打”下寸步难行。现实世界更常见的场景是:
> 你的导师 / 老板:我们要做一个 xxx,目标是达到 yyy 的效果。
>
> 文档?现成框架?详细的需求说明?很多时候都不存在。
真实工作中的许多任务,本质上就是在高度不确定的环境下解决从未见过的问题:需求是模糊的,边界是变化的,没人告诉你标准答案,你需要自己查资料、做实验、搭原型、不断迭代,最后给出一个“能跑、能用、能上线”的解决方案。
这门课想做的,就是在一个相对安全的环境里,提前给你一次“模拟社会毒打”:
- 通过看似有一定难度的项目任务,迫使你练习拆解问题、设计方案、自己寻找资料
- 通过不那么“傻瓜化”的脚手架和代码,让你学会阅读、理解和改造一份中大型代码库
- 通过从创意到上线的完整闭环,让你体验真实产品从 0 到 1 的完整过程
短期来看,这种训练确实比较折磨人;但从长期来看,它会极大提高你在求职和职业发展中的竞争力:你会更能扛事儿,更能在不确定环境中找到突破口,也更有能力把 AI 变成真正落地的产品,而不是停留在“玩玩 Demo”阶段。
# 坚持了好久还是搞不定,我想放弃了
也许是你坚持的方法不对。不要一个人在黑暗中硬撑,可以来跟作者和助教们聊聊:把你已经尝试过的方法、遇到的具体卡点、和你目前的心理状态,坦诚地说出来。很多时候,只要稍微调整一下方向、补上一个关键知识点,你就能继续往前走。
# 我觉得教程有的设计不合理
欢迎随时联系作者、提交 issue,或者在群里 / 课堂上直接反馈。我们非常希望和你一起把这套教程打磨得越来越好:哪里不清晰、哪里体验不好、哪里让你白费力气,都可以坦诚指出来。越真实、越具体的反馈,越能帮助后来者少踩坑。
# Reference
- [南京大学 计算机科学与技术系 计算机系统基础 课程实验](https://nju-projectn.github.io/ics-pa-gitbook/ics2025/)
Binary file not shown.

After

Width:  |  Height:  |  Size: 623 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.1 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 64 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 107 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 379 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 373 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 656 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 318 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 41 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 283 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 119 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 127 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 108 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 223 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 385 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 299 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 98 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 268 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 167 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 640 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 13 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.9 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 514 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 148 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 5.3 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 529 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 313 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 407 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 587 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 234 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 651 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.3 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.1 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 124 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 238 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 183 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 442 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 540 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 4.1 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.6 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 3.7 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.3 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.1 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 57 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 602 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 658 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 333 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 36 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 97 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 236 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 336 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 880 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 201 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 388 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 556 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 478 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 44 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 23 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 92 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 114 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 402 KiB

@@ -0,0 +1,577 @@
# 初级一:AI 时代,会说话就会编程
这是一个**基于项目制学习**的学习教程。我们鼓励你跟随步骤一步步操作,并尝试复现结果。
不要担心犯错或修改内容,我们永远相信你可以做到,请你永远记住:
🎉 **完成比完美更重要**
## 本章导读
在这一节,你会用对话式 AI 做出第一个 AI 原生小游戏——一款会“吃单词、写诗、画画”的贪吃蛇,并借此搞清楚 AI 编程的初步效果。
- 预计时间:约 **4 小时**,可分多次完成
- 预期产出:1 个可运行的 AI 原生贪吃蛇 + (可选)1 个你自创的 AI 原生小游戏或 Demo
- Assignment:复现贪吃蛇,并(可选)实现一种你感兴趣的 AI 原生游戏
## 1. 普通人的困境与机会
很多人脑子里有一堆产品点子:一款帮自己记账的小工具、一个记录孩子成长的网页、甚至一款小游戏。但一想到要写代码、要找程序员,就直接劝退。
AI 出现之后,第一次给了普通人一个全新的可能:你不需要会写代码,只需要学会对 AI 说清楚你想要什么。来自 GitHub Copilot 的[数据显示](https://www.wearetenet.com/blog/github-copilot-usage-data-statistics),超过1500万开发者正在用AI辅助编程,平均46%的代码都是AI生成的! 在Java项目中这个比例能达到61%。
让人真正兴奋的是效率的飞跃:开发者完成任务的速度提升了 55%。原本需要 9.6 天才能提交的代码,现在只要 2.4 天就能搞定。 这种肉眼可见的效率提升,说明 AI 不再只是一个“可选工具”,而是正在成为开发流程中不可或缺的编程助手。采用率的数据也印证了这一点:在获得访问权限的当天,就有 81% 的开发者第一时间完成安装并开始使用;其中 96% 的人更是在当天就开始采纳 AI 提供的代码建议。换句话说,开发者几乎是立刻把 AI 融入了日常编码工作。
对于普通人来说,这个趋势更有意义:如果专业程序员都在大量依赖AI写代码,那我们这些**不会编程的人,为什么不能直接跟AI对话来实现自己的想法呢**?
这门课的目标是帮你练成新技能:通过自然语言对话就能做应用。我们将教你怎么跟 AI 用计算机的语言沟通、怎么让AI帮你把脑子里的想法变成真实可用的产品。
## 2. AI 能帮你做到什么程度
在本节中,我们只讨论一个问题:如果你完全不会写代码,现在的 AI 能帮你做到什么程度?
大致来说,你可以把当前大模型的能力理解为:可以胜任简单的内部小工具、数据可视化看板,以及一些轻量级小游戏的开发。这些能力用来做自用工具、从产品经理视角验证需求,基本已经足够。但若想一键生成可直接商用的成熟产品,通常仍需要人工在流程设计、细节打磨上持续优化。
接下来,我们就以贪吃蛇为例,具体看看 AI 编程目前到底能做到什么程度。
### 2.1 60 秒做一个贪吃蛇游戏
首先,请你打开课程中使用的实验网页 [z.ai](https://chat.z.ai/)`z.ai` 是由智谱 AI(中国领先的大语言模型公司之一)开发的 AI 平台,其核心能力由智谱自研的 GLM 系列大模型提供支持。该平台集成了多项 AI 功能,包括幻灯片生成、海报设计和全栈开发等。在本教程中,我们将重点介绍其全栈开发模块的使用。
![](images/index-2026-01-07-18-25-03.png)
输入我们的简单需求后点击 **全栈开发** 按钮,你可以实时观看网页的完整创建过程。通常只需泡一杯咖啡的时间,网页便会自动生成完毕!
```
帮我做一个贪吃蛇游戏:
1. 用方向键控制蛇的移动
2. 吃到食物后蛇会变长,分数增加
3. 撞到墙壁或自己的身体就游戏结束
4. 要有开始和重新开始按钮
5. 界面要简洁好看
```
![](images/index-2026-01-07-18-34-03.png)
生成结束后,你能看到右侧出现可浏览的网页界面。你可以上下滚动浏览页面内容,或点击页面顶部的 🧭 按钮切换至全屏模式查看效果。
> 其中顶部从左到右按钮的作用依次为:箭头按钮展开侧边对话历史栏,铅笔按钮用于新建一个对话,循环箭头按钮用于刷新页面,指南针按钮负责切换至全屏模式,Download 按钮用于下载项目,<> 按钮用于切换代码视图,Publish 按钮用于发布项目。
![](images/index-2026-01-07-18-35-11.png)
如果你想查看该网页的源代码,可以点击右上角的代码图标查看完整代码。
![](images/image7.png)
### 2.2 对话编程能做什么不能做什么
本节聚焦一个具体问题:当你只依赖对话式 AI、不写任何代码时,它究竟能把事情推进到哪一步。
在经验层面,一个较为稳定的结论是:它可以帮你完成一个“小而完整”的东西,但“做到什么程度就算够”,仍然需要你亲自决策每一步的详细步骤。
#### 更擅长“小而清晰”的应用
从前面的贪吃蛇示例中,你已经看到了一种典型模式:
只要你能把界面和交互说清楚,AI 通常可以在几轮对话内,拼出一个可以打开、可以点击、可以玩的完整网页。
这类任务往往具备几个共同特征:
- 范围清晰:一页网页、一个简单内部工具、一个小玩法
- 结果可见:你能立即在浏览器中验证是否按预期工作
- 纠错直接:发现问题后,可以在后续对话中点明具体现象并要求修正(通过复制错误直接粘贴,或者截图粘贴的形式让 AI 进行修改)
在这个边界内,你可以把对话式 AI 看作一位执行力不错的“辅助开发者”。你只需在每一轮用自然语言细化和修正需求,就能快速得到可用的原型。
#### 大型项目需要“流程视角”
一旦超出小而清晰的范围,只指望靠几轮对话让 AI 端到端完成复杂系统,很快就会遇到上限。大型项目往往要接后端、连数据库、整合第三方服务,还牵涉权限、安全、并发和大量业务规则,目标是交付一整套与现有业务深度打通的系统,而不是一页网页。
在这种情况下,更合理的做法不是把所有需求一股脑丢给 AI,而是先梳理出清晰的整体流程:关键步骤是什么、每一步的输入输出和状态变化是什么、哪些节点对性能和安全最敏感。再基于这张流程图,把相对独立的环节拆分出来,交给对话式 AI 生成接口、模块、脚本和测试。
以目前的能力来看,AI 更擅长加速一个个小步骤,由你(或你的团队)来决定怎么拆步骤、如何串联,并负责最终的架构设计、系统集成和运维。
#### 能写和能用的区别
咋一看,AI 好像什么都能写,但这些东西到底能不能用,能用到什么程度,我们该如何划分?
一个可参考的经验是:
- **原型 / Demo / 内部自用工具**:非常适合先交给 AI 打第一版,再由你迭代细节。
- **面向真实用户的大型产品**:通常需要工程师在架构、抽象、性能和维护上长期投入。
- **强安全 / 强合规系统(如支付、风控、医疗等)**:在当前阶段,不宜“生成完就直接上线”,必须引入严格的审查与测试流程。
在当下,你可以相对安心地把 AI 视作一个高效的 Demo 与自用工具搭档:
只要你愿意多测试、多迭代,多问几轮“这里不对,帮我修一下并解释原因”,在原型与内部工具这一级别,整体质量通常是足够且具备实践价值的。
## 3. 动手:你的第一个 AI 原生应用
让我们回到动手部分,在前一部分,我们已经用 AI 快速做出了一个可以玩的贪吃蛇原型,也大致知道了 AI 能做什么、不能做什么。接下来我们将学习如何用最基础的 **vibe coding** 技巧创建一个**现代版**的 AI 贪吃蛇游戏。我们将让蛇吃掉文字字符而不是豆子。最后让游戏根据吃掉的文字字符生成一首诗,并画一幅画。
通过这个实际案例你能够理解全新编程方式的核心理念:如何学会用自然语言清晰地表达需求。
### 3.1 AI 原生贪吃蛇
在一开始,我们可以用最简单的方式与大模型对话,这将帮助我们快速获得产品原型。我们可以直接在聊天框中输入:
> **💡 示例提示词:** 帮我做一个贪吃蛇游戏
>
> ![](images/image12.png)
> **💡 示例提示词:** 帮我做一个贪吃蛇游戏,它应该支持
>
> 1. 我可以吃不同的单词,它们会被收集在一个盒子里
> ![](images/image13.png)
> **💡 示例提示词:** 帮我做一个贪吃蛇游戏,它应该支持:
>
> 1. 我可以吃不同的单词,它们会被收集在一个盒子里
> 2. 当蛇吃了8个单词时,llm 应该根据这些单词创作一首诗,我们可以根据需要重新混合这首诗。
> 3. 当诗完成后,下一步将自动根据这首诗创建一幅图像。
>
> ![](images/image14.png)
注意,在开发过程中,我们可能会遇到不尽如人意的问题,例如点击按钮没有任何反应、使用功能时报错、功能未按预期工作,或者前端页面与预期设计不符。
在这种情况下,我们需要进一步向模型提问,以帮助修复这些意外问题。
![](images/image15.png)
### 3.2 给游戏添加新功能
完成基本功能后,我们可以尝试给我们的程序添加一些新花样!如果你觉得蛇吃单词或字符的过程有点枯燥,你可以让蛇吃不同颜色的单词,并相应地改变蛇的颜色。
你还可以为“吃”的过程添加特效,或者引入触发特效的魔法单词——比如增加蛇的速度或大小。另一个想法是每当蛇吃一个单词时就让模型生成一首诗和一幅图,而不是等到它吃掉八个单词。
如果觉得这些有挑战性,你可以直接向语言模型求助!它可以提供创意建议,让你的游戏更有趣。试一试吧!
```JavaScript
1. "单词解锁世界" 机制
每当蛇吃掉一个单词LLM 会对该单词进行诗意联想例如森林绿荫图像模型会即时为该单词生成一个小艺术品这些图像逐渐拼凑成一个独特的玩家创造的全景图所以玩家每次游玩都在作画和写诗
2. "诗歌拼图" 玩法
蛇吃掉的每个单词都会触发 LLM 生成简短的诗句图像模型生成插图这些诗句和图像像拼图一样组合在一起在回合结束时形成一首 AI 协作的诗和画
3. "魔法单词" & "故事分支"
特殊的魔法单词例如不仅触发 LLM 生成诗歌还会改变场景的情绪或主题将生成图像的风格转变为夜晚暴风雨或梦幻般的氛围
分支故事LLM 在开始时给出一个主题或谜语例如秋天的回忆玩家的单词选择直接影响故事和诗歌的演变图像模型实时更新背景和视觉效果
4. "实时互动生成"
每个单词之后LLM 生成一行对话或描述游戏中的 NPC 可以对玩家说话或者环境可以相应地改变
蛇的外观或游戏中的障碍物可以根据吃掉的单词在视觉上发生变化这要归功于图像模型
5. "创作 & 分享"
玩家可以在会话结束时保存并分享他们 AI 创作的诗歌和图像炫耀他们独特的AI 协作
最美诗歌+艺术最有创意单词组合等排行榜鼓励重玩和创造力
6. "按句贪吃蛇" 挑战
反向模式LLM 给出一句诗或一个谜语玩家必须引导蛇按顺序吃掉单词来重构句子吃错单词会通过图像生成模型触发有趣或艺术性的后果
7. "主题关卡" & "风格选择"
游戏开始时玩家选择一个主题例如童话科幻唐诗LLM 和图像模型都会调整单词选择诗歌风格和视觉效果以匹配使每次运行都感觉新鲜
8. "现场共创"
当吃掉一个特殊单词时LLM 可以提示玩家输入短语或选择风格然后 AI 生成相应的诗句和插图使其成为真正的人类-AI 共创
9. "AI 彩蛋 & 成就"
某些单词组合被 LLM 识别为特殊主题或内部笑话例如月亮桂花河岸触发稀有的诗句和插图奖励探索
10. "成长的故事"
随着蛇的成长LLM 生成一个连续的故事诗图像模型创建一个无缝的长卷或全景图所以玩家同时在写作绘画和玩耍
```
此外,我们还可以要求 LLM 帮你直接生成项目级的提示词。在上一节中,我们只自己写了贪吃蛇游戏的提示词。现在让我们尝试让大模型生成一个带有整体框架和实现路径的提示词(你可以直接用 z.ai 生成):
> 我想让 AI 生成一个网页贪吃蛇游戏,需要一个更完整的提示词,让生成结果更令人印象深刻和有趣。请生成相应的提示词。当前目标是:生成一个贪吃蛇游戏,需要实现吃不同单词生成诗歌的功能,并且应该包含图像生成模块。
z.ai 的回复将会是这样的:
![](images/image56.png)
我们可以使用这个提示词在全栈开发模式下重新生成项目:
![](images/image57.png)
![](images/image58.png)
### 3.3 尝试制作其他小游戏
除了贪吃蛇(游戏),我们可以让想象力尽情驰骋。
创造任何我们想创造的东西,甚至尝试搞砸一切!然后重头再来!
```YAML
1. AI 艺术画廊平台
描述:一个展示 AI 生成艺术作品的在线画廊,用户可以上传、分享和评论 AI 艺术作品。
功能:用户账户系统、艺术作品上传和展示、评分系统、分类浏览、AI 生成工具集成。
技术亮点:React/Vue 前端、Node.js 后端、MongoDB 数据库、AI API 集成。
2. 复古游戏档案馆
描述:一个致敬经典游戏的网站,包含游戏历史、玩法指南和在线可玩复古游戏。
功能:游戏数据库、时间轴展示、在线模拟器、用户评论、游戏收藏功能。
技术亮点:响应式设计、WebGL/Canvas 游戏实现、RESTful API、用户认证系统。
3. 可持续生活追踪器
描述:一个帮助用户通过环保提示和社区挑战来追踪和减少碳足迹的网站。
功能:个人碳足迹计算器、目标设定、进度追踪、社区挑战、环保知识库。
技术亮点:数据可视化、移动端优化、社交功能、推送通知。
4. 虚拟厨房助手
描述:一个基于 AI 的烹饪指导平台,提供个性化食谱推荐和分步烹饪说明。
功能:食谱数据库、食材识别、个性化推荐、烹饪计时器、营养分析。
技术亮点:图像识别 API、机器学习推荐系统、语音控制、实时视频指导。
5. 地下音乐发现平台
描述:一个专注于独立和新兴艺术家的音乐流媒体平台,提供独特的发现体验。
功能:音乐流媒体、艺术家资料、个性化推荐、播放列表创建、社区评论。
技术亮点:音频流处理、推荐算法、社交功能、音乐可视化。
6. 极简任务管理系统
描述:一个具有禅意美学的任务管理工具,专注于简单和高效的任务组织。
功能:任务创建和分类、优先级设置、进度追踪、团队协作、数据分析。
技术亮点:极简 UI 设计、拖放功能、实时同步、跨平台兼容性。
7. 科幻写作工坊
描述:一个为科幻作家提供创意工具和灵感的平台,包括世界观构建辅助和角色开发工具。
功能:故事结构工具、角色资料、世界观构建模板、写作统计、社区反馈。
技术亮点:富文本编辑器、数据可视化、协作编辑、AI 辅助创作。
8. 个人知识图谱
描述:一个帮助用户构建个人知识网络,可视化并连接各种想法和信息的工具。
功能:节点创建和连接、标签系统、搜索功能、导入/导出工具、可视化图表。
技术亮点:图数据库、数据可视化算法、Markdown 支持、跨设备同步。
9. 虚拟植物园
描述:一个互动植物百科全书,用户可以探索植物世界并创建虚拟花园。
功能:植物数据库、3D 植物模型、生长模拟、园艺指南、社区展示。
技术亮点:3D 渲染、季节变化模拟、AR 集成、植物识别 API。
10. 编程挑战竞技场
描述:一个面向程序员的在线竞赛平台,具有各种难度级别的编程挑战。
功能:挑战问题、代码编辑器、自动评估、排行榜、学习路径。
技术亮点:代码沙箱环境、实时评估系统、算法可视化、社交学习功能。
```
还有... 如果你喜欢玩游戏,让我们一起尝试创造游戏吧!
```SQL
1. 3D RPG
广 RPG
Three.js Babylon.js 3D
2. (FPS)
FPS
WebGL/Three.js 3D
3. AI
AI 线
AI
WebSocket ELO
4. 线
线
5.
AI /
6.
3D
3D 线
7. ()
AI
8. ( 2D)
2D
9. ()
AI
10. (3D)
3D
3D
```
# 📚 Assignment
- 复现 AI 原生的贪吃蛇游戏。
- (可选)根据更多参考案例实现不同种类好玩的 AI 原生游戏。
这就是完整的教程!你可能需要 **4 小时** 才能完成所有内容并构建你自己的贪吃蛇游戏。不要着急——探索、实验并享受这个过程。推荐你读完下列附录,用于补充基础知识:
# 附录
## 附录 1:我们需要前端开发知识吗?
在 Vibe Coding 阶段,我们不再要求每一位用户都具备专业的编程能力。这种模式下,你的核心任务主要体现在两个方面:
1. 能够用自然语言,比较清晰地描述自己想要的界面和交互效果;
2. 当 AI 给出的结果不符合预期或出现报错时,能够把报错信息、截图等上下文整理后,再反馈给 AI,协助其完成修正。
在这个前提下,即便你从未写过一行代码,也可以通过与 AI 的持续对话,逐步搭建出可用的原型。
但是,如果我们对前端开发的一些基础概念有所了解,就可以更准确地提出需求,更有效地利用 AI 的能力。这也是本附录希望补充说明的部分。
### 什么是前端?
在一个典型的应用系统中,我们通常会将其大致分为两个部分:
- 一部分是直接呈现在用户面前的界面,以及与界面相关的交互;
- 另一部分是运行在服务器上的数据处理和业务逻辑。
其中,前者通常被称为**前端**,后者则被称为**后端**。
从结果上看,前端就是**用户“能看到、能点到”的那一层内容**。例如:
- 网页上的标题、段落文字和图片;
- 按钮、输入框、下拉菜单、勾选框等交互控件;
- 排行榜页面、游戏界面、动态动画效果等。
后端则更多负责**“看不见”的部分**,例如:
- 用户分数存放在什么地方;
- 登录时如何校验账号和密码是否正确;
- 针对不同用户,如何分配不同的关卡或内容。
**前端开发**的工作,就是在浏览器这一“运行环境”中,把上述可视化界面和交互行为搭建出来,使用户能够顺畅地查看信息、提交表单、进行操作。
### 1. 前端基础三件套:从“页面是哪儿来的”说起
前端页面并不是“凭空出现”的。
当我们在浏览器中打开一个网址时,浏览器会从服务器获取一份描述页面的“说明书”,然后按照这份说明书的内容,一步步把界面“画”出来,并让它能够响应用户的操作。
这份“说明书”,通常由三类内容共同组成:
- HTML
- CSS
- JavaScript
从工程角度看,它们本质上都属于**代码**:
也就是一段一段、遵循固定规则的文本指令;这些指令虽然是人写出来的,但最终是**由浏览器来阅读和执行**的。
为了方便理解,我们可以把这三者类比为一栋房子的不同方面:
1. **HTML:搭骨架,告诉浏览器“有什么”**
HTML 负责描述页面上的“结构”和“元素”。对浏览器来说,HTML 就像是一张建筑结构草图:哪里有一堵墙,哪里有一扇门,哪里有一扇窗。
- 例如:页面中有一个标题、一段文字、一个按钮、一张图片。
2. **CSS:定样式,告诉浏览器“长什么样”**
CSS 负责控制界面的视觉呈现。它相当于给已经搭好的“骨架”穿上合适的“衣服”和“装修”。
- 例如:按钮是蓝色的、带圆角;文字需要居中对齐;背景需要是浅灰色。
3. **JavaScript:管行为,告诉浏览器“怎么动起来”**
JavaScript 负责页面的交互逻辑和动态行为。它更像是这栋房子里的“电路”和“开关”,决定各种设备在什么情况下被触发。
- 例如:点击按钮后弹出提示;表单提交前先检查是否填写完整;游戏角色按一定规则移动。
这三者虽然形式上都是“代码”,但承担的职责并不相同。浏览器会在加载页面时,将它们分别读入,然后按既定顺序执行:先根据 HTML 搭出结构,再根据 CSS 进行渲染,最后由 JavaScript 负责交互和逻辑,让整个页面真正“活起来”。
### 2. 一个简单的执行链路示例
下面我们通过一个极简示例,来直观感受一下“从代码到效果”的完整链路。
![](images/image9.png)
假设我们希望在页面上放置一个可以点击的按钮,并在点击时给用户一个提示。
1. **HTML:声明有一个按钮**
```html
<button>点我</button>
```
当浏览器读到这行代码时,会理解为:
页面上需要出现一个按钮,按钮上的文字是“点我”。
2. **CSS:设置按钮的外观**
```css
button {
background-color: #3498db; /* 蓝色背景 */
color: white; /* 白色文字 */
border: none; /* 无边框 */
padding: 10px 20px; /* 适当留白 */
border-radius: 4px; /* 稍微圆角 */
}
```
浏览器在渲染页面时,会把这段样式规则应用到刚才创建的按钮上,使其变成一个蓝底白字、带圆角的按钮。
3. **JavaScript:定义点击时的行为**
```javascript
document.querySelector('button').onclick = function () {
alert('你点了我!')
}
```
当浏览器执行到这段 JavaScript 时,会给按钮绑定一个“点击事件”。
此后,每当用户点击这个按钮时,页面上就会弹出提示框。
从用户的视角来看,只是“打开网页 → 看到一个按钮 → 点了一下 → 出现提示”。
但在背后,浏览器实际上经历了一个完整的执行过程:**解析 HTML → 应用 CSS → 执行 JavaScript → 响应用户操作**。
这就是前端“三件套”在一个最简场景下的协同方式。
### 3. 现代前端框架:在“三件套”之上的进一步抽象
随着前端应用不断演进,单纯依赖 HTML、CSS 和 JavaScript 手工组织代码,逐渐暴露出一系列问题:
- 页面结构日益复杂,代码量急剧增加;
- 相同的界面片段需要多处复制粘贴,维护成本高;
- 数据变化频繁时,需要手动更新界面,容易出错。
在这种背景下,**现代前端框架**应运而生。所谓“框架”,可以理解为一套经过实践检验的**固定结构和约定**,帮助开发者在统一的规则下组织代码,从而降低复杂度、提高可维护性。
以常见的 React 为例,现代前端框架通常带来以下几方面的能力提升:
1. **组件化:把页面拆成可复用的“模块”**
一个完整的页面,可以被拆解为若干相对独立的区域:导航栏、侧边栏、内容区、评论列表、按钮组等。
在框架中,每一个区域都可以被定义为一个“组件”,组件内部负责自己的结构、样式和行为,同时又可以被组合、嵌套和复用。
这样做的直接好处是:修改或复用某一部分时,只需关注对应组件即可,避免整页代码纠缠在一起。
2. **状态驱动:数据变化带动界面更新**
传统方式下,当数据发生变化时(例如排行榜分数更新),开发者往往需要手动找到对应的界面元素,逐条更新内容。
在框架中,我们只需要更新组件内部维护的“状态”,框架就会自动计算出哪些地方需要重新渲染,并完成界面更新。这种“数据驱动界面”的方式,大大减少了手工操作和出错概率。
3. **统一规范:结构清晰,便于协同与自动生成**
现代前端框架通常对文件组织、组件命名、数据流转等方面提供明确约定。
对于 AI 而言,这种稳定、一致的结构更加友好,有利于自动生成质量更高、逻辑更清晰的代码,也更便于后续维护和扩展。
![](images/image11.png)
### 4. 在 Vibe Coding 中如何利用这些能力?
在 Vibe Coding 的实践中,我们并不要求每一位用户都深度掌握 HTML、CSS、JavaScript 或某一前端框架的所有细节。
更现实的目标是:
- 在概念层面,理解“前端页面是由浏览器执行一组规则生成的”,这组规则主要由 HTML、CSS 和 JavaScript 组成,它们本质上都是代码;
- 知道现代前端框架(如 React)是在这三者之上,对页面结构和交互逻辑的一种进一步组织方式,有助于 AI 更稳定地生成可维护的前端代码。
基于这些认识,在与 AI 协作时,我们可以给出更具指向性的指令,例如:
> “请使用 React 帮我实现一个包含排行榜的页面,右侧展示分数列表,点击某一行时在下方显示该玩家的详细信息,整体风格简洁、现代。”
在这种模式下,**你不必亲自完成每一行代码的书写**,而是通过理解基本概念与角色分工,扮演好“提出需求、检查结果、反复迭代”的角色,让 AI 负责具体实现细节,从而大幅降低前端开发的门槛。
## 附录 2:到底什么是 Vibe Coding
> 💡 什么是 Vibe Coding?计算机科学家 [Andrej Karpathy](https://karpathy.ai/)OpenAI 的联合创始人之一,特斯拉前 AI 负责人)于 2025 年 2 月提出了 **vibe coding** 一词。这个概念指的是一种依赖于 LLM 的编码方法,**允许程序员通过提供自然语言描述而不是手动编写代码来生成可工作的代码。**
![1767350588191](images/1767350588191.png)
从字面上看,Vibe Coding 可以理解为一种“用说的方式来做开发”。它的核心变化在于:你不再需要自己一行一行写代码、查语法、调 Bug,而是直接用自然语言描述你想要的东西,例如:
“我需要一个登录页面,上面有手机号输入框和验证码输入框。”
“登录成功后,跳转到首页,并在右上角显示用户名。”
“给我一个简单的贪吃蛇小游戏,可以用键盘方向键控制。”
大语言模型(LLM)会把这类描述自动翻译成真正可以运行的代码,并生成对应的页面、逻辑和数据结构。你看到效果后,再用自然语言提出修改意见,例如“按钮再大一点”“背景换成深色”“得分记录下来并显示排行榜”,AI 会继续按你的要求调整实现。
在这种模式下,你不需要先学会编程语言,再去写代码;而是把主要精力放在:说清楚要做什么、看到结果后判断“哪里不对”、再提出新的修改。AI 则负责把这些高层的想法落成具体实现,从而显著减少机械、重复的编码工作。
你可以点击这里查看更多关于 vibe coding 的细节:[https://www.ibm.com/think/topics/vibe-coding](https://www.ibm.com/think/topics/vibe-coding)
你可以点击这里查看更多关于 Karpathy 的分享内容:[https://karpathy.bearblog.dev/blog/](https://karpathy.bearblog.dev/blog/)
### 如何假装自己是 Vibe Coding 大师
实际上,在真正的 vibe coding 过程中,我们通常不会使用很多复杂的提示词。也许我们在开始时需要为整个程序提供一个具体且适度复杂的提示词,但在那之后的每一步,你可能只需要以下类型的提示词:
```JSON
"代码里有个 bug,请修复它。"
"我不要部分代码,给我完整的修改后的代码。"
"你的代码还是有问题。"
"请再次修改并给我完整的修正后的代码。"
"刚才还能运行,为什么现在不能运行了?"
"你没理解我的意思吗?不要改我原来的代码。"
"不要添加任何调试功能。"
"不要做我没让你做的事。"
"我让你实现的功能在哪里?"
"你听不懂我说的话吗?"
"我只要一个函数。"
"我告诉过你参考我之前的代码。"
"请不要添加不必要的注释。"
"请不要修改我原始代码的基本逻辑。"
"帮我修改代码。"
"基于我的代码修改..."
"不要改我的变量名!!!"
"不要改原来的函数名!"
"不要乱动我的变量。"
"不要添加额外的功能。"
"不要只生成框架,生成完整的代码。"
```
这听起来可能有点夸张,但实际上,这些就是我们在日常工作中可能使用的提示词。由于大语言模型的**上下文长度限制**,或者有时因为它们的**指令遵循能力**不是很强,模型可能会忘记对话早些时候讨论的内容。在 vibe coding 中,我们倾向使用长上下文的模型,并且使用指令遵循能力强的模型,我们可以通过这两者的排行或者指标来判断其是不是好模型。
或者,由于训练数据集的风格,大模型倾向于以其训练数据的风格回答。例如,有些人说话很严肃,有些人喜欢添加很多修饰,而有些大模型喜欢在代码中添加很多注释或不必要的模块。
## 附录 3:模型上下文
模型上下文可以理解为 AI 的短期记忆。它指的是在当前一次对话或一次任务中,模型能够“看到”和“记住”的所有文本内容,包括你之前输入的问题、系统提供的说明、相关资料等。
正是因为有上下文,AI 才能理解你在接着前面的内容继续提问,才能进行一轮一轮、看起来连贯自然的对话。如果没有上下文,你的每一句话在模型看来都像是一次全新的提问,它无法知道你之前说过什么,也就谈不上延续对话。
每个模型都有自己的有效上下文长度(context window)。这个长度通常用 token(可以粗略理解为“字词片段”的单位)来衡量,目前主流模型大多在 32k~128k token 之间。上下文越长,模型一次能“读”的内容就越多,例如:
- 一次性读完一篇较长的论文或报告
- 在同一轮对话中引用多篇资料、多个案例
- 让模型记住之前几轮的复杂讨论结论
当你输入的内容接近或超过模型的上下文限制时,往往会出现一些常见现象:
- 模型开始遗忘前面长文本中的细节或关键信息
- 对话进行到后面,话题逐渐偏离最初目标
- 对同一材料的不同问答之间,引用的内容不一致
这些现象并不是模型突然“变笨”,而是上下文容量被用满或接近用满后产生的自然结果。
在实际使用中,我们既希望上下文尽可能长,又要意识到:
- 上下文越长,占用的算力资源越多
- 对应的调用成本(费用)也会随之增加
因此,在设计 AI 应用时,需要在让模型看得足够多和控制成本、提升效率之间做平衡。例如:
- 对真正需要长期保留的信息进行提炼后再交给模型
- 对不再需要的细节信息,避免一遍又一遍原样塞入上下文
- 使用外部知识库等方式,把“长期记忆”交给系统,而不是强行塞进模型上下文中
## 附录 4:指令遵循能力
指令遵循能力指的是:模型在理解你的指令之后,能否准确、完整地按照你的要求执行。它不仅包括能回答问题,还包括能按指定格式、风格、步骤完成任务。
例如,下面这些都是对模型有明确要求的指令:
- 将这篇文章总结为三个要点
- 用正式、礼貌的语气写一封回复邮件
- 把这个词翻译成英文,并各造一个例句
- 从文章中提取作者、时间和主要事件
一个指令遵循能力强的模型,通常具备以下特征:
- 按要求的数量输出内容
例如要求总结三个要点,就不会给出五条。
- 覆盖所有指定的要素
例如要求提取作者、时间和事件,就不会遗漏其中任何一项。
- 遵守指定的格式和语气
例如要求使用正式语气,就不会输出过于口语化的回复。
- 不做不必要的额外延伸
例如只要求翻译和造句,就不会额外输出一大段无关解释。
在实际应用中,强指令遵循能力非常重要,原因包括:
- 提高稳定性:同样的指令在不同时间、多次运行时,输出结构和行为模式更加一致,不容易随意发挥
- 提高可复现性:当你把一段提示词配置到产品或流程中时,可以预期模型大致会怎样响应,方便测试和迭代
- 便于系统集成:当模型输出符合预期格式时,更容易与后端程序、工作流或其他工具自动对接
因此,在选择和评估一个大语言模型时,除了关注它是否聪明、知识覆盖是否广之外,还需要特别关注它的指令遵循能力。对于工业级应用来说,能否稳定而准确地执行指令,往往比偶尔给出一次惊艳回答更重要。