我用 TraeCode 从0开始写了一个智能菜谱小程序

案例与作品
1

我用 TraeCode 从0开始写了一个智能菜谱小程序

一、我是谁，遇到了什么问题:person_gesturing_ok:

我是个普通的技术爱好者，平时工作跟开发沾点边，但不是专业前端。会看微信小程序代码，但让我从0搭项目、设计数据结构、写云开发、调 AI 接口，基本一头雾水 :rofl: 。

事情的起因很生活化——女朋友每天问我"今天吃什么"，我也记不住她爱吃什么、上周吃过啥。我就想给她做个小程序，让她直接在里面点菜、看历史，我也能管理菜品。

需求其实挺明确：

  1. 一个微信小程序，能在手机上点菜
  2. 能上传菜品照片
  3. 能查看每日饮食历史
  4. 两个人（我和女朋友）数据要能实时同步
  5. 后面还想加个 AI 功能：拍一下冰箱，AI 告诉我这些食材能做什么菜

听起来不难，但现实困难摆在那：

  1. 我小程序水平只是"能看懂"，从0搭不下来
  2. 下班只有零碎时间，不想耗在查文档和踩坑上
  3. AI 接口、云同步这块我更不会写

二、我是怎么用 TraeCode 解决这件事的:innocent:

我用的是 TraeCode SOLO 模式（Agent 模式）。

为什么选 SOLO：项目从0开始、没有现成代码要读懂，整个项目交给它一条龙搭更省心；而且涉及小程序前端、云开发、AI 接口好几层，我自己手动改容易漏步骤，让 SOLO 全权负责更稳。

整个过程分四步：

第一步：让 TraeCode 先理解项目和需求

第一次打开 SOLO，我没有直接让它写代码。先花几分钟把需求讲清楚：

我要做一个微信小程序，叫"女朋友菜谱"。 功能：首页、点菜、记录、管理四个页面。

  • 点菜页：从已有菜品里选，加入"今日菜单"，底部显示已选数量
  • 管理页：增删改查菜品，支持上传菜品照片
  • 记录页：按日期分组查看历史点菜记录
  • 数据先存本地，后续要接入云开发做两人同步
  • 后面还要加 AI 功能：拍冰箱识别食材生成菜谱

我把"今天先做本地版，云同步和 AI 是后面的事"这句话明确告诉了它。这点很关键——避免它一开始就把云开发、AI 一股脑塞进来，代码太杂反而不好调。

SOLO 直接给我搭好了项目骨架：app.json 配置四个页面，storage.js 封装本地存储，index/order/record/manage 四个页面的 js/wxml/wxss 全部生成。第一次编译就能跑起来，点菜、加菜、查记录都通了。

第二步：让它定位相关文件，给出修改方案

本地版跑通之后，进入"加云同步"阶段。这一步我没有让它从头重写，而是让它在我已有代码上做改造。

需求是这样写的：

现在要实现情侣间数据同步。两个人加入同一个"房间"，菜谱、今日菜单、点菜记录都实时同步。云环境我已经开通好了，envId 在 config.js 里。

SOLO 直接定位到要改的文件：

  • utils/config.js —— 加云环境配置
  • utils/storage.js —— 加云端读写
  • utils/cloud.js —— 新建，负责云同步逻辑
  • pages/manage/manage.js —— 房间配对 UI

它还主动提醒我：“要在云开发控制台创建 gf_rooms 集合，权限设成所有用户可读可写”。这是我自己绝对想不到的坑——集合权限不对，两个人数据就是同步不上。

image
image2436×1608 361 KB

第三步：根据建议完成修改，再用它辅助调试和检查

云同步代码改完，bug 自然就来了。这一步 SOLO 模式特别省事，我把现象一描述，它直接定位问题。

典型的一次调试：女朋友在小程序里加了菜，我这边管理页根本看不到。

我贴给它：

女朋友添加的菜，我这边和云后台都看不到，怎么回事？

它不是瞎猜，而是先让我确认三件事：

  1. 女朋友是不是加入了同一个房间？
  2. gf_rooms 集合的权限是不是设对了？
  3. 这个集合到底建没建？

一步步排查下来，发现是云数据库里压根没建 gf_rooms 集合，所以"创建房间"这步是失败的。建好集合、设好权限之后，同步就通了。

后面类似这种调试还有不少：

  • 临时图片路径重启就失效 → 用 wx.saveFile 转持久路径
  • 云端照片对方看不到 → 改用云函数管理员权限生成临时链接，绕过云存储权限限制
  • AI 拍冰箱报 400 错误 → deepseek-chat 不支持图片输入，换成 GLM-4V-Flash
  • 数据同步排序混乱、删除不同步 → 把合并策略改成"云端为准"

每个问题都是我把报错或者现象丢给 SOLO，它给方案 + 告诉我哪个文件改哪几行 + 改完要在开发者工具里重新编译。我基本就是复制粘贴 + 点编译，而且他不会盲目推荐，你看，他还会发表自己的看法，哪些功能比较贴合实际，能解决用户痛点，哪些功能很鸡肋，会导致问题，都会帮我说的明明白白，太牛了，666 :clap: :clap: :clap:

image
image1846×1490 241 KB

image
image1932×1258 266 KB

第四步：整理最终变更，并生成可提交的结果

最后一步是上传体验版给女朋友用。SOLO 帮我把要做的操作整理成清单：

  1. 微信开发者工具点"上传"，填版本号 1.0.1
  2. 去微信公众平台后台 → 管理 → 版本管理 → 把刚上传的开发版设为体验版
  3. 体验版页面点"添加体验成员"，输入女朋友微信号
  4. 让她扫体验版二维码进小程序

三、成果展示

最终交付物：

模块 交付内容 状态
微信小程序前端 4 个页面（首页/点菜/记录/管理）完整代码 已上线体验版
本地存储层 storage.js，封装菜品/今日菜单/记录的 CRUD 完成
云同步层 cloud.js，房间配对 + 实时监听 + 数据合并 完成
云函数 analyzeFridge（拍冰箱识别食材）、generateRecipe（AI 配图）、getPhotoUrls（图片权限绕过） 已部署
数据库集合 gf_rooms（房间数据）、gf_sync（备份） 已配置权限

这个小程序解决了我俩"今天吃什么"的日常问题：

  • 女朋友在小程序里点菜，我这边实时收到
  • 我管理菜品库，她那边菜谱自动更新
  • 拍一下冰箱，AI 告诉我们这些食材能做什么菜
  • 想不起昨天吃了什么，翻记录页就有

已经投入我俩日常使用了，每天都在开。

b9b1d88dab9a9d2a9a263843a043a709
b9b1d88dab9a9d2a9a263843a043a709534×1018 146 KB

5669fa161171dc66f85b39fb8c6201d6
5669fa161171dc66f85b39fb8c6201d61080×2400 262 KB

image
image642×1314 105 KB

image
image620×1312 149 KB
:clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap: :clap:

四、效率对比

这是我最想说的一段。

以前怎么做（如果不靠 TraeCode）：

我大概会经历：

  • 查微信小程序官方文档：1-2 天，光看四个页面怎么跳转、生命周期怎么用
  • 查云开发文档：1-2 天，数据库集合、云函数、权限模型，每个都得试一遍
  • 报错就 Google/百度：1-2 周，尤其是云同步、权限这种坑，搜不到具体答案
  • AI 接口接入：1 周，得自己读 DeepSeek/GLM 的 API 文档，调通图片输入
  • 调试：不可估，我这种水平，一个小 bug 卡半天很正常 :rofl: :rofl: :rofl:

保守估计：3-4 周才能做出当前这个完整度，而且很可能中途就放弃了。

现在用 TraeCode SOLO 怎么做：

  • 第一天上午：搭项目骨架，本地版跑通 :person_gesturing_ok:
  • 第一天下午：接入云开发，两个人数据同步通 :smiling_face_with_three_hearts:
  • 后续零碎时间：加 AI 功能、修各种 bug、优化 UI :victory_hand:

总共大概2 周零碎时间做出现在的完整度，包含：

  • 4 个页面 + 完整业务逻辑
  • 云开发数据同步
  • 3 个云函数
  • AI 拍冰箱 + AI 配图
  • 一堆细节 bug 修复
维度 纯手写 TraeCode SOLO
项目搭建 1-2 天查文档 10 分钟出骨架
云同步调试 自己搜索+试错 现象描述完就给方案
AI 接口接入 读文档+自己调 直接生成云函数代码
Bug 修复 卡半天很常见 大部分 10 分钟内出方案
总耗时 3-4 周（很可能放弃） 2 周零碎时间

五、经验和技巧总结

踩过几个坑之后，摸索出几条顺手的方法：

1. 上下文一次给全，比来回补充效果好得多

最典型的就是云同步。一开始如果只说"加个云同步"，SOLO 会问你一堆细节：几个人用？同步什么数据？冲突怎么处理？我后来直接把"两个人、加入同一个房间、菜谱+今日菜单+记录都同步、冲突以云端为准"一次讲完，它给的方案直接能用，几乎没来回。

2. 从0开始的项目用 SOLO，已有项目的小改动更适合 IDE 模式

我这个菜谱是从0搭的，整个项目交给 SOLO 一条龙做最顺。但如果是公司里已经有大项目、只想改一个文件的一个函数，用 IDE 模式（让 Trae 只在你需要的时候介入）会更可控，避免它误改其他地方。

3. 调试时，把"现象 + 你做过什么"一起说

很多人报 bug 只说"不行"“不好用”，SOLO 只能瞎猜。我后来都是这样开头：

我做了 X，期望 Y，实际却 Z。代码我已经改成了……，编译也重新编译了。

它定位问题快很多，而且会主动让你确认一些前置条件（比如那个"看不到数据"的 bug，它直接让我先确认三件事，省了我瞎改代码的时间）。