534 lines
23 KiB
Markdown
534 lines
23 KiB
Markdown
# AxiOmron.PcbCheck 汇报演讲稿
|
||
|
||
> 主题：从初学者需求，到完整项目计划<br>
|
||
> 项目：AxiOmron.PcbCheck / PCB 目检放行上位机<br>
|
||
> 建议时长：10～12 分钟<br>
|
||
> 对应页面：[axiomron-pcbcheck-report-draft.html](./axiomron-pcbcheck-report-draft.html)<br>
|
||
> 内容来源：`docs/开发流程.txt`、`docs/纯plan.md`、当前项目实际工程
|
||
|
||
## 使用说明
|
||
|
||
这份文件不是简单的页面文案，而是现场可以直接使用的演讲稿：
|
||
|
||
- “屏显文案”对应 HTML 页面上看到的文字。
|
||
- “演讲主词”是建议直接讲出来的内容，可以按现场时间适当删减。
|
||
- “转场”用于从当前页面自然过渡到下一页。
|
||
- “操作/提示”用于现场演示，避免临场忘记重点。
|
||
- 全程只展示本地模拟和软件证据，不连接真实生产设备。
|
||
|
||
这次汇报的主线是：
|
||
|
||
```text
|
||
模糊需求 → 对话追问 → 补齐边界 → 完整计划 → 分阶段实现 → 测试验收
|
||
```
|
||
|
||
整场汇报不需要把代码讲得很深，重点是说明：我如何从一个初学者的功能描述，逐步学会定义问题、判断风险和验证结果。
|
||
|
||
---
|
||
|
||
## 01. 封面｜3 个月，我从写 if-else 到 Vibe Coding
|
||
|
||
**预计时长：40 秒**
|
||
|
||
### 屏显文案
|
||
|
||
**3 个月，**<br>
|
||
**我从写 if-else**<br>
|
||
**到 Vibe Coding**
|
||
|
||
用 AI 协作搭建一套 PCB 目检放行上位机：把 PLC、双扫码、文件校验、安灯和追溯记录，收束为一条可解释的现场闭环。
|
||
|
||
- 产品形态：WPF 工业上位机
|
||
- 技术基线：.NET 8 / MVVM
|
||
- 汇报重点：需求演进、调试方法、工程边界
|
||
|
||
### 演讲主词
|
||
|
||
大家好，今天我想分享的不是“AI 帮我生成了多少代码”，而是我如何从一个很简单的现场需求，逐步把它变成一份完整的项目计划，并最终做成一个可以运行的上位机项目。
|
||
|
||
三个月前，遇到扫码、查文件、通知 PLC 这种需求时，我很容易直接进入 if-else：扫码成功怎么办，文件找不到怎么办，PLC 超时怎么办。
|
||
|
||
后来我逐渐发现，工业软件最重要的不是先写出一段代码，而是先把现场规则、设备边界、异常情况和验收方式问清楚。AI 可以加快实现，但方向和判断仍然需要我自己负责。
|
||
|
||
### 转场
|
||
|
||
所以我们先回到起点，看一下最开始的需求到底是什么样的。
|
||
|
||
---
|
||
|
||
## 02. 初始需求｜我只想让它先跑起来
|
||
|
||
**预计时长：55 秒**
|
||
|
||
### 屏显文案
|
||
|
||
**最开始，我只想让它**<br>
|
||
**先跑起来。**
|
||
|
||
> “我需要写一个程序：PCB 到位后扫码，根据条码检查文件是否存在，再把结果返回给 PLC。”
|
||
|
||
初版要求：
|
||
|
||
1. PCB 到位后开始处理。
|
||
2. 读取一个条码。
|
||
3. 根据条码检查对应文件是否存在。
|
||
4. 文件存在显示“正常”。
|
||
5. 文件不存在显示“异常”。
|
||
6. 页面显示当前状态、条码、处理结果和日志。
|
||
7. 保存最近的处理记录。
|
||
8. 先使用模拟数据，不连接真实设备。
|
||
9. 页面提供“正常”“异常”“设备故障”三种模拟情况。
|
||
|
||
### 演讲主词
|
||
|
||
这不是一个错误的需求，反而非常适合作为第一版。
|
||
|
||
它已经说清楚了业务主线：PCB 到位以后开始处理，读到条码，根据条码查文件，文件存在就是正常，不存在就是异常，同时页面要能显示状态和日志，而且一开始先用模拟数据。
|
||
|
||
对初学者来说，这已经足够启动一个原型了。问题是，它还没有进入现场工程的层次。
|
||
|
||
它没有说明 PLC 的哪个信号算到位，两把扫描枪到底怎样通信，文件具体怎样命名，也没有说明异常时如何恢复、结果保持多久、什么条件下才算真正完成。
|
||
|
||
所以我当时的第一版想法是：先把正常流程跑通，再用模拟按钮把正常、异常和设备故障演示出来。
|
||
|
||
### 转场
|
||
|
||
但是，当我准备真正开始写设备通信代码时，就会遇到一个问题：还缺哪些信息？
|
||
|
||
---
|
||
|
||
## 03. 第一次对话｜还需要哪些信息才能开始写程序
|
||
|
||
**预计时长：1 分钟**
|
||
|
||
### 屏显文案
|
||
|
||
**真正开始写代码前，**<br>
|
||
**我先问：还缺什么？**
|
||
|
||
> “还需要哪些信息才能开始写程序？”
|
||
|
||
需要补齐四类事实：
|
||
|
||
| 类别 | 关键问题 |
|
||
| --- | --- |
|
||
| PLC | 型号、协议、点位、保持/脉冲、复位、应答、超时和异常恢复。 |
|
||
| 双扫描枪 | 通信角色、端口、结束符、编码、超时、双枪关系和断线行为。 |
|
||
| 文件规则 | 条码格式、文件名规则、匹配方式、目录类型、空文件和正在写入的处理。 |
|
||
| 程序与记录 | 界面、配置、日志、权限、模拟入口、部署方式和是否需要数据库。 |
|
||
|
||
### 演讲主词
|
||
|
||
这一步的价值，不是让 AI 变得更会猜，而是让它少猜。
|
||
|
||
首先是 PLC。需要知道 PLC 的型号和通信协议，哪个地址代表 PCB 到位，哪些地址由上位机写入，信号是保持型还是脉冲型，PLC 有没有复位和业务应答。
|
||
|
||
然后是扫描枪。两把枪是同时触发还是有先后？它们是 TCP Server 还是 TCP Client？返回有没有结束符？如果没有结束符，程序怎么知道一条条码已经接收完成？
|
||
|
||
第三是文件规则。条码是完整文件名，还是要转换成文件名？文件不存在和目录无法访问，是不是同一种异常？文件正在生成时应该等待、重试还是直接失败？
|
||
|
||
最后是程序怎么使用。操作员需要看到什么，工程师需要哪些日志，哪些操作需要权限，模拟入口怎样保留，记录是否要长期保存。
|
||
|
||
这些问题如果不提前确认，代码可能在本地看起来正确，到了现场却因为一个点位、一个报文边界或一个异常分类而产生错误判断。
|
||
|
||
### 转场
|
||
|
||
当这些问题被逐项问出来，需求就开始从“功能列表”变成“工程契约”。
|
||
|
||
---
|
||
|
||
## 04. 需求完善｜从功能描述到工程契约
|
||
|
||
**预计时长：1 分钟**
|
||
|
||
### 屏显文案
|
||
|
||
**需求不再只是“做什么”，**<br>
|
||
**还要说清楚“边界在哪里”。**
|
||
|
||
| 契约 | 需要明确的边界 |
|
||
| --- | --- |
|
||
| PLC 契约 | 到位、复位、结果、应答、任务去重和确认超时。 |
|
||
| 扫描枪契约 | 双路并发、无结束符、总超时、首个有效结果和迟到数据。 |
|
||
| 文件契约 | 条码清洗、路径安全、文件存在、目录异常和结果分类。 |
|
||
| 应用契约 | 设备状态、当前任务、日志、统计、模拟场景和权限边界。 |
|
||
|
||
需求演进链路：
|
||
|
||
`功能描述 → 条件边界 → 失败策略 → 验收证据`
|
||
|
||
### 演讲主词
|
||
|
||
需求完善以后，变化最大的地方是：每个功能都开始有前置条件和失败策略。
|
||
|
||
比如“把结果返回给 PLC”不再只是一句写入代码，而要继续问：结果保持多久？PLC 是否会给业务应答？确认超时怎么办？复位由谁触发？如果到位信号一直保持为真，是否会重复触发同一块 PCB？
|
||
|
||
“读取一个条码”也不再只是调用一次 Receive。要确认两把枪是否同时触发，是否允许任意一把成功，没有结束符时如何判断报文结束，迟到的数据是否会影响下一轮任务。
|
||
|
||
文件检查也要分清楚：文件存在、文件不存在、目录不可访问、路径越界、条码格式错误，这些不能全部压成一个简单的异常。
|
||
|
||
最终，需求被整理成一条链路：先描述功能，再补充条件边界，然后规定失败策略，最后为每个关键判断准备验收证据。
|
||
|
||
### 转场
|
||
|
||
当问题和边界都被整理出来以后，对话的结果就不再是一段零散的代码，而是一份可以执行的项目计划。
|
||
|
||
---
|
||
|
||
## 05. 完整项目计划｜对话的终点是一份可执行的计划
|
||
|
||
**预计时长：1 分钟**
|
||
|
||
### 屏显文案
|
||
|
||
**对话的终点，**<br>
|
||
**是一份可以执行的计划。**
|
||
|
||
| 层面 | 最终形成的内容 |
|
||
| --- | --- |
|
||
| 目标 | 让 PCB 从到位、扫码、文件校验到 PLC 结果反馈，形成可解释、可追溯的业务闭环。 |
|
||
| 流程 | 到位触发 → 双枪扫描 → 条码校验 → 文件判断 → 结果保持 → 应答/复位 → 记录完成。 |
|
||
| 架构 | 当前项目落地为 .NET 8 + WPF；设备通信、流程编排、界面状态、配置和日志保持清晰边界。 |
|
||
| 测试与验收 | 单元测试和 Fake 设备先验证逻辑，再使用真实设备完成现场联调。 |
|
||
|
||
计划的价值：把“我想要一个程序”翻译成目标、状态、接口、阶段、测试和交付门槛。
|
||
|
||
### 演讲主词
|
||
|
||
最后形成的不是一张简单流程图，而是一份完整的项目计划。
|
||
|
||
第一层是目标：让一块 PCB 从到位、扫码、文件校验，到结果反馈和记录完成，形成一条能够解释、能够追溯的业务闭环。
|
||
|
||
第二层是流程：什么时候开始，什么时候扫描，什么时候查文件，结果什么时候写回，什么时候等待 PLC 应答，什么时候复位并进入下一轮。
|
||
|
||
第三层是架构：当前仓库的实际落地基线是 .NET 8 加 WPF。设备通信、流程编排、界面状态、配置和日志各自有清晰边界，便于模拟、测试和后续替换设备实现。
|
||
|
||
第四层是测试和验收：先用单元测试和 Fake 设备验证软件逻辑，再使用真实 PLC、扫描枪和文件服务做现场联调。
|
||
|
||
这里有一个需要主动说明的历史差异：早期计划文本里出现过 WinForms，但当前工程实际采用 WPF。计划不是一次写死的合同，事实确认后可以修正；重要的是把历史方案和最终落地方案区分清楚。
|
||
|
||
### 转场
|
||
|
||
有了目标、流程、架构和验收标准，下一步就是按风险顺序把大计划拆成多个小闭环。
|
||
|
||
---
|
||
|
||
## 06. 开发阶段｜七个小闭环，逐步降低风险
|
||
|
||
**预计时长：55 秒**
|
||
|
||
### 屏显文案
|
||
|
||
**计划被拆成七个小闭环，**<br>
|
||
**每一步都有可以验证的产物。**
|
||
|
||
| 阶段 | 产物 |
|
||
| --- | --- |
|
||
| 01 需求与协议确认 | 点位、握手、报文、结果码和文件规则。 |
|
||
| 02 项目骨架 | WPF、配置、日志、依赖注入和基础状态。 |
|
||
| 03 PLC 通信 | 读写、超时、断线、重连和模拟接口。 |
|
||
| 04 双扫描枪 | 并发触发、无结束符、首个有效结果。 |
|
||
| 05 流程编排 | 任务去重、文件安全、结果保持和恢复。 |
|
||
| 06 状态界面 | 设备、任务、统计、日志和操作权限。 |
|
||
| 07 测试与交付 | 单测、Fake 流程、异常测试和现场验收。 |
|
||
|
||
### 演讲主词
|
||
|
||
这个项目不是一次性把所有功能堆出来，而是按风险顺序搭建。
|
||
|
||
第一阶段先确认事实，避免在错误协议或错误点位上继续开发。第二阶段建立项目骨架，让配置、日志、界面和业务流程有边界。第三、第四阶段分别处理 PLC 和双扫描枪通信，把设备问题尽量隔离在接口和服务里。
|
||
|
||
第五阶段才把到位、扫码、查文件、结果保持和复位串成完整流程。第六阶段把状态和结果展示给使用者。最后用单元测试、Fake 流程、异常测试和真实设备联调完成交付。
|
||
|
||
每个阶段都有可以检查的产物，所以遇到问题时，可以定位是需求没确认、通信没稳定、流程没定义，还是验收证据不足，而不是把所有问题都归结为“代码有 bug”。
|
||
|
||
### 转场
|
||
|
||
这也说明了 Vibe Coding 的真正价值：它可以加快每个小闭环，但不能替我们决定闭环是否成立。
|
||
|
||
---
|
||
|
||
## 07. Vibe Coding 上手难度｜能跑不等于可靠
|
||
|
||
**预计时长：50 秒**
|
||
|
||
### 屏显文案
|
||
|
||
**上手不难，**<br>
|
||
**难的是从“能跑”走到“可靠”。**
|
||
|
||
| 阶段 | 需要的能力 |
|
||
| --- | --- |
|
||
| 做出原型 | 会描述需求、会运行项目，就能很快看到第一个结果。 |
|
||
| 做到可用 | 会拆小任务、补充上下文，并检查 AI 实际改了什么。 |
|
||
| 做到可靠 | 理解业务风险，验证断网、超时、错误输入和恢复路径。 |
|
||
|
||
> 它降低的是写代码的门槛，没有消除软件工程本身的难度。
|
||
|
||
### 演讲主词
|
||
|
||
从体验上说，Vibe Coding 的确降低了入门门槛。
|
||
|
||
会描述目标、会运行项目，就可以很快做出一个原型。再进一步，需要会拆小任务、补充上下文，并且确认 AI 实际修改了什么。真正做到可靠，则必须理解业务风险，主动验证断网、超时、错误输入和恢复路径。
|
||
|
||
工业软件最难的地方，往往不是正常时能不能跑，而是异常时会不会误判、重复触发、误放行，或者丢失现场证据。
|
||
|
||
所以我现在的理解是：AI 像一名速度很快的协作程序员，负责加速实现；我负责方向、边界和最终验收。
|
||
|
||
### 转场
|
||
|
||
下面看一下这份计划最终如何落到一个可以运行的项目界面和处理流程上。
|
||
|
||
---
|
||
|
||
## 08. 实际项目运行｜程序真的运行起来了
|
||
|
||
**预计时长：1 分钟**
|
||
|
||
### 屏显文案
|
||
|
||
**这不是概念图，**<br>
|
||
**程序真的运行起来了。**
|
||
|
||
一块 PCB 的 5 步旅程：
|
||
|
||
1. PLC 通知 PCB 到位。
|
||
2. 两把扫码枪读取条码。
|
||
3. 根据条码检查产品文件。
|
||
4. 发送结果并等待确认。
|
||
5. 保存记录并回到空闲。
|
||
|
||
> 本地运行界面是软件证据，不等同于真实 PLC、扫描枪和文件服务现场验收。
|
||
|
||
### 现场操作
|
||
|
||
1. 展示 WPF 主界面中的设备状态、当前任务、文件校验、流程和日志。
|
||
2. 按页面右侧的 5 个步骤，说明一块 PCB 如何经过系统。
|
||
3. 重点停在第 4 步，说明写入结果以后还要等待 PLC 业务确认。
|
||
4. 强调当前是本地展示环境，没有连接真实生产设备。
|
||
|
||
### 演讲主词
|
||
|
||
到这里，前面讨论的计划已经对应到了实际工程中的界面和服务。
|
||
|
||
页面不是只显示一个最终的 OK 或 NG，而是把设备状态、当前任务、条码、文件检查、流程阶段和日志放在一起。这样发生异常时，工程师能够看到问题发生在哪一步，而不只是看到一个结果颜色。
|
||
|
||
这一页展示的是软件可以运行、流程可以观察，但它仍然不是现场验收证明。真实 PLC、真实扫描枪、真实文件服务和生产网络权限，还需要在现场单独验证。
|
||
|
||
### 转场
|
||
|
||
真正让我意识到工程边界的，是下面这个调试案例：信号明明写成功了，为什么文件仍然不能立即删除？
|
||
|
||
---
|
||
|
||
## 09. 真实调试案例｜先问清楚何时可以删
|
||
|
||
**预计时长：1 分 10 秒**
|
||
|
||
### 屏显文案
|
||
|
||
**信号写成功了，**<br>
|
||
**为什么文件不能删？**
|
||
|
||
最初想法：
|
||
|
||
```text
|
||
写入放行信号 → 删除文件
|
||
```
|
||
|
||
调试后的流程：
|
||
|
||
```text
|
||
写入放行信号 → 等待 PLC 业务确认
|
||
→ 确认成功后，才按配置执行后续动作
|
||
```
|
||
|
||
> PLC 写入成功，不等于产线已经完成业务确认。
|
||
|
||
### 现场操作
|
||
|
||
1. 进入第 9 页。
|
||
2. 点击“收到 PLC 确认”，观察状态变成“业务已确认”，文件允许按配置处理。
|
||
3. 点击“等待确认超时”，观察状态变成“确认超时”，文件保持不动。
|
||
4. 对听众强调：写入成功和业务完成是两个不同层次的结果。
|
||
|
||
### 演讲主词
|
||
|
||
最初的想法很直接：写入放行信号成功以后，就把本轮文件删掉。
|
||
|
||
后来调试时发现，这里混淆了两个概念：协议操作成功，和业务动作已经完成。
|
||
|
||
这可以类比成发邮件。系统显示“发送成功”，只表示邮件已经交给发送系统，并不代表对方已经阅读，更不代表对方已经执行了邮件里的内容。
|
||
|
||
在这个项目里，FINS 写入成功只能说明上位机完成了一次通信操作。只有 PLC 返回业务确认，才能说明产线已经确认了放行结果。确认成功以后，才可以根据配置决定是否执行后续清理；如果确认超时，就必须保留文件，不继续执行危险动作。
|
||
|
||
这个案例让我改变了使用 AI 的方式。以前我可能会直接让 AI 补一行 `DeleteFile`；现在我会先让它追踪完整调用链，确认前置条件、超时行为、默认开关和失败后果。
|
||
|
||
### 转场
|
||
|
||
当问题变复杂时，我不会只把错误信息丢给 AI，而是使用一套固定的证据驱动调试方法。
|
||
|
||
---
|
||
|
||
## 10. 五步调试法｜证据越完整，AI 越不容易靠猜
|
||
|
||
**预计时长：1 分钟**
|
||
|
||
### 屏显文案
|
||
|
||
**程序出错时，**<br>
|
||
**我用这套五步调试法。**
|
||
|
||
1. **先复现**：说明做了什么、期望什么、实际发生什么。
|
||
2. **给证据**：提供报错、日志、配置和最近的修改。
|
||
3. **讲流程**：先让 AI 解释调用过程，不急着修改。
|
||
4. **小步改**：一次只处理一个原因，修改后立即运行。
|
||
5. **正反测**：既测试成功，也测试超时、断网和错误输入。
|
||
|
||
常用提示：
|
||
|
||
> “先不要改代码。请根据日志找到调用流程，列出最可能的三个原因，以及如何逐个验证。”
|
||
|
||
### 演讲主词
|
||
|
||
我的调试方式可以概括成五步。
|
||
|
||
第一，先复现，把做了什么、期望什么、实际发生什么说清楚。第二，给证据，包括日志、异常、配置和最近的修改。第三，让 AI 先解释调用流程，不要一上来就修改代码。
|
||
|
||
第四，一次只改一个原因，修改以后立即运行。第五，不只测试成功场景，还要测试超时、断网、错误输入和功能开关关闭的情况。
|
||
|
||
我常用的提示词是：“先不要改代码，请根据日志找到调用流程，列出最可能的三个原因，以及如何逐个验证。”
|
||
|
||
这样做的好处是，每次修改都能回答三个问题：为什么改、改了什么、怎么证明改对了。
|
||
|
||
### 操作/提示
|
||
|
||
- 页面上的测试证据展示了 PLC 确认成功、确认超时和功能开关关闭三种结果。
|
||
- 不需要逐字讲出所有测试名称，只需说明“成功和失败都要验证”。
|
||
|
||
### 转场
|
||
|
||
方法解决了如何调试，边界解决的是哪些事情不能省、哪些结果不能被误读。
|
||
|
||
---
|
||
|
||
## 11. 工程边界与验收｜这几条不能省
|
||
|
||
**预计时长：55 秒**
|
||
|
||
### 屏显文案
|
||
|
||
**Vibe Coding 很快，**<br>
|
||
**但这些不能省。**
|
||
|
||
| 规则 | 现场含义 |
|
||
| --- | --- |
|
||
| 任务要拆小 | 每一步都应该能运行、能观察、能撤回。 |
|
||
| 修改要看懂 | 确认改了哪些文件、为什么改、影响到哪里。 |
|
||
| 模拟不等于现场 | Fake 设备只能先验证逻辑，不能替代真实设备联调。 |
|
||
| 高风险动作默认关闭 | 删除、放行等动作必须有明确条件和可控开关。 |
|
||
|
||
交付边界：
|
||
|
||
- 异常可恢复：断线、超时、目录不可访问都有状态、日志和恢复策略。
|
||
- 过程可追溯：每一轮任务都能回看输入、判断、结果和失败原因。
|
||
- 现场才算验收：真实点位、通信边界、权限和连续生产稳定性必须确认。
|
||
|
||
### 演讲主词
|
||
|
||
这一页是我认为最重要的工程边界。
|
||
|
||
第一，任务要拆小，每一步都要能运行、能观察、能撤回。第二，修改要看懂，至少知道改了哪些文件、为什么改、影响了什么。
|
||
|
||
第三，模拟不等于现场。Fake PLC、Fake 扫描枪和本地文件可以帮助我们先验证逻辑，但不能替代真实设备、真实网络和真实权限。
|
||
|
||
第四，高风险动作默认关闭。删除文件、放行、清理现场依据，都要有明确条件、可控开关和失败策略。
|
||
|
||
所以交付标准不是“页面能打开”，而是异常可恢复、过程可追溯，并且真实设备完成现场验收。
|
||
|
||
### 被问到现场验证时
|
||
|
||
可以直接回答：
|
||
|
||
> 当前已有本地构建、定向测试和可控模拟流程证据；真实 PLC、扫描枪、文件服务、网络权限和连续生产稳定性仍需要现场联调验收，不能用模拟结果替代。
|
||
|
||
### 转场
|
||
|
||
最后用三句话总结这次从初始需求到项目计划的变化。
|
||
|
||
---
|
||
|
||
## 12. 总结｜从一句话需求到可运行项目
|
||
|
||
**预计时长：50 秒**
|
||
|
||
### 屏显文案
|
||
|
||
**从一句话需求，**<br>
|
||
**到可验证的完整计划。**
|
||
|
||
最后再到一个能运行、能追溯、知道边界的项目。
|
||
|
||
- **会提问**：把需求里的空白和风险问出来。
|
||
- **会拆解**：把自然语言变成流程、阶段和验收标准。
|
||
- **会验证**：把本地证据与真实现场验收分开。
|
||
|
||
### 收尾讲述
|
||
|
||
这次最大的变化，不是 AI 替我写了多少代码，而是我开始能把一个模糊的现场需求，拆成设备契约、状态流程、异常边界、开发阶段和验收证据。
|
||
|
||
以前我更关注“能不能生成代码”，现在我更关注“问题有没有定义清楚、边界有没有说明白、结果有没有被验证”。
|
||
|
||
AI 让开发速度更快，但没有替代工程判断。真正的成长，是我开始能定义问题、判断风险、验证结果，并把一句话需求逐步变成一份完整计划和一个可以运行的项目。
|
||
|
||
谢谢大家。
|
||
|
||
---
|
||
|
||
## 问答备忘
|
||
|
||
### 问：这套程序现在是不是已经连接真实 PLC 了？
|
||
|
||
答：本次汇报展示的是本地可控环境和软件运行证据，没有连接真实生产设备。真实 PLC 点位、通信边界、权限和连续生产稳定性仍需要现场联调验收。
|
||
|
||
### 问：AI 是不是已经替代了开发人员？
|
||
|
||
答：AI 加快了查找、实现和测试，但没有替代需求确认、风险判断和验收责任。尤其是放行、删除和复位这类动作，必须由业务人员确认规则。
|
||
|
||
### 问：为什么计划里出现过 WinForms，最后项目是 WPF？
|
||
|
||
答：WinForms 是早期计划中的技术选择，随着实际工程基线和项目结构确认，当前实现落地为 .NET 8 + WPF。这个变化被保留并明确说明，避免把历史方案误认为最终实现。
|
||
|
||
### 问：为什么不直接把正常流程做完再说？
|
||
|
||
答：正常流程可以快速做出原型，但工业现场真正容易出问题的是超时、断线、重复触发、结果未确认和权限异常。提前定义这些边界，可以减少后期返工和现场风险。
|
||
|
||
### 问：项目现在能不能直接上产线？
|
||
|
||
答：不能仅凭本地模拟结果判断可以上产线。需要完成真实 PLC、双扫描枪、文件服务、网络权限、异常恢复和连续生产稳定性验证后，才能按现场验收结果决定。
|
||
|
||
---
|
||
|
||
## 现场演示检查清单
|
||
|
||
### 开始前
|
||
|
||
- 确认浏览器打开的是 `docs/axiomron-pcbcheck-report-draft.html`。
|
||
- 确认页面能看到 12 个圆点和“下一页”按钮。
|
||
- 确认第 9 页的两个调试按钮可以点击。
|
||
- 不打开真实 PLC、真实扫描枪、真实文件服务器或生产目录。
|
||
|
||
### 演示中
|
||
|
||
- 第 2 页讲完初始需求后，停顿一下，强调“这已经能做原型，但还不能直接上现场”。
|
||
- 第 3～6 页是本次新增主线，要讲清“追问如何变成完整计划”。
|
||
- 第 8 页展示项目运行证据，但明确它不是现场验收。
|
||
- 第 9 页先点“收到 PLC 确认”，再点“等待确认超时”。
|
||
- 第 11 页主动说明模拟测试和现场验收的区别。
|
||
|
||
### 结束后
|
||
|
||
- 用“会提问、会拆解、会验证”收尾。
|
||
- 如果时间不足，优先保留第 2、3、5、9、11、12 页。
|
||
- 如果时间充足，再完整讲第 4、6、7、8、10 页。
|