第二次作业

AI 时代的个人软件过程：校园消费记账 GUI 的迭代记录与心得

一、选定需求与意图描述

本次练习选择“个人校园消费记账 GUI”，使用 Codex 辅助开发，项目名称为“校园口袋”。目标是让大学生通过中文桌面界面记录生活费收支，查看每月消费去向，并在预算接近上限或缴费事项到期时收到提醒。

我将需求具体化为：能够新增、编辑、删除和筛选收支记录；记录金额、日期、分类、支付方式及备注；展示月度收入、支出、结余和消费图表；支持设置月预算、添加到期提醒，以及保存和导出数据。项目采用 Python、Tkinter 和 SQLite，数据保存在本地，日常使用不需要联网。

以下按实际开发过程记录四个阶段。其中，第2轮是 AI 在初版生成期间主动进行的自测修复；第3轮和第4轮是我明确提出修改要求后的迭代。

二、迭代记录

第1轮（初版）

我给 AI 的提示词：

生成一个 个人校园消费记账 GUI：功能包括大学生生活费记账桌面 GUI，记录，统计，提醒……

AI 生成的初版要点：

AI 根据需求生成了总览、收支明细、消费统计和提醒事项四个页面，并实现本地数据库保存、CSV 导出及预算预警。代码将界面交互放在 app.py，将数据校验、存储和统计放在 ledger.py，金额以整数“分”保存。功能范围基本符合预期，但仍需要验证界面布局和实际启动方式。

快速阅读与检查：

检查代码时，我重点关注金额是否可能算错、数据关闭后是否丢失，以及提醒的触发条件。实现中使用 SQLite 保存记录，对金额和日期进行校验；预算达到 80% 和 100% 时分别进入预警状态。提醒在程序启动时及运行期间检查，关闭程序后不会继续提醒，这一点也写入了使用说明。

第2轮（第一次迭代修改：AI 自测与布局修复）

发现的问题：

在初版自动验证中，AI 发现窗口缩小后，总览中的部分最近收支、查看明细按钮及底部状态文字会被挤出可见区域。空账本和有数据的账本也存在不同的布局情况，需要分别检查。

我给 AI 的修改要求：

本轮没有追加独立提示词，仍沿用第1轮的实际需求。布局问题由 AI 在完成该需求的自测过程中发现并修复，因此这里如实记录为一次自动自检迭代。

AI 修改了什么：

AI 调整了页面布局，将最近收支改为可滚动列表，缩减空状态区域的间距，并为底部状态栏保留空间。随后补充最小窗口尺寸的回归测试，检查四个页面在 1020 × 720 窗口下的控件是否可见，测试总数由12项增加到13项。

第3轮（第二次迭代修改：修复双击启动）

发现的问题：

我尝试双击启动文件时，程序没有正常出现。此前功能测试已经通过，但用户实际使用的启动入口仍存在问题。

我给 AI 的修改要求：

我双击怎么没反应，请解决

AI 修改了什么：

AI 复现了 Windows 批处理在原有换行格式及编码切换下截断命令的问题，将启动文件改为 CRLF 换行和 ASCII 内容，并完善 Python 路径查找及失败日志。随后增加 --check-startup 自检参数和真实批处理入口测试，验证从其他目录启动、带空格路径及 GUI 创建，14项测试通过。

这一轮的结果：

启动入口的自动检查通过，成功时输出 CAMPUS_POCKET_STARTUP_OK。如果启动失败，控制台会保留错误信息，详细报错写入 data/startup.log，便于继续定位问题。

第4轮（第三次迭代修改：增加“回到本月”）

发现的问题：

查看历史月份后，原来只能逐月切换回来。历史月份与当前月份距离较远时，需要多次点击，操作不够方便。

我给 AI 的修改要求：

我在本轮选择的实际要求是：

增加“回到本月”按钮，方便查看历史月份后返回（推荐）

AI 修改了什么：

AI 在月份选择器下方增加了“回到本月”按钮，点击后刷新当前页面的记录和统计，已经处于本月时按钮禁用。补充的 GUI 测试验证了总览、收支明细和消费统计三个页面的返回操作，以及历史记录不会被改变，最终15项测试全部通过。

三、我的检查与验证说明

我怎么确认结果正确：

我的验证方法是检查具体的输入、预期结果和测试断言，并让 AI 实际运行测试。这样既能用简单样例核对计算，也能确认窗口交互、数据保存和启动入口是否正常；不能仅根据 AI 说“已经完成”就判断软件正确。

1. 用可手算的样例交叉核对统计

统计测试使用以下2026年9月记录：

记录	金额
生活费收入	2,000.00元
餐饮支出	10.00元
餐饮支出	20.00元
学习支出	50.00元

另加入一条2026年10月1日的99.99元支出，用来检查跨月隔离。9月应统计出收入2,000.00元、支出80.00元、结余1,920.00元；餐饮合计30.00元，学习合计50.00元，每日支出汇总也应为80.00元。测试中的结果与这些手算值一致，10月的支出没有混入9月统计。

2. 检查边界与异常输入

检查内容	样例或操作	验证结果
金额精度	输入0.29元	精确保存为29分
无效金额	空值、负数、0元收支、三位小数、非数字	拒绝保存，并给出提示
日期边界	2024-02-29与2026-02-29	正确处理闰年，拒绝不存在的日期
预算阈值	预算100元，累计支出79.99、80.00、100.00元	分别为正常、80%预警和达到预算
预算关闭	将该月预算设置为0	该月预算提醒关闭
数据持久化	保存后关闭并重新连接数据库	原有记录仍可读取
到期提醒	添加过去、当天和未来到期事项，切换完成状态	只将未完成且已到期的事项列为到期提醒
CSV 导出	中文、逗号和换行备注	导出后可正确读回原始内容

3. 检查完整操作流程

GUI 测试实际创建窗口，并依次执行新增、编辑、搜索、导出和删除。例如，将一笔12.34元支出修改为20.50元后，统计值也变为20.50元；删除后记录数归零。测试还覆盖空账本、有数据的账本、跨年月份切换、最小窗口布局，以及“回到本月”后的列表刷新和历史数据保留。

启动测试通过真正的 启动记账.bat 创建 GUI，并检查成功标记，而不只检查 Python 文件能否导入。测试使用临时数据库，避免将验证数据写入个人正式账本。

本轮最终执行命令为：

python -m unittest -v

结果如下，所有测试通过：

Ran 15 tests
OK

以上验证基于当前 Windows 环境。自动化测试确认了所覆盖的操作，仍不能保证所有设备和所有输入都没有问题。

四、心得

AI 让我惊喜的地方，是它能够把较宽泛的需求快速落实为界面、数据库和测试，并根据失败结果继续修改。它也能补充我起初没有想到的验证，例如金额精度、跨月统计和小窗口布局。这减少了编写重复代码的时间，让我能够更多地关注功能是否符合使用场景。

让我失望的地方，是初次交付时，AI 根据功能测试通过就给出了较乐观的完成判断，而真实的双击入口还没有充分验证。后续修复说明，测试需要覆盖从启动到操作的完整路径。AI 给出的结论应当有可检查的依据，我也需要主动提供实际使用中的反馈。

这次校园记账项目让我对软件工程有了更具体的理解：需求分析决定要解决什么问题，设计让实现和维护有条理，测试帮助发现错误，迭代则把使用反馈转化为改进。从记录生活费到修复启动，再到补充“回到本月”，每次修改都应有明确目标和验证结果。

以后与 AI 协作时，我会把需求和发现的问题描述得更具体，并在每次修改后核对结果。AI 能提高开发效率，但需求是否合适、软件是否可靠，仍需要通过实际验证来判断。