1. “星伴同行”是怎么立项的从一次课堂讨论到自闭症家庭干预痛点梳理1.1 选题来源为什么团队会盯上“家庭干预”这个场景“星伴同行”这个项目最初并不是一个站在讲台上被直接派发下来的题目。它来自山东大学软件学院创新实训的开题周——我们六个人围在一张桌子前翻着学院给的方向列表里面有智慧校园、数字孪生、工业视觉、大模型应用……看着都挺标准但总觉得缺了点什么。转折发生在一个组员的随口一提他在家乡社区做过志愿者接触过几个有孤独症谱系障碍ASD孩子的家庭。他提到一个细节——机构里的干预课排得很满但孩子一回到家家长就不知道今天该练什么、怎么练、练到什么程度算“做到位”。老师每周发一张Excel表有些家长会抄在纸上贴在冰箱上有些直接弄丢了。这个细节让我们停下了选方向的争论。孤独症自闭症的康复干预有一个业内共识叫“干预时长与密度很大程度上影响效果”。机构训练每周大概十到二十小时但真正能改变行为习惯的场景是家庭和日常生活。家长才是陪伴孩子时间最长的人但绝大多数家长没有接受过系统训练他们需要的不是一份“医学级方案”而是一个好用的工具能把专业干预目标拆成他们能执行的小步骤把执行过程记录下来再反馈给老师做调整。这就是“星伴同行”最初的雏形一个连接家长、孩子和干预老师三方的辅助工具。至于“星”这个字就是星星的孩子——ASD群体的常见称呼。“伴”和“同行”则代表我们想做的事不是提供一个诊断或治疗方案而是在家庭干预这条漫长的路上给家长一个陪伴性的、可执行的操作抓手。1.2 三个月调研里我们确认的四个关键痛点立项后的前两周我们没有写任何代码全力做调研。看了不少家长社群的帖子访谈了两位特教老师和三个有ASD孩子的家庭把他们的原话整理成需求卡片。最后收敛出四个高频痛点几乎决定后续所有功能设计第一个痛点是目标过于笼统。老师说“提升孩子的眼神对视能力”家长真的不知道怎么落地。什么叫提升每天做几次每次几秒孩子不看怎么办没有具体拆解目标就只是一句话。第二个痛点是记录靠回忆。很多家长不是不想记录而是干预过程本身就很消耗精力等孩子睡了再凭记忆补记录数据失真很严重。我们访谈的一位妈妈说她手机上存了三四百张照片全是孩子某个动作瞬间根本来不及整理成老师要的结构化数据。第三个痛点是家校信息断层。机构老师布置的居家任务家长执行完没有一个统一渠道反馈给老师。微信聊天记录里夹杂着语音、照片、Excel、备忘录老师复盘的时候要自己翻聊天记录效率极低。第四个痛点是家长容易焦虑甚至自疚。很多家长会因为孩子某个任务没完成直接怀疑是自己方法不对。他们需要的不只是“记录工具”还需要一些正向的提醒和引导告诉他们“这一步没完成也很正常明天换个方式再试”。这些痛点汇总下来我们的结论很清楚不能做“又一个打卡App”因为市面上的通用打卡工具无法表达干预目标的拆解层级和特殊场景。必须做一个围绕特定干预流程设计的工具把专业目标拆解成任务把任务执行变成记录把记录汇总成反馈。2. 产品定位三类用户、两个核心场景和一条红线2.1 用户角色矩阵孩子、家长、干预老师各要什么产品定位阶段我们画了一张用户角色矩阵把所有功能都挂到具体角色下凡是挂不上的功能一律砍掉。第一类角色是孩子严格来说他们不是操作者而是干预行为的接收者。在系统里孩子是一个档案主体存储基本信息、干预目标和历史记录。但我们坚决不做“给孩子打分排名”这类设计因为康复干预不是考试横向对比对家长毫无意义甚至会产生伤害。第二类角色是家长他们是主要操作者。家长端要解决三件事知道自己今天该做什么、做完之后如何快速记录、如何回顾孩子的变化趋势。家长端的所有交互都必须满足一个指标——单次打卡操作不超过30秒。我们实测过一个母亲在给孩子喂饭的中途能拿出的碎片时间非常短复杂的表单会直接杀死使用意愿。第三类角色是干预老师他们是专业侧的纠偏者。老师端负责制定干预目标、拆解成任务、分发给各个家庭、查看执行数据并给出反馈。老师需要看到的是汇总后的趋势和异常标记而不是流水账。这三类角色构成一个闭环老师拆任务家长做任务并记录数据回流给老师做调整。这也是“星伴同行”和普通打卡工具最大的差异——普通打卡工具只有“个人—待办—完成”的线性关系而我们是一个有专业角色的协作网络。2.2 核心场景A居家干预任务的拆解与执行居家干预任务拆解是整个产品最核心的场景。我们参考了实际干预课程中常用的目标分解法——把一个大的行为目标拆成可量化的分解步骤task analysis。举个例子“提升孩子听从两步指令的能力”这个目标可以拆成下面四个任务级别任务一孩子在听到“把杯子拿过来放在桌子上”后完成两个动作。任务二孩子在听到“先拍手再跺脚”后按顺序完成动作。任务三孩子在干扰环境下旁边有玩具仍能完成两步指令。任务四孩子在两步指令中加入一个不相关动作后能排除干扰、正确执行。每一步都包含指令文本、期望行为、辅助层级提示、重复次数建议。家长执行时不再面对“提升听从指令能力”这种悬空目标而是一个清晰的“今天做第几步、怎么操作、做到什么程度算成功”。老师端在创建任务时可以勾选辅助策略比如“语言提示”“手势提示”“身体辅助”“无辅助”。不同辅助层级代表不同程度的独立完成度这些数据最终会汇成一条辅助褪减曲线反映孩子越来越少依赖提示的变化过程。这一套逻辑并不算“高科技”但它非常专业。我们把它做成表单化的配置让老师不需要写文案只需要选择模板和参数一分钟就能生成一个家庭干预任务包。2.3 核心场景B行为数据的记录与复盘第二个核心场景围绕记录展开。行为记录不能做成一张空白的Excel表让家长自由填写那样既费时又无法结构化。我们的做法是“事件化记录”。一个记录事件由以下字段组成任务ID、执行日期、完成状态完成/未完成/部分完成、辅助层级、情绪状态平静/波动/抵触、备注文本框非必填。其中“情绪状态”这一个字段花费了团队不少讨论。最初有人提出做细粒度的情绪选择比如开心、兴奋、平静、烦躁、哭闹、抗拒等六种。但实际测试下来家长在执行过程中根本来不及精确判断情绪类型。最终我们压缩成三档平静、波动、抵触。三档足够描述执行任务的背景又不会让家长陷入选择困难。记录之后是复盘。我们用图表展示三类趋势任务完成率趋势、辅助层级变化趋势、情绪状态分布。这些图表从数据库里聚合出来直接展示在家长端的周报页和老师端的家庭详情页里。老师看完成率趋势可以看到任务是不是太难了看辅助层级变化可以看到孩子在提示减少的情况下是否仍能完成任务看情绪分布可以看到这个任务是不是已经引发了孩子的持续抵触需要调整目标。三个视角对应三种干预决策图表的维度设计不能多多了老师反而不知道看什么。2.4 一条红线我们不做诊断也不替代医生的治疗决策这个原则从立项第一天就写下贯穿整个开发过程星伴同行提供的是辅助记录和干预执行工具不做任何诊断、评估或治疗建议。原因很简单孤独症谱系的诊断和干预方案制定属于专业医疗行为需要具备相应资质的专业人员完成。一个学生实训项目如果在界面上写着“系统判断您的孩子可能存在XX倾向”那不仅不专业而且存在很大的安全风险。用户的信任感一旦被错误信息破坏整个工具就失去了价值。所以我们做了几个明确的设计收缩不出现“量表自测”功能AI辅助建议模块只基于行为数据做“执行建议”例如“该任务连续三天未完成建议老师考虑降低难度或更换强化物”而不是给出任何医学判断首页明确展示一句话声明“本应用仅用于干预任务的记录与协作不作为诊断依据。”这条红线也影响了我们后来的AI模块设计——我们只做“摘要”不做“结论”这样既体现了技术能力又牢牢守住安全边界。3. 技术选型与系统架构小团队六周跑通全栈的取舍3.1 为什么最终选了“小程序 Spring Boot MySQL”项目进入技术选型阶段时我们面临一个很现实的问题团队六个人其中四个人之前没有完整做过全栈项目实训周期只有六周。技术方案的复杂度必须匹配团队的平均水平而不是追求最热门或最前沿。前端选了微信小程序原生开发而不是Uniapp或Vue。原因是微信小程序在高校环境里安装门槛最低——家长扫个码就能用不需要单独下载App也绕过了iOS和Android双端打包的问题。原生开发虽然写起来代码量略多但团队里有两个同学对小程序开发比较熟坑少。后端选了Spring Boot MyBatis-Plus MySQL这是学院实训里最常见的组合。Spring Boot生态成熟安全认证可以用现成的Sa-Token或Spring Security集成MySQL存结构化数据完全够用MyBatis-Plus的代码生成器能快速把数据表映射成基础CRUD接口为我们省下大量时间。部署上没有上K8s或者Docker Compose就一台云服务器两个节点Nginx做反向代理Spring Boot的Jar包用systemd守护进程跑起来数据库直接装在服务器本机。这个部署方案谈不上高可用但对于一个日活预期几百人的实训项目来说简单可靠才是第一位的。选型过程中我们放弃了一个看起来很不错的方案小程序云开发。云开发自带云数据库、云存储和云函数理论上能大幅减少后端工作量。但我们的核心功能需要在多个表之间做复杂聚合查询老师端要按家庭维度查看多周趋势数据。云开发的数据库查询能力在这些场景下限制比较多最后还是回到了传统的关系型数据库。3.2 数据模型设计干预目标、任务、行为记录三张核心表数据模型是我们团队最早动手设计、也改版次数最多的部分。刚开始我们想得很简单——一个用户表、一个任务表、一个记录表结果画到权限关系时发现根本不够。第一版设计推倒重来后核心表结构收敛成三大块干预目标表training_goal记录老师为某个孩子制定的长期目标。关键字段包括goal_name目标名称、target_type目标类型如认知、语言、社交、运动、difficulty_level难度级别、status进行中/已完成/已暂停、creator_id老师ID。干预任务表training_task目标是可拆解的任务是可执行的。关键字段包括goal_id关联目标、task_name任务名称、instruction_text指令文本、expected_behavior期望行为描述、prompt_level辅助层级、repeat_count建议重复次数、schedule_type每日/每周X次、start_date和end_date。行为记录表behavior_record这是数据量最大、也是查询最频繁的表。关键字段包括task_id、child_id、record_date、completion_status完成/未完成/部分完成、prompt_used实际使用的辅助层级、emotion_status情绪三档、note文字备注。这三个表之间是明显的树形关系一个孩子有多个目标一个目标下有多个任务一个任务每天可以生成多条记录。权限设计上我们用了一个简单但有效的模型家庭family和班级class两层分组。孩子属于一个家庭家庭由家长账号绑定多个家庭可以被老师拉进一个班级老师查看班级下所有家庭的数据。这样设计的好处是老师批量管理多个家庭时不需要逐个授权只需要管理班级维度即可。3.3 AI辅助模块的轻量实现先规则引擎后大模型立项时学院鼓励使用大模型能力我们也希望在这个实训里接一接AI的边。但经过一轮讨论我们确定了实现顺序先用规则引擎跑通业务再接入大模型做增强。为什么不全指望大模型因为行为数据是结构化字段很多“建议”本质上是条件判断。比如“某个任务连续三天完成率低于50%”这个场景用规则引擎写一个判断条件五分钟就能实现结果稳定可控如果让大模型去读原始数据再给出自然语言建议每次调用的延迟、成本、不确定性都无法完全掌控。所以我们第一版实现了一个简单的规则引擎用Spring Boot里的配置类维护一组规则例如规则1完成率低于50%且连续天数≥3触发“任务难度调整建议”。规则2辅助层级连续5天为“身体辅助”触发“提示褪减建议”。规则3情绪状态为“抵触”的比例超过60%触发“强化物调整建议”。规则触发后系统会自动生成一段结构化提示文本推送给对应的干预老师。在规则引擎跑通之后我们才额外接了一层大模型API作为增强——把聚合后的数据摘要不是原始明细作为 Prompt 输入要求模型生成更适合家长阅读的安抚式执行建议。这个设计确保了模型即使输出不理想系统的核心能力也不会失效。4. 关键模块实现细节从原型到可演示版本4.1 干预目标拆解与任务打卡核心交互怎么设计的目标拆解界面我们做了三个层级首页是目标列表卡片式展示每个目标的进展状态。点进目标后看到任务列表每个任务标注了难度、建议辅助层级、今天的状态。界面最下面是一个大按钮“记录今日执行”。点击记录按钮后弹出的不是表单而是一串大标签按钮分三组排列。第一组是完成状态完成/部分完成/未完成第二组是实际辅助层级独立完成/语言提示/手势提示/身体辅助第三组是情绪状态平静/波动/抵触。家长不需要打字只需要点三下再决定要不要填备注。这套设计我们改了四版。第一版是普通表单一堆下拉框测试时家长反馈要花一分钟第二版改成滑块选择但滑块操作在手机上容易误触第三版改成单一按钮逐级确认点完完成状态再弹下一步仍然太繁琐最终版才是三组标签同时展示、三下点完、直接提交。提交后的数据写进behavior_record表同时根据日期更新目标详情页的趋势图缓存。由于查询频繁我们给behavior_record表加了(record_date, task_id)的联合索引并引入了Redis缓存热点家庭最近七天的聚合结果避免每次打开详情页都全表扫描。4.2 行为记录与可视化报表后端聚合怎么做最省力可视化报表是家长端和老师端共用的模块但我们给不同角色看了不同内容。家长端周报展示四项指标本周任务完成率、辅助层级褪减趋势、情绪分布饼图、连续执行天数。这四项指标回答家长最关心的四个问题孩子练了吗、独立了吗、状态如何、我坚持了吗。老师端家庭详情页则多两个维度近四周完成率对比柱状图、各目标类型的任务占比。老师可以快速发现哪些目标类型推进顺利、哪些长期停滞。聚合查询的实现我们用了MyBatis-Plus的LambdaQueryWrapper配合原生SQL统计。举一个例子查询某孩子最近7天每个任务的完成率SELECT task_id, COUNT(*) AS total_count, SUM(CASE WHEN completion_status COMPLETED THEN 1 ELSE 0 END) AS completed_count FROM behavior_record WHERE child_id #{childId} AND record_date BETWEEN #{startDate} AND #{endDate} GROUP BY task_id这段SQL的返回值直接映射到实体类再用Stream API做百分比计算和格式化成前端图表所需的JSON结构。前端用ECharts渲染折线图和饼图效果很直观。性能上面我们没有做太多优化因为数据量预期不大。但有一个坑必须提一下聚合查询的日期条件如果用字符串拼接很容易因时区问题导致边界数据漏掉我们最终统一用LocalDate传入并在数据库里将record_date设为DATE类型避免这个隐患。4.3 AI辅助建议模块的Prompt实践怎么让模型不跑偏AI辅助建议模块是整个项目里最有意思的部分。我们把规则引擎的输出作为数据摘要再通过Prompt让大模型生成家长可读的建议文案。核心Prompt设计经过了好几轮调整最终版本大概是这样的你是一名有多年家庭干预经验的特教辅助助理面向家长输出执行建议。 背景以下行为数据来自一个孤独症谱系儿童的家庭干预任务记录。 要求 1. 只基于给定的数据摘要进行总结不添加任何未经确认的结论。 2. 不输出医学诊断、不输出干预方案级别的建议只面向具体任务执行给出引导。 3. 语气温和、具体、可操作不使用恐吓或绝对化表述。 4. 输出不超过120字。 数据摘要{rules_output_summary}这个Prompt有几个小心思。第一我们用了“特教辅助助理”而不是“特教专家”或“医生”降低模型的权威性让它不会输出肯定式结论第二明确写着“不添加任何未经确认的结论”这是对抗大模型编造数据最有效的一句话第三限定120字以内防止模型输出长篇大论家长没时间读。实测下来模型生成的文案质量不错偶尔会有“建议家长带孩子去医院进一步检查”这样的表述我们直接在后端做了敏感词过滤把“医院”“诊断”“治疗”“正常孩子”等词纳入拦截列表一旦命中就退回规则引擎的原始文案。这里也分享一个实际操作中的体会大模型生成的自然语言确实让功能更具“人情味”但它不应该是唯一的输出路径。如果你做一个面向用户的工具一定要把规则引擎或兜底逻辑作为主干大模型只是基于主干的增强不然用户的体验就会变成抽奖——今天运气好AI说得挺准明天运气差AI胡言乱语。5. 实训过程中踩过的坑审核、同步与大模型降级5.1 小程序类目标签与隐私接口审核的麻烦小程序开发到第三周我们提交了第一个体验版结果在微信公众平台审核环节卡了近四天。第一次驳回原因是类目标签不符。我们注册时选了“教育-教育信息服务”但平台审核人员认为应用涉及儿童行为记录应该选择“医疗-康复辅助”类目。如果按照驳回建议修改类目就需要提交相应的资质证明学生团队根本没有。这个问题的处理过程比较曲折。我们先删掉了所有可能“沾医疗”的文案——把“行为干预辅助”改成“家庭学习记录工具”把“干预目标”改成“成长计划”把“康复记录”改成“成长记录”。同时调整了隐私保护指引明确说明收集的信息仅用于任务记录和数据展示不涉及医疗用途。第二次提交后通过了。这个经验值得所有做类似项目的小团队记住小程序审核不是技术测试而是一场“资质与文案的合规审核”。你的功能实际是什么样固然重要但页面上呈现给审核人员的第一印象更加重要。产品命名和关键文案要尽量避免跟医疗、诊断、治疗等词沾边尤其是没有相关资质的团队。5.2 离线打卡与多端数据一致性问题实训后期我们接到一位家长的真实反馈“有时候家里网络不好打卡一直转圈我就干脆不打了。”这个反馈直接触发了一个我们没有想清楚的问题——离线记录。一开始我们的设计是只有联网状态下才能提交行为记录。因为小程序端的网络环境受用户所处场景影响很大家里Wi-Fi不稳定、在户外带孩子时信号差都可能让打卡失败。这个问题不仅影响用户体验还会直接造成数据缺失影响老师端的趋势判断。最终的解决方案分两步。第一步在小程序端维护一个本地提交队列记录提交失败的任务存储成一个JSON数组存在本地缓存中。网络恢复后启动一个自动重试任务将队列中的数据逐条提交到后端。第二步后端接口需要保证幂等性防止重复提交。我们给每条记录生成一个UUID作为clientRecordId表中增加唯一索引重复提交时直接返回已存在的结果。这里必须提醒一下离线队列和幂等设计一定要一起做。如果只做离线队列不做幂等控制网络抖动时前端重试加上后端接收成功但响应超时会导致同一条行为记录被插入两次趋势图会出现莫名其妙的重复峰值。5.3 大模型接口不稳定时的三级降级策略大模型API调用是我们接入的最不稳定因素。高峰期单次调用可能要等5到10秒偶尔直接超时。如果把AI建议功能做成同步必选流程整个任务记录页都会被拖垮。我们设计了三级降级策略第一级正常时调用大模型API生成增强版建议文案 第二级当API超时或返回异常时直接展示规则引擎生成的模板文案 第三级当整个AI服务不可用时系统仍能正常完成记录与报表功能不返回任何建议。实现上调用大模型的逻辑被封装在一个带超时熔断的Service里。我们用了一个简单的手写熔断器——记录最近十次调用的成功率如果低于50%直接跳过调用不再请求大模型。这个手写实现只花了半天但效果非常稳定实训答辩时没有出现过一次AI卡死导致页面崩溃的情况。对于AI功能我有一个很实际的建议不要让AI成为“单点故障”。用户打开应用的目的可能是要快速记录一条任务如果因为AI接口卡了5秒他就再也不想打开这个应用了。所以所有的AI能力都应该被设计成“锦上添花”而不是“不可或缺”。6. 实训复盘从“做完”到“做对”的三个反思6.1 家长端与老师端的需求错位在实训临近结束时我们回访了参与试用的一户家庭发现一个此前完全没意识到的需求错位老师希望在任务详情里看到“数据复盘报告”但家长更需要的其实是“明天做什么”的清晰指引。老师把数据报表当成了分析工具家长把应用当成了“任务清单日记本”。这两个诉求没有谁对谁错但它暴露了一个产品设计的盲区——我们假设“数据记录完成之后家长自然会看趋势复盘”但真实的使用场景是家长每天打开应用的动力主要是“知道今天要做哪些事”而不是“分析上周完成率”。复盘是老师的事不是家长的天然诉求。如果有第二次迭代我们会在家长端把“趋势图表”弱化把“今天建议做哪几个任务”强化在首页直接用一句话告诉家长今天优先完成两个任务并结合近三天数据给出推荐顺序。不同角色的首页内容进一步差异化才能真正让三方各取所需。6.2 合规红线下的功能收缩不做什么比做什么更重要实训答辩的时候评委问了一个很尖锐的问题“你们的系统能不能根据历史记录预测孩子下一阶段的发展趋势”我们当时的回答是不能。这个问题我们也认真讨论过。从技术上用历史行为数据训练一个简单的时间序列模型去预测某个维度的改善概率并不是做不到。但“预测发展趋势”这五个字背后有太多风险预测结果一旦被家长误解为医疗评估或者被机构用来做不恰当的分班决策就会超出我们一个学生实训项目所能承担的责任边界。所以我们在项目文档里明确写了一条功能收缩原则任何涉及未来预测、对比排名、能力画像的功能一律不做。系统只提供“完成率”“辅助层级”等过程性数据摘要不做结论性输出。这个决定在当时让项目显得不那么“有技术含量”但从用户安全角度来说我至今认为这是整个项目里做得最正确的一个决策。6.3 后续扩展方向自然语言打卡与多机构协同如果这个项目要继续做下去我个人比较看好两个方向。第一个方向是自然语言打卡。有些家长反馈“点三下”也还是有点麻烦他们更习惯直接发一条语音说“今天带他做拍手跺脚辅助了一下完成了”。如果后续能接入语音转文字并用大模型把非结构化的家长描述自动转成结构化行为记录字段打卡门槛就会进一步降低。这个场景很实际而且比单纯加一个AI对话机器人更贴合真实使用习惯。第二个方向是多机构协同。目前一个老师只对应一个班级一个孩子只属于一个机构。但实际情况中很多孩子会在多个机构同时做干预不同的老师都想知道彼此做了哪些任务。做一个跨机构的任务互认和进度共享机制会大大减少重复训练和任务冲突。当然这也意味着要面对更复杂的数据权限问题不是短期能解决的。六周实训时间有限我们完整跑通了一个从痛点调研、需求确认、技术选型、系统开发、测试回访到复盘迭代的项目周期。我个人最大的感受是如果你做的事情能真正解决一个具体人群的具体问题哪怕产品规模很小写代码的过程也会踏实得多。星伴同行只是一个起点但它让我明白了软件工程中最重要的一个环节——先想清楚为谁做、为什么做再去写第一行代码。