Can One Person Build a Real App with AI? A Meal Assistant Case Study

Background

The author experimented with AI-assisted programming to test whether a single person can turn an idea into a usable software product. They built a meal assistant tool ("膳食助手") that started as a simple WeChat Mini Program for AI recipe recommendations and evolved into a full multi-platform project including Android, iOS, and a web admin panel.

Product Positioning

The author initially rushed into coding with a vague prompt, resulting in a feature-heavy but unfocused first version. They then stepped back and asked three key questions:

What problem does this tool solve for users?

Would I personally use this tool long-term?

What are the competing tools and what is our advantage?

This reflection led to a clear MVP scope: user side handles AI recipe recommendation, recipe browsing, and diet logging; admin side manages recipe data collection and AI prompt configuration. The principle was to get functionality running first, then iterate.

Cross-Platform Technology Choice

To avoid needing separate developers for WeChat Mini Program, Android, and iOS, the author chose UniApp (Vue.js-based cross-platform framework) for the user client, enabling one codebase to deploy to all three targets plus H5. The backend uses Java 8, Spring Boot 2.7.x, MyBatis-Plus, MySQL 8, JWT . The admin panel uses Vue 3, TypeScript, Vite, Ant Design Vue 4 . AI integration is a custom AiService calling LLMs via HTTP with a mock fallback.

AI-Driven Development Workflow

The author wrote virtually no code. Their role was to craft a detailed prompt and perform acceptance testing. The initial prompt (shown below) specified product goals, tech stack, backend modules, API contracts, data models, frontend pages, admin features, deployment scripts, and a phased implementation plan.

你是全栈工程师。当前是一个全新空仓库，请从零实现「膳食助手」MVP，按下列规格直接编码并可持续迭代。不要编造或写入真实密钥、AppSecret、数据库口令、内网 IP；所有机密用环境变量占位。

════════════════════════════════════
一、产品目标
════════════════════════════════════
做一个健康饮食助手平台，包含三端 + 可选采集服务：
1) 用户端（uni-app）：微信小程序 + App
2) 运营后台（Web Admin）
3) Java 单体后端 API
4) （可选二期）Python 菜谱采集服务，经 HTTP 被 Java 调用

核心闭环：
登录 → 健康档案 → 记饮食（AI 估营养）→ 按餐次推荐菜谱 → 体重/收藏；
后台维护用户、饮食、菜谱知识库、分类标签、AI Prompt。

品牌名对用户展示用「膳食助手」，避免过度强调「生成式大模型」文案（审核友好）。

════════════════════════════════════
二、技术栈（必须遵守）
════════════════════════════════════
- 后端：Java 8、Spring Boot 2.7.x、MyBatis-Plus、MySQL 8、Hutool、JWT
- 用户端：uni-app + Vue3 + TypeScript + Pinia
- 后台：Vue3 + TypeScript + Vite + Ant Design Vue 4 + Axios
- 约束：单体应用；无微服务、无 Spring Cloud、无 Spring AI/LangChain、无复杂 Agent
- AI：自研简单 AiService（HTTP 调大模型）；失败可降级 Mock，保证演示闭环
- Long/雪花 ID：JSON 序列化为字符串，防前端精度丢失；反序列化兼容 number/string

仓库目录建议：
/
 backend/
 miniapp/
 admin/
 recipe-crawler/   # 可后做
 script/           # 启停、构建脚本
 docs/
 .env.example      # 仅占位符，无真实机密
 README.md

════════════════════════════════════
三、后端规格
════════════════════════════════════

【模块包名示例】com.mealmind.fitness

分层：controller / service / mapper / entity / dto / vo / config / common / ai / recipe

【通用】
- 统一响应：{ code:0, message, data }；业务异常 BizException + 全局异常处理
- JWT：Authorization: Bearer <token>；用户端与后台可分密钥或同密钥不同角色声明
- 配置：application.yml + application-dev.yml + application-prod.yml
- 端口建议：dev 后端 8080；prod 可用 18301（可配置）
- 日志写文件可滚动

【用户端主要能力】
1. 登录
   - 微信：code 换 openid/session，发 JWT（WX_APPID/WX_SECRET 环境变量，缺省可开发假登录）
   - App：设备 ID 登录（或游客转正式账号策略自定，需文档说明）
2. 健康档案：性别/年龄/身高/体重/目标体重/目标文案；可算每日热量预算
3. 首页聚合：今日热量、剩余热量、体重进度、今日是否已记餐/称重
4. 饮食：创建记录（含 AI 分析）、列表、按餐次筛选
5. 菜谱推荐（核心，必须严格实现）：
   POST /recipe/recommend/by-tags
   推荐池规则（硬规则）：
   - 只查询「餐次同名分类」下 status=上架 的菜谱（分类名精确：早餐/午餐/晚餐/加餐）
   - 用户 tagIds 命中的菜谱排前面；未命中仍保留在同分类池中
   - 其次可按 targetType 命中排序；早餐/加餐偏低热量，午晚餐可偏高热量
   - 取前 N 条（配置 candidate-limit，默认约 15）交给 AiService 挑选 recommend-count（默认 3）条
   - 换一批必须尊重 excludeRecipeIds，禁止为了凑数悄悄放开排除导致重复同一批
   - 分类下无菜 / 排除后无菜：返回明确业务错误文案
6. 菜谱详情、标签列表、收藏开关
7. 体重记录、简单成就（可选 MVP）

【运营后台主要能力】
- 管理员登录（首次启动可自动建 admin/admin，并提示改密）
- 仪表盘统计（用户数、饮食数等，可简）
- 用户列表/详情
- 饮食记录查看
- 菜谱知识库：分类、标签、菜谱 CRUD（封面/材料/步骤/目标类型/分类）
- AI Prompt 配置（如 RECIPE_TOP3_RECOMMEND），无配置用代码内默认 Prompt
- AI 调试：对指定用户复跑推荐并展示候选/Prompt/响应（可后做）
- （可选）采集任务管理：调 recipe-crawler HTTP

【菜谱数据模型要点】
- recipe_category：至少内置/可维护 早餐、午餐、晚餐、加餐
- recipe_tag / recipe_tag_relation
- recipe_library：name, cover, description, category_id, target_type(日常均衡/减脂/增肌/控糖), calorie/protein/fat/carbohydrate, cook_time, status, recommend_reason...
- recipe_material / recipe_step
- 默认目标类型倾向「日常均衡」，不要把所有菜一律标减脂

【AI 接口形态】
- analyzeDiet(foodDesc) → 热量与三大营养素 + 简短建议
- recommendRecipes(user, todayDiets, candidates, remainingCalorie, mealType) → 只能从候选 ID 中选；Prompt 强调当前餐次；禁止输出外链/站点名

════════════════════════════════════
四、用户端（miniapp）规格
════════════════════════════════════
Tab：首页 / 菜谱推荐 / 饮食 / 我的

关键页面：
- login：自定义导航；显著「返回」+「暂不登录，先逛逛」；协议默认未勾选，未同意不可登录
- home：游客可逛；记餐/体重等写操作再登录；勿反复强制弹登录
- recipe-center/recommend：必选餐次（早/午/晚/加餐），偏好含目标（默认日常均衡）+ 可选标签；点推荐再登录
- analyzing → result：结果缓存；「换一批」累加 excludeRecipeIds 再请求
- diet list/record、profile、weight、favorite、legal、about、mine

请求层：
- 统一 baseURL 配置（dev/prod）
- 401 防抖：短时间只 toast + 跳登录一次
- ID 全程当 string 处理

审核相关：
- 浏览不强制登录；登录可取消
- 弱化「AI/大模型」营销文案；保留核心记餐估算能力

════════════════════════════════════
五、Admin 规格
════════════════════════════════════
- 登录页 + 布局侧栏
- 路由守卫
- 菜谱列表筛选（分类/目标/关键词）、编辑表单（分类下拉含四餐次、目标四选一默认日常均衡）
- 分类/标签管理
- 用户与饮食只读列表即可先 MVP

════════════════════════════════════
六、部署与脚本（可后置但预留）
════════════════════════════════════
- .env.example 列出：DB_*、JWT_*、WX_*、RECIPE_CRAWLER_URL、RECIPE_CRAWLER_TOKEN（值用占位）
- script/docker-start.sh：构建 backend jar + admin dist；Docker 跑 backend/admin；Linux 可用 --network host；nginx 配置生成到项目内 script/.generated/，不要写到易被 Docker 建成目录的错误路径
- 不要把真实 .env 提交进 git

════════════════════════════════════
七、实现顺序（请按此直接开干）
════════════════════════════════════
Phase 1：backend 骨架 + schema.sql + JWT + 用户/档案/饮食 CRUD + AiService Mock
Phase 2：菜谱表结构 + 后台菜谱/分类/标签 CRUD + 推荐 by-tags（分类硬池规则）
Phase 3：miniapp 页面闭环（登录可取消、推荐、记餐、结果换一批）
Phase 4：admin 完善 + Prompt 配置 + 生产脚本
Phase 5（可选）：recipe-crawler

每完成一阶段：给出目录树、关键接口清单、本地启动命令（不含机密）。

════════════════════════════════════
八、编码规范
════════════════════════════════════
- 代码可读、少过度抽象；注释只解释非显而易见逻辑
- 用户可见文案中文
- 改动聚焦需求；不要生成无关 Markdown 文档除非我要求
- 先实现可运行 MVP，再优化 UI
- 任何示例配置使用 YOUR_*_HERE 占位

现在从 Phase 1 开始：在空仓库创建 backend 可运行骨架（含 schema、统一返回、健康检查、管理员初始化），并简述下一步 Phase 2 计划。

To reduce frequent confirmation prompts, the author added: "除涉及系统权限等需要人工确认的情况外，其它问题请自行分析和处理，不要频繁对答。"

Acceptance Testing

Admin Interface

After startup, the admin panel shows dashboard, AI configuration, recipe crawling, and recipe management screens.

WeChat Mini Program

The mini program runs in the WeChat Developer Tool and on real devices, showing login, recipe recommendation, and diet logging flows.

Android / iOS Apps

Packaging for Android and iOS requires HBuilderX cloud packaging. The author demonstrates selecting "App-Android/IOS-云打包", filling metadata, and downloading the generated APK/IPA. The installed app mirrors the mini program UI and interaction.

Pitfalls Encountered

Hallucinations : AI sometimes ignores explicit UI instructions (e.g., producing layout B instead of A). Switching models often resolves this.

Code readability : Generated code is hard for humans to maintain. The author found that providing a personal style guide/document before coding improves consistency.

Hidden bugs : Time format errors, empty parameters, invalid query conditions, missing pagination (full table scans), and N+1 queries in loops. These appear when prompts lack constraints. A post-development global scan for common vulnerabilities is recommended.

Conclusion

The project demonstrates that AI can enable a solo developer to deliver a working multi-platform product, shortening the idea-to-implementation gap. However, AI does not eliminate software complexity. Requirements analysis, product design, architecture decisions, testing, and long-term maintenance still require human judgment. For large, complex systems, the feasibility of full AI delegation remains uncertain. The key takeaway: AI is a powerful accelerator, but the developer remains the architect and validator.