从真实需求开始：先访谈，别写代码
好项目先问“谁头疼”。下面用一个自拟的“晚自习任务排序助手”作为贯穿示例：几个同学最初想做一个“手机存放提醒”，访谈后才发现，大家最烦的是“回座位后不知道先做哪科作业”。于是项目改为用简单规则帮同学排任务顺序。
访谈就问5个问题：你每天哪段学习最乱？那时你会做什么选择？上次失误是什么？如果系统帮你决定，你信吗？你最讨厌被提醒什么？记原话，不要改成自己的想法。访谈人数不必多，可以先从三到五位同学开始，小样本只用于发现初步问题，不能代表所有学生，但每人要聊到具体事件，比如“上周二晚上我背了单词，结果第二天数学作业没写完”。
最小原型：先做会犯错的版本
原型不必追求完美。以“任务排序助手”为例，最小版本只做三件事：输入任务名称、截止时间和预计时长；按“截止越近越优先”输出序列；允许手动拖拽调整。用Excel表格或几十行Python脚本都能实现，不需要接入生成式AI。
把这个原型给自己和两位同学用三天，记录他们实际调整了几次。调整次数是最宝贵的数据：被调整越多，说明规则越脱离真实场景。如果同学每次都把“琐事”移到最后，就说明“截止时间”单一规则并不好用。
再判断AI适合做哪一步
规则原型能工作后，再考虑是否需要AI。例如，可尝试把“周五前交英语作文”这样的自然语言转成任务名称和截止时间。先用自己编写的测试语句比较提取结果，遇到“下周”等模糊表达，应要求用户确认，不能让系统自行编造日期。测试时使用虚构任务，避免上传他人的个人信息。
用测试集暴露失败：别只展示成功案例
给原型准备20个测试场景，每个都写明“输入、期望输出、实际输出”。比如“数学作业明早交、英语单词后天考、体育打卡还有三天”，期望输出把数学作业放第一。但规则如果只看截止时间，可能把三件连续作业都排在一起，没有体现“是否需要整块时间”。
典型失败案例：期末五个任务都写着“下周截止”，规则按预计时长从大到小排，把小论文放首位，但某位使用者更希望先完成一个短任务。把分歧写进文档，让用户选择是否优先处理短任务，并保留手动调整。不能假定所有人的最佳顺序相同。测试集不是证明正确，而是逼你自己说出“它会在哪里错”。
隐私、边界与迭代路演
凡是记录同学学习行为的功能，默认不收集姓名和班级，只给随机编号。若需要对比“使用前后的任务完成率”，就在表单里写清楚“数据只用于改进工具，不用于任何评价”，并且允许任何人随时退出。不要在同学不知情时截屏他们的输入。
技术边界要写进项目说明：工具只提供建议，最终决定由人来做；不做“预测谁考得好”这类可能伤害自尊的项目。路演不要念PPT，让同学现场输入真实任务，看输出是否被接受。记录“哪一步被质疑”，那就是下一次访谈的问题。
循环三到四轮：访谈、原型、测试集、路演，每轮只改一个变量，不要同时换算法和界面。持续记录哪些建议被采用、哪些被拒绝，才能判断这个工具是否解决了最初的问题。
