【Vibe Coding 实战】我如何用 AI 把一张草图变成了能跑的应用

背景：故事的开始

故事的开头，是公司里一个有点棘手的项目需求——给移液枪做自动化调参。

简单来说，就是我们要让移-液枪能快速自动调整参数，达到交付给客户的精准标准。在这之前，这活儿全靠人工，工程师们得一遍遍地测试、验证、调整，而且每种液体的标准还不一样，纯纯的体力活，费时又费力。

后来，我们团队想出了一个结合 LLM+Agent 的改造方案。核心思路就是让 Agent 去自动化地执行操作、收集数据、验证结果，再用这些数据去训练一个预测模型。基本上，就是把整个枯燥的流程都丢给 Agent 去搞定。

过程：从“灵魂草图”到 V1.0

在尝试 AI 编程之前，其实我已经吭哧吭哧搞出了一个 Demo。但在演示的时候，总觉得缺一个酷炫的 UI 界面来展示我们的成果。

一开始我打算用 Python 的 Gradio 快速搭一个，但发现 Gradio 的页面实在是太“朴素”了，有点配不上我们这套方案。

于是我决定，上！必须上 React + Node.js 全家桶！但问题来了，时间紧任务重，哪有空从零手写？这时候，我想到了最近很火的 AI 编程产品，决定尝试一下“Vibe Coding”的感觉。

挑来挑去，最后选了 bolt.new，原因很简单——它做出来的页面是真的好看！抱着试一试的心态，我开干了。

第一步：灵魂画手上线

万物起源于草图。我用 Excalidraw 画了张整体的“灵魂草图”。（PS：Excalidraw 这工具真心好用，强烈推荐！）

第二步：AI 生成前端

草图在手，我把它丢给了 bolt.new，让它帮我生成前端项目。

经过几轮“调教”，一个可以运行的前端项目就诞生了！页面看起来挺清爽，感觉不错。虽然有些小 bug，但伤及无辜，花点时间修复一下就 OK 了，完全不影响主体功能。

第三步：让 AI 看着前端写后端

前端有了，后端自然也得跟上。任务的状态管理、执行流程、各种接口开发、还有和硬件的对接……一堆活儿等着。

这时我灵机一动：既然前端是 AI 生成的，我能不能让 AI 看着我的前端代码，帮我把后端也写了？

说干就干，我把这个任务交给了 Claude。结果相当惊喜，我想要的功能，Claude 基本上帮我搞定了七七八八。当然，这中间我也反复调整了好几轮提示词（prompt）。Claude 甚至还贴心地帮我做了版本管理，可以随时回滚。最终，我调试到了 v9 版本，同时也把我免费的调用次数给榨干了，哈哈。

(Claude 帮我生成的后端代码)

(Claude 甚至帮我设计并创建了数据库表结构)

Claude 根据我的前端项目，不仅生成了对应的 API，连数据库的表结构设计和创建都一条龙服务了。一个基本的 CRUD 后端就这么完成了，效率是真的高！

第四步：缝缝补补，打通最后一公里

有了 AI 生成的前后端框架，剩下的就是一些“体力活”了。我花了一些时间，把剩余的功能补全，比如 Agent 的具体规划（planning）、任务执行逻辑、和硬件的对接等等。

在这个过程中，Copilot 成了我的得力助手，帮我完成了大量的代码补全和逻辑实现。最后，连最终任务的校准报告生成和设计，也是在它的辅助下完成的。

至此，项目的 V1.0 版本顺利诞生！

(最终生成的校准报告)

一些感受

总有人说，AI 编程是来“取代”程序员的。但我的十二年软件开发生涯告诉我一件事：

“写代码从来不是瓶颈，代码最大的成本是理解，而不是写出来。”

在这个时代，“写出代码”的成本正变得越来越低，我相信未来只会更快、更好。但只有真正做过开发的人才明白，去理解需求、去想清楚到底要写出什么样的代码，这才是最核心、最无法被替代的部分。

就像很多人说的，这是一个变化飞快的时代，真正会被淘汰的，可能只是那批不愿意接受改变、不会利用 AI 的程序员。

结尾曲

最后，引用一段我最近看到并且非常喜欢的话来收尾吧：

“LLM很强大，但并未解决根本问题。
LLM在快速原型开发、脚手-架搭建和自动化方面确实带来了真正的价值。然而，它们无法消除清晰思考、谨慎审查以及周密设计的必要性。相反，随着生成代码越来越多，这些基础工作变得更为关键。
是的，写代码的成本确实降低了。但团队一起理解代码的成本并没有降低。
这才是真正的瓶颈。我们不应假装它不存在。”

时代的洪流滚滚向前，我愈发觉得自己渺小。但即便如此，我也希望能在浪潮中留下一点属于我自己的痕迹。