座舱研发的迭代节奏已经从「季度发布」滑到「月级、两周级」，一次车型研发往往并行 10 条以上需求线；而 ASPICE、ISO 26262、ISO 21434 仍在要求一条从需求、设计、测试到变更的完整证据链。一边要快，一边要可验证------这两件事同时收紧，靠人工维护追溯矩阵已经接不住。
在 2026 国际汽车智能座舱大会（ICIC 2026，中国汽车工程学会主办）的关键技术会议上，高远Himee-ALM（高远科技推出的、基于飞书项目的应用生命周期管理方案）展示了它在汽车软件研发全链路上引入 AI 智能体之后跑出的实测结果。
这篇文章不谈概念，只拆四件能落地的工程事：怎么把 6000 页 PDF 拆成可追溯条目、怎么查断链、怎么把合规检查写进动作里、以及无网环境怎么回写结果。文末附实测数据与几个必须说清的工程边界。
一、先说结论：问题不在工具，在模式
再多的协作工具，也补不上研发模式本身的三道裂缝。
|------|----------------------------------------------|----------------------|
| 裂缝 | 具体表现 | 直接后果 |
| 链路割裂 | 需求、设计、测试、缺陷、发布散落在 5 个以上系统，跨工具数据靠人工搬运 | 同一条需求被反复录入，链路断了就拼不回去 |
| 追溯繁琐 | ASPICE / ISO 26262 要求双向可追溯，实际靠跨多份 Excel 逐行核对 | 遗漏率高，评估时只能临时拼证据 |
| 事务繁重 | 需求工程师大量时间花在拆解、录入、找相似、打基线、导数据 | 留给场景辨析与方案权衡的精力被挤压 |
这三道裂缝的共同点是：它们都不是「换个工具」能解决的，因为工具之间没有共同的数据底座。
二、外挂式 AI 与内嵌式智能体的差别
这是整场分享里最值得记的一个判断：离开统一的研发数据基座，智能体只能解决零散事务，串不起需求、追溯、合规这条主链。
|------|--------------------|--------------------|
| 对比维度 | 外挂式 AI | 内嵌式智能体 |
| 数据位置 | 数据分散，AI 结论需人工二次搬运 | 直接读写底座数据 |
| 流程感知 | 流程不感知 AI，结论游离在主链路外 | 结论回流到工作项、评审节点、追溯链路 |
| 协同方式 | 人把数据喂给 AI，再把结论抄回来 | 人和智能体在同一套流程上协同 |
| 能力边界 | 单点的效率工具 | 按岗位角色承担多步连续任务 |
一句话概括：没有挂在底座上的智能体，都只是零散小工具；座舱研发要的是流程里的「数字化员工」。
落到工程上，三条原则：
- 流程先行 ------ 先把主链路画清楚，识别每段的输入输出与判定规则，标准条款配置化。流程不画清楚，智能体就是零散工具。
- 合规内嵌 ------ 把 ASPICE、ISO 26262、ISO 21434 的证据要求写进动作里，每个节点自动检查，证据沉淀到对应工作项。
- 人机协同 ------ 智能体给结论，人做最终决策。检索、拆解、录入、对比、核对这些重活被接过去，工程师回到方案权衡本身。
三、落点一：PDF 需求解析与条目化
客户发来的需求文档经常是几千页 PDF。人工拆解的成本是 20 天（专业需求工程师 2 个月工时），AI 解析压到 2 小时。
关键不在「读出来」，而在保留原始大纲层级并切成独立条目。下面这段是工程实现的思路：先按层级判断 heading，再用规则筛出 requirement，剩下的归为 information。
```python
import re
# 需求句的强特征词，中英文都要覆盖
REQ_PATTERN = re.compile(
r"(应当|必须|应|需满足|不低于|不大于|shall|must|shall\s+be)", re.I
)
# 维度标签关键词表，命中即打标
TAG_RULES = {
"安全": ["功能安全", "ASIL", "安全机制", "失效", "safety"],
"诊断": ["DTC", "故障码", "诊断", "UDS", "diagnostic"],
"性能": ["响应时间", "时延", "帧率", "throughput", "latency"],
"变体": ["配置字", "变体", "高配", "低配", "variant"],
}
def classify_paragraph(text: str, level: int) -> str:
"""按大纲层级 + 句式特征判断段落类型"""
text = text.strip()
if level <= 3 and len(text) < 40 and not REQ_PATTERN.search(text):
return "heading"
if REQ_PATTERN.search(text) and len(text) > 15:
return "requirement"
return "information"
def assign_tags(text: str) -> list:
"""为条目打功能 / 非功能 / 诊断 / 安全 / 变体标签"""
tags = []
for tag, keywords in TAG_RULES.items():
if any(k.lower() in text.lower() for k in keywords):
tags.append(tag)
return tags or ["功能"]
def parse_requirements(paragraphs: list) -> list:
"""paragraphs: [(level, text), ...]"""
items, current_path = [], []
for level, text in paragraphs:
kind = classify_paragraph(text, level)
if kind == "heading":
current_path = current_path[: level - 1] + [text]
continue
if kind == "requirement":
items.append({
"id": f"REQ-{len(items) + 1:04d}",
"path": " / ".join(current_path),
"text": text,
"tags": assign_tags(text),
})
return items
```实测数据：6000 页、约 9000 条需求的文档，解析耗时 3 小时，准确度 96% 左右。
这里有个容易踩的坑：纯规则分类在长句上会漏。工程上的做法是规则先过一遍，把置信度低的段落丢给模型二次判断，不要指望一套正则吃到底。
四、落点二：需求相似度查找
新需求进来时，先判断「历史上是不是已经有了」。直接全库比对太慢，工程做法是两段式：向量召回 Top 10，再让模型做差异性分析。
```python
import numpy as np
def embed(texts: list, model) -> np.ndarray:
""" texts -> (N, d) 向量矩阵，已归一化 """
vecs = np.array([model.encode(t) for t in texts], dtype="float32")
return vecs / np.linalg.norm(vecs, axis=1, keepdims=True)
class ReqIndex:
def __init__(self, texts: list, model):
self.texts = texts
self.vecs = embed(texts, model)
def search(self, query: str, model, top_k: int = 10):
q = embed([query], model)[0]
scores = self.vecs @ q # 余弦相似度
idx = np.argsort(-scores)[:top_k]
return [(self.texts[i], float(scores[i])) for i in idx]
def fingerprint(self, text: str) -> str:
"""语义指纹：用于快速判断是否为完全重复条目"""
import hashlib
norm = "".join(text.split()).lower()
return hashlib.md5(norm.encode()).hexdigest()[:16]
```为什么不直接让模型判断重复？因为全库比对的成本和幻觉风险都不可控。召回 Top 10 之后，模型只需要对 10 个候选做差异分析，准确率显著提高，成本也压得住。
五、落点三：双向追溯完整性检查（核心）
这是 ASPICE 评估里最耗时的一项。V 模型链路从干系人需求 → 系统需求 → 软件需求 → 架构 → 详细设计 → 代码 → 单元测试 → 集成测试 → 系统测试 → 缺陷与回归，人工逐行核对一份矩阵要几天。
工程上把它建模成有向图，四类问题都能自动检出：断链、错链、单向链、信息不一致。
```python
from dataclasses import dataclass, field
from typing import Dict, List, Set
# V 模型主干顺序，用于检出跨级跳跃（错链）
V_ORDER = [
"干系人需求", "系统需求", "软件需求", "架构设计", "详细设计",
"代码", "单元测试", "集成测试", "系统测试", "缺陷",
]
LEVEL = {name: i for i, name in enumerate(V_ORDER)}
@dataclass
class WorkItem:
id: str
type: str
title: str
baseline: str = "v1.0"
upstream: Set[str] = field(default_factory=set) # 上游：被谁派生
downstream: Set[str] = field(default_factory=set) # 下游：派生出谁
def check_traceability(items: Dict[str, WorkItem]) -> List[dict]:
issues = []
for it in items.values():
# 1. 断链：非首节点却没有任何上游
if LEVEL[it.type] > 0 and not it.upstream:
issues.append({"item": it.id, "type": "断链",
"detail": f"{it.type} 无上游追溯"})
for up in it.upstream:
src = items.get(up)
if src is None:
issues.append({"item": it.id, "type": "断链",
"detail": f"上游 {up} 不存在"})
continue
# 2. 错链：跨级跳跃（隔了 2 层以上）
if LEVEL[src.type] + 1 < LEVEL[it.type]:
issues.append({"item": it.id, "type": "错链",
"detail": f"{src.type} -> {it.type} 存在跨级跳跃"})
# 3. 单向链：我认上游，但上游不认我
if it.id not in src.downstream:
issues.append({"item": it.id, "type": "单向链",
"detail": f"上游 {up} 未登记下游 {it.id}"})
# 4. 信息不一致：基线版本对不上
if src.baseline != it.baseline:
issues.append({"item": it.id, "type": "信息不一致",
"detail": f"基线 {src.baseline} vs {it.baseline}"})
return issues
```跑在 9000 条需求的真实项目上，输出大致是这个形态：
```
断链 : 37 条 (软件需求 22 / 单元测试 15)
单向链 : 128 条 (集中在架构 -> 详细设计)
错链 : 6 条 (系统需求直接挂到代码)
信息不一致 : 41 条 (基线 v1.0 与 v1.1 混用)
```输出里必须带责任对象与修复建议，否则这份报告没人愿意用------只报「哪里错了」的报告，最后都躺在共享盘里。
实测效果：这一步从原来的 2-3 周压到数分钟。AI 逐条查证据、给结论，每条结论附带依据，审核员在此基础上改判，而不是替他判。
六、落点四：合规内嵌与用例闭环
把合规要求配置化，而不是写在 Word 里靠人记。
```yaml
# compliance/aspice_cl2.yaml
checklist:
- id: REQ-001
dimension: 功能
rule: "需求必须包含可验证的验收准则"
detect: { has_pattern: ["应", "shall", "must"] }
severity: major
- id: REQ-002
dimension: 安全
rule: "涉及 ASIL 的需求必须标注安全等级"
detect: { require_tag: ["安全"], has_pattern: ["ASIL"] }
severity: blocker
- id: TEST-001
dimension: 可验证
rule: "每条软件需求至少有一条通过的测试用例覆盖"
detect: { min_downstream: { type: "单元测试", status: "passed", count: 1 } }
severity: blocker
```
```python
import yaml
def run_compliance(item: WorkItem, checklist: list, items: dict) -> list:
"""对单个工作项执行检查表，返回不符合项"""
problems = []
for rule in checklist:
d = rule.get("detect", {})
if "has_pattern" in d:
if not any(p in item.title for p in d["has_pattern"]):
problems.append((rule["id"], rule["severity"], rule["rule"]))
if "require_tag" in d:
if not set(d["require_tag"]) & set(getattr(item, "tags", [])):
problems.append((rule["id"], rule["severity"], rule["rule"]))
if "min_downstream" in d:
need = d["min_downstream"]
hit = sum(1 for x in item.downstream
if items[x].type == need["type"])
if hit < need["count"]:
problems.append((rule["id"], rule["severity"], rule["rule"]))
return problems
```用例下发与执行这块，实测 90% 人工节省：2000 个测试用例一键下发到电子表格，支持无网环境录入结果，回来后 AI 自动回写预期与缺陷。
```python
from openpyxl import Workbook, load_workbook
def export_cases(cases: list, path: str):
"""下发：生成离线可填写的用例表"""
wb = Workbook()
ws = wb.active
ws.append(["用例ID", "关联需求", "前置条件", "步骤", "预期结果", "实际结果", "状态"])
for c in cases:
ws.append([c["id"], c["req"], c["pre"], c["steps"], c["expect"], "", "待测"])
wb.save(path)
def import_results(path: str, base: dict) -> list:
"""回写：解析离线结果，处理与基线的冲突"""
ws = load_workbook(path).active
conflicts, results = [], []
for row in ws.iter_rows(min_row=2, values_only=True):
cid, actual, status = row[0], row[5], row[6]
if base.get(cid) and base[cid]["expect"] != actual and status == "通过":
conflicts.append({"id": cid, "reason": "预期与实际不一致但标记为通过"})
results.append({"id": cid, "actual": actual, "status": status})
return results, conflicts
```冲突必须显式报出来，不要静默覆盖。这是无网回写最容易出事的地方------现场改了预期，回来又覆盖掉，追溯链就废了。
缺陷侧实测 97% 成本下降、准确率 98%：18000 条缺陷从 1 人月、2 万元人工录入，转为 60 天 AI 批量录入、1800 元。支持多模态识别语音、文字、图片，缺陷属性自动打标、解决方案智能生成、负责人自动匹配。
七、实测数据汇总
以下数字来自高远Himee-ALM 在客户项目中的实测结果，不是 demo 数据。
|-----------|-------------|---------------------|-------------------------|
| 环节 | 改造前 | 改造后 | 幅度 |
| 缺陷录入 | 1 人月 / 2 万元 | 60 天 AI 批量 / 1800 元 | 成本下降 97%，准确率 98% |
| 用例下发 | 人工逐条分发 | 2000 条一键下发 + 自动回写 | 人工节省 90% |
| ASPICE 审核 | 2-3 周 | 数分钟出结论，人改判 | 数量级压缩 |
| 需求解析 | 20 天人工拆解 | 2 小时 AI 解析 | 6000 页 / 9000 条，准确度 96% |
八、工程边界：几个必须说清的坑
这部分比数据更重要，也是我们在客户项目里付过学费的地方。
- 智能体给结论，不替人背锅。 审核结论、追溯判定都要有人改判环节完全自动化的 ASPICE 签字，目前不现实也不合规。
- 相似度只给候选，不做自动合并。 召回 Top 10 后由工程师决定是复用还是新建，自动合并会把历史需求污染掉。
- 单向链不等于错。 有些断链是历史遗留的合理状态，检查器要支持「已确认豁免」，否则报告里全是噪音，工程师就不看了。
- 无网回写必须冲突检测。 离线期间基线可能已变，回写时按工作项 ID + 基线版本双校验。
- 流程没画清楚之前别上智能体。 我们见过最失败的案例是先买了工具再补流程，结果智能体只是把混乱自动化了一遍。
常见问题
Q1：Himee-ALM 和飞书项目是什么关系？
它就装在飞书项目里。飞书项目负责需求、缺陷、项目这些基础管理，高远Himee-ALM 由高远科技开发、依托飞书项目运行，在上面加了一层，把座舱研发的合规要求、追溯关系和 AI 能力接进来。**它不是飞书项目自带的标准功能。**已经在用飞书项目的团队不用换平台。
Q2：97% 成本下降、90% 人工节省这些数字怎么来的？
来自高远Himee-ALM 在客户项目中的实测结果，不是 demo 数据。因客户保密约定，具体名称与规模不在此披露。
Q3：AI 智能体和普通插件、工作项有什么不同？
插件和工作项是工具，承担某一项功能；AI 智能体按岗位角色承担多步连续任务------从检索、拆解、对比、校验到回流工作项，结论回到主链路供人改判，并且挂在同一套研发数据基座上协同，而不是各自为政。
Q4：没有 ASPICE 评估计划的团队，这套东西有用吗？
有用，但收益点会变。追溯与合规检查的收益依赖评估压力；如果主要是效率诉求，需求解析与缺陷处理这两块的投入产出比更高。
Q5：能直接替换现有的 Polarion / Jira 吗？
不建议一上来就谈替换。高远Himee-ALM 依托飞书项目运行，适合已经在用飞书项目、需要补合规与追溯能力的团队；已有 Polarion 重资产的团队，通常先做双轨并行。
文中所涉数据来自客户项目实测，不同项目规模与阶段会有差异。如果你也在做座舱研发的需求解析、追溯检查或 ASPICE 举证，欢迎在评论区留言交流具体场景。