被微信拒审那天我正坐在沙发上盯着后台那条红色通知第一反应不是改代码而是“原来我在用 VibeCoding 的时候根本没有想过交付物要过审这件事”。我做的这个小程序前后折腾了三个月代码量到了3万行左右素材接近1.8万张全部是我一个人加几个AI辅助编程工具完成的。这个数字听起来很唬人但真正让我觉得自己学会VibeCoding的不是写了多少行而是被拒审后怎么靠同一个AI把问题定位、修掉、再顺利过审。这篇复盘记录的就是那三个月里的真实过程包括我是怎么把需求拆给AI、怎么管理这么多素材、又是怎么接住拒审这一脚——给打算用AI做小程序、又担心一个人搞不定的朋友一个参考。1. 从一次拒审说起这个项目到底做了什么1.1 拒审通知背后是我对交付物的误解先说一下这个小程序本身。它是一个偏工具属性的产品核心功能包括自定义卡片生成、每日任务打卡、以及一个带统计的可视化面板。听起来不复杂但因为我想把“卡片生成”做得足够灵活把“打卡统计”做得足够顺手功能越加越多最后代码量就滚到了3万行。这个量级在传统开发里一个人做大概要小半年但我当时其实只用了不到两个月就写出了第一个能跑起来的版本。问题就出在“能跑起来”和“能上线”之间差着一条审核红线。第一次提审平台返回的拒审理由写得很标准小程序的用户隐私保护指引中未完整声明涉及的用户信息处理方式同时部分页面存在内容安全机制不完善的情况。翻译成人话就是我需要先告诉平台我会收集哪些数据、用来干嘛、怎么保护但我在用户协议里写得含糊不清另外我在某些输入框里没有接入内容安全检测用户如果输入了违规文本小程序里面是直接展示的。这属于基本功没做好跟代码写了多少行没有关系。我那时候才意识到在AI辅助下把功能堆出来只是第一阶段能不能进入线上环境考验的是合规层面的完整度。1.2 什么是 VibeCoding它不是偷懒是换了一种控制方式先说清楚VibeCoding这个词。它指的是开发者通过自然语言描述需求让AI持续生成、修改代码开发者更像是在“带氛围”地和工具协作而不是逐行敲键盘。很多人会误以为这是逃避写代码或者觉得这就是“AI自动生成一个项目”但实际用下来它更像是一种新的控制方式你告诉AI“我们要做什么、边界在哪、不要碰哪块”它负责把碎片变成结构。我在这个过程里最深的体感是VibeCoding不适合没有编程基础的人直接上手也不适合完全没有产品思维的人。因为AI生成代码的速度太快了快到你还没来得及发现问题它已经写完了。如果你脑子里没有一张方案图你会完全迷失在它生成的代码里。我做这个小程序的时候方案图是先手画的流程是先在纸上拆好模块再跟AI对话一句一句让它实现某个具体函数或页面而不是上来就让它“做一个完整小程序”。这个习惯在后期救了我很多次。2. 一个人如何扛住3万行代码架构与流程2.1 把代码量变可控的第一步是先把业务模块拆干净3万行代码如果按单一仓库、平铺方式管理那不管有没有AI都会失控。所以我在项目启动时就拿到了一个“丑但有用”的方案把小程序业务拆成四层。第一层是页面层也就是用户看得到的底部导航和主页面第二层是组件层比如卡片模板、打卡日历、统计图表这些可复用的部分第三层是工具层包括请求封装、存储封装、图片压缩这些和业务无关的基础能力第四层是配置层把文案、主题色、卡片模板的参数全部集中到一个配置文件里。拆完之后AI每次只需要面对一个边界很清晰的子任务。比方说我要做一个“按周视图展示打卡连续天数”的组件我给AI的描述是“小程序的wxml中prompt一个函数接收打卡记录数组输出周视图所需数据包含连续天数计算注意跨周逻辑”它生成的代码往往可以直接用。如果我不拆直接让它生成整个页面它会把样式、逻辑、请求全部混在一起后面改一个功能就要翻半天代码。这个经验挺重要的因为VibeCoding最忌讳的就是没有边界感——人和机器都需要边界。2.2 让AI理解“整份项目说明书”而不是零散指令一个人带着AI写3万行代码最大的痛点不是代码而是“上下文”。AI聊天有窗口限制。如果你每天跟它聊十几次它早忘记你项目全貌了。我的解决方案是在项目根目录放一份“项目说明书”说明书的长度控制在大概两屏内容包括项目定位、技术栈、目录结构、命名规范、现有模块清单和当前阶段要解决的问题。我每次开新对话第一件事就是把这份说明书粘进去然后再提具体需求。这份说明书不是一次性写完的。我大概每两周更新一次比如“新增了统计模块数据字段如下storage键统一以history_开头”。这样做的好处是AI生成的代码风格会保持一致不会出现上一段用的是中文变量名下一段又冒出拼音变量的情况。而且如果我连续对话太乱导致AI答非所问我能直接开一个干净的新窗口重新把说明书的全文贴进去把当前的bug描述一遍通常就能回到正轨。2.3 3万行代码不是一次写出来的让AI成为“结对评审”我写这个项目的时候有个习惯让AI生成代码之后我会自己读一遍核心逻辑。尤其是涉及数据写入、用户隐私和支付跳转的这些地方我几乎不会直接拿AI给的代码就用。方式是把AI写好的大文件拆成几百行的小片段一段段贴回对话里要求它“以严格代码评审者的身份找出极端情况下的问题”。这个过程非常像以前在技术论坛上找人帮忙review代码但响应速度是秒级的。比如有一次它生成的打卡统计函数在“用户在同一天内修改记录再删除”的情况下会统计错乱我一共试了三个边界条件才暴露出来。AI评审给出的结论是应该把“删除”动作加一个独立的时间戳判断。这类问题如果是我自己人肉看大概率要漏掉但用AI按规则找边界效率确实不一样。3. 素材工程1.8万张素材怎么来、怎么存、怎么加载3.1 组合式素材生产1.8万张其实只有50个底图你看到“1.8万张素材”可能会觉得可怕但如果我把算法告诉你你会发现这只是一个数字游戏。我当时做的是一个自定义卡片生成器用户可以选背景风格、字体样式、插画元素和文案排版。四种维度各有一批选项理论组合数就超过了1.8万种。如果按传统的做法这1.8万张图都要预先做成资源文件那肯定不可能。我的做法是只准备了大概50张背景底图加上30种插画元素和20种文字排版模板然后写了一个自动化脚本用canvas在本地把这些元素组合渲染出来再按配置输出成不同尺寸的透明底图。这一步在技术实现上没有特别难但需要想清楚“素材的组合规则”和“运行时的加载策略”。用AI辅助写这个组合脚本的时候我尝到了VibeCoding的甜头。我给AI的描述是“用Node.js写一个批量脚本读取config.json里的组合配置使用canvas库生成PNG文件名按照category_style_element_variant.png的规则输出”。AI直接把骨架代码生成好我只需要调整字体路径和画布尺寸。1.8万张素材单机跑了大概四个小时就全部生成完毕。3.2 压缩与格式选择素材多不等于体积大生成完之后我立刻发现一个很实际的问题——素材如果不压缩2MB的小程序代码包根本装不下。1.8万张图如果每张平均50KB就是900MB这个量级连云端的下载流量都扛不住。我的处理分三层。第一层是做同质化合并很多素材只是颜色差异我把它们全部转成WebP格式把透明底图合并到一个雪碧图文件里通过CSS定位来取图。第二层是尺寸分级列表页用200px的小图预览页用600px的中图只有编辑页才加载原尺寸。第三层是瘦身脚本我写了一个简单的压缩流水线把所有生成出来的图用统一质量参数压一遍。大概有两成图片肉眼看起来完全没差别但体积直接小了一半。具体脚本我当时已经跑通了核心代码大概是启动一个本地任务node scripts/compress.js --input ./raw --output ./optimized --format webp --quality 80这个脚本遍历原始素材目录把每一张图都改成WebP格式质量参数设为80。实测下来一组原本要2.3MB的背景图压完之后只有700KB左右视觉损失基本可以忽略。这个步骤对小程序很重要因为在微信这类小程序生态里包体大小直接决定你eCode可不可以带资源文件上线。3.3 运行时策略为什么不能把素材全塞进代码包素材的加载策略是我后期才补的一个模块。我在思考“1.8万张素材”和“小程序包体限制”之间矛盾的时候才意识到真正的解法不是无限压缩而是“不要一次性加载所有素材”。小程序默认包体限制大约在2MB加上主包和分包总共也不能无限膨胀。1.8万张素材如果全部打进包里无论怎么压缩都会超限。我最终的做法是只把组合规则、配置文件、核心模板放进代码包所有预测会高频使用的素材也放一小部分其余素材全部传到云存储上运行时按需拉取再加本地缓存。用户第一次打开编辑页的时候会请求一批图片CDN预缓存的清单后续再访问就直接读缓存。这个方案在前端里很常见但用在小程序和AI协作开发里需要想清楚哪些资源必须进代码包、哪些资源可以走运行时加载。我甚至试过在服务端动态生成缩略图。后来觉得成本太高还是回到“预生成CDN”的路线。整个过程并没有用到特别高深的架构但对一个单人项目来说提前想清楚资源计划能省下后面非常大的返工时间。4. 微信拒审拆解从平台回执到可落地的整改4.1 常见拒审类别与对应策略被拒审之前我对平台审核规则的认知是“把功能做出来就好”那显然不够。从那次之后我整理了一份非常实际的小程序审核排查表在我后来复盘中反复用到。这里列一下比较常见的拒审原因和大多数开发者的对应策略你可以直接对照看。常见拒审原因表现形态整改方案类目与实际功能不符选了“工具”类目但有社交内容根据核心功能重新选择最匹配的类目并补充相关资质用户隐私保护指引不完整后台有获取手机号或位置代码但指引里没声明列出所有在代码里用到的API逐一对应到隐私声明字段强制授权一进入页面就弹窗要求授权头像昵称改为用户主动触发授权比如点击按钮后再发起内容安全能力缺失UGC输入框没接入内容检测接入平台提供的内容安全API对用户输入做识别虚拟支付合规问题安卓端存在虚拟物品购买但未走指定渠道梳理所有支付场景虚拟内容必须走平台规范或换成积分体系代码包过大/加载异常小程序长时间白屏或分包加载失败压缩资源开启按需加载确保核心页面秒开我当时踩中的是第二条和第四条。隐私声明的问题在于我在代码里用到了获取用户昵称头像的API同时启用了位置信息的接口——但我在后台的隐私保护指引里只写了“用于展示信息”没有明确说明位置信息是用在本地打卡记录上。平台的判定标准很简单代码里用了什么敏感API指引里就一定要写清楚。如果你不写就是不合格。4.2 隐私保护与用户授权最容易踩的坑所有微信小程序在提审时都会有一份用户隐私保护指引开发者需要在平台后台逐项填写你要收集哪些信息、使用目的和处理方式。我在第一次提审的时候只填了寥寥几句结果审核员在测试过程中发现我的打卡功能会发起位置授权但指引里没有对应声明因此直接判拒。后来我在整改时做了一个很机械但有效的事把用到的API列表全部打印出来再和后台的指引选项逐一核对。具体来说我全局搜索了整个项目里所有wx.get开头的调用然后逐一分类。头像昵称填写能力、位置信息、本地缓存读写等全部添加到指引。除了平台自带的那套勾选我还在用户协议里新增一段话用普通用户能看懂的方式说明数据用途。这个动作本来以为很麻烦结果在AI辅助下只花了半小时就完成。我把搜索出来的API列表粘给AI让它帮我整理一份“用户协议-数据使用说明”的文案然后我再做人工校对。改完之后重新提审隐私这块一次通过。4.3 内容安全机制这一步一定要提前接拒审回执里的另一条是“部分页面存在内容安全机制不完善”。原因其实很直接我在打卡动态的输入框里允许用户写自定义文字但没有做任何违规内容识别。平台的要求是只要你有用户输入的地方就需要有能力处理违规内容。这个能力不能只靠前端关键字屏蔽前端只能拦一部分更稳妥的是调用平台提供的内容安全接口。整改方式也很直接在用户输入完文字之后先本地做一个简单的关键词过滤同时把输入文本提交到内容安全API做异步检测。检测结果如果是“违规”就立刻显示提示并禁止发布。这个流程我一开始以为要走很久但是因为我把功能拆得很细AI只需要生成一个封装好的“文本检测”函数然后插入到表单提交的流程里。前后大概花了两个晚上就接完了。需要注意的是这个接口有频率限制所以我写了一个节流逻辑用户停止输入300毫秒后再调用检测避免每个字符都请求一次。5. 贴近实战的 VibeCoding 调试方法5.1 把报错原文“翻译”成指令是AI协作的核心能力VibeCoding不是只会提需求Debug才是决定项目生死的关键。我经历过最崩溃的情况是AI生成了一大段代码运行时报错直接卡死而我把报错信息贴回给AI它给出的修复方案引入了新的问题。后来我总结出一个模式给AI报错时不要只贴报错信息还要同时提供它之前生成的代码上下文、我期望的输出结果、以及我尝试过的处理方式。比如有一次页面白屏控制台报了一个很隐蔽的错误大概是某个组件里调用了不存在的属性。单看报错只有一行但如果我不附上上下文AI根本不知道它自己生成的那个函数命名和另一个文件里的数据字段不一致。我把相关两个文件的代码节选都贴进去然后描述“这段逻辑在打卡记录更新后应该触发统计面板重绘。现在白屏帮我在保证现有事件机制不变的前提下修正数据映射。”AI调整之后白屏问题马上就消失了。这类经验表明VibeCoding调试的核心不是“AI聪明不聪明”而是你给的信息够不够准。5.2 我常用的AI调试对话模板到了后期我几乎把所有调试都固定成一套模板。这套模板不一定适用所有人但可以当作参考框架。它分四步先说背景再说问题再说约束条件最后要求AI给出两到三个可选的方案不要只给一个。举个例子我在调打卡连续天数统计的时候是这样写的“这是一个微信小程序项目打卡记录存储在本地storage中。每条记录含打卡日期。我需要计算用户连续打卡天数如果今天没打卡而且最后一条记录不是昨天连续天数应该重新归零。请检查我下面这段函数尤其注意跨月和修改记录的情景。只给修复方案不要改其他部分。”这个指令结构比“帮我修bug”强太多了。AI能理解边界、知道你的评价标准还能在约束内工作而不是自由发挥。另一个技巧是“让AI提出反例”。我发现生成代码时问AI“这段代码可能被哪些极端输入击穿”比直接让它写代码更能暴露问题。因为在自然语言对话里让AI扮演攻击者它会主动列出边界条件通常这些边界条件是我根本想不到的。这种“反向提问”的调试方式大概是VibeCoding最接近真实团队评审的部分。5.3 人与AI的边界什么时候必须自己写AI给我节省了大量编码时间但有些代码我坚持自己手写。第一类是任何涉及真实支付和用户信息的逻辑我指的不是不让AI写而是每一行都要自己再看一遍。第二类是核心算法比如打卡连续天数的跨周计算我把AI生成的版本拿去优化了很多次到最后已经完全能看懂它每一个变量代表什么。第三类是那些层层嵌套的交互状态比如同时出现弹窗、键盘和授权引导的时候AI很容易把状态管理写乱。我给自己定的规则是AI负责全部“体力劳动”比如初始化项目、搭页面结构、生成类型定义、批量处理素材我负责“关键决策”比如数据结构怎么设计、缓存策略怎么做、哪些函数必须改成纯函数方便测试。这几条边界定下来之后AI生成代码的可用率明显提高了因为它知道你想要的不是“能跑”的代码而是“能维护”的代码。6. 三个月总结踩坑清单与独立开发者建议6.1 我踩过的五个坑第一个坑是前期没有认真做合规自查直到拒审才回头补隐私和内容安全这个代价比想象中大因为重新提审至少要等一两个工作日。第二坑是素材压缩没有一开始就设计好前期所有图片用PNG等到快提审才发现包体超标不得不用一个晚上重新批量处理。第三个坑是项目说明书没有及时更新有一段时间AI的代码风格出现明显漂移后来发现是因为对话窗口重置后它一直在用旧的项目结构描述生成新代码。第四个坑是依赖性的滥用在页面里堆了过多的第三方组件库结果框架更新后部分组件报错排查起来非常浪费时间。最后一个坑是在AI对话中一次提了太多需求我以为它能把“页面、逻辑、样式、数据请求”一次性都改了结果它改到一半就忘记约束条件反而不如拆成多个小任务。6.2 给想用VibeCoding做小程序的人的建议如果现在有人问我一个人加AI能不能做出一个能上线的小程序我的答案是可以但你要接受三个前提。第一你不能把AI当成外包团队它是个动作很快但经常需要你纠偏的同事第二不管代码怎么生成你都要具备能读懂核心逻辑的能力哪怕看不懂每一行也要能看出“这段代码可能有问题”第三合规这件事没有任何捷径在开工之前就把隐私声明、内容安全、类目选择这些基础打好比你写了3万行代码再去整改要划算太多。实操上我还推荐准备三个独立文件项目说明书、待办事项列表和测试清单。项目说明书用来维持AI的全局上下文待办列表用来拆分任务测试清单用来在提审前做逐项自查。我在拒审之后把这三份文件补上后续开发效率提高了不少。尤其是测试清单线上过审前我按清单逐项确认能明显降低那种“提交后心里没底”的状态。6.3 最后的一点私人体会做这个项目之前我一直觉得软件开发最大的瓶颈是时间不够、人手不够。被微信拒审那天以及之后几天的效率暴涨让我发现单人开发最大的瓶颈其实是想清楚目标。AI可以帮你把3万行代码写出来也可以帮你在半天内把手动压缩素材的活全部干完但它没法替你提前想清楚“平台要求什么、用户会怎么操作、哪些边角条件可能触发异常”。VibeCoding给我最深的改变不是让我变得能写更多代码而是让我学会把每一个需求拆得更小、更明确。过程中写的3万行代码和1.8万张素材某种程度上都是副产品真正的收获是那一套和AI协作的节奏拆到位、说清楚、多验证、再交出去。如果你也打算一个人做小程序我建议不要一上来就追求功能多先把一个核心流程跑通把合规底子打好然后让AI帮你把细节滚起来——这个过程会比你想的更顺利也更有成就感。