diff --git a/docs/AxiOmron_PCBCheck_完整汇报稿.md b/docs/AxiOmron_PCBCheck_完整汇报稿.md new file mode 100644 index 0000000..43f805d --- /dev/null +++ b/docs/AxiOmron_PCBCheck_完整汇报稿.md @@ -0,0 +1,141 @@ +# 《3 个月,我从写 if-else 到 Vibe Coding》汇报稿 + +> 建议时长:8~10 分钟
+> 面向听众:以非开发人员为主
+> 核心目标:让听众听懂 Vibe Coding 是什么、上手难不难、怎样调试、有哪些风险。 + +--- + +## 一、起点:Vibe Coding 到底是什么(约 1 分钟) + +大家好,我今天汇报的主题是:**《3 个月,我从写 if-else 到 Vibe Coding》**。 + +先解释一下什么是 Vibe Coding。 + +过去写程序,我需要自己把需求翻译成一行一行的代码。现在,我可以先用自然语言告诉 AI:我要做什么、程序应该怎样运行、出现异常时怎么办。AI 帮我阅读项目、生成代码、运行测试,我再检查结果、继续调整。 + +它有点像和一名速度很快的程序员结对工作。以前我主要负责“写代码”,现在我更多负责“把问题讲清楚”和“判断结果对不对”。 + +这三个月,我用这种方式完成了一个 PCB 目检放行上位机。它会接收产线信号、读取条码、检查产品文件,然后决定 PCB 是否放行,并保存过程记录。 + +--- + +## 二、我用 AI 做了什么(约 4 分钟) + +### 1. 先让 AI 理解业务 + +这个项目不是简单做一个界面。它要同时和 PLC、两把扫码枪、文件服务器以及报警系统通信。 + +一块 PCB 到位后,程序需要完成五步: + +1. 接收 PLC 的到位信号。 +2. 触发两把扫码枪读取条码。 +3. 根据条码检查产品文件。 +4. 把检查结果发给 PLC,并等待 PLC 确认。 +5. 保存记录,等待下一块 PCB。 + +我没有对 AI 说“帮我写个上位机”就结束,而是先让它把这五步画成流程,列出每一步的成功、失败和超时情况,再逐步实现。 + +这也是 Vibe Coding 的第一个注意点:**需求越模糊,AI 写得越快,返工也可能越快。** + +### 2. 从小功能逐步搭起来 + +我先让 AI 搭出可以运行的界面,然后逐个接入扫码、文件检查、PLC 通信和运行记录。每完成一小步,就先运行和验证,再继续下一步。 + +对有代码基础的人来说,Vibe Coding 的入门难度并不高。会安装开发工具、会运行项目、能看懂基本报错,通常很快就能开始。 + +但“能生成代码”和“能交付程序”不是同一件事: + +- 入门很容易:会用自然语言描述需求,就能做出一个原型。 +- 做到可用,需要知道怎样拆分任务、补充上下文和检查结果。 +- 做到可靠,仍然需要业务知识、调试能力和风险判断。 + +所以它降低的是写代码的门槛,没有消除软件工程本身的难度。 + +### 3. 一次真实的调试过程 + +项目中有一个需求:PCB 放行以后,删除本次使用过的产品文件。 + +程序日志显示“放行信号写入成功”,但文件没有删除。最直接的想法,是让 AI 把删除代码放到“写入成功”后面。 + +但我没有直接这样改,而是让 AI 做三件事: + +1. 根据日志找到放行信号在哪里写入。 +2. 沿着程序流程查找 PLC 确认信号在哪里读取。 +3. 分别模拟“收到确认”和“确认超时”两种情况。 + +最后发现,写入成功只代表上位机把消息发出去了,不代表 PLC 已经完成放行。就像邮件显示发送成功,不代表对方已经阅读并执行。 + +因此正确逻辑是:只有收到 PLC 的确认,才允许删除文件;如果等待超时,文件必须保留。同时,这个删除功能默认关闭,避免现场配置错误造成误删。 + +这个 Bug 最后不是靠猜某一行代码解决的,而是通过**看日志、追流程、做对比测试**定位的。 + +--- + +## 三、用 AI 怎样调试程序(约 2 分钟) + +很多人担心:代码是 AI 写的,出问题以后怎么办? + +我现在使用一套比较简单的调试方法,可以概括为五步。 + +### 第一步:先复现 + +先确认在什么操作下必然出现问题。不要只告诉 AI“程序坏了”,要告诉它“我做了什么、期望看到什么、实际发生了什么”。 + +### 第二步:给证据 + +把错误提示、运行日志、相关配置和最近修改交给 AI。证据越完整,AI 越不容易靠猜。 + +### 第三步:让 AI 解释流程 + +不要一上来就说“直接修复”。先让 AI 回答:这个功能从哪里开始,经过哪些步骤,失败发生在哪一步。确认它理解正确以后再修改。 + +### 第四步:一次只改一个问题 + +修改范围越大,越难判断到底是哪一处起作用。先做最小修改,再重新运行。 + +### 第五步:同时验证成功和失败 + +程序正常运行只是一个场景。还要验证超时、断网、输入错误等情况,确保程序不会在异常时做出危险动作。 + +我常用的一句话是: + +> “先不要改代码。请根据日志找到调用流程,说明最可能的三个原因,以及如何逐个验证。” + +这句话通常比“帮我修一下”更有效。 + +--- + +## 四、学习路径和注意点(约 2 分钟) + +我的学习方式是四步:看一点、拆一个、搭起来、解决真实问题。 + +我先通过视频了解 AI 编程工具的基本用法,再找一个项目观察它的结构,然后自己搭一个小项目。真正提升最大的阶段,是拿它解决一个真实问题,因为真实问题会遇到设备、网络、超时和错误数据,而不是只有演示里的成功路径。 + +最后,我总结了四个注意点: + +1. **不要一次提出过大的需求。** 把任务拆小,每一步都能运行和检查。 +2. **不要盲目接受 AI 的修改。** 至少要看改了哪些文件、为什么这样改。 +3. **不要把本地运行成功当成现场验证。** 模拟测试不能代替真实设备和真实网络。 +4. **删除、付款、放行等高风险动作要默认关闭。** 必须有明确条件和人工可控的开关。 + +所以,我对 Vibe Coding 的结论是:**上手并不难,做出原型很快;真正的能力,是会描述、会验证、会调试,也知道什么时候不能完全相信 AI。** + +AI 没有让我不再需要技术,而是让我可以把更多时间放在理解问题和验证结果上。 + +我的汇报结束,谢谢大家。 + +--- + +## 现场演示建议 + +演示只保留两个动作,控制在 2 分钟内: + +1. 播放 PCB 从到位、扫码、文件检查到放行的模拟流程。 +2. 展示两种调试结果:收到 PLC 确认时允许删除;确认超时时文件保留。 + +演示时不需要展示大段代码,只需要展示日志或测试结果,并用“邮件发送成功不等于对方已经执行”的比喻解释问题。 + +如果现场演示失败,可以直接说: + +> “这也是调试的一部分。现在我会先保留现场状态和日志,而不是连续修改代码。演示环境没有连接真实设备,下面展示我提前准备的测试结果。” diff --git a/docs/AxiOmron_PCBCheck_汇报文案.md b/docs/AxiOmron_PCBCheck_汇报文案.md new file mode 100644 index 0000000..602234e --- /dev/null +++ b/docs/AxiOmron_PCBCheck_汇报文案.md @@ -0,0 +1,267 @@ +# AxiOmron.PcbCheck 汇报文案 + +> 主题:3 个月,我从写 if-else 到 Vibe Coding
+> 项目:AxiOmron.PcbCheck / PCB 目检放行上位机
+> 建议时长:10 分钟
+> 使用方式:本文件按网页汇报的 9 个页面整理;“屏显文案”用于页面内容,“讲述提示”用于口头汇报。 + +--- + +## 01. 封面|3 个月,我从写 if-else 到 Vibe Coding + +### 屏显文案 + +**3 个月,**
+**我从写 if-else**
+**到 Vibe Coding** + +用 AI 协作搭建一套 PCB 目检放行上位机:把 PLC、双扫码、文件校验、安灯和追溯记录,收束为一条可解释的现场闭环。 + +- 产品形态:WPF 工业上位机 +- 架构基座:.NET 8 / MVVM +- 核心结果:可追溯放行闭环 + +### 讲述提示 + +三个月前,我遇到类似需求时,第一反应通常是继续加 if-else:扫码成功怎么办、文件找不到怎么办、PLC 超时又怎么办。现在我更关注如何先把现场规则拆成状态、契约和异常边界,再借助 AI 快速实现与验证。 + +今天分享的不是一个单独页面,而是我如何用 AI 协作,逐步搭建一套 PCB 目检放行上位机。 + +--- + +## 02. 起点|让一块 PCB 安全地被放行 + +### 屏显文案 + +**不是做一个界面,**
+**而是让一块 PCB 安全地被放行。** + +> “扫码成功、文件存在、PLC 收到信号——这些局部成功,如何组成一个真正可追溯的业务成功?” + +| 关联对象 | 需要解决的问题 | +| --- | --- | +| PLC | PCB 到位触发、忙碌、结果码、放行与复位,都需要明确握手语义。 | +| 双扫码枪 | 两路 TCP 返回可能成功、失败或不一致,不能靠单一分支草率处理。 | +| 文件校验 | 根据条码查找产品 ID 文件;找不到、重试耗尽和连接异常是不同结果。 | +| 现场追溯 | 异常要能报警、记录、回看;工程师需要看到过程,而不仅是最终 OK / NG。 | + +### 讲述提示 + +这个项目的难点不在于“连上设备”,而在于这些设备的局部结果如何组成一个可靠的业务结论。 + +例如,扫码成功不代表可以放行;PLC 写成功也不代表产线已经完成放行;文件删除更不能发生在错误的时机。我要解决的是一条完整的现场闭环。 + +--- + +## 03. 架构|先搭骨架,再接设备 + +### 屏显文案 + +**把易变的设备放在边缘,**
+**把稳定的业务流程留在中心。** + +核心:`WorkflowHostedService` + +后台状态机负责单板生命周期;WPF 只订阅运行态,不阻塞 UI。 + +| 分类 | 组件 | 职责 | +| --- | --- | --- | +| 触发 | Omron PLC | 到位、复位、结果码、放行应答 | +| 输入 | 双 TCP 扫码枪 | 并发触发、结果汇总与不一致处理 | +| 校验 | SFTP / 本地文件 | 按条码检索、重试、路径安全边界 | +| 可观察性 | 安灯、CSV、日志 | 异常通知、结果追溯、监控与设置 | + +架构原则: + +- 接口隔离设备实现 +- 后台处理耗时 I/O +- 配置不写死在流程里 +- UI 只展示状态 + +### 讲述提示 + +我的第一步不是先做漂亮界面,而是把每一类设备抽象成接口。这样 PLC、扫码枪、文件查找和安灯都能被替换为模拟实现,流程服务只关心业务规则。 + +这一层架构也让 AI 能更好地协作:我可以让它先沿接口和实现追踪调用链,再只改动目标边界,而不是在 UI 或设备代码里直接塞逻辑。 + +--- + +## 04. 核心流程|从 if-else 到状态机 + +### 屏显文案 + +**代码不再问“下一个 if 是什么”,**
+**而是问“当前 PCB 处于什么状态”。** + +1. **到位触发**:忽略重复上升沿,防止同一块板流程重入。 +2. **扫码与校验**:汇总双扫码,再根据条码检索产品 ID 文件。 +3. **结果与放行**:写入结果码,发出放行脉冲,等待 PLC 业务应答。 +4. **完成与追溯**:清状态、记录 CSV、刷新界面,等待下一块板。 + +关键规则: + +- 扫码失败:安灯 + NG 放行 +- 文件不存在:重试耗尽后 NG 放行 +- 系统异常:故障锁存,不自动放行 +- 收到 PLC 应答后,才执行可选清理 + +### 讲述提示 + +这就是我从 if-else 思维切换到状态机思维的关键点。每一种异常都不是额外补一段判断,而是状态机中明确的一条路径。 + +这样做的好处是,任何一个现场问题都可以回到三个问题:当前状态是什么?允许的下一步是什么?失败后应该如何恢复或锁存? + +--- + +## 05. 搭建过程|从方案到可运行系统 + +### 屏显文案 + +**从方案到测试,**
+**每一层都先解决一个真实问题。** + +| 时间 | 阶段 | 内容 | +| --- | --- | --- | +| 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)`,**
+**而是先问清楚“何时可以删”。** + +需求:配置可选启用;收到 PLC 放行应答后,删除本轮读取到的产品 ID 文件。 + +AI 协作过程: + +1. 追踪 `扫码 → 文件匹配 → ReleasePermit → PlcAckRelease` 的调用链。 +2. 明确 FINS 写入成功,只证明协议操作成功;不能等同于 PLC 完成业务应答。 +3. 保存精确命中路径;等待应答;先清放行脉冲;再由本地或 SFTP Provider 负责安全删除。 +4. 验证:应答成功删除;应答超时不删;越界路径拒绝;删除失败不回滚已确认放行。 + +AI 的三个贡献: + +- **读懂陌生系统**:快速在配置、接口、后台服务、设备实现和测试之间建立调用链。 +- **把自然语言变成契约**:把“放行后删除”翻译成前置条件、超时行为、默认开关和失败后果。 +- **让异常可验证**:用 Fake PLC / Fake 文件服务覆盖关键分支,让现场风险先在可控环境暴露。 + +### 讲述提示 + +这个案例最能说明我对 AI 的使用方式发生了变化。以前我可能直接让 AI 写删除文件的代码;现在我会先要求它追踪整条流程,再一起确认动作的前置条件与失败边界。 + +AI 帮我缩短了理解陌生系统和实现测试的时间,但业务责任仍然在我这里:什么时候删、删谁、失败后如何处理,必须由我结合现场规则确认。 + +--- + +## 08. 学习路径|从看懂到解决 + +### 屏显文案 + +**学习不是囤教程,**
+**而是不断缩短“看懂”到“解决”的距离。** + +1. **看 5 个视频**:只抓住 WPF、依赖注入、后台服务、设备通信的基础概念。 +2. **拆 1 个项目**:沿着一块 PCB 的生命周期,理解配置、状态、接口和日志为何存在。 +3. **自己搭一个**:从界面骨架到 PLC、扫码、文件校验,持续用 AI 做代码阅读和小步实现。 +4. **解决真实问题**:把“PLC 应答后再删文件”落成可配置、可测试、可追溯的工程规则。 + +关键转变: + +> 从“让 AI 帮我生成代码”,升级为“我能给 AI 足够明确的业务上下文,并验证它给出的工程边界”。 + +### 讲述提示 + +我并不是等到学会所有技术才开始做项目,而是在真实问题里逐步学习。视频帮助我建立术语,拆项目帮助我理解结构,自己实现帮助我建立手感,真实问题则迫使我理解生产边界。 + +--- + +## 09. 总结|从代码到工程交付 + +### 屏显文案 + +**从 if-else 到 Vibe Coding,**
+**改变的不是“谁来写代码”。** + +而是我开始能把一个模糊的现场需求,拆成: + +- 设备契约 +- 状态机 +- 异常边界 +- 可验证的交付 + +| 边界 | 内容 | +| --- | --- | +| 已在本地覆盖 | 项目定向构建与工作流、文件相关测试可验证逻辑分支、接口隔离和异常行为。 | +| 仍需现场确认 | 真实 PLC 点位、SFTP 根目录与删除权限,必须在产线按实际设备与权限完成联调。 | + +最后三点: + +1. **技术深度**:不是“调用了多少 SDK”,而是能否说清状态、超时、失败与恢复。 +2. **学习能力**:不是“看了多少教程”,而是能否把陌生系统拆成可验证的问题。 +3. **业务结合**:不是“做了一个界面”,而是让现场每一次放行都可解释、可追溯。 + +### 收尾讲述 + +AI 让开发速度更快,但它没有替代工程判断。真正的成长,是我开始能定义问题、判断边界、验证结果,并把一个模糊需求交付成可靠的现场流程。 + +谢谢。 + +--- + +## 汇报现场速记 + +- 用方向键或右下角“上一页 / 下一页”控制网页汇报。 +- 第 6 页点击“播放模拟流程”,演示完整闭环。 +- 不演示真实 PLC、真实 SFTP 或真实删除动作。 +- 不展示具体现场 IP、账号、密码、完整生产路径或未确认的 PLC 点位。 +- 被问到“是否现场验证”时,回答:本地逻辑与定向测试可验证;真实设备和权限仍需现场联调验收。 diff --git a/docs/assets/axiomron-dashboard-report.png b/docs/assets/axiomron-dashboard-report.png new file mode 100644 index 0000000..8060eed Binary files /dev/null and b/docs/assets/axiomron-dashboard-report.png differ diff --git a/docs/axiomron-pcbcheck-report-draft.html b/docs/axiomron-pcbcheck-report-draft.html new file mode 100644 index 0000000..6e94b1e --- /dev/null +++ b/docs/axiomron-pcbcheck-report-draft.html @@ -0,0 +1,1254 @@ + + + + + + + 3 个月,我从写 if-else 到 Vibe Coding + + + + +
AI PROGRAMMING · FIELD CASE
+ +
+
+
+
+

3 MONTHS · ONE REAL PROJECT

+

从写 if-else
到 Vibe Coding

+

我如何用 AI 搭建一套 PCB 目检放行上位机,以及普通人怎样上手、调试和避坑。

+
+ +
+
一段真实的 AI 编程实践01 / 08
+
+ +
+
+

01 / WHAT IS VIBE CODING

+

改变的不是“要不要思考”,
而是把时间花在哪里。

+
+
+ 过去 +

自己翻译成每一行代码

+

需求 → 查资料 → 写代码 → 运行 → 修改

+
+ +
+ 现在 +

先描述目标,再检查结果

+

讲清需求 → AI 实现 → 我来验证 → 继续迭代

+
+
+
一个简单比喻:像和一名速度很快的程序员结对工作——AI 负责加速,我负责方向与验收。
+
+
Vibe Coding 不是一句话生成全部,而是持续对话与验证02 / 08
+
+ +
+
+

02 / THE PROJECT

+

这不是概念图,
程序真的运行起来了。

+
+
+
+ AxiOmron PCBCheck WPF 主界面,展示 PLC、扫码枪、文件校验、安灯、流程状态与运行日志 +
+ 真实 WPF 运行界面 +
设备状态、当前条码、流程和日志集中展示本地展示环境 · 未连接真实设备
+
+
+ 一块 PCB 的 5 步旅程 +
+
01PLC 通知 PCB 到位START
+
02两把扫码枪读取条码SCAN
+
03根据条码检查产品文件CHECK
+
04发送结果并等待确认ACK
+
05保存记录并回到空闲DONE
+
+
+
+
+
运行界面是本地证据,不等同于真实 PLC / SFTP 现场验收03 / 08
+
+ +
+
+

03 / HOW HARD IS IT

+

上手不难,
难的是从“能跑”走到“可靠”。

+
+
+ 门槛低 +

做出原型

+

会描述需求、会运行项目,就能很快看到第一个结果。

+
+
+ 需要方法 +

做到可用

+

要会拆小任务、补充上下文,并检查 AI 实际改了什么。

+
+
+ 仍需专业判断 +

做到可靠

+

需要理解业务风险,并验证断网、超时和错误输入等异常场景。

+
+
+ +
+
有代码基础,上手会更快;没有代码基础,也可以从小工具开始04 / 08
+
+ +
+
+
+

04 / A REAL DEBUGGING CASE

+

信号写成功了,
为什么文件不能删?

+
+
+ 最初想法 · 有风险 +
await WriteReleaseAsync();
+await DeleteFileAsync();
+
+
+ 调试后 · 等待业务确认 +
await WriteReleaseAsync();
+if (ackReceived)
+    await DeleteFileAsync();
+
+
+

LOG 放行信号写入成功 → 等待 PLC 确认超时

+

像邮件显示“发送成功”,不代表对方已经阅读并执行。

+
+
+
调试情景演示等待选择
+
+
+ + +
+
+ 点击上方按钮 +

比较两种结果

+
PLC 业务结果待确认
+
产品文件保持不动
+
+
+
+
+
调试结论:协议成功 ≠ 业务完成05 / 08
+
+ +
+
+

05 / DEBUG WITH AI

+

程序出错时,
我用这套五步调试法。

+
+
01

先复现

说明做了什么、期望什么、实际发生什么。

+
02

给证据

提供报错、日志、配置和最近的修改。

+
03

讲流程

先让 AI 解释调用过程,不急着修改。

+
04

小步改

一次只处理一个原因,修改后立即运行。

+
05

正反测

既测试成功,也测试超时、断网和错误输入。

+
+
+
我的常用提示:“先不要改代码。请根据日志找到调用流程,列出最可能的三个原因,以及如何逐个验证。”
+
+
dotnet test · targeted3 PASSED · 666 ms
+
PASS收到 PLC 确认且开关开启 → 删除文件
+
PASS等待 PLC 确认超时 → 保留文件
+
PASS删除功能开关关闭 → 保留文件
+
+
+
+
证据越完整,AI 越不容易靠猜06 / 08
+
+ +
+
+

06 / FOUR THINGS TO REMEMBER

+

Vibe Coding 很快,
但这四条不能省。

+
+
01

任务要拆小

每一步都应该能运行、能观察、能撤回。

+
02

修改要看懂

至少确认改了哪些文件、为什么改、影响到哪里。

+
03

本地不等于现场

模拟测试不能替代真实设备、真实网络和实际权限。

+
04

高风险动作默认关闭

删除、付款、放行等动作必须有明确条件和可控开关。

+
+
+
AI 可以给建议,但业务责任和最终判断仍然属于人07 / 08
+
+ +
+
+
+

07 / TAKEAWAY

+

上手不难,
真正的能力是会验证。

+

AI 没有让我不再需要技术,而是让我把更多时间放在理解问题、判断风险和验证结果上。

+
+
+
会描述把目标、条件和期望结果讲清楚
+
会调试用日志和测试逐步排除原因
+
有边界知道什么时候不能完全相信 AI
+
+
+ +
+
+ + +
+ + +
+ + + +