工地上叫 AI 助手的东西已经很多了，多数停在问一句答一句：能查进度百分比，能读规范，能解释某个指标，但活还是人干。10 月 21 日，Buildots 把这条线往前挪了一格——它给 Dot 加了一个任务库，你可以把「查一下这个预测延误」「核对分包商说的进度」这类活派给它，它跑完分析、回一份带图表的结论，还要说明这个数字是怎么来的。
这次升级不收费，全球所有用户直接推送。Dot 是两年前上线的，此前的能力是问答：问某层装了百分之多少、本周哪些班组在什么区域作业、某个活动的延误预测是多少。新版本被官方称作上线以来最大的一次升级，方向很明确——从「访问数据」转向「承担工作」。
一、五项升级里，三项在解决信不信的问题
官方列了五项变化。第一项是接任务：任务库里目前有三类预置任务——调查一个预测中的延误、核对某个分包商的进度声明、比较同一活动在项目不同位置的完成情况。派出去之后，Dot 自己跑分析并回报。
第二项是全量数据洞察：Dot 不只是读文档和现成报表，而是能读底层的全部数据集，把跨报表、跨数据类型的关系、异常和趋势找出来。它给出的每条报告里多了一个「为什么重要」的小节，还支持直接在对话里出图表。
第三项是这次最值得记的一条，官方叫「展示它的工作过程」（shows its work）：用户可以要求 Dot 拆解任何一个数字的计算过程与假设，比如一个预测延误是怎么算出来的。第四项是全天候的平台支持问答并可直接开单。第五项是新界面，改成全屏的对话式布局。
三个细节里的判断
- 任务是有清单的，不是随便许愿。预置任务库意味着这些分析路径被事先定义过、验证过。这比开放式的「你想让我做什么都行」更保守，但出错的范围可控。
- 「为什么重要」不是装饰。项目经理要的不是一个数字，是这个数字该触发什么动作。把结论、含义、下一步绑在一起，才减少一次转述损耗。
- 展示计算过程，等于承认答案要能被复核。这是生成式工具最难承诺的一条，因为它要求系统把生成的内容锚在可重算的指标上。
二、为什么「展示工作过程」比「多一个功能」重要
进度数据的用途，从来不是看板好看。它连着进度款、连着工期索赔、连着总包对分包的履约判断。这些场合的共同点是：结论会被第三方追问。你说某专业延误了十天，业主要问依据，分包要问口径，仲裁要问计算方法。一个只会给结论的助手，在这种对话里没有位置。
把计算过程和假设摊开，性质就变了：它从一个「给建议的聊天窗口」变成一个能被审阅的分析记录。这跟造价软件要出计算书、结构软件要出计算书的道理一样——工程行业对工具的要求从来不是聪明，是可追溯。
把这一周的两条消息放在一起看会更清楚。Procore 在 10 月 21 日开放公测的 Procore AI Go 是语音优先的现场问答：对着手机问图纸、问 RFI、问日志，答案是口头给出、带出处的，公司明确说接下来才让现场人员用它建日志、起草 RFI，行动能力还在路线图上（见本站 10 月 22 日）。同一天，Buildots 的升级直接跨过问答，把任务派了出去。一个在解决「怎么问」，一个在解决「谁来干」。
| 对比项 | 问答式助手（如 Procore AI Go 现状） | 接活式助手（Buildots Dot 新版本） |
|---|---|---|
| 输入 | 一句话问题 | 任务类型加参数，或对话追问 |
| 输出 | 口头答案加出处 | 分析结论、图表、「为什么重要」、后续建议 |
| 核心难点 | 噪声环境下的识别、索引粒度 | 分析路径可复现、归因边界 |
| 失败长什么样 | 答非所问、引用错版本 | 路径对但前提错，结论看起来很专业 |
| 谁负责 | 提问的人 | 派活的人，因此必须能复核 |
三、它凭什么能回答「电工这两周该去哪」
Dot 能派活，前提是它手里有可计算的现场。Buildots 的数据来自每周的现场采集：安全帽上的 360 度相机或专门的走场采集，把每个房间、每个区域的施工状态拍下来，再与计划里的活动对齐，判断哪些装了、装了多少、在哪个位置装的。
这套数据的价值不在总量，而在维度：同一个活动被拆到了具体位置。没有位置分解，AI 只能告诉你某专业整体完成了 62%；有了位置分解，它能说三层东区的喷淋头最近两周几乎没动，而五层西区在加速。前者是报表，后者才是可以派给班组的活。
公司本月初发布的全球施工基准报告，用的就是同一条数据管线——把计划与实际逐周比对，量化不同项目、不同专业的完成节拍。这次升级等于把那份报告的分析能力开放成对话入口。
四、技术上难的三处，都不在模型上
第一处是两个坐标系的对照。计划按活动（WBS）组织，现场按位置（LBS）组织，AI 要回答的问题恰好横跨两者：喷淋头安装这个活动，在三层东区完成了多少。这要求项目在计划阶段就把活动拆到可拍摄验证的粒度，也要求模型和现场的构件命名能对上。这一段是数据工程，不是模型能力。
第二处是从「检测到」走到「归因」。相机能看到的是已经安装的构件，看不到材料堆场里的箱子和班组的人数。所以它能判断「慢」，但判断「为什么慢」时只能依赖计划逻辑与历史数据。厂商给的例子是提示电工该把重心放到哪个区域，这是相关性判断；真正的原因往往在采购、前置工序或人力调配，仍要人来定。
第三处是可复现。生成式的回答天然有随机性，而延误天数的算法必须每次一样。要让「展示计算过程」成立，系统得把生成部分约束在确定性指标之上，并且能追到具体的扫描批次和对比基线。这一条如果做不到，展示出来的只是一段听起来合理的解释。
五、给 BIM 工程师的六条准备动作
想让这类工具在项目上真的派得出活，先做这几件事
- 把活动编码和位置分解定成一套。WBS 与 LBS 的交叉是这类工具唯一的工作坐标系。两套编码各行其是，AI 就只能回答到专业层级，等于没用。
- 让模型构件对上现场可识别的单元。扫描看到的是安装完成的构件，不是工序。模型里的构件命名和分类要能直接映射到「这个房间里装了什么」，而不是停留在图纸编号。
- 计划拆到能被拍摄验证的粒度。一周完成两百平方米这种表述无法验证；拆到区域与系统，才能逐周比对。
- 把假设写成字段，不要写在正文里。班组人数、工作日历、材料到场时间，这些是延误分析的输入。写在备注里，机器读不到；做成字段，才可复算。
- 报告模板固化三段式：结论、依据、下一步。这是厂商在推的格式，也确实是甲方愿意看的格式。提前把内部模板改成这样，工具一上线就能直接用。
- 试点挑一个能量化的问题。挑一个专业、两周时间、一个明确指标，比如某系统的周安装量。跑完对比人工统计的工时，比听发布会更有说服力。
六、这篇稿子要打折扣的地方
厂商口径与未公开项
- 预置任务目前只有三类，官方说还有更多在开发，任务库的边界会决定这套东西的上限。
- 没有任何准确率、节省工时或客户案例数据，全部能力描述来自厂商博客与新闻稿。
- 「不额外收费」指的是包含在现有订阅里，不是零成本：采集设备、走场人力与数据治理仍要投入。
- 归因能力有结构性边界——数据只覆盖已安装的实体，看不到材料、人力与前置工序的真实状态。
- 「展示计算过程」解释的是计算逻辑与假设，不等于结论正确；假设本身错了，拆解得再清楚也是错的。
把两份消息并起来看，这一周建筑 AI 的分工开始清楚了。Mach9 在数据入口上做自动提取，把现实世界变成可查询的图纸与要素；Buildots 在数据出口上做自动分析，把现场变成可以派下去的活（见本站今日另一篇）。中间那段最不起眼、也最费人的工作，仍然是把模型、计划和编码整理成机器能读的样子。工具每年都在换，这一段整理得好的团队，换哪一代工具都省事。
资料来源：Buildots 官方博客《The new Dot: Major AI assistant upgrades for construction project teams》与 PR Newswire 新闻稿（2026-10-21）；Procore 官方新闻稿《Procore Launches Voice-First AI Mobile App Built for the Jobsite》（2026-10-21）。图片：Buildots 官方产品素材。厂商自报数据未经独立验证。