SmartDietManager 项目复盘 — 8 周开发回顾
项目概览
| 项目 | SmartDietManager — 家庭饮食管理应用 |
|---|---|
| 时间 | 2026-04-01 ~ 2026-05-28（8 周） |
| 技术栈 | Qt 6.5 + QML + C++17 + SQLite |
| AI 工具 | 全程使用 AI 辅助开发 |
| 状态 | v1.0 可交付 |
做得好的
- AI 驱动的前端开发：QML UI 代码 80% 由 AI 生成，人工主要负责调整布局和动画细节
- Repository 模式统一了数据访问：从食材到菜谱到家庭，全部走 Repository + Service 两层，新增模块成本极低
- Mifflin-St Jeor 公式实现：TDEE 计算准确度经过验证，与专业营养师 App 误差 <5 大卡
- Argon2id 安全方案：从第一天就定了最高安全标准，没有后期返工
待改进
- QML 状态管理混乱：中后期页面增多后，属性绑定和信号传递变得难以追踪，缺少统一的状态管理方案
- 数据库迁移没有自动化：每次改表结构都是手动 ALTER TABLE，应该用 migration 工具
- 离线功能缺失：所有数据都在本地 SQLite，没有云端同步，家庭共享实际体验打折扣
- 推荐算法过于简单：当前只是加权打分，没有引入协同过滤或 ML，推荐质量有限
AI 辅助开发的体会
- 设计文档阶段 AI 贡献最大：PRD、架构设计、数据库设计、接口文档，AI 生成初稿，人工精修
- QML 代码生成质量高：声明式 UI 和 AI 很契合，描述需求 → 生成完整页面
- C++ 业务逻辑需要重写：AI 生成的 C++ 代码逻辑正确率约 70%，复杂交互（家庭解散事务）需要完全重写
- 最大的坑：AI 生成的
QSqlQuery::prepare()+bindValue()代码在循环中使用时产生了隐蔽的绑定错误，直到测试才发现
如果重来一次
- 引入 QML 状态管理库（如 QML Store 或自定义 ViewModel 模式）
- 从第一天就用 migration 管理数据库变更
- 推荐引擎应该先做 A/B 测试验证效果再上线，而不是”感觉还行”就交付
- 缩小 MVP 范围 — 5 个模块砍成 3 个，集中精力打磨核心体验