合规 + 溯源 + 高效 | 汽车软件文档的最优解“磐析DOC”内测持续招募中

 

  产品介绍// 
 

 

磐析——AI 驱动的ISO 26262 Part6软件设计文档自动生成桌面工具。

 

从客户C/C++代码仓库出发，在分钟到小时级产出可追溯的软件架构设计与单元设计文档。

 

  一句话定位// 
 

 

磐析把「读代码 → 建结构 → 写规范文档→ 做质量门禁」整条链路产品化：

 

不是通用聊天式Copilot，而是面向功能安全软件设计（Part 6）的专用生成系统，让团队把精力从重复性排版与抄写，转回到架构判断与评审。

 

01

行业痛点：为什么传统做法跟不上

 

痛点1：文档与代码脱节

典型现状：设计文档滞后于实现，或靠人工从代码「反推」

后果：评审时无法信任文档，追溯矩阵名存实亡

 

痛点2：Part 6 结构复杂

典型现状：SWSaD / SWUdD、接口规

格、数据流、单元前后置条件等章节多、格式严

后果：资深工程师被文档占用，项目周期被拉长

 

痛点3：大仓分析成本高

典型现状：头文件、调用关系、模块边界靠人工梳理

后果：漏模块、漏接口，ASIL 分解缺乏依据

 

痛点4：通用 AI 不可控

典型现状：一次性Prompt生成，无阶段校验、难续跑

后果：幻觉、章节缺失、无法纳入现有质量体系

 

 

磐析针对的，正是「合规结构+代码真源+可运营生成」三者同时满足的需求。

 

02

领先性：解决可交付的设计证据链

 

 

标准先行，而非事后贴标签

 

生成物对齐ISO26262 Part6软件设计活动，并参考ASPICE SWE.2/SWE.3的文档粒度组织内容，包括：

软件架构设计（SWSaD）：层次结构、模块职责、接口与数据流/控制流

软件单元设计（SWUdD）：单元规格、函数级前后置条件、内部结构

追溯矩阵：需求与设计之间的映射骨

 

Agent 按阶段步骤推进，而不是让模型自由发挥章节标题。

 

 

代码真源＋调用图谱，而不是

「读过README的作文」

 

磐析在生成前会构建面向C/C++的调用图与符号分析，支撑：

项目画像与模块列表的自动归纳

模块级架构摘要

接口、依赖、数据流等章节的可回溯线索（与源码路径、符号信息对齐）

 

这意味着文档描述的是仓库里实际存在的结构与关系，显著降低「看起来专业但与代码不符」的风险——这正是功能安全评审最忌讳的一类问题。

 

 

分段式Agent流水线

＋自动化门禁

 

与「单次长Prompt」不同，磐析采用多阶段主循环：

基线阶段——画像、图谱、章节、全局事实索引

模块撰写——按模块并行/串行产出架构与详设中间稿

全书综合——全局章节（结构分解、接口规格、数据流等）

校验收口——统一检查与装订

 

每个阶段在质量检查通过后才会进入下一步；若发现内容缺失、结构不完整或检查未通过，产品会给出明确的处理建议（例如针对局部补全或从中断处继续），而不是静默交付残缺稿件。

 

这是把生成能力约束在可评审、可修订的工程流程里，而不是依赖「一次生成即定型」的体验。

 

 

可运营：续跑、诊断、进度透明

 

面向真实项目的长时生成，磐析在桌面端提供：

续跑：中断或失败后从checkpoint继续，而非整单重来

进度与活动区：结构化展示当前阶段、模块与工具活动

诊断包导出：失败或停止时可打包日志、引擎近期事件等，便于支持团队定位

停滞策略分级：区分系统休眠、模型流超时与长时间无进展，减少「假进行中」

 

这些能力让 AI 文档生成从「演示玩具」进入可排障、可交付的工程范畴。

 

 

数据主权与部署形态

 

桌面端离线运行：核心分析、编排、导出在本地完成；仅需配置BYOK大模型 API（支持多家云厂商与私有部署端点）

机器绑定 License：按设备授权，适合车企与Tier1对代码出域的管控要求

多格式导出：Markdown（源稿）、Word、PDF，便于纳入现有评审与基线管理流程

 

03

        核心优势一览          

 

维度1：速度

磐析的做法：Agent 引擎自动解析仓库并分阶段成稿

带来的价值：将数周级手工整理压缩到分钟～小时级（视仓库规模与模型响应而定）

 

维度2：一致性

磐析的做法：模板+manifest +assemble 装订

带来的价值：多模块、多文档风格统一，减少「每人写法不同」

 

维度3：可信度

磐析的做法：调用图 + gate 检查 + 追溯线索

带来的价值：评审可对照代码与中间产物，而非纯自然语言信任

 

维度4：合规友好

磐析的做法：Part 6 /ASPICE 粒度预置

带来的价值：降低从「有文档」到「能过审的设计证据」的转换成本

 

维度5：可维护

磐析的做法：章节缓存与指纹、路径真源

带来的价值：代码变更后可针对性续跑，而非全量重写

 

维度6：企业就绪

磐析的做法：本地桌面、License、诊断与导出

带来的价值：适配研发网、安全评审与售后支持流程

 

 

04

        典型适用场景         

 

1、新平台/ 新ECU软件栈：快速拉起首版架构设计与详设底稿，供架构师裁剪

 

2、存量项目补文档：代码已存在但设计文档缺失或严重过时

 

3、供应商交付物对齐：统一乙方输出结构与追溯粒度，降低集成评审成本

 

4、ASIL 升级或变更影响分析：在模块与接口结构化后，更易做波及分析（需结合项目配置与人工裁定）

 

 

05

与常见替代方案的对比（摘要）

 

方案1：纯人工编写

局限：慢、贵、易与代码漂移

磐析的差异化：自动从代码抽取结构，人工聚焦裁切与裁定

 

方案2：静态分析工具仅出图

局限：少叙事、少Part 6叙事章节

磐析的差异化：图谱 + Agent 撰写符合模板的叙述与表格

 

方案3：通用LLM对话

局限：无阶段门禁、难追溯、难续跑

磐析的差异化：流水线、gate、manifest、诊断与续跑一体化

 

方案4：国外通用ALM模板

局限：不贴合国内车企文档习惯与语言

磐析的差异化：中英文档、本地化桌面与 License体系

 

 

结语// 
 

 

功能安全软件设计的难点，从来不只是「会不会写文档」，而是能否持续证明设计与实现一致。

 

磐析的领先性在于：把标准结构、代码分析、Agent编排与质量门禁铸成一条可重复运行的流水线——让团队用更短时间得到可评审、可修订、可追溯的设计文档底稿，而不是又一份与仓库无关的AI散文。