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

原来，工时是怎么记的？

这家公司在南岛做建筑施工，既做总包也做木工分包，现场四十多名工人，同时开工的项目十几个。管理层是老板和一位合伙人，往下是项目经理和几位工头（Site Manager）。合作前，公司内部沟通在微信群，对外在邮件，工时记录在 Excel 表里：工头下班后回忆当天谁干了几个小时，填进表，月底会计汇总算工资。

4 月 9 日，老板在群里第一次说出需求：“我想建立一套工地工人的工时、项目、每日填写并且追踪记录的系统……面向安排工人的工地管理，工人自己，办公室会计和行政，都能快速看到自己需要的信息。”4 月 28 日又补了两条：VO（Variation Order，变更单）和工地日志，最好能语音输入，工地日志要能传照片。

拆开看，这是三件事：每天谁去哪个工地干了多久（工时）；每个工地每天发生了什么（日志和 VO）；每个项目到今天花了多少人工（成本）。前两件在工头手里，第三件在老板心里，中间没有一张连着的表。

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

客户最终想要的是一个能看到所有项目实施进度的系统。4 月 21 日的拆解会上，我们把第一阶段定为“智能工地”的工时统计：数据量最大、每天都发生、也最容易验证对错的一环。项目进度管理放到第二阶段。

两条设计原则当天就定了。第一，工头填的东西尽量用下拉选择和智能判断：工人名字、工地名称从列表里选，工时超过 12 小时自动提示，不让他在手机上自由打字。第二，语音只用来“调出表格”，不用语音直接下命令，录入的正确率靠表单结构保证，不靠模型猜。

4 月 22 日，业务咨询师把第一阶段画成五步流程和四个角色：项目经理早上发任务，工头确认和改动，需要时记 VO，下班前汇报实际工时，系统自动汇总并生成工地日志。工人不需要公司账号，只在一个 Lark 外部群里收通知。

还有一个不起眼的门槛：海外公司当时办不了飞书企业认证，老板花了一周多解决注册问题。同一时间我们先在内部群里跑项目经理与工头的双向流程，工人群只做单向广播，进度没有停。

我们接进了什么？

原则仍然是连接而不是替换：工人还是在群里说话，老板还是看表，只是中间多了一层会写表的智能体。

• 飞书群入口：每个工地一个群。工头把当天完成情况、突发事件、照片发进群，@ 智能体就行；不想打字的用飞书自带的语音转文字，看到转出来的字再发。
• 本地运行：智能体跑在客户办公室的一台 Mac mini 上，用 OpenClaw 做调度，模型走客户自己的 Codex 账号，数据留在客户自己的飞书空间里。
• 拆成多个智能体：工时记录、工地日志、VO 各一个，互不打扰。5 月 15 日内部定的：拆开以后客户体感更好，出了问题也好查。
• 一套多维表格做底座：工人档案表管身份，工人时薪表按生效日期分版本，日常记录表每工地每天一行，日工时明细表是工时和人工成本的唯一来源，项目成本明细表放材料、运输、报销、分包这些非人工成本，再加 VO 表、工地日志索引表和成本驾驭舱仪表盘。到 6 月 27 日汇报时是 12 张核心表。
• 工时到工资不走大模型：日常记录表新增或修改满足条件时触发多维表格自动化，循环查找对应工人的时薪，命中就修改月度工资统计表的那一行，没命中就新增。会算错的环节不交给会猜的东西。
• 人留在三个地方：工头每天确认实际工时；项目经理编辑任务、审批跨工地调拨；老板和会计核对时薪与成本。智能体不改时薪、不算工资单、不批任何东西。

第一个月：问题不在功能，在稳定性

5 月 7 日，第一版工作流全流程跑通，工程师录了四段演示：早上 9 点按工地推送任务，下午 5 点提醒工头确认，工头回复修改实际工时，晚上 7 点对没确认的二次提醒。5 月 8 日老板进测试群实测。

同一天，业务咨询师在内部群写下一句话：“这几天的开发测试，OpenClaw 的稳定性一直是最大的问题。这个不解决，将无法商用。”不稳定的来源有四个：飞书插件版本与 OpenClaw 新版本不匹配、飞书机器人的权限设置、模型账号的 token 用尽、网关断连。5 月 9 日的周报里，阻塞点只写了这一条。

解决办法不神秘：锁定一个稳定版本、改动前先备份、加配置让重连更稳。6 月 9 日到 10 日又遇到一轮 Codex 鉴权失效和模型冷却（cooldown），工程师远程连进去排查修复，写了一份处理说明留给客户，以后再遇到先照着看。

5 月 22 日，老板看了 VO 和工地日志的暂定方案，说了一句让我们坐直的话：“能不能解决语音输入或者便捷输入的问题？不然和手动填表，并没有多大进步……AI 发挥的改进太小了。”她说的是对的。填表的人是工头，站在工地上，手上有灰。答案不在表格里，在输入法里：手机装一个语音输入法，说完看到字再发，而不是把语音丢给模型猜。这件事我们没有做任何开发。

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

5 月 27 日我们去了客户公司，项目经理第一次到场。会上把工地日志要记什么逐条列出来：天气及其影响、工时、与业主方 site manager 的沟通、检查与 QA、施工计划完成情况、图纸更新、VO 相关信息。日志以文字为主，可以带照片，由一个独立的智能体处理，每天固定时间生成一份 Daily Site Log。

两个业务细节是这次会上才问出来的。第一，大包与非大包项目的日志内容不同，所以在项目表上加一个属性字段，创建工地时就标好。第二，VO 由工头在现场用自然语言提交，智能体提取到 VO 表，但业主方有两种签字习惯（一天一签、多天共签一张），所以要能导出两种格式的 Excel。

这次会也把第一阶段的目标收成一个：成本可视化。项目进度与业主计划的比对留到第二阶段。工程师带回去的待办是：日常记录表按工地绑定、建工时统计和成本表、VO 表生成与汇总、工地日志智能体加提醒。

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

6 月 1 日到 3 日，第一阶段全部功能部署到老板办公室的 Mac mini，测试群的人迁进正式工作群。6 月 6 日的成本驾驭舱截图：15 个项目、累计工时 6,013 小时、210 条日常记录。6 月 15 日，老板在群里说“今天已经正式开始营业了”，系统进入全公司使用。

上线两周内改了四件事。6 月 12 日，多维表格从 5 月 5 日起已用掉基础版单表 2000 行额度的 41%，一个季度肯定超，升级到专业版（单表 2 万行），首先升的是每个工人每天都有一行的日工时明细表。6 月 16 日，查出日期错位的原因是表格时区一开始设成了北京时间，改成新西兰时间。同一天老板提出，工时统计群里所有人都能看到工资表，当天把工资表设为群成员不可见，并另建一个技术对接群，让工头们不用看工程师修东西。6 月 18 日，VO 不再单独建表记工时，而是在日工时明细里打一个“VO”标记，默认为“日常”，查数据时两部分能分开。

6 月 17 日的一次人工核查值得写下来。工程师对着表格逐条比对，列出四类错误：同一天有两条空白日常记录，没有项目没有工人、工时和成本都是 0，疑似误建；一个工人出现在项目工人列表里却没有工时描述；同一项目同一天被拆成两条记录，要人工确认是否重复；早上定时任务已发布“今日没有现场任务”，当天群里却出现了实际工时。这些错误系统一条都没拦住，全是人比对出来的。

同一天还改了一条规则，用的是自然语言。老板的要求是：“如果信息里面不是在说工时，就把信息记录在工地日志/事件描述里。”智能体回复确认：以后群里 @ 它的内容没有明确说工时的，先记到日常记录表的事件描述或工地日志，不再因为缺工时卡住；只有明确涉及可结算工时的，才写日工时明细表。规则改完，两条被卡住的记录当场补齐，现有工时一条没动。

6 月 27 日一季度交付汇报：数字与看板

6 月 27 日的交付汇报会上，业务咨询师给出的口径：项目管理系统完成约 85%，正式试运行约一个月，12 个核心表格，20 个项目入驻，沉淀 334 条日常记录，累计录入 1 万多小时工时。同一天的仪表盘显示累计工时 12,149 小时。核心入口是项目总览，含现场记录、任务汇报、成本核算、VO 管理四个模块；管理层从一屏看经营状态：累计项目成本、人工与采购成本、项目总成本排名、每日人工成本趋势，每张表可以点开，用自然语言问它。

老板当场定的两件事

老板的评价照实记：对团队非常满意，系统实现了核心功能。比评价更重要的是她当场宣布的两个安排：安排专人每天盯系统使用情况；把员工从 Excel 记工时转到飞书系统，给一段缓冲期，然后逐步强制。

还有一件事当场说清楚：审批环节没有进系统，成本审批仍在线下人工进行。二季度起合作模式变化，客户团队自己操作，我们做教练，回答问题但不轻易下场。

交付之后：退群、被顶掉的绑定、一句话查工时

6 月 29 日内部定了退出条件：观察到 7 月 7 日，运行正常就全部撤出客户的工时统计群，群交还客户，也是为了保护客户隐私。7 月 9 日我们的人退出了两个群：工时记录群（记每个工人在哪个项目干了几小时）和工地管理群（生成每个工地每天的日志和照片）。

7 月 24 日出了一件事。客户自己创建了一个新智能体，把原来工时统计智能体在飞书上的绑定关系顶掉了，从那天起到发现为止，工时记录都脱离了原有校验规则在跑。工程师当天远程修复，然后专门写了一份“如何创建多个智能体而不破坏原绑定关系”的操作指引。这不是客户的错，是我们交出去的时候，没把“怎么不弄坏它”写下来。

7 月 29 日群里的一段对话，是这套系统日常的样子。一位工人 @ 智能体：“计算本人 13-19/07 整周工时总数及工作地点。”智能体回复：整周合计 49.5 小时，工作地点某项目，明细 7/13 6.5 小时、7/14 5 小时、7/15 到 7/18 每天 9.5 小时、7/19 无工时记录。项目经理接着问另一位工人 6 月 1 日到 21 日的工时，它开始逐日查。没有人打开过 Excel。

9 月 1 日项目督导给老板的确认：“经过这几个月的实际运行，智能体整体运行稳定，暂未出现明显问题，这套工作流也已经进入常态化使用阶段。”群主移交客户。

三个月留下的四条教训

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

• 稳定性是第一个功能：5 月 8 日那句“不解决无法商用”是对的。锁版本、先备份、写一份客户能照着做的故障处理说明，这些工程手段排在任何模型能力之前。
• 入口决定采用率：客户说“AI 改进太小”，问题不在 AI，在工头站在工地上怎么输入。下拉选择、语音转文字、工人不需要账号，这三件事没有一件是模型做的。
• 上线不是终点，数据要有人天天盯：6 月 17 日四类错误没有一条被系统拦住。老板安排专人每天看，是这套系统能进入常态化的真正原因。
• 交出去之前，把“怎么不弄坏它”写下来：7 月 24 日的绑定被顶掉，暴露的是交接文档的缺口。角色权限、新建智能体的步骤、出问题先看哪里，这些要和系统一起交付。

现在怎样了？

系统由客户自己运营，我们的人已经不在工时统计群里。二季度客户团队在同一套飞书加 OpenClaw 的框架上自己开始做第二件事：给关联的设计公司做 H1 保温合规报告的自动计算，我们做教练。

最好的验收还是不是数字。6 月 27 日老板给自己团队定的下一步，是把工头从 Excel 迁到飞书，并给他们缓冲期。一套系统能不能留下来，取决于最不想改变的那个人愿不愿意用它。

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