上周我用一条提示词撬动了一个微信小程序的完整开发流程，从敲定想法到扫码上线只用了不到两天。这里说的不是套个模板改改文案，而是从产品定位、页面结构、代码生成到部署上线的整条链路。拆开来看每一步都不神秘，但串起来之后，很多没做过小程序的朋友会觉得无从下手。这篇文章我就把 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 从一个单纯的待办工具，会慢慢变成一个轻量级的个人任务管理中心。如果你也想用提示词驱动的方式做一个小程序，我的建议是：先别管技术和流程，拿出一张纸写下你想解决什么问题，用户打开小程序第一个动作是什么，第二个动作又是什么。把这些问题想清楚之后，提示词自然写得出来，代码生成只是水到渠成的事。
上周我用一条提示词撬动了一个微信小程序的完整开发流程，从敲定想法到扫码上线只用了不到两天。这里说的不是套个模板改改文案，而是从产品定位、页面结构、代码生成到部署上线的整条链路。拆开来看每一步都不神秘，但串起来之后，很多没做过小程序的朋友会觉得无从下手。这篇文章我就把 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 从一个单纯的待办工具，会慢慢变成一个轻量级的个人任务管理中心。如果你也想用提示词驱动的方式做一个小程序，我的建议是：先别管技术和流程，拿出一张纸写下你想解决什么问题，用户打开小程序第一个动作是什么，第二个动作又是什么。把这些问题想清楚之后，提示词自然写得出来，代码生成只是水到渠成的事。