软件架构设计规格书还在手写?AI Agent 正向设计:从需求文档到完整规格书一键生成

做汽车电子软件架构的团队，最怕的不是架构设计本身，而是设计做完，文档才刚刚开始。

一份上百页的需求文档，一套甲方定制的模板（Word + Excel），再加上 ASPICE SWE.3、功能安全 ASIL 分配、分层架构（应用层→服务层→抽象层→驱动层）等规范要求，架构师需要一条一条拆需求、画分层图、定义接口矩阵、写动态时序、标需求追溯。一版需求写一轮，需求变更再来一轮，永远在追赶。

软件架构文档编写，正在变成汽车电子研发流程里一个越来越突出的瓶颈。它慢，因为分层设计维度多、接口关系复杂、规范约束严格；它难，因为覆盖完整性、需求追溯和评审一致性，很难长期只靠人工经验保证。

软件架构设计 Agent 想解决的，就是把架构文档编写从”周级”压缩到”小时级”，并让架构团队从重复整理中解放出来，把时间花在更重要的架构决策、设计评审和方案优化上。

一、痛点：架构文档手写，到底难在哪

把问题摊开，汽车电子软件架构文档手写的难，集中在五件事。

第一，分层太多，人工穷举不现实。 一套完整的中间件架构，涉及应用层、服务层、抽象层、驱动层四层，每层又有多个子架构、数十个组件、上百个软件单元。每个组件要定义功能描述、接口列表、ASIL 等级、开发类型、依赖关系——人工写得再认真，也很难保证不漏。

第二，模板太多，甲方要求各不相同。 不同主机厂的架构模板格式差异大：有的要求 Word 版规格书 + Excel 接口矩阵，有的要求 PlantUML 架构图 + Markdown 正文。模板里的 <XX><XXX> 占位符几十处，逐一替换既耗时又容易遗漏。更不用说甲方模板更新后，格式调整又要重来一遍。

第三，规范太多，覆盖靠记忆不可靠。 ASPICE SWE.3 对软件详细设计有明确的评审要素要求（O-1~O-9），功能安全标准对 ASIL 分配和隔离有硬性约束。哪些检查项需要覆盖，哪些反模式需要规避，长期靠人工经验维护，风险很高。

第四，需求一变，文档就要返工。 需求文档更新后，架构设计必须同步调整。但”改了哪些需求”和”哪些组件受影响”之间，往往缺少清晰关联。漏改不会立刻报错，只会在后续开发中静默留下风险。更棘手的是，当需要对比两个版本的架构差异时，人工逐条比对接口信号、依赖关系、资源分配，工作量巨大且极易遗漏。

第五，评审成本高，越到后面越容易走形。 一条架构设计是否合理，通常要同时对照需求、接口、规范和历史经验。几十个组件还能逐条看，上百个就很容易从”认真评审”变成”格式检查”。更糟的是，评审意见的整改往往缺少闭环——改了没有、改了什么、改后是否引入新问题，追踪成本很高。

前三点拖的是效率，后两点埋的是质量隐患。而第四点——需求变更后的文档同步和版本差异分析——恰恰是汽车电子架构这类强追溯领域最在意，也最难靠人力稳定覆盖的部分。

二、场景一：系统软件架构正向设计——从一份需求文档到完整规格书

这是最核心，也最能体现”效率差”的场景。

以一个典型的座舱域控制器项目为例：需求文档 80+ 页，涉及电源管理、通信管理、诊断管理、状态管理等多个功能域。人工编写架构规格书，架构师需要逐条拆需求、按四层架构分层、定义子架构和组件、逐一编写功能描述与接口定义、绘制架构图和时序图、填写接口矩阵、建立需求追溯。一个熟练架构师完成上述工作，两到四周是常态。

过去：数周手写 架构师需要逐一分析需求、分层设计、编写文档、画图、校对。期间需求变更一次，就要重新排查影响范围。

现在：小时级生成 架构师只需提交需求文档和甲方模板，Agent 自动完成需求分析、分层设计、接口定义、动态场景设计和文档生成，最终交付一份完整的 Word 规格书、Excel 接口矩阵和 PlantUML 架构图。架构师不再从空白文档开始，而是基于生成结果进行评审、修订和确认。

但比”快”更重要的是效果：

• 更完整：需求到架构的追溯全覆盖，动态场景和资源分析不再靠”想起来才写”
• 更一致：整份文档的结构、编号、术语风格统一，不同项目之间也能保持同样的交付标准
• 更规范：自动对齐 ASPICE SWE.3 的文档组织要求，分层隔离清晰，不会出现跨层调用这类基础问题
• 更好追溯：每条需求到每个架构元素的映射关系一目了然，需求变更时能快速定位哪些组件需要调整

三、场景二：BSW 基础软件架构——AUTOSAR 模块级设计

如果说中间件架构关注的是”分层组件”，那 BSW（基础软件）架构关注的是 AUTOSAR CP 的模块级和 API 函数级设计。

这也是一个高频痛点场景。BSW 架构规格书需要把每个底层模块提供的 API 函数逐一列清楚——函数名、参数类型和含义、返回值、调用关系——还要补充任务周期、中断向量、编译环境（OS 和编译器版本）。这些信息散落在代码、数据手册和工程师的脑子里，人工整理成文，光是对齐函数签名就和查 bug 差不多。

Agent 的做法是直接从需求文档出发，自动识别项目涉及的 BSW 模块，按模板生成一份完整的 BSW 架构规格书。成品包含：每个模块的 API 函数级定义、任务与中断配置、编译环境说明、需求到架构的追溯表。

效果很直接：以前需要翻阅代码和口头确认来补全的函数签名，现在一次性结构化输出，团队有了一个可以共同引用的”底座文档”。新增模块时不再是”问问老李当时怎么设计的”，而是看规格书。

四、场景三：甲方模板适配——再也不怕模板换了

甲方模板变更是架构师的另一个”噩梦”。不同的主机厂、不同的项目阶段，模板格式千差万别。每次模板更新，都意味着一轮繁重的格式调整。

但这个问题本质上不是”架构设计”问题，而是”数据与格式耦合”问题。架构数据——组件定义、接口矩阵、动态场景——并不会因为模板换了一版就改变；真正消耗时间的，是把同样的数据按新模板重新排版和校对。

Agent 的做法就是把这两件事解耦：架构设计产出的数据保持结构化，模板适配则自动完成”数据填充到格式”这一步。无论是 Word 规格书还是 Excel 接口矩阵，Agent 都能自动识别模板的章节结构和占位符，将架构数据准确填入对应位置，同时保留模板原有的字体、段落、表格样式。

这样做带来的三个核心优势：

第一，模板更新零返工。 甲方换模板，架构师不需要逐章重新排版。重新提交新模板，Agent 走一遍流程输出新格式的规格书，架构数据不变，格式自动对齐。

第二，一份数据，多格式输出。 同一套架构设计数据，可以同时按主机厂 A 的模板输出 Word，按主机厂 B 的模板输出 Excel，按内部评审模板输出 Markdown。不再需要为不同交付对象维护多套文档。

第三，内容和格式分开维护。 架构师专注设计内容，模板的表格列数、章节顺序、样式细节这些格式问题由 Agent 自动处理。模板里的填写说明会被自动清除，占位符会被自动替换，图表会被自动嵌入——人工不需要逐行检查和修补。

写在最后

软件架构设计 Agent 的目标，从来不是取代架构师。它要替掉的，是架构文档编写里那些重复、机械、最消耗耐心的部分——拆需求、填模板、画图、标追溯、做检查；而把人，留给那些真正需要经验和判断力的决定：架构方案选型、设计 trade-off 评估、评审质量把关。

尤其是在汽车电子软件架构这种强规范、强分层、强追溯的领域，它最大的价值不只是”写得快”，而是让架构文档这件事变得更稳定、更一致、更容易进入团队的工程闭环——每份文档都有迹可循，每次变更都可追溯，每次评审都有据可依。

当架构师不再被空白文档和甲方模板困住，真正重要的工作才刚刚开始。

本文是软件架构设计 Agent 系列的第一篇，聚焦正向设计——从需求文档出发，生成中间件和 BSW 架构规格书。后续将陆续介绍：架构评审（如何用 Agent 对规格书做自动化评审）、版本差异对比（需求变更后精准定位影响范围）、逆向架构生成（从遗留代码还原架构文档），以及更多域的架构设计实践。敬请关注。