上周我用一条提示词撬动了一个微信小程序的完整开发流程从敲定想法到扫码上线只用了不到两天。这里说的不是套个模板改改文案而是从产品定位、页面结构、代码生成到部署上线的整条链路。拆开来看每一步都不神秘但串起来之后很多没做过小程序的朋友会觉得无从下手。这篇文章我就把 WorkBuddy 这个项目的完整过程摊开来讲包括我怎么用提示词生成代码、怎么配置微信后台、怎么避开那些文档里不会写的坑。如果你正准备做自己的第一个小程序或者已经在用 AI 辅助写代码但卡在生成之后怎么办这一步那这篇文章正好适合你。我会尽量把每个环节的操作逻辑讲清楚不光是怎么点更是为什么这么做。1. 项目整体设计与思路拆解1.1 核心需求解析WorkBuddy 到底要解决什么问题WorkBuddy 这个名字听起来像个职场助手实际上它做的就是一件很具体的事把待办事项从清单升级成带状态流转的执行工具。市面上的待办 App 很多但大部分只解决记下来的问题不解决做完了没有的问题。WorkBuddy 加了两个核心状态进行中和已完成配合时间提醒和分类标签让使用者对任务的推进情况一目了然。这个定位不是我拍脑袋想的。在动手之前我调研了一圈发现很多人的手机里装了不止一个待办应用但真正长期在用的几乎没有。原因很统一功能堆得太满光设置一个任务就要填五六个字段打开应用的动力很快就没了。所以 WorkBuddy 的交互原则就两条创建任务足够快查看状态足够直观。1.2 为什么选择微信小程序这个载体同样的产品思路可以做 App、可以做网页我最终选了微信小程序核心原因有四个。第一微信小程序的获客成本低朋友之间扫码就能体验不需要跳转应用商店第二小程序的开发门槛相对 Web 应用要高一些但比原生 App 低很多尤其适合个人开发者快速验证想法第三微信生态自带的订阅消息能力可以免费实现任务提醒不需要自己搭建推送服务第四微信小程序的审核和上线流程是标准化的走一遍之后第二次再上线就非常有底。选型的时候还要考虑团队的技术储备。我之前对 JavaScript 和前端框架有些基础小程序使用的语法和 Vue 很接近学习成本完全可控。如果你是完全零基础也不是不能做但建议先把 JavaScript 的基础语法过一遍至少能看得懂函数和对象是怎么写的。1.3 用提示词作为开发的起点思路与人机协作方式这次开发的特殊之处在于代码的主力不是我写的而是通过提示词生成的。我把自己当产品经理把 AI 当程序员这中间最关键的事情就是把需求描述清楚。一条好的提示词不是把功能名称丢给工具而是要把功能的行为、界面布局、交互逻辑都交代完整。我写的第一版提示词大约 300 字描述了工作台的页面结构、任务的三种状态、状态切换的交互方式。生成的代码框架整体可用但细节上有不少问题比如按钮的位置不合理、编辑任务之后列表没有刷新。后面我针对这些问题不断追加提示词做迭代每次只提一个明确的修改点生成的代码质量会稳定很多。这里分享一个心得提示词开发不是一次成型而是描述—生成—验证—补充描述的循环。把 AI 当成一个记忆力很好但需要明确指令的初级工程师你的沟通质量直接决定代码质量。2. 搭建开发环境与配置微信后台2.1 注册小程序账号选对主体类型能省很多事开发小程序的第一步不是装工具而是去微信公众平台注册一个小程序账号。这里有一个很容易被忽略的选择主体类型。个人主体和企业主体的权限差异很大个人主体无法开通微信支付部分 API 接口不可用但审核流程相对简单企业主体功能全面但需要营业执照和对公账户验证。WorkBuddy 这个项目用到的都是基础能力不需要微信支付所以注册个人主体就够了。注册时选小程序而不是公众号因为两者的后台管理界面不一样注册错了还要走迁移流程平白给自己添麻烦。注册完成后在开发管理页面能找到 AppID这个字符串相当于小程序的身份证后面配置工具的时候必须用到。2.2 安装开发者工具微信开发者工具的初始化配置微信官方提供的开发者工具是绕不开的环节虽然它经常被吐槽占用内存大但调试小程序确实离不开它。我用的稳定版下载之后用注册好的小程序账号扫码登录首次打开会让选择项目类型这里选小程序然后填入 AppID。初始化的时候有个小细节框架选择。微信开发者工具现在支持原生 JavaScript 和 TypeScript还支持引入第三方框架。对新手来说我建议先不要引入任何额外框架直接用原生语法。WorkBuddy 开发时我用的是原生 JavaScript原因很简单生成的代码结构最稳定查问题时资料最多而且未来维护起来也不需要额外学习框架概念。初始化之后工具会自动生成一个示例项目包含 app.js、app.json、pages 目录等基础文件结构。我习惯先把示例代码全部删掉从一个干净的框架开始这样能避免示例代码和业务代码混在一起排查问题时思路更清晰。2.3 认识小程序的项目结构和核心配置文件微信小程序的目录结构比普通网页项目多了一些规则。根目录下必须有 app.json 全局配置文件它声明了小程序所有的页面路径、窗口样式和 tabBar 配置。每个页面由四个文件组成.js逻辑层、.wxml结构层、.wxss样式层和.json页面配置。理解这个小程序项目结构很重要。它明显的特征是配置驱动并行你想新增一个页面除了写页面代码还要在 app.json 的 pages 数组里注册路径。板块缺失就会白屏报错导致系统无法正常编译。WorkBuddy 一共有三个页面工作台、任务管理和数据统计我在 app.json 里按顺序注册好之后底部的 tabBar 才能正常切换。说到 tabBar这是小程序里很常用的导航组件。配置 tabBar 的时候有一个很容易踩的坑图标文件需要是 PNG 格式且大小有限制不能直接用 JPG 或者 SVG。我第一次配置的时候随手放了两个图片文件编译时直接报tabBar 图标必须是 PNG换掉之后就正常了。3. 提示词驱动核心功能实现3.1 撰写提示词的三个层次页面、功能、数据流如果把整个小程序的开发需求拆解到提示词里面我发现比较有效的做法是分三个维度来写。页面维度描述每一页长什么样功能维度描述用户能做什么操作数据流维度描述数据在页面之间怎么传递。第一次写提示词的时候我只写了页面和功能忽略了数据流。结果生成出来的页面虽然各自能用但任务列表页新增的任务在工作台的状态统计里不会同步更新。后来我意识到问题的根源是数据缺少统一的管理方式于是补了一段提示词要求把任务数据统一存放在全局globalData中所有页面通过调用同一个方法读取和写入数据。这个调整之后跨页面的数据同步问题就迎刃而解了。3.2 生成核心代码任务创建、状态流转与列表渲染任务创建是 WorkBuddy 使用频率最高的操作。我给的提示词描述是页面上方有一个输入框用户输入任务内容后点击添加按钮任务以卡片形式展示在下方的列表中列表按照创建时间倒序排列。生成的代码里核心部分是一个addTask方法从输入框取到内容之后把任务对象 push 到全局数组里然后调用setData刷新视图。这里的setData是小程序的一个特点我们用this.setData()方法修改数据既能完成逻辑层数据更新又自动触发视图层渲染。但要注意一个性能问题频繁调用 setData 会导致页面渲染卡顿尤其在任务数量较多的时候。我的做法是把所有需要更新的数据先组装成一个对象再一次调用 setData 传入而不是在循环里多次调用。状态流转是 WorkBuddy 的核心交互。每个任务卡片上有两个按钮标记为进行中和标记为已完成。按钮绑定的事件方法会接收任务的 id然后遍历任务列表找到对应项修改它的 status 字段。这里提示词生成的事件方法有一个 bug就是遍历时直接修改了数组但没有用新数组整体赋值结果界面上状态变了数据层其实没变。修复的方法很简单用map方法生成一个新数组再赋值。列表渲染用到了wx:for指令类似于网页开发里的循环渲染。因为在小程序中直接修改数组某项的某个属性时视图层无法自动感知所以需要特别注意。这里有一个经验列表项数据建议加一个独立的_id字段不要用数组的索引做唯一标识。因为后续删除或排序时索引会变化容易引发渲染错乱。3.3 数据持久化本地缓存的设计与实现任务数据如果只存在内存里一旦退出小程序就全没了这是不可接受的。小程序的持久化方案相对 Web 要简单一些主要就是wx.setStorageSync和wx.getStorageSync这两个接口把数据保存到本地。我实现的方案是每次任务数据变化时调用saveTasks方法把整个任务数组序列化后写入本地缓存每次进入小程序时在onLaunch生命周期里读取缓存并恢复到全局数据。这样的设计适合任务数量不大、数据关系简单的场景WorkBuddy 这种工具完全够用。这里有一个注意点本地缓存有大小限制单个 key 的数据量不能太大。如果任务文本非常长或者列表数据量大建议改造为分页存储不要一股脑把整个数组塞进缓存。3.4 界面样式与体验优化从能用变为好用代码能跑和好用是两回事。WorkBuddy 第一版的长相比粗糙文字挤在一起按钮没有反馈列表滚动也没有平滑效果。我在提示词里追加了样式优化要求重点描述了卡片圆角、阴影、状态标签的颜色区分等视觉细节。小程序样式用的是 WXSS语法上大部分跟 CSS 一致但有一些独有的单位比如rpx。我一开始沿用网页开发的习惯用px写样式结果在不同屏幕上显示不一样后来统一改成rpx后适配就稳定多了。简单推算方法是小程序规定屏幕宽度默认为 750rpx一套值适配所有屏幕——记住这个规则样式写起来会顺手很多。另外一个体验细节是空状态的提示。当任务列表没有任何数据时直接展示空页面会让人疑惑我就加了一个居中提示暂无任务点击上方输入框开始创建再加一个小图标辅助说明。这个小改动对第一印象的提升很明显。4. 调试运行与真机预览4.1 本地调试模拟器与调试器的配合使用微信开发者工具内置的模拟器可以实时预览页面效果但模拟器不等于真机很多问题在模拟器里看不出来比如真机上会有字体渲染差异、页面滚动穿透等。我在本地调试时习惯分两步先用模拟器快速调整界面布局和交互然后立刻用真机预览验证手感。开发者工具的调试面板和浏览器很相似也有 Console 和 Network但有个小程序的特殊玩法AppData 面板可以图形化查看当前页面所有的数据字段改动数据后页面会实时响应。调试数据绑定问题的时候比看代码直观得多如果页面渲染的结果和预期不一致优先切到 AppData 面板查看是数据没更新还是视图没刷新。4.2 真机预览的两种方式预览二维码与上传体验版本地调试阶段要在手机上跑起来可以用开发者工具顶部的预览按钮生成一个临时的体验二维码用微信扫码即可在真机上打开。但预览模式有一个限制它依赖开发者工具与本机的连接关掉工具之后二维码就失效了不能拿去给别人做长期体验。如果要给朋友或者同事体验正确的方式是上传代码。上传之后代码会出现在微信公众平台的版本管理里可以把它设为体验版这样任何人扫同一个二维码都能打开而且只要不删版本就一直有效。两种方式的区别让我在协作环节的体验顺畅了许多光是临时预览和体验版的分工就避免了很多这个码怎么扫不了的误会。4.3 常见编译错误与调试技巧开发过程中免不了编译报错这类问题初学者遇到就很容易慌这里我把这段时间遇到的高频报错做个速查整理报错场景常见原因排查方向解决办法页面空白且 Console 报Page is not defined使用了某个框架语法当前环境不支持检查 js 文件中是否用了未定义的方法回到原生写法提示wx.setStorageSync:fail存储的数据格式非法或超出限制检查是否把 undefined 或者函数等不可序列化内容存入缓存图标不显示tabBar 图标格式非 PNG换成 PNG 格式的 81x81 像素图标真机样式错乱使用了不支持的 CSS 属性或单位优先使用 rpx 和基础样式属性避免使用 flex 的复杂嵌套调试技巧上有一个我特别喜欢的操作在 Console 里直接执行小程序全局函数。比如我想测试某个方法对数据的处理逻辑直接在 Console 里调用getApp().globalData查看当前真实数据状态再手动执行方法观察结果。这样可以绕过页面的交互流程快速锁定数据层面的问题。5. 审核发布与扫码上线5.1 上传版本与填写审核信息代码调试完成之后先在开发者工具里点击上传填入版本号和项目备注。版本号建议遵守语义化版本规则初版填 1.0.0后续每次改动按递增规则来。备注可以写清楚本次版本更新了哪些内容这一方面方便自己在多个版本里回溯另一方面也有利于审核人员理解小程序的功能。上传成功之后进入微信公众平台后台在版本管理里找到刚上传的开发版本点击提交审核。这时候需要填写一些基本信息和功能页面截图审核人员会根据这些材料加上实际体验来判断小程序是否符合规范。材料不用写得特别花哨但一定要如实页面截图最好用真机截图而不是模拟器截图减少所见非所得的误差。5.2 审核周期与加急审核的使用条件微信小程序的审核周期通常在 1 到 7 天官方会给一个区间预期。工作日提交的审核概率上会比周末快我第一次提交是周四下午第二天中午就通过了。如果你赶时间而且小程序涉及的是常规类目可以申请加急审核个人主体也有机会获得这个资格。不过加急不是无限使用的非必要不推荐把审核时间预留出来更稳妥。审核结果分为通过、驳回和需整改。我第一次提交因为页面上出现了测试两个字被驳回了。审核留言里提示要清除测试数据和演示内容改完重新提交之后通过。这里注意只要不是涉及内容违规驳回往往只指某个细节改完重新提交即可心态不要崩。5.3 发布上线的完整链路从扫码到真实可用审核通过后后台的版本状态会变为审核通过需要手动点击发布按钮。发布之后用户搜索小程序名称或者扫码就能打开正式版。这里要特别说明很多人以为审核通过就等于上线了其实还有一个手动发布环节漏掉这一截的话用户扫码看到的仍然是旧版本。发布完成后用微信扫码打开小程序别人看到的就是完整可用的正式版。我将 WorkBuddy 的二维码发给几位朋友体验顺手收集反馈的过程让我对产品功能有了更直接的判断有人希望任务可以按优先级排序有人想要删除确认弹窗。这些反馈都记录在下个迭代版本里开发小程序的价值开始显现出来了。5.4 上线之后的运维与版本迭代小程序发布上线后最重要的事情就是及时关注线上运行状态。微信公众平台的后台提供了访问量和访问趋势的统计可以看在某个页面停留的时间和分析页面访问深度的数据信息。针对个人开发者不用追求复杂的监控体系定期看一眼后台的基础数据遇到用户反馈问题及时处理修复即可。迭代方面每次修改代码之后都要重新走一遍上传—提交审核—发布的流程但第二次之后会熟悉很多。这里分享一个小技巧每轮迭代前先在本地把功能测试完整再上传提审尽量避免为了修一个小问题反复提交审核因为提交审核本身有时间和人力成本。6. 从 WorkBuddy 提炼的实用经验常见问题与避坑清单6.1 开发阶段最容易踩的五个坑第一全局数据与页面数据不同步。我处理这个问题的方法前面提到过统一用全局方法操作数据不让页面直接修改全局数组。这种做法在项目刚起步时貌似多此一举但页面一多带来的维护便利很值。第二过多的 setData 调用影响渲染性能。如果界面上出现明显卡顿优先检查是不是有循环或者高频事件在持续调用 setData。合并数据一起更新往往可以显著改善。第三页面生命周期理解不到位。初始化数据放在onLoad里常被称为常规操作但每次进入页面时onShow才是最适合刷新数据的地方。特别是有跨页面数据变更的场景onLoad只在页面首次创建时执行一次依赖它会导致数据不同步。第四样式和自动布局的问题。小程序里不同的手机上屏幕宽度不同rpx 适配会好很多但也要注意部分老旧机型对某些新 CSS 属性支持不足。保持样式简单直接是最可靠的写法。第五滥用第三方组件库。遇到 UI 需求第一反应是找第三方组件库这很自然。但组件库会引入额外的依赖和样式覆盖的复杂度WorkBuddy 的界面全部用原生组件实现效果完全可以接受还省去了依赖维护的麻烦。6.2 审核与发布阶段的避坑经验标题、简介和页面内容的一致性很重要。小程序名称一旦确定就很难修改而且发布后名称和内容不符的情况容易被驳回。我建议在编写代码之前就想好名称和简介这个小程序的核心功能关键词要在简介里明确体现便于审核人员快速理解。小程序审核对个人主体的限制要提前弄清楚。比如个人主体不能涉及社交、支付、直播等类目你能做什么取决于你选择的类目范围。如果不想卡在审核环节在产品设计阶段就避开敏感能力做轻量工具类应用是最稳妥的路径。6.3 利用提示词开发小程序的使用心得基于提示词的开发模式并不要求你必须完全看懂每行代码但有几个关键节点需要理解清楚数据是怎么存储的、事件是怎么绑定的、页面之间是怎么跳转的。把这几个核心机制搞清楚之后AI 生成的代码就变成可维护的资产而不是一段黑盒。我的做法是让 AI 生成代码时附带简短注释并定期通读一遍核心逻辑。不需要全会写但至少能说出每个文件大致在做什么。这个习惯在排查问题和二次迭代时节约了大量时间。另外提示词本身也是一个可以积累的资产。我每次写提示词都会留一个副本迭代到下一版时在旧的提示词基础上追加需求描述这样既保持上下文连贯又能让生成的代码风格保持一致。毕竟每个 AI 工具的项目理解能力都受上下文影响越是连贯的对话生成结果越稳定。7. 复盘与扩展可能性WorkBuddy 从一条提示词到扫码上线整个过程走完之后我的一个判断是小程序开发的入门门槛确实已经变得很低但真正决定产品质量的仍然是需求理解和细节打磨。AI 能帮你生成很多代码却不能替你想清楚产品到底解决谁的什么问题。下一步我计划给 WorkBuddy 增加两个能力一个是基于订阅消息的任务提醒另一个是简单的数据统计图表。前者涉及订阅消息的模板配置需要在后台申请后者可以用小程序自带的绘图能力实现。这两个功能做完之后WorkBuddy 从一个单纯的待办工具会慢慢变成一个轻量级的个人任务管理中心。如果你也想用提示词驱动的方式做一个小程序我的建议是先别管技术和流程拿出一张纸写下你想解决什么问题用户打开小程序第一个动作是什么第二个动作又是什么。把这些问题想清楚之后提示词自然写得出来代码生成只是水到渠成的事。 
长河君 · 2026/10/20 23:38:17 · 阅读 1.2k 提示词驱动微信小程序开发：从需求到上线全流程实战
上周我用一条提示词撬动了一个微信小程序的完整开发流程从敲定想法到扫码上线只用了不到两天。这里说的不是套个模板改改文案而是从产品定位、页面结构、代码生成到部署上线的整条链路。拆开来看每一步都不神秘但串起来之后很多没做过小程序的朋友会觉得无从下手。这篇文章我就把 WorkBuddy 这个项目的完整过程摊开来讲包括我怎么用提示词生成代码、怎么配置微信后台、怎么避开那些文档里不会写的坑。如果你正准备做自己的第一个小程序或者已经在用 AI 辅助写代码但卡在生成之后怎么办这一步那这篇文章正好适合你。我会尽量把每个环节的操作逻辑讲清楚不光是怎么点更是为什么这么做。1. 项目整体设计与思路拆解1.1 核心需求解析WorkBuddy 到底要解决什么问题WorkBuddy 这个名字听起来像个职场助手实际上它做的就是一件很具体的事把待办事项从清单升级成带状态流转的执行工具。市面上的待办 App 很多但大部分只解决记下来的问题不解决做完了没有的问题。WorkBuddy 加了两个核心状态进行中和已完成配合时间提醒和分类标签让使用者对任务的推进情况一目了然。这个定位不是我拍脑袋想的。在动手之前我调研了一圈发现很多人的手机里装了不止一个待办应用但真正长期在用的几乎没有。原因很统一功能堆得太满光设置一个任务就要填五六个字段打开应用的动力很快就没了。所以 WorkBuddy 的交互原则就两条创建任务足够快查看状态足够直观。1.2 为什么选择微信小程序这个载体同样的产品思路可以做 App、可以做网页我最终选了微信小程序核心原因有四个。第一微信小程序的获客成本低朋友之间扫码就能体验不需要跳转应用商店第二小程序的开发门槛相对 Web 应用要高一些但比原生 App 低很多尤其适合个人开发者快速验证想法第三微信生态自带的订阅消息能力可以免费实现任务提醒不需要自己搭建推送服务第四微信小程序的审核和上线流程是标准化的走一遍之后第二次再上线就非常有底。选型的时候还要考虑团队的技术储备。我之前对 JavaScript 和前端框架有些基础小程序使用的语法和 Vue 很接近学习成本完全可控。如果你是完全零基础也不是不能做但建议先把 JavaScript 的基础语法过一遍至少能看得懂函数和对象是怎么写的。1.3 用提示词作为开发的起点思路与人机协作方式这次开发的特殊之处在于代码的主力不是我写的而是通过提示词生成的。我把自己当产品经理把 AI 当程序员这中间最关键的事情就是把需求描述清楚。一条好的提示词不是把功能名称丢给工具而是要把功能的行为、界面布局、交互逻辑都交代完整。我写的第一版提示词大约 300 字描述了工作台的页面结构、任务的三种状态、状态切换的交互方式。生成的代码框架整体可用但细节上有不少问题比如按钮的位置不合理、编辑任务之后列表没有刷新。后面我针对这些问题不断追加提示词做迭代每次只提一个明确的修改点生成的代码质量会稳定很多。这里分享一个心得提示词开发不是一次成型而是描述—生成—验证—补充描述的循环。把 AI 当成一个记忆力很好但需要明确指令的初级工程师你的沟通质量直接决定代码质量。2. 搭建开发环境与配置微信后台2.1 注册小程序账号选对主体类型能省很多事开发小程序的第一步不是装工具而是去微信公众平台注册一个小程序账号。这里有一个很容易被忽略的选择主体类型。个人主体和企业主体的权限差异很大个人主体无法开通微信支付部分 API 接口不可用但审核流程相对简单企业主体功能全面但需要营业执照和对公账户验证。WorkBuddy 这个项目用到的都是基础能力不需要微信支付所以注册个人主体就够了。注册时选小程序而不是公众号因为两者的后台管理界面不一样注册错了还要走迁移流程平白给自己添麻烦。注册完成后在开发管理页面能找到 AppID这个字符串相当于小程序的身份证后面配置工具的时候必须用到。2.2 安装开发者工具微信开发者工具的初始化配置微信官方提供的开发者工具是绕不开的环节虽然它经常被吐槽占用内存大但调试小程序确实离不开它。我用的稳定版下载之后用注册好的小程序账号扫码登录首次打开会让选择项目类型这里选小程序然后填入 AppID。初始化的时候有个小细节框架选择。微信开发者工具现在支持原生 JavaScript 和 TypeScript还支持引入第三方框架。对新手来说我建议先不要引入任何额外框架直接用原生语法。WorkBuddy 开发时我用的是原生 JavaScript原因很简单生成的代码结构最稳定查问题时资料最多而且未来维护起来也不需要额外学习框架概念。初始化之后工具会自动生成一个示例项目包含 app.js、app.json、pages 目录等基础文件结构。我习惯先把示例代码全部删掉从一个干净的框架开始这样能避免示例代码和业务代码混在一起排查问题时思路更清晰。2.3 认识小程序的项目结构和核心配置文件微信小程序的目录结构比普通网页项目多了一些规则。根目录下必须有 app.json 全局配置文件它声明了小程序所有的页面路径、窗口样式和 tabBar 配置。每个页面由四个文件组成.js逻辑层、.wxml结构层、.wxss样式层和.json页面配置。理解这个小程序项目结构很重要。它明显的特征是配置驱动并行你想新增一个页面除了写页面代码还要在 app.json 的 pages 数组里注册路径。板块缺失就会白屏报错导致系统无法正常编译。WorkBuddy 一共有三个页面工作台、任务管理和数据统计我在 app.json 里按顺序注册好之后底部的 tabBar 才能正常切换。说到 tabBar这是小程序里很常用的导航组件。配置 tabBar 的时候有一个很容易踩的坑图标文件需要是 PNG 格式且大小有限制不能直接用 JPG 或者 SVG。我第一次配置的时候随手放了两个图片文件编译时直接报tabBar 图标必须是 PNG换掉之后就正常了。3. 提示词驱动核心功能实现3.1 撰写提示词的三个层次页面、功能、数据流如果把整个小程序的开发需求拆解到提示词里面我发现比较有效的做法是分三个维度来写。页面维度描述每一页长什么样功能维度描述用户能做什么操作数据流维度描述数据在页面之间怎么传递。第一次写提示词的时候我只写了页面和功能忽略了数据流。结果生成出来的页面虽然各自能用但任务列表页新增的任务在工作台的状态统计里不会同步更新。后来我意识到问题的根源是数据缺少统一的管理方式于是补了一段提示词要求把任务数据统一存放在全局globalData中所有页面通过调用同一个方法读取和写入数据。这个调整之后跨页面的数据同步问题就迎刃而解了。3.2 生成核心代码任务创建、状态流转与列表渲染任务创建是 WorkBuddy 使用频率最高的操作。我给的提示词描述是页面上方有一个输入框用户输入任务内容后点击添加按钮任务以卡片形式展示在下方的列表中列表按照创建时间倒序排列。生成的代码里核心部分是一个addTask方法从输入框取到内容之后把任务对象 push 到全局数组里然后调用setData刷新视图。这里的setData是小程序的一个特点我们用this.setData()方法修改数据既能完成逻辑层数据更新又自动触发视图层渲染。但要注意一个性能问题频繁调用 setData 会导致页面渲染卡顿尤其在任务数量较多的时候。我的做法是把所有需要更新的数据先组装成一个对象再一次调用 setData 传入而不是在循环里多次调用。状态流转是 WorkBuddy 的核心交互。每个任务卡片上有两个按钮标记为进行中和标记为已完成。按钮绑定的事件方法会接收任务的 id然后遍历任务列表找到对应项修改它的 status 字段。这里提示词生成的事件方法有一个 bug就是遍历时直接修改了数组但没有用新数组整体赋值结果界面上状态变了数据层其实没变。修复的方法很简单用map方法生成一个新数组再赋值。列表渲染用到了wx:for指令类似于网页开发里的循环渲染。因为在小程序中直接修改数组某项的某个属性时视图层无法自动感知所以需要特别注意。这里有一个经验列表项数据建议加一个独立的_id字段不要用数组的索引做唯一标识。因为后续删除或排序时索引会变化容易引发渲染错乱。3.3 数据持久化本地缓存的设计与实现任务数据如果只存在内存里一旦退出小程序就全没了这是不可接受的。小程序的持久化方案相对 Web 要简单一些主要就是wx.setStorageSync和wx.getStorageSync这两个接口把数据保存到本地。我实现的方案是每次任务数据变化时调用saveTasks方法把整个任务数组序列化后写入本地缓存每次进入小程序时在onLaunch生命周期里读取缓存并恢复到全局数据。这样的设计适合任务数量不大、数据关系简单的场景WorkBuddy 这种工具完全够用。这里有一个注意点本地缓存有大小限制单个 key 的数据量不能太大。如果任务文本非常长或者列表数据量大建议改造为分页存储不要一股脑把整个数组塞进缓存。3.4 界面样式与体验优化从能用变为好用代码能跑和好用是两回事。WorkBuddy 第一版的长相比粗糙文字挤在一起按钮没有反馈列表滚动也没有平滑效果。我在提示词里追加了样式优化要求重点描述了卡片圆角、阴影、状态标签的颜色区分等视觉细节。小程序样式用的是 WXSS语法上大部分跟 CSS 一致但有一些独有的单位比如rpx。我一开始沿用网页开发的习惯用px写样式结果在不同屏幕上显示不一样后来统一改成rpx后适配就稳定多了。简单推算方法是小程序规定屏幕宽度默认为 750rpx一套值适配所有屏幕——记住这个规则样式写起来会顺手很多。另外一个体验细节是空状态的提示。当任务列表没有任何数据时直接展示空页面会让人疑惑我就加了一个居中提示暂无任务点击上方输入框开始创建再加一个小图标辅助说明。这个小改动对第一印象的提升很明显。4. 调试运行与真机预览4.1 本地调试模拟器与调试器的配合使用微信开发者工具内置的模拟器可以实时预览页面效果但模拟器不等于真机很多问题在模拟器里看不出来比如真机上会有字体渲染差异、页面滚动穿透等。我在本地调试时习惯分两步先用模拟器快速调整界面布局和交互然后立刻用真机预览验证手感。开发者工具的调试面板和浏览器很相似也有 Console 和 Network但有个小程序的特殊玩法AppData 面板可以图形化查看当前页面所有的数据字段改动数据后页面会实时响应。调试数据绑定问题的时候比看代码直观得多如果页面渲染的结果和预期不一致优先切到 AppData 面板查看是数据没更新还是视图没刷新。4.2 真机预览的两种方式预览二维码与上传体验版本地调试阶段要在手机上跑起来可以用开发者工具顶部的预览按钮生成一个临时的体验二维码用微信扫码即可在真机上打开。但预览模式有一个限制它依赖开发者工具与本机的连接关掉工具之后二维码就失效了不能拿去给别人做长期体验。如果要给朋友或者同事体验正确的方式是上传代码。上传之后代码会出现在微信公众平台的版本管理里可以把它设为体验版这样任何人扫同一个二维码都能打开而且只要不删版本就一直有效。两种方式的区别让我在协作环节的体验顺畅了许多光是临时预览和体验版的分工就避免了很多这个码怎么扫不了的误会。4.3 常见编译错误与调试技巧开发过程中免不了编译报错这类问题初学者遇到就很容易慌这里我把这段时间遇到的高频报错做个速查整理报错场景常见原因排查方向解决办法页面空白且 Console 报Page is not defined使用了某个框架语法当前环境不支持检查 js 文件中是否用了未定义的方法回到原生写法提示wx.setStorageSync:fail存储的数据格式非法或超出限制检查是否把 undefined 或者函数等不可序列化内容存入缓存图标不显示tabBar 图标格式非 PNG换成 PNG 格式的 81x81 像素图标真机样式错乱使用了不支持的 CSS 属性或单位优先使用 rpx 和基础样式属性避免使用 flex 的复杂嵌套调试技巧上有一个我特别喜欢的操作在 Console 里直接执行小程序全局函数。比如我想测试某个方法对数据的处理逻辑直接在 Console 里调用getApp().globalData查看当前真实数据状态再手动执行方法观察结果。这样可以绕过页面的交互流程快速锁定数据层面的问题。5. 审核发布与扫码上线5.1 上传版本与填写审核信息代码调试完成之后先在开发者工具里点击上传填入版本号和项目备注。版本号建议遵守语义化版本规则初版填 1.0.0后续每次改动按递增规则来。备注可以写清楚本次版本更新了哪些内容这一方面方便自己在多个版本里回溯另一方面也有利于审核人员理解小程序的功能。上传成功之后进入微信公众平台后台在版本管理里找到刚上传的开发版本点击提交审核。这时候需要填写一些基本信息和功能页面截图审核人员会根据这些材料加上实际体验来判断小程序是否符合规范。材料不用写得特别花哨但一定要如实页面截图最好用真机截图而不是模拟器截图减少所见非所得的误差。5.2 审核周期与加急审核的使用条件微信小程序的审核周期通常在 1 到 7 天官方会给一个区间预期。工作日提交的审核概率上会比周末快我第一次提交是周四下午第二天中午就通过了。如果你赶时间而且小程序涉及的是常规类目可以申请加急审核个人主体也有机会获得这个资格。不过加急不是无限使用的非必要不推荐把审核时间预留出来更稳妥。审核结果分为通过、驳回和需整改。我第一次提交因为页面上出现了测试两个字被驳回了。审核留言里提示要清除测试数据和演示内容改完重新提交之后通过。这里注意只要不是涉及内容违规驳回往往只指某个细节改完重新提交即可心态不要崩。5.3 发布上线的完整链路从扫码到真实可用审核通过后后台的版本状态会变为审核通过需要手动点击发布按钮。发布之后用户搜索小程序名称或者扫码就能打开正式版。这里要特别说明很多人以为审核通过就等于上线了其实还有一个手动发布环节漏掉这一截的话用户扫码看到的仍然是旧版本。发布完成后用微信扫码打开小程序别人看到的就是完整可用的正式版。我将 WorkBuddy 的二维码发给几位朋友体验顺手收集反馈的过程让我对产品功能有了更直接的判断有人希望任务可以按优先级排序有人想要删除确认弹窗。这些反馈都记录在下个迭代版本里开发小程序的价值开始显现出来了。5.4 上线之后的运维与版本迭代小程序发布上线后最重要的事情就是及时关注线上运行状态。微信公众平台的后台提供了访问量和访问趋势的统计可以看在某个页面停留的时间和分析页面访问深度的数据信息。针对个人开发者不用追求复杂的监控体系定期看一眼后台的基础数据遇到用户反馈问题及时处理修复即可。迭代方面每次修改代码之后都要重新走一遍上传—提交审核—发布的流程但第二次之后会熟悉很多。这里分享一个小技巧每轮迭代前先在本地把功能测试完整再上传提审尽量避免为了修一个小问题反复提交审核因为提交审核本身有时间和人力成本。6. 从 WorkBuddy 提炼的实用经验常见问题与避坑清单6.1 开发阶段最容易踩的五个坑第一全局数据与页面数据不同步。我处理这个问题的方法前面提到过统一用全局方法操作数据不让页面直接修改全局数组。这种做法在项目刚起步时貌似多此一举但页面一多带来的维护便利很值。第二过多的 setData 调用影响渲染性能。如果界面上出现明显卡顿优先检查是不是有循环或者高频事件在持续调用 setData。合并数据一起更新往往可以显著改善。第三页面生命周期理解不到位。初始化数据放在onLoad里常被称为常规操作但每次进入页面时onShow才是最适合刷新数据的地方。特别是有跨页面数据变更的场景onLoad只在页面首次创建时执行一次依赖它会导致数据不同步。第四样式和自动布局的问题。小程序里不同的手机上屏幕宽度不同rpx 适配会好很多但也要注意部分老旧机型对某些新 CSS 属性支持不足。保持样式简单直接是最可靠的写法。第五滥用第三方组件库。遇到 UI 需求第一反应是找第三方组件库这很自然。但组件库会引入额外的依赖和样式覆盖的复杂度WorkBuddy 的界面全部用原生组件实现效果完全可以接受还省去了依赖维护的麻烦。6.2 审核与发布阶段的避坑经验标题、简介和页面内容的一致性很重要。小程序名称一旦确定就很难修改而且发布后名称和内容不符的情况容易被驳回。我建议在编写代码之前就想好名称和简介这个小程序的核心功能关键词要在简介里明确体现便于审核人员快速理解。小程序审核对个人主体的限制要提前弄清楚。比如个人主体不能涉及社交、支付、直播等类目你能做什么取决于你选择的类目范围。如果不想卡在审核环节在产品设计阶段就避开敏感能力做轻量工具类应用是最稳妥的路径。6.3 利用提示词开发小程序的使用心得基于提示词的开发模式并不要求你必须完全看懂每行代码但有几个关键节点需要理解清楚数据是怎么存储的、事件是怎么绑定的、页面之间是怎么跳转的。把这几个核心机制搞清楚之后AI 生成的代码就变成可维护的资产而不是一段黑盒。我的做法是让 AI 生成代码时附带简短注释并定期通读一遍核心逻辑。不需要全会写但至少能说出每个文件大致在做什么。这个习惯在排查问题和二次迭代时节约了大量时间。另外提示词本身也是一个可以积累的资产。我每次写提示词都会留一个副本迭代到下一版时在旧的提示词基础上追加需求描述这样既保持上下文连贯又能让生成的代码风格保持一致。毕竟每个 AI 工具的项目理解能力都受上下文影响越是连贯的对话生成结果越稳定。7. 复盘与扩展可能性WorkBuddy 从一条提示词到扫码上线整个过程走完之后我的一个判断是小程序开发的入门门槛确实已经变得很低但真正决定产品质量的仍然是需求理解和细节打磨。AI 能帮你生成很多代码却不能替你想清楚产品到底解决谁的什么问题。下一步我计划给 WorkBuddy 增加两个能力一个是基于订阅消息的任务提醒另一个是简单的数据统计图表。前者涉及订阅消息的模板配置需要在后台申请后者可以用小程序自带的绘图能力实现。这两个功能做完之后WorkBuddy 从一个单纯的待办工具会慢慢变成一个轻量级的个人任务管理中心。如果你也想用提示词驱动的方式做一个小程序我的建议是先别管技术和流程拿出一张纸写下你想解决什么问题用户打开小程序第一个动作是什么第二个动作又是什么。把这些问题想清楚之后提示词自然写得出来代码生成只是水到渠成的事。