用 AI 从零做出一个能上线的微信小程序

（以"嵌入式计算工具箱"为例，一篇给新手的方法论）走一遍从需求到提审的完整流水线，把最容易翻车的"白屏危机"掰开揉碎讲清楚。

我前阵子用 AI 搭了个微信小程序，从零到提审断断续续大概跑了十来天。这篇就当把整个流水线和那些坑都讲一讲，给想用 AI 做小程序的你省点时间。

你不用是前端高手。我基本上也不会，主要就是会"把需求说清楚、让 AI 写、自己把关"。这套方法比会写代码更值钱。

读完你能得到两样东西。一是个真能提审的小程序思路，二是套能复用的 AI 协作纪律。

1 先想清楚要做什么

AI 不会替你想需求。你先得用大白话把想法说出来。我当时就一句："做个嵌入式工程师用的小工具，能查寄存器、查引脚、算点常用的东西。"

把这句话丢给 AI，让它拆成功能清单。它会给你列一堆：计算类（进制转换、位运算、定时器分频）、参考数据类（寄存器映射、引脚图、通信协议速查），再加搜索和收藏。这就是你的功能树。

新手最容易栽在类目上。微信对个人主体（也就是你用自己身份注册，不是公司）有很多红线。小说、社交、游戏这些个人基本过不了。我选的是"工具 > 效率"，稳。这一步一定先定，不然后面做完了卡类目就白干。

接着让 AI 帮你出一份设计文档。不用多正式，把页面有哪些、数据从哪来、隐私怎么写说清楚就行。这份文档是后面跟 AI 对话的"地基"，省得每次从头解释。

给 AI 写需求有个窍门：别写"做个好用的小程序"。要写"做三个页面，页面一显示芯片列表，点进去显示寄存器表格，支持搜索"。越具体，它越不跑偏。

2 让 AI 出架构，你拍板

小程序长什么样，AI 能给你一套标准目录。最外层有全局配置（管页面路由和窗口样式）、页面文件夹（每个页面一屏）、组件文件夹（能复用的小零件）、还有放业务逻辑的服务层。

给新手翻译一下这几个词。页面就是你在微信里看到的一屏。组件是把多处要用的界面块单独抽出来，比如一个卡片。服务层是放"怎么取数据、怎么存收藏"这种公共逻辑的地方，页面只管显示。

这里有个我踩死过的坑，先说免得你重蹈。微信里那些配置文件（点开是花括号那种）是不能当代码模块引进来用的。你想在程序里读一份数据，得把它写成真正的代码文件，用"导出再引入"的方式。我们项目里专门写了个小工具，从数据原稿生成这种代码文件，原稿留着、生成物别手改。这条现在看是常识，当时可是白屏排查了好几轮才搞明白。

架构上还有个思路：把"算东西的逻辑"和"查的参考数据"分开。计算工具是纯逻辑，寄存器引脚是数据。分开后数据错了好单独改，逻辑也清爽。

体积也得盯。主包别超两兆，大了传不上。功能多就用分包。我们整个包才零点几兆，远远没到上限。

3 数据是最容易翻车的地方

做参考数据类功能，数据准不准直接决定工具有没有用。我这个项目里，芯片引脚表就是数据最集中的地方。

先说正确姿势。数据从源头整理好（官方手册之类），写成数据原稿，再用那个小工具生成代码文件。生成之后跑个校验脚本，确认格式没歪。

然后说坑点。我们的引脚表，核对官方手册才发现，四十八个脚全标错了位置。还凭空多出了这个封装根本不存在的脚，又把电源脚和启动脚给漏了。要不是写了个比对脚本对着官方手册一行行对，上线后别人照着接线能接出事。

所以给新手一句忠告：凡是涉及专业数据，一定找权威来源对照，最好写个自动比对。AI 整理得再顺，也可能把大封装的脚号抄到小封装上。它不知道，你得知道。

4 分模块写，边写边真机看

功能别一口气全写完。一个模块一个模块来。我们做了寄存器速查、引脚互查、统一搜索、收藏这几块。

寄存器那块，让 AI 写页面：上面选芯片，中间选外设，下面展开寄存器位定义，还能搜。引脚那块用了个画图组件，把芯片脚位画出来，点和表能互相跳。

搜索和收藏是打通的。搜索结果点进去要能直接定位到对应芯片；收藏要跨页面都认。这些让 AI 写服务层，你只管说清"要跨页面、要带芯片参数跳转"。

给 AI 写页面有个模板：先说这页干嘛，再说有哪几个元素，每个元素点下去干什么。比"写个好看的页面"强十倍。

模块写完一个，就上真机点一遍。别等全部写完才测，那时候出问题你都不知道是哪个模块惹的祸。具体踩过什么大坑，下一章单说。

5 白屏危机：修了好几次，一次比一次糟

这是我做这个小程序碰到的最大一个问题，重点说一下。

白屏是什么。你点开小程序，屏幕一片白，啥也不显示。模拟器上可能还好好的，一上真机就白。最要命的是它不报错，就干瞪眼白着。

我们的白屏，根子出在数据文件的引入方式上。先普及一个基础知识：程序要读一份数据，得用"引入"把那份数据拉进来。微信里有些配置文件点开是花括号，但那些文件在微信眼里只有配置语义，打包的时候它不把这种文件当成能引入的代码模块。你要是写了"引入一个花括号文件"，真机上这份模块根本没被登记，于是依赖它的整个页面加载失败，白屏。

问题是我们当时不知道这条规则。于是开始了漫长的瞎修。

第一轮，我们猜是打包时把"看起来没用"的文件丢掉了。有个构建选项管这事，我们就去翻它、改它。改完发现白屏没好，反而有的页面也开始白了。因为文件压根不是被误删，是压根没被当成模块，你翻选项只是在决定丢哪个，根子没碰。

第二轮，我们盯上子包。数据放在子包里，是用一个会变的路径去引入的（路径不是写死的，是拼出来的）。微信打包只能认写死的引入路径，变来变去的路径它分析不了，模块就打不进去。我们就在子包引入上折腾，挪来挪去。结果白屏还在，还因为叠了半拉修补更乱了。

第三轮，我们想，是不是子包不行，搬到主包试试。把数据模块挪进主包。还是白。因为"花括号文件不能当模块"跟它在主包还是子包没关系。这下主包还变大了，白屏照旧。

第四轮，我们发现失败发生在顶层引入，也就是页面一加载就执行的那种。顶层引入一旦失败，整个页面模块就废了，连降级显示都没有，直接白。我们给引入加了兜底、加了判断。这下白屏是不直接炸了，可数据还是空的，真问题一个字没碰。等于把脓包捂住了。

你看，四轮下来，一次比一次糟。每轮都在不同的层上打补丁：构建选项一层、子包路径一层、包位置一层、兜底一层。没有一轮去问"到底什么才算一个能引入的模块"。我们一直在现象的皮上挠，没碰到肉。

此时我判断 AI 走进了死胡同，大概率排查的方向不对。因此我换了一个方式，让它全面核查代码，不再这个错误方向上深究。于是 AI 想通了：这四轮看起来不一样，其实是一个毛病换了张脸。都是"把花括号文件当代码模块引入"这件事的不同表现。打包器从不把花括号文件编成可引入的模块，真机上"引入花括号文件"就是登记不上。前面那些修法，无非是把这张脸换了个位置。

真正的修法，是把数据换成真模块。我们定了一条规矩：花括号文件只当源数据留着（人能改、好维护），再写个小工具，从这份源数据生成真正的代码文件（里面就是"导出这份数据"一句话）。页面和服务统统去引入生成出来的代码文件。打包器认代码文件，引入就通了，页面就起来了，白屏没了。

这条规矩现在成了我们项目的铁律：花括号文件在微信里只有配置语义，绝不当数据模块引入；要引数据，引代码文件。

给新手一句掏心窝的：真机白屏，八成是某个模块没加载出来。先问自己两个问题，引入路径对不对，引入的文件类型对不对。更关键的是，修第一次没找着根因，就别急着在另一层打第二补丁。停下来，重新想清楚这个平台"什么才算模块"，比连猜四个层管用得多。我们那四轮，就是没停，硬把小坑刨成了大坑。

6 收口，建几道自动门禁

写完别急着交。让 AI 帮你写几个检查脚本，当质量门禁。

我们有五道。一是跑全套测试，二是查页面结构合法性，三是查事件绑定有没有悬空，四是查工程结构和体积，五是查数据完整性。每次改动完过一遍，全绿才放心。

关于页也得合规。功能列表、数据来源、免责声明、隐私说明，一样不能少。涉及"数据可能不全准"的，明明白白标出来，别糊弄。

最后真机过一遍冒烟清单：收藏能点、搜索能跳、关于页能正常显示。真机才是照妖镜。

7 提审，人工七步

代码稳了，剩下是微信后台的活，AI 给不了账号。

第一步注册，个人主体。第二步填类目和信息，名字图标简介按定好的来。第三步填隐私保护指引，我们纯离线不收集信息，勾那个"不涉及"就行。第四步备案，按微信引导走。第五步开发者工具上传体验版，写版本号。第六步真机再冒烟一遍。第七步提交审核，等通知。

提审有风险预判。个人主体工具类，类目别踩红线就稳。数据来源我们标得清清楚楚，反而利于过审，但审核员可能追问出处，你把官方手册准备好。

重点提醒：审核通过不等于上线。通过后得自己点"发布"。忘了这步，东西就一直躺在审核通过里。被驳回也别慌，看原因改了重提。

8 这套方法能复用

回过头看，AI 协作有几条纪律最值钱。

大任务拆小，分步跑。别让 AI 一次干一整天，你也等得心慌。

测试分级。日常小改跑针对性检查，阶段收尾才跑全量。

修 bug 别顺手扩大范围。先定位根因，再动手，改完确认真落盘。

最关键的：数据准不准，AI 补不了你的领域知识。它整理得再漂亮，专业数据你得自己对着权威来源核。我们那四十八个脚，就是这么救回来的。

写到最后说一句，小程序开发没那么玄。你把需求说清，AI 写，你把关，门禁兜着，流程走完就上线。剩下的，就是多做几个、多踩几回，自然就熟了。

本文由 kuzhang 整理