第一句問題：每個字看起來都明確
這個站的起點是一句問題：「我可以用計算機工具的網址來架站嗎？」
字面解讀很自然——使用者想拿現有的 ∑ Calc 子網域去架另一個東西。 技術上馬上可以回答：可以、不行、有什麼方案。 如果照字面實作，這個站今天會是 ∑ Calc 的某個 subpath，或者用 iframe 嵌進去。
但這樣做的人會錯過一個事實：這句問題裡每一個關鍵字，最後都被自己否定。
四輪追問，每輪都翻一個假設
第一輪：「你想要的是綁自訂網域、子路徑、還是 iframe 嵌入？」
→ 答案是「綁自訂網域」。第一個字面意義的假設掉了——使用者不是要在 ∑ Calc 的網址下放東西， 是要一個新網域。
第二輪：「這個自訂網域是給 ∑ Calc 改個門面，還是放別的東西？」
→ 答案是「想用買的網域架個人品牌中樞站，把各專案跟文件放上去」。 第二個字面假設掉了——這跟 ∑ Calc 幾乎無關，是全新的東西。 「計算機的網址」只是發問時順手抓的參照點。
第三輪：「品牌站的調性偏向接案、找工作機會，還是純粹分享？」
→ 答案是「純粹學習與分享，不接案」。第三個假設掉了——一般人架個人品牌站的預設動機 是接案或求職，但這個使用者明確不要。這個答案會深刻影響全站的文案、按鈕命名、CTA。
第四輪：「品牌名字、視覺風格你想自己定還是我提案？」
→ 答案是「叫 Bobo Labs、風格你決定，專案內容之後再補」。 四輪走完，從「∑ Calc 的延伸」變成「全新的個人品牌靜態站、純分享、Swiss 排版、空殼先上」。
如果照字面實作會發生什麼
假設我跳過追問，照「用計算機網址架站」的字面意思動手—— 可能做出來的東西大概是：calc.moneyai168.com/blog/、或 ∑ Calc 首頁多一個 tab、 或一個 iframe 嵌入式的小站。
技術上會成立。但它不會是這個使用者要的—— 因為這站要的是「跟 ∑ Calc 切開、不接案、純分享」的調性， 掛在 ∑ Calc 底下會繼承計算機產品的所有暗示（這是個工具、這是 freemium 產品、這是商業面）。
模糊需求最大的風險不是做錯細節，是做錯框架。細節錯了改一改就好，框架錯了整個重來。
追問的成本，比想像中低
四輪追問聽起來很多，但每輪只是一個 AskUserQuestion，每個回答按一下就好。 四輪的總時間大概是兩分鐘。
相對於這兩分鐘換來的——把「在 ∑ Calc 底下加東西」這個錯誤框架攔住， 把全站文案語氣的方向定下來、把品牌名字確定、把視覺風格授權釐清—— 兩分鐘投資的回報率非常高。
一個容易被忽略的反直覺：對使用者來說，回答四個選擇題比看著一個錯方向的成品來抱怨容易得多。 選擇題給的是「決策權」、抱怨給的是「修正權」——前者使用者愛、後者使用者煩。
順手撞到的小坑：git 目錄該在哪一層 init
技術細節順手記一下：原本的工作目錄根目錄混了好幾個東西—— ∑ Calc 的子目錄、 claude-config、無關的大檔 docs。如果在根目錄 git init，會把所有東西都掃進去。
解法是在 bobo-labs-site/ 子資料夾裡 init，把這個專案隔離成獨立 repo。 「不要在 cwd 根目錄 init」這條規則平常聽起來像廢話，但在多專案混居的開發環境下， 它是避免把無關歷史污染進新 repo 的唯一辦法。
關鍵教訓
第一句問題的字面意義，幾乎永遠不是真正的需求：「用 X 的網址架站」這句話裡的 X，最後被自己的回答否定了。模糊需求要逐層追問，不要照字面實作。
細節錯了改一改就好，框架錯了整個重來：模糊需求的風險不是做錯細節，是做錯整體方向。要先用追問把框架釘住。
追問的成本比想像中低：四輪 AskUserQuestion 大約兩分鐘，換到「不接案」這種深刻影響全站文案的明確答案。投資報酬極高。
選擇題比改錯題容易：對使用者來說，回答四個選擇題比看著一個錯方向的成品來抱怨容易。前者給決策權，後者給修正權。
多專案混居要在子資料夾 init：cwd 根目錄混雜時，git init 在子資料夾才能隔離。這條規則平常聽起來像廢話，混居環境下是唯一辦法。