这是一个：

SasaDaily 假设商业案例。

不是 Google 公布的真实客户案例。

假设有一家：

4 人小型景观维护公司。

每天工作地点不是办公室，

而是：

屋顶花园。

住宅庭院。

商办植栽。

社区公共空间。

老板真正最熟悉的是：

植物。

灌溉。

材料。

施工。

客户需求。

但每天最容易漏掉的事情，

反而发生在：

手正在工作、根本不方便打字的时候。

例如上午 10 点，老板突然发现四件事

第一：

某款培养土快没了。

第二：

客户原本指定的植物，

现场日照可能不适合。

第三：

滴灌其中一区水压：

看起来不对。

第四：

客户昨天好像又问：

能不能把另一区一起改。

这些事情当下都：

记得很清楚。

问题是：

老板手上正在：

剪枝。

拉管线。

搬盆栽。

戴手套。

很多人这时候会怎么做？

第一种：

跟自己说：

等一下再记。

然后：

忘记。

第二种：

传一段语音给自己。

晚上手机里：

十几段录音。

还是要：

重新听一次。

第三种：

在群组丢一句：

记得买土。

结果：

哪一种？

买多少？

哪个案场？

什么时候要？

全部没有。

这就是很多现场型小公司的：

信息转换成本。

Gemini Live 最适合先解决的不是「帮我经营景观公司」

而是：

现场想到的工作，不要再丢失。

Google 8 月 26 日开始替 Gemini Live 加入更完整的：

语音生产力能力。

其中一条路，

就是可以把用户一路讲出的：

Brain Dump

交给 Spark，

再整理成：

Google Docs

等后续工作成果。

对景观公司来说，

这比：

「跟 AI 聊植物」

更实际。

老板第一轮只负责「说」

例如现场可以直接讲：

松江案场。
西侧滴灌看起来压力不足，
还不知道是管线堵塞还是供水问题。
目前不要直接判断原因。
另外培养土剩下大概两包，
但我还没确认仓库库存。
客户昨天有提到想加一区香草，
我还没答应。
下午提醒我先确认：
库存、
灌溉原因、
客户到底是不是正式要追加。

讲完：

继续工作。

不用停下来：

打完整会议纪录。

AI 第一个价值就是把「口语」变成可以工作的结构

例如整理成：

已观察

西侧灌溉异常。

尚未确认

异常原因。

仓库实际培养土库存。

客户提出但尚未承诺

增加香草区。

下一步

查库存。

检查水源与管线。

重新确认客户需求。

这已经比：

一段三分钟录音

容易处理很多。

但今天上午教过一件很重要的事

漂亮文档不能让不确定的东西偷偷变成确定。

例如老板原本说：

好像还剩两包。

AI 不能直接整理成：

培养土库存：2 包。

这两句：

完全不同。

第一个只是现场记忆

第二个已经像：

库存事实。

如果接着 Spark 根据：

「还有两包」

去算采购量，

错误就开始：

往后传。

所以这家公司规定：

凡是语音里出现：

可能。

好像。

不知道。

还没确认。

客户有提过。

全部不能：

自动升级成正式数据。

第二步：把「现场笔记」和「正式系统」分开

这家公司不要让 Gemini Live 成为：

公司的唯一数据库。

现场语音整理的定位只是：

Operational Inbox。

白话就是：

今天有哪些东西：

需要处理。

不是：

公司正式库存。

正式报价。

正式排班。

正式合约。

例如培养土剩几包

正式答案：

应该来自：

仓库盘点。

或者：

公司的库存表。

不是：

老板上午口头说：

「我记得还有两包。」

客户是不是要增加施工范围也一样

老板说：

客户昨天好像有问。

不代表：

客户正式下单。

真正需要：

回到客户 Email。

消息。

正式报价

确认。

AI 的任务是：

提醒这件事情没有确认。

不是：

替公司把它确认掉。

第三步：Spark 可以帮忙把下一步做成工作文档

假设下午回到工作室，

老板确认：

今天现场有六个待处理项目。

这时才让 Spark：

进一步整理。

例如：

把今天三个案场的现场语音整理成一份 Docs。
分成：
已确认问题、
尚待查证、
客户变更、
材料需求、
明天以前必须处理。
没有正式数据支持的地方保留「待确认」。
不要替我创建报价或下单。

这样：

一天散落的现场信息

开始回到：

一个地方。

第四步：材料研究可以让 AI 帮忙，但不要直接采购

例如某个案场需要：

新的滴灌控制器。

Spark 可以协助：

研究。

比较。

整理。

例如整理：

规格。

适用面积。

兼容性。

不同供应商信息。

甚至创建：

比较用 Sheet。

但是最后：

采购

仍然应该停下来。

因为「规格看起来对」和「公司真的应该买」是两件事

可能还要考虑：

原本系统兼容性。

维修习惯。

供应商保固。

交期。

公司既有库存。

客户预算。

现场尺寸。

AI 可以把比较工作：

做快。

但最终责任：

仍然在：

技师与公司。

Google 自己也没有建议用户把付款数据随便交给 Spark

Google 对 Spark 的官方安全说明很清楚：

不要直接在 Spark 的 Task Thread 里输入：

登录信息。

付款数据。

或者你认为：

敏感的数据。

真正需要：

密码。

付款信息

时，

Google 建议用户：

自己接手浏览器操作。

所以景观公司的采购流程应该是：

AI 可以：

研究。

比较。

准备。

人：

确认。

付款。

第五步：客户报价也不要直接从 Brain Dump 生成并寄出

例如老板现场说：

如果加香草区，
大概多几千块吧。

这句最危险。

如果 AI 整理成：

香草区追加费用 5,000 元。

然后又自动寄给客户，

那就不是：

整理错一个数字。

而是：

真的产生：

商业承诺。

所以公司的规则可以很简单

AI 可以准备：

报价需要哪些数据。

例如：

增加多少面积？

植物品种？

盆器？

灌溉？

人工？

运送？

完成后：

创建：

报价数据缺口清单。

但正式价格：

仍由人填。

这样 AI 才是在降低行政时间，不是在替公司乱定价

例如 Spark 可以整理：

追加香草区目前仍缺：
实际面积。
植物品种。
盆器数量。
是否需要增加灌溉管线。

项目负责人：

补完。

才进入：

正式报价。

第六步：Daily Brief 可以解决早上最容易漏掉的事情

Gemini Live 现在也加入：

Daily Brief。

Google 表示，

它可以结合：

Gmail

与：

Calendar

的重要信息，

让用户直接：

用语音听。

对小型现场公司而言，

早上出门前非常适合。

例如老板一边装工具，一边问：

今天有什么重要事情？

可能听到：

上午屋顶花园维护。

下午住宅施工。

某客户 Email 有新回复。

某个供应商今天交货。

这比到了现场才发现：

「原来客户昨天晚上改时间」

好很多。

但 Daily Brief 不是正式派工表

这也要分清楚。

它是：

信息入口。

真正员工今天在哪里工作、

几点集合、

是否改班，

如果公司已有：

正式排班系统，

最后仍应该：

以正式排班为准。

因为 AI 摘要不是新的 Source of Truth

这和昨天 Ask Gemini：

完全相同的管理原则。

AI 可以：

帮你把散落数据找回来。

但是：

公司一定要知道：

真正正式答案在哪里。

第七步：客户改时间，AI 只能先准备

例如客户 Email：

星期五能不能改到星期四？

Gemini Live 可以：

搜索。

提醒。

甚至透过 Spark：

查看 Calendar。

整理可能影响。

例如：

星期四另一案场撞期。

某员工已有调度。

供应商还没到货。

AI 这时候最有价值的是：

列出：

「如果真的改，会影响什么？」

而不是：

直接回答客户：

可以。

一句「可以」背后可能有四种成本

员工加班。

运输。

材料提前。

其他客户改期。

AI 如果只看到：

Calendar 有空，

不代表：

整个营运真的：

有空。

所以对外时间承诺最后一定停在人

Google 的 Spark 本身也设计了：

Confirmation

机制。

例如在：

发送通信。

修改数据。

购买。

提交表单

等特定动作前，

系统可能要求用户：

检查与确认。

但 Google 同时明确提醒：

这些保护措施：

不能保证排除所有风险。

用户仍然需要：

主动监督。

第八步：这家公司甚至不应该把所有商业数据都放进 Spark

这一点今天一定要说清楚。

Google 目前的 Spark：

不支持使用公司或学校专用 Google 帐号。

现阶段主要是：

符合资格的个人 Google 帐号用户。

所以这个 4 人景观公司案例，

不是：

「整家公司已经把 Workspace 帐号接给 Spark。」

而是：

老板使用符合资格的个人帐号，

处理：

非敏感、低风险的工作整理。

哪些数据不要放？

例如：

客户完整付款数据。

信用卡。

银行帐号。

员工薪资。

员工身分证明。

密码。

机密合约。

其他真正敏感数据。

都不应该因为：

「AI 很方便」

就塞进个人 AI Agent。

这反而是一个很重要的企业导入原则

工具能做

不代表：

公司现在就适合用它做。

有些功能对：

个人工作

已经很好用。

但如果要：

全公司部署。

权限管理。

审核。

数据保存。

公司帐号。

合规

还需要另一套：

企业级考量。

所以这家公司今天真正采用的范围很小

只做：

现场非敏感 Brain Dump。

工作缺口整理。

公开供应商研究。

自己的 Daily Brief。

内部待办草稿。

这五类。

哪些完全不让 Spark 自己完成？

正式报价。

采购付款。

客户退款。

正式施工范围变更。

员工排班变更。

对外承诺。

重要合约。

这些：

全部停在人。

这并不代表 AI Agent 没有用

反而代表：

开始用得成熟了。

因为小公司真正需要的，

不是：

「全部自动。」

而是找到：

最浪费时间、

又最容易验证

的一小段。

先压缩掉。

这家公司最浪费时间的，其实是每天晚上刷新脑袋

做一个假设试算。

以下数字全部是：

SasaDaily 假设数字。

不是 Google 官方 ROI。

假设老板每天花 45 分钟整理现场信息

包括：

重听语音。

翻 Email。

整理明天要买什么。

把现场问题写进文档。

确认有哪些事情：

还没处理。

20 个工作天：

就是：

15 小时／月。

如果 Gemini Live＋Spark 把这段降到每天 20 分钟

每天少：

25 分钟。

20 天：

约：

8.3 小时／月。

也就是：

一年可能累积接近：

100 小时

的行政时间差距。

但再次强调：

这只是：

计算方式示范。

真正能省多少：

要自己量。

而且时间不是唯一 KPI

如果只是变快，

但 AI 每星期：

把三个客户需求整理错，

那可能根本：

没有价值。

所以这家公司至少还要看：

现场事项漏掉几次。

AI 整理后需要修正多少。

重复询问客户的次数。

错用旧信息的次数。

真正减少多少行政时间。

还要特别记一个数字：AI 补错的比例

例如一星期有：

40 个现场口述项目。

其中：

30 个完全正确。

8 个要小改。

2 个把「还没确定」

写成：

「已决定」。

后面这两个：

才是真正需要改善的地方。

因为景观公司最怕的不是句子不漂亮

而是：

状态变错。

材料：

「可能不够」

变成：

「已缺货」。

客户：

「有问过」

变成：

「已追加」。

日期：

「可能星期四」

变成：

「改到星期四」。

这种错误：

会直接进入营运。

最成熟的工作流可以只有五步

第一步：Speak

现场：

想到就讲。

第二步：Structure

AI 把：

观察。

未确认。

缺数据。

下一步

分开。

第三步：Verify

人确认：

正式来源。

第四步：Prepare

Spark 再：

研究。

整理 Sheet。

创建文档。

准备下一步。

第五步：Approve

碰到：

价格。

采购。

付款。

正式时间。

对外承诺

停下来。

为什么这种公司特别适合 Voice AI？

因为：

AI 对办公室员工最大的优势，

可能是：

少打一点字。

对现场工作者的优势却可能是：

原本根本没有办法打字。

这个差距：

很大。

一个工程师坐在电脑前

多打一段 Prompt：

可能只是：

多 30 秒。

一个园艺师正在屋顶施工

要停下来：

脱手套。

擦手。

拿手机。

打开 App。

输入数据。

可能就直接选择：

算了。

这就是为什么：

Voice

对 Physical Work

有特殊价值。

这也是今天案例和之前 GPT-Live 汽车维修案例的延伸

汽车维修厂的问题是：

车主讲了一大堆：

异音。

警示灯。

故障经过。

AI 先把：

接车信息

整理好。

今天景观公司的问题则是：

工作人员自己在现场产生信息。

看到材料不足。

发现施工异常。

想到后续问题。

直接用 Voice：

把 Context 留下。

两者都利用：

「手正在忙」

这个真实工作条件。

再往下一步，才是 Agent

Voice 解决：

输入。

Spark 解决：

整理与后续多步骤工作。

两个接起来，

才真正产生：

新的工作方式。

不是：

语音比较酷。

而是：

现场发现问题后，到问题进入数字工作流，中间少了一次人工转抄。

小公司真正应该算的就是这个

不要问：

Gemini Live 有几个 AI 功能？

问：

我们每天到底有多少信息，
是先出现在人的脑袋里，
最后还要人工抄进系统？

如果这个量：

很多，

Voice AI：

很值得测。

但最后公司一定还是要创建正式系统

如果生意继续长大，

10 个人。

30 个人。

100 个案场。

不能永远靠：

老板的 Gemini Live

当作中枢。

最后还是需要：

正式 CRM。

库存。

排班。

报价。

项目系统。

AI 应该是：

进入这些工作流的：

入口。

不是：

替代所有企业系统。

所以这个案例真正成熟的终点不是「所有人都用 Gemini Live」

而是：

现场语音：

更快进入：

正确流程。

例如：

发现灌溉异常。

↓

语音记录。

↓

AI 结构化。

↓

进入正式维修纪录。

↓

负责人确认。

↓

再产生：

真正工作。

这才是：

AI 工作流。

今天真正的结论

一家 4 人景观维护公司，

不需要先创建：

复杂 AI Agent 部门。

它可以只先解决一件：

每天都发生的小麻烦。

现场想到的事情，不要等晚上再重新想一次。

Gemini Live：

负责让人：

用说的留下 Context。

Spark：

负责把 Context：

变成可以工作的结构。

但是：

价格。

采购。

付款。

排班。

正式客户承诺

还是：

人决定。

如果最后真的每月少掉：

几个小时甚至十几个小时

的重复整理，

而且错误没有增加，

那这才是一个：

值得留下的 AI 工作流。

不是因为：

它最炫。

而是因为：

它把原本会从现场掉到地上的信息，接回了公司的工作流程。

今天，和 AI 一起进步一点。

每天学会一个 AI 技巧。

每天节省一点时间。

每天提升一点能力。

SasaDaily，陪你一起成长。

推荐阅读

AI 商业案例｜2026/08/02：汽车维修厂怎么用 GPT-Live？从接车描述、技师交接到报价确认，减少听错与重复询问

AI 商业案例｜2026/08/26：5 人活动企划公司怎么用 Ask Gemini？客户改期、厂商进场与会前数据一次找齐，正式承诺仍由人确认

AI 商业案例｜2026/08/12：7 人食品原料批发商怎么用 Workspace Studio？询价附件自动归档、需求整理到业务通知，正式报价与付款前停下来