142 lines
6.8 KiB
Markdown
142 lines
6.8 KiB
Markdown
# 《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 确认时允许删除；确认超时时文件保留。
|
||
|
||
演示时不需要展示大段代码，只需要展示日志或测试结果，并用“邮件发送成功不等于对方已经执行”的比喻解释问题。
|
||
|
||
如果现场演示失败，可以直接说：
|
||
|
||
> “这也是调试的一部分。现在我会先保留现场状态和日志，而不是连续修改代码。演示环境没有连接真实设备，下面展示我提前准备的测试结果。”
|