11 月 12 日，Anthropic 发布 Claude for Manufacturing。一个插件，17 个技能，4 个连接器：Autodesk Fusion、Infor、Microsoft 365、Oracle NetSuite。
官方给的例子很具体：一批钢材晚到两周，采购员问 Claude 哪些客户订单受影响、其他厂区还有多少钢材；采购员批准后，配合 Infor 自己发布的插件，Claude 可以向另一家供应商下采购单，并在 Infor 里重排受影响的生产。
这条消息被读成"AI 开始动 ERP 了"。但 17 个技能里，最难的既不是下单，也不是排产，是报价。
一、十七个技能里，报价要翻的是全厂的账本
插件覆盖销售、质量、运营、供应链、设计、系统设置六个域。官方对报价那条技能的描述是：读取客户需求、列出缺失信息、对比类似工单的成本、起草报价供发布。这句话里有四个动作，每一个都对应一类数据。
| 技能域 | 官方举例 | 依赖的系统数据 | 出错的代价 |
|---|---|---|---|
| 销售 | 新工单报价 | 实际订单、库存、生产步骤、工单成本（NetSuite） | 报低了亏钱，报高了丢单 |
| 质量 | 检验失败调查、纠正措施报告 | 历史同类问题报告、检验记录 | 措施落不到根因，问题复发 |
| 运营 | 生产报告 | 产量目标、设备停机、停机损失 | 停机成本算不清，改善无依据 |
| 供应链 | 向其他供应商寻源、RFQ 与报价对比 | 采购订单、库存、供应商历史报价 | 询价对象选错，交期补不上 |
| 设计 | Fusion 模型变体与评分 | 现有模型、工程师目标参数 | 变体不可制造，白做一轮 |
| 系统设置 | 对话式接入（"Set us up"） | 各系统账号、接口与权限 | 以为接通了，其实半通 |
报价要把七类数据拼在一起：BOM 版本、工艺路线与标准工时、工作中心费率、良率与损耗、库存可用量（含在检与已预留）、外协与运费、汇率与税率。任何一类是估计值，报价就是估计值——AI 只是把这个估计值更快地送到客户手里。
值得留意的是 NetSuite 连接器取的四样东西：实际订单、库存、生产步骤、工单成本。前三个决定"做不做得出来"，最后一个决定"做完赚不赚"。这四样凑齐，才是"以实际成本报价"；而多数企业的现状是标准成本加成，差异留到年底一次性消化。
2025 年 Manufacturing Leadership Council 调查中，仍在手工录入数据的制造商比例（Anthropic 在发布页引用）
这个数字把问题拉回地面。如果工单成本、工时、良率本来就是靠人抄进去的，接一个大模型并不会让报价变准，只会让错误的报价出得更快、更像那么回事。
还有一个常被混淆的区别：成本可见，不等于成本可报价。工单成本如果只归集到订单层，遇到一个新型号就没有可用的参照；只有归集到工序层——每道工序的工时、良率、费率——才能把一张新图纸拆成可估算的工序组合。这也解释了连接器为什么取"生产步骤"和"工单成本"两项，而不是一个总金额。
二、连接器只读，写入留给原厂：这个分工是对的
发布页里有一个很容易被跳过的细节：Claude for Manufacturing 的 Infor 连接器只支持查询记录；要改数据，得用 Infor 自己发布的那个插件。
这不是能力不足，是责任划分。读操作的风险是"看到了不该看的"，靠权限解决；写操作的风险是"改错了还原不回来"，靠业务系统的校验、审批和留痕解决。把这两件事放进同一个连接器，等于让一个外部分析工具绕过原系统的全部控制点。
查询连接器
只读。权限跟随登录用户。答错了可以重问，成本是一次对话。
写入插件
改单据。走原系统校验与审批流。错了要冲销、要解释、要留证据。
官方还写了两条设计原则：每项工作以用户的复核结束；Claude 可以把数字和结论链接回底层数据与文档。第二条比"准确率"更重要——复核的人如果只能看到一段结论，他能做的只是相信或不信；能顺着链接回到原始单据，他才是在审核。
别把"能查"顺口说成"能改"。
演示现场最容易发生的一幕：采购经理看到 AI 查出受影响的订单，接着问"那它能不能直接把交期改了"。这一句话会把项目从"分析工具"变成"写操作项目"——预算、审批层级、验证范围、回滚方案全部要重做。写操作要单独立项，不要夹在报表项目里偷偷上线。
三、权限继承很省事，但它继承的是一张过期的授权表
官方明确写了：Claude 的访问权限跟随用户本人在 Infor 中的权限。这句话在架构上很干净——不用另建一套账号体系，审计时也答得清"它代表谁"。
问题在于，它继承的是"这个人此刻的权限"，而这个权限往往是历史累积的结果。换岗没回收、项目结束没清理、临时授权忘了关，这些在企业里是常态，不是例外。把它交给一个会 7×24 小时读数据的智能体，等于把这些历史遗留一次性放大。
报价这个场景尤其敏感。销售该看到的是价格表与交期，成本会计该看到的是工单成本与费率，采购该看到的是供应商报价。三者的可见面本来不同。如果图省事用一个权限很大的账号去跑，AI 看到的是全公司的成本结构，再把它写成一份会被转发给客户的报价单——这不是技术故障，是信息泄露。
最危险的不是 AI 报错价，是它把不该给销售看的成本结构，写进了一份会被转发出去的报价单。
还有两个更隐蔽的入口：离职人员的账号没有停用，智能体还在替他读数据；报价的定价审批与成本数据维护由同一个人负责，AI 一接入就把这道职责分离的墙拆了。这两件事在权限表上都看不出来，只能靠流程查。
四、接进 Odoo 之前，先补四张表
如果要把这套能力落到 Odoo 上，先别急着接模型。四张表不补齐，接什么模型都一样。
- 成本口径表。标准成本、移动平均、实际成本，哪一个是报价口径；BOM 版本与生效日；哪些物料按批次计价。
- 工时与费率表。工作中心费率、准备工时与批量阶梯、外协工序的计价方式。Odoo 里对应工作中心与工序工时，字段空着，报价就只能靠猜。
- 良率与损耗表。按工序的良率、报废率、返工率。这一项最容易被忽略，也最能让报价差出十几个点。
- 报价版本与有效期表。价格表、币种、汇率取数日期、审批人。报价单是有保质期的，模型不知道哪一版还有效。
四张表有一个共同要求：每一项都要有"生效日"。没有生效日的表，人和模型都只能靠上下文猜，而猜出来的成本，恰好是最像答案的那种错误。
给 CIO 的三条动作：
- 先做十张历史报价的回测。拿已成交和已亏损的真实报价，让 AI 按现有数据重算，比对差异。差异集中在哪里，就去修那张表——不要先改提示词。提示词治不了脏数据。
- 权限按岗位快照，不按个人账号。为报价智能体建专用角色，权限等于该岗位应有权限，不继承任何人的历史授权；离职与调岗触发权限复核，而不是等审计发现。
- 读用通用连接器，写用原厂插件。写入路径必须经过原系统的校验与审批，中间保留人工确认和回滚方案。这条不是保守，是让项目能通过内控。
报价单是制造企业唯一一张同时写着成本、价格和承诺的纸。AI 可以把它写得更快，但写对的前提，是那七类数据本来就有人管、有版本、有生效日。
回到那批晚了两周的钢材。真正让采购员敢按下批准键的，不是模型有多聪明，而是它查的订单、库存、工单成本都在系统里，且他能顺着链接一条条看回去。智能体进 ERP 的门槛，从来不在模型那一侧。
资料来源：Anthropic《Introducing Claude for Manufacturing》（2026-11-12，含 17 个技能、4 个连接器、权限跟随、人工复核与"不操作设备"说明）；Anthropic 发布页引用的 2025 年 Manufacturing Leadership Council 调查（79% 制造商仍在手工录入数据）；Infor 同期发布的制造业插件说明；AI Soda《每日 AI 热点 11 月 13 日》对上述发布的中文转述（2026-11-13）。
口径说明：技能清单、连接器范围、权限继承方式与"每项工作以用户复核结束"均引自 Anthropic 官方发布页；钢材延迟案例为官方示例，非客户实证，官方页面未披露具名客户。79% 为调查受访者自述，未见样本量与问卷原文，本文按"厂商引用"处理。报价所需七类数据与四张表为实施经验归纳，不代表 Anthropic 或 Odoo 官方口径。
