活动报名表、签到表、物资清单各存各的——一次公益活动下来，数据散落在三个不同的地方。

一、公益活动的信息，总在三个地方各记各的

朋友在社区公益组织做协调工作。每次活动，她要做三件事：在群里发报名链接收集志愿者信息、活动当天拿纸质表让志愿者签到、活动结束后清点剩余物资手写登记。

这三件事互不关联。

活动前她不知道报名的人里到底谁能来，活动中她不知道物资够不够用，活动后她想统计总服务人数和志愿时长还得翻聊天记录。最让她头疼的是："报名人数 30 人，实际到场 18 人，中间差的 12 人去哪了——没人知道。"

我决定帮她做一个真正能跑起来的公益项目管理 Web 系统。核心目标是把活动创建→志愿者报名→确认→签到→物资管理→成果记录串在同一条管理链上，让每场活动可追溯。

注意：以下所有截图均来自真实运行的系统界面，非设计稿。

二、先看成品的首页：一张工作台看清全局

系统打开，最先看到登录，登录管理员账户就是工作台总览。顶部四个统计卡片——公益活动总数、注册志愿者数、已完成活动数、待确认报名人数——让活动负责人不用点进任何菜单就能知道今天的"待办缺口"在哪里。

左侧是即将开始的活动卡片。每张卡片显示活动日期、地点、报名进度和三种状态（报名数 / 确认数 / 签到数）。这个设计的意图很明确：把"报名"和"确认"分开。很多人报了名不代表一定会来，只有点了"确认"的志愿者才是真实可用的人力。

右侧是活动状态分布图和物资使用率圆环图。从分布能一眼看出当前有多少活动在招募、正在进行或已结束。物资圆环的百分比来自所有物资的加权使用率——这个数据不是为了好看，而是为了让物资管理员在活动前就能判断"库存够不够，需不需要补货"。

三、我把一次公益活动拆成了几个关键环节

系统设计了三个核心角色：活动负责人（创建活动、确认志愿者、记录成果）、志愿者（报名、签到）、物资管理员（物资出入库）。每一环都对应一个独立的页面：

活动管理：从创建到归档的完整生命周期

活动负责人进入"活动管理"页面，可以在四个筛选标签中切换——全部、招募中、进行中、已结束。筛选不是为了花哨，而是负责人的日常工作节奏通常是：先处理"进行中"的到场情况，再关注"招募中"的报名进展。

点击任意活动卡片打开详情弹窗。弹窗的底部是这个活动最核心的数据——报名志愿者列表。每位志愿者的状态用彩色徽章区分：待确认（蓝色）、已确认（绿色）、已签到（紫色）。负责人可以直接在弹窗里把志愿者从"待确认"改为"已确认"或直接签到。

这个设计的业务逻辑是：报名人数和到场人数从来不是一回事。把中间状态暴露出来，负责人才能判断是否还需要补招志愿者。

志愿者头像墙：名字背后是活生生的人

"志愿者管理"页面左侧是头像墙。每个头像用首字和不同的背景色区分——这个设计的出发点是：公益组织的志愿者很多是熟人，看到头像比看表格里的文字更容易定位到具体的人。

点击一个头像，右侧展示该志愿者的详细信息：联系方式、加入时间、参与活动次数、志愿时长、技能标签。页面的下半部分是志愿者数据表格，可以按姓名、电话、加入时间等字段快速浏览。

志愿者信息会沉淀到人才库页面。活动结束后，有意愿继续参与的志愿者自动进入人才库，下次活动可以直接从中邀请，不需要重新收集信息。这是为了防止"一次活动后志愿者就失联"的常见问题。

签到台：现场用的东西不能花哨

签到台是专门为活动现场设计的大按钮页面。左侧选择当前进行中的活动，中间展示实时签到数据——已签到 vs 待签到。右侧是签到操作区：搜索框和签到按钮。

签到按钮被刻意做得很大——因为在活动现场，操作人可能是拿着手机站在门口的工作人员，小按钮很容易点错。搜索功能支持按姓名快速过滤，找到志愿者后点击签到，状态会实时更新到工作台的进度数据中。

签到数据关联到活动和志愿者两个维度，活动结束后可以在"成果记录"页面看到最终到场人数和签到率。

物资台账：进度条比数字更直观

物资管理页面上方是总览圆环图，下方是每种物资的卡片：名称、总量、已用量、剩余量、进度条、最后更新时间。

选用进度条而非纯数字的原因：物资管理员在活动准备阶段需要快速判断"某样东西快用完了没有"。进度条的视觉判断比读数字快得多。出库时可以选择关联到某场活动——这样活动结束后可以复盘每场活动消耗了多少物资。

四、我把需求交到了飞算 JavaAI 的智能引导里

系统搭建过程用了飞算 JavaAI 的智能引导功能。在工作区中打开智能引导，输入了这段需求：

请帮我生成一个公益项目与志愿者管理 Web 应用。活动负责人可以创建公益活动、管理志愿者报名、确认与签到；物资管理员可以记录物资入库和出库；志愿者可以查看自己的参与记录。系统需要包含 10 个管理页面：Dashboard、活动管理、志愿者管理、签到台、物资管理、成果记录、人才库、数据分析、个人中心、登录注册。

智能引导把需求拆解成几个阶段来消化：

第一阶段：确认需求。 它反向问我角色定义、状态流转细节和权限边界。我补充了三个角色（活动负责人、志愿者、物资管理员）和活动状态机（招募中→进行中→已结束）。

第二阶段：实体与接口设计。 它自动梳理出核心实体（活动、志愿者、物资、签到记录）及其关联关系，生成了 RESTful API 接口定义。这一步我没怎么改——活动与志愿者的多对多关系是标准设计，它给出的方案就是最优解。

第三阶段：表结构 DDL。 针对每个实体生成了 MySQL 建表语句，自动加上了外键约束和索引建议。活动表的时间字段、志愿者表的技能标签字段都被它考虑到了。

第四阶段：生成计划。 它列出了即将生成的文件结构——路由、页面组件、状态管理、Mock 数据层。我确认了使用 Vue 3 + Vue Router + Pinia + 纯 CSS 的技术栈。

第五阶段：源码生成。 进度条从 0% 跑到 100%，大约 45 秒后全部源码生成完毕。项目可直接运行，首页登录后即可使用。

五、人机协作的思考

整个项目从零开始到可运行的前端工程，飞算 JavaAI 智能引导承担了约 70% 的骨架搭建工作：路由配置、页面基础布局、组件拆分、Mock 数据结构等。

剩下的 30% 需要我注入"灵魂"：

• 业务状态机的细化：报名→待确认→已确认→已签到，这个四态流转不是 AI 能自动推导的，它需要在设计阶段就把业务规则想清楚。

• 签到台的大按钮交互：AI 默认生成的签到按钮是标准尺寸，但在活动现场这个场景下，按钮必须显著醒目——这是我基于实际使用场景做的调整。

• 进度条代替数字：物资页面的展示方式，AI 给出的是表格，但我改成进度条卡片——因为对于现场快速浏览来说，进度条的视觉信息密度更高。

• 头像墙 + 人才库：公益组织的熟人协作特性决定了头像墙比表格更适合找志愿者，人才库的沉淀则是为了降低下次活动的招募成本——这些设计意图只有熟悉业务的人才能判断。

AI 是个极其高效的伙伴，但业务设计的出发点永远在人身上。

#飞算JavaAI炫技赛 #AI编程 #Java开发 #微服务 #程序员日常 #技术分享