用 AI 从 0 到 1 做了一个「决策型」微信小程序:我踩过的坑和留下的架构

📅 发布时间:2026/8/6 18:29:15
用 AI 从 0 到 1 做了一个「决策型」微信小程序:我踩过的坑和留下的架构
用 AI 从 0 到 1 做了一个「决策型」微信小程序我踩过的坑和留下的架构纠结吃什么、谁请客、真心话大冒险谁上……这些场景每天都在发生。本文不是功能说明书而是一次真实的 AI 辅助开发复盘产品怎么定、技术怎么选、多人实时怎么做、以及哪些地方 AI 帮了大忙、哪些地方必须自己把关。一、先说结论AI 能提速但不能替你做产品判断2024–2025 这波 AI 写代码最大的变化不是「能生成代码」而是一个非大厂、甚至非全职前端的人也能在几周内把一个完整小程序从想法推到可上线。但我自己做下来有一条很清楚AI 擅长必须人来定脚手架、CRUD、接口样板产品边界做什么、不做什么页面结构、样式初稿交互节奏3 步内出结果Bug 定位、重构建议数据模型与权限边界文档、模板内容填充冷启动体验与传播点一句话AI 是高级结对程序员你是产品经理 架构师。二、产品从哪来不是「随机工具」是「可复用的场景系统」最开始的想法很朴素做一个随机选择小工具。但市面上转盘、抽签类小程序一抓一大把如果只做「输入选项 → 点一下 → 出结果」几乎没有留存。后来我把定位收成一句话同一套随机引擎支持「个人决策 多人互动」两种模式。拆开就是三个入口快速随机单人—— 冷启动必须丝滑3 秒出结果我的列表 / 池子—— 餐厅、任务、惩罚规则可保存复用开个局多人房间—— 拉好友一起抽支持「选人 选事」再加一层内容真心话、大冒险、谁请客、去哪玩等内置模板以及一个偏娱乐的「今日段子」入口用来降低空白页压力。产品名最终落在「局趣随机」——偏社交、偏局感而不是冷冰冰的「Random Tool」。这是一个示例名称实际项目中可根据定位调整。如果你也在做工具型小程序建议先问自己用户第二次打开的理由是什么答案如果只是「再随机一次」留存会很难看如果是「我的池子还在 / 昨晚那局还能开」路径就通了。三、技术选型小而全不追求炫技目标是快速上线 可维护最终栈如下前端UniApp Vue 3 Vite主端微信小程序实时Socket.IO 客户端房间同步选 UniApp 的原因很务实一套代码主打微信后续若要 H5 / 其他小程序端成本可控Vue 3 组合式 API 和 AI 生成代码也比较合拍。后端NestJS Prisma MySQL实时通道Socket.IO房间成员、选项、开抽结果登录微信code2session开发环境可降级 mock openidNest 的模块边界清晰AI 生成 Controller / Service / Gateway 时不容易把业务揉成一团Prisma 对表结构变更也友好。核心表简化版users —— openid 唯一自增 id 作业务主键 list / list_item —— 个人池子与选项可带 weight room / room_user / room_item —— 房间、成员、匿名/公开选项 result —— 抽选结果谁 做什么设计上刻意坚持一件事前端不自己发明用户身份。一切以服务端 upsert 后的user.id为准HTTP 带X-User-IdWebSocket 入房校验库里的真实用户。早期我踩过一个坑前端Math.random()造临时 id刷新就换人房间和列表全乱。AI 一开始也会顺着「先跑起来」写这种临时方案——能跑 ≠ 能上线身份链路必须自己收口。四、AI 协作实战我是怎么用的1. 先写「需求文档」再让 AI 写代码不要一上来就说「帮我做一个随机小程序」。更有效的提示类似做一个支持单人随机 多人房间的微信小程序。 - 单人快速输入、常用列表、内置模板 - 多人创建/加入房间、每人可加选项、统一随机可选「人事」 - 技术UniApp Vue3 NestJS Prisma Socket.IO - 约束3 步内出结果不要转盘用洗牌/卡片仪式感先做 MVP 请先给产品结构、表设计、开发优先级再写代码。让 AI先出方案、再落代码返工会少很多。2. 按模块喂不要整仓一锅炖我实际拆成的任务粒度单人快速随机页 本地/接口列表模板数据与「一键开局」用户登录code → openid → users upsert列表 CRUD 与按 userId 隔离房间 Gateway创建、加入、同步选项、开抽结果展示与分享文案每个模块给 AI 时带上已有文件路径、接口约定、禁止事项例如禁止再硬编码userId 1。3. 让 AI 做「全链路排查」比让它「再写一个功能」更值钱上线前最有价值的一次对话不是「加个按钮」而是从uni.login到users表再到房间joinRoom把用户身份链路画清楚指出断层。它会帮你发现列表接口默认userId 1房间信任前端乱传的 creatorId本地没有缓存真实 user这类问题靠人肉翻代码也行但 AI 在「跨前后端叙事」上确实快。4. 内容与文案也可以 AI 填但要人工过审真心话 / 大冒险模板、结果分享文案「今天的冤种是xxx」很适合批量生成再人工删掉低俗、违规、过火的条目。工具产品的「好玩」和「能过审」之间必须有人值守。五、几个值得单独说的技术点1. 微信登录的「有秘钥 / 无秘钥」双模式正式环境code→ 微信jscode2session→openid→ upsert。本地没配 AppSecret 时用 code 派生稳定的 mock openid保证开发期多账号、联机、数据隔离仍可测。这对个人开发者很友好——先把链路跑通再补正式配置。2. 房间状态用 WebSocket而不是狂轮询多人场景下成员进出、选项增减、开抽倒计时REST 轮询又丑又费。Socket.IO 房间维度广播足够注意入房校验 user 是否存在断线重连后的房间状态快照开抽只允许房主或约定角色触发防刷3. 体验 算法随机本身是Math.random或加权抽样就够。差异在操作是否足够短输入 → 点 → 结果结果是否有「被选中」的仪式感洗牌、翻牌而不是生硬弹 Toast结果是否可截图传播AI 默认会把精力花在「功能都有」你要主动把 PRD 写进「节奏」和「传播」。4. 小程序 独立 H5 的内容页「今日段子」这类偏内容的模块我做成可独立部署的 H5小程序里 web-view / 跳转访问方便单独迭代也方便以后接公众号。主业务随机引擎、房间、池子仍留在小程序原生页保证性能和体验。六、开发节奏建议适合个人 / 小团队结合这次实践更稳的顺序是阶段做什么刻意不做第 1 周单人随机 自定义列表 模板不做房间第 2 周登录与数据隔离、列表云端同步不做复杂权重第 3 周房间创建/加入 简单开抽不做排行榜之后匿名选项、历史倒霉榜、分享图按数据再加很多人包括早期的我会一上来就做「炫酷多人」结果单人打开都是空的——冷启动死在第一屏。七、AI 开发的边界我总结的 5 条先定产品一句话再打开对话框。身份、权限、钱、消息推送——人工设计AI 实现。生成代码后必跑真机 / 开发者工具不看「能编译」就信。让 AI 写测试用例和排查清单比让它堆功能更划算。过审文案、用户协议、隐私与 openid 使用说明AI 只能打草稿。AI 不会替你上架也不会替你面对用户第一句「这玩意儿有啥用」八、上线后的一点体感通过这个实践项目我验证了AI辅助开发在中小型项目中的可行性和边界。项目主要覆盖了以下场景一个人纠结时快速随机 我的池子一桌人起哄时开房间一起抽摸鱼时段子 / 模板整活技术上没有黑科技难的是把「随机」做成可复用的场景而不是一次性小玩具。如果你也在用 AI 做小程序欢迎在评论区交流你的第一版砍掉了什么多人实时你用的 WebSocket 还是云开发有没有被 AI「自信地写错」坑过的经典案例我的经典案例默认userId 1全员共享一个池子 技术上没有黑科技难的是把「随机」做成可复用的场景而不是一次性小玩具。如果你也在用 AI 做小程序欢迎在评论区交流技术实现你的第一版砍掉了什么多人实时你用的 WebSocket 还是云开发有没有被 AI「自信地写错」坑过的经典案例我的经典案例默认userId 1全员共享一个池子 附录技术栈速览小程序名局趣随机 小程序发版状态已发版 前端UniApp Vue3 Vite 后端NestJS Prisma MySQL 实时Socket.IO 登录微信小程序 code2session开发可 mock 核心能力快速随机 / 自定义池子 / 多人房间 / 模板库本文分享的技术方案和架构思路可供开发类似决策型小程序时参考。通过这个实践项目我验证了AI辅助开发在中小型项目中的可行性和边界。