有一类事情，单独看并不复杂，却总是很容易被忘掉：孩子这周上了几次课？下节课是什么时候？上次到底是请假了，还是只是没有记录？
家里课程一多，信息就会散落在聊天记录、备忘录、课程卡片和家长的记忆里。真正需要它的时候，往往不是坐在电脑前整理，而是在出门前、接孩子时，临时想确认一个答案。
所以我做了一个小程序，叫“课校记”。它不是想把家庭管理做成一套复杂系统，而是先解决一个很具体的问题：让家里每个人都能快速知道课程安排，也能把每一次上课结果留下来。
打开首页，先知道今天和本周要处理什么
课校记的家庭首页把日期、本周安排、最近记录和课程概览放在一起。打开之后，家长可以先看到下一节课、最近发生了什么，以及每门课程还剩多少次，不需要在聊天记录和备忘录之间来回查找。
首页的重点不是展示尽可能多的信息，而是让“现在最需要处理的事”先出现。课程很多时，清晰的层级比功能数量更重要。
点进一门课，安排、余额和最近记录都在一起
进入具体课程后，可以看到课程的上课安排、当前剩余次数、累计缴费和最近记课记录。以古筝课程为例，课程主页把“记一次”和“余额管理”放在最容易找到的位置，下面再展开课程设置和历史记录。
这让一次日常操作变得很直接：刚上完课可以记课，想确认还剩多少次可以直接看余额，需要续费时也能从同一门课程进入缴费记录。
先看全貌：课程记录是不是一眼能看懂
只知道“今天有课”还不够。过一段时间之后，家长通常还会想知道：这个月实际上上了多少次？某次课程是什么结果？临时调整过的安排有没有留下痕迹？
课校记把课程记录做成按时间回看的记录流，并把已上课、请假、取消等结果区分开。当前页面可以看到历史记录总数、不同结果的数量，也可以按月份和课程筛选。它的价值不在于记录越多越好，而在于需要回看的时候，能够快速找到那一次发生了什么。
记一次课程，尽量不要打断当下的节奏
很多记录工具的问题不是没有功能，而是记录动作太重。课校记把一次记课压缩成几个清晰的选择：课程、实际时间、结果、扣几次课时，以及可选备注。
这样，临时加课、补记或者刚下课时，都可以快速留下记录。AI 在开发时可以帮我补齐表单和校验，但“哪些字段必须有、哪些字段可以选填”，还是要回到真实使用场景里判断。
一条记录，为什么还要有详情页
一条历史记录不应该只是一个列表上的标题。需要核对时，用户还要知道课程名称、实际发生时间、扣减次数和记录人；如果后续做过调整，也应该能看出变化。
记录详情页把这些信息集中放在一起，并保留更正和删除记录的入口。对家庭管理来说，这种“能回头看清楚”的能力很重要：它减少了重复询问，也让课程次数的变化有迹可循。
课时和缴费，别再混在聊天里
课程管理还有一个很现实的部分：剩余多少课时、什么时候续费、买了多少次、赠送了多少次。过去这些信息很容易和转账截图、聊天消息混在一起，过一段时间就很难确认。
课时余额页先把当前剩余次数放到最醒目的位置，再把补充次数和校准余额分开。用户不必翻找历史消息，就能先回答“还剩几次课”。
新增缴费页面则记录实付金额、缴费日期、购买课时和赠送课时，并明确这笔缴费是否计入当前余额。它不试图替代支付平台，而是把家庭真正关心的课程资产留下来。
家庭记录，不能只依赖一个人
课程信息通常不是一个人的事情。接送孩子的人、负责报名的人、临时需要查看安排的家人，都可能需要知道同一份信息。课校记把家庭作为共同记录的空间，让成员可以围绕同一个家庭查看课程和处理记录。
在“我的”页面，可以看到当前家庭和成员协作的概览，也可以继续进入家庭成员、提醒与记课、个人资料和反馈等功能。共同记录不应该要求每个人都学习一套复杂系统，而是让大家围绕同一份课程信息协作。
我是怎样用 AI 把它做出来的
这次开发最有意思的地方，不只是“用了 AI 写代码”，而是我逐渐把 AI 当成了一个可以反复对话的开发搭档。
第一阶段：先把模糊想法变成可判断的问题
一开始我只有一个很朴素的想法：把家里的课程管起来。但这句话不能直接指导开发。于是我和 AI 先把它拆成具体场景：谁会使用？什么时候打开？最常查看什么？哪些结果必须由人确认？哪些信息适合放在首页？
这个阶段 AI 的帮助主要是补充视角、整理问题和比较方案。真正的取舍仍然由我来做。比如，家庭成员、提醒、课程记录都可以继续扩展，但第一版必须先让“查看安排”和“完成记课”顺畅起来。
第二阶段：让界面围绕使用场景组织
有了场景之后，我让 AI 协助把页面结构、文案和交互状态整理出来，再逐步落成小程序界面。这里最容易踩的坑，是只关注“页面有没有”，却忽略了“状态是否说得清”。
同一个课程，可能处于进行中、待确认、已上课、请假或取消。AI 可以很快生成页面和状态的初稿，但每个状态是否符合真实使用，必须结合具体流程逐个检查。
第三阶段：让 AI 加速实现，而不是替我做产品决定
在编码过程中，AI 很适合处理重复性工作：根据已有结构补齐页面、整理样式、生成基础逻辑、解释报错，并根据明确的修改要求快速迭代。
但“看起来能运行”和“真的适合使用”是两回事。一个按钮放错位置、一个返回路径不自然、一个状态提示含糊，都会让用户在真实操作中犹豫。于是我会把每次修改拆成小目标，让 AI 改一件事，再立刻回到实际界面检查结果。
第四阶段：用真实界面做验收
开发不能只看代码和静态截图。我会在微信开发工具和体验版里实际打开页面，点击、返回、切换底部导航，检查不同状态下的文字和布局，再把问题描述成可复现的现象交给 AI。
这种方式很像和一个速度很快的工程师一起工作：AI 负责快速提出和实现修改，我负责判断问题是否真的解决，是否引入了新的问题，以及这个功能是否仍然符合最初的使用场景。
第五阶段：把“能用”留给用户，把“该不该做”留给自己
AI 让开发速度变快了，却没有消除产品判断。相反，反馈来得越快，越需要保持边界感：哪些建议值得采纳，哪些功能应该延后，哪些细节虽然技术上能实现，但会让产品变得更复杂。
课校记目前还是体验版。它已经可以用来验证家庭课程查看、记录、待确认和提醒这些核心流程，但我不会把体验版包装成一个已经被大量用户验证的成熟产品。接下来更重要的事情，是继续观察真实使用时哪里仍然麻烦，再决定是否扩展功能。
这次开发给我的一个结论
用 AI 开发产品，真正的效率提升不只是少写一些代码，而是把“想法—方案—实现—验证”的循环缩短了。你可以更快做出一个版本，也可以更快发现它哪里不对。
但循环变快之后，人的作用并没有变小。需求边界、用户价值、取舍和最终验收，仍然需要有人负责。AI 更像一台很强的加速器，方向盘依然在开发者手里。
如果你也遇到过家庭课程难记录、难回看、容易漏确认的问题，可以关注课校记后续的体验和更新。当前体验版入口以实际发布的小程序码和体验资格为准：
这篇文章里的界面截图来自当前体验版，按实际界面展示产品功能；文章仍然省略了内部配置、凭据和服务细节，只保留产品体验与开发方法。