Vibe Coding 实战 —— 20天开发了一款医学管家全栈 App

最近 Vibe Coding 这个词很流行，这是一个随着 AI 在编程领域不断发展而生长出来的概念，直译过来就是氛围编程，

简单来说就是你不需要关心代码细节，只需要负责和 AI 沟通就行，最终达到预期的效果。我给它取了个名字：面向感觉编程，感觉会更贴切点。

AI 时代，传统技术栈之间的界限逐渐模糊，人人都是全栈工程师。虽然道理谁都懂，但是纸上得来终觉浅，自己上手实战才是王道。

于是我开发了一个产品，把之前开发的一个医学报告 OCR 小工具，升级成了一个商业化的产品。全程基于 Vibe Coding，用了20多天时间。

这是一个医学管家的产品，核心功能：用户上传纸质或者截屏的医学报告，AI 会自动解析出时间、地点、指标等信息进行数字化管理。

随着报告越来越多，AI 还会关联同一个指标的发展趋势，帮助用户更好地了解自身健康状况，对于需要定期复查的患者来说极为方便。

产品体验：https://app.caremax.ai

下面聊聊我在 Vibe Coding 开发过程中的一些心得体会。

Vibe Coding 原则

我使用的 IDE 是 Cursor Pro + Claude-3.7-sonnet-thinking。当你面对从零到一，无从下手的时候，我总结的几条原则是：

1.先后端再前端

2.先思考再编码

3.阶段性固化成果

为什么要先做后端？因为后端的干扰项最少，需要考虑的东西更专一，也更核心，前端只不过是围绕后端接口展开设计而已。

在设计后端代码的过程中，也要遵循先思考再编码的原则，先和 AI 讨论思路，不急于写代码。

当输出了一份满意的方案后，阶段性任务完成，把方案固化到一个 markdown 文件里。然后重开一个上下文，继续下一个任务。这就是「阶段性固化成果」原则。

因为冗余的上下文会让模型性能严重下降。

对于有经验的开发者，可以直接设计好架构让 AI 去实现，省去思考的过程（因为 AI 并不一定能想到好架构）。

比如我在设计 ocr 模块的时候，我需要支持 LLM、传统 OCR 多路方案并发识别，每个方案下还有不同的模型可供选择，

这个时候经验告诉我最适合使用抽象类+多态的设计模式，这样后续有新的模型只要重载然后通过注册插件的形式就可以快速拓展，可维护性也变成更高。

类似的地方还有很多，AI 不一定能立刻想到，需要有经验的开发者补上。

商业化的产品不同于自用的工具，自用的工具能跑就行，商业化了就要考虑速率、效率、成功率等用户体验方面的指标。

在内测过程中，我就发现线上环境 AI 解析一张报告的时间是本地环境的5倍，究其原因在于：

1.线上多个服务是独立部署的，每个服务之间都有网络延迟

2.因为服务都是 Serverless，用户量小的情况下每个服务都有冷启动耗时

而本地开发过程中，所有服务都是本地部署，相互调用时几乎没有耗时。基于上面的问题，优化方案也很明显：

1.尽可能把服务放在一个项目里

2.用好并发。

第2点虽然说起来很简单，但是复杂度吊打之前的单文件、串行流水线。

我需要支持多个报告同时解析，每个报告又需要并发多个模型一起识别，最后取最先返回的结果。

为此，我专门开了一个全新的上下文，让 AI 参考 RxJS 响应式编程，实现一个精简版的事件驱动并发模型。最终线上环境一张报告平均 12s 就能解析完毕。

就和开放世界游戏一样，有时候你需要暂时离开主线剧情，去做一些副本任务，为的是主线任务更轻松过关。

以上案例可以看出，现阶段我觉得让一个没有编码基础的人开发一个够用的产品是没问题的，但是涉及到性能优化，必须依赖开发者本身的经验。

这个经验并不一定是技术本身的，还包括通用的 Debug 能力。Debug 本身也是编程能力里很重要的一环。

测试后端模块

当后端业务全部开发完毕之后，按照传统的 SOP 我们就要写单测了。这一步就是体力活了，也是 AI 最擅长的领域。

然后使用 Postman 调试接口，把后端逻辑闭环跑通。这一步就和传统开发一样了，不再赘述。

API 文档

继续下一步。当后端模块开发完并且测试通过后，我一般都是重开一个上下文，让 AI 基于现有的后端代码，

输出一个 Curl Example 集合，然后固化到一个单独的 markdown 文件，让前端基于这份 API 文档编码。

同时，把后端源码全部做 chunk embedding 喂给大模型，这一步也是 Cursor 自带的。有了源码索引和 API 文档，接下去的 UI 代码都轻松多了。

编写前端

UI 方面，根据产品功能和调性决定用什么设计。比如像我这个产品作为一个 SaaS 工具，直接用的 antd、element UI 这类现成组件最合适不过。

如果是个性化的产品就需要自定义设计了，可以截图你喜欢的设计给 AI，让 AI 模仿实现。Caremax plans 套餐页面就是借鉴了其他网站的设计。

有一说一，我觉得前端比后端复杂多了。虽然这个行业后端话语权更大，但我还想为前端正名。

后端关心的是数据状态的逻辑关系，一些底层的 devops 比如负载均衡、并发效率、数据库等等高度复用，基本都已经被云厂商做完了，普通开发者很少机会接触。

而前端需要关心 UI 状态的逻辑关系，这个 UI 状态就没那么方便复用了，每个场景都要专门定制，

比如我遇到 useEffect 时效性问题就产生了很多 badbase，更别说还要设计一些独一无二的动效。但要说可玩性最高的，还是当属客户端。

还记得当年做客户端开发的时候，为了优化滑动流畅性，直接操作底层的 GPU、CPU 内核做性能优化；为了优化代码效率，用 C 语言实现逻辑；

为了优化并发效率，手动管控内核线程；什么图片库、数据库、网络库....统统有基于底层的自定义实现。

所以我一直有个「暴论」，客户端才是最难的，因为它是直接面向硬件开发，可玩性更高。

前端 —— 浏览器封装了大部分逻辑，后端 —— 云厂商做掉了大部分工作。

Vibe coding 死胡同

在整个项目的开发过程中，并非都是一帆风顺。尤其在设计前端页面的时候，一些 UI 上的复杂逻辑经常难住 AI。

这时候经常会面临拆东墙补西墙的窘境，这个问题修好了，那边又出问题了。但最后变成一坨屎山。我的经验就是：

与其在一堆屎山上修修补补，不如推倒重来

同时，及时固化成果+git commit 很重要，类似游戏里的存档，让 AI 可以从上一次的 checkpoint 继续。

不要贪婪，不要侥幸。最小化任务，不要试图一口气完成一个大任务。

尾巴

以上就是我基于 Vibe Coding 开发一款完整产品的心得体会。开发体验用「划时代」这个词来形容一点都不过分，完全重塑了程序员的工作流。

唯一的窘境在于性能优化还是需要较多的经验，很多前端 UI 虽然 AI 也能像模像样写出来，看上去似乎一样，但是可维护性、极致性能还需要有经验的工程师才行。

但我觉得这都是时间问题，随着 AI 模型的能力提升都能解决。

抛开这一点不谈，Vibe Coding 已经极大拓展了传统程序员能力的广度，真正实现了 T 型人才的目标。

文章来自于 “Kitten的时间胶囊”，作者 ：KittenYang