📝 docs(report): 添加 AI 编程汇报材料

* 添加面向非技术听众的完整汇报稿与页面文案
* 提供明亮风格 HTML 演示页及调试情景交互
* 加入本地 WPF 运行截图、代码对比与测试证据

docs/AxiOmron_PCBCheck_完整汇报稿.md

@@ -0,0 +1,141 @@
+# 《3 个月，我从写 if-else 到 Vibe Coding》汇报稿
+
+> 建议时长：8～10 分钟<br>
+> 面向听众：以非开发人员为主<br>
+> 核心目标：让听众听懂 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 确认时允许删除；确认超时时文件保留。
+
+演示时不需要展示大段代码，只需要展示日志或测试结果，并用“邮件发送成功不等于对方已经执行”的比喻解释问题。
+
+如果现场演示失败，可以直接说：
+
+> “这也是调试的一部分。现在我会先保留现场状态和日志，而不是连续修改代码。演示环境没有连接真实设备，下面展示我提前准备的测试结果。”

docs/AxiOmron_PCBCheck_汇报文案.md

@@ -0,0 +1,267 @@
+# 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 点位。
+- 被问到“是否现场验证”时，回答：本地逻辑与定向测试可验证；真实设备和权限仍需现场联调验收。