让蛙兄接住第一颗泡泡

蛙兄看着刚刚准备好的 hoppy-lab。

“实验室已经有了。我们现在就开始研究股票？”

蛙博士摇摇头。

“先别急。我们还不知道 Python 能不能在这里运行，也不知道 AI 能不能把文件放对地方。万一出错，我们甚至还没试过怎样一起调查。”

“那拿什么试？”

“先做一个小游戏。”

蛙兄愣了一下：

“我们不是来学量化的吗？”

“正因为是量化课，才不要一上来就把程序、市场数据和研究假设混在一起。先找一件结果一眼就能看懂的小事，把 AI 和环境检查清楚。”

这个小游戏只需要做到三件事：

• 蛙兄可以左右移动；
• 泡泡会从上方落下；
• 接住泡泡以后，分数会增加。

它不是量化实验。

它是实验室的第一次开机测试。

如果现在直接获取股价数据，一旦失败，可能是环境没准备好，也可能是网络、数据接口、股票代码或程序本身出了问题。好几个问题挤在一起，小白很难知道先查谁。

小游戏就直白多了：窗口有没有出现，青蛙能不能移动，泡泡有没有落下，接住以后分数有没有增加，亲眼一看就知道。

今天只有两次主要交棒

这一课看起来要碰到 Python、环境和游戏，但你真正需要交给 AI 的主要任务只有两个：

1. 先检查电脑和当前项目，需要什么再补什么；
2. 环境可以运行以后，再创建并启动小游戏。

中间如果弹出授权，需要你自己决定；如果出现报错，就把真实现场继续交给 AI。你不需要在开始前学会一整套安装命令。

第一次交棒：先检查，需要什么再补什么

你不需要自己判断电脑里缺什么，也不需要照着课程逐条输入安装命令。

把目标告诉 AI，让它先检查，再根据真实情况补齐环境：

交给 AI 研究助手

复制

我准备在当前项目里制作一个 Python 小游戏。请先检查当前项目、操作系统和终端，以及 uv、Python 和项目内 .venv 是否已经存在并且可用。

请根据实际检查结果补齐环境：

• uv 已经可用就直接复用；缺少时，使用适合当前系统的官方方式安装；
• Python 已经可用并适合当前项目就复用；缺少或版本不合适时，由 uv 准备一个稳定、兼容的版本；
• 项目内已经有能够正常使用的 .venv 就复用；没有时，再使用 uv 在当前项目中创建。

不要重复安装已经能用的内容，也暂时不要创建游戏。需要联网或修改项目之外的文件时，请说明用途；如果界面弹出授权请求，我会阅读操作范围后再决定是否允许。

完成后请重新检查，并用大白话总结：复用了什么、新安装了什么、.venv 在哪里，以及当前环境是否已经可以进入小游戏开发。

这段任务说明可以直接使用，也可以换成自己的说法。它真正表达的是：

先检查真实电脑
→ 能用的继续用
→ 缺少的才安装
→ 创建项目自己的环境
→ 再次检查真实结果

AI 可能会分几步完成检查、安装和验证。你不必遥控每一条命令，只要留意它有没有遵守“先检查、缺什么补什么”的边界。

如果三项都缺，AI 通常会走下面这条路线；如果电脑里已经有一部分，就直接跳过对应步骤：

先准备独立运行的 uv
→ 让 uv 准备合适的 Python
→ 在当前项目里创建 .venv

uv 可以独立安装，并继续替项目准备 Python，所以电脑里还没有 Python 也不碍事。你只需要先认识三个名字：

• Python：真正运行 Python 程序的发动机；
• uv：帮助项目准备 Python、环境和依赖的工具；
• .venv：只属于当前项目的隔离空间，避免和电脑上的其他 Python 项目混在一起。

你不需要手动编辑 .venv，也不需要背安装命令。让 AI 根据真实系统采用当前官方方案，再重新检查结果即可。

想查看原始说明，可以参考 uv 安装文档、Python 管理文档和虚拟环境文档。这些页面的核对日期为 2026 年 8 月 30 日。

Codex 停下来，先看看是不是在等你

安装 uv、下载 Python 或获取游戏依赖时，Codex 可能需要访问互联网，也可能需要在当前项目之外写入工具文件。

这时，它可能不会继续往下跑，而是停下来等待你批准。

蛙兄看着没有继续变化的屏幕，小声问：

“它是不是卡住了？”

蛙博士指了指输入框旁边的权限选项：

“它是在等你决定，哪些事情可以替你做。”

按照我们实际验证时的 Codex 界面，可以看到三种不同程度的选择：

• 请求批准：涉及外部文件或互联网等操作时，经常需要你逐次确认；
• 帮我批准：Codex 可以继续完成低风险的常规操作，检测到风险时再请求你批准；
• 完全访问权限：可以不受同样限制地访问互联网和电脑文件。

在专门创建、内容单纯的 hoppy-lab 中，我们建议选择帮我批准。

这样可以减少常规操作反复弹窗，又不会像“完全访问权限”一样把边界一下放得太宽。

如果你心里没底，继续使用请求批准也完全没问题。它只是需要你多确认几次，并不代表环境装错了。

但“帮我批准”不等于以后完全不会询问。真正需要确认的动作出现时，你仍然要阅读请求，再亲手决定是否允许。

当前截图和按钮名称的核对日期为 2026 年 8 月 30 日。界面以后可能变化，不必死找一模一样的文字。只要记住：优先选择能够让常规工作继续、同时仍会拦下风险操作的中间方案，不为省事直接开放整台电脑。

如果使用 WorkBuddy，权限入口和名称可能不同。先让它解释当前授权范围，再坚持同一条原则：只给完成这间实验室所需的权限。

第二次交棒：让小游戏真正跑起来

现在应该已经具备：

• 可以使用的 uv；
• AI 已经确认可以使用的 Python；
• 当前项目里的 .venv；
• 一条能够继续添加依赖并运行程序的路线。

这时候才轮到小游戏真正进场。

游戏窗口和键盘操作通常需要借用一个现成的图形库。这种项目借来的功能零件，也叫“依赖包”。选哪一个、怎样安装，继续让 AI 根据当前环境决定。

下面这段任务说明可以直接使用。你也可以保留目标和边界，换成自己的说法：

交给 AI 研究助手

复制

请在当前项目里创建并运行一个最小可操作的 2D Python 小游戏。

游戏规则如下：

• 画面底部有一个绿色的青蛙角色；
• 玩家可以使用键盘左右方向键控制青蛙水平移动，青蛙不能跑出窗口；
• 泡泡从画面顶部的随机位置向下落；
• 青蛙接住泡泡以后，分数增加 1，泡泡重新从顶部出现；
• 没接住的泡泡落出画面后直接重新出现，第一版不用扣分；
• 画面上清楚显示当前分数；
• 玩家关闭窗口时，程序能够正常结束。

第一版只使用简单图形和文字。不要添加外部图片素材、音乐、复杂动画、关卡、联网功能和其他额外玩法。

请先检查当前项目已有文件，避免覆盖无关内容。选择一个与当前 Python 兼容、适合完成简单 2D 窗口的最小依赖，用一句话说明选择它的理由，并通过 uv 把它加入当前项目的 .venv，不要装进整台电脑共用的 Python 环境。

动手前，先用大白话复述你理解的玩法。然后完成最小版本并实际运行，不要只生成代码。

如果运行失败，请读取真实报错并继续调查和修复。程序成功启动后，告诉我怎样操作，并让我亲自验收。如果当前工具无法持续展示游戏窗口，请明确告诉我需要亲自执行哪一步，等我运行后，再根据真实结果或报错继续处理。

它比环境检查的任务说明更详细，因为这里需要把“做成什么样”说清楚。你仍然不必逐字照搬，只要保留下面几类信息：

• 青蛙、泡泡、移动和计分怎样工作；
• 第一版暂时不要哪些额外功能；
• 依赖应该进入当前项目的 .venv；
• AI 需要先复述自己的理解；
• 它不只负责写代码，还要实际运行并处理报错。

AI 可能选择不同的简单图形库，也可能采用不同的文件结构。

我们不要求每个人得到一模一样的代码。只要它说明选择原因，把依赖放进项目环境，并留下能够继续运行的最小项目即可。

AI 说完成了以后，请你亲自玩一下

当 AI 运行程序时，屏幕上应该出现一个小游戏窗口。如果当前工具无法替你持续展示窗口，它应该告诉你亲自运行哪一步。这不等于失败，只是最后的观察需要由你完成。

不要只看它最后回复了一句“已经完成”。

请亲手检查：

• 窗口是否真的出现；
• 左右按键是否能让青蛙移动；
• 泡泡是否从上方向下运动；
• 接住泡泡以后，分数是否真的增加。

具体颜色、速度、字体和布局不需要和课程示例一样。

青蛙也可以暂时只是一个绿色圆形或方块。第一版的任务是证明玩法和运行链路成立，不是参加美术比赛。

如果窗口没有出现，可以继续问 AI：

程序没有出现可操作窗口。先确认它是已经退出、仍在运行，还是图形环境没有成功打开。请读取真实运行状态和输出，不要只根据代码猜测。

如果窗口出现了，但按键无效或泡泡不动，可以说：

窗口已经出现，但我实际观察到的是：方向键没有效果，泡泡也没有移动。请先对照当前代码解释输入和画面更新是否真的在运行，再只修改一个最可能的问题并重新启动。

你描述得越接近自己真正看到的现象，AI 越容易继续调查。

如果卡住，把真实现场继续交给 AI

不同电脑可能会在不同地方停下来：有人卡在下载或权限，有人暂时找不到刚安装的工具，也有人能打开窗口，却发现按键没有反应。

课程不可能提前列完所有报错，也没有必要。

无论卡在环境还是游戏，都不要只说“失败了”，也不要从搜索结果里连续复制十种修复命令。保留刚才的完整输出和你亲眼看到的现象，再继续说：

卡住时继续对话

复制

先不要重新安装全部环境，也不要同时尝试多个修复。

请读取刚才执行的命令、完整输出和退出状态，再结合我实际看到的现象，用大白话判断最可能的原因。

先只处理一个方向，然后重新执行同一个检查或操作，并比较前后结果有什么变化。

这套循环可以反复使用：

保留完整现场
→ 请 AI 解释最可能的原因
→ 一次只试一个方案
→ 重新运行同一个检查
→ 比较新旧结果
→ 再决定下一步

如果报错内容变了，也是一条新信息。它可能说明刚才的问题已经越过去了，现在停在下一处。

游戏跑起来以后，故意改一件小事

第一次成功运行，只能说明 AI 和环境已经合作完成了一个版本。

我们再做一次小修改，看看这条合作路线能不能继续使用。

如果不知道改什么，可以先让 AI 提供选择：

请给我三个只改一个主要地方的小变化。每个选项用一句大白话说明会看到什么。现在先不要修改，等我选择。

它可能建议：

• 让青蛙移动得快一点；
• 改变泡泡颜色；
• 漏掉泡泡以后扣一分；
• 接到五颗泡泡以后显示胜利。

选择一个你看得懂的变化，再告诉 AI：

我选择这一项。请只完成这个变化，不要顺便增加其他功能。修改后重新运行，让我用实际画面确认它已经生效。

这一步很小，却很重要。

你没有先寻找代码的哪一行负责速度或颜色，而是先描述想看到的结果，再让 AI 修改、运行，最后用画面验收。

这就是以后研究程序也会反复使用的协作方式：

说清变化
→ AI 修改
→ 重新运行
→ 观察真实结果
→ 决定是否继续

最后，请 AI 帮你整理工作台

游戏玩完以后，不需要背下刚才出现的所有命令。

但你应该知道这间实验室里大致留下了什么，以及下次怎样继续。

可以这样问：

和 AI 研究助手一起验收

复制

请用大白话总结这次实际完成的内容：

1. 当前项目里创建了哪些主要文件；
2. uv、Python、.venv 和游戏依赖各自解决什么问题，它们之间是什么关系；
3. 当前项目的 .venv 在哪里，Python 和游戏依赖由谁管理；
4. 下次回到这个项目时，我应该怎样让你重新运行小游戏；
5. 这次成功证明了什么，又没有证明什么。

请根据当前项目和真实运行结果回答，不要给我一份与现场无关的通用教程。

这次成功至少说明：

• AI 能够在你选定的项目里创建和读取文件；
• 当前 Python 环境能够运行一个带依赖的程序；
• 你能够通过观察画面判断程序有没有完成目标；
• 出现问题或想要变化时，你知道怎样继续和 AI 对话。

但它没有证明：

• 市场数据接口已经可用；
• 股价数据一定正确；
• 量化假设已经得到支持；
• AI 以后写出的每个程序都会自动正确。

实验室完成了第一次开机测试。

下一步，我们要把真正属于量化研究的原料搬进来：市场数据。

网页上明明能看到股票价格，为什么程序不一定能直接拿到？

这个问题，会把我们带到下一次实验。