Day 1 我把 Visual Learning Lab 的方向定下來，也先畫了一個很陽春的首頁草圖。今天的目標很單純：不接 GPT、不處理 PDF、不做 3D，只先讓這個東西真的跑起來。

昨天的草圖大概只有「上傳 PDF、貼文字、按 Visualize」這幾個元素，本來我只是想先留一個畫面概念。結果今天把需求丟給 Codex 之後，它直接幫我用 Streamlit 做出第一版介面。

老實說，這也是我這次鐵人賽想玩的方式。以前如果我要做網站，我可能會先去找 Streamlit 教學、研究 Python 怎麼寫、再慢慢搞懂每個元件。但這次我想反過來：我先告訴 AI 我要什麼，再看它能不能把東西做出來，之後我再負責判斷要不要改。

今天我給 Codex 的需求其實很簡單：做一個 Visual Learning Lab 的首頁，包含 PDF 上傳、文字輸入、Visualize 按鈕，再把未來預計要做的六種能力先放到頁面上：Concept Map、Flow、Analogies、Image Breakdown、3D / Motion，以及 Source Check。

前五個功能原本就在規劃裡，但 Source Check 是今天才正式被加進產品的。

昨天文章底下有人留言問了一個我覺得很重要的問題：

把教材變成概念圖和互動內容確實比摘要器有辨識度，但如果視覺化變得很好懂，卻在簡化過程中偷偷錯了，要怎麼抓？每個節點是不是應該能回到 PDF 原始段落？

這個問題我原本其實沒有想得這麼深。我一直在想怎麼讓教材變得「更好懂」，卻沒有注意到另外一件事：如果 AI 把內容簡化錯了，而且畫面又做得很漂亮，使用者反而可能更容易直接相信它。

所以今天我決定把這件事直接變成產品功能，而不是只把它當成一句提醒。

目前的想法是，未來每個重要概念、節點或 AI 產生的解釋，都盡量保留來源資訊。使用者點下去之後，可以回到原始 PDF 對應的頁面或段落，確認這個視覺化到底是從哪裡來的。後面如果做得到，也會再加一層內容查核，讓 AI 產生的簡化說明重新跟原文做比對。

所以我在 PRODUCT_VISION.md 裡多加了一條：

<視覺化不能切斷內容與原始資料的關係；重要結論應該可以追溯來源>

這也讓我第一次覺得，這個工具或許真的可以慢慢長出一些不只是「GPT 外殼」的東西。

今天實作的部分倒是比想像中快。Codex 幫我產生了 app.py 和 requirements.txt，接著我把它下載到電腦，用 Streamlit 跑起來。

中間當然還是有翻車。

我第一次下指令時，Windows 直接跟我說找不到 Python；裝好 Python 後又出現找不到 requirements.txt，最後才發現只是因為我在錯的資料夾執行指令。Streamlit 裝好後，再跑：

python -m streamlit run app.py

瀏覽器終於第一次真的打開了 Visual Learning Lab。

目前的首頁已經可以看到 PDF 上傳區、文字輸入框、Visualize 按鈕，下面也先把未來六種視覺化能力做成卡片。當然現在全部都還只是外殼，按下 Visualize 只會出現「之後會加入視覺化功能」的提示，AI 還完全沒有接進去。

但我還滿喜歡現在這個狀態。

Day 1 它只是一個文字草圖，Day 2 它至少已經變成一個真的可以打開、可以按、可以上傳檔案的介面。

而且今天我第一次比較明確感受到 Vibe Coding 跟我原本想做的「學程式 30 天」差在哪裡。今天我完全沒有先去學 Streamlit 的語法，也沒有逐行研究 Codex 寫的程式，而是把注意力放在產品本身：首頁要長什麼樣、哪些功能應該出現、哪個問題值得加進 Product Vision。

這次我比較想知道的，不是「我今天學會多少 Python」，而是「今天這個產品多了什麼」。

Day 2 的答案是：它第一次出現在螢幕上，而且多了一個我一開始完全沒有想到的功能——Source Check。

明天開始，就要讓它第一次真的有腦了。

Day 3 的目標是把 GPT 接進 Visual Learning Lab。先不碰 PDF，只從最簡單的文字開始：使用者貼一段內容，按下 Visualize，GPT 要真的分析它，找出核心概念、關係，並開始告訴系統這份內容適合怎麼被視覺化。

到時候就會第一次從「漂亮的空殼」，變成真的 AI 工具。

目前專案也同步放在 GitHub：
https://github.com/f24131128-lgtm/visual-learning-lab