周末刷到一条消息：有人用一句提示词，让顶级 AI 模型写出了一款能玩的 QQ飞车风格赛车游戏。我最初是不信的，游戏这东西，建模、物理、手感，哪个不是硬功夫？但转念一想，现在大模型写代码的能力已经卷到这个地步，也许真能成。当天晚上我就试了。没有装任何游戏引擎，没有搭项目，就是把一段话说清楚发给模型，几分钟后拿到一个几百KB的HTML文件，双击打开，键盘一按，车真的在动。
这篇文章想跟你聊聊这条路径的完整套路：怎么设计提示词、生成后怎么改、遇到问题怎么让 AI 自己修，以及哪些坑是我替你踩过的。不管你是前端开发者、AI 工具爱好者，还是单纯想看看"大模型写游戏"到底能到什么程度，这篇都应该能给你带来点参考。
1. 一句话生成游戏：这个项目到底在做什么，为什么值得试试
1.1 "顶级模型一句话"背后的真实逻辑
先说结论：所谓"一句话写出能玩的 QQ飞车"，并不是科幻，也不是标题党夸大，它本质上是用结构化提示词驱动大模型完成一次代码生成任务。
现在的主流大模型，比如 DeepSeek、通义千问这类顶级模型，内部都吃下了海量的开源代码，尤其是 Web 前端项目。你让它"写一个按钮"或者"写一个轮播图"，它早就训练得滚瓜烂熟。而赛车游戏在 HTML/JavaScript 领域是一个非常经典的练手项目，GitHub 上有无数版本，模型对这种"竖向卷轴赛车"的实现模式非常熟悉，几乎到了条件反射的程度。
你把需求描述得越清楚，它输出的代码就越接近一个能跑的成品。这就是"一句话"背后的真相：不是真的只有一句话，而是把一堆复杂需求压缩成一两句高信息密度的话。普通用户看到的是"一句话"，实际操作里是"一句顶十句"的精确指令。
这个模式在 2025 年已经非常成熟了。我身边做前端的朋友，甚至已经开始用 AI 生成基本功能模块，再人工微调交互细节。游戏开发圈子虽然还习惯用 Unity、Godot 这类重型引擎，但对于"原型验证""教学演示""个人练手"这类轻量场景，AI 生成的单文件 Web 游戏已经足够惊艳了。
1.2 为什么偏偏选 QQ飞车这个方向
QQ飞车这个方向不是随便选的。它有三个其他题材给不了的优势。
第一，认知门槛极低。只要玩过赛车游戏，就知道"方向键控制左右、上加速、下刹车、躲避其他车辆"这套操作逻辑。模型不需要额外理解复杂的游戏规则，玩家也不需要看说明文档，上手即玩。
第二，视觉反馈足够强。赛车游戏天然自带速度感和刺激感，路面飞速后退、路边景物掠过、碰撞闪白屏，这些反馈很容易让玩家产生"挺好玩的"的第一印象。相比之下，让 AI 写一个俄罗斯方块或者扫雷，视觉上就平淡很多。
第三，单文件就能实现。QQ飞车原版是 3D 赛车，但我们玩的是"仿 QQ飞车风格"的轻量版本。用 Canvas 2D 绘制俯视卷轴赛车，完全不需要物理引擎、不需要 3D 模型、不需要资源服务器，一个 HTML 文件加几百行 JavaScript 就能搞定。这也正好卡在大模型代码能力的舒适区里。
还有个细节，网上很多人在搜"QQ飞车单机版"，说明大家想要一个不联网、能随便玩、没有氪金压力的版本。虽然我们不可能真的去复刻原版游戏，但做一个玩法类似、风格接近的小原型，练手和娱乐都足够了。
1.3 这个东西适合谁，能解决什么问题
如果你属于以下几种情况，我建议你花半小时亲手试一遍。
一是前端开发者。你会看到 AI 如何快速搭建游戏循环、碰撞检测、Canvas 绘制这些经典模块，也能对比自己的实现思路和大模型生成代码之间的差异。
二是AI 工具重度用户。很多人玩 AI 还停留在"写文案、做表格"的层面，但 AI 写代码这件事的潜力远比想象中大。通过这个小项目，你能直观感受到提示词质量对输出结果的影响有多大。
三是游戏开发初学者。以前想做个游戏，要从完全零基础学引擎、学脚本、学资源管理，光入门就得一两周。现在你可以在十分钟内得到一个能跑的赛车游戏，然后拿着这个基础版本去改造、去学习、去拆解，学习路径一下子缩短了很多。
一句话总结：这不是一个"炫技"项目，而是一个人人都能复现的 AI 编程实战样本。接下来我详细拆解每一步怎么做。
2. 动手前先想清楚：技术选型和提示词设计思路
2.1 技术选型：为什么是 HTML + Canvas + JavaScript
在选择实现方案时，我脑子里过了一遍所有可选项，最后坚定地选了"原生 HTML + Canvas + JavaScript"，一个外部库都没用。原因很朴素：越简单的依赖链，越不容易中途翻车。
如果用 Unity 或 Godot 这类游戏引擎，模型确实也能生成 C# 脚本或 GDScript 代码，但你本地得装几 GB 的编辑器，还得配置项目结构，跑起来又是一堆环境问题。这会让整个演示过程从"五分钟看到成果"变成"半小时还在装环境"，完全背离了初衷。
而 HTML 文件的好处是，任何电脑、任何浏览器都能直接打开运行。大模型生成的页面天然就是"双击即玩"，不需要编译，不需要构建工具，不需要服务器。Canvas 2D 虽然做不出原版 QQ飞车那种 3D 画面，但配合简单的透视模拟和视觉装饰，速度感完全够用。
还有一个很多人忽略的点：Canvas 游戏代码在数据空间里出现的频率极高，模型对"游戏循环 + 精灵绘制 + 碰撞检测"这套组合拳的输出稳定度，远超其他领域。换句话说，这个选型本身就在利用大模型的长处，而不是跟它的短处较劲。
2.2 提示词设计思路：好提示词的四个核心要素
很多人问："为什么我让 AI 写游戏，它给我写一堆废话？"答案很简单：你的提示词本身就是一堆废话。
我总结了一套提示词设计的四要素框架，适用于所有 AI 编程场景，包括写游戏。
第一，明确角色和技能定位。让模型扮演资深前端游戏工程师，这和直接说"帮我写个游戏"的产出质量差着两个量级。角色设定会激活模型在对应领域的高质量知识分布。
第二，明确技术栈和输出形式。告诉模型用原生 HTML + CSS + JavaScript、单文件、不要外部库，这些约束条件直接决定了代码是否开箱即用。不说明的话，模型很可能给你生成一个需要 npm install 的 React 项目。
第三，明确功能清单和交互规则。操作方式、赛道样式、碰撞逻辑、计分方式、界面状态，能想到的都要写清楚。AI 不会替你决定，你漏掉的每个细节，最终都会变成"代码里没有这个功能"。
第四，明确性能和质量要求。比如"用 requestAnimationFrame 驱动游戏循环""保持 60FPS""关键逻辑写注释"。这些要求会引导模型输出工程化程度更高的代码，而不是随手拼凑的玩具。
这条框架不只能用来写游戏，写任何代码需求都可以套用。我后面所有迭代对话，都是在这个框架上做局部调整。
2.3 完整提示词示例与逐块拆解
下面是我实际用过的一个完整提示词，原样贴出来：
请你扮演一名资深前端游戏工程师，用原生 HTML + CSS + JavaScript（不要用任何外部库） 在一个单文件 HTML 里实现一个仿 QQ飞车风格的竖向卷轴赛车小游戏。 具体要求： 1. 操作：玩家用键盘方向键控制赛车，左右转向，上加速，下减速/倒车。 2. 赛道：竖向卷轴，画面顶部为远处，底部为近处；道路中央有虚线， 路边有红白相间路肩和草地、树木等背景。 3. 玩家车：从底部出发，绘制成俯视角的彩色赛车。 4. 障碍与计分：赛道上有其他车辆作为障碍，碰撞后减速并屏幕闪白； 按行驶距离计分，每 100 米增加 10 分。 5. 界面：游戏开始前显示标题和“按任意键开始”，结束后显示得分和“按 R 重开”。 6. 性能：使用 requestAnimationFrame 驱动游戏循环，保持 60FPS。 7. 约束：所有代码写在一个 HTML 文件里，关键逻辑带中文注释。这段提示词拆开看，正好对应上面说的四要素。
第一行是角色定位和技术约束。第二到第六条是功能清单，每一条都是"用户能感知到的具体行为"，而不是抽象描述。比如我没有说"要有游戏感"，而是说"路边有红白相间路肩和草地树木"，模型就能直接画出对应的画面。
第七条是质量承诺条款，目的是让模型知道你在乎代码可维护性和运行性能。实践中，加了这一条之后，生成的代码里注释完整度和 requestAnimationFrame 的正确用法都明显更规范。
注意，这段提示词里没有出现任何"请写一个类似某某游戏的完整克隆"这类可能涉及版权争议的描述。我们要做的是玩法启发和风格参考，这是安全的练手方向。
3. 生成、运行与核心代码拆解：初版到底能用成什么样
3.1 第一次生成的流程与结果
实际操作流程比我预想的还要顺滑。我把上面那段提示词粘进对话框，模型思考了大概十秒钟，输出一个接近五百行代码的 HTML 文件。我先把它复制成一个game.html，然后直接双击用浏览器打开。
第一次打开的画面是这样的：深灰色背景，中间一条竖向公路，公路两侧是绿草地，草地上错落分布着树木和几栋小房子。一辆红色赛车停在画面底部正中，车头朝上，造型就是 Canvas 绘制出来的菱形加两个尾翼，挺有模有样。画面中央显示着"按任意键开始"的提示。
按下方向键的瞬间，路面的虚线开始快速向下滚动，路边景物也随之后退，速度感一下就出来了。我试着按左右方向键，车头保持朝上，但车身左右平移，屏幕边缘处会有轻微的位移缩放效果——这其实是用一个很简单的"越靠近画面边缘，车辆绘制越靠下"的伪透视实现的。坦白说，画面跟原版 QQ飞车没法比，但作为"AI 两分钟写出来的东西"，已经超出预期了。
更让我意外的是，它还真的把障碍车、碰撞减速、计分系统全跑通了。路上每隔一小段就会出现一辆颜色不同的障碍车，撞上之后整个屏幕白闪一下，速度明显掉下来，右上角有一个里程计数在 steadily 往上走。开到一定公里数，画面提示"游戏结束"，显示最终得分，按 R 键重启一局。
我第一次玩到游戏结束的时候，隔壁桌朋友问我是不是偷偷下载了某个小游戏站上的资源。我说不是，这是 AI 刚写的。他愣了两秒，然后说了一句："这玩意儿以后真的要让一批初级程序员失业了。"
3.2 核心代码模块逐个看：正经聊聊实现原理
初版能跑通，靠的是几个经典的游戏开发模块。我挑几个关键模块的代码逻辑拆给大家看，这些都是 AI 生成后我整理过的版本，注释也重新梳理了一遍，方便直接拿去当模板。
第一个是游戏主循环。所有游戏都离不开循环：不停地更新状态，不停地绘制画面。这里用的是requestAnimationFrame，它能让浏览器以显示器的刷新频率调用回调函数，比setInterval优化得多。
let lastTime = 0; let gameState = 'ready'; // ready | running | gameover | paused function gameLoop(timestamp) { const deltaTime = Math.min((timestamp - lastTime) / 1000, 0.05); lastTime = timestamp; if (gameState === 'running') { update(deltaTime); // 更新所有逻辑 draw(); // 绘制当前画面 } requestAnimationFrame(gameLoop); } requestAnimationFrame(gameLoop);注意Math.min这个写法。它把deltaTime限制在最大 0.05 秒，防止浏览器标签页切出去再切回来时，累积的帧间隔让游戏里的车瞬间飞出十条街。这个小细节很多手写代码的人都会漏掉，但 AI 生成的代码里出现了，说明它的训练数据里确实包含了很多高质量游戏代码。
第二个是赛道滚动。竖向卷轴赛道的核心不是让车向上移动，而是让路面元素向下移动，制造"车在前进"的错觉。
let roadOffset = 0; function drawRoad() { const laneX = canvas.width / 2 - roadWidth / 2; ctx.fillStyle = '#333'; ctx.fillRect(laneX, 0, roadWidth, canvas.height); // 虚线：根据 roadOffset 偏移绘制，模拟向前滚动 ctx.fillStyle = '#f1f1f1'; for (let y = -40; y < canvas.height; y += 40) { const dashY = (y + roadOffset) % canvas.height; ctx.fillRect(laneX + roadWidth / 2 - 3, dashY, 6, 20); } roadOffset += speed * deltaTime * 200; }roadOffset就是"虚拟里程表"，它随着速度增加而增大，取模后让虚线无限循环。背景里的草地和树木，也是用同一套偏移逻辑，只是偏移速度比道路慢一点，形成简单的视差效果。这才是速度感的来源。
第三个是玩家车辆绘制。AI 选的是用 Canvas 的rotate和fillRect组合画一个俯视角的赛车，形状是一个倒梯形车身加两个尾翼，中间用不同颜色区分驾驶舱。
function drawCar(x, y, color) { ctx.save(); ctx.translate(x, y); ctx.beginPath(); ctx.moveTo(0, -18); // 车头 ctx.lineTo(10, 8); // 右前 ctx.lineTo(25, 12); // 右尾 ctx.lineTo(-25, 12); // 左尾 ctx.lineTo(-10, 8); ctx.closePath(); ctx.fillStyle = color; ctx.fill(); ctx.restore(); }关键在于ctx.save()和ctx.restore()的配对使用。如果不做这两步，后续所有绘制都会带着坐标变换的状态，整个画面会乱掉。这是 Canvas 开发里最常见的错误之一，AI 代码里配得整整齐齐，我挺欣慰。
第四个是碰撞检测。这个版本的碰撞检测走的是简单粗暴的矩形相交判断。
function checkCollision(player, obstacle) { const gapX = Math.abs(player.x - obstacle.x); const gapY = Math.abs(player.y - obstacle.y); return gapX < (player.width + obstacle.width) / 2 && gapY < (player.height + obstacle.height) / 2; }这个算法忽略车辆的倾斜角度，直接用轴对齐包围盒判断。对俯视角赛车游戏来说，精度勉强够用。后面我在迭代版本里会让它更"宽容"一些，因为玩家反馈碰撞判定太严，经常擦着边也减速。
我这里放的代码是"拆解"用的精简版，AI 实际生成的代码里还包含了障碍车循环生成、计分界面渲染、键盘事件监听、开始结束状态切换等完整逻辑，整体大约五百行。作为单文件游戏来说，这个体量非常健康。
3.3 真实运行体验：能用，但手感还停留在"原始"阶段
初版能玩，但距离原版 QQ飞车那种"丝滑漂移、氮气爆发"的手感还有相当远的距离。
先说好的方面：帧率稳定，画面流畅，操作响应零延迟，这些基础体验完全达标。键盘按下去的一瞬间车就有反应，没有那种让人抓狂的"迟滞感"。计分和碰撞叠合的闪屏反馈也很及时，玩起来有正反馈。
再说不足。第一，手感偏"弹"——左右转向是瞬移式的，没有速度递进的过程，看起来像在跳而不是在开。第二，赛道只有直线，没有弯道，玩到后面会无聊。第三，碰撞判定偏严，明明差半个车身宽也判撞车。第四，没有漂移、没有氮气、没有对手排名，游戏性单薄。
这些问题我心里有数，因为我知道"能玩"和"好玩"之间差着一整个迭代周期。接下来要做的，就是继续用提示词让 AI 逐项修补短板。
4. 用对话继续调教：从"能玩"到"好玩"的完整过程
4.1 第二轮提示词：给游戏加上漂移和氮气加速
初版跑通之后，我做的第一件事不是自己改代码，而是继续跟模型对话，把需求清单一条一条丢给它。这一步就是 AI 编程的精髓：你不是在写代码，你是在做产品经理。
第二轮对话我提的需求是这样：
在现有代码基础上增加两个系统： 1. 漂移系统：按空格键进入漂移状态，漂移时赛车整体旋转一个角度， 车身两侧绘制轮胎印，画面增加速度线效果；漂移结束后根据漂移时长给出小幅度加速奖励。 2. 氮气系统：增加一个氮气槽，漂移和累计行驶里程会补充氮气； 按 Shift 键消耗氮气获得额外加速，持续期间屏幕边缘有蓝色光效。 3. 所有新代码和原代码保持风格一致，不要破坏原来的计分和碰撞逻辑。注意，最后一条约束特别重要。大模型在改写代码时，最常见的翻车方式就是"新功能写好了，旧功能坏了"。我明确要求它不要破坏原逻辑，这相当于给它了一个回归测试清单的氛围。
模型给出的方案是用一个isDrifting布尔值配合一个漂移计时器来管理状态。按下空格时，车辆转向角度会被锁定，但速度方向保持原向，视觉上就形成了"车子斜着滑"的漂移感；同时引入一个粒子数组，每帧在地面上画两组慢慢变淡的轮胎印。氮气槽则用百分比数值管理，漂移结束时按漂移时长充能，里程每满一千米也充一点，Shift 触发加速时每帧递减。
改完重新打开页面，手感直接从"GBA 赛车"跳到了"手机赛车游戏"级别。漂移时车身的倾斜角度、拖出的轮胎印、速度线划过屏幕的效果，让驾驶过程有了明显的操作空间。我试着在直道上连续漂了几次，氮气槽攒满后一段加速冲刺，画面边缘的蓝色光效让速度感翻了一倍。这一刻我才真正觉得，"AI 写游戏"这件事不再只是演示，而是真的能迭代出好玩的内容。
4.2 第三轮迭代：加入 AI 对手车与简单音效
漂移和氮气搞定之后，游戏已经有点意思了，但还缺一个核心目标——没人跟你竞争。赛车游戏没有对手，就像打篮球没有篮筐，爽归爽，没有终点。
第三轮我提了两个需求：
1. 增加 AI 对手车系统：赛道上会出现 3 到 5 台颜色各异的 AI 赛车， 它们会和玩家保持大致相同的速度行驶，偶尔会根据玩家的位置横向偏移， 试图阻挡或让开。游戏结束时除了显示玩家里程，还显示玩家在 AI 中的名次。 2. 增加简单音效：用 Web Audio API 生成引擎声和碰撞声， 不要引入任何外部音频文件。第一个需求本质上是给 AI 车加一套非常轻量的"目标追踪"逻辑。AI 车在垂直方向上持续下移，速度曲线会参考玩家的实时速度；水平方向用一个随机扰动函数决定移动目标，每隔零点几秒重新计算一次当前位置和目标的差值，然后向目标靠拢。这套逻辑做不出真正复杂的对抗 AI，但看起来已经有模有样了，车与车之间明显有错位超车的动作。
第二个需求是用 Web Audio API 合成音效。这一点我强烈建议大家学一下，因为很多 AI 生成的游戏都栽在"没有声音"上，而 Web Audio 其实一点都不难。模型生成了一段十几行的代码，定义了一个beep函数，用振荡器生成不同频率的方波，碰撞时播放低频短音，氮气加速时播放一个频率渐升的扫频音。虽然音色很"机械"，但游戏氛围立刻完整了。
改完之后，我在开局后故意让一台蓝色 AI 车超过我，然后追着它跑了一整圈赛道。这种"超车与被超车"的张力，是前面两个版本完全没有的。游戏从"能玩"变成了"想继续玩下去"的状态。
4.3 迭代过程总结：三个让 AI 编程更稳定的关键技巧
这三次迭代跑下来，我总结出了三个实战技巧，对任何 AI 编程场景都适用。
第一，每次迭代只做一件事。我第二轮只加了漂移和氮气，第三轮才加 AI 对手和音效。很多人在一个提示词里塞五六个新需求，结果模型手忙脚乱，每项都做了但每项都是半成品。跟模型交流，跟对人布置工作一样，需求越聚焦，完成度越高。
第二，把报错信息直接丢回模型，让它自己修。迭代过程中，我也遇到过一次页面白屏的情况。F12 一开，控制台里明晃晃一行"player is not defined"。我没有自己动手查，而是把完整报错信息复制粘贴给模型，说"运行时出现这个错误，请修复"。它很快定位到问题：障碍车辆生成时调用了尚未初始化的玩家对象。几秒钟给出修复后的代码。
第三，维护一份"需求变更清单"。每轮迭代前，我把当前功能列表复制进提示词的开头，让它先在清单里标注"现有功能"和"新增功能"，再输出代码。这个方式能显著降低模型漏掉旧功能的风险。
5. 踩坑实录：AI 写游戏时，这几个问题几乎人人都会遇到
5.1 方向键操作把页面带着滚动了
初版跑起来后，我第一时间就发现：按方向键时，整个页面也跟着上下左右滚动。原因很简单——方向键的默认行为就是滚动页面，游戏代码监听方向键的同时没有阻止默认事件。
解决办法是在键盘监听函数里加一句：
window.addEventListener('keydown', (e) => { if (e.key.startsWith('Arrow')) { e.preventDefault(); } // ... 原有逻辑 });这个坑在网页游戏里出现频率极高。第一次遇到可能觉得莫名其妙，但记住这条，以后做任何浏览器端游戏都能少踩一次。
5.2 碰撞判定过严导致"擦边也减速"
初版的碰撞检测用的矩形相交逻辑，判定的是一个完全包围盒。问题在于，俯视角赛车是菱形车身，四角位置其实是空的，肉眼看着没撞上，包围盒已经重叠了。结果就是玩家经常觉得"明明擦着边，凭什么说撞了"。
我的处理办法是给碰撞范围做收缩——在判定条件里把参与计算的宽高各乘一个系数，比如 0.7。这个系数你可以在代码里做成一个COLLISION_SCALE常量，方便反复调试。实践下来，系数设在 0.7 到 0.8 之间手感最舒服，既不会漏判明显的碰撞，也不会误伤擦边操作。
5.3 运行一段时间后画面明显卡顿
玩到第三局，我发现帧率明显下降，辅助驾驶的 AI 车动作出现一顿一顿的现象。打开性能面板看了一眼，内存占用持续上涨，问题定位在粒子系统上。
轮胎印粒子和氮气光效粒子在每帧都要新增，但旧粒子没有被及时清理，数组越来越长，绘制开销越来越大。正确的做法是在粒子的update方法里判断生命周期，超过设定时间就从数组中移除。这属于最典型的"内存泄漏式卡顿"。遇到画面越来越卡的情况，第一反应就查数组和对象列表有没有无限增长。
5.4 常见问题速查表：全部问题与解决思路汇总
我把整个过程中遇到的问题整理成一张速查表，方便大家以后照着排查。
| 问题现象 | 直接原因 | 解决思路 |
|---|---|---|
| 方向键让页面滚动 | 默认键盘行为未拦截 | 在 keydown 中调用e.preventDefault() |
| 画面越来越卡 | 粒子或障碍数组无限增长 | 给对象加生命周期，及时从数组中移除 |
| 碰撞判定过严 | 包围盒大于视觉车身 | 引入碰撞缩放系数，收缩判定范围 |
| 切换标签页回来后游戏跑飞 | 未限制帧间隔 | 对deltaTime做最大值钳制 |
| 漂移时画面倾斜过度 | 旋转角度无上限 | 给漂移角度设置最大阈值并做阻尼回正 |
| AI 对手车原地抽搐 | 新增代码里缺少时间因子 | 所有水平位移乘上deltaTime再更新 |
| 字符键触发意外功能 | 事件监听过宽 | 只对指定按键做逻辑判断，其余忽略 |
| 氮气加速无加速感 | 速度增量过小 | 把加速系数从 1.05 调到 1.3，并加光效音量 |
| 首次生成打不开页面 | 代码有运行时语法错误 | 复制报错信息让模型自修，而不是手动排查 |
这张表覆盖了 90% 以上的 AI 生成网页游戏常见问题。我的经验是：遇到问题第一反应应该是"把问题反馈给 AI"，而不是自己动手改。因为模型对自己刚生成的代码有上下文记忆，修复效率远高于人去看那几百行代码。
最后分享一个真实的体验总结
从一条提示词到一个带漂移、氮气、AI 对手和音效的可玩赛车游戏，整个过程花了一个晚上。坦白说，这个速度在我五年前刚接触游戏开发时是完全不敢想象的。但真正让我觉得有价值的，不是"AI 能写代码"这个事实本身，而是它改变了创作者的工作方式——你不再是那个坐在键盘前一行行敲代码的苦力，而是变成提出需求、评审结果、引导迭代的产品经理和游戏策划。
我个人在实际操作中的体会是：提示词工程本质上就是需求工程。你把游戏规则描述得越精确，AI 产出的成品就越接近你脑子里的画面；你迭代得越有节奏感，最终做出来的东西就越像"你的作品",而不是"AI 的玩具"。这一套方法，不只是写游戏，写任何程序都通用。
最后再分享一个小技巧：给 AI 提需求的时候，不妨在每轮对话前带上固定的规则前缀，比如"请基于现有代码继续修改，不要重写，不要破坏既有功能"。这句话的作用，比我试过的任何花哨提示词技巧都更直接有效。祝你在 AI 编程这条路上，玩得开心。
