最近把“提示词直出小游戏”这条路子彻底玩明白了。起因是看到 IQuest-Q1 模型开源的消息想着把手头的游戏生成实验从闭源模型搬到本地模型上试试结果一发不可收拾从贪吃蛇到打砖块从“生成完就跑不起来”到“AI 自己定位 bug 并修复”整个过程非常有代表性。我把完整玩法、提示词模板、修 bug 的套路以及开源模型的适配经验全部整理出来给同样在折腾提示词工程的朋友一个可直接抄作业的参考。这个玩法适合谁如果你正在用 AI 编程工具做小项目想知道“提示词到底怎么写才能一次生成能跑的代码”或者你好奇开源模型在代码生成和 bug 修复上到底能不能打这篇内容基本覆盖了。我们不做理论空谈全是实测记录和可复现的提示词模板。1. 提示词直出小游戏——一个让人上头的玩法1.1 什么是“提示词直出小游戏”所谓“提示词直出小游戏”就是不给 AI 任何代码骨架只通过一段结构化的自然语言描述让大模型直接输出一个完整、可运行的小游戏。这个“直出”不是让 AI 写一个函数或者一个片段而是让它一口气给出完整的 HTML 文件、CSS 样式和 JavaScript 逻辑浏览器打开就能玩。我之所以迷上这个玩法是因为小游戏是所有代码生成实验里“反馈最直观”的一种。你写一个 CRUD 接口生成的结果对不对可能要等接口联调才知道但小游戏不一样鼠标一操作就知道 AI 到底理解了没有——碰撞检测对不对、计分逻辑卡不卡、边界处理有没有问题全部在十秒内暴露。这种即时反馈对调试提示词非常有帮助。有朋友会问“这和写普通业务代码有什么区别”区别在于小游戏需要模型同时处理玩法描述、视觉呈现、交互逻辑、状态管理四层信息而且每一层都可能出错。你让 AI 写一个“点击按钮弹出提示”的页面它十拿九稳但你让 AI 写一个“玩家控制角色吃食物、每吃一个分数加十、蛇身随之变长、撞墙游戏结束”的贪吃蛇它要协调的东西就多了。正因为复杂它才是测试模型能力的绝佳实验场。1.2 为什么选小游戏作为提示词实验对象小游戏是最合适的提示词实验载体原因有三个。第一范围可控。一个标准的原生小游戏HTML 加 JavaScript 通常在 200 到 500 行左右这个体量对模型来说既有挑战又不至于超出上下文窗口。体量太小测不出模型的逻辑组织能力体量太大模型容易在中途“忘了”前面的需求代码生成到一半开始胡说。第二运行环境零成本。不需要装数据库、不需要配后端、不需要处理跨域问题一个浏览器就够。这让“AI 生成的代码对不对”成了一个纯粹的问题不会被环境配置干扰。第三错误直观可见。游戏跑不起来要么是语法错误要么是逻辑死循环要么是 DOM 操作踩坑。这些错误的复现路径都很短特别适合用来研究“AI 修 bug”的能力边界。我自己做过的实验列表里有贪吃蛇、打砖块、2048、飞机射击还有用 Canvas 做的粒子特效小游戏。每一个都经历了“生成→试玩→出 bug→让 AI 修→再试玩”的循环测下来发现提示词写得好不好直接决定你要在修 bug 环节花多长时间。这不是玄学下面我拆给你看。1.3 提示词直出小游戏的四个核心要素我用了大半个月时间反复打磨最后总结出一个比较稳定的提示词模板。任何“直出小游戏”的需求都逃不出下面四个要素角色定义告诉 AI 它该以什么身份处理任务。比如“你是一名资深前端游戏开发工程师”这句话不是为了装样子而是触发模型调用更专业的知识分布生成结果会明显更规范。需求规格把玩法规矩讲清楚。这是最重要的部分最好是分条列出每条对应一个具体功能点。技术约束指定技术栈。比如“只用原生 HTML/CSS/JavaScript零依赖不使用任何第三方库”这能避免 AI 自作主张引入 CDN 资源减少跑不起来的概率。输出格式规定交付物的形态。比如“输出一个完整 HTML 文件包含内联样式和脚本直接可以双击运行”这句话能把 AI 从“代码片段”模式拉到“完整交付”模式。提示这四个要素里“输出格式”最容易被忽略但作用最大。很多人生成的小游戏跑不起来不是因为 AI 不会写代码而是因为 AI 把代码拆成了多个片段你复制的时候漏了一段。下面是一个我实测效果不错的完整提示词模板你可以直接复制改改参数就用你是一名资深前端游戏开发工程师擅长使用原生技术栈开发小游戏。 请帮我开发一个【贪吃蛇】游戏要求如下 1. 玩法玩家通过方向键控制蛇移动吃到食物后蛇身长度加一得分加10食物重新随机生成 2. 边界蛇头撞到画布边缘或撞到自己的身体游戏结束弹出得分提示 3. 计分页面顶部显示当前得分每吃一个食物加10分 4. 难度每吃5个食物蛇的移动速度加快10% 5. 视觉使用Canvas绘制蛇身为绿色圆角方块食物为红色圆形画面背景为深色 6. 操作空格键实现暂停和继续暂停时显示暂停中文字。 技术约束只用原生HTML/CSS/JavaScript不使用任何第三方库或CDN资源保证代码可以直接保存为HTML文件并在浏览器中打开运行。 输出格式请输出一个完整的HTML文件CSS写在style标签中JavaScript写在script标签中所有代码都在同一个文件内不需要额外说明。这条提示词我用了很多次基本能做到“一次生成、偶尔小修、频繁可用”。但注意这只是一个起始模板你真正玩起来之后会发现光有模板还不够还得掌握一些提示词的写作方法论。2. 提示词工程让小游戏一次跑起来的三个关键2.1 需求描述要“像素级清晰”很多人生成小游戏失败问题不在 AI而在需求描述太模糊。你说“做一个打砖块游戏”AI 就必须要猜球长什么样、砖块排几行、怎么判定输赢、打完了算赢还是接着打。每一个猜测都可能偏离你的预期但 AI 生成的代码已经在“自以为正确”的状态下写完了你要等试玩之后才发现不对。我测试过的写法里“像素级清晰”是指每个关键行为都有明确的定义。拿打砖块举例如果你只写“砖块被球击中后消失”AI 可能给你做成一碰就消失但如果你写“砖块被球击中后检查碰撞的是哪个砖块将被击中的砖块从数组中移除并重新绘制画面”AI 就会老老实实实现一套基于碰撞检测的移除逻辑。后者明显复杂但思路更接近一个真实游戏的核心逻辑。所以写提示词时我建议你拿着需求自我提问游戏的核心循环是什么玩家操作什么AI 自动运行什么结束条件是什么撞墙、撞自己、时间用完、分数达标计分和难度曲线怎么设计视觉风格是什么用 Canvas 还是 DOM有哪些边界状态暂停、重新开始、游戏结束时要不要弹窗这些问题全都在提示词里写清楚之后AI 生成的代码出 bug 的概率会大幅下降。这不是我瞎总结是我对比过“一段话描述需求”和“分条罗列需求”两种写法——同样让 Claude 和 GPT 生成贪吃蛇分条写法的首次可运行率大约高出 40%。2.2 给 AI 搭脚手架技术栈约束与结构约束AI 生成代码时有个很有意思的习惯它默认你什么都能跑所以会随手引入各种库。我在早期实验中AI 给我生成的打砖块游戏居然引用了 jQuery还有一个版本用了 Canvas 但额外加载了一个音频库。你看着它信誓旦旦地写了一个 CDN 链接但等你打开页面网络一抽风游戏就卡死了。所以技术栈约束一定要写死在提示词里。我常用的写法就是模板里那句“只用原生 HTML/CSS/JavaScript不使用任何第三方库或 CDN 资源”这句相当于给 AI 上了个紧箍咒逼它用最基础的能力把游戏实现出来。除了技术栈还有一个“结构约束”值得提让 AI 输出什么形态的交付物。每次直出小游戏我都要求“输出一个完整的 HTML 文件”这是一个很有用的技巧。因为单个 HTML 文件方便你保存、方便你分享、方便你直接在手机浏览器上打开测试。如果你是做 Web 项目也可以约定“输出两个文件一个 HTML 一个 JS”但作为实验单文件最省事。注意约束不是越严格越好。我试过把“不许使用任何 ES6 语法”也写进去结果 AI 生成的代码风格非常别扭反而 bug 更多。合理的约束是“约束技术选型不约束编码细节”给 AI 留出发挥空间效果反而好。2.3 用“小白测试法”写提示词这是一个我自己的土办法但确实管用。所谓“小白测试法”就是你写完提示词之后先把自己当成一个完全没写过代码的人把提示词从头读一遍看看有没有歧义。举个例子你想做一个“接金币”游戏提示词里写“金币从上方掉落”。这句话就有歧义金币是随机掉落还是按固定间隔掉落掉落速度是恒定还是逐渐变快金币碰到玩家角色之后是加分还是消失你站在 AI 的角度想一下它面对一个模糊指令只能“挑一个最合理的默认值”而这个默认值大概率不是你心里想的。我的方法简单粗暴提示词写完之后逐条问自己“这句话我能画出唯一的实现吗”不能就继续细化。这个方法筛掉了我至少一半的无效提示词。为了让你感受更直观我把差劲提示词和优化提示词放在一起对比差劲提示词优化提示词做一个接金币游戏做一个接金币游戏金币每2秒从屏幕顶部随机水平位置掉落玩家用鼠标控制底部篮子左右移动接住金币接到金币加10分金币落到底部失败并结束游戏要炫酷一点背景为深蓝色渐变金币为金黄色圆形每次接住金币时出现粒子爆炸效果持续0.3秒后消失让游戏好玩一些每接住10个金币金币下落速度提升20%同时金币大小缩小5%直到最小尺寸为原来的50%看到区别了吗优化之后的每一条指令都有明确的判断标准AI 不需要“猜”。这就是提示词工程最核心的思维——把需求翻译成 AI 能执行的规格说明而不是情绪和愿望。3. 实操记录从贪吃蛇到打砖块我踩过的提示词坑3.1 第一版提示词与生成结果为了验证模板的稳定性我用上面贴出的贪吃蛇提示词做了多轮测试。第一次测试用 GPT 系列模型生成结果相当顺利——一个完整 HTML 文件打开之后贪吃蛇已经能跑方向键控制、食物随机生成、碰撞后游戏结束、得分显示在顶部。整个过程耗时大约 40 秒这是一次很提气的体验。紧接着我用同一个提示词换了一个模型测试结果翻车了。AI 生成的贪吃蛇蛇身居然是一个一个独立的方块对象移动的时候所有方块同时改变坐标而不是经典的“头往前移、尾巴跟上”的逻辑。结果就是蛇移动的时候“身体分家”观感上就像一条断掉的蜈蚣。最要命的是这个版本里蛇吃到食物后新加的方块是直接堆在蛇头位置的不是加在尾巴上整条蛇越长越奇怪。这个案例让我明白了一个道理同一个提示词在不同模型上的表现可能完全不同。如果你的目标场景是“固定用某一款模型”那你的提示词可以针对它做特化但如果你的提示词需要跨模型复用就要把“蛇移动逻辑”这种关键机制也描述进去。后来我在提示词里加了半句话“蛇的移动逻辑为每一帧新蛇头根据方向键移动一格原蛇身去掉尾部一个方块其余方块保持不变。”加了这半句之后这个模型生成的贪吃蛇也基本可玩了。3.2 翻车现场AI 生成了代码但跑不起来修 bug 之前先说说这些 bug 到底是怎么出现的。我统计了一下自己两周的实测记录AI 生成小游戏最常见的三类问题是未定义变量或函数AI 在代码里调用了某个函数但定义函数的那段代码因为上下文过长被模型“遗忘”了或者粘贴时漏了一段。这类问题最基础但出现频率很高。Canvas 坐标系和碰撞检测错误比如球撞到砖块时碰撞方向算反了表现为“球明明碰到了砖块砖块却一直不掉血”。这类问题纯靠代码 review 很难一眼看出来必须运行之后才能发现。重置逻辑不完整游戏结束之后点了“重新开始”但分数、蛇身长度、画布内容没有完全重置导致新一局游戏开局就是错的。有个翻车案例让我印象非常深刻AI 生成的一个飞机射击游戏运行后所有敌机都出现在屏幕左上角的位置而且不会移动。我检查代码后发现AI 在初始化敌机时写了一个 for 循环但所有敌机的 x、y 坐标都用了同一个变量值导致它们叠在一起。这种 bug 在静态代码里特别难看穿因为逻辑语法完全正确只是数值算错了。这就是为什么我建议你无论如何都要把游戏跑起来再让 AI 修 bug——很多问题只靠“看代码”根本发现不了。3.3 修复对话模板把“帮我改”变成结构化请求踩了足够多的坑之后我总结了一套修 bug 的对话框架。核心原则是不要让 AI 自己去找 bug而是帮 AI 缩小排查范围。差劲的修 bug 请求是这样的“帮我修一下这个游戏我打开之后蛇不移动。”这个问题太模糊了AI 不知道“不移动”是什么状态——是画面卡住了还是按键没反应还是蛇在原地打转它只能猜猜偏了就会给你改一个本来没坏的地方。我的修 bug 模板是这样的我的游戏出现了问题请你帮忙修复。 问题现象游戏可以正常打开蛇也可以显示但按上下左右方向键时蛇没有任何反应。 期望表现按方向键后蛇头应该按照对应方向移动蛇身跟随。 已尝试操作我重新刷新了浏览器也检查了 console 报错发现 console 没有任何错误信息。 相关代码片段只贴出输入处理和移动逻辑的部分 [贴代码片段] 请分析原因并给出修复方案修复时只改动相关部分不要动其他无关代码。这个模板的价值在于给了 AI 四个关键信息现象、期望、尝试、代码范围。AI 拿到这些之后就能直接开始分析问题而不是先花一轮对话追问你“具体表现是什么”。这四要素我们下一节详细讲。4. 修 bug 的实战套路让 AI 帮你干活而不是帮你添乱4.1 描述 bug 的五个要素AI 修 bug 能不能修好很大程度上取决于你给它多少信息。我强烈建议所有人在每次让 AI 修 bug 之前先在笔记软件里按五要素写好描述再复制给 AI现象你看到了什么“游戏打开后是白屏”“蛇吃到食物后分数没有增加”期望你本来希望看到什么“分数应该增加10”“食物应该消失”复现路径怎么稳定触发这个 bug“打开游戏把蛇往墙壁方向移动蛇头碰到边缘就卡住不动了”环境信息在什么环境下运行“Chrome 浏览器最新版直接打开 HTML 文件无本地服务器”代码范围bug 大概出在哪一段“我怀疑是碰撞检测函数 detectCollision 里的逻辑有问题”第五个要素“代码范围”特别有意思。你不需要真的会修代码你只要能在代码里指一个方向AI 的修复准确率就能大幅提升。哪怕你完全不懂编程也可以把 AI 生成的代码贴给它然后说“代码总长度约 400 行bug 出现在每次点击按钮之后触发的那个函数附近”这都比直接甩给 AI 一整段代码然后问“哪里有问题”强得多。4.2 多轮对话中的“上下文管理”修 bug 很少能一轮完成。很多时候 AI 给你第一版修复方案你试了一下问题解决了一半另一半变得更奇怪了。这时候的对话该怎么接很多人会直接把新的报错贴给 AI然后发现 AI 给的修复方案跟上一轮完全冲突改回去之后第一个问题又回来了。这个问题的根源是上下文漂移——AI 在一轮长对话里对前面代码的记忆会变得模糊尤其当对话轮次多、代码反复修改之后它容易把“当前状态”理解成“初始状态”。我的经验是多轮修复中每轮都要重新明确当前代码的完整状态。具体做法是每做一次修复都把最新的完整代码保存到一个文件里下一轮对话时把最新代码重新贴给 AI并加一句话“以下是最新版本的完整代码基于这个版本进行修复不要参考早前的旧版本。”这能非常有效地防止 AI 把新旧代码混着改。另外如果你的 AI 工具支持“代码对比”或“补丁”功能尽量用补丁形式提交修复这样你能看到 AI 到底改了哪几行而不是一头雾水地等它输出一坨新代码。很多 AI 编程工具内置了 diff 视图强烈建议开启。4.3 用最小复现法逼出有效修复这是我压箱底的一个技巧。有时候 bug 特别难缠AI 看了代码也说不知道问题在哪这时候我一般会做一件事手动构造一个最小复现场景。举个例子AI 生成的打砖块游戏有一个 bug——当球速很快的时候球会直接穿过砖块碰撞检测像失效了一样。AI 修了两轮都没修好一会儿说“可能是坐标系换算问题”一会儿说“可能是画布缩放导致的”全是猜测。后来我做了个最小复现实验把球速在代码里直接调成一个很小的值碰撞检测没问题再把球速调大问题出现。然后我让 AI 只针对“球在一个帧内移动的距离超过砖块厚度时碰撞检测失效”这个场景写一个独立的测试函数。AI 最终给了一个解决方案在碰撞检测时把球的位置按上一帧位置和当前位置做插值检查整条路径上是否碰到砖块。这其实就是经典 swept collision detection扫掠碰撞检测的思路。这个案例对我的启发是不要让 AI 在你的完整代码海里捞针而是把问题发生的边界条件摸清楚再让 AI 针对边界条件写一个小型验证实验。最小复现法不仅适用于 AI 修 bug也适用于你自己定位问题的思路——当你把“复现条件”控制在最小的可观察范围内问题原因会清晰得多。5. IQuest-Q1 模型开源本地化编程助手的新选择5.1 这个模型到底是什么定位IQuest-Q1 是一个在推理和代码生成方向做了专门优化的开源模型。它的命名里带“Q1”可以理解为第一代研究版本。这类模型的典型特征是为了保证生成质量参数量不会太小但通过量化、剪枝等手段可以在消费级显卡上跑起来。对做提示词工程的人来说它最大的意义是——你不用再受制于云端 API 的调用限制把模型下到本地想怎么折腾都行。但这不意味着开源模型就能直接平替 Claude 或 GPT-4。实测下来IQuest-Q1 在“代码生成”和“代码修复”两个任务上的表现有明显差异。代码生成方面它能流畅地写出 HTML/JavaScript 小游戏但生成速度比云端模型慢不少而且上下文越长到后半段越容易出现“逻辑松散”的毛病。代码修复方面倒是给了我一个惊喜它对“局部代码修改”的理解比较扎实你给它一段明确标注了问题函数和期望行为的提示词它给出的补丁很多时候可以直接合并。我把实验结过果整理成了一张表方便你判断要不要拿它来做本地编程助手维度IQuest-Q1 实测表现备注完整小游戏生成70% 左右首次可运行依赖提示词精细程度与闭源模型差距明显单函数级代码生成表现稳定适合补全 helper、工具函数bug 定位需要提供明确现象与范围给足上下文后准确率可接受bug 修复局部修改质量不错不要让它大范围重构运行环境支持本地部署需要至少 8GB 显存以上设备流畅推理5.2 本地部署开源模型的价值与门槛为什么开源模型值得关注因为有些场景里闭源 API 真顶不上去。首先是数据安全。我平时会拿一些还没公开的项目片段让 AI 修 bug如果走云端 API代码就等于交给了第三方。自己本地起一个模型整个过程留在电脑里心里踏实得多。其次是可定制性。闭源模型是一个黑盒你觉得它生成的提示词风格不好你没办法改但开源模型你可以做模型微调fine-tune或者改它的系统提示词system prompt让它更贴合你的使用习惯。在提示词直出小游戏的场景里你甚至可以在 system prompt 里固定一套“游戏生成规则模板”让模型每次生成都遵循你的偏好。门槛当然也有。本地部署需要你装显卡驱动、配置 Python 环境、下载模型权重。对纯玩提示词的小白用户来说这第一步就能劝退很多人。我的建议是如果你平时基本只用云端模型那就先不用折腾本地专心把提示词修好如果你有编程基础且对数据隐私有要求再考虑花一个下午把环境搭起来。注意IQuest-Q1 属于开源模型但在不同硬件上的推理速度差异很大。我实测在 RTX 4090 上生成一个 300 行的贪吃蛇大约需要 90 秒在 2060 上可能要 4 到 5 分钟。如果你的显卡性能一般把模型换成量化版本能大幅提速代价是生成质量略有下降。5.3 提示词直出小游戏在开源模型上的调优技巧开源模型对提示词的“敏感度”比闭源模型更高。什么意思同一段提示词Claude 能自动理解你隐含的意图但开源模型可能就“一根筋”——你说了什么它只做什么你没说的它默认不做。这既是坏事也是好事。坏处是如果你提示词写得不完整开源模型生成的游戏会缺东少西。好处是如果你把提示词写得很细开源模型的表现会非常有底线不容易像闭源模型那样有自己的“小创意”。针对 IQuest-Q1我总结了几条调优经验把“游戏循环”显式写清楚。比如要求每一帧的执行顺序是“清空画布→更新物体位置→检测碰撞→绘制→请求下一帧”。这个顺序细节对开源模型特别重要因为它的默认行为可能是不按固定帧率走导致动画闪烁。多用“示例输入/输出”。当你描述某个功能时最好附上一个具体的输入输出对。比如“当分数达到 100 时在页面右上角显示一个金色奖杯图标”。这一点开源模型比闭源模型更需要。分两步生成而不是一步到位。对于较复杂的小游戏让模型先输出“数据结构定义和全局变量”再输出“具体函数实现”。开源模型在长上下文下的连贯性不如闭源模型分段生成的效果明显更好。这最后一条尤其关键。我用 IQuest-Q1 做打砖块的实验时要求它一次输出完整游戏结果它把 Ball 对象的属性定义和实际使用写得不一致后来我改成“先定义 Ball、Brick、GameState 三个对象结构再实现更新和渲染”问题就没出现。6. 常见问题速查与排错实录6.1 AI 生成的代码有语法错误这不是稀罕事尤其是模型上下文很长、输出被截断的时候。我遇到最多的是“括号不匹配”和“函数少了一个闭合花括号”。处理方法很简单先把报错信息原样贴给 AI并叫它只检查语法问题。如果 AI 自己查不出来就手动检查生成代码的尾部——多半是 script 标签没有被正确闭合。还有一个笨办法把代码贴到 Node.js 里跑node --check语法检查命令报错行号能精确到具体位置效率比让 AI 猜高得多。node --check game.js如果是单 HTML 文件可以先用浏览器打开按 F12 看 Console 面板里的红色报错把报错信息直接复制给 AI效果通常不错。6.2 提示词导致代码无限循环这是我见过最迷的 bugAI 为了让游戏一直运行直接在代码里写了一个while(true)循环结果整个浏览器标签页卡死。这是因为很多追求“AI 直出”的人给提示词里加了一句“游戏需要持续运行”模型就真的给你写死循环了。正确的做法是在提示词里明确“游戏循环通过 requestAnimationFrame 实现”而不是“持续运行”。这两个词在 AI 眼中的差别巨大。前者是浏览器原生的逐帧动画机制后者是 CPU 空转的灾难。如果你已经拿到了while(true)代码直接告诉 AI“这段代码导致了页面卡死请用 requestAnimationFrame 重构主循环。”大多数模型都能改对。6.3 模型“幻觉”组件或 APIAI 会一本正经地生成一些根本不存在的 API 或者组件。我遇到过一个情况AI 生成的游戏里调用了一个gameAudio.playSound()方法但整个代码里根本没有定义这个方法还有一个更离谱的是AI 引用了CanvasRenderingContext2D.drawRoundedRect()这 API 实际上不存在好在报错很快就能发现。这种问题的处理核心是“让 AI 只用基础 API”。在提示词里加一句“只使用标准 JavaScript API 和 Canvas API不要使用任何未定义的库函数”幻觉概率会下降很多。另外修 bug 时一定要告诉 AI“如果修复方案中需要调用一个新的函数请把这个函数的定义也写出来。”这句话可以帮助堵住大部分半吊子修复。6.4 上下文爆炸导致修复越改越乱多轮对话长了之后AI 会把每一轮贴过的代码都当作用户需求的一部分修复时会莫名奇妙地把旧代码又加回来。最终的代码越来越长但功能越来越乱。我自己最长的一次对话修同一个游戏修了九轮代码从 400 行膨胀到 700 行bug 还在。我的解决办法是“对话刷新”每隔几轮开一个新对话把最新版本的完整代码加一句“以下是当前完整代码基于此修复如下问题”贴给 AI。新对话的上下文是干净的AI 只关注当前版本修复效果会好很多。提示如果你的 AI 聊天工具有“新建会话”快捷键请把它当作修 bug 的常规操作。不要因为“接着聊方便”就一直续同一个对话上下文越堆越多AI 的注意力分配就越分散。一个让我印象深刻的收尾技巧最后分享一个我最近经常用的技巧在让 AI 修 bug 的提示词末尾加一句“修复完成后请列出你修改的文件名、修改的函数名、修改原因用清单输出。”这句话看起来很啰嗦但非常好用。它逼着 AI 在给出代码之前先整理思路而且在代码合并后你可以快速对照知道它到底动了哪里。我后来用 IQuest-Q1 修一个小游戏 bug 的时候就是因为这个清单式输出一眼看出模型改错了函数——它修改了一个名字相近但根本不相关的函数实际 bug 纹丝不动。看到清单的那一刻我意识到这个小小的附加要求帮我省了至少十分钟的代码比对时间。提示词直出小游戏这条路好玩的不是最终的成品而是你亲眼看着一句中文需求变成一个能玩的东西再亲手陪着 AI 把它修到完美的全过程。这个循环一旦跑通你会发现“让 AI 写程序”和“让 AI 帮你真正完成一个项目”之间差的不是模型能力而是你自己对提示词的理解深度。