先說在前面：這篇要講的冰箱便利貼任務板專案，到寫這篇文章為止都還沒做完，規劃階段的東西比實作階段多很多。但我覺得這個「還沒做完」的狀態剛好適合拿來聊——因為逆向學習這件事，很多時候不是等一個專案完成後才回頭看,而是在做的過程中，就一直被迫回頭確認自己到底懂不懂。

不是先寫程式，而是先寫規格

一般人想像的 vibe coding，大概是打開對話框、丟一句「幫我做一個任務分配系統」，程式碼就噴出來。但這次我第一步做的事情，是先把需求整理成一份規格文件：登入後可以建立或加入組別，任務版上大家自由認領任務，完成後賺取發布者設定的專屬點數，最後可以拿點數兌換那個成員設定的獎品（而且獎品還有庫存限制）。

這份規格我是先寫完，才開始讓 AI 動手的。回頭看，這其實是逆向學習的第一步：AI 能幫你把想法變成程式碼，但沒辦法幫你把模糊的想法變成清楚的邏輯。如果我沒先想清楚「認領任務」跟「賺點數」跟「兌換獎品」這三件事之間的關係，AI 生出來的東西再快，也只是一堆看起來能跑、但邏輯銜接不起來的片段。

技術選型：AI 能幫你接，不能幫你決定

技術上我選了 Vue 3＋Node/Express＋MongoDB，再加上 Socket.IO 做即時同步，第一版先用最單純的 email＋密碼登入。

老實講，這幾個名詞我都不陌生，用 AI 生過類似的程式碼也不是第一次。但「這個專案到底需不需要 Socket.IO」這個判斷，才是真正要補的東西——如果只是任務板偶爾更新一下狀態，其實用一般的 API 輪詢也能做到堪用的效果；但如果我希望組員之間認領任務的狀態能即時同步、不要有人搶了任務卻沒被別人看到，那就是 WebSocket 這種持續連線的機制比較合適。

這種「什麼情境該選什麼技術」的判斷力，AI 可以幫你把 Socket.IO 接好、事件寫好，但沒辦法幫你決定「這個專案值不值得引入這個複雜度」。這一段我自己是先想清楚原因，才開口讓 AI 動手接的。

連動畫場景都先想清楚才動手

這個專案我還規劃了一段冰箱開合的視覺效果：昏暗房間角落，冰箱門縫透出藍光，點擊後鏡頭 zoom in 聚焦到冰箱上層（便利貼貼在上層門），任務完成後冰箱門打開去兌換獎勵。連鏡頭視角、冰箱擺放方向（背靠左牆、上層門鉸鏈往右開）我都先畫好草圖、整理成規劃文件，才交給 AI 去實作。

這裡想誠實對照一下我自己之前做的另一個東西——之前做的 lofi 熱蠟燈動畫，是先讓 AI 把視覺效果做出來，流體力學跟浮力模擬的運算邏輯，我自己現在真要重寫一次，其實寫不出來。那是「先有結果、原理留到以後」的做法，效果好看，但底子是空的。這次冰箱門的動畫剛好相反：邏輯跟鏡頭語言我先想清楚，AI 只是負責把我想好的東西翻譯成程式碼。同樣都是「讓 AI 幫忙做視覺效果」，過程完全不一樣，學到的東西也完全不一樣。

所以逆向學習到底在學什麼

寫到這裡，我想把 vibe coding 重新定義一下：它不是「不懂裝懂讓 AI 生程式碼交差」，而是先確保自己懂需求、懂為什麼選這個技術，再讓 AI 加速把它做出來。AI 省下的是打字跟查語法的時間，省不下你理解跟規劃的時間——如果你想省的是後者，那多半是先跑得快、後面摔得更重。

這個專案目前還在推進中，之後應該還會因為 Socket.IO 的實作細節、或是動畫效果跟預期有落差，再回頭補一輪原理。而這種「先規劃清楚、再動手、動手時才發現哪裡沒想透」的過程，其實跟接下來要聊的 Vue ref 跟 reactive 是同一種精神——先把底層機制搞懂，才不會在真正要用的時候，只是照抄範例卻說不出為什麼。這部分留到明天繼續。