从 SOR 到软硬件规范，一条链路不再返工——汽车控制器需求助手实战
原文链接：https://mp.weixin.qq.com/s/0mwi5GmEJPB-kRDh3j3sSA
把"3 周写不完的需求规范"压到"3 小时自动出初稿 + AI 辅助校核" —— 给汽车系统、软硬件工程师的工程工具。
第 0 章 开头：评审前夜的崩溃现场
周四晚上 11 点 47 分，某Tire1功能安全工程师老陈，盯着屏幕上对齐到一半的需求追溯表，揉了揉太阳穴。
这是他连续第三周加班赶同一份文档——《电控转向系统功能安全需求规范》。SOR（Statement of Requirements，需求陈述文件）上周刚被OEM客户改了一版，理由是"新增 L2 辅助泊车场景的安全目标"。改动本身不大，就是多了 3 条安全目标。
可问题在于，**系统需求（SysR）**里的 18 个章节、**硬件需求（HWR）**里的 22 个模块、**软件需求（SWR）**里 BSW + ASW 数十个章节，都要重新对齐。一条 SysR 改了，下游的 HWR、SWR 可能连带要改 7、8 处。
老陈打开 Word 的"修订模式"和 Excel 的"vlookup"，开始一处处手动比对。这已经是他这个月第三次做同样的事情了。
手机弹出消息，评审组群里的吐槽：
“又改了？你这次又准备让我们陪你熬夜评审吗？““能不能给个一致性的版本号，我先看下结构是否还对得上……”
老陈苦笑了一声——他知道，问题从来不是"愿不愿意加班”，而是这套全靠人肉对齐的工作方式，本身就不可持续。
这不是老陈一个人的故事。
据我们接触的十几家 OEM/Tier 1 来看，一份完整的系统级功能安全规范（含 SysR + HWR + SWR 三层）的传统编制周期是 3 到 6 周，而其中至少有40% 的工时被消耗在"重复对齐"和"防止漂移"上。
而最让人头疼的是：每一次 SOR 变更，都会把这条链路打回原形。
这一篇，是我们做汽车控制器需求助手的起点。
第 1 章 行业痛点：5 个绕不开的"老毛病”
在把工具推出之前，我们花了几个月时间，走访 OEM 和 Tier 1，都有这个痛点。
每个团队的工作流都不一样，但痛点几乎是同一个模子刻出来的。我们把它归纳成 5 条：
痛点 ①：SOR 是"原材料"，但没人愿意结构化它
SOR 通常以 Word / PDF / Confluence 表格 / 甚至邮件正文的形式出现。有的客户一份 SOR 长达 80 页，其中混合着"功能描述"、“接口示意”、“法规条文”、“图片占位"四类内容。
工程师接到 SOR 后，第一件事就是人工把它拆成"结构化的需求条目”——这一步往往就要 2~3 天。拆完之后，还要再花一天核对，因为总会有漏看的边界场景。
更扎心的是，下次 SOR 改版，这些结构化工作全部推倒重来。
痛点 ②：软硬件派生，“复制粘贴 + 记忆"是常态
把系统需求（SysR）拆成硬件需求（HWR）和软件需求（SWR），是功能安全开发中最关键的派生动作。但几乎所有团队的做法都是：
系统工程师把 SysR 复制到 Excel → 硬件工程师对着 Excel 写 HWR → 软件工程师对着 HWR 写 SWR → 各自评审 → 各自归档。
这中间没有人做"跨层一致性”。3 个月后回过头看，软件工程师写的 SWR-04 和系统工程师原意差了一大截，谁也说不清到底哪一版是对的。
痛点 ③：一次变更，“雪崩式返工”
这是压死骆驼的最后一根稻草。
SOR 改一条 → SysR 改 5 条 → HWR 改 12 条 → SWR 改 20 条 → 测试用例改 30 条。**每一处都要评审签字、归档版本号。**工程师不是在"做新功能"，而是在"维护版本的真实性"。
痛点 ④：偏差对比，“人工 diff"是唯一手段
“上次和这次到底改了哪些 SysR？影响到了哪些 HWR/SWR？”
工程师的标准答案是：打开 Word 的修订模式，对照着看。
**两个工程师对着看一天，看到的结果可能还不一样。**漏判、错判是常态。更别说要拿这份"人工 diff 结果"去给评审专家解释"我们这次改动可控”——基本没有说服力。
痛点 ⑤：审查质疑，“你这条改动的依据呢？”
公告审查、第三方审计时，专家最常问的一句话是：
“你这条改动，依据是哪份 SOR 哪一页？什么时候改的？改了之后影响范围多大？”
绝大多数团队的答案是：翻邮件、翻聊天记录、翻同事记忆。
佐证链条不完整，是审查环节最痛的环节——不是规范写错了，而是说不清"为什么这么改"。
这 5 条痛点，单条都不致命，但叠加在一起，就是 3 个月才能跑完一条链路。下一篇，我们讲 需求助手是怎么把这条链路压成 3 小时的。
第 2 章 工具亮相：控制器需求管理助手
我们把工具叫汽车控制器需求助手——Engineering Process Simplifier，把需求工程的工序压缩、规范化、留痕化。
它做的事情只有三件：
结构化变轻SOR 进来直接拆成三层规范（SysR/HWR/SWR），不需要工程师一处处手抠；
派生可控系统变更点只 patch 受影响的 HWR/SWR 条目，不是全篇重生成；
追溯可证每一步改动都留底，从 SOR 哪一页来、改了什么、谁改的、影响范围多大。
适用对象很具体：
OEM / Tier 1 的系统工程师——不用再当人肉对齐器；
OEM / Tier 1 的功能安全工程师——审查前先自查一遍；
需求工程师——把重复劳动交给 AI，把判断留给自己；
第三方审计 / 公告审查——可以直接调取审计日志。
我们团队做这个工具，不是因为 AI 火起来就想上车。三位创始人在功能安全开发一线干了十多年，先后在 OEM、Tier 1、第三方咨询公司工作过。最痛的一刀不是"不会写规范"，而是"写了改、改了写、改完说不清为什么"。
第 3 章 六大核心能力（产品拆解）
3.1 智能需求提取：SOR 一键拆三层
接到 SOR 输入（Word / PDF / Markdown / 纯文本都行），系统工程师点一下按钮，工具会做两件事：
把自然语言描述拆成结构化条目（id / title / description / type / 来源页码）
自动派生 HWR 和 SWR 的初始骨架（每条 HWR/SWR 条目标注"源自 SysR-XX"）
工程师不需要逐条手写，只需要 review + 修改。
**实测下来：一份 80 页的 SOR，从上传到拿到三层规范初稿，平均 3-4 小时。**之前需要 3 周。
图 1 · 智能需求提取主界面：从上传到三层规范生成和管理
3.2 需求结构树：先画骨架，再让 AI 填肉
系统需求有 14 个标准章节（覆盖概述 / 术语 / 市场 / 环境 / 电气 / 功能 / 接口 / 通信 / 机械 / 法规 / 质量 / 生产等），硬件需求有 17 个模块，软件需求分 BSW + ASW。
工具把这套章节骨架做成结构树，工程师可以在提取需求之前先调整。
这等于让 AI"戴着镣铐跳舞"——AI 出的每条需求必须落在工程师指定的章节里，不会跑偏。
举个例子：SYS-6.2 是"功能定义"章，AI 不能把"功能安全目标"塞到这里，只能放到 SYS-11.2。
图 2 · 需求结构树编辑器：14 章 SysR 可调整
3.3 偏差分析：自动 diff + 影响范围
接 SOR 新版本时，工具会自动和上一版基线对比，输出三类变更：
added（新增）
modified（修改）
deleted（裁剪）
更进一步：分析这些变更影响到了下游哪些 HWR/SWR 条目，输出"影响范围清单"。
**审计专家看到这个清单，疑问就减少一半。**他们不需要再问"这次改动影响了多少条目"，工具直接给数字。
图 3 · 偏差分析：自动 diff + 下游影响范围
3.4 增量同步：只 patch 受影响条目
这是我们今年新上的功能，也是这次最想安利给老用户的。
传统做法：SOR 改了 → 全篇 HWR/SWR 重生成。后果是——3 个月的工作几乎白干。
增量同步的做法：
工具识别出"系统变更点"（通常 3-10 条）；
把"变更点 + 软硬件旧版"作为输入，让 AI 只产出 patch 列表（adds / updates / deletes）；
后端 merge 时保留所有 review / comments / editHistory / source。
效果：工程师只 review 受影响的 5-15 条，而不是重新 review 200 条。
我们一个客户用 3 个月后反馈：SOR 改版的返工时间从 5 天压到 0.5 天。
3.5 质量校验报告：severity 分级
工具内置 30 多条质量规则，覆盖四个维度：
完整性：章节缺失 / 条目必填字段缺失
一致性：跨层 reqId 是否对齐
可追溯性：孤立条目检测（哪条 SysR 没有下游对应）
规范性：描述是否包含主语/谓语/可测量条件
报告按 severity 分级（error / warning），按章节聚合。
审查前用这个报告自查一遍，能挡掉 80% 的"低级问题"被专家拎出来。
图 4 · 质量校验报告：错误 / 警告 / 通过率
3.6 评审工作台：批量通过、留痕可证
需求条目不是"工具生成完就完事"的——它要进评审、要被打回、要被改。
工具给每条需求加四个属性：
review状态（待审 / 通过 / 驳回）
comments（多人评论）
editHistory（谁改的、改了什么、为什么改）
source（源自哪条 SysR / SOR 哪一页）
评审专家可以批量通过/驳回，可以一键导出评审报告。
**所有动作都进审计日志。**审计专家打开日志能看到每条改动的全貌——这条 SysR 什么时候加的、改了几次、谁改的、被谁驳回过、最后为什么通过。
图 5 · 评审工作台：操作 + 历史 + 跨层追溯
3.7 需求追溯管理
这个不用多说，质量管理必备
图 6 · 需求追溯功能
3.8 下游集成
可以和各企业已有需求管理软件打通
图 7 · 平台兼容和集成
3.9 规范和报告导出
导出需求规范和变更指导报告
图 8 · 导出的规范和报告
第 4 章 工作流：六步走完整链路
一条标准的需求梳理链路，工具里走完只需要六步：
导入 SOR—— Word / PDF / Markdown / 纯文本都行；
调整结构树（可选）—— 让 AI 知道章节怎么分；
提取需求—— 一键产出 SysR + HWR + SWR 初稿；
工程师 review + 修改—— 工具生成后，工程师逐条过；
偏差分析—— 接 SOR 新版本时，识别"系统变更点"；
增量同步—— 仅 patch 受影响的 HWR/SWR 条目。
每一步都可以独立运行。工具不强迫你走完全部流程——你只想做偏差分析，行；只想做提取需求，也行。
导入 SORStep 1调整结构树Step 2 (可选)提取需求Step 3Review 修改Step 4偏差分析Step 5增量同步Step 6图 9 · 工具工作流：六步走完整链路
第 5 章 技术亮点
半形式化模板：每章连续编号，AI 提示词按层定制（SysR/HWR/SWR 各自独立 EClassId）；
跨层追溯链：相同 reqId 自动建 SysR → HWR → SWR 链；
增量同步不破坏历史：保留 review / comments / editHistory / source；
审计日志完整可追溯：每一步 AI 调用都留痕；
私有化部署可定制：客户可以替换 LLM、调整提示词、对接内部知识库。
第 6 章 效果对比
| 维度 | 传统做法 | EPS 工具 |
|---|---|---|
| 规范初稿编制 | 3-6 周 | 3-6 小时 |
| 一次变更波及面积 | 全篇重写 | 仅 patch 受影响条目 |
| 偏差识别 | 人工 diff 数小时 | 分钟级自动 |
| 整改建议沉淀 | 邮件 / 聊天记录 | 系统化知识库 |
| 审查佐证 | 临时拼凑 | 完整审计日志 |
一位 OEM 系统工程师用后的原话：
“以前每月一次的 SOR 改版都要熬一周夜，现在我和同事轮流 review 半天就过。”
第 7 章 适用场景
- 新车型立项初期规范编制
立项期 SOR 一稿版本不固定，工具能跟上频繁改版，让规范初稿不至于因为改 SOR 而推倒重来。
- 迭代版本变更管理
每次 SOR 改版，接入工具做"增量同步"即可，HWR/SWR 不需要全篇重做。
- 公告审查前自查
把规范和 SOR 一起丢进工具，导出质量校验报告 + 偏差分析报告，自查一遍再送审。
- 跨团队协同（OEM × Tier 1）
Tier 1 接 OEM 的 SOR 时，工具能直接输出 OEM 期望格式的 HWR/SWR 初稿，免去对齐格式的沟通成本。
第 8 章 写在最后
汽车控制器需求助手必将改变汽车电子电气开发的工作模式。
工具仍在快速迭代。下一个版本我们计划把我的安全分析工具打通 自动让安全分析的结论产生新的需求。
联系方式 · VX：DaoDao_Love2022