3 MONTHS · ONE REAL PROJECT

从写 if-else
到 Vibe Coding

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

01 / WHAT IS VIBE CODING

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

过去

自己翻译成每一行代码

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

现在

先描述目标，再检查结果

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

一个简单比喻：像和一名速度很快的程序员结对工作——AI 负责加速，我负责方向与验收。

02 / THE PROJECT

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

AxiOmron PCBCheck WPF 主界面，展示 PLC、扫码枪、文件校验、安灯、流程状态与运行日志 — **设备状态、当前条码、流程和日志集中展示**本地展示环境 · 未连接真实设备

一块 PCB 的 5 步旅程

01PLC 通知 PCB 到位START

02两把扫码枪读取条码SCAN

03根据条码检查产品文件CHECK

04发送结果并等待确认ACK

05保存记录并回到空闲DONE

03 / HOW HARD IS IT

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

门槛低

做出原型

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

需要方法

做到可用

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

仍需专业判断

做到可靠

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

04 / A REAL DEBUGGING CASE

信号写成功了，
为什么文件不能删？

最初想法 · 有风险

await WriteReleaseAsync();
await DeleteFileAsync();

调试后 · 等待业务确认

await WriteReleaseAsync();
if (ackReceived)
    await DeleteFileAsync();

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

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

调试情景演示等待选择

点击上方按钮

比较两种结果

PLC 业务结果待确认

产品文件保持不动

05 / DEBUG WITH AI

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

01

先复现

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

02

给证据

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

03

讲流程

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

04

小步改

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

05

正反测

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

我的常用提示：“先不要改代码。请根据日志找到调用流程，列出最可能的三个原因，以及如何逐个验证。”

dotnet test · targeted3 PASSED · 666 ms

PASS收到 PLC 确认且开关开启 → 删除文件

PASS等待 PLC 确认超时 → 保留文件

PASS删除功能开关关闭 → 保留文件

06 / FOUR THINGS TO REMEMBER

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

01

任务要拆小

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

02

修改要看懂

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

03

本地不等于现场

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

04

高风险动作默认关闭

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

07 / TAKEAWAY

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

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

会描述把目标、条件和期望结果讲清楚

会调试用日志和测试逐步排除原因

有边界知道什么时候不能完全相信 AI