ai产业链

AI 开始改造技术生产：OpenAI 与 Oracle 合作背后的加速与代价

信源：CNBC Television｜Sam Altman 与 Clay Magouyrk 在 Oracle AI World 的对谈⁠｜2026年10月27日

在 Oracle AI World 的对谈中，Sam Altman 说，如果只能建议企业短期内用 AI 做一件事，他会把理解并应对 AI 带来的安全威胁，排在用编程工具提高生产率之前。几分钟前，两位公司掌舵人还在兴奋地讨论普通员工如何自己开发应用；几分钟后，话题又转向 AI 参与设计推理芯片。这段看似跳跃的对话，实际上指出了同一场变化的三个侧面：AI 正在扩大技术的生产能力，也在加速消耗现有系统承受变化的余量。

过去，企业主要把算力用于执行已经写好的规则。如今，一部分算力开始被用于编写规则、检查规则，甚至改进下一代提供算力的硬件。技术进步因此多了一条反馈路径：更便宜的试验带来更多应用与工程探索，成功的探索再改善工具和基础设施。但这条路径能转多快，取决于部署、修复和验证能否跟上生成的速度。OpenAI 与 Oracle 的合作，恰好把这些相互依赖的环节摆在了一起。

Clay Magouyrk 在访谈中表示，Oracle 如今超过 70% 的软件由 AI 编写。这是管理层的表述，访谈没有交代统计范围和口径，不能把它理解为整个研发组织的生产率提高了 70%，更不能据此推算能减少多少工程师。代码完成之后，需求是否正确、数据能否接入、上线会不会影响其他系统，仍然决定软件能否产生价值。

更值得关注的是他随后描述的现象：一些过去不会把自己视为开发者的员工，开始直接制作解决自身问题的应用。这里发生的是需求进入软件开发流程的门槛下降。一个只能为几个人每天节省十分钟的小工具，过去可能不值得写需求、排预算、等待 IT 团队；当制作原型的成本显著降低，这类需求就有机会被满足。

Altman 说，自己更愿意尝试那些只有模糊想法、成功概率不高、却可能带来较大回报的方向。这比“写代码更快”多走了一步。AI 改变了人们是否愿意开始一项探索的判断：过去因为启动成本过高而被放弃的想法，现在可以先做出来，再决定是否继续。企业得到的潜在收益，既包括原有工作的提速，也包括原本不会发生的试验。

Oracle 发布的 App Composer 正是在处理这段落差：员工创建应用，Oracle 承担部署与运行管理，企业 IT 控制访问、数据和成本。按 10 月 27 日的产品说明，该服务处于有限开放阶段，因此应把它看作已经明确的产品方向，而非大规模实施效果的证明。

这也解释了 Oracle 为什么愿意推动更多人自己造软件。AI 可能压低一部分定制开发的价格，却也可能扩大需要数据库、身份管理、运行环境和持续维护的应用数量。如果这些新应用进入 OCI，并依赖 Oracle 的业务数据与权限体系，代码生成的普及就能转化为平台需求。这是一个商业上的合理推论，能否兑现仍取决于新增应用的实际使用量，以及管理它们的成本。

双方的分工还有更深一层含义。OpenAI 希望把模型放进企业日常工作的入口；Oracle 希望原有业务系统、数据和云资源成为 AI 执行任务的基础。两家公司 10 月 27 日披露的合作方向，包括通过 ChatGPT 访问 Oracle 应用和数据，并在企业权限与审批约束下完成工作。由此推演，用户可能越来越少亲自操作复杂的软件界面，但底层记录、交易规则和授权关系仍然需要被维护。界面发生变化，不代表业务系统随之失去价值。

安全问题让这套逻辑变得更紧迫。访谈中，Magouyrk 强调，AI 正在发现过去几十年累积下来的漏洞。这个解释抓住了历史技术债，却只覆盖了问题的一半。即使漏洞本身早已存在，发现和利用漏洞的成本下降，也会改变它的现实危险程度。一个长期没有被触发的缺陷，一旦更容易被识别，就可能从隐患变成迫近的损失。

企业安全因此面临两种速度的竞争。一种是漏洞被发现、复现并用于攻击的速度；另一种是企业确认影响、找到责任人、测试修复并完成发布的速度。如果前者加快，后者仍然受制于跨部门协调和漫长的变更窗口，增加扫描次数可能只是更快地堆积待办事项。

Altman 因而提出，逐个修补整个供应链的所有漏洞可能太难，还需要持续监测流量、阻止漏洞被利用的新服务。这里的工程含义是，发现缺陷、降低暴露和完成根本修复，需要并行推进。临时阻断危险行为可以争取时间，却不能代替修复本身；否则企业只是把长期安全责任交给另一套必须保持可靠的系统。

Oracle AI Security Mesh 的产品设计也体现了从“发现”走向“处置”的意图：测试攻击路径，由独立代理复核发现，确定优先级，再让团队审查修复建议并重新测试。这是厂商公布的能力设计，尚不能仅凭公告推定它能消除复杂系统的安全风险。它值得关注之处，在于把发现漏洞后的工作也纳入服务范围。

由此可以得到一个更有用的判断标准：AI 安全产品的价值，应当看它能否缩短高风险漏洞从被确认到完成有效修复的时间。发现数量增加，可能代表能力更强，也可能代表组织积压更严重。只有处置能力同步提高，企业才获得了净安全收益。AI 一方面扩大软件供给，另一方面帮助处理软件供给带来的复杂性，这两部分必须一起衡量。

对话最后的 Jalapeño 芯片，把这种反馈关系推进到硬件层。Altman 表示，AI 显著加快了这款推理芯片的开发，并称正在将其部署到 OCI。他对芯片性能的高度评价属于当事方判断，不能直接作为跨平台性能排名。

更具体的依据来自 OpenAI 6 月的说明：Jalapeño 从初始设计到制造流片用了九个月，模型参与加速了部分设计与优化工作。这里应采用正文明确的“设计到流片”口径，不能扩写成九个月完成量产和大规模部署；AI 也只是加速因素之一，项目同时依赖工程团队、Broadcom 的芯片实现能力和软硬件协同。

这件事的关键在于，AI 的使用对象开始包括承载 AI 自身的生产工具。更好的模型帮助工程师探索设计和优化方案；如果新芯片随后降低推理成本，同一预算就能支持更多模型调用和工程试验。这构成了一条可能自我加强的技术反馈路径，但远不是无需人类与制造业参与的自动进化。

要理解这条路径为什么有价值，需要先看“算力”到底如何变成服务能力。推理芯片的峰值算术性能并不能独自决定用户体验。模型运行还要搬运权重、读取中间状态，并在多个计算单元之间交换数据。若计算单元频繁等待数据，纸面上的算力就难以充分利用。OpenAI 对 Jalapeño 的架构说明，强调的正是减少数据搬运，以及匹配计算、内存和网络资源，而非只提高单一算力指标。

模型开发者参与硬件设计的潜在优势，也由此变得具体：它知道哪些计算操作最频繁，哪些等待最影响用户，未来模型可能怎样变化，因此有机会让芯片、底层程序与服务调度围绕同一种工作负载共同优化。与之相伴的代价是，硬件一旦制造出来，就远没有软件容易修改；对未来负载的判断越激进，判断失误的成本也越高。

这种优化对代理尤其重要。一次复杂任务可能需要多次调用模型、运行工具、检查结果，再继续尝试。只要串行步骤较多，每一步的等待就会累积；为了更快响应而压低批量处理规模，又可能影响硬件利用率。因而，“每百万 token 更便宜”还不足以说明任务更划算。企业最终承担的是完成一项任务所需的全部调用、失败重试和人工复核成本。

当推理速度与效率改善，而且结果质量得以保持时，一些原本不值得交给代理的任务才可能越过经济门槛。更低的试验成本增加软件和研发探索，更多任务又为推理基础设施提供需求。这正是应用端与芯片端能够相互促进的原因。不过，单位成本下降能否带来总算力需求上升，取决于新增任务的增长幅度，不能仅凭“AI 更便宜”就断言数据中心需求必然无限扩张。

反馈也有物理节奏。模型可以更快提出方案，但流片、制造、封装、系统验证和机房交付不会因此全部同步提速。科学研究的约束同样如此：更快提出假设能扩大搜索范围，实验与复现仍然决定哪些想法成为知识。如果候选方案的生成速度远远超过验证能力，增加算力得到的可能只是更长的等待队列。

因此，这次对谈传递出的产业信号，比某一代模型采用速度更值得长期关注：AI 正在同时改变应用的生产、缺陷的处理和计算工具的研发。三者相互支撑，也相互限制。Oracle 试图把新增的软件活动纳入可管理的企业环境，OpenAI 则试图把模型能力延伸到工作入口与底层算力。双方都在争取承接技术迭代加速后新增的活动，但合作方向本身尚不足以证明谁能获得多少利润。

接下来最有解释力的证据，会来自完整任务的周转时间：一个员工的想法多久成为有人持续使用的应用，一个高风险漏洞多久完成有效修复，一项芯片优化多久进入真实服务。这些时间若能持续缩短，而维护、事故和验证成本没有更快上升，算力才开始稳定地转化为创新产出。届时，AI 改变的将是企业尝试新事物的频率，以及成功成果再次改善生产工具的速度。