【Code with SOLO】用 SOLO + MTC 从零撸了一个无广告日程清单 App：一个非专业开发者的"独立开发"初体验
一、摘要
我用 TRAE SOLO（编码）+ MTC（More Than Coding，非编码工作流）从零搭建了一个无广告的日程清单应用——List Finished。整个项目从需求梳理、UI 设计、前后端开发到部署文档，全程通过 TRAE 完成。作为一个非全职开发者，我用 SOLO 搞定了 React + FastAPI 全栈架构、Zustand 状态管理、PWA 离线支持、Capacitor Android 打包等全套技术方案，MTC 则帮我搞定了 PRD 文档、竞品分析、UI 设计方案等非编码工作。整个过程让我真正体会到了"想法即产品"——我不再只是用户，我成了自己产品的创造者。
二、背景
我平时是一个重度日程管理用户。手机里装过不下十个待办/清单类 App——滴答清单、Todoist、Microsoft To Do、各种小众清单工具……但每一个用久了都有让我忍不住想卸载的毛病：
- 广告太多：免费版恨不得在每一个操作后面塞一个开屏广告
- 核心功能收费：想用个日历视图？付费。想重复任务？付费。想子任务？还是付费
- 功能臃肿：我只是想记个待办，你给我塞社交、商城、积分体系是什么意思
- 数据不自由：导出数据要付费，API 不开放，数据被锁在别人服务器里
有一天我突发奇想：我自己写一个不行吗？
但我不是专业开发者——前端能写一点 React，后端 Python 还行，但让我一个人搞定全栈 + 移动端 + 部署，说实话心里没底。直到我发现了 TRAE SOLO 和它的 MTC 模式。
三、实践过程
1. 用 MTC 做产品经理——“先想清楚再动手”
我没有一上来就写代码。我先用 TRAE 的 MTC 模式（More Than Coding）做了一轮产品梳理。
我对 MTC 说的话大概是：
我想做一个无广告的日程清单 App，核心是简洁、免费、数据自由。帮我分析一下市面上主流产品的优缺点，然后写一份 PRD。
MTC 帮我做了几件事：
- 竞品分析：对比了滴答清单、Todoist、Microsoft To Do 等主流产品的功能矩阵和定价策略，帮我找到了差异化定位——“极简 + 全功能免费 + PWA 离线”
- PRD 文档：输出了完整的产品需求文档，包括功能优先级排序（MVP 先做什么、V2 再做什么）
- UI 设计方案：基于"移动优先"原则，给出了日视图/周视图/月视图的布局方案，配色走清新简洁路线
这一步大概花了十几分钟，但省掉了我在纸上画草图、纠结功能优先级的半天时间。
2. 用 SOLO 搭技术骨架——“我负责想法，它负责实现”
需求清楚了，我切到 SOLO 模式开始写代码。我对 SOLO 的第一句话是：
帮我从零搭建一个日程清单应用，前端 React + TypeScript + Vite + Tailwind，后端 FastAPI + SQLAlchemy + SQLite，要支持 PWA 离线和 Android 打包。
SOLO 几分钟就给我搭好了整个项目骨架：
├── src/ # 前端源码
│ ├── api/ # API 请求层
│ ├── components/ # UI 组件
│ ├── hooks/ # 自定义 Hooks
│ ├── store/ # Zustand 状态管理
│ ├── sync/ # 离线同步队列
│ ├── utils/ # 工具函数
│ └── presentation/pages/ # 页面
├── backend/ # Python 后端
│ ├── app/
│ │ ├── models/ # SQLAlchemy 模型
│ │ ├── routes/ # API 路由
│ │ ├── schemas/ # Pydantic 校验
│ │ └── services/ # 业务逻辑
│ └── Dockerfile
├── public/ # PWA 静态资源
└── capacitor.config.ts # Android 打包配置
91 个源文件，前后端分层清晰。说实话，如果让我自己从零搭这个结构，光是想目录命名就要纠结半天。
3. 核心功能开发——“最难的部分 SOLO 都帮我扛了”
任务 CRUD + 乐观更新
这是整个应用的核心。用户创建、编辑、删除、完成任务，每一个操作都要即时响应——不能让用户点了"完成"之后转圈等两秒。
SOLO 帮我在 Zustand store 里实现了 乐观更新 + 失败回滚 机制：先更新 UI 给用户即时反馈，再异步调后端 API，如果失败了自动撤回并提示错误。12 个 CRUD 操作全部覆盖，体验非常丝滑。
日/周/月三种视图
这个功能我自己估计要写两三天——三种完全不同的布局逻辑、任务卡片的位置计算、滚动联动……SOLO 帮我在一个下午就搞定了，日视图按时间轴排、周视图按七天网格排、月视图按日历格子排，切换的时候动画过渡也很自然。
重复任务
“每天早上 9 点喝咖啡”、“每周一开周会”、“每月 1 号交房租”——这种重复任务实现起来比想象中复杂。要处理重复间隔（每天/每周/每月）、结束条件（永不结束/指定日期/指定次数）、例外日期（这周二不开会）……
SOLO 帮我设计了一套完整的 recurrence 数据结构，前端用 RecurrenceSettings 组件配置，后端用 recurrence_utils 模块解析，生成未来的任务实例。
PWA 离线 + 数据同步
这是我最想要的功能——断网也能用。SOLO 帮我实现了：
- Service Worker 缓存静态资源，断网时从缓存加载
- 离线操作自动写入本地同步队列（localStorage）
- 联网后自动将队列中的操作同步到后端
- 同步失败自动重试
Android 打包
通过 Capacitor 把 Web 应用打包成 Android APK。SOLO 帮我配好了 capacitor.config.ts，处理了 Android 权限声明、状态栏适配、返回键拦截等原生端的问题。
4. 踩过的坑
坑一：日期处理的时区地狱
这个坑差点把我逼疯。项目里需要处理"今天"、“明天”、"这周"等相对日期概念，但 JavaScript 的 Date 对象在不同时区下行为不一致。SOLO 一开始也踩了——用了 getFullYear() 而不是 getUTCFullYear()，导致不同时区的用户看到的"今天"不一样。
后来 SOLO 统一到了一套 UTC 方案：所有日期在服务端以 UTC 存储，前端显示时根据用户本地时区转换。中间还做了向后兼容处理，确保已有的数据不会因为这次修改而出问题。
坑二：Zustand 状态和后端数据的同步
乐观更新听起来简单，但真正做起来全是边界情况：用户快速连续点击怎么办？网络请求顺序乱了怎么办？用户在请求还没回来的时候又编辑了同一条任务怎么办？
SOLO 帮我处理了这些并发场景——每次操作生成唯一 ID，回滚时精确匹配；API 响应回来后用服务端数据覆盖本地临时数据，确保最终一致性。
坑三：测试环境的 import.meta 不兼容
Vite 用 import.meta.env 读环境变量，但 Jest 测试环境不认识这个语法。SOLO 试了好几种方案都翻车了，最后用了一个很聪明的办法——直接 mock 掉整个 API 模块，测试代码完全不触碰 import.meta。
四、成果展示
项目信息
- 项目名称：List Finished
- 项目仓库：GitHub - vernal-breeze/DailyList_app
- 技术栈：React 18 + TypeScript + Vite + Zustand + Tailwind CSS + antd-mobile（前端）、FastAPI + SQLAlchemy + SQLite（后端）、Capacitor（Android）
核心功能
| 功能 | 说明 |
|---|---|
| 多视图切换 | 日视图 / 周视图 / 月视图 / 日程列表，一键切换 |
| 子任务嵌套 | 支持多级子任务，大任务拆小，逐步搞定 |
| 重复任务 | 每日/每周/每月重复，支持自定义间隔和结束条件 |
| PWA 离线 | Service Worker 缓存 + 离线操作队列，断网也能用 |
| 撤销/重做 | Ctrl+Z 撤销，Ctrl+Shift+Z 重做，手滑不怕 |
| 快速添加 | Ctrl+N 全局快捷键，想到什么立刻记下来 |
| Android 客户端 | Capacitor 打包，装到手机上就是原生 App 的体验 |
| 数据同步 | 离线操作自动入队，联网后无缝同步到后端 |
| 无广告 | 永远免费，永远无广告，代码开源 |
技术亮点
| 亮点 | 说明 |
|---|---|
| 乐观更新 + 回滚 | 12 个 CRUD 操作全部覆盖，UI 响应零延迟 |
| 离线优先架构 | Service Worker + 同步队列，弱网/断网场景完整支持 |
| 全局异常处理 | 后端 422/500 统一错误格式，前端不再白屏 |
| API 分页/过滤/排序 | 支持按优先级、分类、完成状态筛选 |
| CI/CD | GitHub Actions 自动跑 lint + 类型检查 + 测试 + 构建 |
| Docker 部署 | 多阶段构建 + 非 root 用户 + 健康检查 |
极速启动
# 1. 克隆仓库
git clone https://github.com/vernal-breeze/DailyList_app.git
cd DailyList_app
# 2. 启动后端
cd backend && pip install -r requirements.txt && python -m uvicorn app.main:app --reload &
# 3. 启动前端
cd .. && npm install && npm run dev
打开浏览器访问 http://localhost:5173，开始管理你的日程。
五、效果与总结
从"用户"到"创造者"
说实话，这个项目对我最大的意义不是"我写了一个 App"，而是我第一次完整经历了从想法到产品的全过程。
以前我用别人的 App，遇到不满意的地方只能吐槽、写反馈、然后等半年也不一定改。现在我不爽了直接打开 TRAE 改代码，五分钟就能上线新功能。这种掌控感是任何第三方工具给不了的。
SOLO + MTC 的分工体验
整个过程中，SOLO 和 MTC 各司其职，配合得非常自然：
| 阶段 | 用什么 | 做了什么 |
|---|---|---|
| 需求分析 | MTC | 竞品分析、PRD 文档、UI 设计方案 |
| 技术选型 | SOLO | 确定技术栈、搭建项目骨架 |
| 核心开发 | SOLO | 前后端全部功能实现 |
| 代码优化 | SOLO | 重构、加测试、搭 CI/CD |
| 文档输出 | MTC | README、部署文档、参赛文章 |
MTC 让我在写代码之前就把产品想清楚，SOLO 让我在想清楚之后快速实现。两个模式组合起来，就是一个完整的"单人产品团队"。
说点掏心窝的话
我之前一直觉得"独立开发"是专业程序员的事——要会前端、会后端、会设计、会运维……一个人怎么可能搞得定？但 TRAE SOLO + MTC 真的把这个门槛降到了"只要你有想法"。
我不是说它完美无缺。中间也踩了不少坑，有些地方 SOLO 生成的代码我也要自己改一改。但关键是——它让我迈出了从 0 到 1 的那一步。没有 SOLO，这个项目可能永远只存在于我的脑子里。
下一步规划
- 认证系统：加用户登录，支持多设备数据同步
- 日历集成：接入系统日历，和其他 App 联动
- 小组件：Android 桌面小组件，不用打开 App 就能看到今天的待办
- 主题定制：支持自定义配色和字体
想和大家聊聊
- 你最受不了现有日程/待办 App 的什么"反人类设计"？
- 如果让你自己做一个 App，你最想解决自己生活中的什么痛点？
- 对于"非专业开发者用 AI 做产品"这件事，你怎么看？
欢迎在评论区交流！如果有什么功能建议，直接说，我可能下一个版本就加上了。
参与贡献
欢迎提交 PR 或 Issue，一起把这个 App 做得更好！
- Fork 本仓库
- 创建特性分支（
git checkout -b feature/AmazingFeature） - 提交更改（
git commit -m 'Add some AmazingFeature'） - 推送到分支（
git push origin feature/AmazingFeature） - 打开 Pull Request
- github网址
开源协议
本项目采用 MIT License 协议开源。