昨天跟一个做前端的朋友聊到“现在学小程序开发还有没有必要”我随口说了一句“我现在写代码基本靠AI了”他第一反应是觉得我在吹牛。然后我打开电脑用WorkBuddy把一个刷题类小程序的页面框架、题库数据结构和答题判定逻辑在半小时内搭了出来他当场不说话了。这件事挺有意思的。AI时代的小程序开发跟五年前完全是两个玩法。以前你得先学HTML/CSS/JavaScript三件套再啃微信官方文档弄懂组件生命周期、事件绑定、数据绑定光是环境配置就能劝退一批人。现在不一样了你真正需要具备的能力变成了三样把需求说清楚、知道AI擅长什么不擅长什么、看得懂AI给你的代码并且能改对。这篇东西我想完整记录一下“当WorkBuddy遇上刷题”这个项目的全过程。包括WorkBuddy是什么、怎么装、怎么做本地部署、怎么把“刷题小程序”的需求拆给AI、AI生成的代码里有哪些坑、最后怎么用hBuilderX跑到微信开发者工具里。适合两类人看一类是想入门小程序开发但一直没动手的另一类是已经在用AI写代码但总觉得哪里不对劲的。1. 从一台旧电脑开始WorkBuddy到底是个什么工具先说结论WorkBuddy不是那种“你问一句它答一句”的聊天框它更像一个常驻在你电脑里的AI开发工作站。你可以把它理解成一个桌面级的智能体环境——界面是工作区形态中间是对话和任务面板左右两侧是文件树和预览区AI可以直接读你本地的项目文件也可以执行命令、运行脚本、改代码再把结果展示给你看。很多人在网上搜“WorkBuddy教程”看到的是英文界面就有点怵。其实这东西上手门槛没有想象中高核心逻辑就一句话它是一个能干活的工作台不是只会聊天的机器人。跟它最像的产品是CodeBuddy但两者定位有区别。CodeBuddy更多是“嵌入IDE的AI插件”你在VS Code或者JetBrains里装上它写代码的时候有自动补全、有对话窗口帮你改代码。WorkBuddy则是独立的桌面应用它本身就是一个完整的开发环境支持导入本地项目、管理文件、执行终端命令同时内置了模型调度、Skill技能管理这些能力。打个比方CodeBuddy是你写字台上的一个好用的笔架WorkBuddy更像是整个写字台本身。我用WorkBuddy跑这个刷题小程序项目跑下来最强烈的感受是它最适合的场景是“从0到1的完整小项目”。因为它能看着你的整个文件结构干活不像网页版对话那样每次都要你去粘贴文件内容、说明上下文效率高很多尤其适合小程序这种“一个项目里有几十个文件、文件之间互相引用”的工程。WorkBuddy在模型选择上也比较灵活。你既可以用它的云端模型服务也可以配置本地模型比如用Ollama跑DeepSeek、Qwen这类开源模型数据完全留在本地。这也是为什么网上搜“WorkBuddy本地部署”“WorkBuddy下载”的人那么多——很多开发者对数据隐私有要求不想把代码扔到云端。安装这块我直接去官网下的Windows安装包装完大概占用1个多G空间。第一次启动会引导你配置模型有两条路云端模型填API Key就能用适合不想折腾本地模型的用户本地模型通过Ollama加载DeepSeek等模型适合对隐私敏感或者网络环境不稳定的用户我测试的时候用的DeepSeek大概量化版有4.7G。在这台旧电脑上跑生成速度大概是每秒十来个tokens虽然不算快但写一个页面框架绰绰有余。1.1 WorkBuddy的Skill机制为什么说它是“给AI安排任务”的正确姿势WorkBuddy里有一个概念叫Skill这是它相对其他AI编程工具最特别的地方。所谓Skill就是一套预先定义好的“任务规范”——你告诉AI做什么、按什么步骤做、输出什么格式它就会按照这个规范去执行。你可以把它理解成给AI写岗位说明书。这次刷题小程序项目我就用Skill把“AI充当小程序开发工程师”这件事规范化了。Skill里包含了角色AI扮演微信小程序开发工程师任务根据题目清单生成小程序代码约束使用原生小程序框架不使用第三方UI库兼容iOS和Android输出每个页面包含wxml、js、json、wxss四个文件数据单独放一个js文件定了这个Skill之后我只需要把标题和需求发给它它生成的代码就非常规矩不会东一榔头西一棒子。如果你不用Skill直接跟它对话它生成的代码往往结构比较散页面之间风格也不统一。1.2 本地部署的PCD普通用户路线图本地部署这块多说几句。很多人问“WorkBuddy本地部署到底难不难”我实际走下来核心流程就四步安装Ollama这个工具是用来跑本地大模型的在Ollama里拉取一个模型我用的是deepseek-r1:7b在WorkBuddy的设置里把模型源指向本地地址测试连通性跑一个简单任务验证这里有个坑要提醒本地跑大模型非常吃内存。7B量级的模型大概需要8G左右的内存如果你的电脑只有16G内存建议不要再开太多其他程序。我测试的时候开着微信开发者工具加WorkBuddy再加浏览器电脑风扇转得跟飞机起飞似的。如果电脑配置不够我建议直接用云端模型。反正对于小程序开发这种任务你不需要多惊艳的模型能力关键是上下文窗口要够大、能记住你项目结构就行。2. 刷题小程序的需求拆解先别让AI写代码先让AI懂你的题库很多人在AI编程工具上栽跟头原因不是工具不行而是需求没说清楚。你发一句“帮我写个刷题小程序”AI给你生成的东西大概率是花架子——有首页、有列表、有答题页但题目是假数据逻辑是硬编码。看着像那么回事实际上没法用。所以这次我特意先花时间把需求文档整理了一遍尤其是题库数据结构这一块。刷题类小程序说破天核心就三部分题目从哪来、题目怎么展示、答完题怎么判。2.1 用JSON组织题库把散装题目变成结构化数据我手头有100道Python基础题是从过去练习笔记里整理出来的。原始形态是这样的题目Python中用于定义函数的关键字是 A. def B. function C. func D. define 答案A这种文本格式人看着没问题但程序没法直接处理。所以第一步是转成JSON每个题目一个对象包含id、type题型、question题干、options选项、answer答案、analysis解析这些字段。我编了一个转换脚本的Prompt让WorkBuddy帮我写然后就得到了类似这样的结构questions [ { id: 1, type: single, question: Python中用于定义函数的关键字是, options: [def, function, func, define], answer: 0, analysis: Python使用def关键字定义函数。 } ]这里有个细节值得注意answer字段我设计成了选项索引整数而不是选项内容字符串。因为选项文本可能会调整索引则稳定不变。这个设计直接决定了后面答题判定的逻辑复杂度如果一开始就乱来后面AI写得再好也救不回来。2.2 页面结构设计五个页面各自干什么刷题小程序我最终定了5个页面功能边界划分得很清楚页面功能关键交互首页(index)展示题库统计、选择刷题模式跳转列表页题目列表(list)展示所有题号区分已答/未答点击进入答题页答题页(quiz)展示题目、选项、提交答案选项点击选中、提交判定结果页(result)展示答题结果、解析上一题/下一题切换错题本(mistakes)展示错题汇总左滑删除、再练一遍这个结构是从普通刷题类App抄过来的成熟模式不算什么创新但它最大的好处是每个页面职责单一AI生成代码时不容易乱。你要是让AI一口气把五个页面揉成一个页面它非得给你写出一坨“屎山”不可。2.3 把需求写成Skill给AI一份“听得懂”的说明书这步是整个项目的分水岭。很多人用AI写代码就直接把需求贴到对话框里AI写一句算一句写完了你不知道它有没有理解全。用WorkBuddy的Skill机制就不一样了你可以把需求文档放进SkillAI会把整份文档作为自己的“操作手册”。我的Skill文件核心部分长这样任务目标 生成一个微信小程序刷题应用包含5个页面首页、题目列表、答题页、结果页、错题本。 数据要求 - 题库数据放在 /data/questions.js 文件中 - 每个题目包含 id、type、question、options、answer、analysis 字段 - answer为选项索引从0开始 技术约束 - 使用原生微信小程序框架 - 不使用第三方组件库 - wxml中不允许使用函数调用如 array.map循环用 wx:for 实现 输出要求 - 每个页面生成 .wxml .js .json .wxss 四个文件 - 代码中要包含中文注释关键逻辑要写清思路 - 样式使用 rpx 单位适配不同屏幕这里面的“wxml中不允许使用函数调用”那条约束是踩过坑之后总结出来的经验。微信小程序的模板语言能力有限不像Vue那么强大你在wxml里用方法做数据变换小程序的WXSWeiXin Script处理起来很麻烦直接卡死你。提前约束好能让AI少走弯路。3. 实战生成WorkBuddy产出小程序代码的全过程记录需求拆好了、Skill写好了接下来就是真正的干活环节。我按时间线把这个过程完整记录下来包括中间AI生成的代码出了什么问题、我怎么一步步修正的这部分应该能帮你避开不少坑。3.1 第一步让WorkBuddy生成全局配置和数据文件我先让WorkBuddy读Skill然后让它生成小程序的基础工程结构。大概半个小时后它生成了一个标准的微信小程序目录结构miniprogram/ ├── app.js ├── app.json ├── app.wxss ├── data/ │ └── questions.js ├── pages/ │ ├── index/ │ │ ├── index.wxml │ │ ├── index.js │ │ └── index.json │ ├── list/ │ ├── quiz/ │ ├── result/ │ └── mistakes/这个结构基本可以直接用。我特别检查了app.json这是小程序的全局配置里面声明了所有页面路径、窗口样式、tabBar等等。AI默认生成的tabBar只有首页和列表页两个tab我把错题本也加了进去这样用户能直接通过底部导航进入错题本。贴一下我当时在app.json里加的tabBar配置tabBar: { list: [ { pagePath: pages/index/index, text: 刷题 }, { pagePath: pages/list/list, text: 题目 }, { pagePath: pages/mistakes/mistakes, text: 错题 } ] }tabBar的图标我暂时没配——AI生成的图标一个是加载图片路径的实际开发中你要么用设计好的图标要么临时用iconfont的在线图标。但小程序原生tabBar不支持远程图标所以你必须要本地图片。这一步我当时偷懒跳过了后面预览的时候tabBar那一栏显得很干瘪算是偷懒的代价。3.2 第二步答题页的核心逻辑——AI生成的代码有哪些坑答题页是整个小程序最核心的页面也是AI最容易翻车的地方。我先说说预期逻辑进来之后显示第一题点击选项选中点“下一题”跳到下一题到最后一题时点“交卷”跳转结果页。同时用户答错的题要记到错题本里。WorkBuddy第一次生成的答题逻辑用的是这样的写法Page({ data: { questions: [], currentIndex: 0, selectedOption: -1, answers: [] }, onLoad() { const questions require(../../data/questions.js) this.setData({ questions: questions.questions }) }, selectOption(e) { const index e.currentTarget.dataset.index this.setData({ selectedOption: index }) }, nextQuestion() { const { currentIndex, answers, selectedOption, questions } this.data if (selectedOption -1) { wx.showToast({ title: 请先选择答案, icon: none }) return } answers[currentIndex] selectedOption this.setData({ answers, selectedOption: -1, currentIndex: currentIndex 1 }) } })看这段代码逻辑本身是通的但它有个问题没有记录用户所选答案的文本只存了索引。后面结果页显示“你的答案A”的时候你无法直接从索引映射回选项文本。表面上看索引够了实际上结果页需要展示内容时你还得在结果页重新拿着索引去questions[currentIndex].options[answerIndex]里取一次文本。这不算致命错误但确实绕。我还发现一个更隐蔽的问题first render时onLoad里的异步require可能会导致渲染时数据还没到。在小程序里require一个本地js文件是同步的所以这里没问题。但如果AI把数据改成从某个接口拉取那就变成异步了很可能出现首帧白屏的情况。AI在这类异步时序问题的处理上往往不如老手程序员想得周全。3.3 第三步结果页和错题本的关联设计结果页这边我的设计思路是交卷后带着一组“题目序号用户答案”的数组跳进结果页结果页负责把每个题的判定结果、正确答案、解析展示出来。这里有一个前后端数据传递的技巧AI一开始没做对——它以为把整个数组放到URL参数里传就行了但小程序页面跳转URL的参数是字符串塞不下一个数组。后来我让它改成用全局变量或者storage传代码就顺了// 在答题页交卷时 wx.setStorageSync(quizAnswers, this.data.answers) wx.navigateTo({ url: /pages/result/result }) // 在结果页读取 const answers wx.getStorageSync(quizAnswers) || []错题本更简单交卷的时候把答错题的ID和用户答案存进去在错题本页面读取并渲染const wrongQuestions wx.getStorageSync(wrongQuestions) || [] wrongQuestions.push({ questionId: question.id, userAnswer: selectedOption, correctAnswer: question.answer }) wx.setStorageSync(wrongQuestions, wrongQuestions)到这里WorkBuddy帮我搭起来的核心逻辑算是能跑通了。全程耗时大约一个半小时包括改bug和调试在内。这个速度放在以前我自己从零手写少说也要一个周末。4. 从WorkBuddy到微信开发者工具hBuilderX转会流程里的隐秘细节很多人问“WorkBuddy能用hBuilderX开发微信小程序吗”我这次的路线是WorkBuddy负责生成代码hBuilderX负责把代码转成微信小程序工程结构并调试预览。中间绕了一个弯但还是走通了这里说说完整链路上那些文档里没写清楚的事。4.1 hBuilderX在这个链路里到底扮演什么角色先捋一下工具分工WorkBuddyAI辅助生成源码hBuilderX一个集成开发环境核心功能是把uni-app之类的项目编译成各端小程序代码微信开发者工具腾讯官方调试器真正运行和验证小程序的地方刷题小程序项目里有两条路把代码跑到微信开发者工具里源码是标准微信小程序原生项目的直接用微信开发者工具打开源码目录预览出来即可源码是uni-app项目就得用hBuilderX跑uni-app的编译任务把代码编译生成到dist/dev/mp-weixin目录再用微信开发者工具打开这个目录看效果我这次用的是原生小程序方案所以严格来说hBuilderX只是用来导入查看工程和配置的真正编译工作由微信开发者工具自己完成。如果你打算用uni-app做跨端应用那hBuilderX的作用就重要得多——不过那就是另一个项目了。4.2 原生小程序和uni-appAI生成的代码是哪种形态WorkBuddy默认生成的是原生小程序代码因为我在Skill里明确写了“使用原生微信小程序框架”。好处是直接打开就能跑坏处是以后要做H5或者App端就得重写。如果你想要的是多端复用的方案生成代码前就得让AI按uni-app的语法来写页面结构虽然还是vue单文件组件但生命周期要写成onLoad而不是mounted。这些细节AI不一定知道你需要在Skill或prompt里声明清楚。一个经验之谈如果项目只做微信小程序就用原生方案少一层编译就少一层坑。如果未来可能要做支付宝小程序、抖音小程序那就直接上uni-app后期不用返工。4.3 微信开发者工具显示“无法读取app.json”这类问题怎么处理我第一次用微信开发者工具打开WorkBuddy生成的目录时直接就报错了app.json: 文件未找到。查了一下原因是WorkBuddy把项目文件生成在了带版本号的子目录里而微信开发者工具的“导入项目”要求你选中包含app.json的那个目录作为根目录。解决方式很简单把miniprogram/这个文件夹里的所有内容拷到一个干净的目录再在微信开发者工具里选择“导入项目”选中该目录即可。后面又遇到一个更奇葩的报错app.json: app.json 未找到实际上下面其实有project.config.json提示工具在读取app.json前会先找project.config.json定位如果你直接导入的是源码目录本身它可能找不到该文件就用默认值去读取了。解决办法是让WorkBuddy在项目根目录也生成一份project.config.json并写明miniprogramRoot: miniprogram/。这个文件长这样{ description: 刷题小程序, packOptions: { ignore: [] }, setting: { urlCheck: false, es6: true, postcss: true, minified: true }, compileType: miniprogram, libVersion: 3.0.0, appid: touristappid, projectname: quiz-miniprogram, miniprogramRoot: miniprogram/ }注意appid字段我填的是touristappid这是测试号游客模式不需要注册小程序账号就能预览。如果你有正式的小程序AppID填进去就行可以用真机预览和上传代码。4.4 预览时的样式问题rpx和px的一步之遥第一个页面跑起来之后我发现文字和按钮的尺寸都偏大而且在iPhone SE和iPhone 14 Pro上的观感差异很明显。原因很简单AI生成的样式里用了不少px硬编码。微信小程序的屏幕适配应该使用rpxresponsive pixel单位。rpx的换算规则是在任何屏幕上宽度都是750rpx。所以如果设计稿是750宽那么设计稿上的多少px就是多少rpx。如果设计稿是375宽iPhone 6/7/8的基准宽度那么1px 2rpx。AI生成代码时如果没被明确告知是很容易用px的。我在Debug时发现首页按钮的font-size: 28px在iPhone 14 Pro上显得特别大因为那是真机不是模拟器。后来我批量改了样式文件里的字体和间距相关属性全部替换成rpx单位观感立刻正常了。如果你不想手动改可以在WorkBuddy的Skill里预先加上一条“所有尺寸、字体、边距统一使用rpx单位。”这样AI生成时就不会放飞自我了。5. 翻车现场复盘WorkBuddy生成代码时最常见的四类问题说句公道话AI编程工具确实能把开发效率提升一大截但它的输出绝不是“拿来即用”的。这次用WorkBuddy做刷题小程序我至少踩了四类坑每一类都值得单独拎出来说说因为以后你大概率也会遇到。5.1 第一类坑数据绑定里的双向绑定误区这个问题在AI生成的代码里出现频率非常高。AI会把Vue的思想带到小程序里来写出来的代码类似input value{{inputValue}} /结果在小程序里你直接在input里输入内容inputValue并不会跟着变。小程序没有Vue那种自动双向绑定你必须在bindinput事件里手动setData。AI需要被明确告知“小程序是单向数据流”它才不会默认套用Vue的思维。我当时发现AI生成的搜索框功能失灵排查了半天最后定位到就是因为这个。正确写法是input value{{inputValue}} bindinputhandleInput /handleInput(e) { this.setData({ inputValue: e.detail.value }) }5.2 第二类坑setData的key不能带特殊字符这个坑更隐蔽。我在设计错题本页面时想让每个错题都可以单独折叠展开State结构用了类似this.setData({ [item-${index}.isOpen]: true })在小程序里这种带-的key在小程序里会直接炸。setData的路径中只支持字母、数字、点号和方括号不能包含连字符。最后我改成this.setData({ [items[${index}].isOpen]: true })稳妥很多。这个经验的价值在于AI生成的动态key操作说不好就会踩中底层限制你必须有意识地审查这类代码。5.3 第三类坑wxml里不能用复杂的JavaScript表达式很多AI在生成Vue代码时习惯了在模板里写一堆表达式比如view{{questions[currentIndex].options[selectedOption]}}/view这种链式索引在Vue里没问题但在小程序的wxml里它可能直接渲染不出来或者报错。WXML支持的操作符非常有限不支持动态的链式索引。解决办法是所有需要在模板里展示的数据都提前在js的data里处理好。比如在selectOption事件里就把当前题目、选项文本、答案文本这些都setData进去模板只负责展示不负责计算。5.4 第四类坑require路径不对模块引入失败WorkBuddy生成的代码里require路径用的是相对路径比如const questions require(../../data/questions.js)这个路径是否正确取决于文件的实际位置。如果WorkBuddy把questions.js放到了miniprogram/data下而页面在miniprogram/pages/quiz下那么从quiz目录到data目录的路径是../../data/questions.js没错。但问题是AI有时候会在“模拟环境”里把目录结构创建错了位或者多个版本并行开发时把文件复制到别的路径导致require报错。这类问题排查起来很枯燥我当时的做法是让WorkBuddy用find命令把所有js文件的位置列出来比对一下路径再统一修正require引用。这一类的经验总结起来就一句话用AI生成代码验收的时候一定要按“数据流”走一遍。从数据加载、到页面渲染、到用户交互、到结果反馈每个环节都测一遍不能因为页面能打开就说完成了。6. 我再加一个功能把“每日一题”和题目随机抽题做进去核心功能跑通之后我顺手用WorkBuddy加了两个小功能每日一题和随机抽题。加这两个功能不是为了炫技而是想验证一件事AI在一个已有项目上做增量开发效率到底高不高。实测下来结论是增量开发比从零开发更考验你对项目的理解也更考验AI对已有代码风格的一致性把握。6.1 每日一题本地存储模拟“每日”每日一题的逻辑不复杂用户进入首页时读取本地缓存里记录的“今天做题日期”如果跟当前日期不一致说明是今天第一次来从题库里按日期哈希选出一道题展示给用户如果已经做过了就展示缓存里的那道题。我让WorkBuddy在首页加了一个“每日一题”模块onShow() { const today new Date().toDateString() const daily wx.getStorageSync(dailyQuestion) if (!daily || daily.date ! today) { const index this.getDailyIndex() const question this.data.questions[index] this.setData({ dailyQuestion: question }) wx.setStorageSync(dailyQuestion, { date: today, questionId: question.id }) } else { const question this.data.questions.find(q q.id daily.questionId) this.setData({ dailyQuestion: question }) } }这里有个小细节“按日期哈希选题目”我让AI用了一个简单的字符串哈希函数把日期字符串转成哈希值再对题库长度取模。这样同一天内每次打开都是同一道题连续几天下来不会重复题号体验感比简单的随机数强很多。6.2 随机抽题利用Fisher-Yates洗牌算法随机抽题功能我做的是“随机挑战10题”模式每次从题库里随机抽10道题不重复做成一套新的卷子。AI用的洗牌算法是Fisher-Yates也叫Knuth shuffle这是最经典的无偏洗牌算法每个排列出现的概率相等。function shuffle(arr) { const result [...arr] for (let i result.length - 1; i 0; i--) { const j Math.floor(Math.random() * (i 1)) ;[result[i], result[j]] [result[j], result[i]] } return result }这块我没什么好改的AI区分得很清楚随机抽题的题目顺序要打乱但选项本身要保持原顺序不能打乱否则答案索引就乱了。这种细节AI能意识到我还挺意外的。6.3 增量功能带来的结构性问题加了这两个功能之后首页的wxml变得比以前长了不少。WorkBuddy在处理“在已有页面里加新模块”这个任务时倾向于往里追加代码而不是重构。这就带来一个问题页面的wxml和js文件越来越长可读性越来越差。这也是我目前对AI生成代码最大的担忧之一。好的代码不是能跑就行还要整洁、可维护、别人能接手。AI生成的代码跑起来往往没问题但代码组织和命名规范常常一言难尽。比如它会生成一些无用变量、重复的数据处理逻辑、甚至把不该放在data里的数据也放进去。这些如果不手动清理时间久了就是一笔技术债。我的应对策略是每个功能开发完花十分钟让AI做一次代码审查。我会直接跟WorkBuddy说请审查首页的js文件列出以下问题 1. 是否有未使用的变量和函数 2. 是否有重复的setData逻辑可以合并 3. 是否有被注释掉的死代码 4. 数据结构是否可以简化它生成的代码审查报告有时候比它写代码的能力还让我满意。这一点我觉得是很多人没用起来的功能——AI不仅能写代码还能当你的低成本代码审查员。7. 收尾发布前的检查清单和我的个人使用体会最后这部分说说这个刷题小程序项目跑通之后我总结出来的一套“AI生成代码验收清单”以及我对WorkBuddy这类工具的真实评价。没有标题党都是实际操作得来的体验。7.1 小程序发布前的必要检查项跑到微信开发者工具里能预览只是第一步真要发布到线上还有很多细节点要过。我列一个自己反复用的检查清单供你直接抄检查项检查方法常见问题配置检查打开project.config.json检查appid、miniprogramRootappid是测试号无法发布miniprogramRoot路径错误导致读取失败接口检查确认没有使用未配置的合法域名request的URL必须是HTTPS且在小程序后台配置过缓存检查验证storage操作是否有异常storage键名冲突导致不同数据互相覆盖兼容性检查用不同机型、不同微信版本真机预览某些CSS属性低版本微信不支持内容检查检查所有页面是否有敏感或违规内容题库里若涉及版权题需要注意授权性能检查查看首屏渲染时间、包体大小图片未压缩导致包体超过2M上传失败我这次特别注意了包体大小。AI生成的代码里可能包含一些它自己加的示例图片和冗余资源我一看miniprogram目录总大小快3MB了直接删掉了那些没用的图片最后压缩到1.2MB达标。7.2 用WorkBuddy做项目最大的隐性成本不是算力是审查网上很多文章吹AI编程工具“一句话生成整个App”我负责任地告诉你那是流量话术。实际体验下来AI确实能把“从0到1”的时间压缩90%但“从1到能发布”的时间你依然省不下来。为什么因为AI给你的是一个“应该是这样”的实现但它不保证真的是这样。你得验证、你得测试、你得改bug这些活的耗时一点不会少。好在你不用再写那些重复的样板代码了省下来的精力可以投入到真正需要判断力的事情上——比如题目质量、用户体验、功能规划。我个人的体会是AI时代的小程序开发门槛确实低了但天花板反而高了。低门槛体现在你不用再死磕基础语法高天花板体现在你要能把控更多环节——从需求设计到数据格式到用户体验再到最后的发布运营。AI写代码你指挥AI。指挥得好不好取决于你对这个领域理解得深不深。所以这次拿WorkBuddy做刷题小程序我最大的收获反而不是代码本身而是理顺了一整套“人机协作”的开发节奏先用Skill定规矩再让AI照着干活最后自己带着审查清单验收。这套流程跑顺之后做什么项目都快。最后再分享一个小技巧开发完某个页面后截图发给WorkBuddy让它帮你分析界面布局问题。它能直接指出哪里间距不对、哪里按钮层级不清晰甚至能给出样式调整思路。把这个能力用起来等于免费请了个带设计审美的同事帮你review界面挺好用的。