一个零经验开发者用 AI 完成微信记账小程序的实践复盘

一个零经验开发者用 AI 完成微信记账小程序的实践复盘

这篇文章不是教程合集，也不是完整源码讲解，而是一次真实开发过程的复盘：在没有微信小程序开发经验的情况下，我如何借助大模型，把一个记账工具从想法逐步推进到可运行、可迭代的微信小程序。

一、先说最终成果

这个项目最终落地成了一款生活记账类微信小程序，我给它取名为小白管账。

它不是一个只做“新增一笔账”的简单 Demo，而是围绕普通人的日常财务场景，做了几个相对完整的模块：

• 今日概览：查看当天支出、收入、流水、预算节奏和简报
• 快速记账：支持文字输入，也尝试接入语音记账
• 账单管理：按日期、关键词、分类查看历史流水
• 预算管理：设置月度预算和分类预算，查看使用进度
• 资产管理：维护资产账户、负债账户和净资产概览
• 生活财务：记录订阅扣款、还款缴费、存钱目标、人情借还
• 数据安全：支持备份、导出、恢复和误删恢复

从结果看，它已经不是一个“写着玩的页面”，而是一个具备真实使用流程的小程序项目。对我来说，更重要的是：它验证了一件事，AI 不只是能回答问题，也可以参与到一个产品从需求、交互、代码到调试的完整过程里。

二、为什么选择记账这个题目

我一开始并不是为了练小程序语法才做这个项目，而是先有一个真实需求。

日常记账看起来很简单，但实际坚持起来并不容易。很多记账工具的问题是：

• 功能入口多，但新增一笔账仍然麻烦
• 账单、预算、资产、还款提醒分散在不同地方
• 报表很多，但每天最需要的信息并不直观
• 只记录已经发生的消费，不太关注未来即将发生的钱

所以我最初给这个项目定的目标不是“做一个复杂财务系统”，而是做一个更贴近日常生活的小工具：

打开后先知道今天花了多少、还能花多少；需要记账时尽量少操作；钱相关的提醒和目标也能集中管理。

这个目标很重要，因为 AI 写代码之前，人必须先把问题说清楚。如果需求本身模糊，只说“帮我做一个记账小程序”，大模型很容易生成一个普通模板，后面会越改越乱。

三、AI 在这个项目里具体帮了什么

这次开发里，AI 的作用不是一次性生成完整项目，而是持续参与每个阶段。

1. 帮我把想法拆成页面

一开始只有一个想法：做一个记账工具。

经过多轮拆解后，项目逐渐形成了几个主页面：

• 今日页：承载每日概览和快速入口
• 账单页：承载流水列表、查询、统计和导入
• 记账页：承载新增账单、智能输入、语音输入
• 生活页：承载订阅、提醒、目标、人情借还
• 资产页：承载账户、资产、负债、备份和设置

这个阶段 AI 的价值是帮助我从“功能想法”过渡到“页面结构”。对于没有小程序开发经验的人来说，能先把页面边界划出来，会明显降低后面的复杂度。

2. 帮我建立基础代码结构

项目后来逐渐拆出了这些层次：

pages/ 页面层，负责展示和交互 services/ 业务服务层，负责账单、资产、生活事项等逻辑 utils/ 工具层，负责日期、金额格式化、本地存储等公共能力 constants/ 常量层，负责分类、类型、存储键等固定配置 styles/ 样式系统，负责主题变量和通用样式 components/ 公共组件

这个结构对小项目来说也许不算复杂，但它解决了一个很实际的问题：页面代码不会无限膨胀。

比如账单新增、资产校准、生活提醒这些逻辑，如果全部写在页面 JS 里，后期维护会很痛苦。拆到服务层后，页面只负责调用和刷新，业务逻辑更容易复用。

3. 帮我补齐微信小程序特有问题

微信小程序开发有不少细节，刚开始很容易踩坑，比如：

• 页面生命周期和数据刷新
• setData的更新方式
• 自定义 tabBar
• open-type="share"的分享行为
• 录音权限和隐私授权
• 开发版、体验版、正式版表现不一致
• WXML、WXSS 与普通 Web 开发的差异

其中一个印象比较深的问题是语音记账权限。

开发版和体验版里语音功能正常，但正式版提示没有麦克风权限。这个问题不是简单写一个wx.authorize就一定能解决，还涉及小程序后台隐私协议、录音用途说明、用户授权弹窗、设置页入口等。通过 AI 辅助分析后，我才逐步把问题拆成“代码权限流程”和“平台隐私配置”两部分去处理。

这类问题如果完全靠新手自己查文档，定位成本会高很多。

四、几个关键功能是怎么迭代出来的

1. 今日页：从首页列表到每日决策卡片

最初我想做的首页可能只是账单列表。但真正使用时，用户打开记账工具并不一定是为了看所有流水，而是想快速知道今天的状态。

所以今日页被调整成“先看概览，再看流水”的结构：

• 顶部展示今日支出
• 同时展示今日收入、今日流水、今日可花
• 根据预算生成节奏提示
• 有待处理生活事项时主动提示
• 最近流水只保留必要信息

这个调整让我意识到：AI 可以写页面，但“页面应该优先展示什么”仍然需要产品判断。

2. 记账页：减少输入成本

记账动作越麻烦，越难坚持。

所以记账页做了两类输入：

• 常规表单输入：金额、分类、账户、日期、备注
• 智能输入：通过一句话或语音描述生成记账信息

比如“午饭 28 微信”这样的短句，本质上包含了分类、金额和账户线索。AI 辅助开发时，可以帮助梳理解析规则、状态流转和异常提示，让这个功能从想法变成可操作流程。

3. 生活页：把未来的钱也纳入管理

很多钱并不是随机发生的，而是周期性、计划性发生的：

• 会员订阅
• 房租保险
• 信用卡还款
• 存钱目标
• 人情借还

这部分如果只靠账单记录，往往要等钱花出去之后才看见。生活页的设计思路是提前记录这些事项，让系统能在首页或生活模块里提示。

这也是我觉得记账工具可以继续扩展的方向：不仅记录过去，也帮助处理即将发生的财务事项。

4. 数据安全：小工具也要考虑恢复

记账数据虽然存在本地，但依然需要备份和恢复能力。

项目里做了：

• 备份快照
• CSV 导出
• 文件恢复
• 剪贴板恢复
• 误删恢复

这部分开发让我意识到，很多“看不见”的功能其实很重要。用户平时不一定会主动用，但一旦数据出问题，这些能力就会决定工具是否可靠。

五、AI 编程的真实体验

这次项目让我对 AI 编程有了更具体的理解。

1. AI 最适合解决“下一步怎么做”

新手开发最大的问题往往不是不会敲代码，而是不知道下一步该查什么、改哪里、怎么拆。

AI 在这方面很有帮助。比如我可以直接描述：

• 这个按钮点击不灵敏
• 正式版没有麦克风权限
• 这个卡片样式太占地方
• 金额是否应该全部隐藏
• 分享入口和引导入口位置重叠

AI 可以根据现象去定位可能的文件、组件和逻辑，再给出修改方向。

2. AI 不是审美和产品判断的替代品

UI 迭代里我也遇到过这种情况：AI 实现了功能，但看起来并不好。

比如金额隐藏功能，一开始做得过于全局，连流水金额都隐藏了；分享入口一开始也设计得像一个大卡片，占空间、不自然。后来经过多轮调整，才逐渐变成更轻量的悬浮入口。

这说明 AI 可以快速执行，但是否舒服、是否克制、是否符合用户习惯，仍然需要人来判断。

3. 提问越具体，结果越可控

模糊提问容易得到模板答案，具体提问更容易得到可用结果。

比较有效的提问方式是：

• 明确当前页面和文件
• 描述期望交互
• 描述现在的问题
• 给出参考样式或截图
• 限定不要影响其他模块

比如“把分享入口改成参考新手引导的小胶囊样式，并避免位置重叠”，就比“优化分享按钮”更容易得到满意结果。

六、给想用 AI 做项目的新手几点建议

如果你也想用 AI 做一个自己的小程序或工具，我的建议是：

1. 先写清楚产品目标，不要一开始就写代码
2. 先做最小可运行版本，不要第一版就追求完整
3. 每次只让 AI 解决一个具体问题
4. 重要逻辑要自己理解，不要只复制代码
5. UI 和交互一定要反复真机预览
6. 遇到平台能力问题时，同时检查代码和后台配置
7. 让 AI 解释修改原因，而不是只要最终代码

AI 能提高开发效率，但它不能替代你对产品的判断。真正有效的协作方式，是把 AI 当成一个能快速讨论、快速试错、快速落地的开发伙伴。

七、总结

从 0 小程序经验到完成一个相对完整的记账项目，这个过程让我最大的感受是：AI 把很多原本很高的技术门槛拆小了。

它不会让开发完全没有成本，也不会自动保证产品好用。但它能让一个普通想法更快进入实践阶段，让新手不再卡死在“我不知道从哪里开始”。

如果说过去做一个小程序需要先系统学习很久，那么现在更可行的路径也许是：

先把真实问题讲清楚，再借助 AI 拆需求、搭结构、写代码、调问题，最后通过自己的体验和判断不断修正。

这就是我这次开发微信记账小程序最大的收获。