企业官网建设流程全解析

先说个背景。去年下半年我接了一个本地商家的需求，要做一个小程序商城，工期紧、预算有限，客户还指定要直接上线微信。当时我手里同时在维护两个老项目，根本抽不出时间从头手写一整套小程序前端加后端。后来我试了下 WorkBuddy，发现这东西比我想象中能打。花了一个多星期就把核心功能跑起来了，后面又花了两天处理审核细节，直接拿下线上版本。这篇就完整复盘一下我怎么用 WorkBuddy 从零做小程序、对接微信登录和手机号授权、最终过审上线的全部过程，包括踩过的坑和排查思路，给同样想用 AI 工作台加速小程序交付的朋友做个参考。

1. 为什么选 WorkBuddy 做小程序而不是传统开发方式

1.1 WorkBuddy 本质上是什么工具

先放下对"AI 编程助手"的固有印象。WorkBuddy 是一个偏向项目级协作的智能工作台，它的核心能力不只是帮你补全代码，而是把需求拆解、任务编排、代码生成、文件读写、命令执行这一套流程串起来。你在里面描述需求，它会生成对应的开发计划，再按计划逐文件生成或修改项目代码。对于小程序这类工程结构相对固定、模式化程度高的项目，这种工作方式非常占优势。

我刚接触 WorkBuddy 的时候，它还只能处理一些独立脚本和单页面应用。到了我做小程序这个阶段，它已经能感知整个项目目录结构，可以同时维护 WXML、WXSS、JS、JSON 四个层级的文件，还能调用开发者工具命令行进行预览和编译。这意味着我不必再像以前那样自己对着模板文件一个个新建页面、手动配置路由。

如果你用过 Cursor 或 CodeBuddy，可能会觉得这些工具本质上都是"对话生成代码"。但从项目交付角度，差别在于 WorkBuddy 更强调"工作台"的概念，它会把任务拆成多个 Skill 模块，比如"创建微信小程序页面""配置分包""生成后端接口文档"，你可以让它在项目上下文里连续工作，而不是每次开一个新对话重新理解代码。热搜词里也有人在找 WorkBuddy 的 PDF 教程和安装指南，说明刚开始研究它的人确实不少，我这里说的都是自己实际用下来的体验。

1.2 传统小程序开发流程的痛点和 WorkBuddy 的解法

传统小程序开发为什么累？我可以用一个对比表来说明。以前我从零做一个带登录、商品列表、购物车、下单流程的小程序，时间基本分布在这些环节：

这些时间里，真正需要动脑子的部分其实占比不大，多数是在搬砖：复制上一套项目的配置、把后端返回的数据字段对齐到页面上、微调样式去适配不同屏幕。WorkBuddy 最直接的价值就是把"搬砖"的部分吃下来。

我实测的流程是这样：我先把需求拆成功能点清单发给 WorkBuddy，它会生成一个多步骤任务列表。比如"创建全局配置文件""实现 wx.login 登录逻辑""编写商品列表页面及对应接口调用"，然后按顺序执行。每一步生成完后，我只需要在预览面板里刷新看效果，发现问题就让它改，改完继续下一步。整个过程中我更像是一个项目经理加测试，而不是每一行代码都要亲自去写。

我当时的感受是，这条路适合三种情况：一是像我这样时间紧张、需要快速交付的；二是团队里没有专职前端，想低成本把小程序做出来的；三是想学习小程序整体架构、但又不想从零啃文档的新手。反过来，如果你做的是高度定制、交互极其复杂的小程序，那 WorkBuddy 只能帮你打底，核心交互还是得自己动手调。

2. 环境搭建与项目初始化细节

2.1 WorkBuddy 安装和 Skill 配置

我是 Mac 环境下操作的，安装过程本身并不复杂，下载对应安装包后直接拖进应用程序目录就行。但真正影响效率的是初始配置，有几个点必须提前弄好。

第一是登录账号和模型服务。WorkBuddy 支持多种模型后端，国内网络环境下我用的是平台自带的服务，这样省去了自己配模型 API 的麻烦。如果你想把 WorkBuddy 接到自己已有的模型网关，也可以在设置里手动填 Base URL 和 API Key，但要注意，项目级代码生成需要的上下文很大，模型能力不够的话，生成的代码质量会直线下降，这是第一个要注意的坑。

第二是 Skill 的加载。Skill 在 WorkBuddy 里相当于一个个专项工作流，比如"小程序页面生成""微信 API 封装""代码审查"等。我第一次做小程序时没加载对应的 Skill，结果它给我生成的代码风格偏向传统网页，组件样式用的是 div 而不是小程序原生的 view，一看就不对。后来我在工作台里启用了小程序开发相关的 Skill，再让它重新生成，代码整体就正常多了。这个经验非常重要：不要只依赖大模型的通用能力，一定要让 WorkBuddy 先加载针对具体平台的工作流规则。

第三是本地项目目录的授权。WorkBuddy 操作文件是需要目录权限的，如果不给它指定工作目录，它默认只能在沙箱里操作，生成的代码没法直接落到你的工程目录里，后续还得手动复制，效率大打折扣。我在初始化阶段就把整个工作计划放在一个专门目录下，比如~/projects/2048-mall，这样它后续读写文件都在这个目录内，版本管理也方便。

2.2 用 WorkBuddy 生成小程序工程骨架

我新建项目时并没有选用微信开发者工具的默认模板，而是让 WorkBuddy 直接生成一套带基础能力的骨架。核心配置集中在app.json和project.config.json两个文件上。

在app.json里，需要明确页面的注册顺序、窗口样式、TabBar 配置。这里有一个容易忽略的细节，就是首屏页面一定要放在 pages 数组的第一项，否则小程序启动时会找不到默认页面。我第一次生成时因为页面顺序调得不对，启动后一直白屏，查找了半天才发现是这个原因。

project.config.json则要注意appid字段。如果你还没有注册小程序账号，可以先在微信公众平台申请一个测试号，把测试号 AppID 填进去。填了 AppID 之后，微信开发者工具才能正常编译预览，否则只能使用游客模式，部分 API 会无法调用。

骨架生成完毕后，整个项目结构大致是下面这样的：

2048-mall/ ├── app.js ├── app.json ├── app.wxss ├── project.config.json ├── sitemap.json └── pages/ ├── index/ // 首页 ├── goods/ // 商品列表 ├── cart/ // 购物车 ├── order/ // 订单 └── mine/ // 个人中心

其实第一版里 WorkBuddy 还生成了一些我没用到的页面，比如优惠券、积分商城，我后来直接从app.json的 pages 列表里删掉了对应路径，同时把文件目录一并清除。这里也提醒一下：让 AI 生成代码的时候，需求描述越精确越好，不要让它在页面规划上自由发挥，否则后面清理的成本还是挺高的。

我把骨架准备好之后，先在微信开发者工具里做了一次全量编译，确认基础页面能正常打开，再开始往下走业务功能。千万不要一上来就让 WorkBuddy 把登录、商品、下单这些一次性全部生成，模块之间依赖关系复杂，一旦出错排查起来非常痛苦。一个阶段一个阶段来，每个阶段都验证通过，这是项目级 AI 协作最重要的节奏。

3. 核心功能开发与关键技术点拆解

3.1 微信登录与手机号授权实现

小程序登录的完整链路看起来就几个接口，实际操作时必须把时序搞清楚。我梳理成下面这张流程表，照着它可以少走很多弯路：

这个链路里最容易出错的地方是：code 只能用一次，而且五分钟内有效。如果后端处理失败、前端重复发送同一个 code，第二次必然报错。我在联调的时候就犯过这个低级错误，前端写了重试逻辑，失败后自动重新发送旧的 code，结果后端一直返回会话过期错误。后来把重试逻辑改成重新调用wx.login()生成新 code 才解决。

手机号授权的实现更值得注意。微信从基础库 2.21.2 开始调整了手机号获取逻辑，现在不能再直接拿手机号明文，而是通过getPhoneNumber按钮触发，得到code，再把这个code发给后端换成手机号。这个过程中，前端只能拿到加密后的数据，真正解密或换取前置手机号信息必须由后端调用微信接口完成。

用 WorkBuddy 生成这段逻辑时，我特别在需求里强调了一点：手机号按钮组件必须使用微信官方的<button open-type="getPhoneNumber">，不能用自定义样式按钮模拟点击再调用 API。微信考察代码时，如果检测到没有使用官方开放能力就直接调用隐私接口，很容易被驳回。另外，小程序后台还需要提前声明"获取手机号"的隐私接口用途，否则用户端根本不会弹出授权框。

WorkBuddy 生成的后端接口代码我也看了好几遍，重点在于把code2Session返回的session_key和手机号换取逻辑分开。由于session_key是敏感信息，它不应该被返回到前端。如果你看到 AI 生成的代码把session_key直接透传回来，一定要改掉。这不仅是规范问题，也是安全底线。

3.2 顶部导航栏与安全区适配

小程序顶部导航栏看起来简单，实际适配坑很多。原因在于微信各版本、各机型对导航栏高度的计算并不完全一致，尤其 iPhone 的刘海屏和底部 Home 指示条，布局稍不注意就会遮挡。

我一开始图省事，全部使用系统默认导航栏，也就是不自定义 navigationStyle。这种做法的优点是微信原生渲染，标题、返回按钮、胶囊按钮的布局完全不用自己管。但我这次做的是电商小程序，首页需要一个带搜索框的自定义头部来提升视觉效果，所以对首页单独开启了自定义导航栏，其他页面保留系统默认导航栏。

自定义导航栏时最关键的是要知道胶囊按钮的高度和位置。WorkBuddy 生成的适配代码大致是：

const systemInfo = wx.getWindowInfo(); const menuButton = wx.getMenuButtonBoundingClientRect(); const navBarHeight = (menuButton.top - systemInfo.statusBarHeight) * 2 + menuButton.height;

这段代码的意思是：胶囊按钮顶部到状态栏底部的距离，乘以二，加上胶囊按钮自身高度，就是导航栏的完整高度。这个公式不是 API 文档直接提供的，而是社区里沉淀出来的计算方式，实测下来在绝大数机型上都是准的。

我沿用这个公式处理了首页头部，页面效果在不同机型上基本一致。只遇到一个特殊情况：部分 Android 机型的statusBarHeight返回的是 0，导致导航栏计算高度少了状态栏那一截，头部整体上移。排查后发现是微信基础库版本过旧，升级到 2.30 以上后问题消失。如果你也遇到类似情况，建议先检查基础库版本，而不是手工去调整高度常量。

除了顶部导航栏，底部安全区也要处理。对于带 TabBar 的页面，官方 TabBar 会自动避开底部安全区，不用额外操心。但我定制了一个购物车悬浮按钮区域，没有走官方 TabBar，这时候就必须手动加上底部安全距离：

.safe-area-bottom { padding-bottom: env(safe-area-inset-bottom); padding-bottom: constant(safe-area-inset-bottom); }

env和constant两个属性都要写，前者是新版 iOS 的写法，后者是旧版兼容写法。顺序不能颠倒，否则低版本机型会忽略后面的声明。这个小点，我在实际开发时忘了一次，结果 iPhone 上按钮被 Home 条压住，看起来非常业余。

3.3 组件化设计与状态管理

小程序开发中组件化是一个不可回避的问题。我做的商城项目里，商品卡片在不同页面多次出现，如果每个页面都复制一份商品卡片代码，后续改价格显示逻辑时就要改好几个文件，容易漏改。

WorkBuddy 在生成这类组件时表现不错，它可以把商品卡片抽成一个自定义组件，放在components/goods-card目录下，然后通过usingComponents引入。引入后，页面之间可以共享组件逻辑，也要注意属性传递问题。自定义组件的properties定义要注意类型，如果一个数字字段被定义成了 String，页面上做价格比较时会发生类型不匹配，导致判断失效，这个问题排查起来需要点耐心。

状态管理方面，我并没有直接引入第三方库如 Redux 或 MobX，而是用globalData加页面setData的组合。项目规模不大时，这个方案足够用，而且微信小程序官方的响应式机制在setData调用时自动更新视图，理解成本很低。真正复杂的是多个页面都要修改购物车数据，比如商品详情页加购、购物车页删减、订单页清空，这三处如果不做状态同步，很容易出现数量不一致。

我的做法是写一个简单的 store 工具，把购物车数据和操作方法放在utils/store.js里，所有页面统一引用同一套接口。WorkBuddy 生成的 store 工具代码本身不复杂，就是对象加方法引用，但它是整个项目数据一致性的关键，所以我当时花了一些时间，专门核对各页面调用 store 方法的时机是否一致，确保没有出现一个页面修改数据后其他页面不知道的情况。

关于 setData，还有一个性能上的注意事项。不要把整个商品列表对象一次性传给页面，而应该只传需要变化的那部分字段。小程序逻辑层和视图层的通信成本不低，数据量大时会出现明显卡顿。WorkBuddy 默认生成的代码有时会把整个 backend response 原样 setData，需要我在需求里明确"按字段更新"才更正过来。

4. 前后端联调、新版体验与上线提审全流程

4.1 接口域名配置与本地联调

小程序最让人头疼的一个环节就是网络请求域名校验。在开发工具里，你可以勾选"不校验合法域名"来调试本地接口，但一旦上传代码并准备发布，所有请求的域名必须满足两个条件：HTTPS 协议、在微信公众平台后台配置为 request 合法域名。否则真机上请求会被拦截，页面拿到不到数据。

我第一次提审的时候就吃过这个亏，本地调试正常，上传后一真机访问，商品列表加载不出来。排查工具看到控制台报错，提示域名不在合法列表中，我才意识到需要在 mp 后台的"开发管理-开发设置-服务器域名"里加上后端接口域名。这里有个经验细节：配置完域名后不是立即生效，需要等几分钟到十几分钟，可以在开发者工具里重启项目再测试。

本地开发阶段，我建议用工具自带的 HTTP 代理功能来模拟线上环境。常用的方式是把后端服务跑在局域网中，前端把请求地址指向局域网 IP，同时打开开发者工具"不校验合法域名"，就能正常联调。但要注意，手机真机预览时，手机和电脑必须在同一网段，否则局域网地址访问不通。如果你用云开发环境，这个问题会简单很多，可以直接使用云函数内网地址，不需要配置额外域名，这是云开发的一个优势。

由于开发阶段频繁改动接口，我还用了基础的数据 mock 方案。WorkBuddy 可以直接在项目里生成一个mock目录，里面放goods.json、user.json等模拟数据文件，前端请求在开发环境下走 mock 数据，生产环境切换为真实接口。这样做的目的是让前端逻辑不依赖后端完成度，工作可以并行推进。实际体验下来，项目节奏舒服了很多，后端接口延期的情况下前端也能正常开发。

4.2 真机预览与体验版配置

开发者工具模拟器毕竟不是真实环境，很多问题只有真机才能暴露。我平时习惯在开发中频繁使用"预览"功能生成二维码，用手机扫码后进入真机环境测试。

真机环境暴露最多的是网络层和授权弹窗的问题。比如在开发者工具模拟器里，用户授权弹窗会自动出现；但真机上如果之前拒绝过授权，按钮会一直无法触发授权流程，除非用户删除小程序重新进入，或者在设置页面重新打开授权。这不算 bug，但首次开发时会困惑。WorkBuddy 生成的授权代码里没有处理"用户拒绝授权后的引导"逻辑，我后来手动加了一段，判断用户主动拒绝后弹出提示，引导用户去设置页打开授权。这段逻辑在上线后挺重要的，因为它直接影响用户转化。

体验版的功能也不可跳过。我每次准备提审前，都会把代码上传到微信后台，设为体验版，再邀请几个同事扫码测试。体验版是真实线上环境，域名校验和接口请求规则跟正式版完全一致。我在体验版测试时发现了一个发布后才会有的严重问题：首次进入小程序时，登录请求和商品请求并发发出，但商品请求依赖登录后获得的 token，导致商品接口返回 401。开发者工具里没出现这个问题，因为本地登录逻辑走的是 mock token。

修复方法其实简单，把商品请求放到登录成功后的回调里，或者在前端封装请求拦截器，统一等待 token 就绪后再发业务请求。虽然问题本身不难，但只在体验版里才能复现，这让我意识到，模拟器和真机之间还是有明显差异，测试环节不能省。

4.3 提审上线的具体操作流程

小程序开发完了，不代表能立刻上线，提审过程也是必须认真对待的环节。我第一次提交审核时就经历了一次驳回，原因是首页底部导航菜单在部分 Android 机型上有点击无响应的问题。我在模拟器上测了很多遍都没复现，后来借了一台低端 Android 手机测试，才发现是自定义导航栏高度计算在低分辨率屏幕下溢出，导致底部点击区域被遮挡。问题修复后重新提交，第二天就通过了。

提审的具体操作流程分这几步：在微信开发者工具点击"上传"按钮，填好版本号和项目备注，然后在微信公众平台后台的"版本管理"中找到开发版本，点击"提交审核"。提交时需要填写审核备注，我通常会把"该小程序面向用户的主要功能、测试账号或说明"写清楚。如果你的小程序需要登录才能使用，审核人员可能因为没有测试账号无法体验全部功能，这种情况最好在备注里说明，或者开通一个游客模式接口，方便审核人员走通流程。

类目选择也需要注意。我做的电商小程序选择的是"电商平台"类目，需要提供相关的资质文件，包括营业执照信息。如果你做的是工具类小程序，类目选择不当也会被拒。我身边有人做本地生活类小程序，选了"生活服务"类目，但实际内容更接近"电商"，审核时多次要求补充资质材料，折腾了快一周还没过。所以类目可以先参考同行小程序，再结合自己的业务范围去选。

拿到审核通过通知后，就可以在后台提交发布。从提审到正式发布，一般是一到三个工作日，如果遇到节假日可能会更长。发布按钮点击之后，小程序也不是立刻全量生效，微信会有一个灰度发布的比例选择，一般默认全量发布即可。我这次整个流程走下来，从代码上传到正式上线用了差不多两天，大多数时间都是在等微信后台的审核队列。

5. 常见问题排查与避坑经验汇总

5.1 高频问题的定位思路和解决办法

开发过程中总有一些问题反复出现，我把我在这个项目里遇到最多、网上也问得最多的情况汇总成一张速查表，方便你直接对照排查：

这张表我给团队里另一位前端同事也看过，他后来做一个工具类小程序时直接对照排查，省了很多时间。这里要特别强调一点：问题出现时，先看微信开发者工具的控制台和学生警告，很多崩溃原因是生命周期写错、API 不存在或者参数类型不匹配，控制台里都有明确提示。不要一上来就怀疑 UI 问题，先确认逻辑层是否正常。

5.2 WorkBuddy 生成代码的常见“AI 坑”

WorkBuddy 自动化程度虽高，但它生成代码时有一些典型弱点，我这里抽几个最实用的经验分享。

第一个坑是它容易生成重复代码。同一个购物车操作方法可能在多个页面里各写一份，而不是抽成公共模块。这种代码运行没问题，但维护迭代时很疼。我在检查时发现它生成的页面里有两份几乎一样的addToCart函数，后来手动把方法挪到了 store 工具文件里，页面通过调用 store 方法实现，代码清晰度提升了一个台阶。

第二个坑是它对微信 API 版本的把握有时不准。小程序基础库更新很快，一些老接口已经废弃，但 WorkBuddy 的训练数据里可能还有旧用法。我特意把它生成的wx.login调用代码和当前官方文档核对了一遍，发现它用的是wx.login的旧回调写法，而基础库新版推荐的是 Promise 风格。我让它按 Promise 风格重构后，整体代码与现代 IDE 的语法提示适配更好，后续维护也轻松一些。

第三个坑是它对加密和敏感数据处理的意识不够强。它生成的后端代码里，曾直接把session_key存到数据库并用明文返回前端，我后来手动改为服务端专用字段，禁止任何对外接口返回。这一点如果你也是用 AI 辅助后端开发，一定要盯紧。微信官方对用户数据安全的要求很严格，一旦检测到敏感信息被明文传输，轻则警告重则封禁接口权限。

第四个坑是测试覆盖不足。WorkBuddy 生成的代码不会自动写单元测试，也不会帮你做场景覆盖。我在交付前专门列了一个人工测试清单，把登录、加购、下单、支付回调、取消订单这些核心链路全部手点了一遍。尤其是支付流程，由于微信支付涉及商户号配置，WorkBuddy 没法替你完成真实支付测试，所以支付相关逻辑必须自己重点检查。

5.3 我的实操经验和交付心得

这里分享一下我对这个工作流程的整体评价。用 WorkBuddy 做小程序，正确的心态是把它当成一个能力很强的初级工程师，而不是一个能完全取代开发的引擎。它能帮你完成大量基础代码和模式化页面，但架构设计、安全审查、兼容性试验和业务逻辑验证仍然需要你自己把关。

在节奏上，我会把整个项目分成四个阶段：初始化阶段只搞定工程骨架；功能阶段按业务模块一步步让 WorkBuddy 生成代码并验证；联调阶段把所有接口打通、统一处理异常；提审阶段重点跑真机、体验版和审核备注。每个阶段都设置明确的结束标准，过程是可控的。

我还用 WorkBuddy 生成了一个简单的自动化脚本，用来批量检查项目里是否存在需要修改的硬编码参数。比如 AppID 是否写死、后端接口地址是否还是局域网地址、调试专用 mock 开关是否还开着。这些如果遗漏了，轻则提审失败，重则发布后线上直接跑不通业务，在提审前用脚本扫一遍就安全多了。

从最后结果来看，这个用 WorkBuddy 做的小程序不仅在规定时间内上线了，后续一个月的迭代里我也没有重写核心逻辑，整体迭代效率还不错。我个人的体会是，AI 协作式开发并不会让程序员变得不重要，反而对开发者的判断力要求更高了。你要能分辨出 AI 生成的哪段代码需要保留、哪段需要重构、哪些地方存在隐私合规隐患。带着这种审核意识去用 WorkBuddy，它才能成为真正的效率工具。

最后再分享一个小技巧。如果你也希望 WorkBuddy 生成的代码更规范，可以在项目根目录放一份自定义的编码规范文件，比如标明"所有网络请求必须封装在 utils/request.js 中""页面跳转必须使用 wx.navigateTo 且避免页面栈过深""不得在页面中直接编写 SQL 语句"等。WorkBuddy 会优先参考项目内的编码规范来生成代码，这个习惯一旦养成，生成出来的代码能省下大量的 code review 时间。