做了这么多年小游戏和互动广告我明显感觉到vivo广告小游戏这块的玩法在起变化。以前接个需求不管是品牌方还是代理商过来开口就是“能不能做”然后我把代码工程打开从零开始搭场景、写逻辑、调兼容性一套流程下来少说两三天遇到复杂的玩法一周都不夸张。现在情况不一样了用AI辅助写代码之后整个节奏从“写代码”变成了“说需求”这是一个非常明显的范式转变。以前你写小游戏核心壁垒在工程能力会写JS、懂引擎、知道怎么处理渲染性能这是硬门槛。但现在AI编程工具几乎把代码生成这部分做成了“基本盘”只要你能把需求描述清楚AI就能把七八成的基础代码直接帮你写完。剩下的工作变成了查漏补缺、调整细节、解决AI不知道的项目落地问题。换句话说现在的核心壁垒已经转移到了需求拆解能力你是不是能想明白这个游戏的核心玩法是什么用户点进广告之后三秒钟内要看到什么样的画面玩到第几步会触发转化按钮这些想不明白的话AI再强也帮不了你。这篇文章我就拿vivo广告小游戏的真实项目来说说从“写代码”到“说需求”这个过程到底怎么落地具体的操作流程、提示词怎么写、遇到哪些坑以及怎么把AI生成的代码真正用起来。不管你是刚入门想做互动广告的新手还是已经在做小游戏投放的老手这篇文章应该都能给你一些新思路。1. 内容整体设计与思路拆解1.1 广告小游戏的本质不是游戏是转化工具先把基调定清楚。vivo广告小游戏虽然名字里有“游戏”两个字但它本质上不是游戏而是一个广告转化工具。用户是在刷信息流或者看内容的时候被这个游戏吸引点进来的他的心态是“看看有什么好玩的”而不是“我要认真打完一关”。这就决定了设计逻辑和普通游戏完全不同。普通游戏追求的是沉浸感、操作深度、长期留存而广告小游戏追求的是三个东西秒懂、好玩、自然引导转化。秒懂指的是用户进来三秒钟之内必须明白怎么玩不需要任何新手教程。以前我做过一个玩法用户要控制角色跳跃躲障碍结果用户进来之后站在原地不动因为他没意识到要点击屏幕。后来改了设计角色自动奔跑用户只需要点击让角色跳起来转化率立刻上去了。好玩是广告小游戏的根本驱动力。不好玩的话用户三秒钟就关掉了后面的一切都白搭。但这里要把握好度不能做着做着真去做一个完整的游戏那成本就失控了。自然引导转化是最关键的一点。用户在游戏中玩得很投入时要在合适的节点弹出转化引导比如“再玩一次”“领取奖励”“下载App”等等。但是不能生硬地弹窗打断否则用户会直接流失需要在游戏机制里做设计比如利用关卡结束的间歇、复活的机会等作为触发时机。用“说需求”来替代“写代码”来落实这些最大的变化是我要把上述逻辑变成一个产品经理式的需求文档然后给AI下达指令。1.2 为什么选择AI辅助而不是纯手工写代码有一段时间我也对AI写代码持怀疑态度尤其是写小游戏这种对性能、兼容性要求都很高的场景。但实际用下来后我的结论是今天的AI编程工具完全值得信赖来处理广告小游戏80%的基础代码。vivo广告小游戏的技术栈其实并不复杂主流的实现形式是开屏试玩广告即一个嵌在广告容器内的H5交互页面常用Canvas渲染配合原生JS或轻量级框架完成交互逻辑。技术难点在于性能优化、平台适配、交互流畅度并不在于代码本身有多复杂。AI对这类有成熟模式的代码库了解得很透彻能生成相当准确的结果。我之前做了一个“10秒钟切水果”的小游戏接到需求后我把玩法逻辑描述给AI它一次就生成了一份还算可用的代码。里面的核心逻辑比如水果从屏幕底部飞出、点击水果触发计分、倒计时结束弹结算面板这些它都能准确理解。最让我惊讶的是连音效这些都想到了还会用AudioContext生成简单的切片音效。当然只靠AI一次生成肯定不够后续的调试和优化工作必不可少。但相比从头写纯手工写一个带物理效果的切水果至少需要一整天而有了AI之后基础版本只需一小时就能就位后续调试半天也基本能完成。效率提升非常显著。1.3 “说需求”需要遵循的基本原则跟AI协作写代码并不是说人就可以完全不动脑子了。恰恰相反对人的要求其实更高只是要求的方向从“怎么写代码”变成了“怎么把需求说清楚”。我的经验是给AI描述需求时有三个原则必须遵循第一个原则是结构清晰。不要像聊天一样一句一句地堆需求而是把需求拆成几个维度玩法概述、操作方式、界面布局、交互节点、视觉风格、性能要求。每个维度用一小段话描述清楚AI才能有序地生成代码结构。第二个原则是明确技术边界。告诉AI要用什么技术栈写是纯Canvas还是短小精悍的DOM实现要不要使用物理引擎库要不要支持重力感应。这些不交代清楚AI可能会默认选一个重型的方案导致运行时性能出现问题。第三个原则是提供边界条件。包括用户可能在什么场景下打开这个游戏比如网络环境可能不太好、目标机型性能差异很大、停留时间预期多长时间等。这些条件会影响AI在写代码时的很多默认决策。说白了说需求不是聊天而是把自己变成一个产品经理技术负责人的共同体把脑子里的完整方案清晰地传递出去。2. 核心细节解析与实操要点2.1 需求描述的完整模板结合我实际操作的经验共享一条我一直在用的需求描述模板。这套模板的特点是把技术维度和产品维度拆开说便于AI理解和生成结构化的代码。技术栈例如原生JavaScript Canvas2D渲染玩法概述在限定时间内用户需点击屏幕使人物跳跃躲避障碍物吃到的金豆越多得分越高。核心机制人物在平面上自动向右奔跑点击屏幕人物跳跃跳跃高度固定长按可跳跃更高场景中随机出现障碍物和金豆碰到障碍物游戏结束触发结算面板金豆每吃一个加10分并播放音效时间限制为20秒时间结束自动结算界面布局顶部显示剩余时间和当前得分游戏区域占满全屏结算面板居中弹出显示得分、重新开始按钮、下载按钮视觉风格卡通风格色彩鲜艳适合休闲广告场景。性能要求保证低端机运行时帧率不低于30帧减少重绘区域。其他需要适配不同长宽比的手机屏幕包括全面屏和刘海屏。这段描述看起来不复杂但你细看会发现里面每一条其实都对应着AI生成代码时的关键决策点。比如“长按可跳跃更高”AI就需要在点击事件和长按事件之间做逻辑区分“减少重绘区域”则会影响AI对Canvas绘制方式的组织方式。2.2 核心机制拆解的关键点在我做了大量广告小游戏之后有一个体会越来越深核心机制是否能拆解清楚直接决定了AI生成代码的质量。比如上面提到的跳跃游戏表面看起来很简单但实际上隐藏着很多需要明确的机制细节跳跃是使用抛物线模拟还是动画曲线如果只是视觉上的跳跃那可以用简单的CSS动画或Canvas位移模拟但如果要真实物理碰撞就需要计算重力加速度。判定逻辑是用像素级碰撞检测还是简易的坐标范围判定小游戏建议用后者更加高效且不易出错。障碍物的生成是纯随机还是有最小间距限制如果没有最小间距限制可能会出现连续两个障碍物同时出现导致用户根本无法跳过的情况。这些细节如果不拆解清楚AI生成的方案即使逻辑上没有bug实际体验也会很差。我会在需求描述时把常见的问题提前规避掉。例如遵循我个人经验在需求里加上一条“障碍物生成的最小间距不低于画布宽度的三分之一”这个落地到代码上就避免了碰撞设计缺陷。2.3 选择合适的AI编程工具说到AI编程工具我最常用的是支持Python、JavaScript等主流语言能力的AI助手。在选择工具时有几个核心维度需要评估第一是代码生成能力。不同工具在生成复杂交互逻辑时表现差异很大。拿小游戏来说有些工具只能输出完整的单文件代码简单但缺少拆分意识有些工具则能将代码拆成多个模块并生成对应的调用逻辑。后者显然更接近实际工程的合理实践。第二是对话能力。写小游戏的过程中经常需要在原有生成代码基础上追加修改需求比如“把跳跃高度调低一点”“在结算面板增加一个分享按钮”。对话能力强的AI会基于上下文理解请求输出修改后的完整段而不是从头生成。第三是上下文记忆长度。一次会话中描述完需求后往往会进行多轮修改如果工具的记忆能力不足容易丢失之前的需求细节导致我们反复重申配置非常影响效率。环境配置方面我个人目前的建议是在本地使用编辑器配合AI插件这样能同时利用AI的能力和本地的调试工具。本地小游戏开发调试比较方便可以用匿名函数或模块方式组织代码以便快速定位问题。2.4 需求描述的避坑指南按照我的经验“说需求”这个环节最容易犯三个错误写出来供大家参考。第一个错误是过度描述。有些开发者觉得描述得越详细越好于是把代码层面的实现细节全部塞给AI比如“创建一个while循环”“使用for遍历数组”。这样做限制了AI的判断能力反而容易生成四不像的代码。AI的价值在于它的海量知识库给它留出可实现的自由度通常是更好的协作方式。第二个错误是忽略平台约束。vivo广告小游戏运行环境有自己特定的要求比如容器大小、API可用性、加载方式等。如果在需求描述里不提这些约束AI可能会生成一些在标准浏览器上运行良好但是在此平台上有兼容性问题的代码。比如要确保长按事件用Pointer Events实现而且不依赖第三方框架来绑定事件。第三个错误是一次描述就到终点。写小游戏是一个迭代的过程需求描述也需要逐步推进。我通常的做法是第一次描述核心玩法拿到基础版本后再描述视觉和交互细节最后再描述性能和兼容性要求。这也符合我开发时一贯的思路——保证核心机制先跑通再逐步丰满细节。3. 实操过程与核心环节实现3.1 一个完整的实操案例vivo广告小游戏“摇一摇福袋”说得再多也不如跑一个真实案例。我这里就以一个vivo广告小游戏常见的“摇一摇福袋”作为案例完整演示从说需求到代码落地的全过程。先说一下场景。这个游戏的玩法很简单小游戏广告场景中用户点击并晃动手机来打开福袋获取福利或抽奖机会。这类玩法的转化率极高因为玩法本身零门槛并且利用了用户的参与感和期待感。我把需求按模板整理好投喂给AI目标代码结构是这样的监听devicemotion事件识别手机摇晃动作摇晃达到阈值后触发福袋打开动画福袋打开后展示奖品内容随机从奖品数组中抽取展示“继续抽奖”按钮引导用户参与页面加载时预加载奖品图片我把这些需求发给AI它还帮我加了一个关键反馈——摇晃过程中用canvas绘制一个进度条让用户知道“还需要摇多久”这个体验设计确实非常好。3.2 核心代码实现与解析AI生成的核心代码大概长这样// 摇一摇福袋 - 核心逻辑 const container document.getElementById(game-container); const canvas document.createElement(canvas); const ctx canvas.getContext(2d); container.appendChild(canvas); // 配置 const SHAKE_THRESHOLD 25; // 摇晃力度阈值 const PRIZE_LIST [ { name: 谢谢参与, weight: 40 }, { name: 1元红包, weight: 30 }, { name: 3元红包, weight: 20 }, { name: 5元红包, weight: 10 } ]; let shakeCount 0; const SHAKE_TARGET 8; // 需要摇晃次数 let isOpening false; // 奖品加权随机抽选 function getRandomPrize() { const totalWeight PRIZE_LIST.reduce((sum, p) sum p.weight, 0); let random Math.random() * totalWeight; for (const prize of PRIZE_LIST) { if (random prize.weight) return prize; random - prize.weight; } return PRIZE_LIST[0]; } // 加速度检测 let lastX 0, lastY 0, lastZ 0; window.addEventListener(devicemotion, (event) { const acc event.accelerationIncludingGravity; const x acc.x || 0; const y acc.y || 0; const z acc.z || 0; const deltaX Math.abs(x - lastX); const deltaY Math.abs(y - lastY); const deltaZ Math.abs(z - lastZ); const deltaTotal deltaX deltaY deltaZ; if (deltaTotal SHAKE_THRESHOLD) { shakeCount; updateProgressBar(shakeCount / SHAKE_TARGET); lastX x; lastY y; lastZ z; } if (shakeCount SHAKE_TARGET !isOpening) { isOpening true; openLuckBag(getRandomPrize()); } }); // 绘制进度条 function updateProgressBar(percentage) { ctx.clearRect(0, 0, canvas.width, canvas.height); ctx.fillStyle #FFD700; ctx.beginPath(); ctx.arc(canvas.width / 2, canvas.height / 2, 100, -Math.PI / 2, -Math.PI / 2 2 * Math.PI * percentage); ctx.fill(); // ...省略部分绘制逻辑 }这块代码在手机上实测没有问题。但也有一些逻辑正确但不完善的点需要手工调整比如devicemotion事件在桌面浏览器上根本不会触发所以我还需要加一个键盘点击的替代方案方便在开发调试时模拟。AI生成的基础代码已经能处理主要部分剩下的补充工作不多但都是关键的经验补充。3.3 完整的工作流程整理完整跑完一次需求到发布我的工作流程大致如下第一步是描述需求。按照前面提到的模板写清楚玩法、机制、界面、视觉和约束。第二步是代码生成。把需求描述交给AI拿到基础代码。这一步通常会有多轮对话比如我描述了需求之后AI生成了一份代码我要求“给代码加上更详细的注释”或“把进度条改成圆形”它会基于上下文进行调整。第三步是本地联调。把代码放到本地调试页面里用开发者工具模拟不同尺寸的屏幕测试。vivo广告小游戏的调试跟浏览器开发类似重点要看帧率和内存占用。我通常会打开Performance面板看看有没有性能瓶颈。第四步是平台适配。因为vivo广告小游戏运行在真实设备上要考虑WebView的兼容性。比如低版本安卓的WebView可能不支持部分ES6语法需要在构建时做转换处理。我会明确告知AI要兼容的浏览器版本范围并要求它避免使用过新的特性。第五步是真机验证。这个环节强烈不建议跳过。有些问题只有在真机上才能暴露出来比如点击延迟、帧率波动、内存不足等。我习惯准备一台中低端机和一台高端机做对照测试。第六步是投放数据回收与分析。游戏上线后要关注各项指标尤其是点击率、完整玩完率和转化率。数据反馈是后续优化小游戏最重要的依据之一。3.4 如何让AI生成的代码更符合平台要求这里要特别说明一下vivo广告小游戏平台的一些特殊性以及如何通过调整需求描述让代码更符合平台要求。首先vivo广告小游戏的容器加载一般要快如果代码体积过大或加载资源过多会导致用户等待时间变长产生流失。所以在需求描述里说明“尽量减少资源加载使用内联SVG和CSS绘制图形而不是加载图片”AI就会倾向于生成轻量代码。其次交互事件要处理得体。在iOS和Android的WebView里点击事件会存在300ms延迟的问题。我会要求AI“所有交互事件必须使用touch事件或pointer事件”实际测试下来这个要求能极大提升操作的灵敏度和流畅感。另外广告小游戏一般要控制时长不同平台对“试玩广告”的时长限制不同。我通常会在需求描述里写明“游戏时长控制在15-20秒以内”这样AI在生成结算逻辑时会把时长作为核心参数而不是默认做成一个可以无限玩下去的休闲游戏。这点尤其重要因为它直接影响转化路径的设计。4. 常见问题与排查技巧实录4.1 性能问题低端机掉帧严重做vivo广告小游戏时最常遇到的问题是性能低下尤其是在中低端Android机上。有一次我把一个AI生成的完整小游戏代码放到真机上跑发现页面明显卡顿滑动和点击反馈都有明显的延迟。排查后发现问题出在大量使用CSS动画和box-shadow效果上尤其是多个动画同时运行时低端机的GPU渲染压力很大导致帧率直线下降。解决办法是改用Canvas绘制一些高频动画降低阴影和模糊效果的使用频率。在这个场景里也可以在需求描述阶段就要求AI“尽量避免使用CSS动画处理高频循环优先使用Canvas API实现动画效果”让问题提前被规避。AI表现在这个环节是相当靠谱的。只要我在需求描述里写清楚了“面向低端机型做性能优化”它生成的代码会自动做一些防御性处理比如用requestAnimationFrame做动画循环、限定内存缓存大小等。4.2 兼容性问题部分机器没有声音和触感反馈异常还有一个高频问题音乐和点击音效在某些机型上不播放。这是因为很多低版本浏览器WebView不支持自动播放音频需要等待用户交互后才能开始播放音频。AI生成的代码通常不会自动处理这个限制。我必须在代码里增加一个用户交互后初始化音频上下文的逻辑比如let audioContext; document.addEventListener(touchstart, initAudio, { once: true }); function initAudio() { audioContext new AudioContext(); }如果不想在需求描述里写这么细节的东西至少可以在描述中加一句“注意音频需要在用户操作后才能播放”。AI通常会理解这句话并给出合理处理方式但以防AI默认使用自动播放逻辑细节提醒仍然重要。触感反馈这块也值得注意。虽然部分现代手机支持Vibration API但低端机和部分系统版本并不支持。处理方式是在代码里检测navigator.vibrate是否存在不存在则降级处理这个在AI生成代码时通常默认包含。4.3 AI代码不改不能直接用我必须诚实地提醒大家一个事实AI生成的广告小游戏代码很少能做到一次全对、直接上线。经过大量测试评测AI生成的代码在核心逻辑组成上准确率很高但在跟平台细节结合的层面几乎每次都有一到两处需要修正的地方。比较典型的几个问题未适配刘海屏导致顶部显示被遮挡未处理页面回退事件导致的退出异常使用现代API但平台WebView支持度不足内存管理缺失导致长时间运行占内存持续增加这也解释了为什么“说需求”这个环节如此重要。把需求描述得越清楚AI生成的代码犯错的概率就越小。AI并不是替代了开发而是将开发从90%的代码编写工作重压中释放了出来让人能把精力聚焦到剩下的10%关键优化中去。4.4 常见问题速查表为了省去大家排查问题的时间整理了一份广告小游戏AI辅助开发常见问题速查表问题现象可能原因解决方案点击无反应事件绑定错误/300ms延迟改用touch或pointer事件界面布局错乱未适配全面屏或刘海屏使用安全区域APIViewport适配音频无法播放浏览器自动播放限制用户手势后初始化音频上下文动画卡顿掉帧高频CSS动画/重绘区域过大改用Canvas绘制限制重绘区域真机无音效平台默认为系统静音检测并提示用户打开媒体音量机器发热严重动画帧数过高/密集计算降低帧数为30-60fps优化循环加载时间过长资源文件过多过大压缩素材使用内联图形4.5 调试工具和流程建议这里再分享一套我日常调试vivo广告小游戏的工具和方法首要推荐使用Chrome DevTools的Device Toolbar模式。通过模拟低配机型的CPU和GPU性能可以提前预判中低端机的运行状态。对于动画性能评测我倾向于用Performance面板记录帧率并用Lighthouse进行基础性能评分。其次在真机测试阶段可以使用基于WebView的调试工具方便查看Console的报错信息和网络请求。在调试流程上我的顺序是先桌面浏览器静态环境调试再开发者工具模拟设备最后真机交叉验证。这个顺序能最大程度减少现场问题。5. 写代码和说需求的能力互补关系5.1 说需求的基础仍是理解代码逻辑很多想转行或刚入门的朋友会误以为“说需求”意味着完全不需要会写代码这是一个严重的误解。以我个人经历而言AI协作效果最好的时刻恰恰是我对代码逻辑理解最深入的时刻。正因为我知道代码应该如何组织、事件应该怎么绑定、性能瓶颈可能出现在哪里我才能把需求描述得精准到位才能在AI生成的代码里快速定位问题。比如前面说的“摇一摇福袋”案例。AI生成的代码里进度条绘制每次都是先clearRect再画这个逻辑在理论上没问题但如果把频率调高在某些机型上可能会出现界面闪烁。这类微观层面的问题如果完全不懂Canvas的绘制机制是很难发现并修改的。所以“说需求”是一个门槛更高的工作它要求你能用人类语言精确表达机器逻辑这比直接写机器语言更考验思维清晰度。5.2 说需求释放了更多创造空间虽然门槛变高了但“说需求”确实解放了开发者的一大块时间和精力这也让我们有更多空间去思考创意层面的设计。以前我做一个新广告小游戏最耗时的往往是环境和基础逻辑的实现。现在有了AI我这个部分可以做得比较快剩下来的时间大部分用在琢磨交互细节和转化数据上了。比如我会花大量时间研究用户玩到第几步时弹奖励最合适关卡的难度曲线怎么设计才能让玩家在大概10秒时产生客服链接的欲望结算面板上按钮的文案怎么表达才能提高点选率这些才是广告小游戏的核心竞争力也恰恰是机器暂时无法取代的部分。从这个角度来说“写代码”到“说需求”的转变对行业的影响是正向的它将从业者的工作重心从低价值的体力劳动解放出来引导向更高价值的思考与决策。5.3 未来的广告小游戏开发者画像从目前的发展趋势看未来的广告小游戏开发者画像大概会是这样他们首先是一名产品策划能够快速定义玩法、目标与转化路径同时他们具备技术视野知道在不同技术选型间如何取舍并能对AI生成的代码做技术评审他们也具备数据敏感度能根据投放数据快速迭代游戏方案。技术人员仍然需要掌握一定的代码能力但未必需要达到手工完成全部实现的程度。多关注提示词工程和AI协作技巧反而会成为更核心的竞争力。有一次我跟一个做广告优化的同事聊天他说自己从小没学过编程但最近也开始用AI工具做一些简单的互动页面效果还挺好。这说明“说需求”这一模式的适用范围远比我们想的更广它让更多非技术背景的人参与到互动创意的生产中来。而这个趋势对vivo广告小游戏这种依赖创意、需要快速迭代的领域意义尤其明显。6. 个人经验小结与后续拓展建议6.1 从需求到代码我最常用的一套提示词最后分享一套我自己经常用来做小游戏AI提示词的底座可以直接复制修改使用你是一名资深的小游戏开发工程师专注于H5互动广告的开发。 请根据以下需求完成一个可运行的广告小游戏 玩法概述一句话描述核心玩法 核心机制描述关键交互和逻辑 界面布局描述页面上各元素的排列 视觉风格描述美术风格 技术限定指定技术栈例如原生JSCanvas不引入外部库 代码要求 - 单文件HTML内联CSS和JS方便直接预览 - 代码注释覆盖关键逻辑 - 适配移动端常用分辨率兼容刘海屏 - 性能优先避免高频CSS动画 - 用中文注释这段提示词的威力在于它一次性把项目的类型、技术边界、输出格式和质量要求都说清楚了。我实测下来AI对这类提示词的响应质量非常稳定很少出现代码结构乱七八糟的情况。6.2 快速验证创意的“十分钟工作流”我发现AI辅助开发最实用的一个场景是快速验证创意。假设灵感来了想验证一个脑洞玩法是否可行以前得写一两个小时的代码才能看到效果。现在我的做法是花五分钟写一份足够简略的需求描述直接让AI生成一份原型代码然后在浏览器里打开看效果。如果玩法反馈好就继续细化和迭代如果反馈不好就果断换方案。这个流程把单个创意的验证成本从几小时压缩到了十几分钟对个人或小团队来说试错空间就大得多。在做vivo广告小游戏这个领域创意更新频率极快用户品味也变化很快能快速试错本身就是很大的竞争优势。我用这套流程做过一个“数字接龙”的创意初版AI只用了七分钟就生成完成虽然不需要很复杂但已经可以点击操作了。虽然后来这个创意没有进入正式投放但整个验证过程几乎没有成本。6.3 给新手读者的三条建议如果你刚接触这个领域想尝试用AI来做vivo广告小游戏我建议你从以下三个方向入手第一条建议从仿写一个经典玩法开始。不要去凭空创造玩法先选一个市面上验证过的经典玩法比如打地鼠、翻牌配对、重力滚球用AI复刻它。在这个过程中重点体会你是怎么描述玩法的AI是怎么把描述变成代码的哪些描述方式能让它准确理解哪些不能。第二条建议构建自己的需求描述模板库。每做一个项目就把需求描述文件保存下来总结哪些部分有效哪些部分会导致AI生成偏离预期的代码。久而久之你会形成一套高效的个人模板。第三条建议边做边学代码逻辑但不用从头啃完整套知识。跟着AI生成的代码逐行去理解和修改遇到不懂的知识点再单独查阅。在这个试错过程中积累起来的技术判断力远比死记硬背语法更有价值。在我看来做vivo广告小游戏核心竞争力从来不是能写出别人写不出来的代码而是能做出让用户愿意点、愿意玩、愿意转化的小创意。AI的普及把实现门槛大幅拉低之后真正拼的还是创意能力和对用户心理的把控力。而“说需求”这门手艺就是连接创意与实现之间的那座桥。在实际项目中我把需求描述清楚的能力已经变成了和写代码能力同等重要的核心竞争力甚至在某些场景下更加宝贵。
从写代码到说需求：AI重构vivo广告小游戏开发范式
做了这么多年小游戏和互动广告我明显感觉到vivo广告小游戏这块的玩法在起变化。以前接个需求不管是品牌方还是代理商过来开口就是“能不能做”然后我把代码工程打开从零开始搭场景、写逻辑、调兼容性一套流程下来少说两三天遇到复杂的玩法一周都不夸张。现在情况不一样了用AI辅助写代码之后整个节奏从“写代码”变成了“说需求”这是一个非常明显的范式转变。以前你写小游戏核心壁垒在工程能力会写JS、懂引擎、知道怎么处理渲染性能这是硬门槛。但现在AI编程工具几乎把代码生成这部分做成了“基本盘”只要你能把需求描述清楚AI就能把七八成的基础代码直接帮你写完。剩下的工作变成了查漏补缺、调整细节、解决AI不知道的项目落地问题。换句话说现在的核心壁垒已经转移到了需求拆解能力你是不是能想明白这个游戏的核心玩法是什么用户点进广告之后三秒钟内要看到什么样的画面玩到第几步会触发转化按钮这些想不明白的话AI再强也帮不了你。这篇文章我就拿vivo广告小游戏的真实项目来说说从“写代码”到“说需求”这个过程到底怎么落地具体的操作流程、提示词怎么写、遇到哪些坑以及怎么把AI生成的代码真正用起来。不管你是刚入门想做互动广告的新手还是已经在做小游戏投放的老手这篇文章应该都能给你一些新思路。1. 内容整体设计与思路拆解1.1 广告小游戏的本质不是游戏是转化工具先把基调定清楚。vivo广告小游戏虽然名字里有“游戏”两个字但它本质上不是游戏而是一个广告转化工具。用户是在刷信息流或者看内容的时候被这个游戏吸引点进来的他的心态是“看看有什么好玩的”而不是“我要认真打完一关”。这就决定了设计逻辑和普通游戏完全不同。普通游戏追求的是沉浸感、操作深度、长期留存而广告小游戏追求的是三个东西秒懂、好玩、自然引导转化。秒懂指的是用户进来三秒钟之内必须明白怎么玩不需要任何新手教程。以前我做过一个玩法用户要控制角色跳跃躲障碍结果用户进来之后站在原地不动因为他没意识到要点击屏幕。后来改了设计角色自动奔跑用户只需要点击让角色跳起来转化率立刻上去了。好玩是广告小游戏的根本驱动力。不好玩的话用户三秒钟就关掉了后面的一切都白搭。但这里要把握好度不能做着做着真去做一个完整的游戏那成本就失控了。自然引导转化是最关键的一点。用户在游戏中玩得很投入时要在合适的节点弹出转化引导比如“再玩一次”“领取奖励”“下载App”等等。但是不能生硬地弹窗打断否则用户会直接流失需要在游戏机制里做设计比如利用关卡结束的间歇、复活的机会等作为触发时机。用“说需求”来替代“写代码”来落实这些最大的变化是我要把上述逻辑变成一个产品经理式的需求文档然后给AI下达指令。1.2 为什么选择AI辅助而不是纯手工写代码有一段时间我也对AI写代码持怀疑态度尤其是写小游戏这种对性能、兼容性要求都很高的场景。但实际用下来后我的结论是今天的AI编程工具完全值得信赖来处理广告小游戏80%的基础代码。vivo广告小游戏的技术栈其实并不复杂主流的实现形式是开屏试玩广告即一个嵌在广告容器内的H5交互页面常用Canvas渲染配合原生JS或轻量级框架完成交互逻辑。技术难点在于性能优化、平台适配、交互流畅度并不在于代码本身有多复杂。AI对这类有成熟模式的代码库了解得很透彻能生成相当准确的结果。我之前做了一个“10秒钟切水果”的小游戏接到需求后我把玩法逻辑描述给AI它一次就生成了一份还算可用的代码。里面的核心逻辑比如水果从屏幕底部飞出、点击水果触发计分、倒计时结束弹结算面板这些它都能准确理解。最让我惊讶的是连音效这些都想到了还会用AudioContext生成简单的切片音效。当然只靠AI一次生成肯定不够后续的调试和优化工作必不可少。但相比从头写纯手工写一个带物理效果的切水果至少需要一整天而有了AI之后基础版本只需一小时就能就位后续调试半天也基本能完成。效率提升非常显著。1.3 “说需求”需要遵循的基本原则跟AI协作写代码并不是说人就可以完全不动脑子了。恰恰相反对人的要求其实更高只是要求的方向从“怎么写代码”变成了“怎么把需求说清楚”。我的经验是给AI描述需求时有三个原则必须遵循第一个原则是结构清晰。不要像聊天一样一句一句地堆需求而是把需求拆成几个维度玩法概述、操作方式、界面布局、交互节点、视觉风格、性能要求。每个维度用一小段话描述清楚AI才能有序地生成代码结构。第二个原则是明确技术边界。告诉AI要用什么技术栈写是纯Canvas还是短小精悍的DOM实现要不要使用物理引擎库要不要支持重力感应。这些不交代清楚AI可能会默认选一个重型的方案导致运行时性能出现问题。第三个原则是提供边界条件。包括用户可能在什么场景下打开这个游戏比如网络环境可能不太好、目标机型性能差异很大、停留时间预期多长时间等。这些条件会影响AI在写代码时的很多默认决策。说白了说需求不是聊天而是把自己变成一个产品经理技术负责人的共同体把脑子里的完整方案清晰地传递出去。2. 核心细节解析与实操要点2.1 需求描述的完整模板结合我实际操作的经验共享一条我一直在用的需求描述模板。这套模板的特点是把技术维度和产品维度拆开说便于AI理解和生成结构化的代码。技术栈例如原生JavaScript Canvas2D渲染玩法概述在限定时间内用户需点击屏幕使人物跳跃躲避障碍物吃到的金豆越多得分越高。核心机制人物在平面上自动向右奔跑点击屏幕人物跳跃跳跃高度固定长按可跳跃更高场景中随机出现障碍物和金豆碰到障碍物游戏结束触发结算面板金豆每吃一个加10分并播放音效时间限制为20秒时间结束自动结算界面布局顶部显示剩余时间和当前得分游戏区域占满全屏结算面板居中弹出显示得分、重新开始按钮、下载按钮视觉风格卡通风格色彩鲜艳适合休闲广告场景。性能要求保证低端机运行时帧率不低于30帧减少重绘区域。其他需要适配不同长宽比的手机屏幕包括全面屏和刘海屏。这段描述看起来不复杂但你细看会发现里面每一条其实都对应着AI生成代码时的关键决策点。比如“长按可跳跃更高”AI就需要在点击事件和长按事件之间做逻辑区分“减少重绘区域”则会影响AI对Canvas绘制方式的组织方式。2.2 核心机制拆解的关键点在我做了大量广告小游戏之后有一个体会越来越深核心机制是否能拆解清楚直接决定了AI生成代码的质量。比如上面提到的跳跃游戏表面看起来很简单但实际上隐藏着很多需要明确的机制细节跳跃是使用抛物线模拟还是动画曲线如果只是视觉上的跳跃那可以用简单的CSS动画或Canvas位移模拟但如果要真实物理碰撞就需要计算重力加速度。判定逻辑是用像素级碰撞检测还是简易的坐标范围判定小游戏建议用后者更加高效且不易出错。障碍物的生成是纯随机还是有最小间距限制如果没有最小间距限制可能会出现连续两个障碍物同时出现导致用户根本无法跳过的情况。这些细节如果不拆解清楚AI生成的方案即使逻辑上没有bug实际体验也会很差。我会在需求描述时把常见的问题提前规避掉。例如遵循我个人经验在需求里加上一条“障碍物生成的最小间距不低于画布宽度的三分之一”这个落地到代码上就避免了碰撞设计缺陷。2.3 选择合适的AI编程工具说到AI编程工具我最常用的是支持Python、JavaScript等主流语言能力的AI助手。在选择工具时有几个核心维度需要评估第一是代码生成能力。不同工具在生成复杂交互逻辑时表现差异很大。拿小游戏来说有些工具只能输出完整的单文件代码简单但缺少拆分意识有些工具则能将代码拆成多个模块并生成对应的调用逻辑。后者显然更接近实际工程的合理实践。第二是对话能力。写小游戏的过程中经常需要在原有生成代码基础上追加修改需求比如“把跳跃高度调低一点”“在结算面板增加一个分享按钮”。对话能力强的AI会基于上下文理解请求输出修改后的完整段而不是从头生成。第三是上下文记忆长度。一次会话中描述完需求后往往会进行多轮修改如果工具的记忆能力不足容易丢失之前的需求细节导致我们反复重申配置非常影响效率。环境配置方面我个人目前的建议是在本地使用编辑器配合AI插件这样能同时利用AI的能力和本地的调试工具。本地小游戏开发调试比较方便可以用匿名函数或模块方式组织代码以便快速定位问题。2.4 需求描述的避坑指南按照我的经验“说需求”这个环节最容易犯三个错误写出来供大家参考。第一个错误是过度描述。有些开发者觉得描述得越详细越好于是把代码层面的实现细节全部塞给AI比如“创建一个while循环”“使用for遍历数组”。这样做限制了AI的判断能力反而容易生成四不像的代码。AI的价值在于它的海量知识库给它留出可实现的自由度通常是更好的协作方式。第二个错误是忽略平台约束。vivo广告小游戏运行环境有自己特定的要求比如容器大小、API可用性、加载方式等。如果在需求描述里不提这些约束AI可能会生成一些在标准浏览器上运行良好但是在此平台上有兼容性问题的代码。比如要确保长按事件用Pointer Events实现而且不依赖第三方框架来绑定事件。第三个错误是一次描述就到终点。写小游戏是一个迭代的过程需求描述也需要逐步推进。我通常的做法是第一次描述核心玩法拿到基础版本后再描述视觉和交互细节最后再描述性能和兼容性要求。这也符合我开发时一贯的思路——保证核心机制先跑通再逐步丰满细节。3. 实操过程与核心环节实现3.1 一个完整的实操案例vivo广告小游戏“摇一摇福袋”说得再多也不如跑一个真实案例。我这里就以一个vivo广告小游戏常见的“摇一摇福袋”作为案例完整演示从说需求到代码落地的全过程。先说一下场景。这个游戏的玩法很简单小游戏广告场景中用户点击并晃动手机来打开福袋获取福利或抽奖机会。这类玩法的转化率极高因为玩法本身零门槛并且利用了用户的参与感和期待感。我把需求按模板整理好投喂给AI目标代码结构是这样的监听devicemotion事件识别手机摇晃动作摇晃达到阈值后触发福袋打开动画福袋打开后展示奖品内容随机从奖品数组中抽取展示“继续抽奖”按钮引导用户参与页面加载时预加载奖品图片我把这些需求发给AI它还帮我加了一个关键反馈——摇晃过程中用canvas绘制一个进度条让用户知道“还需要摇多久”这个体验设计确实非常好。3.2 核心代码实现与解析AI生成的核心代码大概长这样// 摇一摇福袋 - 核心逻辑 const container document.getElementById(game-container); const canvas document.createElement(canvas); const ctx canvas.getContext(2d); container.appendChild(canvas); // 配置 const SHAKE_THRESHOLD 25; // 摇晃力度阈值 const PRIZE_LIST [ { name: 谢谢参与, weight: 40 }, { name: 1元红包, weight: 30 }, { name: 3元红包, weight: 20 }, { name: 5元红包, weight: 10 } ]; let shakeCount 0; const SHAKE_TARGET 8; // 需要摇晃次数 let isOpening false; // 奖品加权随机抽选 function getRandomPrize() { const totalWeight PRIZE_LIST.reduce((sum, p) sum p.weight, 0); let random Math.random() * totalWeight; for (const prize of PRIZE_LIST) { if (random prize.weight) return prize; random - prize.weight; } return PRIZE_LIST[0]; } // 加速度检测 let lastX 0, lastY 0, lastZ 0; window.addEventListener(devicemotion, (event) { const acc event.accelerationIncludingGravity; const x acc.x || 0; const y acc.y || 0; const z acc.z || 0; const deltaX Math.abs(x - lastX); const deltaY Math.abs(y - lastY); const deltaZ Math.abs(z - lastZ); const deltaTotal deltaX deltaY deltaZ; if (deltaTotal SHAKE_THRESHOLD) { shakeCount; updateProgressBar(shakeCount / SHAKE_TARGET); lastX x; lastY y; lastZ z; } if (shakeCount SHAKE_TARGET !isOpening) { isOpening true; openLuckBag(getRandomPrize()); } }); // 绘制进度条 function updateProgressBar(percentage) { ctx.clearRect(0, 0, canvas.width, canvas.height); ctx.fillStyle #FFD700; ctx.beginPath(); ctx.arc(canvas.width / 2, canvas.height / 2, 100, -Math.PI / 2, -Math.PI / 2 2 * Math.PI * percentage); ctx.fill(); // ...省略部分绘制逻辑 }这块代码在手机上实测没有问题。但也有一些逻辑正确但不完善的点需要手工调整比如devicemotion事件在桌面浏览器上根本不会触发所以我还需要加一个键盘点击的替代方案方便在开发调试时模拟。AI生成的基础代码已经能处理主要部分剩下的补充工作不多但都是关键的经验补充。3.3 完整的工作流程整理完整跑完一次需求到发布我的工作流程大致如下第一步是描述需求。按照前面提到的模板写清楚玩法、机制、界面、视觉和约束。第二步是代码生成。把需求描述交给AI拿到基础代码。这一步通常会有多轮对话比如我描述了需求之后AI生成了一份代码我要求“给代码加上更详细的注释”或“把进度条改成圆形”它会基于上下文进行调整。第三步是本地联调。把代码放到本地调试页面里用开发者工具模拟不同尺寸的屏幕测试。vivo广告小游戏的调试跟浏览器开发类似重点要看帧率和内存占用。我通常会打开Performance面板看看有没有性能瓶颈。第四步是平台适配。因为vivo广告小游戏运行在真实设备上要考虑WebView的兼容性。比如低版本安卓的WebView可能不支持部分ES6语法需要在构建时做转换处理。我会明确告知AI要兼容的浏览器版本范围并要求它避免使用过新的特性。第五步是真机验证。这个环节强烈不建议跳过。有些问题只有在真机上才能暴露出来比如点击延迟、帧率波动、内存不足等。我习惯准备一台中低端机和一台高端机做对照测试。第六步是投放数据回收与分析。游戏上线后要关注各项指标尤其是点击率、完整玩完率和转化率。数据反馈是后续优化小游戏最重要的依据之一。3.4 如何让AI生成的代码更符合平台要求这里要特别说明一下vivo广告小游戏平台的一些特殊性以及如何通过调整需求描述让代码更符合平台要求。首先vivo广告小游戏的容器加载一般要快如果代码体积过大或加载资源过多会导致用户等待时间变长产生流失。所以在需求描述里说明“尽量减少资源加载使用内联SVG和CSS绘制图形而不是加载图片”AI就会倾向于生成轻量代码。其次交互事件要处理得体。在iOS和Android的WebView里点击事件会存在300ms延迟的问题。我会要求AI“所有交互事件必须使用touch事件或pointer事件”实际测试下来这个要求能极大提升操作的灵敏度和流畅感。另外广告小游戏一般要控制时长不同平台对“试玩广告”的时长限制不同。我通常会在需求描述里写明“游戏时长控制在15-20秒以内”这样AI在生成结算逻辑时会把时长作为核心参数而不是默认做成一个可以无限玩下去的休闲游戏。这点尤其重要因为它直接影响转化路径的设计。4. 常见问题与排查技巧实录4.1 性能问题低端机掉帧严重做vivo广告小游戏时最常遇到的问题是性能低下尤其是在中低端Android机上。有一次我把一个AI生成的完整小游戏代码放到真机上跑发现页面明显卡顿滑动和点击反馈都有明显的延迟。排查后发现问题出在大量使用CSS动画和box-shadow效果上尤其是多个动画同时运行时低端机的GPU渲染压力很大导致帧率直线下降。解决办法是改用Canvas绘制一些高频动画降低阴影和模糊效果的使用频率。在这个场景里也可以在需求描述阶段就要求AI“尽量避免使用CSS动画处理高频循环优先使用Canvas API实现动画效果”让问题提前被规避。AI表现在这个环节是相当靠谱的。只要我在需求描述里写清楚了“面向低端机型做性能优化”它生成的代码会自动做一些防御性处理比如用requestAnimationFrame做动画循环、限定内存缓存大小等。4.2 兼容性问题部分机器没有声音和触感反馈异常还有一个高频问题音乐和点击音效在某些机型上不播放。这是因为很多低版本浏览器WebView不支持自动播放音频需要等待用户交互后才能开始播放音频。AI生成的代码通常不会自动处理这个限制。我必须在代码里增加一个用户交互后初始化音频上下文的逻辑比如let audioContext; document.addEventListener(touchstart, initAudio, { once: true }); function initAudio() { audioContext new AudioContext(); }如果不想在需求描述里写这么细节的东西至少可以在描述中加一句“注意音频需要在用户操作后才能播放”。AI通常会理解这句话并给出合理处理方式但以防AI默认使用自动播放逻辑细节提醒仍然重要。触感反馈这块也值得注意。虽然部分现代手机支持Vibration API但低端机和部分系统版本并不支持。处理方式是在代码里检测navigator.vibrate是否存在不存在则降级处理这个在AI生成代码时通常默认包含。4.3 AI代码不改不能直接用我必须诚实地提醒大家一个事实AI生成的广告小游戏代码很少能做到一次全对、直接上线。经过大量测试评测AI生成的代码在核心逻辑组成上准确率很高但在跟平台细节结合的层面几乎每次都有一到两处需要修正的地方。比较典型的几个问题未适配刘海屏导致顶部显示被遮挡未处理页面回退事件导致的退出异常使用现代API但平台WebView支持度不足内存管理缺失导致长时间运行占内存持续增加这也解释了为什么“说需求”这个环节如此重要。把需求描述得越清楚AI生成的代码犯错的概率就越小。AI并不是替代了开发而是将开发从90%的代码编写工作重压中释放了出来让人能把精力聚焦到剩下的10%关键优化中去。4.4 常见问题速查表为了省去大家排查问题的时间整理了一份广告小游戏AI辅助开发常见问题速查表问题现象可能原因解决方案点击无反应事件绑定错误/300ms延迟改用touch或pointer事件界面布局错乱未适配全面屏或刘海屏使用安全区域APIViewport适配音频无法播放浏览器自动播放限制用户手势后初始化音频上下文动画卡顿掉帧高频CSS动画/重绘区域过大改用Canvas绘制限制重绘区域真机无音效平台默认为系统静音检测并提示用户打开媒体音量机器发热严重动画帧数过高/密集计算降低帧数为30-60fps优化循环加载时间过长资源文件过多过大压缩素材使用内联图形4.5 调试工具和流程建议这里再分享一套我日常调试vivo广告小游戏的工具和方法首要推荐使用Chrome DevTools的Device Toolbar模式。通过模拟低配机型的CPU和GPU性能可以提前预判中低端机的运行状态。对于动画性能评测我倾向于用Performance面板记录帧率并用Lighthouse进行基础性能评分。其次在真机测试阶段可以使用基于WebView的调试工具方便查看Console的报错信息和网络请求。在调试流程上我的顺序是先桌面浏览器静态环境调试再开发者工具模拟设备最后真机交叉验证。这个顺序能最大程度减少现场问题。5. 写代码和说需求的能力互补关系5.1 说需求的基础仍是理解代码逻辑很多想转行或刚入门的朋友会误以为“说需求”意味着完全不需要会写代码这是一个严重的误解。以我个人经历而言AI协作效果最好的时刻恰恰是我对代码逻辑理解最深入的时刻。正因为我知道代码应该如何组织、事件应该怎么绑定、性能瓶颈可能出现在哪里我才能把需求描述得精准到位才能在AI生成的代码里快速定位问题。比如前面说的“摇一摇福袋”案例。AI生成的代码里进度条绘制每次都是先clearRect再画这个逻辑在理论上没问题但如果把频率调高在某些机型上可能会出现界面闪烁。这类微观层面的问题如果完全不懂Canvas的绘制机制是很难发现并修改的。所以“说需求”是一个门槛更高的工作它要求你能用人类语言精确表达机器逻辑这比直接写机器语言更考验思维清晰度。5.2 说需求释放了更多创造空间虽然门槛变高了但“说需求”确实解放了开发者的一大块时间和精力这也让我们有更多空间去思考创意层面的设计。以前我做一个新广告小游戏最耗时的往往是环境和基础逻辑的实现。现在有了AI我这个部分可以做得比较快剩下来的时间大部分用在琢磨交互细节和转化数据上了。比如我会花大量时间研究用户玩到第几步时弹奖励最合适关卡的难度曲线怎么设计才能让玩家在大概10秒时产生客服链接的欲望结算面板上按钮的文案怎么表达才能提高点选率这些才是广告小游戏的核心竞争力也恰恰是机器暂时无法取代的部分。从这个角度来说“写代码”到“说需求”的转变对行业的影响是正向的它将从业者的工作重心从低价值的体力劳动解放出来引导向更高价值的思考与决策。5.3 未来的广告小游戏开发者画像从目前的发展趋势看未来的广告小游戏开发者画像大概会是这样他们首先是一名产品策划能够快速定义玩法、目标与转化路径同时他们具备技术视野知道在不同技术选型间如何取舍并能对AI生成的代码做技术评审他们也具备数据敏感度能根据投放数据快速迭代游戏方案。技术人员仍然需要掌握一定的代码能力但未必需要达到手工完成全部实现的程度。多关注提示词工程和AI协作技巧反而会成为更核心的竞争力。有一次我跟一个做广告优化的同事聊天他说自己从小没学过编程但最近也开始用AI工具做一些简单的互动页面效果还挺好。这说明“说需求”这一模式的适用范围远比我们想的更广它让更多非技术背景的人参与到互动创意的生产中来。而这个趋势对vivo广告小游戏这种依赖创意、需要快速迭代的领域意义尤其明显。6. 个人经验小结与后续拓展建议6.1 从需求到代码我最常用的一套提示词最后分享一套我自己经常用来做小游戏AI提示词的底座可以直接复制修改使用你是一名资深的小游戏开发工程师专注于H5互动广告的开发。 请根据以下需求完成一个可运行的广告小游戏 玩法概述一句话描述核心玩法 核心机制描述关键交互和逻辑 界面布局描述页面上各元素的排列 视觉风格描述美术风格 技术限定指定技术栈例如原生JSCanvas不引入外部库 代码要求 - 单文件HTML内联CSS和JS方便直接预览 - 代码注释覆盖关键逻辑 - 适配移动端常用分辨率兼容刘海屏 - 性能优先避免高频CSS动画 - 用中文注释这段提示词的威力在于它一次性把项目的类型、技术边界、输出格式和质量要求都说清楚了。我实测下来AI对这类提示词的响应质量非常稳定很少出现代码结构乱七八糟的情况。6.2 快速验证创意的“十分钟工作流”我发现AI辅助开发最实用的一个场景是快速验证创意。假设灵感来了想验证一个脑洞玩法是否可行以前得写一两个小时的代码才能看到效果。现在我的做法是花五分钟写一份足够简略的需求描述直接让AI生成一份原型代码然后在浏览器里打开看效果。如果玩法反馈好就继续细化和迭代如果反馈不好就果断换方案。这个流程把单个创意的验证成本从几小时压缩到了十几分钟对个人或小团队来说试错空间就大得多。在做vivo广告小游戏这个领域创意更新频率极快用户品味也变化很快能快速试错本身就是很大的竞争优势。我用这套流程做过一个“数字接龙”的创意初版AI只用了七分钟就生成完成虽然不需要很复杂但已经可以点击操作了。虽然后来这个创意没有进入正式投放但整个验证过程几乎没有成本。6.3 给新手读者的三条建议如果你刚接触这个领域想尝试用AI来做vivo广告小游戏我建议你从以下三个方向入手第一条建议从仿写一个经典玩法开始。不要去凭空创造玩法先选一个市面上验证过的经典玩法比如打地鼠、翻牌配对、重力滚球用AI复刻它。在这个过程中重点体会你是怎么描述玩法的AI是怎么把描述变成代码的哪些描述方式能让它准确理解哪些不能。第二条建议构建自己的需求描述模板库。每做一个项目就把需求描述文件保存下来总结哪些部分有效哪些部分会导致AI生成偏离预期的代码。久而久之你会形成一套高效的个人模板。第三条建议边做边学代码逻辑但不用从头啃完整套知识。跟着AI生成的代码逐行去理解和修改遇到不懂的知识点再单独查阅。在这个试错过程中积累起来的技术判断力远比死记硬背语法更有价值。在我看来做vivo广告小游戏核心竞争力从来不是能写出别人写不出来的代码而是能做出让用户愿意点、愿意玩、愿意转化的小创意。AI的普及把实现门槛大幅拉低之后真正拼的还是创意能力和对用户心理的把控力。而“说需求”这门手艺就是连接创意与实现之间的那座桥。在实际项目中我把需求描述清楚的能力已经变成了和写代码能力同等重要的核心竞争力甚至在某些场景下更加宝贵。