车端AI(二)——AI系统工程师：搭建AI驱动的ASPICE需求管理平台

系列导读：本文为「车端AI」系列第二篇。上一篇《车端AI(一)——AI系统工程师：遵循ASPICE AI管理车端系统需求》从方法论层面梳理了ASPICE需求工程与车端AI的映射关系。本篇将从工程实战角度出发，完整展示如何搭建一个AI驱动的车端需求管理平台——从架构设计、核心AI模块实现、到文档导出与合规审计，提供可复用的代码框架和避坑指南。

目录

专栏文章索引

1. 为什么需要一个AI驱动的需求管理平台

上一篇文章中我们分析了车端AI需求管理的三大痛点——规模爆炸（L2+项目3000-5000条需求）、跨域耦合（感知→融合→规划→控制→执行5层间200+条依赖）、变更频繁（单项目150-300次变更）。这三个痛点叠加在一起，传统人工管理方式（Excel + Word + 邮件评审）已经捉襟见肘。

那么，一个真正能落地的AI驱动需求管理平台需要具备什么能力？

能力维度 传统工具（DOORS/Polarion） AI驱动平台 管理价值差异
需求采集 人工录入，逐条填写 AI解析场景文本，自动生成结构化需求 效率提升5-10倍
需求分配 人工逐层分解，评审确认 AI自动分配+跨层一致性检测，人工确认 减少需求断裂风险
变更管理 人工评估影响范围，邮件流转 AI自动识别影响域，5分钟出分析报告 变更处理周期从5天缩至1.5天
质量度量 人工评审打分，季度复盘 AI实时5维度评分+趋势预测 从"事后补救"到"事前预防"
追溯矩阵 人工维护，易遗漏 自动生成+覆盖率分析+缺口预警 审核准备从2周缩至2天

基于以上分析，我们在某L2+项目中搭建了一个AI驱动的需求管理平台（下文称ASPICE_AI平台），并在实际项目中完成了从需求采集到审核交付物的全流程验证。

AI应用项目仪表盘 可以同时管理多个项目

2. 平台技术架构与选型决策

2.1 技术栈选型

平台的技术选型遵循三个原则：成熟稳定（车端项目容错率低）、国产化优先（数据不出境）、AI友好（原生支持LLM集成）。

层级 技术选型 选型理由
前端框架 React 18 + TypeScript 5.5 类型安全、生态成熟、Ant Design组件库丰富
UI组件库 Ant Design 5.x 企业级组件库，表格/表单/图表一站式
数据可视化 @ant-design/charts 与Ant Design无缝集成，支持饼图/柱状图/条形图
状态管理 Zustand 轻量级，比Redux简洁50%，适合中等规模应用
后端框架 FastAPI 异步原生支持、自动API文档、Pydantic校验
ORM SQLAlchemy 2.0 (async) 异步查询、类型提示、成熟的关系映射
数据库 SQLite/PostgreSQL 开发环境用SQLite快速验证，生产环境切PostgreSQL
缓存 Redis AI结果缓存（24h TTL），减少重复调用成本
AI模型 DeepSeek / Qwen / GPT-4o 多厂商热切换，国内优先DeepSeek/Qwen
文档生成 python-docx + reportlab Word/PDF正式文档生成，满足ASPICE审核交付

2.2 系统架构总览

平台采用经典的前后端分离架构，核心分为四层。如上图架构示意图所示，前端层承载了Dashboard、需求管理、ODD、RTM、变更、质量、AI Hub等核心功能模块；API层通过FastAPI提供统一的RESTful接口；服务层封装了AI Parser、Allocator、Change Manager等核心业务逻辑；基础设施层则提供PostgreSQL、Redis、LLM Provider和文件存储等底层支撑。

架构决策记录：

  • 为什么不用微服务？ 车端需求管理平台是内部工具，用户量<100人，单体架构足够支撑。微服务引入的运维复杂度（服务发现、配置中心、链路追踪）在内部工具场景下投入产出比不合理。
  • 为什么AI模块独立封装？ AI模块（Parser、Allocator、ChangeManager）与业务逻辑解耦，通过统一的AIService编排层调用。这样可以在不修改业务代码的前提下切换LLM供应商——实测从GPT-4o切换到DeepSeek只需改一行配置。
  • 为什么用Redis缓存AI结果？ LLM调用是平台最贵的操作（单次调用约0.01-0.05元），相同的场景文本在短期内可能被多次解析。通过SHA-256哈希缓存key + 24小时TTL，实测减少约60%的重复调用。

3. 数据模型设计：车端需求的全域建模

车端需求管理的数据模型需要覆盖从项目→ODD→需求→追溯→变更→质量的完整链路。以下是核心数据模型的设计：

3.1 需求模型（Requirement）

需求是整个平台的核心实体。车端需求与传统软件需求的关键区别在于：需要记录层级（感知/融合/规划/控制/执行）、ASIL等级、度量指标和ODD关联。
需求管理demo

3.2 追溯关系模型（RequirementLink）

追溯矩阵的底层数据结构是有向图的边表：
RTM demo，演示已除去敏感项目数据

3.3 变更请求模型（ChangeRequest）

变更管理遵循7阶段状态机：提出 → 影响分析 → 评审 → 批准 → 实施 → 验证 → 关闭。
变更管理演示

4. 核心AI模块实现

这是平台最核心的部分。我们将第一篇博客中描述的理论框架落地为四个可运行的AI模块。

4.1 AI需求解析引擎：从场景文本到结构化需求

核心思路：将ODD场景描述文本输入LLM，通过精心设计的Prompt模板，输出符合ASPICE规范的结构化需求列表。关键在于后处理校验——LLM的输出可能不符合车端约束（如感知延迟>80ms），需要在后处理中自动修正。

4.2 AI需求分配器：跨层分解与一致性校验

核心挑战：车端需求从系统级分解到各子系统时，存在严格的时序链约束和精度链约束。例如，系统端到端延迟≤300ms，则感知延迟+融合延迟+规划延迟+控制延迟的总和不能超过300ms。

平台界面演示：

在需求详情抽屉中，点击「AI分解」按钮，系统自动将顶层需求分解为4-5条子需求（感知/融合/规划/控制），并在底部展示一致性校验结果。绿色表示时序链和ASIL链通过校验，红色表示存在矛盾并给出修正建议。用户可逐条勾选「接受」后导入。
子需求管理

4.3 AI变更影响分析：多维影响传播

变更影响分析是平台最复杂的AI模块。当一条需求发生变更时，需要自动识别：哪些上下游需求受影响？哪些测试用例需要重跑？功能安全等级是否需要重评估？

五维度评分模型说明：

维度 权重 评分依据 低于60分的风险
完整性 25% 需求对ODD场景的覆盖率 存在ODD场景盲区（如夜间/隧道场景未覆盖）
一致性 20% 跨层需求无矛盾、无重复ID 需求断裂，开发阶段返工
可测试性 25% 有量化指标（metric_value）的需求占比 无法编写验收测试用例
可追溯性 20% 来源、设计文档、测试用例引用完整度 ASPICE审核不通过
变更稳定性 10% 版本号>3的需求占比 需求不稳定，开发反复修改

在这里插入图片描述

4.4 AI质量度量引擎：五维度评分与趋势预测

五维度评分模型说明：

维度 权重 评分依据 低于60分的风险
完整性 25% 需求对ODD场景的覆盖率 存在ODD场景盲区（如夜间/隧道场景未覆盖）
一致性 20% 跨层需求无矛盾、无重复ID 需求断裂，开发阶段返工
可测试性 25% 有量化指标（metric_value）的需求占比 无法编写验收测试用例
可追溯性 20% 来源、设计文档、测试用例引用完整度 ASPICE审核不通过
变更稳定性 10% 版本号>3的需求占比 需求不稳定，开发反复修改

在这里插入图片描述

5. 需求追溯矩阵：ASPICE审核的核心交付物

追溯矩阵（RTM）是ASPICE审核员必查的交付物。平台实现了两种视图：矩阵视图（N×N网格，直观展示需求间关系）和表格视图（传统列表，含追溯完整度指标）。

5.1 追溯矩阵的后端实现

class RTMService:
    """需求追溯矩阵服务"""

    async def get_matrix(self, project_id: int) -> dict:
        requirements = await self._get_requirements(project_id)
        links = await self._get_links(project_id)

        # 构建节点（需求）和边（追溯关系）
        nodes = [{
            "id": r.id, "req_id": r.req_id, "title": r.title,
            "asil": r.asil, "layer": r.layer, "status": r.status,
        } for r in requirements]

        edges = [{
            "source": link.source_req_id, "target": link.target_req_id,
            "type": link.link_type, "description": link.description,
        } for link in links]

        # 追溯覆盖率分析
        traced_ids = set()
        for link in links:
            traced_ids.add(link.source_req_id)
            traced_ids.add(link.target_req_id)

        return {
            "nodes": nodes,
            "edges": edges,
            "total_requirements": len(requirements),
            "total_links": len(links),
            "traced_count": len(traced_ids),
            "untraced_count": len(requirements) - len(traced_ids),
        }

5.2 覆盖率分析

平台不仅展示追溯矩阵，还自动计算四项覆盖率指标：

覆盖率指标 计算方式 达标阈值 ASPICE关联
设计文档覆盖率 有design_doc_ref的需求占比 ≥80% SYS.3/SWE.3
测试用例覆盖率 有test_case_ref的需求占比 ≥80% SYS.4/SWE.6
父子关系覆盖率 有parent_id的需求占比 ≥60% SYS.2/SWE.2
总体追溯率 至少有一条link的需求占比 ≥90% SUP.8

6. AI Copilot：上下文感知的对话式助手

除了结构化的AI功能（解析/分配/变更分析/质量度量），平台还集成了一个全局AI Copilot，支持对话式交互。
在这里插入图片描述

6.1 核心设计

Copilot的设计遵循三个原则：

  1. 上下文感知：自动注入当前项目名称、领域类型、所在页面信息到每次对话中
  2. 会话记忆：支持多轮对话，自动管理上下文窗口（12K tokens）
  3. 智能压缩：当对话长度超过窗口的75%时，自动调用LLM压缩历史消息
class AgentService:
    """AI Copilot服务 — 会话管理与上下文压缩"""

    MAX_CONTEXT_TOKENS = 12000
    COMPRESS_THRESHOLD = 0.75
    KEEP_RECENT_MESSAGES = 6

    async def chat_stream(self, session_id: int, user_message: str):
        """SSE流式对话"""
        session = await self._get_session(session_id)
        messages = await self._get_messages(session_id)

        # 估算当前上下文token数
        context_text = "\n".join(m.content for m in messages if not m.is_compressed)
        estimated_tokens = self._estimate_tokens(context_text)

        # 超过阈值则压缩上下文
        if estimated_tokens > self.MAX_CONTEXT_TOKENS * self.COMPRESS_THRESHOLD:
            await self._compress_context(session_id, messages)
            messages = await self._get_messages(session_id)

        # 构建消息（含系统提示词）
        context_messages = self._build_context(session, messages, user_message)

        # 流式输出
        async for chunk in self.llm.stream_chat(context_messages):
            yield chunk

    async def _compress_context(self, session_id: int, messages: list):
        """压缩历史对话：保留最近N条，摘要更早的消息"""
        recent = messages[-self.KEEP_RECENT_MESSAGES:]
        old = messages[:-self.KEEP_RECENT_MESSAGES]

        if not old:
            return

        # 调用LLM生成摘要
        summary_prompt = f"请用不超过300字总结以下对话的关键信息：\n" + \
                        "\n".join(f"{m.role}: {m.content[:200]}" for m in old)
        summary = await self.llm.analyze(summary_prompt)

        # 将旧消息标记为已压缩，创建摘要消息
        for m in old:
            m.is_compressed = True
        summary_msg = ConversationMessage(
            session_id=session_id, role="summary",
            content=summary, is_summary=True
        )
        await self._save_message(summary_msg)

6.2 页面感知快捷操作

Copilot会根据用户当前所在页面，自动推荐相关操作：

当前页面 快捷操作
需求管理 检查需求质量、查找需求缺口
追溯矩阵 追溯分析、覆盖率建议
变更管理 变更影响评估、变更趋势分析
质量度量 项目健康分析、改进建议

7. 正式文档导出：从平台数据到审核交付物

ASPICE审核需要提交正式的文档交付物。平台实现了5种正式文档的自动生成：

文档类型 格式 内容概要 审核关联
需求规格说明书 Word (.docx) 封面+修订历史+目录+引言(含ODD)+按层级分组需求表+追溯摘要+ASIL分布 SYS.1/SYS.2
质量报告 PDF 质量评分+ASIL饼图+状态分布+追溯覆盖率+风险评估+改进建议 MAN.3/SUP.1
追溯矩阵报告 Excel (.xlsx) 追溯主表+覆盖率分析+缺口分析+统计仪表盘 SUP.8
ODD定义文档 Word (.docx) ODD概览+参数详情+关联需求+覆盖矩阵 SYS.1
变更影响报告 Word (.docx) 变更概览+详细列表+影响分析+风险评估+生命周期追踪 SUP.8/SUP.10

7.1 Word文档生成（以需求规格说明书为例）

class DocxReportService:
    """需求规格说明书 Word 文档生成器"""

    async def generate_requirements_spec(self, project_id: int) -> io.BytesIO:
        project = await self._get_project(project_id)
        requirements = await self._get_requirements(project_id)
        links = await self._get_links(project_id)
        odds = await self._get_odds(project_id)

        doc = Document()
        self._setup_styles(doc)  # 微软雅黑, 标题色 #1F3A5F

        self._add_cover_page(doc, project)         # 封面（项目信息表）
        self._add_revision_history(doc, project)    # 修订历史
        self._add_toc_placeholder(doc)              # 目录占位（Word域代码）
        self._add_introduction(doc, project, odds)  # 引言（含ODD参数表）
        self._add_requirements_by_layer(doc, requirements)  # 按层级分组
        self._add_traceability_summary(doc, requirements, links)  # 追溯摘要
        self._add_asil_summary(doc, requirements)  # ASIL分布

        buffer = io.BytesIO()
        doc.save(buffer)
        buffer.seek(0)
        return buffer

文档样式设计要点：

  • 字体统一使用微软雅黑（兼顾中英文可读性）
  • 标题颜色 #1F3A5F（深蓝，传达专业/可信感）
  • 表格使用 “Light Grid Accent 1” 样式（Word内置，兼容性好）
  • 封面信息表含项目编号、车辆平台、自动驾驶等级、领域类型、目标ASIL、生成日期

7.2 PDF质量报告生成

class PdfReportService:
    """项目质量报告 PDF 生成器"""

    async def generate_quality_report(self, project_id: int) -> io.BytesIO:
        # ...数据加载...

        # 质量评分算法：PDF导出报告采用4指标简化公式
        # （注：平台仪表盘使用第4.4节的五维度模型；PDF报告作为审核交付物，
        #  采用更直观的4指标公式，便于评审专家快速理解）
        # 描述完整率(25%) + 度量指标率(20%) + 追溯覆盖率(30%) + 审批通过率(25%)
        score = int(
            desc_rate * 0.25 + metric_rate * 0.20 +
            trace_rate * 0.30 + approve_rate * 0.25
        )

        # 评分着色：≥80绿色，≥60橙色，<60红色
        score_color = "#27AE60" if score >= 80 else "#F39C12" if score >= 60 else "#E74C3C"

7.3 企业级集成：飞书多维表格与DOORS互转

在真实企业落地中，需求管理平台很少从零开始——团队往往已经在使用飞书多维表格（轻量协作）或IBM DOORS（传统重型工具）。平台必须支持与这些存量系统的双向数据互转，才能真正嵌入企业工作流。

7.3.1 飞书多维表格 ↔ 平台需求双向同步

飞书多维表格在车端团队中广泛用于需求初稿采集和跨部门评审。平台实现了双向同步适配器：

方向 映射逻辑 同步策略
飞书 → 平台 飞书字段 → 平台Requirement模型字段（标题/描述/层级/ASIL/负责人/状态） 定时轮询（每5分钟）+ Webhook实时触发
平台 → 飞书 平台需求变更 → 飞书多维表格行更新 变更事件驱动，增量同步 
class FeishuBitableSync:
    """飞书多维表格 ↔ 平台需求双向同步适配器"""

    FEISHU_FIELD_MAPPING = {
        "需求编号": "req_id",
        "需求标题": "title",
        "需求描述": "description",
        "层级": "layer",
        "ASIL等级": "asil",
        "负责人": "assignee",
        "状态": "status",
        "ODD场景": "odd_scenario",
        "度量指标": "metric_value",
    }

    async def sync_from_feishu(self, app_token: str, table_id: str, project_id: int):
        """从飞书多维表格拉取需求到平台"""
        records = await self.feishu_client.get_records(app_token, table_id)
        for record in records:
            fields = record["fields"]
            req_data = {
                feishu_field: fields.get(feishu_field)
                for feishu_field, platform_field in self.FEISHU_FIELD_MAPPING.items()
            }
            # 去重：按飞书记录ID匹配已有需求
            existing = await self.repo.get_by_feishu_record_id(record["record_id"])
            if existing:
                await self.repo.update(existing.id, req_data)
            else:
                req_data["feishu_record_id"] = record["record_id"]
                await self.repo.create(project_id, req_data)

    async def sync_to_feishu(self, app_token: str, table_id: str, project_id: int):
        """将平台需求变更推送到飞书多维表格"""
        changes = await self.change_log.get_unpushed(project_id, source="feishu")
        for change in changes:
            req = await self.repo.get_by_id(change.requirement_id)
            fields = {
                platform_field: getattr(req, platform_field)
                for feishu_field, platform_field in self.FEISHU_FIELD_MAPPING.items()
            }
            if req.feishu_record_id:
                await self.feishu_client.update_record(
                    app_token, table_id, req.feishu_record_id, fields
                )
            else:
                record = await self.feishu_client.create_record(
                    app_token, table_id, fields
                )
                req.feishu_record_id = record["record_id"]
                await self.repo.update(req.id, {"feishu_record_id": record["record_id"]})

关键设计决策：

  • 飞书作为"轻量入口"：评审人员可在飞书表格中直接编辑需求状态/负责人，平台自动同步并触发AI质量评分更新
  • 冲突处理：以平台为"源端"，飞书变更与平台变更冲突时，以平台最新版本为准，飞书变更进入待确认队列
  • 字段映射可配置：通过YAML配置文件管理字段映射关系，不同项目可自定义映射规则
7.3.2 DOORS需求导入/导出（ReqIF标准格式）

IBM DOORS仍是许多Tier 1和OEM的"标准配置"。平台通过ReqIF（Requirements Interchange Format） 标准格式实现与DOORS的双向互转：

class DoorsReqifConverter:
    """DOORS ReqIF格式导入/导出转换器"""

    REQIF_NAMESPACE = "http://www.omg.org/spec/ReqIF/20110401/reqif.xsd"

    async def export_to_reqif(self, project_id: int) -> io.BytesIO:
        """将平台需求导出为ReqIF格式（可直接导入DOORS）"""
        requirements = await self._get_requirements(project_id)
        links = await self._get_links(project_id)

        # 构建ReqIF XML结构
        reqif = etree.Element(f"{{{self.REQIF_NAMESPACE}}}REQ-IF")
        core_content = etree.SubElement(reqif, "CORE-CONTENT")

        # 规格对象（SpecObjects）= 需求
        spec_objects = etree.SubElement(core_content, "SPEC-OBJECTS")
        for req in requirements:
            spec_obj = etree.SubElement(spec_objects, "SPEC-OBJECT")
            spec_obj.set("IDENTIFIER", req.req_id)
            values = etree.SubElement(spec_obj, "VALUES")
            self._add_attribute(values, "Title", req.title)
            self._add_attribute(values, "Description", req.description)
            self._add_attribute(values, "Layer", req.layer)
            self._add_attribute(values, "ASIL", req.asil)
            self._add_attribute(values, "Status", req.status)
            self._add_attribute(values, "MetricValue", str(req.metric_value or ""))

        # 规格关系（SpecRelations）= 追溯链接
        spec_relations = etree.SubElement(core_content, "SPEC-RELATIONS")
        for link in links:
            spec_rel = etree.SubElement(spec_relations, "SPEC-RELATION")
            spec_rel.set("IDENTIFIER", f"LINK-{link.id}")
            source = etree.SubElement(spec_rel, "SOURCE")
            source.set("REF", link.source_req_id)
            target = etree.SubElement(spec_rel, "TARGET")
            target.set("REF", link.target_req_id)
            etree.SubElement(spec_rel, "TYPE").set("REF", link.link_type)

        buffer = io.BytesIO()
        tree = etree.ElementTree(reqif)
        tree.write(buffer, xml_declaration=True, encoding="UTF-8")
        buffer.seek(0)
        return buffer

    async def import_from_reqif(self, reqif_content: bytes, project_id: int):
        """从ReqIF文件导入需求到平台"""
        tree = etree.parse(io.BytesIO(reqif_content))
        root = tree.getroot()

        # 解析SpecObjects
        spec_objects = root.findall(f".//{{{self.REQIF_NAMESPACE}}}SPEC-OBJECT")
        for spec_obj in spec_objects:
            req_id = spec_obj.get("IDENTIFIER")
            values = spec_obj.find(f"{{{self.REQIF_NAMESPACE}}}VALUES")
            attrs = self._parse_attributes(values)
            await self.repo.create_or_update(project_id, {
                "req_id": req_id,
                "title": attrs.get("Title", ""),
                "description": attrs.get("Description", ""),
                "layer": attrs.get("Layer", "system"),
                "asil": attrs.get("ASIL", "QM"),
                "status": attrs.get("Status", "draft"),
                "metric_value": attrs.get("MetricValue"),
            })

        # 解析SpecRelations（追溯链接）
        spec_relations = root.findall(f".//{{{self.REQIF_NAMESPACE}}}SPEC-RELATION")
        for spec_rel in spec_relations:
            link_id = spec_rel.get("IDENTIFIER")
            source = spec_rel.find(f"{{{self.REQIF_NAMESPACE}}}SOURCE").get("REF")
            target = spec_rel.find(f"{{{self.REQIF_NAMESPACE}}}TARGET").get("REF")
            link_type = spec_rel.find(f"{{{self.REQIF_NAMESPACE}}}TYPE").get("REF")
            await self.link_repo.create({
                "source_req_id": source,
                "target_req_id": target,
                "link_type": link_type,
            })

企业级集成要点：

集成场景 方案 适用阶段
存量DOORS数据迁移 一次性ReqIF全量导入，保留原始req_id和追溯关系 平台初始化
日常双向同步 平台作为主数据源，按需导出ReqIF快照供DOORS消费 持续运营
飞书+DOORS双轨并行 飞书用于评审协作，DOORS用于正式基线管理，平台居中桥接 过渡期
增量变更同步 基于时间戳的增量导出，避免全量传输 持续运营

落地经验：在某Tier 1项目中，客户要求同时对接飞书（研发团队使用）和DOORS（功能安全团队使用）。平台通过上述双向适配器，实现了"飞书录入→平台AI解析→DOORS基线归档"的三层流水线，单次需求变更的端到端流转时间从原来的2天缩短至15分钟。

在这里插入图片描述

8. 合规审计与ASPICE CL2检查

平台内置了ASPICE CL2级别的合规检查功能，自动对照8个过程域进行评估：

过程域 检查内容 达标条件
SYS.1 需求获取 需求是否有来源字段、是否关联ODD ≥80%需求有明确来源
SYS.2 需求分析 需求是否有度量指标、是否可测试 ≥70%需求有量化metric
SYS.3 架构设计 需求是否有层级分配、是否有设计文档引用 ≥60%需求有layer+design_ref
SYS.4 集成测试 需求是否有测试用例引用 ≥60%需求有test_case_ref
SUP.8 配置管理 追溯矩阵完整度、基线管理 追溯率≥80%
MAN.3 项目管理 项目信息完整、变更管理流程 变更全部有记录
SUP.1 质量保证 需求评审覆盖率、质量评分 评审率≥50%
SWE.1 软件需求 软件需求分解完整度 有层级分解的需求≥40%

每个过程域的评估结果实时展示在审计页面中，支持一键导出审计日志CSV作为审核证据。

在这里插入图片描述

9. 落地经验与避坑指南

在实际项目落地过程中，我们总结了以下关键经验：

9.1 LLM选型：没有银弹

在这里插入图片描述

经验 具体教训 解决方案
中文理解差异大 某国际LLM在解析中文法规条款（GB/T）时频繁误读 国内场景优先用DeepSeek/Qwen，中文准确率提升30%+
输出格式不稳定 LLM偶尔返回非法JSON，导致解析失败 后处理层增加正则兜底 + 重试机制（最多3次）
延迟波动 同一模型在不同时段响应时间差异2-10倍 前端SSE流式展示，用户无需等待完整结果
成本控制 大量需求批量解析时LLM调用费用快速增长 Redis缓存+语义去重（相似度>0.95的请求复用缓存）

9.2 Prompt工程：领域知识是关键

通用的LLM不了解ASPICE和车端AI的领域知识。关键在于将领域知识注入Prompt：

# 系统提示词（所有AI模块共享的领域上下文）
SYSTEM_PROMPT = """你是一位车端AI系统需求管理专家，具备以下专业知识：

1. 熟悉ASPICE (Automotive SPICE) 开发流程，特别是SYS.1-SYS.4和SWE.1-SWE.6过程域
2. 熟悉ISO 26262功能安全标准，理解ASIL等级(A/B/C/D)的分配和分解规则
3. 熟悉自动驾驶系统架构：感知→融合→规划→控制→执行的5层架构
4. 了解车端传感器特性：摄像头、毫米波雷达、激光雷达的检测距离/精度/延迟参数
5. 了解车端计算平台约束：算力(TOPS)、功耗(W)、内存(GB)的典型限制

在输出需求时，确保：
- 每条需求都是可测试的（包含可量化的指标和单位）
- ASIL等级与功能安全影响匹配
- 各层延迟预算之和不超过系统端到端约束"""

9.3 人机协作模式

平台的AI输出始终定位为**“管理建议"而非"自动决策”**。核心原则：

  • ASIL C/D的需求变更：AI分析结果必须经功能安全经理人工审批
  • 需求分配结果：AI生成的子需求需逐条人工确认后才入库
  • 质量评分：AI评分作为参考，最终评审结论由评审委员会确定

这个设计决策在ASPICE审核中得到了审核员的认可——审核员关注的不是"是否用了AI"，而是"AI输出是否有适当的人工确认机制"。

9.4 数据安全保障

车端需求数据涉及企业核心技术，平台在数据安全方面做了以下保障：

  • LLM调用可私有化：支持DeepSeek/Qwen私有部署，数据不出企业内网
  • API密钥加密存储：使用Fernet对称加密，数据库泄露也不会暴露密钥
  • 审计日志全覆盖：所有写操作自动记录审计日志，满足ASPICE可追溯性要求
  • 权限分级：5种角色（管理员/系统工程师/安全经理/测试工程师/观察者）的RBAC控制

10. 总结与展望

10.1 平台能力总览

模块 核心功能 AI介入程度 ASPICE关联
项目管理 多项目CRUD、领域模板、标准框架 无 MAN.3
需求管理 全生命周期CRUD、看板视图、批量操作 深度（解析/分配/评审） SYS.1/SYS.2/SWE.1
ODD管理 运行设计域定义、参数矩阵 间接（作为AI上下文） SYS.1
追溯矩阵 N×N矩阵、覆盖率分析、缺口预警 自动生成 SUP.8
变更管理 7阶段状态机、AI影响分析 深度（影响传播/安全评估） SUP.8/SUP.10
质量度量 五维度评分、趋势预测、风险项 深度（评分/预测） MAN.3/SUP.1
AI Hub 主动洞察、活动追踪、用量统计 核心 —
AI Copilot 上下文感知对话、流式输出、会话记忆 核心 —
文档导出 Word/PDF/Excel/ReqIF 5种报告 自动生成 全部
企业集成 飞书多维表格双向同步、DOORS ReqIF互转 无（数据管道） SUP.8
合规审计 ASPICE CL2 8过程域检查、操作日志 自动评估 全部

10.2 量化效果

在实际L2+项目中，平台带来了以下量化改进：

指标 改进前 改进后 提升幅度
需求结构化效率 每人每天30条 AI辅助每人每天150+条 5倍
变更影响分析耗时 3-5个工作日 5-10分钟 ~300倍
ASPICE审核准备周期 2-3周 2-3天 ~7倍
需求追溯覆盖率 65-75% 90%+ +20%
跨层需求矛盾发现率 评审时才发现（滞后） 分配时实时检测 提前2个阶段
飞书→DOORS流转周期 2天（人工导出+格式转换） 15分钟（自动管道） ~50倍

10.3 下一步规划

方向 计划内容 预期价值
知识图谱增强 引入Neo4j持久化需求知识图谱，替代内存NetworkX 支撑万级需求的影响分析
RAG知识库 基于历史项目需求构建向量知识库，支持相似需求检索 新项目启动时自动推荐历史需求模板
多模态理解 支持上传传感器布局图/系统架构图，自动提取约束 减少人工录入工作量
AI测试用例生成 基于已整理的结构化需求，自动生成符合ASPICE规范的测试用例骨架（含前置条件、测试步骤、预期结果、ASIL等级关联） 缩短测试设计周期，实现"需求整理完→AI自动生成测试用例"的端到端流水线
CI/CD集成 需求变更触发自动化测试流水线 实现需求→测试的全自动回归

下期预告：本文完成了从需求采集、AI解析、变更管理到文档导出的全链路搭建。但需求管理的最终目的是驱动高质量的测试验证。下一篇《车端AI(三)——AI全栈开发：从需求到代码实现、自动HIL测试》

系列文章索引

声明：本文所述平台为作者在实际项目中搭建的AI驱动需求管理系统，文中截图为平台演示环境的脱敏数据，不涉及任何具体客户项目的真实需求。平台的AI模块代码为作者原创，LLM调用层支持多供应商热切换。如需交流技术方案，欢迎在评论区留言。

版权声明：本文为CSDN博主「Dear_Knight」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。

# 人工智能 # 汽车 # 架构 # 需求分析
Logo
CSDN-OPC开发者社区

这里是“一人公司”的成长家园。我们提供从产品曝光、技术变现到法律财税的全栈内容，并连接云服务、办公空间等稀缺资源，助你专注创造，无忧运营。

更多推荐

cover

从零构建 Java 智能体 RAG 系统：Milvus 向量数据库实战指南

avatar CSDN-OPC开发者社区
cover

提升办公效率：OpenClaw 本地自动化 AI 工具搭建实战教程

avatar CSDN-OPC开发者社区
cover

OpenClaw一键安装部署操作指南，TopClaw中文界面零基础上手

avatar CSDN-OPC开发者社区