企业官网建设流程全解析

最近把“提示词直出小游戏”这条路子彻底玩明白了。起因是看到 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 的角度想一下，它面对一个模糊指令，只能“挑一个最合理的默认值”，而这个默认值大概率不是你心里想的。

我的方法简单粗暴：提示词写完之后，逐条问自己“这句话我能画出唯一的实现吗？”不能，就继续细化。这个方法筛掉了我至少一半的无效提示词。

为了让你感受更直观，我把差劲提示词和优化提示词放在一起对比：

看到区别了吗？优化之后的每一条指令都有明确的判断标准，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 小游戏，但生成速度比云端模型慢不少，而且上下文越长，到后半段越容易出现“逻辑松散”的毛病。代码修复方面倒是给了我一个惊喜：它对“局部代码修改”的理解比较扎实，你给它一段明确标注了问题函数和期望行为的提示词，它给出的补丁很多时候可以直接合并。

我把实验结过果整理成了一张表，方便你判断要不要拿它来做本地编程助手：

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 提示词导致代码无限循环

这是我见过最迷的 bug：AI 为了让游戏一直运行，直接在代码里写了一个while(true)循环，结果整个浏览器标签页卡死。这是因为很多追求“AI 直出”的人，给提示词里加了一句“游戏需要持续运行”，模型就真的给你写死循环了。

正确的做法是，在提示词里明确“游戏循环通过 requestAnimationFrame 实现”，而不是“持续运行”。这两个词在 AI 眼中的差别巨大。前者是浏览器原生的逐帧动画机制，后者是 CPU 空转的灾难。

如果你已经拿到了while(true)代码，直接告诉 AI：“这段代码导致了页面卡死，请用 requestAnimationFrame 重构主循环。”大多数模型都能改对。

6.3 模型“幻觉”组件或 API

AI 会一本正经地生成一些根本不存在的 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 帮你真正完成一个项目”之间，差的不是模型能力，而是你自己对提示词的理解深度。