Wenti Labs创始人：一个WhatsApp群，管住整座工地

施工现场并不缺应用：从项目管理平台、BIM系统到各类移动端工具，供给其实早已不少。真正稀缺的，是那些能够理解现场节奏、信息断裂与协同压力，并愿意顺着既有工作习惯发挥作用的工具。

在这期Structural Intelligence Podcast中，Wenti Labs联合创始人兼CEO Ethan Ow从自己的项目管理经历出发，重新解释了施工行业所谓「技术采纳慢」的问题。他的答案很直接：现场人员不是拒绝技术，而是拒绝那些增加录入、培训和切换成本，却没有真正减少工作量的系统。

Wenti Labs的路径是把AI放进团队已经每天使用的WhatsApp里，让它像一名持续整理信息的「数字实习生」。以下是主持人Owen Keenan与Ethan Ow的对话整理，围绕施工工作流、AI智能体与技术落地展开。经AI4ELAB翻译、润色与编辑。

访谈正文

主持人 Owen Keenan：欢迎来到节目。请先介绍一下你自己，以及Wenti Labs正在做什么。

Ethan Ow：我在2023年12月创办了Wenti Labs。我的职业起点是建筑项目管理。若你从机场进城，可能会经过我参与过的CapitaGreen项目——顶部有红色结构的那栋楼。我从项目早期一直做到临时占用许可阶段。

那段经历让我真正理解施工现场的工作流：现场发生什么、不同团队怎样协同，以及项目管理者每天面对的混乱。尤其是初级项目经理，很多工作其实是在追踪现场的各种信息：进度如何、问题有没有解决、谁在等谁、最新消息是什么。

在新加坡施工现场，最重要的生产力工具之一其实是WhatsApp。一个项目可能有二十个不同群组，业主、顾问、总包、分包商和现场人员都在其中。大家实时处理问题，但信息也因此变得极其分散。

当经理问我「今天进展怎样？某件事的最新情况是什么？」时，我得在邮件、会议纪要、聊天记录和各种文件间来回翻找，才能拼出一条相对可靠的答案。这种人工收集和核对信息的过程，会明显拖慢决策。

因此我开始想：能不能做一个「AI版的自己」？不是取代所有人的工作，而是接管我过去最讨厌、最机械的部分——找资料、汇总信息、确认最新状态、整理文档。

今天的AI已经能承担其中相当大的一部分。当然，现场真正复杂的判断、协调和问题解决，仍然非常依赖人的经验；但大量文档处理、信息检索与基础数据汇总，AI已经可以做得不错。

主持人：我做过近四年现场工程师，非常能理解。施工现场节奏很快，决策必须及时，而且必须正确。你是如何从项目经理转向创业的？

Ethan：离开CapitaGreen后，我加入了当时增长非常快的Uber。那段经历给了我第二个很大的启发：数据可以实时流入系统。

在Uber内部，我们可以随时看到新加坡、圣保罗或纽约的订单量；可以看到某个区域司机活跃度为何下降、供给是否不足，并立刻做决策——比如发优惠券、在特定地区激励司机上线，或调整运营策略。

我当时一直在想：为什么施工不能做到这样？为什么现场已经完成的事情，要至少一周后才会反映到报告里？为什么不能更实时？

Uber之所以能做到，是因为每个人都有手机和App。于是我开始思考：施工行业里，所有人都已经在用的共同工具是什么？答案很快就出现了：WhatsApp。

后来Uber在新加坡被Grab收购，我没有加入Grab，而是进入Travis Kalanick创办的CloudKitchens，在新加坡做纯外卖厨房的建设。结果我又回到了同一个问题：现场协调、进度追踪、找出阻碍并推动解决，仍然全靠WhatsApp。

我离开传统施工行业几年后，手机上已经有Uber、Grab、Instagram等各种新工具，但施工团队的基础工具仍然是PDF、邮件、CAD图纸和各种零散系统。行业在这个维度上几乎没有改变。

GPT-4开放API后，我们开始测试它的能力。最早在2023年7月，我做过一个非常简单的Telegram工具：拍一张名片，它自动提取信息并写进我的Excel表，相当于一个个人CRM。我发现这种能力确实有用，便开始思考怎样把它用于施工。

之后我们不断和项目业主、项目经理及行业从业者沟通，验证哪些需求是真的、哪些需求值得付费。我们先找到首个客户，再围绕客户的实际工作流定制产品。那个最初的定制工作流，后来逐渐沉淀成了可复制的核心方案。

主持人：许多人认为施工行业是「技术采纳慢」的行业。你怎么看这种说法？

Ethan：我认为这是一个误解。问题并不是施工行业缺少技术，而是市场上有太多不适合现场的解决方案。

很多企业已经试过四五轮不同的软件：一半时候能用，另一半时候却让团队额外增加工作量。最后大家形成了心理预期：这又是一个看起来很酷、但很快会过去的玩具。

施工行业存在数千年，早已有稳定而成熟的工作方法。问题是，一个项目里有很多参与方，每家公司都有稍微不同的工作流、系统和习惯。于是最低共同标准往往只能退回到邮件，或者聊天工具。

很多施工软件试图解决所有问题：有一百种工作流，就想做一百个功能。但对于现场人员而言，打开一个App后，往往不是得到一个解决方案，而是遇到九十九个障碍：资料在哪？该填什么表？该进入哪个模块？该找谁确认？

现场条件并不适合人们长期拿着手机在复杂界面里操作。大家只是想把事情完成，然后继续干活。

而且施工项目是动态变化的。早期可能追踪桩基或开挖，后期则要追踪插座安装、空调测试和调试。系统很难随着工程阶段快速调整，结果是现场人员得在二十套模板间切换。WhatsApp之所以总会成为默认工具，正因为它几乎在任何项目、任何阶段都能用。

主持人：对施工科技公司来说，最常见的错误是什么？

Ethan：第一类错误是默认「人人都有能运行复杂App的手机」。现场并不总是如此。即使人手一部手机，设备性能、网络条件和使用习惯也不一定支持复杂软件。

假设现场有十名工人，只有三人能安装并顺畅使用App，其余七人还得依赖那三个人录入数据。于是又出现二次录入、信息遗漏和责任不清的问题。

第二类错误是忽视现场团队的持续流动。传统B2B软件上线时，培训一批人就可以了；但施工项目每三到六个月就可能进入新阶段、换一批分包和现场人员。你得不断重新培训，且希望他们不犯错。这是永无止境的变更管理。

第三类错误是按「理想数据」设计系统。比如BIM碰撞检测要有效，模型属性必须在每一步都标注得非常完整；否则什么都是碰撞。许多软件都假设基础模型正确、每个人都按标准工作，但现实不是这样。

所以我们的设计原则是：系统必须有韧性，即使输入数据质量一般、流程偶有中断，也能尽可能从中提取有价值的信息。我们不要求完美的数据，只要能生成合规、报表和付款所需的最低有效信息即可。

主持人：那么，Wenti Labs具体如何进入一个施工项目？

Ethan：举一个安全追踪的客户案例。我们直接与项目经理沟通，对方认可方案后，大约两天就能完成系统设置。之后，他们只要把我们的WhatsApp智能体号码加入已有的项目群组即可。

现场每天会出现很多安全问题：有积水、围挡没做好、通道有障碍、某处存在违规或隐患。工作人员发现问题后，通常会拍照发群里，说明位置和情况；其他人看到后就会去处理，之后在群里确认关闭。

这本来就是现场既有的工作流。问题在于，事情虽然解决了，很多人却不会再回到主系统里补录一遍。因为他们还有二十件更急的事要做。结果是，现场行动完成了，但正式记录没有形成。

我们的智能体留在群里，自动识别哪些对话与安全问题有关，哪些只是普通聊天；读取照片、文字、项目名称、位置、时间和严重程度，再将其整理到客户原本就在使用的报告模板中。到每天结束时，系统即可生成安全报告。

也就是说，团队不必先翻WhatsApp记录、再登录另一个系统、再填写表格。AI把现场发生的事直接转成可用文档。

主持人：这样不仅节省录入时间，也让项目管理者能及时看到未关闭事项、重复问题和资源需求。

Ethan：对。更重要的是，我们可以把多个项目的信息汇总起来。过去，每个项目的安全报告可能只是Excel或PDF，没有人有精力跨项目分析。

而不同项目可能用不同系统、不同顾问、不同命名方法。「高处作业」在不同报告里可能有不同叫法。用Excel分析时，它们很可能被当成完全不同的问题；但AI能够理解这些表述本质上是否相同。

因此，企业总部可以更快看到：哪些安全问题最常出现？是某个项目独有的问题，还是整个组织存在系统性问题？是否应该加强培训、调整标准或投入更多资源？

这才是真正缩短「现场发生」与「管理层知道并决策」之间的时间差。

主持人：你把AI称作「实习生」，这个比喻很直观。

Ethan：对。与其把AI智能体想成神秘黑箱，不如把它想成一个坐在电脑前、持续阅读群消息的实习生。

当群里出现「这里有安全隐患」时，它会识别问题，复制信息、整理照片、录入表格；当群里讨论「午饭吃什么」时，它会忽略。它的目标是加快从「工作发生」到「工作被记录」之间的过程。

一天里可能有两百条消息。人当然会漏掉一些内容，而一个未妥善处理的围挡问题，可能最终变成事故。只要能减少遗漏、加快关闭和复核，就有机会让现场更安全。

主持人：除了安全管理，还有哪些应用？

Ethan：一个很典型的场景是混凝土交付与质量追踪。

现场工程师会在WhatsApp里向供应商订购混凝土，例如第二天需要几车、什么等级、多少方量。供应商到场后会交付混凝土，供应商自己的系统其实往往已经很数字化，有送货单、iPad和内部记录。

但对总包而言，如果有三家供应商，就得面对三套系统、三个群组和不同格式的数据。每辆混凝土车进场时，现场团队会拍送货单、拍坍落度试验结果，并记录是否合格。一天可能有二十多车，每车都要追踪。

之后还会有混凝土试块强度测试。实验室会发回格式很漂亮的PDF报告，但若一个项目浇筑了两百车混凝土、做了数百个试块，就得有人逐份核对：这个试块对应哪一批混凝土？强度是多少？通过还是不通过？

同一套源数据，运营团队要用来追踪交付，质量团队要确认强度，财务团队要核对供应商付款。但过去，往往要由不同人花大量时间各自建立三张追踪表。

有了我们的系统，送货单拍照后就能进入流程；月底从供应商网站导出的送货单可批量导入；实验室发来的PDF可直接转发给AI。系统会读取试块编号、匹配浇筑批次、识别强度结果，并判断是否合格。

在新加坡，行业正大力推进集成化数字建造，对文件命名和归档也有很多要求。实验室报告往往使用自己的命名规则，而总包需要重新命名，标明浇筑日期、试验龄期和项目归档信息。AI可以读取文件内容、按客户规则改名，并上传到Autodesk等已有平台。

这不是什么惊天动地的技术突破，却是真实、重复、消耗人的工作。很多施工人员已经完成了真正的专业工作，却把90%的时间花在把数据弄对，只剩10%的时间用于决策。我们想把这个比例反过来：让AI做枯燥的整理，让人专注决策、问题解决和现场协调。

主持人：这也回应了人们对AI可靠性的担忧。你不会把所有决策都交给它，而是让它承担明确、受控的任务。

Ethan：是的。施工团队需要把「人工收集与整理信息」和「基于信息作出决策」分开。

你可以让AI做一个实习生会做的工作，但不能让它承担一个本应交给资深专家的复杂判断。前提是，你要能清楚说明工作流和流程。如果你无法向实习生解释一项任务，那往往说明问题不在技术，而在流程本身没有被梳理清楚。

AI的意义不是解决世界上一切问题，而是减少重复劳动、降低疲惫感，并改善合规、安全、计划和现场管理。

主持人：Wenti Labs在技术上如何实现？许多人会把智能体理解成黑箱。

Ethan：我还是倾向于使用「一组实习生」这个说法，而不是把智能体当成一个黑箱。

每个步骤都给它明确指令：输入是什么，输出应该是什么。例如，一个任务只负责看照片并描述照片，不做其他判断；后续再由其他步骤读取描述、提取字段、匹配项目上下文、填入对应表单。

从技术架构上看，我们有一套适用于不同施工工作流的「乐高积木」。每个客户的流程有细节差异，但很多底层上下文是相似的。客户告诉我们他们现在怎样做，我们便判断需要启用哪几个模块、哪几个「实习生」。

安全追踪可能需要三类模块；混凝土追踪可能需要更多模块。智能体背后实际上是多种工具、多个步骤和一连串数据处理流程。

至于幻觉问题，我们会通过复核机制处理。可以让一个最终的AI步骤检查前面各步骤的产出：这个结果是否合理？是否与预期格式和既有输出一致？若不一致，就重跑或要求复核。行业里把这叫作「LLM as a judge」，但从第一性原理看，就是让另一个「实习生」检查前一个实习生的工作。

每次API调用本身没有长期记忆，这既是限制，也是优势。它可能失去部分上下文，但也意味着每一次核查都能以新的视角重新判断。最重要的是：人仍然要检查实习生的工作。无论信息来自AI还是其他系统，经验丰富的人都应验证它。

主持人：最后一个问题：施工团队要真正接受并信任这些技术，最需要发生什么变化？

Ethan：最大的变化是思维方式。

施工行业习惯在启动前把一切规划得非常完整：图纸、尺寸、细节都要确认。这样做完全可以理解，因为一根柱子弄错，后果可能很严重。

但技术不是这样运作的。如果一个工具今天不能100%满足需求，明天可以修补；两个月后，模型和智能体能力可能又明显进步。与其等待「完美的模型」，不如今天就从一个小场景开始。

选一个可控的任务进行试验，真正理解模型的边界：它今天能做什么、不能做什么、你希望它未来能做什么。六个月后再回头看，你会比那些一直等待完美方案的人更有经验，也更有能力。

等待观望的人，最终可能会落后很远。

主持人：最后想对行业说什么？

Ethan：保持开放，主动思考AI还能承担什么任务。但要把它用在已经擅长的事情上，而不是把连人类都难以解决的复杂问题直接交给它，并期待它做得完美。

至少在现阶段，这不是正确的方法。先从明确、重复、有规则的任务开始。技术会继续进步，而真正开始实践的人，会最先知道如何把它变成生产力。

https://open.spotify.com/episode/6G7gsjKJOOkkDvkpGiq5LG https://www.youtube.com/watch?v=_jD0tjvXhd4