最近半年，我们发现选型会上的问题变了。

以前客户围着我们问的是"支持哪些流程模板""能不能覆盖 ASPICE 全流程"——说白了，都是问功能清单。现在不一样了，越来越多的人开口第一句就是："你们的智能体，能自己干活吗？"

这个问题问到点子上了。但答案特别容易走偏。参加过的这类讨论里，以为智能体会把现有流程软件推倒重来的人，占了大多数。这是个误判，而且是个代价不低的误判。

变的不是功能，是软件的形态

亚远景做了十几年评估，见过好几轮工具换代，但这次的性质不一样。

传统流程软件——不管是 ALM、需求管理还是追溯工具——本质上都是"记录系统"。它的工作是存：存需求、存追溯链、存评审记录。流程得靠人推，人看完信息、做完判断，再回到系统里把状态改掉。软件从头到尾是被动的。

智能体带来的变化，是软件第一次能"理解目标、自主执行"：你给它一个目标，它自己去读数据、找路径、执行动作、核对结果。软件从被动记录，变成主动完成。

这个差别，用一件具体的事说得最清楚。

一条需求变更提进来，在记录系统里，它只是多了一条状态为"待处理"的记录，后面全靠人：谁去评审、要不要改设计、哪些测试受影响，一项项点过去。而"理解目标、自主执行"的智能体是另一回事：它先读这条变更，顺着追溯链找出所有受影响的条目，把影响范围列成清单，标出哪些产物要复核——你拿到的不再是一条待办，而是一份"这 7 个条目需要复核"的工作单。

前者是记录，后者是执行。这两者的距离，就是过去二十年流程软件和接下来十年智能体之间的距离。

Gartner 给过一个数字：到 2026 年底，40% 的企业级应用会集成面向特定任务的智能体。行业里给这次迁移起了个名字——从"记录系统"到"结果系统"。

为什么这件事在汽车电子行业格外难，也格外确定

先说难。

汽车电子的流程软件不只是提效工具，它是证据的载体。ASPICE、ISO 26262、ISO 21434 都要求每一步可追溯、可核查。一个只会"生成内容"的智能体在这里没用——它得说清这条需求从哪来、这份证据挂在哪个过程域上、这个结论是谁定的。

再说确定。

准入门槛在抬，研发预算在压，定点窗口在缩，三股压力一起压过来，靠加人已经加不动了。凯捷今年的调研里，89% 的车企说过去三年研发成本明显上升，多数高管认为未来两三年必须降本 15%–20% 才能保住竞争资格。这时候，"要不要用智能体"根本不是选择题。

行业里的动作已经很明确。今年 3 月，海外有厂商发布了一套专门对准 ASPICE 全 V cycle 的多智能体方案，云端和物理隔离的本地环境都能跑，而且直接嵌进 OEM 和 Tier-1 现有的工程工具链——注意，是嵌进去，不是换掉。目前已经在北美、日本、印度的项目里落地。国内的思路也趋同，一句话概括：让人做判断，让智能体做执行和核对。

关键判断：路径是「先融合，再逐步替代」

这是我们最想讲清楚的。

现在谈智能体，有两种姿态。一种是"革命派"，张口就是传统软件要完了；另一种是"改良派"，觉得在现有软件上加个 AI 助手就算完事。我们认为，两种都不对。

正确的路径是——先把智能体融合进你现有的系统，再谈逐步替代。

三个理由，每一个都有我们见过的反面例子。

第一，数据长在旧系统里。 一家做了十年的供应商，需求库、追溯链、缺陷知识全都沉淀在现有平台里。推倒重来，等于把这些资产清零。我们见过有团队为了"上智能体"把用了五年的需求库推倒，结果迁移到一半发现历史追溯链对不上，评估师讲不清来龙去脉，反而多花了半年。这一点，国际工业软件厂商自己也看得很清楚——他们在既有产品线里嵌入智能体，让工程师无需切换原有工作流。让工具适应人，而不是让人去适应新工具。

第二，合规要求智能体继承治理，而不是绕开它。 权限、审计、变更记录，在汽车电子里不是可选项，是底线。所以智能体必须长在记录系统之上，继承它的权限模型和审计能力，而不是在旁边另起一套"AI 系统"。我们也见过图快的团队，让工程师把设计文档贴到一个公有云对话工具里"帮忙写"，写是写出来了，客户审核那天拿不出任何留痕，也说不清数据流向，那个环节最后整个返工。绕开治理换来的"高效"，到了评估现场一文不值。

第三，能力升级是有台阶的。 有厂商把 AI 能力明确分成三级：给建议 → 做分析与风险预防 → 自主执行。我们认为这不是保守，这是工程规律——先在低风险环节验证它，确认它靠得住，再逐步放开手脚。一上来就谈"全自主"的，要么是没踩过坑，要么是在卖概念。反过来说，我们也见过一上来就把智能体放到最高自主级的团队，第一批产物评审全挂——倒不是因为内容错，是因为没人说得清每条结论的依据是什么。那是责任的问题，不是准确率的问题。

所以"融合"不是妥协，是必经的入口。"替代"会发生，但它是结果，不是起点。

给正在选型的企业三条建议

别问"能不能自动生成文档"，问"能不能读到我系统里的数据、再把结果写回去"。 前者是生成能力，后者才是融合能力。读不到、写不回，那它就只是个侧边栏，看着热闹。

把边界设计清楚。 哪些环节可以自主执行、哪些必须人审批、哪些必须留下签字那个名字——尤其涉及 ASIL 定级、风险接受这类判断的时候。边界越清晰，敢放开的范围才越大。

试点选"最痛但不致命"的环节。 需求解析、追溯核对、评估前自查，这几处人工消耗大、结果可验证，适合先跑。跑通了，再往上走。

我们的立场

亚远景不做"替代"的姿态，做"融合"的工程。所以我们的产品只有一条设计原则：往你现有体系里长，不要求你推倒重来。

产品推荐清单

对应着前面那条路径，看我们这边有什么。

研发过程与文档

• DPAI｜开发过程增强智能：按 ASPICE、ISO 26262、ISO/SAE 21434 三条标准做的研发垂类智能体，V 模型 10 个过程域全覆盖，文档生成、代码双向工程、AI 评审一起做。实测 82 → 26 人天，整体提效 68%；生成内容 82% 以上无需修改。

• AI-APMS｜智能研发过程管理平台：四大 AI 能力原生嵌进每个工作产品——智能文档一键生成、自动追溯构建、AI 智能合规评审、智能文本编辑。其中自动追溯建链为国家发明专利。典型 Tier1 架构项目口径：单项目工时 85 → 24.5 人天。

安全分析

• AI-HARA：ISO 26262 危害分析与风险评估。八步标准流程加 46 条场景库；ASIL 不走 AI 推理，由前端本地矩阵计算，追求 100% 准确。周期从 1–2 周压到 30 分钟–2 小时。

• AI-FMEA：按 AIAG-VDA 六步法做失效模式与影响分析，S/O/D 有评分准则、AP 自动计算。一份复杂系统的分析从 2–4 周压到 3–5 天。

• AI-TARA：ISO/SAE 21434 威胁分析与风险评估，对齐 UN RCE R155。八步分析引擎，CAL 自动计算。单项目从 2–3 周压到 1–2 天。

• AI-FTA：对齐 ISO 26262 与 IEC 61025 的智能故障树分析。自动建树，最小割集、最小径集与 FV 重要度一并算出。3–5 天的工作，2–4 小时出首版。

三条共同的设计原则

1. 读得进来，也写得回去。 全部支持与你已有的 ALM / PLM / 需求管理系统集成，标准 API 加 ReqIF 导出。

2. 继承你的治理。 全部支持纯私有化部署，数据不出内网、支持本地大模型；权限分级、操作留痕、版本可审计。

3. AI 出初稿，人做判断。 ASIL 这类定级由本地矩阵算，不由 AI 推理；AI 生成的内容明确标记，正式结论须经工程师审核签核。我们也提供 AI 工具置信度（TCL）评估的支持材料，帮你回答评估访谈里"AI 参与了多少"这类问题。

软件形态的更替不会敲锣打鼓，它是在你继续用着旧系统的那些日子里，悄悄完成的。

你现在的流程工具里，有哪些环节，已经可以放手让智能体接手了？要是拿不准从哪切，把你最痛的那一段拿出来——我们用你的真实工件跑一遍。