一、摘要
本项目使用 React + TypeScript + Vite 从零构建了一个本地优先的医患沟通助手，解决患者就医咨询难、医生回复效率低的痛点。 AI 仅作为辅助工具，帮助医生分析紧急程度和润色回复语气，最终诊断和回复决策权始终在医生手中。
AI 伦理声明 : 本系统中 AI 仅辅助医生工作，不参与任何诊断、治疗建议。紧急程度分析仅供参考，最终判断由医生做出。AI 润色不改变医生回复的原意，仅调整语气风格。
二、背景
我是谁？
非计算机专业在校大学生，上一个帖子还是小说家，这次挑战全栈开发。
为什么做这个东西？
源于亲身经历吧，大家在医院也或多或少会经历类似找不到医生。病人有问题又不知道问谁的情况。
所有我就想到了这个。
病人给医生发消息，医生能够看到。医生看到后即使是随意简短的回复，也能成为病人的定心丸。
医患沟通中，医生时间紧张，回复往往简短生硬；患者焦虑等待，一句"术后疼痛正常"反而让人更不安。我想，如果AI能帮医生把"没问题"翻译成"请放心，这是恢复过程的一部分"，会不会让医患关系更温暖？
我觉得这是一件值得去做的有意义的事。所有我就做啦。
适用的工作场景:
小型诊所或社区医院，医生需要处理大量患者咨询，但现有沟通方式效率低。
主要的问题：
对于患者来说：不知道医生何时回复，紧急情况无法及时处理 快速得到专业回复
**对于医生来说：**重复性回答多，难以区分哪些需要紧急处理 高效处理，优先处理紧急情况
核心目标:
1.患者能快速发起咨询
2.医生能按紧急程度排序处理
3.AI 辅助判断紧急程度和润色回复
三、实践过程
第一步：
很简单，把自己的想法直接告诉solo，我们一起来深化场景。
Solo主动确认了一些关键结点，说明它有它的思考。
/spec模式下直接长任务生成文档，再执行文档，solo自己设计运行一会后就把最初版本端上来了。
Solo的步骤归纳如下：
1 任务拆解思路（患者端/医生端/数据层）
2 设计数据模型（IndexedDB 索引结构）
思路: 先确定数据结构，再设计界面。
3 第二步：实现数据层（IndexedDB）
思路: 使用 idb 库封装 IndexedDB 操作，支持用户的 by-phone 索引和消息的 by-sender/by-receiver 索引。
4 第三步：实现 AI 紧急程度分析
思路: 基于关键词匹配，判断消息是否包含紧急/心理相关词汇。
5 第四步：实现 AI 语气润色（三种风格）
思路: 在不改变原意的前提下，调整语气风格。
6 第五步：实现患者端
包括登录逻辑和发起咨询
7 第六步：实现医生端
主要是按紧急程度排序
第二步：让它告诉我怎么用。
对的
它直接就全部完成生成文件放在那里了，但是我不知道怎么用。
不得不说自己啥都不会，全让solo教。
干脆生成一键脚本了。
本人懒。
当然solo不是万能的，事情没有一帆风顺。
马上就是一大堆的问题。
四、问题与解决
问题一：路由问题
或者
或者
一打开是一片空白，换路径、刷新、重开，各种404。
这种情况出现了好多次
Solo在路由配置这块有待加强啊，当然因为多了角色切换、多端跳转，路由复杂度翻倍，反正我自己是肯定不会的，solo牛逼
所以忍无可忍，直接说“类似跳转出错问题已经发生很多次了。请反复测试后生成测试报告”，之后就没问题了。
至于怎么去调剂解决的办法就是：
简单粗暴，让kimi生成prompt，让ai生成的东西去调教solo。
Solo发现问题: React Router v6 使用 HashRouter，但跳转时页面空白。
原因: 没有正确配置 HashRouter 的 history 模式。
解决: 使用 createHashRouter 替代 createBrowserRouter，路径自动带 #。
其实我也看不懂，它说什么是什么吧，我只知道页面跳转和空白问题都解决了。
这个时候页面仅仅能够正常打开功能还没测试。
问题2：回答的太垃圾了，ai润色不好。
可以看到医生的简短回复，下图是润色后的回复。
“术后疼痛正常"润色成"我理解您的不适，术后疼痛正常，别担心。请安心休养，有问题随时联系我。”
看似长了，实则空洞。 患者要的是"为什么正常"“什么情况下不正常”，不是正确的废话。
润色后和没润色一样。还得医生自己修改。这肯定是无用又不靠谱的。
所以这个时候就有了两个方法。
方法一：优化本地模型来生成更人性化的回答。
方法一其实并不太现实，效果有限，但是我还是让kimi生成了prompt改动一次。
改动效果有区别也有成效：
不过依旧一坨，拉完了。
方法二：利用api调用大厂的模型。
还是让kimi发力。让它生成cn实现大模型调用功能的prompt。
关键设计：让 AI 润色成为可选模式，医生可自主选择本地模型或 API。
说明“这是一个可以选择的模式，是附加功能。可以选择使用大模型进行，也可以就按照原来的润色”
新加问题：
Solo完成后去测试发现了新问题：API"假装工作"
Api功能保存成功后。
Ai润色出现了同样的回复。
说明api没有成功调用。让kimi生成prompt继续调教。
这一步solo发现问题后也是自己解决了。
说的什么咱也不懂，就不贴图了。（设计我自己的密钥）
想了解我可以发在评论区。
再次生成回复有了明显变化。
问题3：患者登录后消息列表空白
此时患者已经发了消息，医生这边成功调用deepseek进行了回复和发送。
但是登录患者账号却一片空白，仿佛一切都没有发生。失忆了？
很明显错误，不但看不到自己发的历史记录，也看不到医生的回复。
排查过程:
还是先问kimi
得到prompt，solo去自己排查。
包括
检查 localStorage - 会话存储正常
检查 IndexedDB - 数据存在
检查查询逻辑 - 发现 getMessagesByUser 查询的是 by-receiver 索引
最终原因: 医生回复后，消息的 receiverId 仍是医生ID，患者用 by-receiver 查不到。
解决: 合并查询 by-sender（患者发的）和 by-receiver（应该改为患者接收的），并进行去重。并且优化了整个数据流。
五、成果展示
数据层 db/index.ts 用于IndexedDB 封装
AI 分析 ai/urgency.ts 用于紧急程度判断
AI 润色 ai/polishing.ts 用于语气风格调整
患者端 pages/patient/ 用于登录/咨询/查看
医生端 pages/doctor/ 用于列表/回复/润色
流程图展示：
0.选择自己的角色（实际场景中这一步意义不大）
1.患者登录：
这里用的是2号病人，李阿姨。
2.病人发起咨询
3.描述问题，提交医生
4.退回页面，能看到更新的历史记录
切换到医生端
5.登录医生界面后
发现多条未回复和已回复内容。
其中就有2号病人李阿姨的消息。
6.1回复病患李阿姨
下图是调用deepseek的过程和结果。
6.2下图是调用本地模型的回复
依旧拉完了
7.回复发送回到消息界面，李阿姨的状态更新，显示以回复。
切回患者端
8.最后回到患者李阿姨
可以看到正常收到回复，而且已经回复和还没被回复的消息有了绿色标点区分。
9.点开消息查看回复
至此流程全部完成。
六、效果与总结
SOLO 作用:
1.从零设计数据模型和架构
2.封装 IndexedDB 操作
3.实现 AI 关键词匹配和语气润色
4.解决路由、数据关联、账号复用等问题
5.伦理边界，自动在代码中添加 AI 辅助声明和约束
可复用方法:
1.本地优先架构: IndexedDB + localStorage，适合离线优先的轻量应用
2.AI 紧急分类: 关键词匹配可复用到客服、工单等场景
3.语气润色: 三种风格模板可扩展
下一步优化方向:
添加消息推送提醒
支持语音输入
最后的最后我想说：
这个作品，我想为真实的医患关系做一点小事。
技术不复杂，但场景真实。
如果能让医生的回复少一分冰冷，多一分温度，这20分钟就值得。
但我也清楚，目前的版本放在真实医院里，还远远不够。
1.现在只是本地网页，localhost运行，但是真实场景需要微信小程序或App，患者扫码即用，我不会小程序开发，没申请过资质。
2.现在单机存储，数据在浏览器，真实场景需要云端数据库，多设备同步，病历关联，但我没做过服务器部署，不懂数据安全合规。
3.现在是模拟医生账号登录，但是真实场景是对接医院HIS系统，实名认证，处方权限，我完全没接触过医院信息化，也没有对接医院的实力。
4.现在AI润色是"玩具"级别，但是真实场景医疗AI需要药监局审批，责任界定清晰，我不懂医疗法规，不敢越界。
所以这个项目，我更想分享的是想法和思路——
1.医患沟通的温度，可以来自AI的语气润色，而非更贵的设备
2.本地优先+AI辅助，是小团队也能尝试的技术路径
3.非计算机专业的人，用SOLO也能把想法跑起来
至于小程序开发、医院对接、医疗合规、规模化运营……这些都超出了我一个在校大学生的能力。
如果有开发者、产品经理、医疗从业者看到这里，觉得方向有价值，欢迎继续优化和投入使用。代码开源，思路共享，就当是我抛砖引玉。
如果这个东西真的真的能够实现，还请勿忘我。
“自有后来人”