博客 · AI 落地案例 · 新西兰建筑

新西兰 AI 技术落地实践案例:一家建筑公司的工地工时管理,从 Excel 到飞书群与成本看板的三个月

内容复核 2026.09.148 分钟BEE Sigma 落地团队

这篇新西兰 AI 落地案例的主角是南岛一家建筑施工公司,既做总包也做木工分包,几十名工人分布在近二十个项目上。合作前,工时靠工头下班后回忆和 Excel 汇总,老板看不到各项目的人工成本。2026 年 4 月 8 日启动,5 月 7 日第一版跑通,6 月 15 日全公司使用。6 月 27 日一季度交付汇报:12 个核心表格、20 个项目、334 条日常记录、累计 1 万多小时工时进了飞书多维表格。下面用图讲中间三个月发生了什么。

01

原来,工时是怎么记的?

公司内部沟通在微信群,对外在邮件,工时在 Excel:工头下班后回忆当天谁干了几个小时,月底会计汇总算工资。4 月 9 日老板提出需求:一套工地工人的工时、项目、每日填写与追踪系统,工地管理、工人、会计和行政都能快速看到自己需要的信息;4 月 28 日又补了 VO(变更单)和工地日志。拆开是三件事:谁去哪个工地干了多久、每个工地每天发生了什么、每个项目到今天花了多少人工,中间没有一张连着的表。

工时记录前后对照:原来回忆加 Excel 五步,现在群里一句话由智能体写表、自动化算时薪、老板看成本驾驭舱
合作前后工时的记法对照。左边靠回忆和 Excel,右边靠群里一句话。
02

第一刀切在哪里:先做工时,不做整个系统

4 月 21 日的拆解会上,我们把第一阶段定为工时统计:数据量最大、每天都发生、最容易验证对错;项目进度管理放第二阶段。两条原则当天定下:工头填的东西尽量下拉选择和智能判断,不在手机上自由打字;语音只用来调出表格,不直接下命令。4 月 22 日方案画成五步流程和四个角色,工人不需要公司账号,只在一个 Lark 外部群里收通知。

第一阶段五步流程:任务发布、任务确认与实时修改、VO 变更记录、每日汇报、自动汇总与日志生成
4 月 22 日第一阶段方案里的五步流程:早上发任务、工头确认修改、VO 按需触发、下班前汇报实际工时、系统汇总生成工地日志。
四个角色的权限卡:项目经理、工地经理 Site Manager、财务人员、工人(通知接收)
同一份方案里的四个角色。工头看不到财务成本,财务通过独立私密表看工时与成本,时薪表和工时表分离。
03

我们接进了什么?

原则仍然是连接而不是替换:工人还是在群里说话,老板还是看表,中间多了一层会写表的智能体。每个工地一个飞书群,工头把完成情况、突发事件、照片发进群并 @ 智能体;智能体跑在客户办公室的 Mac mini 上,用 OpenClaw 调度,工时、工地日志、VO 各一个智能体。底座是一套多维表格:日工时明细表是工时和人工成本的唯一来源,工时到工资由多维表格自动化按时薪计算,不走大模型。智能体不改时薪、不算工资单、不批任何东西。

数据流:飞书群工头一句话、智能体解析写表、工头确认、自动化时薪匹配、月度工资汇总、成本驾驭舱
一句话到成本看板的数据流。金色节点是人;工资计算不走大模型。
多维表格数据表清单:项目表、日常记录表、日工时明细表、月度工资汇总表、工人时薪表、项目成本明细表、VO 表、成本驾驭舱
6 月 1 日部署前的数据表清单,以及“施工项目总览|成本驾驭舱”仪表盘。
飞书多维表格自动化流程“工时同步工资表”:触发、循环关联工人时薪、查找记录、分支判断、修改或新增月度工资统计记录
4 月 23 日搭的“工时同步工资表”自动化:触发、循环、查找、分支、修改或新增,没有一步交给大模型。
04

第一个月:问题不在功能,在稳定性

5 月 7 日第一版全流程跑通:早上 9 点按工地推任务,下午 5 点提醒工头确认,晚上 7 点二次提醒。5 月 8 日业务咨询师在内部群写下:“OpenClaw 的稳定性一直是最大的问题。这个不解决,将无法商用。”不稳定有四个来源,解决办法不神秘:锁定稳定版本、改动前先备份、加配置让重连更稳,再写一份客户能照着看的处理说明。同一时期我们也想清楚了输入问题:工头站在工地上,手上有灰,答案不在表格里,在输入法里,手机装一个语音输入法,说完看到字再发。这件事没有做任何开发。

稳定性问题的四个来源:插件版本不匹配、机器人权限设置、模型 token 用尽、网关断连,以及锁版本、先备份、稳重连三个手段
第一个月的真正问题。四个来源,三个工程手段,加一份故障处理说明。
05

5 月 27 日线下会:把“工地日志”说清楚

5 月 27 日我们去了客户公司,项目经理第一次到场。会上把工地日志七项内容逐条列出,由独立智能体每天固定时间生成一份 Daily Site Log;大包与非大包项目日志不同,在项目表上加一个属性字段;VO 由工头现场用自然语言提交,业主有两种签字习惯,所以要能导出两种 Excel 格式。这次会也把第一阶段目标收成一个:成本可视化。

工地日志内容框架表:天气情况、工时、沟通内容、检查及 QA、施工计划完成情况、图纸更新情况、VO 相关信息
5 月 27 日会议纪要里的工地日志七项框架。
Site Log Agent 总体方案:加入项目群默认不说话,持续读取群消息、图片、语音转文字,识别九类信息写入结构化数据库,每天固定时间生成 Daily Site Log
5 月 22 日工程师的工地日志智能体方案:进群但默认不说话,识别九类信息写入结构化表,每天生成一份日志。
06

6 月:上线、升级、改规则

6 月 1 日到 3 日部署到老板办公室的 Mac mini,6 月 15 日全公司正式使用。两周内改了四件事:多维表格升到专业版(单表 2 万行)、时区从北京改为新西兰、工资表对群成员不可见并另建技术对接群、VO 工时改为在日工时明细里打标记。6 月 17 日一次人工核查抓出四类数据错误,系统一条都没拦住;同一天老板用一句自然语言改了一条规则:不说工时的信息记到工地日志或事件描述,只有可结算工时才进日工时明细表。

6 月 6 日成本驾驭舱顶部指标卡:项目总数 15,累计工时 6,013,日常记录总数 210;金额已打码
6 月 6 日的成本驾驭舱:15 个项目、6,013 小时、210 条记录。含金额的卡片已打码。
6 月 17 日人工核查抓出的四类错误:空白记录、工人无工时、同项目同日拆两条、定时任务“无任务”却有工时
6 月 17 日的四类错误。这也是老板安排专人每天盯数据的原因。
群聊截图:老板要求不是在说工时的信息记到工地日志或事件描述,智能体确认规则已调整并补齐两条记录
6 月 17 日用一句话改规则,智能体确认后当场补齐两条记录,现有工时一条没动。项目名已打码。
07

6 月 27 日一季度交付汇报

交付汇报的口径:系统完成约 85%,12 个核心表格,20 个项目入驻,334 条日常记录,累计 1 万多小时工时,当日仪表盘显示 12,149 小时。管理层从一屏看经营状态,每张表可以用自然语言问它。老板当场定了两件事:安排专人每天盯系统使用情况;把员工从 Excel 转到飞书系统,给一段缓冲期再逐步强制。审批环节没有进系统,成本审批仍在线下。二季度起客户团队自己操作,我们做教练。

6 月 6 日与 6 月 27 日两次仪表盘快照对比:项目 15 到 20、累计工时 6,013 到 12,149、日常记录 210 到 334、核心表 8 到 12
三周之间的增长:项目、工时、记录、核心表四项都翻了一截。
一季度汇报材料:项目开始日期趋势折线图与日常记录日期趋势折线图
6 月 27 日汇报材料里的管理视图。右侧含人名的分布饼图已裁去。
08

交付之后:退群、修复、移交

7 月 9 日我们的人退出了工时记录群和工地管理群,群交还客户,也是为了保护客户隐私。7 月 24 日客户自建的新智能体顶掉了原智能体的飞书绑定,工程师当天远程修复,并写了一份“如何创建多个智能体而不破坏原绑定关系”的操作指引,这是我们交接文档的缺口。7 月 29 日群里一位工人 @ 智能体查整周工时,它回复合计 49.5 小时并逐日列明细,没有人打开过 Excel。9 月 1 日确认整体运行稳定,进入常态化使用,群主移交客户。

交付后流程:6.29 定退出条件、7.9 退出两个群、7.24 绑定被顶掉当天修复、写操作指引、9.1 常态化确认
交付之后的三步:退出、修复、移交。
项目运营系统结构图:现场入口、AI 结构化、核心台账、完整性校验、驾驭舱洞察
6 月 29 日整理的项目运营系统结构图。客户公司名已遮盖。
09

三个月留下的四条教训

回头看,最贵的不是开发,是这四个判断。

  • 稳定性是第一个功能:锁版本、先备份、写一份客户能照着做的故障处理说明,排在任何模型能力之前。
  • 入口决定采用率:工头站在工地上怎么输入,决定系统有没有人用。下拉选择、语音转文字、工人不需要账号,没有一件是模型做的。
  • 上线不是终点,数据要有人天天盯:6 月 17 日四类错误没有一条被系统拦住。老板安排专人每天看,是系统能进入常态化的真正原因。
  • 交出去之前,把“怎么不弄坏它”写下来:角色权限、新建智能体的步骤、出问题先看哪里,要和系统一起交付。
10

现在怎样了?

系统由客户自己运营,我们的人已经不在工时统计群里。二季度客户团队在同一套飞书加 OpenClaw 的框架上自己开始做第二件事:给关联的设计公司做 H1 保温合规报告的自动计算,我们做教练。一套系统能不能留下来,取决于最不想改变的那个人愿不愿意用它。

三个月时间线:4.8 启动、4.21 第一刀、5.7 第一版跑通、5.27 线下会、6.15 全公司使用、6.27 一季度汇报、7.24 绑定修复、9.1 常态化
三个月时间线,每个节点都能在项目记录里找到日期。

证据边界:本文所有数字来自项目群聊记录、6 月 27 日一季度交付汇报纪要与当日仪表盘截图,日期均已标注;“12 个核心表格、20 个项目、334 条记录、1 万多小时”是 6 月 27 日的截止快照,此后系统由客户运营,我们不再掌握最新数字。客户为新西兰南岛建筑施工公司,已匿名;截图中的公司名与人名已裁除或遮盖,含金额与项目名的区域已打码,工资数字未采用。

FAQ · 快速回答

新西兰建筑公司的 AI 落地案例里,工地工时管理 AI 做哪一步,人做哪一步?

AI 做四件事:早上按工地推送任务、解析工头在群里说的话并写进日常记录和日工时明细、生成工地日志、汇总成本看板。人做三件事:工头每天确认实际工时,项目经理编辑任务和审批跨工地调拨,老板和会计核对时薪与成本。工资计算走多维表格自动化,不走大模型;审批不在系统里。

需要换掉 Excel,或者让工人装新 App 吗?

不需要装新 App。工人只在飞书或 Lark 的群里收通知、说一句话,不需要公司账号;不想打字的用语音转文字。Excel 记工时是逐步退出的:6 月 15 日系统正式使用后,老板给了员工一段缓冲期,再逐步强制在系统里记录。

工地工时管理系统多久能上线?

这个项目 4 月 8 日启动,5 月 7 日第一版工作流跑通,6 月 1 日部署到客户的 Mac mini,6 月 15 日全公司正式使用,约 10 周。其中开发本身不到一半时间,剩下的花在稳定性、飞书企业认证、表结构确认和现场输入习惯上。

工资和成本数据谁能看到?

分角色。工头只看本工地当日派工与工时,看不到财务成本和其他工地;项目经理看所有工地的工时汇总、进度、VO 与成本;会计通过独立的关联表看工时与成本的计算结果,时薪表和工时表分离;工资汇总表对工时统计群的普通成员不可见(6 月 16 日调整)。
DT
BEE Sigma 落地团队

把工作流真正接进企业现有系统的一线交付团队,方法来自已交付项目。

Read Next · 相关阅读

把第一条业务流,交给 Agent 试试

一次免费诊断,看清企业在 AI 时代的可见度;AIM 评估帮你找到最合适的落地切入角度。