一、照护排班这件事，比想象中复杂得多

家里有老人接受社区照护的都知道，日常沟通基本靠三个群：家属群、护理员群、社区协调群。信息分散在不同人的聊天记录里，今天谁来、做了什么、下次什么时候——每个环节都可能掉链子。

我接触到阳光社区的实际需求时，发现他们服务着 8 位老人，配了 5 名护理员，每天的照护任务接近 30 项。排班表一直在用 Excel，谁请假了临时调班全靠打电话，服务记录写在纸质本子上，家属想了解情况得单独找社区问。

问题很具体：

• 排班全靠手工：每日任务分配跟着感觉走，护理员工作负荷不均；
• 服务过程不透明：家属看不到老人的实时照护情况；
• 异常响应滞后：漏服务、迟到的任务经常到下班才发现；
• 数据没有沉淀：老人的体征变化、服务完成率，全靠人工回想。
  我想做一个真正能用的照护排班系统。不只是把 Excel 搬到页面上，而是把"今天谁来服务"这件事管理起来。

二、照护管理需要几个角色视角

在动手之前，我先拆解了这个场景的参与者：

• 社区管理员：维护老人档案、分配护理员、查看整体运营状态；
• 护理员：查看每日任务、领取服务、记录完成情况；
• 家属：了解老人每日服务详情和健康状况。
  

每个角色的诉求不同。管理员关心"今天还有哪些任务没分配"，护理员想知道"我今天要做哪些事"，家属关注"老人今天状态怎么样"。

我把首页定调为"工作台"——管理员一打开就能看到今日服务总数、完成率、待分配任务和异常提醒。数字要清晰，颜色要分明，方便老年人家属和工作人员快速理解。

三、打开飞算 JavaAI，这次我没有自己写一行脚手架

确定好需求后，我打开飞算 JavaAI 的智能引导，输入了这样一段需求：

四、智能引导顺了五个步骤

第一步：确认需求

智能引导首先把需求拆解成清晰的结构：三个角色（管理员、护理员、家属）和对应的九大功能模块。它没有直接开始写代码，而是先让我确认"真的是这些功能吗"。这一步很关键——如果我想要的排班逻辑和它理解的不一样，在这里就能纠正。

第二步： API 设计

它给出了四个核心实体：老人档案（Elderly）、护理员（Caregiver）、服务排班（Schedule）、服务记录（ServiceRecord），以及配套的 CRUD 接口。这里我发现它默认把"照护等级"作为文本字段，我手动改为枚举类型（半自理/全护理/失智照护），让它后面直接生成带校验的代码。

第三步：表结构生成

DDL 生成得规整，主外键关系、索引都带了。让我意外的是它会自动给 schedule 表加上 slot（班次）字段，区分早中晚班——这说明它对照护排班的业务场景有基本理解。

第四步：生成计划一览

计划列出了 9 个页面组件、路由配置、Mock 数据层和样式文件。我看了一下结构和命名规范，都符合 Vue 3 组合式 API 的推荐做法，直接确认了。

第五步：代码生成

代码生成完成后，我没有直接把它部署到生产——AI 生成的骨架解决的是"从零到七八十"的问题，剩下的二十是业务细节和异常分支。

五、九大页面，构成完整的照护管理闭环

项目落地了 9 个菜单页面，覆盖了从建档到排班到追溯的完整链路：

项目落地了 9 个菜单页面，覆盖了从建档到排班到追溯的完整链路：

模块	页面	核心功能
🏡 工作台	Dashboard	今日服务统计、任务进度、异常摘要、在岗护理员
👴 老人档案	ElderlyList / Detail	档案卡片、照护计划、本周日历、服务记录
📋 照护计划	CarePlans	按照护等级配置每日任务清单
📅 排班日历	Schedule	今日任务列表、分配和完成操作
🧑‍⚕️ 护理员管理	Caregivers	资质证书、专长标签、工作量条
✅ 服务记录	ServiceRecords	服务归档与详情追溯
👥 家属看板	FamilyBoard	老人汇总看板、每日时间线、周报
🔔 异常提醒	Alerts	未分配/未完成/异常体征分Tab管理
📈 数据分析	Analysis	7天趋势图、类型分布、工作量统计

7天趋势图、类型分布、工作量统计

登录页

工作台

老人档案

排班日历

家属看板

数据分析

六、UI 设计的三个关键抉择

设计上我选了 Accessible Calm Green 风格——暖白底色搭配安宁绿主色，整套色彩体系都经过对比度检验：

1. 字号全线放大：正文 16px，标题 24px 起，统计数字 30px。相比常规后台的 14px 正文，这套字号对老年人家属更友好；
2. 高对比度语义色：完成绿 #2D9B4E、待分配橙 #E68A2E、紧急红 #C62828——三色对比度均在 WCAG AA 以上，不依赖颜色也能通过图标和文字理解状态；
3. 卡片化设计替代表格：老人档案和照护计划用卡片展示，减少密集表格带来的阅读疲劳。

七、人机协作的真正边界

这次实践让我再次确认对飞算 JavaAI 的定位：骨架交给 AI，灵魂留给自己。

AI 完成得好的部分：

• 项目脚手架（路由、布局、Store）的搭建，节约了大约 60% 的前置时间；

• CRUD 接口的 Mock 数据层生成，格式规整，命名一致；

• 前端组件的基础结构与事件绑定。
  需要人工深度介入的部分：

• 异常业务分支：比如"紧急异常卡片在前端高亮显示并置顶"，AI 不会自动区分严重程度和展示优先级；

• 数据关联逻辑：照护计划根据照护等级动态渲染不同的任务列表——这种多级关联需要手动调整 Mock 数据的组织方式；

• UI 质感调校：AI 生成的样式只是"能用"，距离"好读好用"还有距离。间距、字重、阴影深度、动画节奏——这些细节决定了产品是否真的有人用

八、做完之后，我对"照护数字化"有了新理解

这个系统没有做任何前沿技术：没有 AI 诊断、没有智能推荐、没有 IoT 对接。它就是解决一个很朴素的问题——照护安排需不需要有人负责，服务做完之后有没有留下记录，家属能不能看到结果。

但就是这些"朴素"的需求，在阳光社区是真实存在的痛点。当我把排班系统跑起来，看到家属看板上能实时显示老人今天接受的服务时间线时，我意识到：好的工具不是炫技，是把原本混乱的事情理清楚。

话题标签： #飞算JavaAI炫技赛 #AI编程 #Java开发 #社区养老 #照护管理 #技术分享