夜雨聆风关于 AI4MBDSE AI+MBSE+测试 - 三个领域交叉的个人技术雷达。 从跨领域信号中找到真正值得关注的变化， 用「雷达扫描 -> 精读拆解 -> 方法沉淀」的多Agent协作流， 把技术洞察转化为可复用的工程方法和知识资产。 |
PPT构建组：有朋友说最近的PPT红色锚点有点多有点扎眼，可能跟skills里面的golden style有比较大的关系，这几天调教了红色的占比规则，替换了golden style里面的参考样例，成效如下
开场 今天看的是“证据链”
如果把 AI 放进测试、验证或 MBSE 工作流，最麻烦的往往不是“能不能生成结果”，而是结果出了问题以后，谁能说清楚它依据哪条规则、覆盖了哪个边界、留下了什么证据。
今天的几条信号刚好都在回应这个问题：安全测试要从策略约束里长出来，缺陷检测要能被人复核，模型验证要接得上硬件，需求追踪也不能只靠事后补链接。
01 主线判断
本期最值得看的不是某个单点算法，而是“规范、模型、代码、测试、验证证据”之间正在被重新接线。
这件事对 AI4MBDSE 的意义很直接：AI 不只是生成器，它要进入工程闭环，就必须成为可追踪工作流的一部分。
02 重点信号
信号 01｜从策略规范生成安全测试：它把安全/合规策略反向转成测试用例，适合沉淀为需求约束驱动测试方法。 英文标题：Inverting the Shield: Systematically Generating Safety Tests from Policy Specifications 分类：AI+测试｜AI Early Signal / AI + 测试 为什么选它：放回“需求或合规规则如何变成测试”的现场，这条信号解决的是测试来源问题：不是靠人不断补红队提示词，而是从策略规范里抽约束，再反向生成边界用例。 能用吗：适合做小样例验证。风险在于策略解释和测试结果仍需要人工复核，不能把生成出来的用例直接当成真实覆盖。 怎么用：选一条内部安全或合规规则，拆成 3 个约束、5 个反例测试和 1 张回归维护表。 原始链接：https://arxiv.org/abs/2605.24883v1 |
信号 02｜X-ray 缺陷检测 英文标题：Interpretable Computer Vision for Defect Detection in X-ray Tomography of Aerospace SiC/SiC Composites 分类：AI+测试｜MBSE + 测试 / 验证 为什么选它：上一条看的是“测试怎么来”，这一条看的是“AI 判断怎样被验收”。可解释原型层的价值，不在于替代专家，而在于让检测结果带着可复核证据进入验证流程。 能用吗：适合做验证证据链样例。边界是场景很垂直，航空复合材料 X-ray 不能直接泛化到所有工业检测。 怎么用：把一次 AI 检测拆成检测对象、模型输出、解释证据、验收判据四栏，形成一张可审核记录。 原始链接：https://arxiv.org/abs/2605.20159v1 |
信号 03｜SysML 直连硬件验证 英文标题：SHIA: A Direct SysML-Hardware Interface Architecture for Model-Centric Verification 分类：MBSE+测试｜工程方法 / 数字线程 为什么选它：如果模型只停在设计阶段，验证阶段就会变成脚本、仿真环境和人工记录各自说话。SHIA 的启发是让 SysML 模型继续约束硬件验证，而不是在交接点失效。 能用吗：适合学习架构思路，不适合直接照搬。落地取决于硬件接口、工具链集成和模型语义是否足够稳定。 怎么用：梳理一条“模型权威源 -> 硬件接口 -> 执行结果 -> 模型回写”的闭环，先画清楚断点。 原始链接：https://arxiv.org/abs/2605.11248v1 |
信号 04｜Agent 程序性记忆管理 英文标题：Managing Procedural Memory in LLM Agents: Control, Adaptation, and Evaluation 分类：AI/Agent｜AI Early Signal / Agent / Workflow / Knowledge 为什么选它：这条信号把视角从“上下文保存”推到“技能能否复用”。如果一个 Agent 每次都靠重新提示，它就不是真正的工程工作流，只是一次性助手。 能用吗：适合作为趋势卡观察。AFTER 基准偏通用办公任务，迁移到测试、需求分析或 MBSE，需要重新定义任务集。 怎么用：把一个重复任务写成技能单元：输入、步骤、工具、检查点、失败回退，各列 1 条。 原始链接：https://arxiv.org/abs/2606.23127v1 |
信号 05｜需求追踪嵌入代码结构 英文标题：ReqToCode: Embedding Requirements Traceability as a Structural Property of the Codebase 分类：MBSE+测试｜MBSE + 测试 / 验证 为什么选它：最后这条更像底层治理问题：需求、代码、测试如果靠外部文档维持关系，链路很容易静默断开。ReqToCode 的方向是把追踪变成代码库结构的一部分。 能用吗：适合学习方法，不建议一上来改造工程仓。它需要团队流程、代码组织和测试资产一起调整。 怎么用：拿一个小模块做试验：需求 ID、代码目录、测试用例、验证记录四者必须能互相定位。 原始链接：https://arxiv.org/abs/2603.13999v1 |
03 今日沉淀
今天可以把“证据链”作为共同主题：策略要能生成测试，检测要能解释，模型要能连到验证，需求追踪要能落进代码结构，Agent 技能要能被评测和复用。
真正值得沉淀的不是五篇论文摘要，而是一张方法表：规则从哪里来、测试怎么生成、证据如何复核、结果如何回写、下一次如何回归。
04 今日小动作
• 30 分钟内，只选“Inverting the Shield”做一张方法卡：输入是什么策略，输出是什么测试，人工复核看哪三项。
• 再用 10 分钟给这张方法卡加一个“证据字段”：每个测试结果必须留下规则来源、触发边界和复核结论。
日报精读PPT
AI4MBDSE 不追热点，只沉淀 AI 如何成为系统工程生产力。