药时铃：从 Web 原型到微信小程序，以及为什么停止产品化扩张

一次做出了原型，也做出了停止判断的项目。

药时铃最初想处理的是一个具体的家庭协同问题：居家老人需要看见今天的用药安排，完成后能够留下确认记录；异地子女希望了解计划是否被执行，并在出现漏服时得到提醒。

这个问题听起来可以直接拆成页面和接口，但医疗场景把每一个普通产品词都变得更严格。“提醒”是否可靠，“记录”能证明什么，“药品资料”从哪里来，“家庭协同”需要怎样的身份和授权，这些都不能只靠把功能写出来回答。

项目最终完成了 Web MVP、微信原生小程序和一套可运行的本地后端，也在复盘后停止了药品数据库、硬件和商业化扩张。保留它的意义，不是把原型包装成待上线产品，而是完整呈现工程实现与停止判断如何同时成立。

为什么先做 Web MVP

第一阶段选择 React + Vite，是为了尽快把老人端、子女端和后端数据流放进同一个可观察的界面。Express 提供 API，Prisma 管理数据模型，SQLite 让本地运行不需要额外数据库服务。

当时验证的流程包括：

演示用户与用药计划
  -> 老人查看今日用药
  -> 点击确认
  -> Express API 写入记录
  -> Prisma 持久化到本地 SQLite
  -> 子女端查看计划和状态
  -> 手动执行漏服检查

Web MVP 还包含药品库、详情、浏览器扫码、演示编号查询和 Web Speech API 播报。它证明了前端、后端和数据层可以组成一条完整演示链路，也让老人端与子女端的职责可以在开发早期被看见。

但这里的“完整”只指原型流程完整，不代表账号、医疗数据、提醒可靠性或线上运营已经完成。历史 Web 版本使用固定演示用户，本地 SQLite 也只适合单机环境。

React、Express、Prisma 和 SQLite 如何组成闭环

Web 前端负责呈现角色视角与操作入口，Express 把药品、计划、记录和预警拆成 JSON API，Prisma 则把这些概念落到明确的数据模型中：

• Medicine 保存演示药品资料。
• User 表达固定演示老人和子女角色。
• MedicationPlan 保存用药计划。
• MedicationRecord 保存用户确认操作。
• Alert 保存手动漏服检查产生的演示预警。

SQLite 降低了本地 MVP 的启动成本，适合验证关系和接口，但它没有解决多实例、访问隔离、加密、备份和数据删除等生产问题。确认记录也只表示用户按下了按钮，不能证明药物被真实服用，更不能证明剂量、时间或疗程正确。

这条闭环最有价值的地方，是让产品词汇对应到实际状态变化；它不能把一次前端点击升级成医疗事实。

为什么后来转向微信原生小程序

后续主要体验转向微信原生小程序，希望让移动端入口更贴近日常使用场景，也借此练习 WXML、WXSS、原生页面生命周期、wx.request 和 wx.scanCode。

小程序保留了：

• 今日用药与确认操作。
• 药箱、药品详情和本地搜索。
• 服药记录页面。
• 手动漏服检查与预警页面。
• 演示编号扫码和手动编号查询。
• 后端连接状态检查。

迁移并不是把 Web 功能逐页复制。历史 Web 中的子女计划管理没有进入当前小程序；浏览器语音也收缩为播报文本预览，没有形成完整语音播放。当前 canonical 运行主线因此是“微信原生小程序 + Express / Prisma 后端”，旧 React Web 前端只保留在本地历史归档。

哪些能力完成了，哪些只是演示

能力	当前状态	真实边界
Web 前后端闭环	历史 MVP 已完成	不属于当前 canonical 运行主线
微信原生小程序	原型页面与 API 契约已完成	未完成微信开发者工具编译验证
今日用药、药箱和记录	已完成原型流程	只使用虚构演示数据
确认记录	已完成	只代表点击确认，不证明真实服药
子女计划管理	只存在于历史 Web MVP	当前小程序没有该页面
漏服检查	手动触发演示	没有定时任务或真实消息推送
扫码查询	演示编号查询	不是正式药品识别、追溯或真伪验证
语音	Web 有浏览器播报，小程序为文本预览	不是完整语音提醒系统
账号与家庭绑定	仅固定演示角色	Basic Auth 和 Demo Token 不是真实认证体系
硬件	未实现	没有药盒、传感器、蓝牙、固件或 AIoT 设备

canonical 仓库建立后，后端在全新临时 SQLite 数据库中完成了 Prisma schema、三份 migration、虚构 seed、健康检查和必要演示流程验证；小程序完成了 JavaScript、JSON、页面路径、相对导入和 API 契约检查。项目没有自动化测试框架，本机也没有可用的微信开发者工具 CLI，因此不能把静态检查描述为真机或 IDE 编译通过。

药品资料库和扫码识药的合规边界

药品资料很容易让一个演示页面看起来像正式信息服务，但演示 seed 并不是经过药学专业审核的权威数据库。扫码功能也只是读取内部演示编号，再查询本地演示记录。

因此，公开材料必须把边界写在功能旁边：

• 不提供诊断、问诊、处方、剂量或个体化用药建议。
• 不替代医生、药师、药品说明书或医疗机构。
• 演示药品数据不是正式药品信息服务。
• 扫码不用于正式识别、追溯或真伪验证。
• 漏服检查不是可靠的实时健康预警。
• 不应输入真实姓名、手机号、病情、处方或用药记录。

这不是在功能完成后补一句免责声明，而是决定项目还能继续做什么、不能宣传什么的产品约束。

家庭协同方向为什么没有形成足够强的产品理由

复盘时需要把“问题存在”与“这个方案值得继续”分开。老人提醒、家人查看状态、计划管理和消息触达并不是独占能力，家庭健康管理、提醒工具和既有服务中已经有大量相近入口。仅仅把这些功能重新组合，并不足以证明一个新产品有明确替代价值。

这个项目也没有完成足以支撑扩张的用户验证：

• 没有建立稳定的目标用户渠道。
• 没有获得可持续、权威且可审核的药品数据资源。
• 没有验证家庭成员愿意长期维护计划和确认状态。
• 没有验证提醒、协同或数据服务能够形成清晰的付费理由。
• 没有完成系统竞品研究、正式用户访谈或付费实验。

因此，不能从“流程可以运行”推导出“用户会持续使用”，也不能从“家庭协同听起来重要”推导出“这个实现有足够差异”。这些产品假设没有充分成立。

为什么能做出来不等于值得继续做

继续开发当然还能增加很多东西：定时任务、微信订阅消息、更多药品资料、家庭邀请、账号权限、智能药盒和传感器。但每增加一层，责任也会扩大：提醒必须更可靠，身份与家庭关系需要授权，健康数据需要保护，药品信息需要专业来源，硬件还会带来供应链和售后问题。

这时继续堆功能会掩盖更早的问题：

1. 用户是否真的需要另一套入口。
2. 数据是否有合法、权威、持续的来源。
3. 提醒失败或记录错误时由谁承担责任。
4. 家庭协同是否有足够高频、明确的使用场景。
5. 用户为什么愿意迁移、持续维护甚至付费。

在这些问题没有答案时，技术可行性不能替代产品可行性。停止扩张不是否定已经完成的工程，而是拒绝把工程投入继续建立在未经验证的假设上。

为什么竞品、合规和用户验证应该更早

如果重新安排顺序，第一步不应是先补药品库或硬件，而是更早完成三类验证：

1. 竞品与替代方案：用户今天如何提醒和协同，现有工具已经解决了什么，真正空缺的环节在哪里。
2. 合规与责任边界：哪些数据可以展示，药品信息从哪里获得，提醒失败与误解会带来什么风险。
3. 用户与渠道：谁会持续使用，谁负责维护计划，如何触达老人和子女，是否存在足够明确的付费理由。

这些问题越晚回答，已经完成的页面、数据模型和设备设想越容易变成继续投入的惯性。原型仍然有价值，但它应该服务于验证，而不是成为必须继续扩张的理由。

为什么最终停止数据库、硬件和商业化扩张

最终没有继续把项目包装成正式药品数据库、实时健康预警或软硬件一体化成品，原因不是某一个接口无法实现，而是完整产品需要同时具备：

• 权威药品数据和专业审核。
• 正式账号、授权、家庭关系与隐私保护。
• 可靠定时任务、消息触达和异常处理。
• 数据加密、审计、备份和删除机制。
• 医疗合规、责任沟通与持续专业支持。
• 硬件设计、生产、连接、维护和售后能力。
• 经验证的用户渠道与商业理由。

当前项目不具备这些条件。于是范围被收缩到已经真实完成的部分，并明确不再继续产品化扩张。

为什么公开仓库使用全新 canonical 历史

公开前没有直接推送两个旧目录。新的 canonical 仓库从当前有效源码中重新筛选，只保留：

• 微信原生小程序的最新页面改动。
• Express 后端、Prisma schema 和 migration。
• 全新的虚构演示 seed。
• 架构、产品边界、开发演进和发布检查文档。
• 一张经过审计的 Web MVP 首页截图。

旧 Web 前端、旧 Git 历史、运行数据库、日志、构建产物、本地配置和旧运行记录都没有进入公开仓库。历史演示凭据在公开前已经失效并完成轮换；公开仓库与唯一的全新提交也完成了凭据扫描。

采用干净历史不是为了抹去开发过程，而是为了不给公开仓库继承无法安全确认的运行数据和敏感历史。开发演进保留在文档和复盘中，源码历史则从可审计的边界重新开始。

项目最终保留了什么

停止产品化扩张后，药时铃仍然保留了几类可以复用的经验：

• 用 React、Express、Prisma 和 SQLite 快速建立全栈流程原型。
• 把同一 API 契约迁移到微信原生小程序。
• 为适老化界面处理字号、状态、操作反馈和信息层级。
• 区分确认操作、健康事实和医疗建议。
• 用虚构 seed、忽略规则和本地配置隔离运行数据。
• 在公开前重建可审计的 canonical 仓库。
• 在技术可以继续推进时，依据合规、竞品和产品验证主动停止扩张。

它最终更像一个技术与产品判断案例，而不是一个等待上线的医疗产品。

下一次会如何调整顺序

下一次面对相似项目，我会把顺序调整为：

1. 先定义不能做和不能承诺的边界。
2. 先研究替代方案、目标用户和触达渠道。
3. 用访谈或低成本实验验证问题频率与维护意愿。
4. 确认数据来源、责任和合规要求。
5. 只实现最短的核心流程，不提前扩展资料库和硬件。
6. 在原型阶段就设计虚构数据、本地配置和公开仓库边界。
7. 根据验证结果决定继续、收缩或停止，而不是根据已投入代码量决定。

工程确实完成，产品假设没有充分成立，停止扩张是经过判断后的决定。这三件事可以同时为真。

项目详情、当前源码与完整边界可以从项目作品页继续查看。