电源测试开发一体化套件

解决什么问题

电源测试上位机的难点很少集中在“画一个界面”上，更多分散在几个容易翻车的层面：

• 协议面宽：一台测试机往往同时面对 VISA / 串口 / CAN / I²C / 485 / PLC / Modbus，传输层、协议层、异步模式各不相同，写错一帧的代价是整条测试线停摆。
• 命令集庞大且语义模糊：设备手册动辄数百页 PDF，*IDN?、MEAS:VOLT? 这类命令的写/查询语义、pre_ 前置依赖很容易靠记忆脑补。
• 通信与 UI 打架：VISA 查询阻塞主线程、停止标志写进被复用函数导致“启动即停”，都是上位机最常见的回归。
• 无法离线开发：没有真机就写不下去，改一行要等设备到场才能验证。

它是怎么工作的

技能包不依赖其他技能包，内部按领域拆成 references/ 下的模块，按需渐进加载，而不是一次性全读。

• 功能开发总流程走 references/workflow/，按需求→架构→通信→异步→数据→日志→解耦→测试→规范九阶段编排。
• 定位与交接走 references/codebase/，只读项目私有的 module_index.md / handover.md，最省 token。
• 设备手册、SCPI 命令、源/负载/功率/CT 领域常识分别在 references/manual/ 与 references/domain/；手册检索 SOP 明确“防模糊识别红线”——不确定的命令语义不允许猜测。
• 通信、数据配置、日志加密、UI 生成、测试模拟、代码审查各有主责模块；跨领域问题（如“UI + 通信”）由主责模块主导，协同模块只做契约交叉。

自动化工具链让骨架一步到位：scripts/workflow/scaffold.py 生成可直接运行的五层架构项目，内含缺键防护控制器、pre_ 前置命令、Stub 模拟、Hex 双轨日志、冒烟测试与配置热加载；scripts/devices/generate_device_registry.py 支持 --cmd "键:模板" 生成设备注册表条目并做语义校验；scripts/quality/check_command_semantics.py 复查 read_ 必须查询、pre_ 必须写且有主键、字节级重复表。

新增一台设备的标准闭环：生成条目 → 追加 registry → 语义复查 → mode=sim 用 Stub 跑通全流程 → 冒烟测试 → 联机核对。全程自动推进，只在需真机验证、方案分叉需决策、触发成本护栏时停下询问。

适用边界与注意点

• token 不是无限的：任务先分级（小任务只加载 1 个模块，大任务九阶段逐步汇报）；重试编译/lint/打包最多 3 次，同一问题 2 次无进展即止损上报。
• 工业红线是硬约束：UI 线程禁网、UI 与业务分层、配置值禁止硬编码、写命令（无 ?）走 write 而非 query、句柄用上下文管理器并断开后置 None、停止标志不得放进被启动流程复用的函数。
• 它不替代真机验证：模拟驱动只保证流程与契约正确，精度、时序、抗干扰仍需联机核对。
• 项目私有数据不入包：module_index.md、handover.md、config 随项目生成，技能包提供的是方法论与模板，不是某个具体项目的代码。