【AI 辅助编程做设备数据采集：一个真实项目的迭代复盘（OpenSpec 驱动）】

AI 辅助编程做设备数据采集：一个真实项目的迭代复盘（OpenSpec 驱动）

一、项目背景：不是"写个脚本"，而是长期运行的工业采集系统

这个项目是一个 WinForms + .NET Framework 的设备数据采集程序，核心目标是：

通过 Modbus RTU/TCP 和厂商私有协议，采集多种设备数据，落库、上报 ELN，并支持现场可视化运维。

从 openspec 迭代轨迹看，项目经历了典型的工程化路径：

• infra-foundation：配置系统、通讯工具、日志、采集循环基础设施
• winforms-gui：从控制台走向现场可用 UI（设备配置、状态、日志）
• air-rtu-collection / tear-strength-rf3259h / leather-shrinkage-tcp / uv-device-rtu-collection：按设备分能力接入
• local-sqlite-device-upload：本地 SQLite 持久化 + 通用查询预览
• optimize-project-performance：围绕 Task.Run、HttpClient、UI 刷新的性能治理

我的体感：AI 在这个项目里最有价值的，不是"帮我写代码"，而是"帮我持续做对的工程决策"。

二、为什么 OpenSpec + AI 组合有效

我们不是直接让 AI 改代码，而是先走：

proposal -> design -> specs -> tasks -> apply

这个流程对设备采集类项目非常关键，因为它天然有三类高风险：

1. 协议风险（寄存器、字节序、功能码）
2. 并发风险（采集线程、UI 线程、异步上传）
3. 现场风险（运行稳定性、可回滚、日志可追溯）

OpenSpec 把"需求、决策、约束、任务"都显式化，AI 再按这个结构落地，能显著减少"改着改着偏题"。

三、几个真实案例（来自迭代过程）

1）协议接入阶段：先固化能力边界，再写代码

在 infra-foundation 和设备能力迭代里，AI 先把能力拆成独立 spec（如 modbus-rtu-tool、http-upload、collection-loop），再实现。

收益是：后续新增设备时，复用路径清晰，不会每次"推倒重写"。

我的感悟：
设备项目最怕"隐式约定"。先写 spec，比先写代码更省时间。

2）本地落库与查询：从"能传"升级到"可追溯"

local-sqlite-device-upload 这轮很典型：

不是只关心接口成功，而是强调：

• 统一落库模型
• ORDNO 作为主检索键
• 预览 UI 与设备类型策略解耦
• 数据保留策略（默认 30 天）

这类需求，如果只靠口头沟通很容易遗漏。AI + OpenSpec 的好处是"每条约束都有位置可落"。

我的感悟：
工业采集系统的第一原则不是上传成功，而是可追溯可排错。

3）性能优化：把"感觉卡"变成"可验证任务"

optimize-project-performance 里，AI 给出的结构很实用：

• 明确非目标（不改协议、不牺牲完整性）
• 决策对比（为什么不用每次 new HttpClient）
• 风险与缓解（DNS、队列延迟、UI 防抖）
• 可执行任务拆分（2 小时内可完成粒度）

我的感悟：
性能优化最怕一句"优化一下"。要把它拆成可验证行为。

四、AI 在这个项目里最实用的 5 个习惯

1. 先定义不做什么（Non-goals）

   避免 AI 过度发挥。

2. 每次改动先锁定影响面

   尤其 Program.cs、MainForm.cs、HttpTool.cs、DeviceUploadLocalStore.cs 这种核心路径。

3. 协议字段改动必须走"读取-解析-日志-落库-上传"全链路检查

   只改一行寄存器索引是高危操作。

4. 线程相关改动默认先怀疑 UI 跨线程访问

   回调里先 InvokeRequired 再碰控件，这是硬规则。

5. 保留现场可诊断日志

   AI 可以帮你生成代码，但现场问题只能靠日志还原。

五、这轮 AI 协作最大的收获

这次最有价值的沉淀不是某个函数，而是三件事：

• 需求沉淀：从口头需求变成可审计 spec
• 决策沉淀：为什么这么做，而不是只看改了什么
• 团队沉淀：新同事接手时，能看懂系统如何演进到现在

一句话总结：
AI 让写代码更快，OpenSpec 让项目不乱跑。两者结合，才适合真实工业项目。

六、给同类项目的建议（可直接照搬）

• 小步快跑：一个 capability 一个变更，不要大包大揽
• 强约束输入：给 AI 明确协议、线程、日志、回滚边界
• 保持 artifact 完整：proposal/design/specs/tasks 不要跳步
• 用可验证条目收尾：每个任务都能明确 Done/Not Done

结语

设备采集类项目对"稳定性、可追溯、可维护"要求很高。

这类项目里，AI 不是替代工程师，而是把工程师从重复劳动里解放出来，去做更关键的架构与决策。

如果你也在做类似 WinForms + Modbus + ELN 的系统，建议是：
先建立 OpenSpec 迭代习惯，再谈 AI 提效，效果会非常明显。