图中是早期统计页设计稿，数值为界面示例。本文统计来自 2026 年 9 月 3 日对本地仓库的只读复核。
六个提交日里发生了什么
建立模块化工程，接通记录、待办、搜索、便携运行和后台任务自检。
完成 PySide6 高保真静态复刻和快捷悬浮窗探索，主运行线后来收敛到 PyQt5。
项目空间、文件归档、全局拖放、时间线和待办看板开始形成完整工作流。
集中重构科技风界面，同时修复小窗口、弹窗、悬浮窗和卡片几何问题。
当天 89 次提交，项目分组、资料库、回收站、AI 辅助、便签和稳定性修复快速收敛。
当前 Git 历史终点，提交内容是修复小窗口下拉菜单快速关闭。
7 月 29 日到 9 月 2 日之间，SQLite、API、SSE/Webhook、手机报销入口、Excel 导出、应用图标、自检和 Windows 打包继续推进，但这些内容尚未完整进入 Git 历史。它们只能写作“当前工作树中的后续开发”，不能伪装成已有版本标签或正式发布记录。
提交多，不代表架构已经成熟
把提交标题按一次性关键词归类后，UI、交互与视觉有 56 次，待办、项目与记录有 45 次，修复与稳定性有 44 次，其他功能 15 次，数据、备份与统计 5 次，文档、设计与工具 2 次。
这组分布很符合信息密集型桌面软件的真实成本。把按钮摆出来很快；让小窗口可用、菜单不误关、拖放不丢上下文、后台任务能回收、窗口切换不破坏状态，往往需要更多轮修改。
从能运行到能交付
当前打包使用 PyInstaller 单文件 GUI 模式，console=false，同时带上 momo_app/assets 和 momo_api/web。最新可执行文件生成于 2026 年 9 月 2 日，大小为 74,473,506 字节，也就是 71.02 MiB。
单文件方便交付，却会带来启动解包、依赖收集和问题诊断成本。下一步优化不会只盯着“再小几兆”，而会继续检查三件事：干净 Windows 环境是否能启动，异常是否有可导出的日志，旧数据迁移和恢复是否能在独立目录完成。
现有文档记录过一组压力测试：50,000 条记录的首次导入为 1.838 秒，重新加载为 0.822 秒；10,000 次 get_record 调用为 0.0026 秒；另一组 1,000 条记录、121 次页面切换和刷新约 1.17 秒，RSS 从约 67.2 MB 上升到 69.7 MB 后趋于稳定。这些是项目文档中的既有结果，本次审计没有重新运行，因此它们应当被看作待复验的历史记录，而不是本轮结论。
当前还欠哪些工程工作
仓库没有配置远程地址和发布标签，也没有 CI 工作流；requirements.txt 仍是最低版本约束，不是可复现锁文件；当前工作树存在 20 个 tracked 变更路径和 46 个 untracked 文件。这些都比“167 次提交”更能说明项目现状。
接下来要做的事情很明确：整理工作树并形成可审查提交，补依赖锁定和自动化构建，把恢复测试放到独立目录，继续拆分过大的记录页。一个项目真正稳定的标志不是功能列表变长，而是每次修改都更容易验证，也更容易退回。
评论区