我对现今的前端技术几乎完全不懂，但借助于AI，几乎不需要什么背景知识就可以轻松构建这样一个还不错的应用。本文除了简要介绍一下这个网站的功能外，同时也谈谈开发过程的一些经验感悟，希望对你有所帮助，更期待一起交流经验。

背景

在医院看到不少爸妈都很认真负责地记录着孩子的各项检测数值，我也曾经将一些数据记录在笔记本中。那些牵动家长们内心的数值，一旦离开了纸质记录本，就很难说清楚，也不便于和医生沟通交流，更难发现其中的变化规律。某天在从医院回家的路上，灵机一动：何不构建一个血常规追踪应用，让整个治疗过程清晰直观呢？

本文会简单介绍一下这个网站，更重要的会分享一下在使用Lovable平台和Cursor中的一些独家的感受。

成果展示

我的Lovable会员每个月有100次AI对话额度，打算物尽其用，“强行”让它值回票价，便计划用它来搭建网站雏形。经历了几天的迭代、趟过一些坑、也用光了Cursor的次数后，我总算以网站的形式，捣鼓出了一个比较完整的血常规追踪功能。先来看看基础功能，后面再谈谈开发过程中的一些经验。

我们可以快速预览到最近一次检测有哪些指标异常：

也可以通过单指标或多指标的选择进一步分析变化趋势，同时可以结合期间的治疗及手术情况，分析指标变化的原因：

然后可以通过医疗日历，查看到每天的用药情况等：

在检测数据的录入中，除了传统的手术填表外，借助于AI识图，可以通过上传图片，系统会自动识别出检测数据，包括采样时间等以及各项指标的数值，并自动填充到表单中：

我们可以添加期间的用药及手术类型，针对不同的病种，可以自定义自己的用药以及手术，可以用不同颜色区分： 同时也提供了一些预设，可以选择性导入：

同时，除了单个日期的添加记录，支持批量选择日期，通过Shift等常用区间选择的交互方式，可以快速添加一整段时间的记录，这样对于一些需要长期用药，这会更便捷一些。

有时找医生沟通，我们需要一个表格呈现一些数据，网站提供了将选定区间的信息导出的功能，同时会标注期间的一些关键事项。

做完这些后，为了让初次使用的人可以快速上手，我们可能还需要一个使用指南，借助于现在便捷的网页生成能力，一个简洁美观的说明页也快速生成了：

开发过程

和AI一起明晰目标——反复折腾多缘于目标不清

尽管头脑中已经有不少这个应用的功能点，但在让AI开始正式编码前，我们还需要细化一些东西，于是我和Gemini 2.5 Pro聊了起来。像一个倾诉对象一样，我和它谈我的目标，也让它反过来询问我一些事项，最后我们敲定了方案，Gemini 2.5 Pro 在我得到有首肯后，很快就帮我生成了一份需求文档。这期间，AI会帮助我们完善一些可能欠考虑的细节，比如数据的隐私性，它强调：

数据安全：对病人的血常规数据进行加密存储，确保数据库中的数据没有明文可读内容。加密算法建议采用行业常用的对称加密算法如AES（高级加密标准），以保障数据在存储过程中的安全性。

最终形成了一个初版的提示词，它将交给Lovable平台：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34

根据你提供的新信息，我们可以进一步完善开发提示词，以下是目前整理的详细提示词，涵盖了之前和新确认的需求，可用于在 https://lovable.dev/ 创建应用：

### 应用概述
开发一个用于跟进病人血常规变化的APP，主要具备两大核心功能：一是允许病人录入血常规情况，支持文字和图片录入方式，图片录入时使用OCR工具识别内容，录入的数据会整理后记录到数据库；二是通过图表（主要是趋势图）展示相关数据，支持选择展示某一个指标的数值，图表横轴为按真实日期连续排列的日期，纵轴为指标对应的数值，同时要考虑每个指标的参考范围并在图中展示，根据数值低于或高于参考范围，对应点展示不同颜色。

### 功能需求

#### 数据录入功能
1. **文字录入**
    - 提供简洁的文字录入界面，病人可按照规范格式录入血常规数据，数据应包含日期（精确到上午或下午）以及各项血常规指标数值（如C反应蛋白、中性粒细胞绝对值、血小板、血红蛋白、红细胞、白细胞等）和标准单位。
    - 当用户录入同一天同一时间（上午或下午视为不同时间）的指标时，新录入的数据将覆盖之前的记录。
    - 提供对某一次血常规结果数据进行单独修改的功能，允许更新或删除某一项指标。
2. **图片录入**
    - 支持病人上传血常规检查报告的图片，APP自动调用OCR工具识别图片中的内容。
    - 展示OCR识别结果供病人确认，病人确认无误后数据存入数据库；若识别结果有误，病人可手动修正。

#### 数据存储功能
1. **数据库记录**：将录入的血常规数据整理后记录到数据库中，数据结构应包含日期、时间、各项血常规指标数值及单位。
2. **数据安全**：对病人的血常规数据进行加密存储，确保数据库中的数据没有明文可读内容。加密算法建议采用行业常用的对称加密算法如AES（高级加密标准），以保障数据在存储过程中的安全性。

#### 图表展示功能
1. **趋势图展示**
    - 以趋势图形式展示血常规指标数据，用户可选择展示某一个指标的数值。
    - 图表横轴为按真实日期连续排列的日期，纵轴为指标对应的数值。
    - 在图表中展示每个指标的参考范围，根据数值低于或高于参考范围，对应点展示不同颜色，以便用户直观了解指标情况。
2. **可选功能（预留）**
    - 未来考虑支持其他类型的图表（如柱状图、饼图等）展示数据。
    - 支持对数据进行筛选，例如只展示某一段时间内的数据。
    - 支持同时对比多个指标的趋势图，以便更直观地观察数据之间的关系。

#### 多用户管理功能（预留）
预留多用户管理功能，为未来支持多个病人使用APP做准备，包括用户的注册、登录和数据隔离等功能。

省略...

在Lovable平台创建应用——选对工具，事半功倍

虽然作为开发者，手上有不少编程工具可以使用，我这次还是选择了Lovable平台，除了我恰好有会员外，还有几个因素也是比较重要的：

• 一站式的开发与发布平台，这样初期的开发与部署可以无缝衔接，不需要再额外考虑部署的问题。
• 结合Supabase等开放数据库，提供了多用户的认证以及可以方便地进行数据存储与管理。
• 它和GitHub的集成，可以方便地进行版本管理，以及未来若有必要，可以随时转到其它开发工具中继续开发。

和Lovable寒暄几句（你好）后便开始制造我们应用的初始版本，没一会，几个页面便出来了，整体雏形便有了。页面美观程度嘛，也还不错？ 但在和Lovable深入接触后（也就是真正开始开发），我有几点不太爽的感受：

• 它对于一些稍微复杂点的算法，就容易陷入死循环——反复修改，反复出错，简直让人头大。不知道啥时我居然和AI和编辑器生闷气：）比如我在想让趋势图支持多指标的选择相关功能时，在Lovable平台中反复好多次没有成功。我琢磨着是不是背后的模型还不够强大，在我切换到Cursor中启用Claude 3.5 Sonnet后很快搞定。
• 它对于指令的遵从还不错，但是缺少一些设计，有些人说用大模型开发容易搞出屎山，大概是这种感觉。并且它写代码是重复重写一个个文件，导致差异上我们也不容易看出来，虽然它经常有文件过大时的重构提示，但这显然治标不治本。
• 它的输出和修改还是过慢了，对于一些较小的修改，等的我有点忧伤，这不是我想要的"氛围"(Vibe Coding)。

这让我像一个渣男，打算"移情别恋"转投Cursor的怀抱。但更渣的是，我时不时还得回来蹭一下它的发布能力——毕竟人家有打通GitHub一键部署的神通。

在Cursor中精细化开发——真正的战斗才刚刚开始

我早前写过一篇Cursor的开发技巧及思考，感兴趣可以翻看过往文章，也可以在我博客找到：AI编程之Cursor使用技巧及一些思考。在Lovable那儿碰了几鼻子灰后，我不得不把代码克隆下来，开始进行“真刀真枪”的开发。

借助于Cursor，我们可以这样更有效的推进工作。为了让它知道我在干啥，也为了它不要反复乱改一些设定，我们先让Cursor通读一下整个项目，并生成Cursor rules。没一会就生成了好几个文件，看起来满满当当，也有模有样的，为了更好的使用，你可别全信，咱继续定制：

• 提炼最基础的原则，将它作为一个Always规则，使每次沟通可以带上。反正Cursor又不会基于Token计费（不过Max版本说会收费，你要更小心），这里规则三五百行是没问题的。注意上面默认生成的里面，一般是不会给你设定Always规则的。你每次得自己主动添加上相关文件，这对擅长遗忘的我们容易造成伤害。
• 删除不需要或模糊的规则。比如像这个工程我没打算让它写测试，所以测试相关说明可以删除。我也不喜欢它在做一件事后马上去更新文档（我还没确认最终是不是这个方案呢），所以文档的更新我也会限制。
• 添加一些新的规则。我发现现在AI真的有点智能了，居然学会偷懒！有时候一堆lint报错都没解决，就开始给我汇报工作成果了，这就想邀功？未免太早了吧，瞧您这干的啥事。于是我得给它上个"紧箍咒"，需要它每次提交时，先检查一下lint，确保没有问题。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# 业务逻辑和数据处理规范较

## 血常规数据管理

### 数据说明
本工程数据区分本地demo数据和数据库supabase存储的数据，它们完全隔离。
* 未登录用户使用的是本地demo数据。
* 登录用户使用其自身数据。

### 数据模型
参考类型定义：@types/blood-test.ts

#### 血常规指标
指标区分基础指标和其它指标。
* 基础指标的参考： @constants/basicIndicators.ts
* 全部指标定义在：@constants/indicators.ts

还有一些规则，我们要一边开发，根据AI的表现为它量身定制。比如我们已经npm run dev启动了项目，它每次提交完又想运行一次，你知道这显然不必，咱已经能动态热更新，所以得限制它。有时我们会沉迷于Vibe Coding的便捷，执着于像个甲方一样反复让它修改实现，就是不想思考如何优化规则，这时AI就会反复提醒你：）所以我感觉，在一个较复杂的项目上，想要快，必须得慢下来，琢磨一下如何去定义适合自己的规则。

在不断的调整和修改下，Cursor的月次数告急。我观察了一下Cursor的计数规则，它不是以你每次的交互多少来计数，而是差不多按完成一项工作来计算。于是假如你是想一出是一出，让它把东边修缮一下，西边再改改，那次数就哗哗的没了。可以考虑以一次将要修改的任务整理好，甚至一些关联的地方也提醒它注意修改，这样可以更充分的利用好次数。比如我这里的用药管理和手术管理经常是类似的逻辑，我就让它修改用药管理界面的A、B、C处，同时在手术管理中也需要类似的逻辑。这次只需要消耗一次计数，哗啦啦一大堆代码和功能就完善了。不过这招也别滥用，不建议一次性塞给它太多不相关的修改任务。我的经验是，把类似的功能打包一次性修改，独立的功能分开处理。改完一部分，自己确认没问题了就赶紧提交到版本库，免得一次改太多，到头来想挑挑拣拣哪些要哪些不要的时候，那叫一个尴尬！虽然Cursor和Cline等都有Checkpoint，其实都不好解决这个问题，我们得自己规范流程。

在使用Cursor过程中，过往我对模型的选择没有太在意，但这次我特意观察了一下，发现不同模型在Cursor中的表现还是有些差异的。比如在Cursor中，我试着用了一段时间那传说中被各大自媒体吹爆的Gemini 2.5 Pro，结果发现这家伙有点“高冷范儿”——思维链一开始还好好说中文，搞着搞着就中英混杂，甚至直接飙英文了，跟它沟通像在考六级。同时感觉它可能太过思维活跃了，动不动自我否定又来推敲一次，导致产出效率其实不高。而当我切换到Claude 3.5 Sonnet模型时，它甚至都表现更好一些，这或许和不少人的感知略有不同，我不确定是否Cursor未对它调教好（默认Prompt未能很好适配？）。但也不要迷恋Claude 3.5 Sonnet，在一次调整中，它也陷入了无尽的自我怀疑与纠结中，还是多花一倍代价（2x）切换到它哥（Claude 3.7 Sonnet）后问题很快得以解决。这告诉我一个道理，必要时启用最强大模型有时是更经济的事情。这个道理很快又被证明也不靠谱，因为没几天Claude 4 Sonnet出来了，号称更强大的编码能力，同时在Cursor中更便宜(0.5x)。我赶紧用上，没想到它似乎还是一匹没有驯服的野马，时有脱缰的时候。事后我在想为啥Cursor给这些优惠呢，在几天后费用升到0.75x时，它渐渐好了起来，或许前面就是鼓励我们使用，有足够数据偷偷调教呢？

借助MCP让代码感知DB——不再做知识的搬运工

我是在使用Lovable才知道有Supabase这个数据库的。最开始惊讶于原来居然可以在保障安全性的同时，不需要借助后端，前端直接就可以和DB交互。它借助了Postgresql的RLS机制，用户的权限被严格限制了。在开发期间，我有一次需要调整和迁移DB。最开始我频繁将DB Schema以及现有数据等截图贴给它，然后Cursor又为我生成一些SQL语句，说可以让我在Supabase平台SQL Editor中执行。我意识到这不是我想要的方式，作为一个现代化的BaaS服务（后端即服务），它也提供了mcp server，果断添加到Cursor中，然后就可以在Cursor中直接操作数据库了。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
    "mcpServers": {
      "supabase": {
        "command": "npx",
        "args": [
          "-y",
          "@supabase/mcp-server-supabase@latest",
          "--access-token",
          "<YOUR_SUPABASE_ACCESS_TOKEN>"
        ]
      }
    }
}

如下图，对于DB的修改及查询，甚至迁移等工作，都可以借助这个MCP工具完全在Cursor中完成，我终于不用当搬运工了。

专属网址——入口必须简单直接

整体网站的功能基本就绪后，要是想给其他人用，我寻思着得给它配个好记的网址才行。在NameCheap上找了一个并不太Cheap的com域名: blood-track.com。然后在Lovable平台直接绑定这个域名就可以通过新的自有域名访问啦。我看了一下，域名解析到了一个IPv4地址，应该是Lovable的接入层，因为我在平台登记了项目的自有域名，请求中header又有这个域名信息，故让Lovable路由到它所部署的代码实例上并不困难。

后续规划

开发的初衷嘛，主要是想解决自己记录、整理和洞察（或‘分析’）这些医疗数据时遇到的一些麻烦。因为所知有限，不一定适配于其它病种，虽然基础完备，但也有一些工作后续有空会继续考虑完善：

• 一些关键事件的记录与呈现。当前虽然有一些手术记录，但对于比如输血、输血小板等，或者感染事件，它也会引发血常规直接变化。
• 如果使用者变多，Supabase的免费Plan就不够使用了，而要每个月额外几十刀的话，可能自托管supabase或切换到其它DB都可能要提上议程。
• 多语言版本也可以考虑，如果有呼声的话（我怎么能听到这里的呼声）。
• 支持更多端，比如微信小程序或APP等。

本站提供的是公益免费的服务，域名、开发维护等成本较低，包括AI的识别等，整体花费不多暂时能够承担。（话说大模型识别一次检查数据费用不到一分钱，感谢这个时代。）

后记

如果你完整看完，不知道期间的感触你是否也有共鸣？如何在AI时代更高效的开发，这是现今乃至未来几年传统开发者都需要面临和思考的问题。 你可能有疑问为什么不开发一个微信小程序等，其实我也有此意。所以期间也尝试用全新的开发范式来建立微信小程序，比如从UI的设计开始，借助AI来设计交互图，然后我也试着回归VSCode + Cline看整体开发一个微信小程序的成本如何，初步完成一个Demo来看，成本尚可接受。未来有空会进一步聊一聊。有Cline后咱最新的模型或免费的渠道羊毛都可以褥一下，成本可能更低（注意也可能时间成本高得多）。

本篇文章就先到这里，感谢你的耐心阅读。期待未来有更多的成果和经验可以继续和你聊聊，欢迎一起交流探讨。这一块领域，全世界都还在探索，我们保持在路上。

我是个爱折腾技术的工程师，也乐于分享。欢迎点赞、关注、分享，更欢迎一起探讨技术问题，共同学习，共同进步。为了获得更及时的文章推送，欢迎关注我的公众号：爱折腾的风