引言

昨天，我們把開發環境搭好了。

Cursor 看得到專案，Codex CLI 也可以直接讀取、修改資料夾裡的檔案。換句話說，從今天開始，我們其實已經可以真的叫 AI 動手了。

但我自己平常想做一個網站或 App，通常不是先從「我要用什麼框架」開始，也不太會是突然想到一個很厲害的產品點子。

很多時候，起點反而只是生活裡的一個小麻煩：

這件事如果有個工具可以幫我處理，好像會方便很多。

有些想法最後真的變成專案，有些想一想就算了。所以今天想分享的，就是把這個過程攤開來看：一個生活中的小麻煩，是怎麼慢慢變成一個可以開始做的東西？

一、靈感通常就藏在生活的小麻煩裡

1.1 從「如果有這個就好了」開始

很多專案的起點，其實沒有想像中那麼正式。有時候不是市場研究，也不是先寫商業計畫，而只是某天突然覺得——如果有一個東西可以幫我把這件事處理掉就好了。

例如：每次都要找同一類資訊、同一件事一直重複做、資料散在很多地方、現有工具某個地方總讓人覺得卡、原本可以很簡單的流程，卻一直來回確認

這些都可能是起點。這時候我通常不會急著想功能，而是先問自己：我真正覺得麻煩的，到底是哪一件事？

1.2 這個麻煩，還可以往哪裡想？

當一個小念頭出現之後，我會習慣再往下想幾層。如果沒有想法，5W1H 剛好是一個滿好用的框架：

這些看起來很普通的做法，反而很容易讓我想出：這個麻煩到底卡在哪裡。

1.3 可以再把情境往外推一點

想到這裡之後，還可以再問兩種問題。

What if｜如果不是最理想的情況呢？

例如：如果使用者要找的東西根本不存在呢？如果他打錯字、或用了不一樣的說法呢？如果一次要處理的東西很多，不是只有一筆呢？或是說如果他中途離開，回來之後呢？

這時候不需要一次把所有例外都解掉。比較像是先提醒自己：真正使用的時候，情境通常不會只有一條最漂亮的路。

How do we know｜怎麼知道它真的有比較好？

重點是答案不該是「我做了一個搜尋功能」或「網站上線了」。

答案通常會比較接近：原本要花十分鐘的事，現在一分鐘內做得完。 或是：原本要開五個地方才湊得出來的東西，現在一個地方就有。

1.4 各種領域也很類似

如果把同樣的想法換到別的情境，其實也很容易找到類似的小麻煩。

情境不同，但出發點都很像：先從生活裡那個一直覺得麻煩的地方開始。

而且痛點也不只有一種。有時候是資訊找不到，有時候是流程太多步，有時候是要跨好幾個平台，有時候只是覺得現有的工具收費有點貴。

二、那我這次的念頭，是從哪裡開始的？

講了這麼多，那我在這一個系列文之中要做什麼呢？

2.1 一開始只是想確認一個版本

我有時候會遇到一個場景：站在唱片行的架子前面，手上拿著一張實體專輯，想知道的事情其實很簡單——這個版本的專輯裡面到底裝了什麼？ 寫真書幾頁？小卡是隨機抽還是整套附？海報有沒有？這個通路限定版跟一般版，差別到底在哪裡？

聽起來很單純，但可能得在瀏覽器的好幾個分頁或其他電商APP之間切換：官方頁面寫得不清楚、賣場各說各話、開箱文散落在不同平台、熱心整理的圖過兩個月就沒人更新了。

一隻手拿著手機、另一隻手拿著專輯，站在店裡翻這些東西 —— 有點痛苦。 而且這個痛苦有一個特徵：它每次不嚴重，但它每次都在。（當然，僅限於我零用錢還夠買專輯的時候。）

那時候我腦中出現了一個想法：

如果有一個地方可以直接把這些資訊整理好，查起來應該方便很多。

這就是這次專案最一開始的起點。

2.2 然後我開始往下想

把剛剛那個框架套回來，大概會長這樣：

拆完之後，我延伸思考了兩件事：
第一，最有感的是 Where 那一格。使用情境是站著、單手、可能還有點趕時間——所以我可能會需要注重手機上的使用者介面 如果我做出一個電腦上很漂亮、手機上卻很難用的網站，那它其實沒有解決我原本的問題。

第二，真正的價值可能不在「有資料」，而在**「湊齊」** 資訊。因為現在每個來源其實都有一部分資訊，痛的是要自己拼湊。

再加上前面那兩個問題：

What if —— 如果某些版本還沒收錄呢？如果關鍵字打錯呢？這種情況一定會發生，因為資料不可能一開始就完整。所以「查不到」這件事本身，可能也需要好好處理。

How do we know——如果原本要翻很多頁才能確認的資訊，現在可以更快找到，而且不需要在不同來源之間一直切換，那這個網站就真的解決了一部分問題。

三、那我為什麼想做這件事？

有了想法之後，我自己還會再想一件事：我為什麼要花時間把它做出來？ 答案不一定是「因為它可以賺錢」。不同專案，本來就可能有不同目的。

3.1 已經有人做過了，還要做嗎？

想到一個點子之後，很容易第一時間去搜尋：有沒有人做過？如果真的找到類似的產品，也很容易冒出一句：那是不是就不用做了？我覺得這件事沒有那麼絕對。

有人做過，不代表你現在遇到的問題已經被解得很好。 你還可以再看看：現有工具是不是很難用？會不會需要付費？資訊是不是不完整？有沒有某一群人的需求沒被照顧到？某些流程是不是還是很麻煩？

反過來也一樣。完全沒有人做，也不代表一定是機會。 有可能只是需求很小、資料太難取得，或維護成本太高。

所以我比較喜歡把它想成：

「有人做過」不是放棄理由；「沒人做」也不是需求證明。

3.2 先知道自己想從這個專案得到什麼

同樣一個想法，不同人做，目的可能完全不同：

以我這次來說，我並沒有打算靠這個網站營利。比較像是剛好趁這次鐵人賽，把一個自己原本就覺得麻煩的事情做掉。

它還是會花一些模型、主機、資料或其他服務的費用。但如果這 30 天同時能讓我完成系列、練習一套完整流程，又真的做出一個自己會用的工具，對我來說這個投入是可以接受的。

這個答案不一定適合每個人。重點只是：先知道自己為什麼想做。

3.3 衡量一下，再決定值不值得

每個人的標準都不一樣。有人願意花兩個月做一個自己喜歡的小工具；有人做 side project 只願意投入兩個週末；如果是商業產品，要考量的又更多。

所以我不太會把「值不值得做」當成一個有標準答案的題目。比較像是在過程裡衡量：我願意投入多少時間？會不會需要一直維護？資料好不好取得？需要花多少錢？我自己真的會用嗎？做完之後，我想得到的是什麼？...等等。

以這次來說，我知道它可能不會變成什麼大型產品，也沒打算靠它賺錢。但它剛好是一個我自己真的會用、範圍又適合拿來走完 30 天的題目。

所以對我來說，答案很簡單：值得做。 不是因為市場多大，而是它剛好符合我這次想得到的東西。

四、想法很多，先排出第一版

當一個點子開始變具體之後，功能通常也會越想越多。以這個專案來說，我很容易一路想到：搜尋、收藏、帳號、評論、社群、推播、AI 推薦、排行榜、App、管理後台⋯⋯

問題不是這些想法不好，而是—— 不可能全部同時做。 所以這時候我更在意的是優先順序。

4.1 先找到最核心的流程

我會先問自己：如果第一版只能讓使用者完整做完一件事，那會是哪一件？

以這次的專案來說：

找到專輯 → 選擇版本 → 查看配置

就這三步。如果這條流程本身都還不好用，那會員、收藏、AI 推薦做得再漂亮，也還不是現在最重要的事。

4.2 哪些事情要先做？

比起把功能分成「做」和「不做」，我自己更常用的是排序：

這種方式對我來說比較自然。因為很多功能不是永遠不要，只是——現在還不是它。

而且說實話，我也不確定自己排的順序一定對。像「收藏」這個功能我就有點猶豫，它看起來很基本，但如果連查詢本身都還沒做順，收藏其實也沒什麼好收的。所以我先放 Next，之後看情況。

4.3 有些功能很酷，但不一定要先做

例如：「既然是 K-pop 網站，要不要做 AI 推薦？」很酷。

但它現在有沒有幫我解決「我找不到某張專輯的配置」這個問題？如果沒有，那就可以先排到後面。

這種排序最大的好處，是每次又想到新功能的時候，可以先問一句：它現在真的比核心流程更重要嗎？ 而不是想到什麼就立刻加什麼。

這概念其實類似於很多人所謂的「MVP」（Minimum Viable Product ，最小可行性產品）

五、先把目前想到的東西寫進 idea.md

到這裡，其實已經有不少東西想清楚了：我為什麼想做、使用者可能是誰、什麼情境會用、核心流程是什麼、第一版先做什麼、還有哪些想法先留到後面。這時候，可以先把這些整理成一份 idea.md。

5.1 為什麼不直接寫 SPEC？

SPEC 是 specification（規格、規範、詳細說明）的簡稱。

在正式開發時，通常會有某種形式的規格文件，用來記錄目前已經確定的需求、功能、限制與技術決策。不同團隊可能會拆成不同文件，我這個系列後面則會整理成一份 SPEC.md。

但今天先不急著生正式 SPEC。現在我們主要是在整理「為什麼做、給誰用、第一版先做什麼」這些想法，所以先把它們放進 idea.md。

等後面技術選型也確定，再把 idea.md 和那些技術決策一起整理成真正可以拿來開發的 SPEC.md。

5.2 AI 也可以一起幫忙想

我以前開發的時候，其實很常先把需求講給 AI，再讓它幫我補出一些沒想到的東西。這也是 AI 很有價值的地方之一。 所以我試了一下：

我目前想做一個實體專輯配置資訊查詢的網站。
靈感來源主要源自於逛實體專輯店時，有時候想查詢專輯內容物時，會需要在不同的網站、APP之間切換，有時候也不一定查得到。目前最優先版本希望可以有完善的搜尋流程：「找到專輯 → 選擇版本 → 查看配置」，請幫我找出可能遺漏的使用情境、彼此矛盾的地方，或我沒想到的需求，幫我以5W1H的架構（可以另外加What if 跟 How do we know），整理成一份 idea.md。

【圖1、請 AI 幫忙整理想法】

結果 AI 比我想像中整理得完整很多。我原本只是想叫 AI 幫我把前面的想法整理一下，結果它比我預期多想了不少。（總共整理了300多行）

例如它把「專輯版本」再往下拆成 Release、Version、SKU、Inclusions、POB，也提醒我：同一張專輯在不同地區、通路、批次之間，可能根本沒有一個全球一致的「版本」定義。

【圖2、AI 幫我定義了資料層級】

它也丟出了一個我前面沒有特別想過的衝突：如果我一開始就追求跨語言、錯字容忍、條碼、圖片辨識全部都能找得到，第一版的搜尋成本會非常高。

【圖3、AI 幫我想到了可能的衝突/矛盾】

甚至他也直接幫我排好了開發的階段 P0、P1、P2：

【圖4、AI 建議的 MVP 開發階段】

這些東西不一定全部照收，但它們很適合拿來當思考的材料。

5.3 這一步不一定每個人都需要

這次 AI 幫我展開得很完整，但 idea.md 本身不算是必要流程。如果你本來就熟悉產品、架構和資料設計，也知道自己要用什麼技術，其實可以直接和 AI 討論後進入規格整理。

我這次刻意保留 idea.md，只是因為今天想把「從一個模糊念頭一路長成可開發方向」這個中間過程攤開來看。同時，之後的規格書也可以以這個檔案為依據去進行規劃。

如果你本來就已經知道自己要做什麼、也知道大概要怎麼做，這一步完全可以跳過。

結語與明日預告

昨天，我們把工具準備好了。今天，我們沒有急著寫功能，而是從生活裡的一個小麻煩開始，慢慢往下想：我真正覺得麻煩的是什麼？除了我以外還有誰會遇到？我為什麼想做這件事？第一版應該先做什麼？哪些想法可以先放到後面？最後，把目前已經想清楚的東西先整理進 idea.md。

現在方向有了。但明天開始，AI 就會真的進來一起工作。在那之前，還有兩件事要先處理：

如果它改壞了，我們怎麼回得來？如果需求有模糊空間，它可以自己決定到哪裡？

所以明天，我們先把安全繩綁上，再分享一些我習慣與AI對話的方法。

明天見。