SignalPass
SignalPass
登录注册

可追溯任务实录

执行与验证示例

以一个研发任务为线索,呈现执行状态维护、模型与工具调用、验证结果记录,以及代码、数据、日志、图表和报告如何汇入可复现成果包。

返回 SignalPass 首页查看研发任务快照查看电磁仿真案例

当前任务输入

SignalPass
>_完成毫米波阵列天线仿真优化,并交付可复现分析报告
01

任务边界已形成

目标、输入材料和交付要求完成确认。

02

模型与工具执行

分析脚本与仿真工具按计划运行。

03

验证检查通过

关键结果、图表和证据链完成检查。

04

成果包已就绪

代码、数据、日志、报告和证据链完成汇总。

01

研发任务快照

从任务目标到成果包,执行状态持续可见

研发任务快照

示例研发任务正在执行

执行可追踪

任务目标

READY

输入研发目标、数据、工具环境和约束。

执行计划

PLANNED

系统拆解任务并安排模型、代码和工具调用。

验证检查待确认

HIL REQUIRED

验证器发现结果、数据或结论存在不一致风险。

发现 2 个验证缺口,建议人工确认后继续执行

工具运行

RUNNING

调用仿真、分析脚本和外部工具完成计算。

成果包

PACKAGE READY

沉淀代码、数据、日志、图表、报告和证据链。

执行记录成果包

任务节点依次运行,验证证据持续流向最终成果包。

任务目标READY
执行计划PLANNED
验证检查待确认HIL REQUIRED
工具运行RUNNING
可复现成果包结构
code/
data/
logs/
figures/
report.md + evidence_chain.json
02

示例任务

以电磁仿真优化为例,看系统如何组织执行、验证与交付

用一个具体任务呈现输入、执行、验证与成果包交付。

任务输入

毫米波阵列天线仿真优化

目标是完成仿真参数分析、异常组合复查和结果报告交付;输入包括 CST 模型、S11 扫频数据、方向图指标和基线说明。

典型执行链路

01

形成执行计划

明确目标、输入数据、工具环境、验收条件和交付物。

02

调用仿真与分析工具

调度 CST、脚本和模型调用,记录参数、版本、输入输出和运行状态。

03

解析指标并发现异常

抽取 S11、方向图和关键性能指标,标记异常参数组合和缺失日志。

04

修复后形成成果包

补齐运行记录、复跑异常组合,并把新结果写入报告和证据链。

验证器检查什么

S11 曲线与原始扫频数据是否一致
方向图指标是否能追溯到对应仿真结果
图表、结论和运行日志是否互相对应
异常参数组合是否完成复跑或人工确认

最终成果包

code/
data/
logs/
figures/
evidence_chain.json

交付结果

最终结果不是一段解释,而是一套可审阅、可复跑、可交接的研发材料;团队可以继续检查、复现或二次开发。

03

完整流程

四个关键场景串起执行、验证与交付

输入研发目标、已有数据、工具环境和约束,系统先形成可执行任务边界。

研发目标

完成毫米波阵列天线仿真优化,并交付可复现分析报告

交付目标

代码 / 数据 / 图表 / 报告 / 证据链

仿真与分析任务
已有模型与扫频数据
硬约束清晰度 86
CST / HFSS 结果需可复现
对比基线:传统相位补偿方法
输入材料已关联
antenna-array-model.cst
s11-sweep.csv
baseline-notes.pdf

任务启动简报

任务边界已形成

目标:阵列仿真优化与结果分析
输入:模型、扫频数据、基线说明
下一步:生成执行计划并调度工具
04

交付材料

交付的不只是回答,而是可审阅的研发材料

一次交付包先定义执行计划,再保留运行日志,最终沉淀到可复现成果包目录。

执行计划

执行计划定义任务如何推进

已生成task/execution_plan.md

执行计划明确目标、输入、工具、验证条件和交付物,让后续运行有清晰路径和验收标准。

明确任务目标、输入数据、工具环境和限制条件
列出模型调用、脚本运行、仿真工具和验证节点

执行计划样例

01
任务边界

目标是完成天线阵列仿真优化与结果分析,输入包括模型、扫频数据和基线说明。

02
执行安排

系统将调度模型调用、分析脚本、CST / HFSS 仿真和验证器,并记录每一步输出。

03
验收口径

最终必须交付代码、数据、日志、图表、报告和证据链,缺一项都不能直接进入交付。

下一步:按计划进入工具执行

05

失败到修复

可信不是永远成功,而是失败可发现、可修复、可复现

真实研发任务会失败;关键是让失败可发现、修复可记录、结果可复现。

01验证失败

验证器发现问题

系统发现仿真结果、数据统计或报告结论不一致,当前输出不能直接进入交付。

02暂停执行

执行被暂停

系统停止进入下一阶段,保留失败上下文、输入输出、日志和影响范围。

03HIL 确认

人工确认修复方向

研究员确认需要补数据、换参数、重跑脚本或调整验证规则。

04重跑验证

系统重跑并记录版本

系统重新调用模型或工具,记录新旧版本、参数差异和验证结果。

05可复现

修复链进入成果包

最终交付不仅包含结果,也包含失败记录、修复过程、验证证据和可复现材料。

修复闭环

失败路径被记录下来,成果才值得交付

可靠的研发自动化不应假装流程永远顺利,而要能发现问题、暂停执行、重跑验证,并把证据链写入交付物。

2 个验证缺口被标记
1 次暂停执行与 HIL 确认
修复版本进入最终成果包