用 AI 做一个校园记账桌面软件：六轮迭代记录与心得

课程：软件工程 · 第 3 讲《AI 时代的个人软件过程》
选题：个人校园消费记账 GUI（大学生生活费记账、记录、统计、提醒）
项目源码：https://github.com/Zhyuan0001/campus-expense-tracker
最新版本：v3.1.0 — Windows 便携版 exe，可在仓库 Release 页直接下载
技术栈：Electron + Vue 3 + TypeScript + Element Plus + ECharts + FastAPI + SQLite

本文按讲义给的迭代记录模板组织：第 1 轮初版 → 第 2、3 轮修改 → 我的检查与验证说明 → 心得 → 验收自评。
实际共迭代了 6 轮，前 3 轮严格对应模板，后 3 轮是把它从"能跑通"推到"合格可用"的过程。

一、我选的需求

讲义给了两个题目，我选了个人校园消费记账 GUI。原始需求是：

大学生生活费记账桌面 GUI，记录，统计，提醒……

我把它细化成 8 条可验证的功能需求（F1-F8）：

编号	功能	说明
F1	记账	输入金额（正数）、选分类、填可选描述、选日期，保存并提示
F2	查看记录	表格展示，支持按月筛选，删除需二次确认
F3	分类统计	指定月份各分类金额与占比，饼图可视化
F4	月度统计	指定月份消费总额
F5	预算提醒	设置月预算，三色状态：<80% 绿、80%-100% 黄、>100% 红
F6	自定义分类	可增删分类，默认分类不可删，实时同步到记账下拉框
F7	数据导出	导出全部记录为 CSV
F8	主题切换	亮色/暗色两套主题，立即生效且重启后保持

约束边界（不可改动的不变量）：数据库表名字段名、默认 8 种分类（餐饮/交通/学习/娱乐/社交/购物/医疗/其他）、
CSV 导出列顺序（ID,日期,分类,描述,金额）；金额必须 > 0，日期必须严格 YYYY-MM-DD。

最终形态是一个双击即运行的 Windows 便携版：Electron 打包桌面壳（内置 Chromium，不依赖系统浏览器），
后端 FastAPI + SQLite 被 PyInstaller 打包成独立可执行文件塞进应用，数据库文件跟 exe 放在一起，
可以拷进 U 盘换台电脑继续用，不需要预装 Python 或 Node.js。

第1轮（初版）

我给AI的提示词

【项目背景】
技术栈：Python 3.10 + PyQt5 + SQLite3 + matplotlib
项目概况：大学生生活费记账桌面 GUI，支持记录消费、分类统计（含饼图可视化）、
月度分析、预算提醒、自定义分类、数据导出 CSV、亮/暗主题切换。
编码约定：PEP8；类名 PascalCase；函数/变量 snake_case；中文界面。

【需求描述】
F1 记账：输入金额、选分类、填描述、选日期，提交保存
F2 查看记录：表格展示，支持按月筛选，删除选中记录
F3 分类统计：指定月份各分类金额与占比，饼图可视化
F4 月度统计：指定月份消费总额
F5 预算提醒：设置月预算，三色状态显示（绿/黄/红）
F6 自定义分类：用户可添加/删除自定义分类
F7 数据导出：导出全部记录为 CSV
F8 主题切换：亮色/暗色两套主题

【约束边界】
- 单文件主程序，不超过 800 行
- 数据库自动建表，文件名 campus_expenses.db
- matplotlib 图表嵌入窗口内，不弹独立窗口
- 金额必须 > 0，日期格式严格 YYYY-MM-DD
- 默认分类不可删除（只能隐藏）

【验收标准】
- 5 个 Tab 均可正常切换
- 记账后记录出现在列表中
- 饼图正确显示中文
- 预算三色状态正确
- 单元测试全部通过

AI生成的初版要点

生成了 786 行、8 个类的单文件程序（Database / PieChartWidget / ExpenseTab / RecordsTab /
StatisticsTab / BudgetTab / SettingsTab / MainWindow），F1-F8 全部实现，用 QSS 样式表做亮暗主题，
并配套写了单元测试。

是否符合期望：基本符合，能跑起来、5 个 Tab 都能切换。但快速阅读代码后发现两个明显问题
（见第 2 轮），而且界面观感确实一般——这也成了后来整体换技术栈的伏笔。

第2轮（第一次迭代修改）

发现的问题

matplotlib 中的中文全部显示成方框乱码——饼图里的"暂无数据"和分类名称都是口口口
分类排序反直觉——SQL 里按 is_default DESC 排序，导致顺序不是用户期望的插入顺序

我给AI的修改要求

修复两个问题：
1. matplotlib 饼图中文字体缺失 —— 需要配置中文字体，使用系统可用的 Noto Sans CJK 字体
2. 分类排序 —— 改为按 id（插入顺序）排序，而不是按 is_default DESC

（注意：这里我没有说"改一下字体问题"，而是写清了"用哪个字体文件、改成按什么字段排序"。）

AI修改了什么

用 fontManager.addfont() 手动加载 /usr/share/fonts/opentype/noto/NotoSansCJK-Regular.ttc，
并把 plt.rcParams["font.sans-serif"] 首选设为 "Noto Sans CJK JP"、
设置 axes.unicode_minus = False 防止负号显示异常
分类查询 SQL 从 ORDER BY is_default DESC, name 改成 ORDER BY id
顺带补了一个测试用例 test_categories_ordered_by_id 把排序行为锁住

结果：饼图中文正常渲染，分类顺序变成餐饮 → 交通 → 学习 → 娱乐 → 社交 → 购物 → 医疗 → 其他，
测试全部通过。

第3轮（第二次迭代修改）

发现的问题

预算 Tab 只有一行文字提示"已使用 X%"，看不出直观的进度，也不知道快超支了没有。

我给AI的修改要求

在预算 Tab 中添加进度条：
- 使用 QProgressBar 显示本月已使用百分比
- 进度条颜色随状态变化：绿色（<80%）、黄色（80%-100%）、红色（>100% 超支）
- 超支时进度条显示 100%（不要让进度条溢出）

AI修改了什么

导入 QProgressBar，在 BudgetTab 里加了 25px 高的进度条；_load() 中计算已用百分比并按状态设置颜色
（绿 #00b894 / 黄 #fdcb6e / 红 #d63031）；未设置预算时清空样式。

验证结果：25% 时绿色、105% 时红色且进度条停在 100%，符合预期。

到这里讲义要求的"最少 2 次迭代修改"已经满足。但我发现这个版本界面观感差、高分屏缩放糟糕，
于是又往下做了 3 轮。

第4轮：整体换技术栈（PyQt5 → Electron）

发现的问题

初版功能没问题，但 PyQt5 的界面不好看，4K 高分屏下缩放很差；而且我希望它以后有可能复用到移动端。

我给AI的修改要求

【项目背景】
校园消费记账应用已有一个 PyQt5 单文件版本，功能完整但界面观感差、高分屏适配糟糕。
想整体重写技术栈：前端用 Web 技术栈（Vue3 + TypeScript + Element Plus + ECharts），
后端用 FastAPI + SQLite；业务逻辑与数据库结构保持不变，只换实现。

【需求描述】
1. 复用原有的全部功能（F1-F8），新增一个"首页仪表盘"：本月支出、分类占比饼图、
   近 6 个月趋势折线图、最近 5 条记录
2. 桌面包装用 Electron（内置 Chromium，不依赖系统浏览器），而不是 pywebview
3. 后端要从"跟着 Python 解释器跑"变成"独立可执行文件"，让用户不用装 Python

【约束边界】
- 数据库表名、字段名、默认 8 个分类、CSV 导出列顺序都不许变
- 便携版语义：数据库文件必须落在应用（exe）同目录，不能写进 AppData
- 界面全中文，窗口最小尺寸 900x650
- 金额必须是有限正数、日期必须严格补零 YYYY-MM-DD

【验收标准】
- 双击 exe 能直接启动，不需要预装任何运行时
- 在 exe 同目录生成 campus_expenses.db
- 6 个页面（首页/记账/记录/统计/预算/设置）功能正常，亮暗主题可切换
- 图表中文正常显示

AI修改了什么

这一轮改动最大，产出三层结构：

Electron 主进程：启动/停止后端进程、轮询健康检查、退出时清理进程；窗口无菜单、ready-to-show
后再显示；安全配置 contextIsolation: true + nodeIntegration: false
preload 安全桥接：用 contextBridge 只暴露必要接口，不把 Node 能力直接给渲染层
Vue3 渲染层：把 6 个页面组件搬进来，抽出统一 API 层（消掉原先 5 个组件里重复的 API_BASE 硬编码）
PyInstaller 打包后端：backend.spec 用 onedir 模式打包，electron-builder 再通过 extraResources
把整个后端目录塞进安装包

便携版的关键是数据库路径：主进程把 DB_PATH 环境变量指向 PORTABLE_EXECUTABLE_DIR（exe 所在目录），
后端优先读这个变量；装到不可写目录时回退到用户数据目录，避免启动即崩。

第5轮：全面质量审计（查出 21 项缺陷）

发现的问题

功能都"能跑"，但我不确定细节上是否真的正确。于是这轮不加功能，专门做审计。

我给AI的修改要求

注意，请再次在本机上确认所有功能实现无误，按照ppt流程规范安全可追溯的进行工程，
对整个软件的所有功能和细节进行全面测试，擅长使用子agent团队进行研究、测试、判断、提升；
得到完美的exe便携软件

AI修改了什么

用三条互不依赖的路径同时验证：

读 electron-builder 的 portable.nsi 模板和 PyInstaller 源码，静态推演打包后在 Windows 上的真实行为
起真实 uvicorn 进程，对 12 个路由做 31 组黑盒验收（含并发、CSV 字节内容、统计口径一致性）
把生产构建产物托管起来接真实后端，在浏览器里逐功能点击

共查出 21 项缺陷，其中几项真的会当场翻车：

缺陷	不修的后果
金额传 `Infinity` 能通过校验并写进数据库	之后所有读接口永久 500，用户连删都删不掉
portable 版双击两次会互删解压目录，且 95MB 解压期间无任何界面	用户以为没点上再点一次 → 白屏/崩溃
非补零日期 `2026-9-5` 能入库，但被统计静默丢弃	记录列表加起来 ¥33、统计页只有 ¥22，账不平
CSV 导出写固定可预测的 `/tmp` 路径	同机其他用户可用符号链接劫持，让服务进程覆写任意文件
`npm run typecheck` 从来没通过过	主进程有类型错误一直裸奔（CI 没覆盖该目录）

修复后补了 11 个回归用例，后端测试从 19 个扩到 30 个，覆盖率 95% → 97%；
并给渲染层补上第一套组件测试、把类型检查接进 CI。

第6轮：调研驱动的功能升级（v3.1.0）

发现的问题

修完缺陷后，软件"能跑、没明显 bug"，但我不知道它够不够格算一个合格的记账软件。
与其拍脑袋加功能，不如先看看别人怎么做。

我给AI的修改要求

【项目背景】
校园消费记账桌面应用 v3.0（Electron + Vue3 + Element Plus + ECharts + FastAPI + SQLite），
已发布为 Windows 便携版 exe。现在想把它从"能跑通的课程作业"提升到"合格/优秀的软件"，
但我不确定该补哪些功能，也不确定桌面应用在不同窗口比例下该怎么布局。

【需求描述】
1. 先做调研，不要直接写代码：
   a) 对标市面上的记账应用（钱迹/随手记/鲨鱼/一木/薄荷/YNAB/Actual/Firefly III/MMEX/
      ezBookkeeping），拉一张功能矩阵，标出必备/推荐/加分，并在"本项目"一列标出已有与缺失
   b) 调研桌面 Web 应用（VS Code / Notion / Slack / Windows XAML）怎么处理窗口缩放，
      给出适合本项目的断点方案（宽度断点 + 长宽比断点）
2. 按调研结论只做 P0（合格线）里性价比最高的几项，不要一次全做
3. 响应式要覆盖"竖窗/窄窗"形态，现在窗口最小 900x650 根本拉不窄

【约束边界】
- 不改数据库表名和字段名，不改已有 API 的路径与响应格式
- 保持便携版语义：数据库仍落在 exe 同目录
- 新功能要有测试
- 已有的输入校验（金额必须是有限数、日期严格补零）不能回退

【验收标准】
- 编辑已有记录：行内按钮能改金额/分类/描述/日期，保存后列表与数据库都更新
- 搜索与筛选：能按关键词（描述/分类）和分类筛选，能一键重置
- 备份与恢复：能导出 JSON 备份、能从备份恢复；恢复前二次确认，且能覆盖回原数据
- 响应式：窗口拉成竖条时导航变底部栏，拉宽时回到侧边栏；指标卡列数随宽度变化

AI修改了什么

先产出调研报告，再按结论实现。调研结论直接改变了我的优先级判断：

对标约 20 款竞品后发现，本项目连"编辑记录"都没有（只能删了重记），而这是所有记账应用的必备能力
——属于"合格硬伤"
调研里"数据丢失/停止维护是致命伤"被反复提及 → 把备份/恢复提到最高优先级
响应式调研指出 minWidth: 900 直接把竖窗形态挡死，侧栏 220px 永远常驻

实际改动：

后端（+161 行）：新增 PUT /api/expenses/{id}（编辑）、GET /api/backup（JSON 全量备份）、
POST /api/restore（整库恢复）；GET /api/expenses 扩展筛选参数
（keyword / category / date_from / date_to / min_amount / max_amount）。新增 17 个测试。

前端：记录页加关键词搜索框（回车即搜、清空自动重查）、分类下拉、"筛选/重置"与匹配条数提示，
每行加编辑按钮弹出编辑弹窗；设置页加"数据备份与恢复"卡片，恢复前二次确认；
新增 composables/useLayout.ts 把窗口尺寸与长宽比抽成响应式状态，输出
navMode（侧边栏 / 图标轨 / 底部栏）与栅格列数，导航据此自动切换形态。

我的检查与验证说明

我怎么确认 AI 生成的结果是正确的——分四层，而且刻意不只依赖单元测试：

运行样例（单元测试）：后端 47 个 pytest（覆盖率 95%），覆盖新端点的正常路径与边界
（编辑沿用金额/日期校验、备份恢复的整库替换、筛选参数组合）；渲染层 32 个 vitest 覆盖组件行为。
测试里特意包含回归项，比如把"预算恰好 80% 应为黄色"这种边界锁死。
端到端人工验证：把生产构建产物用静态服务器托管、接真实后端，在浏览器里逐功能点击。
为什么不信单元测试就够了——本项目的后端测试走 TestClient 的内存 ASGI 调用，测不出真实 HTTP 行为。
第 5 轮那个"Infinity 投毒"缺陷，就是在 19 个单测全绿的情况下存在的，最后靠真实 HTTP 请求才暴露。
交叉验证（备份/恢复往返）：不是"点了没报错就算过"，而是构造往返用例——
备份 3 条共 ¥136.5 → 主动删掉 2 条并把预算改成 5000 → 恢复 →
逐项比对：记录数回到 3、金额合计回到 ¥136.5、预算回到"未设置"。
这样才能确认恢复真的还原了数据，而不是只弹了个成功提示。
审查边界：提交编辑前先确认弹窗回填值正确（金额 88.00 / 分类 / 日期 / 描述计数 2/200）才保存；
搜索用中文关键词验证；升级后回头检查上一轮修的"中文 locale"和"本地日期函数"是否还在生效
——分页仍显示"共 3 条 / 20条/页"，新代码里的备份文件名也复用了 todayLocal()，
说明前面的修复被沿用了而没有在重写中被覆盖掉。

自动化持续验证：GitHub Actions 在每次 push 时并行跑 4 个 job——后端测试、旧版前端测试、
渲染层测试 + 类型检查、代码规范检查；Windows 的 exe 则在推 tag 时自动构建并发布到 Release。

心得

本次协作最大惊喜："先调研再动手"比"直接加功能"高效得多

我原本的想法是"多加功能显得厉害"——多账本、云同步、AI 识图，听起来都很有分量。
但让 AI 先对标二十款真实记账应用、拉出功能矩阵并按必备/推荐/加分排序之后，结论完全反过来了：
本项目真正缺的是编辑记录这种"不补就不算合格"的基础能力，而不是那些花哨的东西。
同一份调研还指出"数据丢失/停止维护是致命伤"，于是备份/恢复被提到最高优先级——
这是我自己拍脑袋排不出来的优先级。

另一个惊喜是让 AI 用"子 agent 团队"分头干活：一轮里同时有一个 agent 去静态推演 Windows 打包后的
运行时行为（它真的去读了 portable.nsi 模板）、一个 agent 起真实服务做黑盒测试、
我自己在浏览器里点界面。三条路径互不依赖，交叉出来的结论比任何单一路径都可靠——
portable 版"双击两次互删文件"这个问题就是静态推演先发现、再被我实测验证的。

本次协作最大失望：环境类的坑会被反复踩中

另一台机器上，AI 已经在环境说明里专门记录了教训："npm install ... | tail 会吞掉退出码，
导致误判成功"。而我在本机验证时原封不动地又踩了一次——用 npm ci | tail 的退出码判断安装成功，
实际那次是 TLS 失败。

同一个坑在同一个项目里被记录两次，说明这类问题靠"记住"解决不了，只能靠把判断方式固化下来
（改成先落盘再看文件、或用后台任务的退出码）。这也印证了：设计文档写得越具体，后续越不容易
走回头路——凡是没写进文档的约定，下一次一定会有人（或 AI）重新踩一遍。

一点反思

AI 很擅长"把代码写得比我想的更周全"，但它不知道我到底要什么。这六轮下来，最有价值的动作
不是让它写代码，而是：把需求写成可验证的验收标准、让它先调研再动手、以及坚持"不信单元测试全绿
就等于功能正确"。前面几点看起来是在拖慢进度，实际上省掉了后面反复返工的时间。

验收自评

验收标准	是否达标	说明
① 功能跑通：选定需求的基本功能可演示正确结果	✅	8 项核心功能（记账 / 记录列表+搜索筛选 / 编辑 / 删除二次确认 / 分类统计饼图 / 预算三色提醒 / 自定义分类 / CSV 导出）+ 备份恢复、亮暗主题、多比例响应式。已在真实 Windows 机器上运行便携版验证可用，并在开发机上用生产构建产物 + 真实后端做端到端逐项点击验证
② ≥2 轮迭代记录：每轮记录"你给AI的修改要求"+"AI实际改了什么"	✅	共 6 轮：初版 → 中文字体与排序修复 → 预算进度条 → 技术栈重写为 Electron → 全面质量审计（21 项缺陷）→ 调研驱动的功能升级。每轮均含提示词与实际改动
③ ≥1 次验证说明：写清楚"我怎么确认AI生成结果是正确的"	✅	见《我的检查与验证说明》：运行样例（47+32 个自动化测试）、审查边界、备份恢复往返交叉验证、回归检查，并说明了为什么单测全绿不等于功能正确
④ 1 条心得：本次协作中最大的意外是什么，AI 在哪里让你惊喜或失望	✅	见《心得》：惊喜是"先调研再动手"改变了优先级判断、以及子 agent 并行交叉验证；失望是环境类坑被重复踩中

附：项目信息

源码仓库：https://github.com/Zhyuan0001/campus-expense-tracker
可执行文件：仓库 Release 页 → v3.1.0 → 便携版 / 安装包（Windows）
自动构建：推 v* 标签由 GitHub Actions 自动产出 Windows exe 并发布 Release
测试与 CI：后端 47 个 pytest（覆盖率 95%）+ 渲染层 32 个 vitest + 类型检查 + 代码规范，
由 CI 在每次提交时并行执行
验证范围说明：已在真实 Windows 机器上运行便携版 exe 验证可用（启动、增删改查、图表、
预算、主题、备份恢复均正常）；开发阶段的端到端验证在 Linux 上用生产构建产物 + 真实后端完成，
Windows exe 由 GitHub Actions 自动构建并校验完整性（PE 格式、字节数、内嵌后端）

posted @ 2026-10-10 18:04 打电话的杜甫阅读(9) 评论(0) 收藏举报

刷新页面返回顶部

用 AI 做一个校园记账桌面软件：六轮迭代记录与心得

一、我选的需求

第1轮（初版）

我给AI的提示词

AI生成的初版要点

第2轮（第一次迭代修改）

发现的问题

我给AI的修改要求

AI修改了什么

第3轮（第二次迭代修改）

发现的问题

我给AI的修改要求

AI修改了什么

第4轮：整体换技术栈（PyQt5 → Electron）

发现的问题

我给AI的修改要求

AI修改了什么

第5轮：全面质量审计（查出 21 项缺陷）

发现的问题

我给AI的修改要求

AI修改了什么

第6轮：调研驱动的功能升级（v3.1.0）

发现的问题

我给AI的修改要求

AI修改了什么

我的检查与验证说明

心得

本次协作最大惊喜："先调研再动手"比"直接加功能"高效得多

本次协作最大失望：环境类的坑会被反复踩中

一点反思

验收自评

附：项目信息

公告