SESSION 01 · 08/01
真问题定义：从自己的烦开始
💬 小宇原话：「每次去汉口接我妈，都要现场查半天，查出来的时间还不准。」
立项课的标准问题：「你最近一次觉得什么东西特别不顺手？」小宇写下了通勤查询。讨论后把范围收窄到他自己最熟的 2 号线沿线——「做一个我自己每天真的会用的东西」。
问题定义真实需求
🌱 成长证据：理解了好工具的第一性原理——解决自己的真问题。
SESSION 02 · 08/05
用户调研：样本量 = 1，但很深
💬 小宇原话：「我爸的答案居然和我不一样——他嫌走路多，我嫌换乘多。」
采访了两位「用户」：自己和爸爸。发现两个人对「最快」的定义不同：小宇要总时间最短，爸爸要「少走路的换乘」。于是定下产品规则：结果页同时显示总时间和换乘次数。
用户思维需求分析
🌱 成长证据：两个用户就发现了需求分歧——样本小不代表没洞察。
SESSION 03 · 08/08
线路数据整理：把武汉装进一张表
💬 小宇原话：「原来数据是这样来的——不是 AI 变出来的，是人先整理好的。」
整理 2 号线、4 号线主要站点和换乘关系，做成结构化数据。小宇第一次理解「数据结构」这个词：站是点、线是列表、换乘站是特殊的点。AI 帮他把表变成了代码，但表是他自己填的。
数据意识信息结构化
🌱 成长证据：明白了 AI 的「聪明」需要人喂给它的结构化信息。
SESSION 04 · 08/12
换乘算法：想清楚再让 AI 写
💬 小宇原话：「我给 AI 讲了我的想法，它一次就写对了——因为我先在纸上画了图。」
小宇在纸上画了站点关系图，想清楚「同线直达 / 跨线找换乘」两种情况，然后把逻辑讲给 AI 听，AI 写出查询函数。这节课的结论被小宇自己总结成一句话：「我先想清楚，它就写得好」。
逻辑思维人机协作
🌱 成长证据：体会到了「清晰的表达 = 高质量的人机协作」。
SESSION 05 · 08/15
界面草图：三个盒子
💬 小宇原话：「我奶奶会用微信——那这个就得让我奶奶也能看懂。」
画界面草图：起点、终点、按钮，三个盒子，结果页一句话方案 + 时间。小宇提出的验收标准是「奶奶能看懂」——他自己发明了「无障碍验收」而不自知。
设计易用性
🌱 成长证据：把「简单」当成了设计目标，而不是功能堆砌。
SESSION 06 · 08/19
和 AI 建构：一周从草图到能跑
💬 小宇原话：「它写得比我快一百倍，但我说错一个站名它就全错了。」
集中建构课。小宇负责说需求、验收每一步（「这个站名写错了」「按钮要绿色」），AI 负责实现。他总结出的协作心得：「AI 快，但要求我准」——这是整个项目最重要的一句话。
工程思维人机协作
🌱 成长证据：建立了「我说得越准，它做得越好」的工作方式。
SESSION 07 · 08/22
步行时间修正：数据要跟现实对齐
💬 小宇原话：「换乘不只是换辆车，还要走好远！地图 App 都没算这段。」
实测发现换乘站的步行时间被低估了。小宇给每个换乘站加上步行分钟数，还按「带行李 / 不带行李」做了两档。他开始理解：数据不是整理完就完了，要跟现实持续对齐。
数据校准实证精神
🌱 成长证据：从「做出来」进阶到「做得准」。
SESSION 08 · 08/26
爸爸实测：第二个用户上线
💬 爸爸的反馈：「时间比地图还准一次——因为你们算了我不爱走的那个换乘。」
请爸爸连续三天用这个工具通勤。反馈非常具体：换乘提示要在出门前提醒、字体要大。小宇逐条迭代，还加了一个「到站提醒」的备忘功能。第一次体验到「用户持续使用」带来的迭代节奏。
用户思维迭代
🌱 成长证据：从一次性交付转向了持续服务的视角。
SESSION 09 · 08/29
边界情况：如果两个站是同一个呢
💬 小宇原话：「我把起点终点选成一样的，它居然还真给我出了个方案——走 0 分钟。」
边界情况大扫除：同站出发、线路停运、不存在的站名。小宇列了一张「奇怪情况清单」逐条测试修复。他说这节课像「抓 bug 的侦探游戏」。
工程思维边界分析
🌱 成长证据：学会了主动「找茬」自己的产品，而不是等用户发现。
SESSION 10 · 09/02
路演：一个真用户的产品演讲
💬 小宇原话：「它的日活是 2——我和我爸。但我们的满意度是 100%。」
结营路演，小宇演示了完整流程，并公布了那句全场鼓掌的「日活 2、满意度 100%」。作品页发布。他给下一版定的目标：「把 4 号线加进来，让第三个用户上车」。
路演发布
🌱 成长证据：能幽默而准确地定义自己产品的成功标准。