268 lines
11 KiB
Markdown
268 lines
11 KiB
Markdown
# AxiOmron.PcbCheck 汇报文案
|
||
|
||
> 主题：3 个月，我从写 if-else 到 Vibe Coding<br>
|
||
> 项目：AxiOmron.PcbCheck / PCB 目检放行上位机<br>
|
||
> 建议时长：10 分钟<br>
|
||
> 使用方式：本文件按网页汇报的 9 个页面整理；“屏显文案”用于页面内容，“讲述提示”用于口头汇报。
|
||
|
||
---
|
||
|
||
## 01. 封面｜3 个月，我从写 if-else 到 Vibe Coding
|
||
|
||
### 屏显文案
|
||
|
||
**3 个月，**<br>
|
||
**我从写 if-else**<br>
|
||
**到 Vibe Coding**
|
||
|
||
用 AI 协作搭建一套 PCB 目检放行上位机：把 PLC、双扫码、文件校验、安灯和追溯记录，收束为一条可解释的现场闭环。
|
||
|
||
- 产品形态：WPF 工业上位机
|
||
- 架构基座：.NET 8 / MVVM
|
||
- 核心结果：可追溯放行闭环
|
||
|
||
### 讲述提示
|
||
|
||
三个月前，我遇到类似需求时，第一反应通常是继续加 if-else：扫码成功怎么办、文件找不到怎么办、PLC 超时又怎么办。现在我更关注如何先把现场规则拆成状态、契约和异常边界，再借助 AI 快速实现与验证。
|
||
|
||
今天分享的不是一个单独页面，而是我如何用 AI 协作，逐步搭建一套 PCB 目检放行上位机。
|
||
|
||
---
|
||
|
||
## 02. 起点｜让一块 PCB 安全地被放行
|
||
|
||
### 屏显文案
|
||
|
||
**不是做一个界面，**<br>
|
||
**而是让一块 PCB 安全地被放行。**
|
||
|
||
> “扫码成功、文件存在、PLC 收到信号——这些局部成功，如何组成一个真正可追溯的业务成功？”
|
||
|
||
| 关联对象 | 需要解决的问题 |
|
||
| --- | --- |
|
||
| PLC | PCB 到位触发、忙碌、结果码、放行与复位，都需要明确握手语义。 |
|
||
| 双扫码枪 | 两路 TCP 返回可能成功、失败或不一致，不能靠单一分支草率处理。 |
|
||
| 文件校验 | 根据条码查找产品 ID 文件；找不到、重试耗尽和连接异常是不同结果。 |
|
||
| 现场追溯 | 异常要能报警、记录、回看；工程师需要看到过程，而不仅是最终 OK / NG。 |
|
||
|
||
### 讲述提示
|
||
|
||
这个项目的难点不在于“连上设备”，而在于这些设备的局部结果如何组成一个可靠的业务结论。
|
||
|
||
例如，扫码成功不代表可以放行；PLC 写成功也不代表产线已经完成放行；文件删除更不能发生在错误的时机。我要解决的是一条完整的现场闭环。
|
||
|
||
---
|
||
|
||
## 03. 架构｜先搭骨架，再接设备
|
||
|
||
### 屏显文案
|
||
|
||
**把易变的设备放在边缘，**<br>
|
||
**把稳定的业务流程留在中心。**
|
||
|
||
核心：`WorkflowHostedService`
|
||
|
||
后台状态机负责单板生命周期；WPF 只订阅运行态，不阻塞 UI。
|
||
|
||
| 分类 | 组件 | 职责 |
|
||
| --- | --- | --- |
|
||
| 触发 | Omron PLC | 到位、复位、结果码、放行应答 |
|
||
| 输入 | 双 TCP 扫码枪 | 并发触发、结果汇总与不一致处理 |
|
||
| 校验 | SFTP / 本地文件 | 按条码检索、重试、路径安全边界 |
|
||
| 可观察性 | 安灯、CSV、日志 | 异常通知、结果追溯、监控与设置 |
|
||
|
||
架构原则：
|
||
|
||
- 接口隔离设备实现
|
||
- 后台处理耗时 I/O
|
||
- 配置不写死在流程里
|
||
- UI 只展示状态
|
||
|
||
### 讲述提示
|
||
|
||
我的第一步不是先做漂亮界面，而是把每一类设备抽象成接口。这样 PLC、扫码枪、文件查找和安灯都能被替换为模拟实现，流程服务只关心业务规则。
|
||
|
||
这一层架构也让 AI 能更好地协作：我可以让它先沿接口和实现追踪调用链，再只改动目标边界，而不是在 UI 或设备代码里直接塞逻辑。
|
||
|
||
---
|
||
|
||
## 04. 核心流程｜从 if-else 到状态机
|
||
|
||
### 屏显文案
|
||
|
||
**代码不再问“下一个 if 是什么”，**<br>
|
||
**而是问“当前 PCB 处于什么状态”。**
|
||
|
||
1. **到位触发**：忽略重复上升沿，防止同一块板流程重入。
|
||
2. **扫码与校验**：汇总双扫码，再根据条码检索产品 ID 文件。
|
||
3. **结果与放行**：写入结果码，发出放行脉冲，等待 PLC 业务应答。
|
||
4. **完成与追溯**：清状态、记录 CSV、刷新界面，等待下一块板。
|
||
|
||
关键规则：
|
||
|
||
- 扫码失败：安灯 + NG 放行
|
||
- 文件不存在：重试耗尽后 NG 放行
|
||
- 系统异常：故障锁存，不自动放行
|
||
- 收到 PLC 应答后，才执行可选清理
|
||
|
||
### 讲述提示
|
||
|
||
这就是我从 if-else 思维切换到状态机思维的关键点。每一种异常都不是额外补一段判断，而是状态机中明确的一条路径。
|
||
|
||
这样做的好处是，任何一个现场问题都可以回到三个问题：当前状态是什么？允许的下一步是什么？失败后应该如何恢复或锁存？
|
||
|
||
---
|
||
|
||
## 05. 搭建过程｜从方案到可运行系统
|
||
|
||
### 屏显文案
|
||
|
||
**从方案到测试，**<br>
|
||
**每一层都先解决一个真实问题。**
|
||
|
||
| 时间 | 阶段 | 内容 |
|
||
| --- | --- | --- |
|
||
| 04·16 | 先把现场语言画出来 | 梳理通信角色、PLC 点位、结果码、异常策略和状态机，不急着进入代码。 |
|
||
| 04·17 | 初始化 WPF 工程 | 建立 MVVM、Host/DI、日志与配置，让界面与业务流程先有干净的边界。 |
|
||
| 04·19 | 补齐可运维能力 | 管理员解锁、SFTP 探活、扫码启动探活、CSV 结果记录相继落地。 |
|
||
| 05·17 | 重构主放行流程 | 接入双扫码判定，把扫码、查文件、告警、放行统一为单板工作流。 |
|
||
| 06·10 | 把联调变得可观察 | 补齐 TCP 扫码连接测试与日志，让通信问题可以被定位，而不是被猜测。 |
|
||
|
||
### 讲述提示
|
||
|
||
这个项目不是一次性把所有功能堆出来，而是按风险逐层搭建：先确定规则，再建立骨架，然后补齐运维能力，最后持续让通信和异常更可观察。
|
||
|
||
AI 在这里的作用，是加快每一个小闭环的实现和验证，而不是跳过业务设计。
|
||
|
||
---
|
||
|
||
## 06. 场景演示｜一块 PCB 从到位到放行
|
||
|
||
### 屏显文案
|
||
|
||
**用一个可控的模拟流程，演示“从到位到放行”。**
|
||
|
||
流程：
|
||
|
||
1. PLC 检测到 PCB 到位
|
||
2. 双扫码枪返回条码
|
||
3. 产品 ID 文件校验
|
||
4. 写结果并等待放行应答
|
||
5. 写入追溯记录，回到空闲
|
||
|
||
关键判断：
|
||
|
||
> “PLC 写入成功”不代表产线已确认放行。只有收到 PLC 应答，才能进入后续清理和完成记录。
|
||
|
||
补充规则：
|
||
|
||
- 双扫码任一成功即可继续；两者不一致时保留诊断信息。
|
||
- 文件未找到会受控重试；通信或认证异常进入系统故障，而非误放行。
|
||
- 放行脉冲有时长与应答超时；清理动作默认关闭，避免误删现场依据。
|
||
|
||
### 现场演示动作
|
||
|
||
1. 点击网页上的“播放模拟流程”。
|
||
2. 随着每一步高亮，口头说明它对应的现场动作。
|
||
3. 在第 4 步强调：此时不是“写了放行位就结束”，而是等待 PLC 给出业务应答。
|
||
4. 到第 5 步说明：完成记录和文件清理都依赖这一确认条件。
|
||
|
||
### 讲述提示
|
||
|
||
我不会在汇报现场连接真实 PLC 或 SFTP，而是用模拟器展示主流程。这种方式既能稳定演示完整业务链路，也能清楚地区分“本地逻辑验证”与“真实现场验收”。
|
||
|
||
---
|
||
|
||
## 07. AI 编程案例｜先问清楚何时可以删
|
||
|
||
### 屏显文案
|
||
|
||
**AI 的价值不是直接补一行 `Delete(file)`，**<br>
|
||
**而是先问清楚“何时可以删”。**
|
||
|
||
需求：配置可选启用；收到 PLC 放行应答后，删除本轮读取到的产品 ID 文件。
|
||
|
||
AI 协作过程：
|
||
|
||
1. 追踪 `扫码 → 文件匹配 → ReleasePermit → PlcAckRelease` 的调用链。
|
||
2. 明确 FINS 写入成功，只证明协议操作成功；不能等同于 PLC 完成业务应答。
|
||
3. 保存精确命中路径；等待应答；先清放行脉冲；再由本地或 SFTP Provider 负责安全删除。
|
||
4. 验证：应答成功删除；应答超时不删；越界路径拒绝；删除失败不回滚已确认放行。
|
||
|
||
AI 的三个贡献：
|
||
|
||
- **读懂陌生系统**：快速在配置、接口、后台服务、设备实现和测试之间建立调用链。
|
||
- **把自然语言变成契约**：把“放行后删除”翻译成前置条件、超时行为、默认开关和失败后果。
|
||
- **让异常可验证**：用 Fake PLC / Fake 文件服务覆盖关键分支，让现场风险先在可控环境暴露。
|
||
|
||
### 讲述提示
|
||
|
||
这个案例最能说明我对 AI 的使用方式发生了变化。以前我可能直接让 AI 写删除文件的代码；现在我会先要求它追踪整条流程，再一起确认动作的前置条件与失败边界。
|
||
|
||
AI 帮我缩短了理解陌生系统和实现测试的时间，但业务责任仍然在我这里：什么时候删、删谁、失败后如何处理，必须由我结合现场规则确认。
|
||
|
||
---
|
||
|
||
## 08. 学习路径｜从看懂到解决
|
||
|
||
### 屏显文案
|
||
|
||
**学习不是囤教程，**<br>
|
||
**而是不断缩短“看懂”到“解决”的距离。**
|
||
|
||
1. **看 5 个视频**：只抓住 WPF、依赖注入、后台服务、设备通信的基础概念。
|
||
2. **拆 1 个项目**：沿着一块 PCB 的生命周期，理解配置、状态、接口和日志为何存在。
|
||
3. **自己搭一个**：从界面骨架到 PLC、扫码、文件校验，持续用 AI 做代码阅读和小步实现。
|
||
4. **解决真实问题**：把“PLC 应答后再删文件”落成可配置、可测试、可追溯的工程规则。
|
||
|
||
关键转变：
|
||
|
||
> 从“让 AI 帮我生成代码”，升级为“我能给 AI 足够明确的业务上下文，并验证它给出的工程边界”。
|
||
|
||
### 讲述提示
|
||
|
||
我并不是等到学会所有技术才开始做项目，而是在真实问题里逐步学习。视频帮助我建立术语，拆项目帮助我理解结构，自己实现帮助我建立手感，真实问题则迫使我理解生产边界。
|
||
|
||
---
|
||
|
||
## 09. 总结｜从代码到工程交付
|
||
|
||
### 屏显文案
|
||
|
||
**从 if-else 到 Vibe Coding，**<br>
|
||
**改变的不是“谁来写代码”。**
|
||
|
||
而是我开始能把一个模糊的现场需求，拆成：
|
||
|
||
- 设备契约
|
||
- 状态机
|
||
- 异常边界
|
||
- 可验证的交付
|
||
|
||
| 边界 | 内容 |
|
||
| --- | --- |
|
||
| 已在本地覆盖 | 项目定向构建与工作流、文件相关测试可验证逻辑分支、接口隔离和异常行为。 |
|
||
| 仍需现场确认 | 真实 PLC 点位、SFTP 根目录与删除权限，必须在产线按实际设备与权限完成联调。 |
|
||
|
||
最后三点：
|
||
|
||
1. **技术深度**：不是“调用了多少 SDK”，而是能否说清状态、超时、失败与恢复。
|
||
2. **学习能力**：不是“看了多少教程”，而是能否把陌生系统拆成可验证的问题。
|
||
3. **业务结合**：不是“做了一个界面”，而是让现场每一次放行都可解释、可追溯。
|
||
|
||
### 收尾讲述
|
||
|
||
AI 让开发速度更快，但它没有替代工程判断。真正的成长，是我开始能定义问题、判断边界、验证结果，并把一个模糊需求交付成可靠的现场流程。
|
||
|
||
谢谢。
|
||
|
||
---
|
||
|
||
## 汇报现场速记
|
||
|
||
- 用方向键或右下角“上一页 / 下一页”控制网页汇报。
|
||
- 第 6 页点击“播放模拟流程”，演示完整闭环。
|
||
- 不演示真实 PLC、真实 SFTP 或真实删除动作。
|
||
- 不展示具体现场 IP、账号、密码、完整生产路径或未确认的 PLC 点位。
|
||
- 被问到“是否现场验证”时，回答：本地逻辑与定向测试可验证；真实设备和权限仍需现场联调验收。
|