仪器脚本不是普通命令行工具#

很多脚本写坏了，最多就是生成一个错误文件。但仪器脚本不一样。它可能打开波形输出，可能给电路输入信号，可能让电源通道保持开启，也可能因为接线错误导致测量结果完全不可信。

所以 WaveForms 自动化适合先从三件事做起：

• 能不能找到 WaveForms 和 DWF SDK。
• 能不能识别设备连接。
• 在不输出硬件信号的情况下，能不能打印完整计划。

waveforms-lab-toolkit 里的 probe_waveforms.py 和采集脚本 dry-run 路径，正是在解决这个问题。它先让使用者知道当前环境是否成立，避免一上来就控制硬件。

dry-run 是实验安全的一部分#

README 里的使用顺序很明确：先运行环境探测，再干跑采集脚本，最后确认接线和幅度后显式加 --run。

这条路径看起来保守，但很适合模电实验。

1
probe -> dry-run -> confirm wiring -> --run -> capture -> analyze

模电放大器实验里，小信号幅度、通道接法、偏置状态都很敏感。如果脚本默认直接打开输出，就把“误操作成本”放大了。把 dry-run 做成默认设置，等于给每一次测量加了一个确认层。

这也会改变脚本的写法。一个好的采集脚本不能只负责执行动作，也要在执行前把计划打印清楚：

• 输出频率是多少。
• 幅度是多少。
• 采样率和采集时长是多少。
• 输出文件在哪里。
• 哪些硬件通道会被启用。
• 结束时会关闭哪些资源。

这些信息写进命令行输出，比事后猜测安全得多。

CSV 离线分析降低硬件依赖#

实验自动化还有一个常见问题：如果所有分析都必须连着仪器跑，调试会很慢。

WaveForms 可以导出 CSV，工具包里也有 analyze_waveform_csv.py 这类离线分析脚本。这个设计很实用。采集数据和分析数据分开以后，很多工作就不需要反复碰硬件：

• 调整峰峰值、均值、频率估计等计算方法。
• 重画报告图。
• 对比不同测量条件。
• 检查 CSV 格式兼容性。
• 在没有设备的机器上回看实验。

对学生实验尤其有帮助。实验室时间有限，硬件连接也容易受环境影响。把采集结果保存成普通数据文件，后续分析就能回到可重复的软件流程里。

工作区打包解决“我当时怎么看的”#

README 里提到 examples/experiment3_mos/ 里有 MOS 放大器采集、绘图和 WaveForms 工作区打包脚本，并且支持 live preset 和旧 CSV reference 两种模式。

这件事很细，但很值得记。

很多实验报告只保留最后图片，等到要复查时，很难知道当时 WaveForms 窗口里怎么配的、通道怎么显示的、哪些数据是现场采集、哪些是历史参考。

工作区打包的意义就是把“观看方式”也保存下来：

• live preset 用来快速配置 WaveForms 窗口。
• CSV reference 用来查看旧测量数据。
• 预览图和导入脚本帮助重建上下文。
• 默认不自动开启输出，避免打开工作区就影响硬件。

这比只保存一张截图更适合回看。截图是结果，工作区是观察环境。

输入/输出电阻测量要可计划#

仓库里提到共栅极输入电阻、输出电阻测量脚本，以及对应绘图脚本。它们有一个共同点：测量脚本默认只打印 dry-run 计划，只有显式 --run 才会启用电源、波形输出和示波器采集；绘图脚本只读取本地 CSV/JSON，不启用硬件。

这个分离很值得保留：

1
measurement script: touches hardware
2
plot script: reads files only

这样改图时就比较踏实：调坐标轴、改拟合方式、换配色，都只是在读本地文件，不会顺手把硬件输出打开。你在准备测量前，也能先看到脚本准备做什么。

实验脚本最怕“顺手运行一下”产生副作用。把硬件动作集中到少数命令，并要求显式开关，是很朴素但有效的工程纪律。

CI 只做它该做的事#

这个仓库有 GitHub Actions，运行 Python 语法检查。它不会在 CI 里真的连接仪器，也不该这么做。

实验自动化仓库的 CI 目标应该现实一点：

• 脚本能否被 Python 解析。
• 命令行参数是否能正常加载。
• 不依赖硬件的离线分析能否运行。
• 文档和示例路径是否还存在。

硬件联调留在本地或实验室机器上。CI 负责守住基础质量，不假装自己能验证所有真实测量。

这个范围对低资源服务器和静态博客也类似：能静态完成的事情就静态完成，别为了“看起来自动化”把运行成本搬到服务器上。

Codex skill 的意义是封装工作流#

仓库里还放了 waveforms-control skill。对这种工具来说，skill 不该鼓励 agent 直接乱控仪器，它更适合把安全流程固定下来。

如果我以后真拿这个 skill 跑实验，我希望它每次都先把这些事摆出来：

• 先探测环境。
• 默认 dry-run。
• 明确幅度、频率、采样率和通道。
• 需要硬件输出时必须显式确认命令参数。
• 结束后关闭输出、电源和设备句柄。
• 离线分析优先使用已有 CSV。

这和普通代码生成不同。仪器控制场景里，agent 第一件事应该是把会动硬件的步骤说清楚，再决定要不要执行。

对实验回看的启发#

这个工具包也提醒我，模拟实验报告不该只保留最后曲线。

更理想的实验材料应该包括：

• 原始 CSV。
• 分析脚本。
• 绘图脚本。
• 工作区或窗口配置。
• dry-run 计划。
• 最后报告图。
• 一段解释测量范围的说明。

这样下次回看时，能分清哪些是现场采集，哪些是离线处理，哪些只是显示配置。实验就从一次性截图变成了可回放流程。

先让脚本默认停住#

这次看下来，我最想保留的不是“一键采集”，而是脚本先停一下。先探测、先 dry-run、先把文件和通道说清楚，再决定要不要真的输出信号。模电实验里，这一点比多省几秒更重要。