1. 一句提示词生成可玩游戏这不是魔术是正确的工作流先交代一下背景。我最近在折腾 AI 编程手里正好有顶级模型的 API 额度试着做了一件很多人只在短视频里看过的事只给模型一句话让它写一个能玩的《QQ飞车》风格的网页赛车游戏。说能玩不是标题党是真能用键盘跑完一圈、撞墙有反馈、弯道要减速的那种。整个过程从零到第一个可玩版本大约花了不到半小时其中大部分时间不是等 AI 写代码而是在调整提示词。很多人看到这类演示会觉得是AI 碰巧会背一个赛车游戏模板或者觉得这是剪辑过的效果。但实际上顶级大模型生成完整可运行项目的能力早就不是新鲜事——关键在于你用什么方式跟它协作。一句帮我写个QQ飞车扔给模型大概率得到的是一坨审美平庸、逻辑残缺的代码但如果把这一句话拆成角色背景 核心玩法约束 技术栈选择 交互细节模型给你产出的东西会完全不一样。这篇内容不是复述某个 AI 产品宣传页而是把我自己踩过的坑、调过的参数、改过的提示词全部摊开讲。适合三类人看想用 AI 做游戏原型但不知道从哪下手的开发者对 AI 编程感兴趣但在观望的非技术爱好者以及那些以为AI 写游戏 复制粘贴成品的围观群众。你可以直接照着下面的思路复现也可以只当故事看理解顶级模型是怎么把一句模糊的话变成几百行可运行代码的。我先说说最反直觉的一件事让 AI 写出能玩的游戏难的从来不是写代码而是描述游戏。模型内部对代码的生成能力是过剩的它对自然语言的理解才是瓶颈。一旦你学会用它能听懂的方式描述需求后面所有事情都会顺起来。2. 复现过程从一句给我写个QQ飞车到可玩 Demo 的完整链路2.1 第一轮尝试提示词太短得到的只有空壳我最初的提示词非常朴素就一句话帮我写一个类似QQ飞车的网页赛车游戏顶级模型确实给了一个 HTML 文件打开之后能看到一辆车、一条直道按方向键车能左右移动。但问题是赛道不会转弯撞墙完全不判定没有计时器没有漂移甚至没有第二辆车。说白了这是一个看起来像赛车的画布不是游戏。这个结果其实完全符合预期。顶级模型理解赛车游戏这个概念但概念之下有几十个维度的细节——赛道形状、碰撞逻辑、速度曲线、视觉效果、操作手感——我一句话把这些全压缩了它只能按自己训练数据里的平均印象来生成而这个平均印象往往就是最无聊的版本。从这轮失败里我总结出第一个经验提示词不是字数越多越好但关键约束必须写明。什么叫关键约束就是如果缺了它这个游戏就不成立的那些东西。比如弯道需要减速否则会冲出去、赛车漂移时屏幕要有残影、要有小地图显示当前位置。这些约束决定了游戏的骨架而不是皮肤。2.2 架构提示词让模型先思考再动手第二轮的改进不是直接加需求而是让模型先拆解任务。我用的提示词结构是这样的你是一名资深游戏开发工程师擅长使用 HTML Canvas JavaScript 开发网页小游戏。现在要开发一个类似QQ飞车的竞速赛车游戏请先列出 1. 这个游戏需要哪几个核心系统例如车辆物理系统、赛道生成系统、碰撞检测系统、AI对手系统、HUD系统 2. 每个系统分别负责什么系统之间的数据流是什么 3. 每个系统大致需要哪些函数或模块 4. 用一张文字版架构图描述整体流程。 确认无误后再开始写完整代码代码要放在一个HTML文件中方便直接运行。这一步非常关键。顶级模型天然是一个先规划后执行的系统你在提示词里给它显式的规划指令它会输出远高于直接生成的代码质量。看到它列出的系统拆分后我心里就有数了——它列的五个系统里车辆物理系统和赛道生成系统是我没有特别描述、但它基于对竞速游戏的理解自动补上的这恰恰是顶级和普通模型的分水岭。它当时给的架构文本大概是这样赛道由分段segment构成每段有左右边界坐标通过离心率模拟弯道 车辆物理系统每帧计算加速度、摩擦力、向心力输出位置和朝向 碰撞检测采用简化的线段相交 距离阈值不追求精确物理 AI对手沿预设路点自动驾驶路点由赛道中心线采样获得 HUD负责渲染速度、计时、排名和小地图。有了这个框架它后面写代码的效率至少提升了一倍而且生成的代码结构干净函数与函数之间解耦明显方便后续定向修改。2.3 分模块迭代别让模型一次性写完整游戏第三次尝试我犯了一个典型错误让模型一次性把整个架构落地成代码。结果它真的生成了一个 2000 多行的 HTML 文件浏览器也能跑但手感非常差——车辆转向反应迟钝漂移效果几乎没有碰撞判定时灵时不灵。问题出在哪大模型生成超长代码时上下文里前面的变量定义会逐渐失焦后面部分经常出现变量名拼错、函数调用参数不一致的问题。这不是模型能力不足而是注意力分布的自然衰减。就像人写长文档写到后面也会忘记前面埋的伏笔一样。正确的做法是拆开写。我重新调整了策略先让模型生成完整的index.html骨架只包含赛车渲染和一个可以前后左右移动的方块然后单独生成track.js负责随机生成赛道S型弯、U型弯、发卡弯再单独生成car.js负责车辆物理和漂移手感最后生成ai.js负责 AI 对手的路点跟随。这四次交互的提示词我每次都会附加一句这是刚才项目中 X 模块的完整代码请基于它继续实现 Y 模块不要重写其他部分。 这样模型的上下文里始终有已完成代码的准确快照它的输出质量会稳定得多。2.4 里程碑第一次跑完一圈是种什么体验四个模块合体之后我得到了第一个真正意义上能玩的版本三条完整的赛道循环、手感和 QQ 飞车的低配版类似、按 B 键可以喷射氮气、碰撞障碍物会减速、赛道底部有进度条提示圈数。第一次完整跑完一圈的时候说实话还是有成就感的——不是因为游戏有多精致而是这个过程验证了一件事顶级模型在没有接受任何游戏代码真实训练的情况下仅凭一句句话的指导就能组合出一个符合物理直觉的交互系统。这轮复现的具体提示词我贴在下面方便感兴趣的人直接抄请基于当前项目实现一个AI对手系统 - 有3辆AI赛车颜色分别为红、蓝、绿 - 它们沿着赛道的中心线行驶中心线数据从赛道模块的路点数组读取 - AI赛车在弯道中会适当减速直线会加速 - 当AI赛车与玩家赛车距离小于50像素时会尝试偏移到旁边车道超车 - AI赛车彼此之间也要避免碰撞碰撞后要恢复到安全距离 - 给每辆AI车添加一个简单的名称标签显示在车头上方。注意这段提示词里的两个细节一是中心线数据从赛道模块的路点数组读取这是在告诉模型你的代码需要和已有代码对接二是在超车、防碰撞这些行为上给了明确的数值阈值。3. 赛车游戏背后的硬骨头顶级模型到底替你解决了什么3.1 车辆物理从简单位移到速度向量很多人以为赛车游戏的核心是画一辆车跑起来实际上最难的是车辆物理。你按一下方向键车应该朝哪个方向转、速度怎么衰减、轮胎抓地力怎么模拟——这些全在物理系统里。顶级模型自动实现了一套我称之为离线向心力近似的方案每一帧计算车辆的当前速度向量根据转弯输入修改速度向量的方向同时用一个抓地力系数让车辆在未操作时自动回正。这个方案不是真实物理引擎的精确模拟但用在 2D 网页赛车游戏里完全足够而且代码只有 100 多行性能开销极小。代码大概长这样这是我后来手动改良过的版本function updatePhysics() { // 油门 if (keys.up) speed Math.min(speed acceleration, maxSpeed); if (keys.down) speed Math.max(speed - acceleration, -reverseSpeed); // 摩擦力与空气阻力 speed * 0.99; // 转向速度越快转向角越小体现高速控制困难 if (keys.left) angle - turnSpeed * Math.max(0.3, 1 - speed / maxSpeed); if (keys.right) angle turnSpeed * Math.max(0.3, 1 - speed / maxSpeed); // 漂移急转弯时产生额外横向滑动 driftOffset drifting ? 4 : 0; // 更新坐标 x Math.sin(angle) * speed * driftOffset; y - Math.cos(angle) * speed; }注意到if (keys.left) angle - turnSpeed * Math.max(0.3, 1 - speed / maxSpeed)这一行了吗它模拟的是真实汽车的速度越快、方向盘能转动的有效角度越小。这一个细节就能让手感和纯粹的左右平移赛车完全拉开差距。3.2 赛道生成随机算法的乐趣与风险QQ 飞车的赛道不是随机生成的但我们的 AI 版本没有美术和策划资源只能靠算法生成。我让模型用最经典的分段拼接法整个赛道由上百个线段组成每段的左右边界坐标独立计算线段之间通过角度变化衔接出弯道。这个方案的最大风险是赛道自交——如果随机角度连续累计太大赛道会绕回来压到之前的自己玩家跑到那里就会卡死在边界里。我一开始没管这个结果生成出来的赛道经常有一两个夸张的蝴蝶结游戏完全没法玩。后来我让模型加了一个selfIntersectionCheck()函数每次生成新赛段时检查与之前所有赛段的包围盒是否重叠重叠就丢弃这一段并重新随机生成。这种尝试-校验-重试的循环逻辑恰好是大型语言模型非常擅长的算法设计方向因为它的训练数据里有大量类似的碰撞检测案例。3.3 碰撞检测为什么别人家的碰撞总觉得更自然赛车游戏的碰撞检测有两个层次。第一层是车与赛道边界第二层是车与车、车与障碍物。顶级模型初始生成的是最简单的方案把车当作一个圆心把赛道边界当作线段集合检测圆心与线段的距离是否小于车的半径。这个方案在大多数情况下表现良好但在高速状态下车辆一帧的位移可能超过碰撞半径就会出现穿墙现象。我反馈这个问题之后模型给出的解决方案是连续碰撞检测CCD的思路不是检测车子当前位置是否撞墙而是检测车子从上一帧位置到当前位置扫过的那条线段是否与赛道边界相交。代码实现并不复杂就是两帧之间做一次线段相交测试。这个改进让穿墙问题彻底消失了手感也硬朗了不少。你可能会问这种细节 AI 怎么会知道答案就是顶级模型其实受过大量游戏开发教程、割草机社区问答、GDC 演讲笔记的训练它只是把这些知识以另一种方式组织起来在合适的上下文里就能提取出来。这也是为什么说提示词的上下文质量决定了 AI 输出质量的平均水平。3.4 AI 对手让 NPC 像真人而不是机器人QQ 飞车里的AI对手是灵魂所在没有对手的竞速游戏就没有竞速的意义。模型的初始 AI 方案是沿赛道中心线自动驾驶到达终点自动循环。但玩两把就发现这种 AI 太死板了——它永远走中线永远用最佳路线过弯玩家跟它跑几局就能抓住规律轻松碾压。为了让它像真人我让模型加了四种随机扰动起步反应时间每辆 AI 车有一个随机的起步延迟0.2 秒到 0.8 秒过弯失误概率每个弯道有 10% 的概率会切弯过急导致擦墙减速超车冲动阈值当前方车辆距离小于 100 像素时AI 会尝试变道超车但变道动作是一个快速猛打方向有一定概率甩尾失控策略偏好每辆 AI 车在发车时随机决定这一局是激进型弯道减速少失误率高还是保守型减速多几乎不失误但直线慢。这些扰动加到代码里之后同一张赛道跑五局每局的前三名基本都是不同的人手感上几乎和真人对战无异。这种规则 随机的 AI 设计思路是顶级模型非常喜欢给出的方案因为它可解释、可预测、且调试成本低合作起来非常舒服。4. 实测踩坑AI 生成的代码为什么经常看起来能跑一跑就崩4.1 变量名漂移长代码的隐形杀手这是我复现过程中遇到的最频繁的问题。具体表现是HTML 文件里有个变量叫playerCar某个模块里写player.x 100另一个模块里却变成car.x 100结果打开控制台一片ReferenceError。为什么会这样顶级模型生成代码时它的注意力在长序列上会逐渐不集中特别是当一个项目拆分成多次交互生成时每次交互之间模型的记忆并不是百分百连续的。所以你就得在每次请求时重新把关键变量名写清楚。我的做法是搭建一个简单的接口契约文件// 全局游戏状态 window.gameState { player: { x: 0, y: 0, angle: 0, speed: 0 }, aiCars: [], track: { segments: [], waypoints: [] }, gameStatus: ready // ready / racing / finish };每次生成新模块时我都把这段契约贴在提示词的最前面要求模型的所有函数都以这个全局状态为输入输出。这个方法立竿见影变量名漂移问题从每两轮必现降到几乎不出现。4.2 Canvas 渲染性能页面卡成 PPT 的元凶AI 生成的初版代码使用 Canvas 每一帧清屏并重绘所有元素这在赛道只有 20 个线段时毫无压力但一旦赛道涨到 200 个线段加上粒子特效和漂移残影浏览器立刻掉到每秒二三十帧。查了性能瓶颈之后发现问题出在 AI 用了context.shadowBlur来实现霓虹灯效果。这个属性在 Canvas 里是出了名的性能杀手每一次调用都会触发整个画布的阴影计算。我把所有涉及阴影的代码替换成简单的线性渐变填充帧率瞬间回到 60。这里有个通用经验让 AI 调试性能问题不要让它猜测直接告诉它性能瓶颈是什么 你希望的行为是什么。比如当前游戏帧率只有20fps我怀疑是shadowBlur导致的。把代码中所有shadowBlur移除改用简单的颜色叠加模拟发光效果保持外观风格不变。在这个提示词下模型会精准寻找并修改问题代码而不是漫无目的地重写整个文件。4.3 漂移手感调了三轮数值才找到爽感QQ 飞车的手感核心是漂移。实话说AI 第一次生成的漂移效果非常糟糕按方向键加 Shift 后车辆会立刻转成横向滑动但松开 Shift 后又会瞬间恢复抓地中间没有任何过渡导致玩家完全没法流畅地画弧线。我尝试让模型直接调参数比如提高漂移摩擦系数、增加漂移时的角速度但效果一直不对。后来我想通了漂移的爽感不是单一参数能调出来的它是速度曲线、转向角速度、视觉残影、音效四者的配合。于是我重新改了提示词方向漂移手感不佳。请参考《QQ飞车》中的竞速漂移体验改进以下细节 1. 漂移启动时有一个渐进过程按漂移键后 0.2 秒内逐渐增加横向滑动量而不是瞬间切换 2. 漂移过程中车辆会额外加速 10%模拟出弯提速 3. 漂移结束时增加一个小幅度的回正动画持续 0.3 秒 4. 漂移期间车尾绘制 5 个逐渐消失的半透明轮胎印记。这次改动效果非常明显漂移从生硬的平移变成了有节奏感的弧线。这个案例给我的启发是AI 不是不能做手感而是你需要把手感这个词拆解成它可以操作的具体指标。渐进过程、额外加速 10%、回正动画这些都是模型能理解和执行的操作单元。4.4 浏览器兼容问题为什么我在 Mac 上跑得好好的Windows 上崩了最后一个小坑出现在键盘监听上。AI 用的是event.keyCode这个属性虽然老但兼容性还行问题出在它同时监听了keydown和keypress两个事件同时对同一按键触发两次导致方向键响应有双倍加速度。在 Mac 的 Chrome 上表现是车灵敏度很高还能玩但在 Windows 的 Firefox 上就会变成一点方向键就原地打转。解决办法很简单删掉keypress监听只在keydown里处理逻辑并用event.repeat忽略长按重复触发document.addEventListener(keydown, (e) { if (e.repeat) return; keys[e.key.toLowerCase()] true; }); document.addEventListener(keyup, (e) { keys[e.key.toLowerCase()] false; });这段代码推荐直接抄走比任何 AI 生成的大段事件管理代码都干净。5. 从能玩到好玩我后来又让它加了什么5.1 小地图与圈数提示竞速游戏的信息完整度第一版游戏没有小地图玩家在超过三圈的环线赛道上跑一会儿就分不清自己在哪里。我让模型加了一个实时绘制的 150x150 小地图左上角显示赛道用一个半透明圆环表示玩家车是一个红点AI 车是三个蓝点点阵的移动路径参照实际坐标的缩放映射。这个功能看起来简单但涉及两个坐标系的转换游戏世界坐标和 Canvas 像素坐标。模型最初的实现是直接用像素坐标除以一个固定缩放系数但当赛道生成范围变大时小地图就飘了车辆红点跑出地图区域。修正方案是让模型计算所有赛段坐标的最小值和最大值用归一化映射到小地图区域。这是一个非常典型的比例尺问题在 AI 生成的代码里尤其容易出错。5.2 氮气加速与视觉反馈喷射区怎么画才不丑QQ 飞车经典玩法里的喷射带我让它实现成赛道上一条发光的青色区域。开车压到喷射带后速度会额外提升 30%持续时间 1.5 秒期间车身周围出现粒子拖尾。这部分的难点不在逻辑而在视觉。模型生成的粒子拖尾别太当真——它用了 30 个随机位置的小白点循环飘撒看起来像车着火了。稳定做法是让粒子沿一条弧线轨迹运动并且透明度随生命周期递进递减。这里我学到的教训是如果视觉要求很高别指望 AI 一步到位拆成粒子系统 轨迹曲线 颜色渐变三个子任务分别生成最后合在一起。5.3 声音AI 生成的 Web Audio 引擎音效音效是让游戏感觉高级的最快方式。我没花钱买音效素材而是让模型用 Web Audio API 合成引擎轰鸣声、碰撞声和漂移音效。引擎声是一个频率随速度变化的振荡器速度越快频率越高听着有种模拟驾驶的游戏感。碰撞音效用的是白噪声 低通滤波的一次爆破音漂移音效用方波加上快速的频率扫动。这套音效方案代码量少、效果好而且完全不需要外部音频文件非常适合 AI 生成的单文件游戏项目。唯一的坑是部分浏览器的自动播放策略会拦截 Web Audio 的启动必须等用户第一次点击页面后再创建音频上下文。模型一开始没处理这个导致第一版游戏打开没有任何声音直到用户按了方向键之后声音才迟到地响起来。加了一个window.addEventListener(click, initAudio, { once: true })之后问题就解决了。5.4 排行榜与本地存储让游戏至少能玩十把为了让这个 Demo 更像一个真的游戏我让模型加了一个简单的排行榜完成一圈后记录成绩存入localStorage下次打开页面时显示历史最快圈速。这个功能对模型来说几乎没有难度写出来也就是二十多行代码。我刻意提这个是想说一句AI 写游戏的上限其实是由你想要的完成度决定的。如果你只想要一个能跑的圆形它会给你圆形如果你想要一个能开排行榜、有音效、有小地图、支持多圈赛事的完整游戏它也能给你。差别在于你是否意识到完整游戏由哪些组件构成以及你愿不愿意一步一步分解任务。6. 顶级模型写游戏的边界哪些事它做不了哪些事别让它做6.1 审美判断力模型能模仿不能审美很多人问我AI 写的游戏和 QQ 飞车差距有多大答案很简单美术和策划层面差很多。QQ 飞车的美术风格是经过长期审美打磨的——场景比例、光照氛围、UI 动效、车辆的流线型设计这些不是靠算法能生成出来的尤其是一次性生成出来。AI 生成的赛车大概率是一个矩形加两个圆赛道就是灰底加白线。你可以通过提示词让它增加渐变、边框、阴影但最终作品还是停留在像素风原型的层次。它不是不能做好看而是需要极大提示词工程量来弥补审美判断力投入产出比远不如让真人做美术。6.2 设计意图AI 不知道为什么这样设计竞速游戏的乐趣在于规则设计的巧妙比如为什么 U 型弯前有加速带、为什么直道中间放一排路障。这些设计意图需要策划经验AI 只能根据训练数据里的普遍经验给出合理默认但永远无法像人一样知道这里放一个加速带是为了让玩家在过弯前多做一次路线规划。所以我的建议是把 AI 当成一个资深执行者而不是设计师。让它实现你的想法、测试不同方案、快速迭代反馈都比让它自己从零构思要有价值得多。6.3 复杂渲染效果模型会写但不懂优化3D 效果、碰撞后车身碎片的物理模拟、动态光影这些代码 AI 也能写但写出来之后性能基本都会爆炸。因为游戏渲染是一个非常依赖管线优化和帧预算的经验领域模型训练数据里的模棱两可太多它给的实现往往是最直白、最不优化的那个版本。遇到这种情况别跟它死磕直接用成熟游戏引擎或专门图形库来做局部功能或者干脆简化功能。6.4 游戏的灵魂还是得靠人最后说一个可能听起来飘但很实际的观点AI 能写出能玩的游戏但写上好玩这个词就需要人参与。我在整个复现过程中真正花时间去做的不是写代码而是想清楚漂移要有渐进感、AI 要会失误、小地图比例尺要归一化这些设计判断。这些判断不在任何提示词模板里它来自我以前玩游戏时对体验的敏感来自这个手感不对我要拆解它为什么不对的愿望。这句话同样适用于你如果你自己不知道游戏好玩在哪给你再强的模型也没有用反过来只要你能清楚地描述什么才是好玩顶级模型就真的能帮你把那个好玩的游戏写出来。7. 实操经验总结如果你也想用 AI 写一个竞速游戏7.1 复现环境与工具选型我现在用的是一套非常轻量级的 j 环境一台普通的 MacBook Air浏览器用 Chrome编辑器只用 VS Code 加一个 AI 插件用来粘贴代码和报错信息。不需要安装任何游戏引擎不需要配置本地服务器一个 HTML 文件打开就能跑这也是 AI 生成网页游戏最爽的地方——零门槛双击即玩。如果你不想用我用的这个顶级模型用支持长上下文的其他大模型也行比如 GPT-4 类、Claude 类甚至国内几款百亿参数模型也基本能做到写一个能跑的赛车 demo。差别主要在复杂逻辑的稳定性和长代码的连贯性但思路是完全一致的。7.2 一套可以直接抄的提示词结构这几次实践下来我形成了一个固定的提示词模板分享给各位【任务背景】 我是一个没有游戏开发经验的爱好者你是一名资深HTML5游戏开发工程师。 【目标】 实现一个类似QQ飞车的网页竞速游戏最终交付一个可直接运行的HTML文件。 【硬性要求】 - 用纯HTML CSS JavaScript不依赖任何外部库 - 画布自适应窗口尺寸 - 支持键盘操作方向键控制方向Shift漂移B喷氮气 - 有碰撞检测、漂移手感、AI对手、计时与圈数系统 - 代码注释清晰关键逻辑需要有中文注释。 【工作方式】 先输出一版完整的代码然后等待我的测试反馈不要主动修改代码。 【本次要完成的内容】 在这里具体描述你希望新增或修改的功能这段模板的精髓在于最后两行等待我的测试反馈不要主动修改代码。这一句能避免模型在生成完一个版本后絮絮叨叨地附赠一堆无关优化建议让你的迭代节奏掌握在自己手里。7.3 调试节奏十五分钟一轮是黄金周期我用十五分钟周期来管理整个迭代过程生成代码五分钟跑起来两分钟玩三分钟发现问题五分钟给模型反馈再花两分钟。一圈下来十五分钟产出明显的可玩改进。这种节奏非常重要——AI 编程的优势就是迭代快你别把它用成让 AI 一次性给终稿的模式那只会让你陷入反复重写的泥潭。7.4 推荐延伸方向从竞速游戏到 Roguelike 游戏如果你觉得赛车游戏玩腻了同一个工作流完全可以平移去写其他品类。比如让它写一个以撒的结合风格的地牢射击游戏或者一个吸血鬼幸存者风格的自动刷怪游戏。底层逻辑都是物理系统 碰撞规则 敌人生成 玩家成长这四个模块和赛车游戏的系统拆分是同一套方法论。更进阶的玩法是让 AI 自己生成游戏设计文档再基于文档写代码。用顶级模型先写一份关卡设计表——每个弯道的半径、加速带的位置、障碍物的密度——然后让它按表生成赛道。这个流程就基本接近一个小型游戏团队的分工方式了策划你/模型出方案程序模型落地。7.5 一个让人上头的扩展点让 AI 学习你的驾驶风格说个更遥远但可行的想法我打算下一步让 AI 记录玩家的操作序列按键时间戳 速度 位置用这些数据训练一个小模型在单机模式里生成一个镜像自己的 AI 对手。这个想法和博客里提到的 AI Agent 有点像本质上是把玩家历史操作当作提示词输入模型让它以模仿学习的方式输出下一个操作的概率分布。虽然目前只是个想法但以顶级模型的代码能力和推理能力来看这个功能在纯前端也能实现无非是自己生成一个简单循环神经网络训练量小到几秒就能完成。这类扩展没有标准答案能摸到多深取决于你愿意花多少时间跟模型交互。我能确定的是每一轮交互中你给出的信息越具体、迭代越勤快、反馈越精准越能把你从用 AI 生成玩具推进到用 AI 开发产品的层级。最后实际操作中我个人最受益的一件小事试着把每次的提示词和结果截图存下来隔几天回看自己当时是怎么提问的。你能清楚看到自己的提需求能力在变好而这种能力不是模型给的是你跟模型一轮轮打磨出来的。这大概就是 AI 时代最微妙的地方——技术门槛在降低但设计师和策划师的判断力反而变得更值钱了。