辰曦花卉智能经营系统 + 飞书 AI 机器人矩阵
一家真实花卉批发企业每天在用的经营系统：员工在飞书群里发一句话就能接单出库，5 个 AI Agent 代跑流程，企业累计销售 540 万+。
做成什么
540 万+（3 基地 · 65 品种 · 56 客户 · 10 员工）
企业累计销售
处理订单 1,027 单 · 结算 34 万+
上线首月
零——只读为主 + 白名单 + 人工确认
AI 写入权限
问题
花卉批发的出库、库存、对账、资金全靠手工记录，仓库现场录不进去，老板看不到实时经营数据。更难的一层是：真让 AI 接管录单和查账，老板凭什么信它不会把账写坏？
做法
分两个阶段长出来的。① 先用飞书多维表格搭 MVP，几天内跑通业务闭环、验证真实需求；等业务长到 3 个基地、65 个品种、56 家客户、10 名员工，多维表格在并发写入、对账一致性和复杂查询上撑不住了，② 重构为 Flask + PostgreSQL 生产系统，稳定运行至今。在这套系统上再挂 5 个飞书群 AI Agent：员工发一句话完成接单、出库核对、成本录入，老板直接提问查库存、欠款和经营数据。写入安全是整套设计的核心——只读为主、写入走白名单、人工确认后才执行。按生产标准交付：30+ 接口权限控制、全程操作审计、每日异地备份、失败自动回滚。
AI 在这个项目里的角色
5 个飞书群 AI Agent 每天在真实企业里跑接单、出库核对、成本录入和经营问数。关键不是让 AI 会写单，而是让老板敢让它写：只读为主、写入白名单、人工确认后才执行——AI 永远碰不到数据库的写权限。这是「Agent 进真实生产环境」最难的那一步。
一个真的有人在靠它做生意的系统
服务一家真实的花卉批发企业，覆盖出库、库存、对账、资金全流程，生产运行至今——支撑 3 个基地、65 个品种、56 家客户、10 名员工的日常经营，企业累计销售 540 万+。上线首月就处理了 1,027 单、结算 34 万+。
先搭 MVP，再亲手把它换掉
第一阶段：飞书多维表格当数据库。 小企业最真实的约束是养不起运维。几天就能跑通业务闭环、当场验证真实需求——这个阶段它是对的。
第二阶段：重构为 Flask + PostgreSQL。 业务长到几个基地、几十个品种、几十家客户之后，多维表格在并发写入、对账一致性和复杂查询上开始撑不住。于是整体重构为 Flask + PostgreSQL 生产系统。
值得写下来的不是「我选对了框架」，而是判断什么时候该换：MVP 阶段的正确选择，到了业务量级变化时就变成了债。两个阶段我都真跑过，也真换过。
让老板敢把写权限交出去
系统上挂了 5 个飞书群 AI Agent：员工在群里发一句话完成接单、出库核对、成本录入；老板直接提问就能查库存、欠款和经营数据。
难的不是让 AI 看懂「张姐花店要 200 扎 A 级红玫瑰」，而是让人敢让它动账：
- 只读为主——绝大多数提问走只读路径，碰不到写入
- 写入白名单——只有被显式列入白名单的操作才可能触发写
- 人工确认后才执行——AI 给出结构化单据，人点确认，系统才落库
AI 永远碰不到数据库的写权限。 这一条是整套设计的地基，也是老板愿意让它上生产的原因。
按生产标准交付
30+ 接口权限控制、全程操作审计、每日异地备份、失败自动回滚。钱的数据错不得——这不是练手项目的工程标准，是有人靠它发工资的标准。