用 TraeCode 完成个人校园消费记账项目的三轮迭代

项目背景

这次软件工程课程实践，我选择开发一个“个人校园消费记账”桌面程序。它面向大学生日常记账场景，使用 Python、Tkinter/ttk 和 SQLite，实现消费记录、月度统计、类别筛选和预算提醒。开发过程中我使用 TraeCode 辅助分析需求、生成代码、定位 Bug 和完善测试，但功能是否符合需求，仍通过代码检查、临时数据库测试和人工界面验证来确认。

第一轮 从需求到可运行版本

第一轮提示 AI 完成基础 GUI、消费新增、SQLite 持久化、月度总支出、分类统计和预算提醒。AI 将项目拆分为入口、界面、存储和统计四个文件。金额采用整数分存储，避免浮点误差；预算提醒设置 80% 和 100% 两个阈值。

这一轮完成后，我验证了新增记录、切换月份、分类统计和预算状态。界面能够显示“预算使用正常”“接近预算上限”“已达到或超过预算”，说明基础业务流程已经跑通。

插图：
、

。

第二轮 通过测试发现并修复真实 Bug

第二轮增加编辑功能和更严格的输入校验。人工测试时发现两个关键问题：打开编辑窗口后出现 StringVar 没有 focus_set 方法的错误；未来日期能够保存，与“只记录已经发生的消费”不一致。

我把明确的复现步骤和预期结果交给 AI。修复后的代码把金额输入框控件单独保存，再通过 after_idle 设置焦点；同时在新增和编辑流程中都增加“日期不能晚于今天”的判断。测试还覆盖了不存在日期、负数金额、字母金额、取消编辑、跨月编辑和未选择记录等情况。

这一轮让我认识到，AI 生成代码后不能只看“能运行”，还要设计边界用例。修复前后的截图形成了清晰证据链：先记录 Bug，再展示修复结果。

插图：

第三轮 分离筛选明细和月度统计

第三轮增加类别筛选。最容易混淆的是统计口径：筛选餐饮后，左侧明细和筛选合计只显示餐饮，但右侧月度总支出、分类统计和预算提醒仍要按整月全部记录计算。

我在提示词中明确了“年份 + 月份 + 类别”共同筛选、切换立即刷新、空结果显示、编辑后移出当前筛选、按数据库 ID 编辑和删除，以及录入类别与筛选类别相互独立。最终界面能够在全月 90 元的情况下，显示餐饮 2 条合计 50 元，或学习 1 条合计 30 元，同时右侧仍保持 90 元和接近预算上限。

插图：

验证方法

项目最终验收使用独立临时数据库，避免影响真实数据。开发记录显示 9 项综合测试通过，覆盖金额与日期校验、消费记录与统计、筛选口径、编辑无重复、预算提醒、删除同步和重启持久化。本次提交整理又在代码副本上复核了语法、金额规则、预算边界、数据库增删改查、筛选、编辑、删除和持久化。

人工界面测试则保留了真实截图，包括输入错误提示、预算三档状态、编辑窗口和类别筛选。没有截图的测试不会被写成“截图证明”。

协作心得

这次实践中，AI 最有价值的地方是快速把自然语言需求转换成代码结构，并在我提供清晰复现步骤后定位问题。与此同时，我也遇到过“修改预览并未真正写入文件”和测试断言本身出错的情况。这说明开发者必须重新读取磁盘文件、区分应用缺陷与测试脚本缺陷，并用独立数据验证结论。

我逐渐形成了更有效的协作方式：先写清业务规则和不允许破坏的数据，再把验收标准写成可操作步骤；每轮只解决有限目标；出现 Bug 时保留复现证据；完成后让 AI 列出实际执行的测试和待人工验证项。这样可以减少“看起来完成”与“真正可交付”之间的差距。

总结

最终项目实现了消费新增、编辑、删除、月度统计、类别筛选和预算提醒，并保留了三轮迭代记录。更重要的是，我通过这一过程练习了需求拆解、边界测试、缺陷复现、证据整理和 AI 协作，而不仅是得到一份可运行代码。