企业官网建设流程全解析

一条提示词能不能做出一款能扫的微信小程序？我这次是亲测下来了：能，而且整个链路比我预想的顺。最近我用 WorkBuddy 从零写了一个工具类小程序，过程非常像带了个上手极快、偶尔需要盯一盯的实习生——它会按我的提示词把工程框架、页面、样式一起铺出来，剩下的工作主要是检查、调错和善后。今天就按我实操的路径，把从提示词、生成代码、导入开发者工具，到最终扫码上线的全过程完整拆一遍。

我不会跟你聊太多概念，直接说清楚：这条提示词怎么写、WorkBuddy 生成出来的代码长什么样、在微信开发者工具里要改哪几个点、提交审核会被哪些地方卡住。全程都是能直接抄作业的内容，哪怕你没写过前端，照着走也能把一个小工具类小程序弄上线。

1. 为什么我把一条提示词当剧本，而不是从空白工程开始

1.1 这条提示词解决的核心问题

做微信小程序最大的门槛不是功能复杂，而是“空白页焦虑”。传统流程里，你要先跑通一串前置动作：注册账号、创建 AppID、下载开发者工具、新建项目、选模板、理解 app.json 里怎么注册页面、知道 .wxml/.wxss/.js/.json 四个文件各自干什么。这一套下来，对于没写过前端的人，基本当天就放弃了。

AI 辅助开发的逻辑，是把你从“从零手写”变成“生成后修改”。微信小程序本身有一套非常固定的工程规范，恰恰适合让大模型代劳。WorkBuddy 本质上就是预置好了这套规范，你只需要告诉它要做什么，它就能按规范把目录、路由、页面、基础交互一次性铺开。我这次最直观的感受是：初始化成本从小时级降到了分钟级，我可以把省下的精力全部放在功能逻辑和上线细节上，而不是在脚手架里打转。

1.2 和传统开发流程的对比

为了让你更直观地看差异，我把两条路径放在一起对比：

你会发现，WorkBuddy 并没有跳过“上线配置”“后台设置”这些硬性环节，它帮你省掉的是最耗时、最劝退的编码初始化和页面搭建。后端存储、支付、复杂权限这类内容，它也能生成框架，但架构决策仍然要你自己拿主意。换句话说，它降低的是“把想法变成第一个可用版本”的成本，而不是替代所有工程决策。

1.3 这个方案适合谁

我身边问这个问题的朋友，大致是三类人。第一类是想快速验证一个产品灵感，不知道要不要投入开发的人；第二类是产品经理或运营，有清晰的需求描述能力，但不熟悉前端技术；第三类是本身有前端基础，但被重复搭建页面磨得不耐烦的老手。

对这三类人，用提示词生成第一版再手工微调，都比我之前推荐的“先学一个月前端再动手”高效得多。但我也要给你提个醒：如果你要做的是强交互、高定制动画、复杂实时通信的项目，AI 生成只能当起点，不能直接当终稿。工具类小程序、内容展示类小程序、简单工具链，是这条路线最舒服的区间。

2. 准备工作：把账号和提示词都备齐

2.1 账号、工具与 AppID

在生成代码之前，有两件事必须提前做好，不然代码生成完会卡在“导入工程”这一关。第一，注册一个小程序账号。个人开发者注册个人主体即可，路径是微信公众平台，在“注册”里选小程序，按指引填邮箱、身份证信息，审核非常快，基本当天能过。第二，下载微信开发者工具，这是微信官方 IDE，Windows 和 macOS 都有安装包，用同一个账号扫码登录就能用。

注册完成后，在“开发管理 -> 开发设置”里能看到 AppID。这个参数我建议你提前复制到备忘录里，因为后面导入工程时要填，WorkBuddy 生成的代码里一般也会留一个占位符，你需要替换成自己的。很多人生成完代码急着导入，结果因为 AppID 没换成自己的，预览时报错，来回折腾半小时，完全没必要。

2.2 提示词为什么不能直接写“帮我做一个小程序”

我第一次用这类工具时写的是：“帮我做一个待办清单小程序。”结果是灾难现场——它给我生成了五六个页面，包括登录、个人中心、统计报表，甚至一个积分商城入口。原因是模型不知道你的真实范围边界，你给一条模糊需求，它就会按“常见小程序”的样子自由发挥，把能有的功能全给你铺上去。

所以提示词写作的核心，不是“把需求说清楚”，而是“把边界锁死”。你要告诉它：一共有几个页面，每个页面要展示什么，支持哪些操作，数据存在哪里，长什么样。有了这些约束，它生成的代码才不会跑偏。

2.3 我用的可复用提示词模板

下面这份模板可以直接复制进 WorkBuddy，里面的需求描述你可以按需替换：

你是一名微信小程序前端工程师，请用原生微信小程序实现一个「待办清单」小程序。 页面要求： 1. 首页：展示待办列表，支持新增待办、勾选完成、长按删除； 2. 新增页：输入框 + 保存按钮，保存后返回首页并刷新列表； 3. 设置页：展示当前待办数量，提供“清空全部”按钮并二次确认。 交互要求： - 数据使用 wx.setStorageSync 本地持久化，刷新或重启后不丢失； - 新增待办后自动刷新首页； - 删除操作需通过 wx.showModal 二次确认。 视觉要求： - 主色使用 #07c160（微信绿），列表使用卡片样式； - 空状态显示“暂无待办，点击右下角新建”。 技术约束： - 使用原生小程序语法，不要引入第三方组件库； - 微信 API 统一使用当前最新推荐写法； - 生成完整 app.json 路由配置。

你可能注意到我特别强调了“数据存在本地”，因为很多人写提示词时不会管数据层，而模型默认会给所有小程序配云开发，导致你后面要开通云服务、创建云函数，完全是凭空增加复杂度。个人工具类项目用本地缓存就够了，先把核心流程跑通，再考虑多端同步。

3. 实操全过程：从提示词到能跑的工程

3.1 WorkBuddy 生成出来的工程结构

点击生成后，WorkBuddy 的输出是一个标准的小程序工程目录。我第一次拿到时第一反应是“居然真能生成得像模像样”，目录结构很规范：

. ├── app.js ├── app.json ├── app.wxss ├── project.config.json └── pages ├── index/ │ ├── index.js │ ├── index.wxml │ ├── index.wxss │ └── index.json ├── add/ │ ├── add.js │ ├── add.wxml │ ├── add.wxss │ └── add.json └── settings/ ├── settings.js ├── settings.wxml ├── settings.wxss └── settings.json

这里我解释一下每个文件的职责，方便你判断生成结果够不够。app.json 是整个小程序的路由表，pages 数组里列出的每一个路径都对应一个页面。页面目录下四个文件分工很明确：.wxml 是页面结构，.wxss 是样式，.js 是逻辑和数据，.json 负责页面级配置。如果 app.json 里注册了一个路径，但对应目录不存在，编译会直接报错。所以拿到生成代码后，第一件事就是对照 app.json 检查 pages 目录下是否所有引用都存在。

3.2 三轮迭代修改，把生成代码改成能用的代码

生成只是开始，真正让它变成一个能安心上线的版本，我做了三轮修改。第一轮是整理页面结构。我的提示词写了三个页面，但 WorkBuddy 只生成了 index 和 add 两个，settings 目录压根没有，app.json 里也没注册。这种情况不用重新生成，我已经录入过：只需要手动创建 settings 目录，补上四个文件，并在 app.json 的 pages 数组里加上pages/settings/settings即可。

第二轮是事件绑定的修正。AI 生成的列表删除逻辑有时会直接写成bindtap="deleteTodo"，没有处理当前点击的是哪一条数据。这时候接收事件参数需要用e.currentTarget.dataset.id拿到对应项，否则要么删错，要么永远只删第一条。如果你看到生成的代码里 deleteTodo 函数没有读取 dataset，需要自己补上。

第三轮是过时 API 的替换。我的需求里涉及“用户信息”，WorkBuddy 生成代码时用了wx.getUserProfile这个老接口。这个接口在最新版本已经被收紧了，弹窗授权逻辑经常失效，正确的做法是改用“头像昵称填写能力”，在页面上放一个button open-type="chooseAvatar"让用户选择头像，再用input type="nickname"让用户填写昵称。这是最近几年微信改版后最稳的做法。

3.3 导入微信开发者工具并跑起来

打开微信开发者工具，选择“小程序 -> 导入”，目录指向 WorkBuddy 生成的那个文件夹，AppID 填你自己注册的那个，点击导入。

这里有一个特别常见的坑：如果导入后提示“未找到 app.json”，大概率是目录层级选错了。WorkBuddy 生成时可能把工程文件放在某个子目录里，你需要导入的是包含 app.json 的那一层，而不是最外层套娃目录。

导入成功后，先在模拟器里完整跑一遍核心链路：新增一条待办、返回首页看列表是否刷新、勾选完成、长按删除、确认弹窗、再清空全部。这个过程中如果控制台报红色错误，优先看是 JS 语法错误还是 WXML 绑定错误。只要这三轮逻辑都走通，你的本地开发阶段就已经结束了，可以往上线推进。

4. 从二维码到正式上线：我走的完整提审链路

4.1 真机扫码预览，第一次白屏如何解决

在开发者工具右上角点击“预览”，会生成一个二维码，手机微信扫码后就能在小程序里进行真机体验。这个环节我第一次踩了白屏的坑：手机打开后一片空白，模拟器里明明一切正常。

后来排查发现是基础库版本和域名校验的问题。开发者工具里有个“详情 -> 本地设置”，默认会勾选“不校验合法域名、web-view（业务域名）、TLS 版本以及 HTTPS 证书”，模拟器环境下不受限制，但真机预览会走真实域名校验，如果你的代码里有wx.request请求非 https 接口，会被直接拦截，表现就是白屏。

临时解决办法是在本地设置里勾上“不校验合法域名”再重新预览；正式解决办法是去小程序后台把请求域名加到服务器域名白名单里。如果你像我一样用的是纯本地缓存存储，代码里没有网络请求，那白屏多半是基础库版本问题，把调试基础库调低一点，或者检查 console 里有没有 API 不兼容的报错。

4.2 后台配置：服务器域名、隐私保护指引

真机跑通后，不要急着提审，还有两个后台配置必须处理。

第一个是服务器域名。在微信公众平台的后台，“开发管理 -> 开发设置 -> 服务器域名”里可以配置 request 合法域名。这里只支持 https，不支持 IP 和端口。如果你的小程序没有发起任何外部网络请求，这个配置可以跳过，但一旦后续加了接口调用，必须提前配置，否则线上版本请求会被拦截。

第二个是用户隐私保护指引。这个要比很多人想得要重要。现在提审强制要求你声明收集了哪些用户信息，哪怕只是头像昵称，也要在“设置 -> 服务内容声明 -> 用户隐私保护指引”中如实填写。我第一次提审就被驳回了，原因就是隐私保护指引里没有完整声明头像昵称的用途。修改后重新提交，很快通过。

如果代码里涉及wx.getUserProfile、wx.getLocation、wx.chooseImage等敏感接口，后台指引里必须逐项声明，并且在代码里做好隐私弹窗或按钮触发的逻辑，否则审核仍然会被卡。

4.3 提交审核与正式发布

所有配置完成后，回到开发者工具，点右上角“上传”按钮，填写版本号和备注信息。然后到小程序后台“版本管理”里，可以看到刚上传的开发版本，点“提交审核”。

提交审核时有两个细节要留意。一是类目选择，个人主体的小程序建议选“工具 -> 效率”或对应你真实功能的类目，不要为了蹭流量乱选医疗、金融类目，那基本会被拒绝；二是审核备注一定要写清楚“该小程序的主要功能是什么、如何操作”，审核员会按你的描述走一遍核心流程，能跑通、不违规，自然放行。

我这次从提交审核到通过大概花了几个小时，没有遇到排队严重的时段。审核通过后，回到版本管理里点“发布”，小程序就正式上线了。从生成代码到最终发布，我全程大概用了一个下午加一晚上，这个速度放在以前是没法想象的。

5. 常见问题与排查实录

5.1 编译报错类

我用表格整理了这次实际遇到的编译问题，以及对应的处理方式，你可以直接对照排查：

这类问题的共性特征是：app.json 里的页面注册信息与实际文件结构不一致。AI 生成的代码通常不会给你少文件，但手工或跨版本情况容易漏，所以第一轮排查永远先对齐“路由表”和“目录表”。

5.2 接口与授权失败

接口和授权问题在高版本基础库里尤其多，我整理了三个高频场景：

wx.getUserProfile is not a function，这是接口已收紧或基础库版本太低导致。处理方式是放弃旧接口，改用头像昵称填写能力。wx.request fail url not in domain list，说明请求的接口域名没有配置到后台合法域名列表，开发阶段可以临时勾选“不校验合法域名”，上线前必须补配置。还有setStorageSync报错，一般是因为本地缓存空间不足，单个 key 有容量上限，注意减少存储量。

排查授权类问题时，先区分清楚是“权限弹窗没出现”还是“接口调用失败”。弹窗没出现通常是隐私授权声明没做，接口调用失败通常是域名、AppID 或基础库问题，这两个方向不要搞混。

5.3 上线审核被驳回的三种高频原因

网上很多人抱怨审核严格，其实大部分驳回都是可以提前规避的。我总结出三类高频原因。

第一类是类目与功能不匹配。个人主体的小程序如果涉及资讯、社交、直播等类目，很容易被拒，因为个人主体通常只能选部分工具、教育、生活服务等类目。选类目前先查一下小程序后台的类目资质要求。

第二类是占位内容和测试数据。审核员会真实操作你的小程序，如果首页写的是“测试数据”或“演示内容”，他们会怀疑你的产品没有完整功能。上线前把默认数据清空，改成空状态引导，或者填入真实可用的内容。

第三类是隐私协议不完整。只要涉及用户信息，哪怕只是头像昵称，后台隐私保护指引漏填就会被驳回。不要只填一个笼统的“收集用户信息”，要把收集的字段、用途、使用场景写清楚。

6. 如果重做一遍，我会在提示词阶段先做这三件事

6.1 把“不要做什么”也写进提示词

踩过一次模型自由发挥的坑之后，我现在的提示词都会加一句“不要添加无关页面”“不要预留假数据”“不要使用第三方组件库”。AI 生成的代码在没有约束的时候，会按“典型完整产品”的样子塞功能，你后期清理代码的时间可能比节省下来的时间还多。正向需求描述重要，反向边界描述同样重要，这一条能帮你省掉大量无意义的删改。

6.2 先完成最小可运行版本，再扩展功能

我这次是一口气生成三个页面，过程中出现了页面缺失、路由不一致的问题。如果重新做，我会在提示词里只保留“待办列表 + 新增 + 删除”这个最小闭环，跑通之后再对 WorkBuddy 说“添加一个设置页，显示待办数量，增加清空全部按钮”，一次加一个功能。这样每一轮迭代的变量最小，出了问题也能快速定位，对个人项目来说效率反而更高。

6.3 无论用工具还是手写，数据边界都要提前想清楚

很多 AI 生成的小程序失败在数据层没有提前决策。我用本地缓存做待办，是因为单设备场景完全够用，但如果想做多设备同步，就必须在上线前切换到云开发或自建后端 API，这个切换基本等于重写数据层。建议你在第一次写提示词时，就明确写出“数据保存方式是什么”。个人工具类直接写“本地缓存”，后续再加同步能力时，再让模型按新架构重构相关模块。提前想清楚数据边界，能避免后期为架构问题返工。

这条流程跑通之后，我最大的体会是：写提示词本身也是一种开发能力，它决定了 AI 生成代码的上限。工具负责铺路，但方向和边界必须由你自己把控。如果你也有一个放在脑子里很久的小程序想法，照着这个流程先跑通一个最小版本，再考虑怎么做得更完整，可能比一直等自己“准备好”更有效。