开发记 - bonflow 植物养护&识别 App
Growth in order, rhythm in form.
在秩序中生长，在形式中律动。
上个月的主要进度：完成了一款植物识别和生长记录 App，上周五已提交 App Store 审核，目前仅支持 iOS 18 以上设备。
这是一个整合检验各种 AI 工具和近两年工作展示的 MVP（Minimum Viable Product）。主要是为了好玩，当然也是一个很好的简历展示项目。
💡 Idea 的开始
3 月是植物人的忙碌季。给大部分植物换了盆，沙漠玫瑰切了枝，还野心勃勃买了一颗 40 块的罗汉松。
问题接踵而至：
- 换盆后的进度很难掌握，重剪后不知是否过度
- 咖啡渣培育的土发现虫害，被迫更换营养土
- 营养土不透气导致闷根（也可能最近天气过于潮湿）
- 最后换成了赤玉土，才算暂时稳定
忙活的过程中，我希望有一个可以记录植物生长的 App——不是简单的提醒浇水，而是完整记录每一次换土、修剪、施肥的决策和后续反馈。
市面上的产品，要么丑、要么贵、要么没有国区。
🏷️ 名字的诞生
在 Gemini 的指导下，我描述了需求：
“我想起一个 App 的名字，用于记录植物的生长记录和日常护养，倾向于 rook、flow”，试试结合 ぼんさい（Bonsai）
Gemini 的建议：
结构与音律的融合 (Structural Fusion)：直接将 “Bonsai” 的词根与你喜欢的词结合，创造出一种类似高端硬件品牌的命名感。
- Bonflow：将"盆 (Bon)“与"流动 (Flow)“结合。听起来非常顺滑，寓意植物在器皿中展现出的生命韵律。
- Sairook：取自"栽 (Sai)“与"堡垒 (Rook)"。给人一种非常扎实、可靠的记录感，像是一个守护植物生长的坚固容器。
- Sai-Logic：栽种逻辑。听起来像是一个精密、工程化的养护工具，符合你对"系统性"记录的需求。
Bonflow 成功诞生。
📱 iOS 历险记
App 的开发从 iOS 开始。年前做过一个拳击硬件的 App，就设计规范和开发文档来说，感觉是个比较容易让 AI 协助的平台。
比较麻烦的是国内的备案。
网站备案
大概花了一周。
审核需要提供隐私政策链接，就先弄了个网站：阿里云注册了 bonflow.com.cn 域名（¥38/年），买了个 ¥99/年的云服务器，写了个七七八八的内容直接在阿里云上申请网站备案。
⚠️ 事后诸葛亮：其实有链接就可以，直接在 Notion 链接挂过去就行……这一步有点没太大必要，就当作练手了。
有了备案号之后在网站页脚加了一下，还要去公安部备个案（装了好几个 App 还有各种平台认证，这一步还没弄完……）
App 备案
这一步大概也是一周。把一些 Developer 的证书内容填一填就差不多。
注意：申请的名字要和 App 本身的名字完全一致（包括大小写），不然在开发者平台无法添加申请下来的备案号。
🛠️ 使用的工具
Claude Code
最开始尝试了三方 API（太贵），试了 Qwen Coding Plan（太烂），后面买了一个 Claude Pro。
5 小时限额之后就歇一歇，梳理文档、整理逻辑或者去调整设计稿，整个一个劳逸结合。
Stitch
MCP 直接接入 Claude Code，但效果并不十分理想。每次叫 Stitch 更新一下设计规范，它就会生成一份新的，导致文件本身有很多份设计规范。
后面我会手动把 DESIGN.md 文件复制到 VS Code 里面，并告诉 Claude Code：
“你的设计规范在这里”
主要的设计页面会打包到一个文件夹，告诉 Claude Code：
“你的设计稿在这里”
Obsidian
对于一些逻辑比较复杂、会出现 Bug 的页面，我会叫 Claude 先根据现在的逻辑整理一份 Markdown，然后在接入阿里云 Coding Plan（量大管饱）的 Obsidian 中慢慢梳理，再导入回 VS Code。
🌿 关于植物的识别
识别部分主要有两部分内容：端侧识别和云端识别。
端侧识别
端侧部署了一个可以识别 66 种植物的 YOLO11n 分类模型。
最开始尝试 YOLOv26 去做训练，发现我的 Mac Mini 速度实在太慢（大概是 26 混合了两种模型的算法，算起来会很乱），而且精度并没有提高。就回到了 v11 版本，目前 YOLO11n 的识别过程大概在 2s 左右。还存在一些识别不准、素材校准的问题。
模型大小筛选
按照 iPhone 12 以上的算力筛选（iPhone 12 搭载 A14 Bionic，有 16 TOPS 的 Neural Engine），经过 CoreML 转换后的实际可用范围大致是：
| 型号 | 参数量 | 模型大小 | iPhone 12 预估 FPS | 适用场景 |
|---|---|---|---|---|
| YOLO11n | 2.6M | ~6MB | 30–60 FPS | 实时摄像头 |
| YOLO11s | 9.4M | ~18MB | 20–35 FPS | 实时摄像头 |
| YOLO11m | 20.1M | ~40MB | 10–20 FPS | 拍照识别（推荐） |
| YOLO11l | 25.3M | ~50MB | 5–12 FPS | 可用但偏慢 |
| YOLO11x | 56.9M | ~110MB | <5 FPS | 不适合 |
YOLO11n-cls 目录结构
plant_classify/
├── data.yaml
├── train/
│ ├── pothos/ # 绿萝
│ │ ├── pothos_001.jpg
│ │ ├── pothos_002.jpg
│ │ └── ... (≥200 张)
│ ├── heartleaf_philodendron/ # 心叶蔓绿绒
│ ├── monstera_deliciosa/ # 龟背竹
│ └── ... (66 类)
├── val/ # 结构同 train，约 20% 数量
└── test/ # 结构同 train，约 10% 数量
识别的种类
共 66 类，按科属分类：
| 科属 | 种类数 | 代表植物 |
|---|---|---|
| 天南星科 | 13 | 龟背竹、绿萝、心叶蔓绿绒、白掌、合果芋 |
| 榕属 | 5 | 橡皮树、琴叶榕、垂叶榕 |
| 龙血树属 | 4 | 富贵竹、巴西铁树、龙血树 |
| 棕榈科 | 4 | 散尾葵、袖珍椰子 |
| 虎皮兰属 | 3 | 虎皮兰、金边虎皮兰 |
| 竹芋科 | 5 | 彩虹竹芋、孔雀竹芋 |
| 小型观叶 | 9 | 吊兰、网纹草、镜面草 |
| 蕨类 | 4 | 波士顿蕨、铁线蕨 |
| 开花类 | 7 | 蝴蝶兰、兰花、长寿花 |
| 木本盆栽 | 5 | 发财树、鸭脚木 |
| 多肉/仙人掌 | 6 | 芦荟、玉露、石莲花 |
| 气生 | 1 | 空气凤梨 |
数据集
Claude 帮我按照识别难易程度配置数据数量：
| 难度 | 代表种类 | 每类最少张数 | 建议张数 |
|---|---|---|---|
| ⭐ 易识别 | 龟背竹、虎皮兰、芦荟 | 150 张 | 300 张 |
| ⭐⭐ 易混淆 | 绿萝 vs 心叶蔓绿绒 | 300 张 | 500 张 |
| ⭐⭐⭐ 品种多 | 竹芋类、石莲花 | 500 张 | 800 张 |
根据版权和常见室内植物的数量建议写了爬虫自动爬取。
训练
依旧是 Claude 的指导。
YOLO11s-cls 的模块结构与 freeze 值对照：
freeze 值 |
冻结到哪里 | 效果 | 适用场景 |
|---|---|---|---|
freeze=0 |
不冻结 | Full fine-tune | 数据 >500 张/类 |
freeze=2 |
冻结前 2 个 Conv | 保留最基础边缘检测 | 数据较多 |
freeze=5 |
冻结前 5 个模块 | 保留低级特征（边缘/纹理） | 数据中等，200–500 张/类 |
freeze=9 |
冻结到 SPPF 前 | 保留大部分 backbone | 数据较少，100–200 张/类 |
freeze=11 |
冻结整个 backbone | 只训练分类头 | 数据极少，<100 张/类 |
# 训练命令
yolo classify train \
model=yolo11s-cls.pt \
data=plant_classify/ \
epochs=100 \
imgsz=224 \
freeze=5 \
lr0=0.001
云端识别
写了 3 个 Prompt，模型依旧使用量大管饱的阿里云 Coding Plan，返回时间大概 30-40s。
三个 Prompt 的调用时机汇总：
| Prompt | 触发时机 | 调用频率 |
|---|---|---|
| 植物识别与健康分析 | 用户拍照时 | 按需，用户主动触发 |
| 历史养护记录建议 | 用户查看植物详情页 / 添加养护记录后 | 每次添加记录后更新 |
| 今日环境推荐 | 每天早上 8 点推送 / 用户打开首页 | 每天一次，缓存当天结果 |
💰 成本计算
开发期（一次性投入）
| 项目 | 费用 | 备注 |
|---|---|---|
| Token 消耗 | ~$80 (≈¥580) | 前期直接调取三方 API，账单爆表 |
| Claude Pro | $20 (≈¥145) | 1 个月，5 小时/天限额 |
| Coding Plan | ¥40 | 1 个月，阿里云，量大管饱 |
| 备案时间 | ~20 天 | 网站+App 前后 |
| 小计 | ~¥765 | 开发期一次性投入 |
运营期（按年）
| 项目 | 费用 | 备注 |
|---|---|---|
| Apple 开发者账户 | ¥688/年 | 必须 |
| 域名 | ¥38/年 | bonflow.com.cn |
| 云服务器 | ¥99/年 | 阿里云轻量应用服务器 |
| 小计 | ¥825/年 | 固定运营成本 |
后期 API 成本（预估）
切换回 API 后，按日活用户和调用频率预估：
| 场景 | 单次 Token | 日调用次数 | 月成本预估 |
|---|---|---|---|
| 植物识别（按需） | ~500 | 10 次/用户 | ¥0.5/用户 |
| 养护记录建议 | ~800 | 1 次/用户 | ¥0.3/用户 |
| 每日环境推荐 | ~300 | 1 次/用户 | ¥0.2/用户 |
| 合计 | - | - | ~¥1/用户/月 |
假设 100 日活用户，月 API 成本约 ¥100；1000 日活用户约 ¥1000/月。
总览
| 阶段 | 费用 |
|---|---|
| 开发期（一次性） | ~¥765 |
| 运营期（首年） | ¥825 |
| 首年总计 | ~¥1,590 |
| 次年（仅运营） | ¥825/年 |
📝 总结
目前 App 还有很多问题：
- 端侧识别率不高
- API 调取时间过长
- FLOW 部分的设想没有十分完善
但作为一个近两年学习成果的展示，还是蛮不错的 Demo。可以展示：
- 端侧部署能力（CoreML + YOLO）
- 云端 API 集成
- AI 工具的运用（Claude Code、Stitch、Obsidian）
- 完整的产品思维和执行能力
是个蛮好的面试展示项目。
下一步计划：
- 优化端侧模型准确率（增加训练数据、调整阈值）
- 缩短云端 API 响应时间（优化 Prompt、考虑缓存策略）
- 完善 FLOW 页面的时间滑块和生长曲线可视化
项目地址：bonflow.com.cn
App Store：待上架 🚧