企业官网建设流程全解析

说实话，我刚听到“7天用AI做一个工具箱微信小程序”这个需求时，第一反应是：这有点猛。但冷静拆解一下，这个组合恰恰是目前个人开发者上手小程序最正确的打开方式之一。工具箱类小程序的核心特点是功能独立、边界清晰、不需要用户体系，而AI最擅长的就是模块化代码生成。你不需要完整学会小程序开发，只需要会拆需求、能读懂报错、会验收代码，7天从0到提审，完全跑得通。

这篇内容我会把我真实操作过的流程、踩过的坑、以及AI辅助开发时的提示词模板、代码结构、审核注意事项全部梳理出来。适合三类人看：一是想快速给自己做个作品集的新手开发者，二是想验证某个工具类想法的产品经理，三是被各种教程绕晕、想直接跑通一遍完整上架链路的人。

1. 为什么说“AI+工具箱”是新手的正确打开方式

1.1 工具箱类小程序天然适合AI辅助开发

工具箱类小程序有三个非常明显的特征，恰好和AI生成代码的优势高度匹配。

第一，功能独立性强。一个工具箱里塞着随机数生成器、时间戳转换、JSON格式化、二维码生成、色值转换等等，每个工具都是“一页一功能”，相互之间没有复杂的状态流转。你可以把每个工具当作一个独立小项目发给AI，生成完合入主工程就行，不用让AI去理解一套庞大的业务架构。这种“可切块的代码生成”就是AI最舒服的干活方式。

第二，模板代码占比高。首页、列表页、工具结果展示页，这些页面长得很像，无非是按钮、输入框、结果区域、复制按钮、历史记录。AI生成这类UI模板几乎零失误，你只需要稍作修改就能复用。工具箱项目的代码重复率极高，前期让AI多生成几套，后面抽成组件就非常快。

第三，无后端依赖。绝大多数工具类功能在前端本地就能完成计算，比如生成随机数、时间戳换算、文本加密、二维码生成。没有后端意味着你不用买服务器、不用配域名、不用担心接口挂了，上线门槛直接降到最低。我在实际开发中甚至觉得，工具箱类小程序是所有小程序类型里最适合“个人开发者+AI”的组合，没有之一。

1.2 7天计划的核心意义：先跑通链路，再谈打磨

很多人做小程序死在第一周，因为想一次做到尽善尽美。7天规划的价值在于强制你接受“最小可用版本”：先用7天时间跑通“注册开发者账号—搭建工程—AI生成功能—真机预览—提交审核—上线”这条完整链路。链路通了，后面加新工具就是复制粘贴的体力活。

我见过太多朋友学了两三个月小程序课程，还没注册开发者账号。其实注册完账号、下载开发者工具的那一刻，你才真正进入“做产品”的状态。7天计划本质上不是做一个多么完美的产品，而是把“想法到上架”这条链路完整走一遍，这个链路经验的价值远超过工具箱本身的功能价值。

技术栈上我再多说一句：只做微信端，优先使用原生小程序开发，也就是WXML + JS + WXSS。不要一上来就选uni-app。不是说uni-app不好，而是AI在原生小程序上的训练语料最充足，生成代码的准确率更高。我用uni-app测试过几次，AI偶尔会把小程序API和Vue生命周期混在一起，排查成本反而更高。既然目标是7天跑通，就用AI最熟悉的原生方案，别给自己加戏。

2. 七天实战计划：从立项到提审的全流程拆解

2.1 第一天只做一件事：锁死范围

第一天最重要的不是写代码，而是做减法。

你要列出一批候选工具清单，然后砍到只剩5到8个。为什么是这个数量？太少了页面显得空，提审观感不好；太多了7天内根本做不完。AI辅助下，一个工具从生成到调试，顺利的话需要4到6小时，不顺利可能要一个晚上，6个工具已经接近7天计划的合理上限。

我推荐的第一批工具组合是：随机数生成器、时间戳转换、日期天数计算、JSON格式化、色值转换、二维码生成。这6个工具覆盖面广、展示效果好、实现难度有梯度，适合给审核人员和围观朋友演示。

第一天还有一件不能漏的事：申请小程序AppID，个人主体即可。注册流程在微信公众平台官网就能完成，身份证认证后立即开发，别卡在这个环节。小程序类目可以暂选“工具-效率”，后续提审前再确认细节。

2.2 第二到第五天：让AI批量产出功能模块

这四天是核心产出期，策略是“每天批量处理1到2个工具”。

每做一个工具，单独给AI发一次需求，不要一次性把整个工具箱的需求都丢给AI。我之前贪快试过一次性描述6个工具，AI生成了一大坨代码，页面互相耦合，报错都看不懂，最后全部推翻重来。正确做法是切块：一次只描述一个需求，得到代码后自己读一遍，合入项目，跑一下真机预览，确认没问题再做下一个。

给AI下需求时，建议固定一套结构：身份设定、交付物说明、功能描述、技术限制、UI要求。我后文会写一个完整的提示词模板，照着改就行。第五天结束前，6个工具都应该能独立跑通。

2.3 第六天到第七天：联调、提审与兜底方案

第六天做“真实环境检查”。把小程序设置为体验版，二维码发给三个朋友，让他们分别在iPhone和安卓上试玩。收集的核心信息不是“好不好用”，而是“哪里不能点、哪里闪退、哪里样式乱了”。工具类页面逻辑简单，一般不会有严重的隐藏bug，但不同机型的样式差异和输入框行为差异一定存在。

第七天提审。个人主体需要准备一份隐私保护指引，如果工具不涉及收集用户信息，就如实说明“本小程序仅在本地处理数据，不收集任何用户信息”。提交审核时填写的功能描述要写得具体一点——不要只写“工具箱”，而是写清楚“提供随机数生成、时间戳转换、JSON格式化等多种实用工具，所有处理均在本地完成”。

这里额外提醒一件事：微信小程序每年有年审流程，过了有效期还没年审会被暂停服务。建议在手机日历里设置重复提醒，避免上架后突然被暂停搞个措手不及。

3. 零基础实现一个工具模块：随机数生成器全案例

3.1 先把需求拆成AI能理解的语言

很多新手给AI下需求时习惯写“帮我做一个随机数工具”，信息量太低了，AI只能自由发挥。你需要先把需求拆成具体的交互要素，再交给AI。

以随机数生成器为例，我建议先自己列需求要点：

• 页面包含两个输入框，分别填写最小值和最大值
• 点击“生成”按钮后，在结果区域显示一个随机整数
• 结果支持一键复制
• 保留最近10次生成记录，存入本地缓存
• 页面有清空记录的入口
• 样式简洁，对齐微信设计规范

把这些要点逐条列出后，AI对功能边界的理解就会清楚很多。好用的AI提示词本质上就是“结构化需求”，你给它喂的信息颗粒度越细，它输出的代码越接近可以直接运行的状态。

3.2 提示词模板：让AI一次写对少返工

下面这个模板我实际用了很多次，命中率很高，你直接复制改一改就能用：

你是一名资深微信小程序原生开发者。请帮我生成一个随机数生成器页面，文件路径为 /pages/random/index。 功能要求： 1. 页面顶部是标题“随机数生成器”。 2. 中间区域有两个输入框，分别用于输入最小值、最大值，需做数字类型校验。 3. 点击“生成”按钮后，在区结果显示一个介于最小值与最大值之间的随机整数。 4. 结果区域下方显示最近10条生成历史记录，最新记录排在最前面。 5. 每条历史记录右侧有一个复制按钮，点击将结果复制到剪贴板。 6. 提供“清空历史”链接，点击后清除所有历史记录。 7. 历史记录使用 wx.setStorageSync 保存，key 为 random_history。 技术要求： - 使用原生微信小程序语法，不使用第三方库，不使用 TypeScript。 - 使用 rpx 作为尺寸单位，样式简洁，接近微信原生设计风格。 - 输出四个文件的内容：wxml、wxss、js、json。

这个提示词的关键信息点有三处：明确文件路径、明确交互细节、明确技术限制。AI拿到这样的提示词后，输出大概率是完整可运行的，不需要大改。

3.3 二次对话与代码合入：验证比生成更重要

AI生成代码后一定会有些小问题。我的经验是：不要指望它一次写对，但它的基础结构通常是可用的，你只需要针对报错和边界情况做修补。

最常见的三个问题：

• 输入框为空时点击生成，程序直接崩溃
• 历史记录顺序是正序，最新记录排在最底下
• 复制功能漏写了反馈提示

这时候不需要自己看代码，直接把报错信息或现象描述贴回给AI，比如“点击生成按钮后控制台报错：Cannot read property 'length' of null”，AI会给你修复代码。整个工作流是：AI写代码，你负责读报错、验收、再反馈，循环两三轮，一个工具就稳定了。

历史记录的核心逻辑其实很简单，AI生成后你最好自己看一遍，这段代码不长，能看懂一部分逻辑对后续维护会很有帮助：

// 读取历史记录 let history = wx.getStorageSync('random_history') || []; // 插入最新记录到头部，并截取前10条 history.unshift(newItem); history = history.slice(0, 10); // 写回缓存 wx.setStorageSync('random_history', history);

4. 工具类小程序绕不开的四个技术点

4.1 wx.request封装与全局错误处理

纯工具类小程序大概率用不到网络请求，但如果你后续想接入AI翻译、图片识别这类云端接口，就一定要先做一层请求封装。我不建议把请求逻辑散落在各个页面里，AI生成的代码经常在页面里写多个wx.request，一旦接口报错，排查起来非常痛苦。

我用的封装比较简单，基于Promise包一层，统一处理状态码和错误提示：

function request({ url, method = 'GET', data = {} }) { return new Promise((resolve, reject) => { wx.request({ url, method, data, header: { 'Content-Type': 'application/json' }, success(res) { if (res.statusCode === 200) { resolve(res.data); } else { wx.showToast({ title: '请求失败，请稍后重试', icon: 'none' }); reject(res); } }, fail(err) { wx.showToast({ title: '网络异常，请检查网络', icon: 'none' }); reject(err); } }); }); } module.exports = { request };

页面里使用的时候，直接request({ url: 'xxx', method: 'POST', data: {...} }).then(...)就行。封装的意义不只是代码好看，而是全项目只有一个地方管理错误提示，后续接新工具时不用重复处理。

不过我也要泼一盆冷水：工具箱类功能优先做本地计算，能不上网就不上网。本地计算的好处是响应快、离线可用、审核风险低。一旦依赖云端接口，内容合规、接口稳定性、费用问题都会变成新的负担。

4.2 数据缓存：不是所有东西都该存

wx.setStorageSync是工具箱项目最常用的API，但很多AI生成的代码会把所有东西都往缓存里塞。需要明确的是，小程序本地缓存上限是10MB，存多了不仅性能下降，还可能出现诡异的“看不到数据更新”的问题。

工具箱里适合存缓存的数据类型主要是三类：历史记录、用户偏好设置（比如是否开启震动反馈）、草稿输入（比如用户正在编辑的长文本）。不适合存的是：图片base64、从接口拉取的大列表、不设过期时间的业务数据。

这里特别说一点“设置缓存时间”的诉求。很多人问缓存要不要设过期时间，我的答案是：工具箱里的缓存一定要带时间戳。你在本地缓存里存数据时，额外存一个expire字段，读取时判断是否过期。举个实际场景：色值转换工具生成了历史记录，下个月你给工具增加了新算法，旧的历史结果如果还展示出来，用户一眼就会觉得数据不对。带上时间戳的缓存读取逻辑，可以让我随时判断“这批结果已经过期了，不展示旧格式数据”。这个习惯能帮你规避很多隐蔽问题。

4.3 页面数据驱动的正确姿势：setData别瞎用

AI生成代码里最常见的性能问题就是setData乱用。我见过AI生成了这样的代码：在循环里不断setData，渲染几千条历史记录时直接把页面卡死。学会了小程序的道理再去看AI的代码，你会省很多心。

setData的规矩就三条：

• 只在数据变化时调用，不要在页面加载时反复同步相同数据
• 尽量使用路径更新，不要整个对象塞进去
• 大列表要分片渲染，不要一次性set所有数据

路径更新的写法是：

this.setData({ 'history[0].value': '123' });

这样只更新对应字段，页面不会重新渲染整个列表。长历史列表的处理我后文还会讲，这里先记住一个原则：小程序页面卡顿，绝大多数不是微信的锅，是开发者把太多数据一次性塞给了setData。

4.4 组件化改造：AI生成的代码怎么复用

第七天结束后，你很自然会觉得自己有个能跑的工具箱了，但代码里一定有大量复制粘贴。AI生成第一版时，每个页面都是独立的，公共样式和交互逻辑重复度极高。我建议第五天或第六天专门抽时间做一次组件化改造，把公共UI抽成组件。

最值得抽的组件是“结果复制卡片”：一个灰色的圆角卡片，里面是结果文本，右下角一个“复制”按钮。这个组件在随机数工具、时间戳工具、JSON工具里都会用到。抽成组件后，新建工具页只需要在wxml里写一行组件引用。组件目录结构类似这样：

components/ copy-card/ copy-card.js copy-card.wxml copy-card.wxss copy-card.json

组件的js里需要自定义事件，通过triggerEvent把复制内容传给父页面：

// copy-card.js Component({ properties: { text: { type: String, value: '' } }, methods: { onCopy() { if (!this.data.text) return; wx.setClipboardData({ data: this.data.text, success: () => { this.triggerEvent('copied', { text: this.data.text }); } }); } } });

组件化的好处在后续新增工具时才会真正体现。假设你上线后想加第7个工具，页面结构直接复用组件，新增成本会降到1小时以内。

5. 提审与实操避坑：审核红线、兼容性与异常处理

5.1 类目选择、隐私协议与功能合规边界

个人开发者提审最容易忽视的是类目选择和隐私协议，工具箱概不能例外。个人主体的小程序，类目选“工具-效率”最稳妥，类目描述里要如实写清楚功能用途。审核人员看到“工具箱”三个字，通常会重点关注界面是否完整、功能是否可跑、是否涉及敏感信息。

关于隐私保护指引，这里要强调：即使工具不做登录、不收集任何用户信息，也要在提审时如实填写并提交隐私协议。平台现在对隐私合规查得很严，不填写隐私协议被拒的案例比比皆是。如果工具确实不收集信息，就选择“不涉及收集用户信息”的选项，如实描述即可。

这里必须谈一个更重要的边界问题：工具箱类项目虽然好做，但有些功能不要碰。个人开发者不要做身份证识别、人脸分析、医疗建议、投资收益计算这类强资质要求的功能。这些领域要么需要特殊资质，要么容易被误判为违规收集个人信息。一旦做了这类功能，审核被拒是小事，账号被限制或封禁就麻烦了。想做AI能力相关的场景，优先选择文本处理、格式转换、图像裁剪这类不涉及隐私数据的安全场景，合规成本最低。

5.2 顶部导航栏高度适配与iPhone机型兼容

工具箱页面如果全用系统默认导航栏，不会遇到高度适配问题。但如果你想让页面更精致，把顶部导航栏自定义化，就要处理不同机型的导航高度差异。

正确的获取方式不是写死某个像素值，而是通过胶囊按钮位置来反推。调用wx.getMenuButtonBoundingClientRect()拿到胶囊按钮的尺寸和右上角坐标，再结合系统状态栏高度，就能算出导航栏实际高度。兼容写法的核心思路是：不同机型的胶囊按钮坐标不同，导航高度跟着胶囊位置动态适配。不过我的建议是工具箱第一版不要做自定义导航，用系统默认导航省掉一批适配问题，等项目成熟后再考虑个性化。

iPhone机型上还需要留意输入框的聚焦和键盘遮挡问题。比如在时间戳工具里，用户输入数字后键盘弹起，页面是否自动往上顶、结果区域是否被遮挡，这些都要在真机上逐一验证。AI生成的代码在开发者工具里看着很正常，真机上可能就有键盘遮挡的体验问题，务必用互通体验版测一轮。

5.3 审核被拒的常见理由与应对

工具箱类小程序被拒的理由相对集中，你可以先自查一遍再提审：

被拒后不要反复硬提，逐条看拒绝原因，解决后在“重新提交”时写清楚修改说明。微信审核一般会在1到7个工作日内出结果，预留好这个时间窗口。

6. 从“做出来了”到“好用了”：六个细节习惯

6.1 复制结果后必须给反馈

工具箱里最高频的操作就是“复制结果”。如果用户点完复制按钮后没任何反馈，他会下意识再点一次，然后觉得是不是坏了。wx.setClipboardData本身会弹出系统的“内容已复制”提示，但样式比较生硬，你可以自己在成功回调里做一个轻量反馈，比如页面顶部浮出一个“已复制到剪贴板”的tag，0.8秒后消失，UI更可控，体验也更好。

6.2 空状态不要留白

AI生成的代码最常忽略空状态。历史记录为空时，页面直接留白，用户会觉得功能是不是不完整。在最常见的场景里加上空状态文案：“暂无历史记录，先使用一次工具吧”，配合一个简单的插画或图标，整体观感会提升一大截。所有涉及列表的页面都要检查这一点。

6.3 长列表的加载更多思路

工具类项目如果做历史记录，很容易遭遇长列表问题。比如用户用了一个月的随机数工具，历史记录可能有几百条，一次渲染全部记录一定会卡。

我用的方案是分段渲染：页面保存一个limit变量，初始只渲染前50条，当用户滚动到底部时再加载下一个50条，或者提供一个“加载更多”按钮。列表数据始终只向setData传递需要展示的那一段，而不是全量历史。在工具箱这种场景里，没人会去翻第100条随机数记录，所以加载到100条封顶也完全够用。

6.4 离开页面保存输入状态

这是工具箱项目里很加分的细节：用户在时间戳工具里输入了一个时间，切出去回微信聊天，再切回来，输入内容还在。

实现方式是使用onHide和onShow生命周期：onHide时把当前输入框内容存到storage，onShow时回填。成本极低，但体验提升明显。很多人对工具类小程序的第一印象就是“它懂我”，这种小细节远胜过复杂炫酷的功能。

6.5 缓存时间戳的封装

前面提到缓存要带时间戳，这里直接给出一个简便可复用的封装：

function setCacheWithExpire(key, value, expireSeconds) { const wrap = { value: value, expiredAt: Date.now() + expireSeconds * 1000 }; wx.setStorageSync(key, wrap); } function getCacheWithExpire(key) { const wrap = wx.getStorageSync(key); if (!wrap || !wrap.expiredAt) return null; if (Date.now() > wrap.expiredAt) { wx.removeStorageSync(key); return null; } return wrap.value; }

工具箱里很多“规则可能变化”的功能都可以用这套逻辑。比如色值转换的公式如果升级了，历史记录在7天后自动过期，不会出现新旧公式混用的奇怪局面。这也是我在第4章提到的“缓存时间设置”实际落地方案。

6.6 数据埋点：知道用户在用哪些工具

这可能是7天项目里最容易被忽略的一步，但它可能是长期运营中最有用的一步。工具箱类小程序的增长逻辑很明确：工具越多越丰富、常用工具越靠前越顺滑。而“常用工具”的判断不能拍脑袋，要靠数据。

上线后建议给每个工具页的访问和复制行为做简单的埋点统计。埋点可以用wx.reportEvent，也可以自己封装一个统一的统计方法，上报到自己的日志服务。有了数据后，就能把高频工具调整到首页前三位，低频的移到折叠区域。这个动作听起来简单，但对后续留存和口碑传播的影响非常大。

我自己做下来的体会是：AI辅助开发7天工具箱，最大的价值不是那个能跑的小程序，而是你第一次亲手走完了“想法到上架”的全流程。这段路走完之后，AI对你来说就不是一个聊天窗口，更像一个随叫随到的初级组员，你负责判断方向、验收质量、兜住边界。最后再分享一个真实的小技巧：每次让AI生成的代码，单独归到一个“tool_code_lib”文件夹里，不要直接从上一个工具页面复制到下一个。下次要做新功能，拿着这个文件夹里的提示词重新生成版本，再和现有代码做对比，你往往能得到一份比上一版更干净的实现。