3 MONTHS · ONE REAL PROJECT
从写 if-else
到 Vibe Coding
我如何用 AI 搭建一套 PCB 目检放行上位机,以及普通人怎样上手、调试和避坑。
01 / THE FIRST REQUEST
最开始,我只想让它
先跑起来。
这就是《开发流程.txt》里的最初版本:目标很清楚,但工程边界还没有被说出来。
02 / ASK BEFORE BUILDING
真正开始写代码前,
我先问:还缺什么?
这一步把“能不能写”变成“哪些事实还没有确认”。
型号、协议、点位、保持/脉冲、复位、应答、超时和异常恢复。
IP、端口、通信角色、结束符、编码、超时、双枪关系和断线行为。
条码格式、文件名规则、精确/模糊匹配、目录类型、空文件和正在写入的处理。
界面、配置、日志、记录、权限、模拟入口、部署方式和是否需要数据库。
03 / TURN QUESTIONS INTO CONTRACTS
需求不再只是“做什么”,
还要说清楚“边界在哪里”。
定义一轮任务什么时候开始、什么时候结束,以及长保持信号如何避免重复触发。
不把一次 TCP Receive 想当然地当成完整条码,明确无结束符和迟到结果的处理。
把条码清洗、文件存在、目录不可访问和路径越界区分成可追踪的结果。
把设备状态、当前任务、日志、统计和模拟场景放进可观察的界面闭环。
04 / THE COMPLETE PROJECT PLAN
对话的终点,
是一份可以执行的计划。
让 PCB 从到位、扫码、文件校验到 PLC 结果反馈,形成一条可解释、可追溯的业务闭环。
到位触发 → 双枪扫描 → 条码校验 → 文件判断 → 结果保持 → 应答/复位 → 记录完成。
当前项目落地为 .NET 8 + WPF;设备通信、流程编排、界面状态和配置日志保持清晰边界。
单元测试和 Fake 设备先验证逻辑,再用真实 PLC、扫描枪和文件服务完成现场联调。
计划的价值:把“我想要一个程序”翻译成目标、状态、接口、阶段、测试和交付门槛。
05 / BUILD IN RISK ORDER
计划被拆成七个小闭环,
每一步都有可以验证的产物。
点位、握手、报文、结果码和文件规则。
WPF、配置、日志、依赖注入和基础状态。
读写、超时、断线、重连和模拟接口。
并发触发、无结束符、首个有效结果。
任务去重、文件安全、结果保持和恢复。
设备、任务、统计、日志和操作权限。
单测、Fake 流程、异常测试和现场验收。
计划不是一次写死:事实确认后可以调整实现,但每次调整都要回到边界、证据和验收标准。
06 / HOW HARD IS IT
上手不难,
难的是从“能跑”走到“可靠”。
做出原型
会描述需求、会运行项目,就能很快看到第一个结果。
做到可用
要会拆小任务、补充上下文,并检查 AI 实际改了什么。
做到可靠
需要理解业务风险,并验证断网、超时和错误输入等异常场景。
它降低的是写代码的门槛,没有消除软件工程本身的难度。
07 / THE PROJECT RUNS
这不是概念图,
程序真的运行起来了。
08 / A REAL DEBUGGING CASE
信号写成功了,
为什么文件不能删?
await WriteReleaseAsync();
await DeleteFileAsync();
await WriteReleaseAsync();
if (ackReceived)
await DeleteFileAsync();
LOG 放行信号写入成功 → 等待 PLC 确认超时
像邮件显示“发送成功”,不代表对方已经阅读并执行。
比较两种结果
09 / DEBUG WITH AI
程序出错时,
我用这套五步调试法。
先复现
说明做了什么、期望什么、实际发生什么。
给证据
提供报错、日志、配置和最近的修改。
讲流程
先让 AI 解释调用过程,不急着修改。
小步改
一次只处理一个原因,修改后立即运行。
正反测
既测试成功,也测试超时、断网和错误输入。
10 / BOUNDARIES & ACCEPTANCE
Vibe Coding 很快,
但这些不能省。
任务要拆小
每一步都应该能运行、能观察、能撤回。
修改要看懂
至少确认改了哪些文件、为什么改、影响到哪里。
模拟不等于现场
Fake 设备只能先验证逻辑,不能替代真实 PLC、扫描枪和文件服务。
高风险动作默认关闭
删除、付款、放行等动作必须有明确条件和可控开关。
断线、超时、目录不可访问,都要有状态、日志和恢复策略。
每一轮任务都能回看输入、判断、结果和失败原因。
真实点位、通信边界、权限和连续生产稳定性必须现场确认。
11 / TAKEAWAY
从一句话需求,
到可验证的完整计划。
AI 没有替我完成工程判断,而是帮我更快地提问、拆解、实现和验证,最后把一个模糊需求变成能运行、能追溯、知道边界的项目。