





























借助 Gemini3 加持完成首款微信小程序开发,全程让 AI 参与功能、设计、前后端开发全环节,开发中遵循从静态骨架到智能核心再到闭环生态的路径,还针对性攻克了 AI 幻觉与地图数据冲突、云函数超时等 AI 应用开发的通用痛点,也切实体会到与 AI 深度协作的效率提升。

真的很久很久没有这么兴奋了!!!首先是在 Gemini3 的加持下完成了首款小程序,其次我切实感受到了深度与 AI 一起工作效率的大幅提升,以及对未来无限可能的期待!总结一下这次小程序开发,功能、设计、前后端开发整体 AI 都干了什么。


我们将开发过程分为了五个阶段,遵循了从“静态骨架”到“智能核心”再到“闭环生态”的路径:
1. 顶层设计与基础设施搭建架构选型:确定了微信小程序原生 + 云开发 (Cloud Base)的无服务器架构。前端负责交互,云函数处理 AI 和地图逻辑,云数据库存储用户资产。视觉规范:建立了Zoo Style视觉体系(米白背景、森林绿主色、鹅卵石圆角卡片),并在app.wxss中定义了全局 CSS 变量。导航框架:配置了app.json,确立了“旅行规划”和“我的旅行”双 Tab 结构。
2. 核心功能模块开发 (Plan & Overview)首页 (Index):实现了自定义区间日历(支持跨月选择)和城市选择器(国内/国外分组、拼音搜索),解决了原生组件交互单一的问题。目的地概览 (Overview):实现了“图文解耦”的内容展示。
3. 核心技术攻坚 (Result – 智能行程页)RAG 架构重构:为了解决 AI 瞎编地点导致地图无坐标的问题,我们将逻辑重构为AI 提名 -> 地图 API 验证 -> AI 最终规划的 RAG(检索增强生成)模式,但这里由于加载太慢容易失败而影响体验,最终还是选择和地图逆地址解析再回填。高级交互:实现了长按拖拽排序功能,且拖拽后自动重新计算路线和距离。
4. 用户系统与资产闭环 (My Trips)云数据库:创建了trips和users集合,实现了行程的云端存储。权限管理:实现了完整的“微信一键登录”流程,增加了隐私协议和用户协议的勾选校验。社交裂变:实现了将特定行程分享给微信好友,好友点击后可查看并转存行程的逻辑。
5. 发布与合规优化过审策略:移除了高风险的wx.getLocation强制授权,改为默认北京定位+手动选城。性能优化:开启了“按需注入”,并调整了云函数超时配置(60s)以适应大模型生成耗时。
在开发过程中,我们解决的几个最棘手的问题,其实也是目前 AI 应用开发最通用的痛点:
AI 的“幻觉”与地图数据的“严谨”之间的冲突
难点:DeepSeek/Kimi 生成的地点名(如“成都好吃街”)在地图 API 里搜不到,导致返回坐标 (0,0),地图连线飞到非洲,或者报错。
解决方案:
云函数超时与并发限制
难点:大模型生成文本需要 15s+,搜图 12 张并发请求会导致 QPS 超限(腾讯地图个人版限制 5QPS)或 IP 被封,导致云函数 3s 默认超时报错。
解决方案:
复杂的数据一致性与状态管理
难点:用户在列表拖拽修改顺序后,地图上的连线、点与点之间的距离时间都需要实时重算;“查看模式”与“新建模式”的数据流混淆。
解决方案:
微信小程序生态的限制
难点:无法直接保存长图(Canvas 绘图太复杂)、隐私接口(定位、用户信息)审核收紧。
解决方案:降级策略,定位权限改用默认城市;酒店比价改用wx.navigateToMiniProgram跳转成熟的腾讯地图小程序。
本文由人人都是产品经理作者【小王子和小企鹅】,微信公众号:【小王子和小企鹅】,原创/授权 发布于人人都是产品经理,未经许可,禁止转载。
题图来自Unsplash,基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理,仅供阅读参考。 原文来自 — 版权归原作者所有。