企业官网建设流程全解析

最近我拿 WorkBuddy 做了一个挺有意思的实验：把想要的小程序用一条提示词描述清楚，扔给它生成代码，然后自己接手走完微信开发者工具的编译、预览、上传、提审这些环节，最后真的拿到了一个扫码就能在微信里打开的正式版本。整条链路走下来，我的感受是：这不是玄学，AI 辅助开发确实比从零手写快非常多，但它也绝对不是你打一句话就能躺着上线的“魔法按钮”。中间涉及需求边界、代码验收、编译调错、审核配置一堆环节，每一个都有坑。这篇文章我就把全流程拆开讲，从提示词怎么写开始，一直到提交审核和正式发布，把我踩过的坑和觉得“早知道就好了”的细节都整理出来，给正打算尝试同类工作流的同学一个参照。

1. 先别急着写提示词：把需求写成 AI 能执行的“产品说明”

很多人第一次用 WorkBuddy 都是随手写一句“帮我做个点单小程序”或者“生成一个电商小程序”，然后期待它一次性吐出一套无 bug 的代码。实测下来，这种输入大概率会给你一个结构看着挺完整、但一编译就四处报错的半成品。原因不复杂：像 WorkBuddy 这类工具，本质上是把提示词理解成一份《产品需求文档》，你在文档里给出的信息颗粒度越粗，它在页面设计、数据结构和交互方式上的自由发挥就越多。自由发挥一多，后面等着你的就是改错和返工。

1.1 提示词模板：我把一次成功的输入拆成了五块

这次我做的示例是一个咖啡店点单小程序，为了避免生成结果跑偏，我的提示词是这样组织的：

“你是微信小程序开发工程师。请帮我生成一个名为‘某咖啡’的点单小程序。页面要求：首页展示商品分类和商品列表，商品卡片包含名称、价格、图片占位、简介；顶部有搜索框；底部固定 tabBar，包含‘点单’和‘订单’两个页面。交互要求：点击商品可加入购物车，购物车展示在当前页面底部，能修改数量、计算总价、清空；结算页收集用户昵称和取餐方式，提交后跳转到一个订单成功页。数据先用本地 mock 数据，商品数组单独放在一个 js 文件中，方便我后续替换成后端接口。视觉风格偏暖色，主色调用棕色，全局使用 rpx 做适配。”

这段提示词看起来不算长，但信息密度很高。它包含了五个关键部分：

• 岗位设定：告诉 AI 你期望它扮演什么角色，它就会自动带上对应的技术栈常识；
• 页面目录：首页、购物车、结算页、订单成功页全部点名，生成结果基本不会缺页面；
• 交互细节：加入购物车、修改数量、计算总价、清空这些动作写清楚，AI 生成的逻辑代码会更有针对性；
• 数据边界：明确要求 mock 数据，并把数据文件的位置规定好，后面替换接口时只需动一个文件；
• 样式约束：主色、适配单位这类视觉要求直接写进提示词，虽然不可能做到像素级还原，但整体不会跑偏。

1.2 提示词写得模糊，代价会出现在哪个环节

我把同一个需求分别用“精简版”和“完整版”各生成了一次，对比非常直观。精简版只写“做个点单页面”，生成结果里只有一个孤零零的商品列表，购物车逻辑完全没有；提示词里不写“本地 mock”，AI 就会自行选择调用某个不存在的接口域名，导致预览时页面数据一片空白。这些都属于“生成时很爽、调试时想哭”的情况。

所以我的建议是：把提示词当需求文档写，宁可啰嗦，不要省略。页面清单、核心交互、数据来源、视觉基调这四件事是必须交代清楚的。你可能会觉得这已经不算“一条提示词”了，但实际上它仍然是“一条”，只不过是一条结构化的、能真正指导 AI 干活的高质量指令。真正值得花的时间不是后面反复改 bug，而是最开始想清楚自己要什么。

2. 生成代码不是终点：我用这套验收清单拦截了大部分返工

WorkBuddy 生成完代码后，我打开目录看了一眼。从结果看，它已经具备了一个微信小程序项目的基本骨架：app.js、app.json、project.config.json、pages 目录，以及 tabBar 里配置的两个页面文件夹。页面内 wxml、wxss、js、json 四个文件都齐全。这些结构本身没什么问题，但“结构齐全”和“能直接运行”之间还差着一道关键的手工验收。

2.1 我会按顺序检查的五个项目

这里我直接把验收流程列出来，每一步都有具体原因：

2.2 一个容易忽略的细节：生成代码里可能混入“伪 API”

刚开始用时，我注意到 WorkBuddy 生成的某个页面里出现了一段类似wx.showToast的调用。这个 API 本身真的存在，但参数格式写得不对，把 duration 写成了纯数字而不是对象形式。这种“API 存在但用法错误”的坑特别隐蔽，编译阶段根本不会报错，只有真机跑到那一行时才会有异常表现。所以验收代码时不能只看活跃报错，还得逐个检查它调用的小程序原生 API 用法是否符合微信生态规范。

另一个容易出问题的是资源路径。AI 生成的代码里有时会出现image: "/images/logo.png"这样的写法，但实际项目里并没有 images 目录。生成工具不会自动帮你准备图片资源，所以你在做验收时要特别留意所有引用了本地资源的代码块，要么补齐文件，要么改成网络图片或纯色占位。这里我的习惯是：把模板里的大部分图片都统一改成 solid 色的 view 加文字，省去后续 UI 阶段换图时的修改成本。

3. 本地调试与真机预览：AI 代码的三类典型报错和修复路径

把 WorkBuddy 生成的代码导入微信开发者工具后，我遇到了不少编译错误，好在类型非常集中。我把它们归成三类：路径类、语法类、结构类，每一类都有比较固定的排查套路。

3.1 环境准备阶段，最容易在 AppID 上卡住

打开微信开发者工具，点“导入项目”，选择 WorkBuddy 生成的代码目录。此时有个关键选择：AppID 怎么填。如果只是本地看效果，可以直接用测试号功能，它会帮你通讯成一个临时的 AppID，适合跑通编译；但如果计划上传到真正的线上，就需要你自己申请正式小程序账号，然后在控制台拿到正式 AppID。这个环节建议一开始就用正式 AppID 创建项目，否则做完开发再切换，会遇到项目配置重置的问题，很麻烦。

导入时还要注意一个选项：是否使用“云开发”环境。WorkBuddy 生成的代码默认是纯前端 mock 数据，没有用到云函数，所以我在导入时直接选择了不使用云服务。如果你勾错了，开发者工具会尝试关联云环境，而项目里并没有对应的初始化代码，之后编译时会出现莫名的权限报错。

3.2 三类高频报错的根因和处理方法

第一类是“页面路径未找到”相关的报错。比如module "pages/index/index.js" is not defined，或者Page is not constructed。这类错误绝大多数是因为 app.json 里注册的页面路径和实际文件名不一致，或者页面目录层级不对。我在测试时遇到过 WorkBuddy 把页面生成在pages/category/index下，但 app.json 里写的是pages/category/category，这种偏差不改的话无论编译多少次都过不去。

第二类是 wxml 的“语法解析错误”。AI 生成模板时偶尔会写出不合法的表达式，常见于wx:if或{{ }}内部。举个例子，它生成过wx:if="{{item.count > 0 &&}}"，后面那个&&后面没有操作数，整个页面直接白屏。这种 bug 修改起来不难，但如果你不打开编译日志的详细条目，很容易对着空白页面无从下手。修复后要立刻在模拟器里操作一遍对应组件，确认页面不再白屏。

第三类是“事件绑定到不存在的函数”。js 里没有定义submitOrder，但 wxml 里有bindtap="submitOrder"。报错一般不会在编译期出现，而是等你在模拟器里点击那个按钮时才触发TypeError: _this.submitOrder is not a function。遇到这类问题，我会直接打开 wxml，把所有事件绑定全部列出来，再对照 js 里的函数清单执行一个小脚本或人工核对一遍，基本一次性清完。

3.3 真机预览的步骤和验证方法

编译通过后，点击开发者工具顶部工具栏里的“预览”，会生成一个临时二维码。扫码时需要注意：这个二维码的有效期很短，一般只够你进行快速验证，而且真机报错只能通过“远程调试”模式查看控制台日志。我的验证清单是：从首页进入详情，加入购物车，修改数量，再走一遍结算流程，最后确认订单成功页跳转无异常。这一套走通，核心链路就没有大问题了。

4. 一键上传到扫码上线：体验版提审与正式发布

本地调试通过，只能说项目“能跑”，距离“上线”还有一段路。微信小程序的发布严格来说要经历：开发者工具上传版本、在管理后台提交审核、审核通过后发布为正式版。这里每一步都有细节。

4.1 上传前的版本配置，做错了容易白等

在开发者工具点“上传”按钮之前，先确认两件事：版本号写得规范，比如 1.0.0，而不是随意填个 1.0；项目备注写得清楚，比如“初始版本，含点单与订单模块”，它会被带到管理后台，便于后续回溯。上传过程本身很快，完成后到小程序管理后台的“版本管理”页面，就能看到新提交的版本，这时候可以二次确认代码包大小。WorkBuddy 生成的项目通常只有几百 KB，远低于整体限额，这一点基本不用担心。

4.2 提交审核时的常见驳回点

审核这个环节是很多 AI 开发项目的“翻车重灾区”，驳回原因归结起来主要有四类。

第一类是“类目与功能不匹配”。比如我做的是一个咖啡点单工具，功能里涉及堂食、自提这类消费场景，那就得选餐饮相关类目，不能随便选一个“生活服务”带过。类目选错，审核人员打开小程序后会对不上号，驳回理由写得很简略，沟通成本极高。

第二类是“功能页面不完整或无法体验”。AI 生成的代码里如果还残留着“TODO”字样或一只死按钮，审核人员点进去发现功能缺失，就会以“页面功能无法使用”为由打回。我的建议是上传版本前，全局搜索一遍 TODO、mock、占位这类关键词，把可疑的残页处理干净。

第三类是“涉及用户信息但没有相应的隐私保护说明”。因为点单流程里收集了用户昵称，平台要求在小程序后台完成用户隐私保护指引的填写，同时需要在项目的 app.json 里配置相关的声明。如果不填，审核人员会在隐私协同检查环节判不通过。这里的解决思路很朴素：凡是你说要收集的信息，都要在后台如实声明用途，不要藏着掖着。

第四类是“app 页面内存在测试或废弃内容”。比如我生成的订单成功页里有可能出现一段“本页面为演示数据”的注释文字，审核人员如果看到这类字样，会觉得产品质量不行。所以提交前，全项目搜索一下“demo”“test”“示例”“占位”等词汇，把能删的删掉。

4.3 从审核通过到真正的“扫码上线”

审核通过后，需要手动点击“发布”按钮，小程序才会进入正式版状态。这时候你再去微信里搜这个小程序名称，或者在管理后台生成正式版二维码，任何人扫码打开的就已经是在线运行的正式版本了。这一步的动作很简单，但带来的体验变化是质的：从开发环境里的模拟器，变成真实用户在微信里可访问的服务，整个链路才算是闭合了。

5. 复盘：这类“提示词到上线”的工作流，到底适合哪些项目

跑完这整个流程后，我并不是说以后所有小程序都可以丢给 WorkBuddy 一键生成并发布。实际上它的应用边界非常清晰：适合做那些“逻辑不复杂、页面数量少、以展示和提交为主”的工具型小程序，比如点单、预约、名片、题库、信息查询类项目；不适合做的是强交互、强实时性、复杂状态管理的应用，比如视频社区、IM 聊天、多角色权限系统。判断标准可以用一条朴素原则：如果需求的交互流程可以在一张纸上画清楚，那就非常适合用提示词驱动生成。

如果你发现自己做的是右侧那种项目，我的建议是把 WorkBuddy 定位成“脚手架生成器”，而不是“全部代码提供者”。让它生成骨架和基础页面，再人工开发核心逻辑，效率依然远高于从空目录开始手写。

结尾我分享一下个人的新习惯：现在每次开工前，不管项目简单还是复杂，我都会先花二十分钟写一版覆盖页面、交互、数据来源、风格约束的完整提示词，即使最后没有直接用 WorkBuddy 生成全部代码，这份提示词也可以通过单独的方式继续使用。它相当于一张不用画 UI 的架构图，能让 AI 和同事都快速理解需求，减少很多沟通成本。你如果想体验“一条提示词到扫码上线”的完整链路，就从一个小点单工具开始试，跑通一次之后，你大致就能预判哪些环节可以交给 AI，哪些环节必须自己把住，这个过程本身比项目上线更有价值。