这篇能做出什么
读完并跟着做，你会得到三样东西：
一个能直接在浏览器里玩的「打砖块」小游戏。它由腾讯 WorkBuddy 里选用 Hy4 模型，根据一段自然语言描述生成，不需要你手写游戏逻辑。
一套可复用的提示词写法：把「一句话需求」补成「一句话 + 验收标准 + 技术约束」，让模型少跑偏。
一条跑通的构建链路：本地 npm run dev 能调试，npm run build 能产出静态文件，双击产物前先过一遍 preview。
顺带还会练习一件容易被忽略的事：长任务里怎么判断它有没有偏离目标。生成一个几百行的游戏，模型要连续做十几步操作，中途「顺手帮你重构一下」是很常见的，这篇会给出一套逐条对照的检查方法。
说明一句：WorkBuddy 的界面、模型列表会随版本变化，下面按常见的「工作目录 + 会话 + 模型选择」结构来讲，具体按钮名称以你客户端当前展示为准；Node.js 版本同理，以官方文档当前版本为准。
前置条件清单
动手之前，确认这几项都齐了：
- 已安装并登录腾讯 WorkBuddy 客户端（下载与安装方式以官方页面为准）。
- 模型选择里能看到 Hy4，并能正常对话。如果列表里没有，先更新客户端，或按官方说明确认账号权限。
- 本机装了 Node.js LTS 与 npm，终端里
node -v、npm -v都能输出版本号。 - 一个干净的工程目录，路径里不要有空格和中文，例如
~/code/buddy-breakout。 - 会用终端做三件事：
cd进目录、npm install、npm run dev。 - 建议装个 Git，每轮改稿前提交一次，回滚成本几乎为零。
不需要你懂 Canvas API，也不需要你会写碰撞检测——这些正是交给模型的部分。但你得能看懂「球穿过挡板了」「分数不刷新」这类现象，把它描述清楚。
分步骤
步骤 1：先把脚手架搭起来，别让模型从零建工程
很多人习惯让 AI 一次性把项目结构、依赖、配置全生成出来，结果构建报错时你分不清是代码问题还是配置问题。更稳的做法是：工程骨架你自己搭，业务代码交给模型。
在终端里执行（vanilla 是原生 JS 模板，够用且依赖少）：
```bash
mkdir buddy-breakout && cd buddy-breakout
npm create vite@latest . -- --template vanilla
npm install
npm run dev
```
浏览器打开终端里提示的地址，看到模板页面就说明链路通了，先按 Ctrl+C 停掉。这时目录里已经有 index.html、src/、package.json，构建配置也齐了。后面模型只需要往 src/ 里填东西。
顺手提交一次基线：
```bash
git init
git add -A
git commit -m "chore: vite 脚手架基线"
```
步骤 2：把「一句话」补成可验收的需求
真正意义上的「一句话复刻」是能跑通的，比如：
> 用原生 JS 和 Canvas 做一个打砖块小游戏。
但这句话里的「打砖块」有一百种实现：挡板跟不跟鼠标、有几条命、球速多少、失败后怎么重开，模型只能自己猜。猜错一次，你就要多改一轮。所以要在后面补上验收标准——验收标准不是给模型看的礼貌用语，是给你自己验收用的清单。
把下面这段整段粘进 WorkBuddy 的对话框（text 代码块，可直接照抄改）：
```text
在当前项目的 src/ 目录下，用原生 JavaScript + Canvas 实现一个打砖块小游戏（Breakout）。
禁止引入任何第三方库，禁止使用图片和音频文件，所有图形用 Canvas 绘制。
验收标准：
1. 打开页面立刻开始，画布逻辑尺寸 800x600，随窗口等比缩放且不变形。
2. 鼠标左右移动、键盘左右方向键，都能控制挡板；挡板不能移出画布边界。
3. 砖块 6 列 4 行，按行区分颜色，被球击中后消失并加 10 分。
4. 球碰到左、右、上边界反弹；碰到下边界扣 1 条命，共 3 条命。
5. 生命为 0 时画面显示 Game Over 和「按空格重开」，按空格能完整重置分数、生命和砖块。
6. 分数与剩余生命常驻显示在画布左上角，字号不小于 16px。
7. 代码拆成 main.js（入口与循环）、game.js（状态与碰撞）、config.js（常量）三个文件，关键逻辑写中文注释。
先输出你准备创建和修改的文件清单、实现顺序，以及每条验收标准对应的实现思路。
我确认之后你再开始写代码，不要一次性把所有文件写死。
```
最后两句是关键：先给计划、后写代码。这一步能挡掉相当一部分「它理解错了但一路写到底」的情况。
步骤 3：在 WorkBuddy 里发起任务，并锁定工作目录
打开客户端后，按这个顺序操作：
1. 新建会话，把工作目录指向刚才的 buddy-breakout 文件夹。目录选错是新手最常见的问题——模型会把文件生成到桌面或者用户根目录，你在项目里怎么找都找不到。
2. 在模型选择处切到 Hy4。名称与可选状态以客户端当前展示为准。
3. 粘贴步骤 2 的提示词，发送。
它大概率会先回一份文件清单。这时候你要做一次人工检查：
- 三个文件是否都在
src/下，有没有跑到项目根目录去； - 有没有偷偷引入
pixi.js、phaser之类你明确禁止的库； - 有没有把
index.html里的<script>入口改对。
确认没问题，回一句「按这个计划执行」。如果它擅自加了依赖，直接回「不加任何依赖，用原生 Canvas 重写计划」。
步骤 4：本地跑起来，逐条对验收标准
```bash
npm run dev
```
打开浏览器，拿步骤 2 的 7 条标准当检查表，一条一条过。不要凭感觉说「好像还行」，具体到行为：
- 用鼠标把挡板推到最左边，看它是否卡在边界而不是滑出去；
- 让球落到最下方，看生命从 3 变 2，而不是直接 Game Over；
- 三条命耗尽后按空格，看分数是否归零、砖块是否全部复原；
- 把窗口拖窄，看画布是否等比缩放、有没有被拉伸。
发现问题就记下来，先别急着改，攒到下一轮一起提。
步骤 5：分轮改稿，每轮只做一件事
最影响效率的做法是：一次贴 15 条修改意见过去。模型容易只改前 5 条，后面的被「理解」掉。更稳的节奏是一轮一个主题，每轮用同一个句式：
> 现象 + 期望 + 改动范围
第一轮，手感：
```text
现在的手感有问题：球打到挡板边缘和打到正中间，反弹角度几乎一样，玩起来很平。
期望：按击中位置决定反弹角度，打在挡板左三分之一往左偏，右三分之一往右偏，中间接近垂直反弹。
改动范围：只修改 game.js 里球与挡板的碰撞处理，不要动渲染、不要动配置项名称。
```
第二轮，视觉：
```text
砖块现在是纯色方块，太素。
期望：砖块带 2px 圆角和轻微内阴影，球移动时留 6 帧半透明拖尾，挡板两端做圆角。
改动范围：只改渲染相关函数，游戏逻辑不变。仍不允许用图片资源。
```
第三轮，边界情况：
```text
这三个场景需要处理：
1. 浏览器标签页切走再切回来，球会瞬移，改成切走时暂停、切回来时给 1 秒倒计时再继续。
2. 窗口 resize 后画布变模糊，用 devicePixelRatio 做高清适配。
3. 页面失焦时键盘事件卡住导致挡板一直往一个方向走，改为失焦时清空按键状态。
改动范围：main.js 的循环与事件部分，加上 config.js 里的新常量。
```
每轮改完，git commit 一次，再跑一遍验收清单。三轮下来，一个手感尚可、视觉不寒酸的复刻版本就有了。
步骤 6：跑通构建，检查产物
开发态能跑不代表构建产物能用。执行：
```bash
npm run build
npm run preview
```
build 会在 dist/ 下产出静态文件，preview 起一个本地服务让你验证产物。不要直接双击 dist/index.html 用 file:// 打开，模块加载和路径解析在这个协议下经常出问题，白屏了你还会以为是构建失败。
如果你打算把游戏放到某个子路径下（比如站点下的 /games/breakout/），在 vite.config.js 里加一行相对基路径，避免部署后资源 404：
```javascript
// vite.config.js
import { defineConfig } from 'vite'
export default defineConfig({
base: './',
})
```
再跑一次 npm run build，产物可以直接丢到任意静态托管上。
步骤 7：观察长任务里有没有偏离目标
这是这篇最想让你带走的一节。一次生成几百行游戏，属于典型的「长任务」：模型要连续做创建文件、写逻辑、改入口、调整样式十几步。任务越长，越容易发生三种漂移：
漂移一：悄悄改需求。 比如你要求「3 条命」，它写着写着变成「无限命，撞到底部直接重开」，理由是「体验更流畅」。防范办法很简单：每次它说要「优化一下」时，回一句「先复述一遍我的 7 条验收标准，再说明你要改哪几条」。
漂移二：范围膨胀。 你说改碰撞角度，它顺手把整个渲染层重构成类组件。这类改动风险高、收益低，因为你的验收清单里根本没有渲染重构这一项。直接回：「只改我指定的函数，其他文件保持原样。」
漂移三：上下文变长后开始遗忘。 对话到几十轮之后，它可能忘记「禁止用图片资源」这条约束，开始给你写 new Image()。这时候别硬聊，开一个新会话，把当前三个文件的完整内容 + 验收清单贴进去，说「这是现状，接下来只做这一条修改」。新会话的上下文干净，命中率明显更高。
一个实用的自查节奏：每完成一轮改稿，花 60 秒对着验收清单打勾，发现某条从「通过」变回「不通过」，基本就是漂移发生了，立刻回滚到上一个 commit 再重提需求。
常见坑与排错
1. 模型没切到 Hy4，输出风格和长任务表现不一样。
先确认会话顶部显示的模型名。切换模型后建议新建会话，别在旧对话里直接切，历史上下文会干扰。
2. 文件生成到了错误目录。
症状是项目里 src/ 空着，桌面多出几个 js 文件。原因通常是工作目录没指定。让它先执行一次列目录、打印当前路径，确认位置再动手。
3. npm run dev 提示端口被占用。
换端口即可：
```bash
npm run dev -- --port 5174
```
4. 画布模糊、球有锯齿。
高分屏下要按 devicePixelRatio 放大画布后端尺寸，再用 CSS 缩回视觉尺寸。这条可以直接写进第三轮改稿需求里。
5. 键盘控制没反应。
常见原因是把 keydown 监听绑在了 <canvas> 上，而 canvas 没有焦点。改成监听 window，并在 keyup 时清空按键状态。
6. 构建报「找不到模块」，本地 dev 却正常。
多为文件名大小写不一致——本地文件系统不敏感，构建环境敏感。统一改成小写文件名再提交。
7. dist 打开白屏。
先确认是通过 npm run preview 或静态服务器访问，而不是 file:// 直开；再检查 base 配置是否匹配部署路径。
8. 模型引用了 CDN 或 npm 包但没安装。
这类「隐形依赖」在构建时才炸。让它把所有依赖列出来，二选一：要么 npm install 装上，要么改成本地实现。小游戏场景建议后者。
9. 一轮提太多修改，只改了一半。
改成一轮一个主题、带明确「改动范围」。改完立刻验证，别攒着。
10. 越改越乱，想回到上一版。
这就是步骤 1 里 git init 的价值。git diff 看它到底动了什么，git checkout . 一键回到上次提交。
下一步建议
游戏跑通之后，可以顺着这几个方向继续练：
- 换一种复刻对象：贪吃蛇、2048、扫雷，用同一套「一句话 + 验收标准 + 分轮改稿」的模板走一遍，你会发现第 2 次比第 1 次省一半时间。
- 加音效：用 Web Audio API 现场合成打击音，仍然不引入任何素材文件，正好检验模型会不会偷偷给你塞一个 mp3 链接。
- 把数据外置：让砖块布局改成从 JSON 读，这样加关卡不用改代码，也是练习「约束改动范围」的好题目。
- 部署上线：
dist/是纯静态文件，丢到任意静态托管都能跑，具体操作以对应平台的官方文档为准。 - 沉淀提示词库：把这次用过的三段提示词存下来——初始需求、改稿三件套、漂移纠正话术。以后做内部小工具、数据看板、脚本自动化，换掉业务描述就能复用。
最后提醒一句：这套流程的价值不在于「一句话生成游戏」本身，而在于你始终掌握验收标准。模型负责写，你负责定义「什么叫做完了」，这个分工在越长的任务里越重要。