高远Himee-ALM 亮相 ICIC 2026：AI 智能体如何重构智能座舱研发管理链路

高远Himee-ALM 是北京高远华信科技有限公司（高远科技）推出的应用生命周期管理方案，由高远科技开发、依托飞书项目运行，面向智能座舱与汽车软件研发场景，把 AI 智能体内嵌进需求、设计、测试、缺陷、发布的完整链路，实现需求双向追溯、ASPICE / ISO 26262 / ISO 21434 证据自动沉淀。在客户项目实测中，缺陷录入成本下降 97%、准确率 98%，ASPICE 审核从 2-3 周压缩到数分钟。

9 月这场会，开馆前一小时，主会场外的走廊就被堵住了。

来的人比预想的多——整车厂、座舱方案商、芯片公司、AI 平台方、检测认证机构，几乎都到齐了。2026 国际汽车智能座舱大会（ICIC 2026）由中国汽车工程学会主办，今年的主题是「全域 AI 驱动·智能体重构座舱新未来」。议题拆开来看，每一条都指向同一件事：当座舱体验从「人适应车」翻到「车适应人」，研发链路本身要先翻一遍。

高远科技创始人兼 CEO 张会斌受邀在大会「关键技术会议三：基础支撑关键技术会议」做主题分享，题目是《AI 智能体在智能座舱产品研发管理中的应用》。

会上展示的，是高远Himee-ALM 在汽车软件研发全链路上引入 AI 智能体之后的真实结果——不是 demo，是客户项目里实测的数字。

一、一个正在发生的转折：研发链路要先翻一遍

张会斌没有从产品讲起，先抛了一个现场共识：座舱研发现在承受的是双重压力，而且都在同时收紧。

这两条线，一条都不肯让步。

一条是软件迭代本身。 座舱 HMI、车控逻辑、语音交互的迭代节奏已经从「季度发布」滑到「月级、两周级」，一次车型研发往往并行 10 条以上需求线，还要处理跨域集成与基线变更。旧式季度发布节奏，已经接不住这样的并发量。

另一条是合规与可验证门槛。 ASPICE 流程评估、ISO 26262 功能安全、ISO 21434 网络安全，每一项都要求从需求、设计、测试到变更的完整证据链。传统靠人工维护追溯矩阵的模式，已经不可持续。

迭代要求你快，合规要求你慢。过去的解法是加人，现在人已经加不动了——这正是 AI 智能体必须进场的位置。

二、问题出在模式上，不只是工具上

再多的协作工具，也补不上研发模式本身的三道裂缝。

第一道：链路割裂，工具孤岛。 需求、设计、测试、缺陷、发布散落在 5 个以上系统里，跨工具数据全靠人工搬运。同一条需求在 Excel、需求池、测试管理、变更单之间被反复录入，链路一旦断就再难拼回。

第二道：追溯繁琐，人工矩阵。 ASPICE、ISO 26262 要求需求-设计-测试双向可追溯。现实中维护一份追溯矩阵需要跨多份 Excel 逐行核对，遗漏率高，ASPICE 评估时只能临时拼凑证据。

第三道：事务繁重，专业被淹没。 需求工程师大量时间花在拆解、录入、找相似、打基线、导数据这些事务性工作上，留给客户场景辨析、技术方案权衡的精力反而被挤压。

三、不是外挂插件，是长在底座上的「数字化员工」

演讲里这个判断被张会斌反复强调：离开统一的研发数据基座，智能体只能解决零散的事务，无法串起需求、追溯、合规这条主链。

座舱研发需要的是嵌入流程本身的协同能力，不是又一个对话框。

没有挂在底座上的智能体，都只是零散的小工具；座舱研发要的，是流程里的「数字化员工」。

四、三项原则，一群员工

高远Himee-ALM 的解法被总结成「三项原则、一群员工」。

原则一，流程先行。 先把座舱研发的主链路画清楚，识别每段的输入输出与判定规则，标准条款配置化。流程不画清楚，智能体就只是零散的小工具。

原则二，合规内嵌。 把 ASPICE、ISO 26262、ISO 21434 的证据要求写进动作里，智能体在每个节点自动检查规则，证据沉淀到对应工作项。合规不再是评估前的一次突击，而是日常动作的自然产出。

原则三，人机协同。 智能体给结论，人做最终决策。检索、拆解、录入、对比、核对这些重活被接过去之后，需求工程师、架构师、测试人员回到方案权衡与场景辨析本身。

「一个底座、一群员工」是这套方案的结构：高远Himee-ALM 是研发数据与流程的中枢，多智能体集群挂在这个底座上协同工作。

五、八大能力：从需求进入到质量闭环

八大能力模块覆盖了座舱研发从需求进入到质量闭环的完整链路：

双向追溯完整性检查沿着 V 模型链路自动遍历——从干系人需求、系统需求、软件需求，到架构、详细设计、代码，再到单元测试、集成测试、系统测试，最后回到缺陷与回归——识别断链、错链、单向链和信息不一致。

六、实测数据：不是 demo 的数字

以下数字来自高远Himee-ALM 在客户项目中的实测结果。

PDF 解析能力在 6000 页 / 9000 条需求文档上用时 3 小时，准确度 96% 左右。

七、三本账：周期更短、举证更省、资产更厚

研发周期更短。 事务性工作被智能体接管后，需求拆解从 1-2 天压到数分钟，用例下发节省 90% 人工。

合规举证更省。 ASPICE、ISO 26262、ISO 21434 的证据不再临时拼凑，审核一键出报告，2-3 天压到数小时。

车型资产更厚。 需求库、追溯矩阵、缺陷知识在底座内持续沉淀，下一代车型可直接复用上一代已验证的条目与用例集。资产沉淀本身，就是跨车型研发效率的复利。

演进方向是把智能体用到舱驾融合的场景里，逐步实现座舱研发由人工驱动转向数据驱动。

座舱研发的下一道分水岭，不在谁的座舱硬件更亮，而在谁能把 AI 智能体长进研发链路里——让人做判断，让智能体做执行与核对。

常见问题

Q1：高远Himee-ALM 和我们正在用的飞书项目是什么关系？

它就装在飞书项目里。飞书项目负责需求、缺陷、项目这些基础管理，高远Himee-ALM 由高远科技开发、依托飞书项目运行，在上面加了一层，把座舱研发的合规要求、追溯关系和 AI 能力接进来。它不是飞书项目自带的标准功能。 已经在用飞书项目的团队不用换平台。

Q2：演讲里展示的 97% 成本下降、90% 人工节省，是真实数据吗？

是。这些数字来自高远Himee-ALM 在客户项目中的实测结果，不是 demo 数据。具体客户名称、规模、阶段可预约演示进一步交流。

Q3：AI 智能体和我们之前说的插件、工作项有什么不同？

插件和工作项是「工具」，负责承担某一项功能；AI 智能体是「数字化员工」，能按岗位角色承担多步连续任务——从检索、拆解、对比、校验到回流工作项，结论回到主链路上供人改判。智能体挂在一个统一的研发数据底座上协同工作，而不是各自为政的零散工具。

Q4：已经在用 Polarion 或 Jira 的团队，能直接用吗？

高远Himee-ALM 依托飞书项目运行，最适合已经在用飞书项目、需要补齐合规与追溯能力的团队。已有 Polarion 等重资产投入的团队，通常先做双轨并行，逐步迁移。

Q5：AI 给出的审核结论可以直接用于 ASPICE 评估吗？

AI 逐条查证据并给出结论，每条结论附带依据，但最终判定与签字仍由审核员完成。高远Himee-ALM 的定位是把核对工作做完，把判断权留给人。

Q6：没有 ASPICE 评估压力的团队，值得上吗？

值得，但收益点不同。追溯与合规检查的收益与评估压力正相关；如果主要是效率诉求，需求解析与缺陷处理这两块的投入产出比更高。

关于高远科技

北京高远华信科技有限公司（高远科技）成立于 2007 年，是国家级高新技术企业，飞书项目专精伙伴、飞书生态联盟伙伴（Meego & aPaaS）、AI 生态伙伴、火山引擎 AI 解决方案伙伴，美国 PMI 授权教育合作伙伴。总部位于北京，在上海、武汉、合肥、深圳设有分支机构，客户遍及汽车、高端制造、电气、电力、离散制造等行业。

高远Himee-ALM 是高远科技的应用生命周期管理产品，由高远科技开发、依托飞书项目运行。名字中，Hi 取自 highfar（高远），mee 取自 meegeo（飞书项目 Meego），ALM 即 Application Lifecycle Management（应用生命周期管理）——它代表的是高远与飞书项目联合打造的、面向应用全生命周期的研发管理方案。

获取完整演讲资料

如果你的团队也在被座舱研发的需求录入、追溯矩阵、ASPICE 审核这几件事压着，欢迎扫码预约演示或领取完整演讲资料，我们会结合你的项目规模与阶段给出具体测算。

#高远Himee-ALM #高远科技 #应用生命周期管理 #智能座舱研发 #AI 智能体 #ASPICE #ISO 26262 #ISO 21434 #需求双向追溯 #飞书项目 #汽车软件研发 #ICIC 2026