CostLogic 的巧思：先校准图纸，再让 AI 把数量带到发票

施工报价往往从一张 PDF 图纸开始。承包商要先做 takeoff：从图纸上量出长度、面积，数出房间和材料，再把数量换算成报价，最后开成发票。真正容易出错的地方，常常不在某一次计算，而在数量从图纸流到报价、再流到收款文件时，被人重新抄了一遍。

CostLogic 是一款面向施工团队的浏览器工具，把图纸量算、报价和发票放在同一条工作流里。用户可以上传施工 PDF，在图纸上校准比例，直接量线性、面积和计数数量，也可以让 Auto Room 识别房间。内置的 Onyx 助手则能查找房间、给量算结果定价、起草发票，还能回答当前项目的问题。1

CostLogic 的设计重点落在两个容易被 AI 藏起来的问题：测量到底依据什么比例，以及一次测量的数量能不能继续作为后续工作的同一个对象。1

图纸上的一条线有多长，不能靠像素直接判断。系统必须知道图纸比例；比例错了，后面的长度、面积、材料数量都会一起错。CostLogic 把校准比例放在工作流入口：上传图纸后，页面会自动命名，并尝试从图签读取比例；用户可以继续在图纸上测量和调整。1

这个设计把一个容易被模型藏起来的前提，变成了工作台里可以看见、可以修改的状态。CostLogic 的 AI scale detection 可以帮助读取图纸比例，但条款明确写着，测量结果取决于用户设置的比例和上传图纸的准确性，AI 结果也可能出错；用于投标、采购或施工前，用户仍需核对测量、数量和价格。1

我更愿意把这看成「先固定误差来源，再调用 AI」的产品选择。假如比例一直藏在模型推理里，用户看到的只是一串看起来合理的数字，很难知道问题来自识别、比例还是图纸本身。把比例放到前面，AI 的工作范围就窄了一层：模型负责从一个明确的测量前提里找房间、做量算或生成后续文件，人负责确认这个前提是否成立。

代价也由此变得清楚。用户必须知道哪一个比例可信，并承担第一次校准的责任；AI 读比例时，图纸页面提取出的文字会发送给第三方模型服务。CostLogic 的安全说明写明，AI scale detection 和页面命名使用 Fireworks AI，发送的是图纸页面提取出的文字。2 对施工团队来说，这个步骤同时决定准确性边界和数据离开工作区的边界。

第二个选择藏在 CostLogic 对 Onyx 的定位里。Onyx 的示例把动作接在已有对象上：识别图纸里的房间，把一份 takeoff 转成 estimate，起草 invoice，或者检查某个 bid 的利润率。产品首页把这条链路概括为：测得的数量直接进入定价和账单，中间不再重新录入。1

这比「聊天里能调用很多功能」具体得多。一次量算在系统里先是图纸上的线、面或计数结果，随后变成报价行项目，再成为发票里的依据。Onyx 的价值在于让同一个业务对象在不同阶段继续存在，减少每个阶段重新解释和抄写的机会。

这条连接正好对应施工软件里的一个细小痛点。Drawer AI 在 2026 年 4 月 10 日的一篇文章中写到，电气承包商的 takeoff 数据如果不能顺畅进入开票系统，就需要手工重新录入；遗漏会拖慢开票、影响现金流，并造成少计费和利润流失。3 CostLogic 把量算、报价和发票放在一起，缓解的核心摩擦是数量跨阶段时被重新抄写。

Onyx 也没有被设计成可以无边界读取整个公司的聊天机器人。安全说明称，Onyx 会根据用户自己的账户权限读取与请求相关的项目、量算、报价和发票数据；如果要读取 notes pad，用户可以在 Settings → Onyx AI 里关闭这个工具，而且系统不会在用户没有提出请求时读取它。2 这让「上下文」变成了一个有对象、有权限的范围，而不是一句笼统的「AI 了解你的项目」。

这里的成本同样不能省略：结构化对象一旦被 AI 改写成报价或发票，就更接近真实业务动作，错误的影响也会更大。CostLogic 的条款把核对责任留给用户，并明确提醒 AI 辅助结果可能不准确。4 所以，Onyx 适合加速从测量到文件的传递，最终对比例、数量、价格和税务处理的判断仍要由用户完成。

CostLogic 的巧思可以压缩成两步：先把图纸比例这个隐含前提显式化，再让已经确认过的数量沿着量算、报价和发票继续流动。前一步减少了 AI 在错误前提上自信计算的空间，后一步减少了人把同一数字复制到不同系统时产生的断裂。

这条原则也适用于其他有数字责任的 AI 工具：先把最容易改变结果的前提放到用户能检查的位置，再给 AI 一组有类型、能继续写回的工作对象。聊天只是入口；真正决定产品是否可靠的，是模型能依据什么开始，以及它的输出最终落在哪里。