汽车企业用 AI，为什么从飞书开始？|上下文|供应商支付账期|汽车企业|知识库|调用

企业用飞书重新组织信息与工作，由此沉淀的上下文助力提升企业效率。

文丨沈行

同样一个大模型，进入不同公司，能做的事情可能完全不同。

它可以写报告、总结会议，但如果不了解这家公司正在做什么、过去做过哪些决定，依旧很难真正参与工作。企业里的很多任务也不是靠一条指令完成的。AI 要继续往下做，需要知道事情从哪里开始，中间发生过什么，为什么变成今天这样。

汽车行业尤其能说明这个问题。

一辆汽车背后，是需求、软件、硬件、测试、制造和供应链共同完成的复杂工程。一个功能发生变化，可能同时牵动车端软件、手机、云端、芯片和生产线。参与的人和公司越多，研发节奏越快，信息之间能不能连起来就越重要。

过去，这些信息主要供人阅读、沟通和判断。大模型开始参与研发和经营之后，它们又多了一层新的作用。

在车企的开发过程中，一项功能从需求提出到最终交付，往往要经历多轮评审、开发、测试和修改。比如，辅助驾驶功能从高速场景扩展到城市道路，AI 不仅要了解最新需求，还要知道此前的用户反馈、测试数据、硬件变化和未解决的安全问题。

数字钥匙在部分手机上无法使用时，AI 也不能只查看一份故障报告，而要同时追踪手机、车端、云端和硬件记录，才能判断问题出在哪里。

对 AI 来说，这些需求变更、测试结果、故障记录和供应商往来，才是理解一个项目的上下文。只有把问题的起因、已经尝试过的方案和仍未解决的限制连起来，它才可能给出下一步可执行的判断。

而今天的汽车行业的新变化，又让这件事变得更加迫切。车型越来越多，软件更新越来越频繁，一项功能背后连接的团队、系统和供应商也越来越多。过去依靠人反复沟通还能维持的信息传递，越来越难跟上研发和交付的速度。

8 月以来，我们访谈了超过 5 家车企和供应链公司。保隆科技要同时连接主机厂和中德研发团队；银基科技的一把数字钥匙，要横跨手机、车端、云端和硬件生产，还要适配不同车企各自的开发体系。

这些企业面对的具体问题不同，但共同的问题是：信息散落在不同公司、团队和系统里。AI 想参与得更深，第一步就是把这些彼此分散、不断变化的信息重新连起来。

一些车企很早就意识到了上下文的重要性。2021 年 5 月，理想汽车创始人李想在飞书未来无限大会上把飞书称为 “超级感知工具”。在他看来，飞书流转的不只是办公和信息，也包括企业里的认知和知识，并通过共同协作把它们连接起来。

理想之外，飞书在汽车行业的使用也已不局限于新势力车企。从上汽这样的整车集团，到博世、玲珑轮胎和欣旺达等供应链企业，它已经沿着整车、零部件、轮胎和动力电池等环节进入汽车产业链。这些企业开始把散落在文档、消息、会议、表格和流程中的工作信息汇集到同一个协作环境里，让一项任务的来龙去脉能够连续保存，也让 AI 有机会理解工作并进入流程。

飞书 CEO 谢欣也在 AI 生产力大会汽车行业专场中表示，企业里的绝大多数任务并不发生在孤立的工具中，而是贯穿文档、消息、会议、表格、流程和人与人的协作。当 Agent 进入企业，工作方式将从 “人使用软件” 转向 “人和 Agent 在同一个工作环境里共同完成任务”。

工厂里有一条生产汽车的产线。围绕 AI 和企业内外的上下文，汽车行业正在形成 “第二条产线”。

飞书想进入的，正是这里。

“上下文” 改变汽车产业链的合作模式

在复杂的汽车行业，上下文往往不只存在于一家企业内部。

一辆车的研发涉及主机厂和大量供应商。过去，主机厂提出要求，供应商完成零部件开发，再把成品交给主机厂集成。随着汽车电子和软件越来越重要，双方开始共同设计、共同开发。主机厂更早参与软件和系统定义，供应商也更早进入整车架构。

一方修改需求，另一方的设计、测试和交付节奏都可能随之变化。原本分散在不同公司的研发过程，越来越紧密地连在了一起，也让汽车行业需要的上下文天然跨越企业边界。

业务已经连在一起，信息却还散落在不同系统里。主机厂和供应商都有自己的需求和项目系统，中间仍靠 Word、Excel、邮件和会议传递。文档可以发过去，需求与设计、开发、测试之间的关系却很难一起带过去。会上解决一个问题后，双方还要分别回到自己的系统更新状态。

项目经理因此花大量时间对信息、催进度，同一件事为什么在两个系统里显示不同状态，也常常需要人工解释。

对 AI 来说，它看到的也只是孤立的信息片段。比如，摄像头参数变了，它未必知道会影响算法标定、控制器软件和整车测试；供应商延期了，也未必知道会卡住哪一轮试制。

2026 年年中，上汽与联合汽车电子借助飞书项目打通了一个研发项目。原本分散在邮件、电话里的需求传递、计划同步、变更通知、交付物和评审资料，可以在双方系统之间直接流转，相关文档、会议和讨论也挂到具体事项下面。

上汽把设计需求、零部件设计任务、软硬件开发、测试和评审等 187 个主流程节点放进同一条项目链。每条需求都能继续关联设计、开发和测试任务，并明确负责人和时间。到了节点，系统自动提醒和汇总，项目经理不用再逐个追问，全部计划排期由一至两小时缩短至五分钟，问题溯源和项目交接所需的时间也大幅降低。“这条链上七个角色，分属两家公司，今天跑在同一条流程上。” 上汽集团创新研究开发总院院长王从鹤表示。

更重要的是，需求为什么变化、谁做过什么决定、一次修改影响了哪些环节，过去大量存在于项目经理和工程师记忆里的信息也能随着项目留下来，成为 AI 理解业务所需的上下文。“AI 不缺算力，缺的是上下文。” 王从鹤说。当跨企业的任务、进度、交付物和决策过程持续沉淀在同一条流程中，AI 才有可能真正理解研发现场。一个项目踩过的坑，有机会变成下一个项目可以直接调用的经验。

但合作双方并没有因此进入同一套内部系统。上汽和联合汽车电子属于两个不同的飞书租户，各自的数据、流程和权限仍然分开。主机厂定义共同推进的工作和交付节点，供应商保留内部流程，只开放必要的数据和状态。

这很符合汽车产业链的现实。主机厂和供应商需要一起工作，却不可能向彼此开放全部数据。知识产权、责任归属和数据边界，都要求信息流动的同时保留边界。

飞书进入汽车行业的过程，也在反过来改变飞书。它要理解 APQP、IPD、ASPICE 和整车开发中的质量节点，也要适应供应商的数据边界、不同车企的流程，以及专业工程系统和协作工具之间的分工。

今年 7 月，上汽与飞书把合作扩大到集团层面。在此之前，上汽通用、上汽通用五菱、智己汽车、联合汽车电子等公司已经分别使用飞书。集团签约后，双方开始把合作延伸到研发项目、整零协作、AI 应用，以及 “研产供销服” 等更多环节。

类似的合作正在更多车企中出现。公开数据显示，2025 年销量前十的新能源乘用车品牌中，有 7 家选择了飞书项目；国内销量前 30 名的新能源车企中，约三分之二已经与飞书合作。飞书项目在软件研发管理 SaaS 和 IPD 管理 SaaS 市场的份额分别达到 46.8% 和 68.6%。

上汽大乘用车智能部件部总监张健琼把这种关系类比为 IBM 早年与通用汽车的合作：软件公司先陪第一个客户把复杂项目跑通，再从中找到可以复用的部分，做成其他企业也能使用的产品。第一个客户付出了更多试错成本，软件公司也借此真正学会这个行业。

到了大模型时代，这种积累又多了一层价值。企业能不能用好 AI，不只取决于模型本身，也取决于它能获得多少真实、连续、权限清晰的业务上下文。飞书过去在汽车行业连接项目、文档、会议和流程，也因此成为 AI 进入真实业务的一部分基础。

车企内部的 AI 与 “上下文” 实践

产业链之间的上下文之外，一家车企内部还有另一套更庞杂的信息。

车型越来越多，开发周期越来越短，AI 开始进入研发、质量和管理流程。企业里的 AI 也比个人打开一个聊天框复杂得多。它不仅要读懂一份文件，还要知道文件属于哪个项目、谁有权查看、关联哪些测试，以及它的答案能不能用于正式决策。

会议、文档、群聊、项目节点、质量标准和历史问题，共同记录了一家公司怎么工作。过去几年，不少汽车企业已经把这些信息留在飞书里，同时保留了人员、项目和权限之间的关系。

四维图新的转变很典型。

公司最初考虑自建一套 RAG 知识库，把企业资料重新整理后交给 AI。但他们后来发现，企业信息每天都在变化，人员和项目又有复杂的权限关系。重新建一套知识库，几乎等于再复制一套组织和权限体系。

最终，四维图新直接使用飞书已有的聊天、会议、文档和权限关系，让 AI 在原有权限内读取信息。飞书已经嵌入日常业务，这些上下文会随着工作自然更新，也不需要企业再单独维护一套。

对浙江黎明这样的制造企业，上下文还包括另一类信息：老师傅长期积累的经验。

公司把冷挤压、机加工和模具设计经验整理进智能体。面对新的设计任务，AI 先给建议，工程师再修改；图纸评审也由 AI 先检查、标重点，专家最后判断，单张图纸的审核时间从约三个小时缩短到 10 至 20 分钟。

过去分散在老师傅脑中的工艺经验、设计规则和判断方法，由此变成了组织可以反复使用的能力。

但让 AI 知道一家企业发生过什么，只是第一步。随着 Agent 进入办公场景，新的问题是，AI 能不能利用这些上下文继续完成后面的工作。

8 月 25 日发布的豆包工作，提供了这样一个新的连接方式。它可以围绕目标拆解任务、调用工具，并持续推进复杂工作。放到企业里，飞书保存员工身份、权限、组织关系和工作记录，豆包工作更像一套执行框架，让模型能够在这些上下文之上调用企业已有的工具和流程。

这也让企业 AI 从能根据公司的真实状态继续做事。

银基 CTO 张亮此前已经在尝试类似方式。银基软硬一体的产品和项目涉及的部门、工种、角色非常多，如何快速了解项目和产品的最新进展来支撑下一步的决策，过去需要花费很多时间精力，现在他可以用多个数字分身来整理会议、跟踪目标、汇总进度。同时，因为项目和会议已经记录了工作过程，他不再要求团队额外写一遍周报，获取信息的效率却成倍提高了。“我们已经相信，它能很好地了解我的上下文。” 他说。

不过，企业上下文并不会天然汇集在同一个系统里，也不是所有信息都适合被打通。银基还要通过钉钉、企业微信和个人微信与客户沟通，这些信息无法自动回到飞书。即使技术上可以连接，信息是否愿意开放，也取决于企业之间的利益和信任。保隆 CIO 黄军林认为，如果主机厂只是借助过程透明进一步压价、压缩周期，供应商就不会愿意开放更多信息。与此同时，出于 GDPR 合规、员工隐私和公司内部政策等方面的考虑，欧洲团队对数据和会议记录设置了更严格的边界，部分能力也会因此受到限制。

因此，AI 需要读懂企业，但 “读懂” 从来不等于看到一切。信息在什么关系中产生、可以流向哪里，本身就是上下文的一部分。飞书已经积累了不少汽车企业的项目、文档和协作记录，而决定这些积累最终价值的，是它们能否在明确的权限与边界之内，进一步转化为 AI 可以可靠执行的任务。

当大模型进入千行百业后，人变得更重要了

汽车行业并不是孤例。

随着 AI 从回答问题走向参与工作，越来越多行业都开始意识到上下文的重要性。同样的大模型进入不同企业，能发挥多大作用，还取决于企业自己的知识、数据、权限和工作记录。

摩根士丹利给财富管理顾问做的 AI 助手，连接了公司自己的研究和知识库。目前，它已经可以从约 10 万份内部文档中回答问题，超过 98% 的顾问团队在使用。几十年积累下来的研究、流程和客户服务经验，让 AI 能够回答一家金融机构真正关心的问题。

沃尔玛也在做类似的事。它的 Wally 把销售、库存和需求数据放在一起，帮助采购团队判断哪里缺货、为什么缺货；面向员工的 MyAssistant 则可以读取门店、团队和经营信息。零售业务每天都在变化，AI 接入这些持续更新的信息后，才能参与实际经营。

但企业里的上下文，并不只存在于文档和数据库里。

代码、制度和 SOP 记录了企业明确写下来的规则，更多真正影响工作的东西，其实一直留在人身上。

一个质量工程师知道，某类异常过去出现过几次，最后是怎么解决的；采购负责人知道，同样一句交付承诺，放在不同供应商身上意味着什么；一线员工知道，流程手册里的十个步骤，真正容易出问题的是哪两个。

这些经验很多没有完整写进系统，却每天都在影响企业的判断。AI 要参与这些判断，也必须逐渐理解这些原本分散在人和部门里的信息。

这也意味着，AI 进入一家企业以后，光把现有资料接进来还不够。管理层要决定哪些业务值得投入，哪些数据可以开放；业务负责人要把真正的问题说清楚；一线员工则最清楚哪些工作反复发生，哪些判断长期依赖经验。

人的参与，本身也在不断补充企业的上下文。