Hello，我是 Roland，又到了每週與你分享我的所見所聞的時刻。

我不是工程師，背景是十年的遊戲行銷。但從去年下半年開始，我陸陸續續用 AI 工具嘗試過幾個軟體專案，其中一個叫思藏（Thinkrium）的個人知識管理工具，到現在還在持續開發中。最近跟一個也在研究 AI 的朋友聊，我們都有同一個感觸：你可以看到很多人做出厲害的東西、總結出各種經驗談，但那些總結往往刪掉了過程中到底踩了哪些坑——而踩坑的經驗，其實比成果本身更有參考價值。這篇文章想記錄的，就是這些通常不會被寫出來的部分。

一、從自己的日常挖需求

我最早開始接觸 AI 輔助開發，是從一個桌面陪伴遊戲開始的。

當時的想法很簡單：上班族整天盯著電腦，如果螢幕角落住著一個可以互動的小角色，在你工作的空檔摸摸牠、逗逗牠，能得到一點治癒感和正反饋，應該會有不錯的市場。後來桌面放置類遊戲確實風行了一陣子，某種程度上也印證了這個方向的判斷。

那是 AI 開發工具剛開始流行的時候，但我還沒接觸到那些工具，所以用的是最原始的方式——在聊天介面跟 AI 討論，讓它給我程式碼和整體的文件結構，然後一個一個去複製貼上。核心功能說穿了就是個番茄鐘，開發起來幾乎沒遇到什麼難解的問題。但後來卡在了寵物的像素動畫製作上，當時的生圖工具加上我自己的能力，實在沒辦法把這種素材做到可見人的程度，所以暫停了。

再後來是一個遊戲化健身 App。起因是我自己在健身減肥的過程中發現，健身 App 這個領域裡，大多數產品做的事情都差不多：內建動作庫、安排訓練計劃、或是接入 AI 自動生成課程。但幾乎沒有一個像《多鄰國》那樣，去認真思考「怎麼讓使用者堅持下去」這件事——怎麼在 App 裡給使用者正反饋、讓人有額外的動力持續訓練。直到今天，我也依然沒看到這樣的應用出現。

做這個專案的時候，有了之前桌寵遊戲的經驗，我對 vibe coding 已經有了一定的理解，開發方式也從複製貼上，進化到用 VS Code 搭配 Roo Code 這個外掛，讓 AI 直接在編輯器裡建立文件、撰寫程式碼，我只負責確認做出來的東西能不能跑，以及功能和介面是不是我想要的。這個專案走得比桌寵遠很多，最後是一個可以正常運作的 APK。但同樣卡在了素材上——雖然當時的生圖工具在一致性維持上已經進步很多，我也寫過一篇文章分享生圖技巧，但要精確生成我想要的運動動作關鍵幀，甚至衍生成一段演示影片，還是需要耗費大量的時間精力去想怎麼處理。最終也是暫停了。不過現在 AI 生圖和影片的能力都比那時候強很多，後續還是打算把這個專案做完。

這兩個專案讓我意識到一件事：AI 輔助開發的可行性，取決於你的需求跟當下工具能力之間的距離。工具一直在進步，但你的時間和精力是有限的，等待的成本跟硬推的成本，都要算進去。

二、從 RSS 到 思藏（Thinkrium）

桌寵和健身 App 暫停開發之後，我沒有立刻去想下一個 App 要做什麼。因為在這之後我開始嘗試經營遊戲茶水間這個自媒體，而在這個經營過程中，我開始建立一套自媒體文章創作的工作流，而在這個工作流迭代優化的過程中，則逐步出現了想要做一個符合自己工作流的知識庫軟體，也就是現在在做的思藏（Thinkrium）

作為一個持續輸出遊戲產業分析的內容創作者，我高度依賴 RSS 來收集素材。但光有 RSS 不夠，你還需要一個地方把值得留下的內容存起來、整理好。我最早用的組合是 RSS 加 Notion。選 Notion 的一個重要原因是它的 Web Clipper 生態最成熟——當時我的工作流是在 RSS 閱讀器裡瀏覽、看到值得收藏的就打開網頁、按下 Web Clipper 儲存進 Notion。筆記軟體有沒有一個好用的 Web Clipper，是我在選工具時很看重的一個條件。

後來我對 Notion 純雲端的穩定度越來越存疑，剛好 Obsidian 也推出了自己的 Web Clipper，而且透過語法自定義和 AI 的結合，可以達到相當不錯的儲存效果，所以我全面轉向了 Obsidian。

但不管是 Notion 還是 Obsidian，整個流程的根本痛點一直沒變：RSS 瀏覽 → 打開網頁 → 按下 Web Clipper 儲存 → 再切到筆記軟體確認結果。這個不斷切換介面的過程，每天重複幾十次，累積下來是很明顯的消耗。

再後來，我對 AI 工具的使用更加熟練，流程又進化了一輪——我直接把連結貼給 AI，讓它按照我定義的格式去讀取網頁、整理內容、轉存成 markdown 文件。省掉了 Web Clipper 這個環節，但介面和工具本身還是分開的，割裂感依然在。

與此同時，我日常使用的 RSS 閱讀器 Folo 也讓我越來越不滿意。它的更新把原本的三欄式設計改成兩欄式，點開文章預覽就會遮住文章列表，想切下一篇必須先關掉預覽，使用節奏被徹底打斷。加上過濾雜訊的能力不足、搜尋歷史文章不好用、日常使用中的小毛病也不少，整體體驗持續下滑。

這些事情加在一起，讓我開始想：那我自己做一個 RSS 軟體好了。思藏 在最一開始，其實就是一個 RSS 專案。但想著想著，我又覺得——按照我的流程，我收集完素材之後還要整理、打標、建立關聯，最後才是在需要的時候找出來用。如果這些事情全部要在不同的工具之間跳來跳去，那做一個 RSS 軟體也只是解決了其中一環。如果我做一個可以把輸入、整理、輸出都一站式解決的東西，不是更好嗎？

思藏就是這樣從一個 RSS 軟體的發想，變成了一個知識庫專案。

三、在 Obsidian 上折騰過的事

在決定自己做之前，我在 Obsidian 上花了不少力氣，嘗試用 AI 來管理我的知識庫。

最早的嘗試是讓 AI 批次處理素材——把幾個月累積的新聞筆記統一整理，補上標籤、補全欄位、歸檔到對應資料夾。我設計了一套封閉的標籤體系，42 個標籤涵蓋內容類型和知識領域，搭配結構化的欄位記錄公司、產品、地區、關鍵字。然後讓 AI 按照這些規則跑。第一輪跑下來，結果看起來不錯，但問題很快浮現：AI 在處理批次任務時穩定性很差，檔案移動失敗、欄位填錯、中途斷掉的情況都遇過。而且同一個概念，這次打的標是「AI」，下次就變成「人工智能」，聚合效果直接廢掉。

我也試過更進階的做法。用 MCP 讓 AI 直接操作瀏覽器來自動化收藏流程，試過語義搜尋來解決「找不到存過的東西」的問題。語義搜尋的效果一開始讓人興奮，但實際測試下來只有大約三成的文章能被搜到，而且面對包含特殊符號的中文檔名時表現很不穩定。後來我發現，其實關鍵字搜尋配合 AI 的分析和聯想能力，就能做到差不多的效果——問題的核心從來都不在搜尋技術夠不夠強，而在於資料本身有沒有被好好整理過。

整個過程讓我越來越清楚一件事：Obsidian 的靈活性是真的，CSS Snippet 加上各種插件，確實可以把它打造成很多種樣子。但這個靈活也帶來了很陡峭的自定義門檻，插件裝多了對啟動速度和穩定性都是負擔，最終呈現上也還是有屬於 Obsidian 框架本身的天花板。要在框架內達成一個非原生的近似結果，再去解決這個結果帶出來的各種問題，耗費的精力不比自己做一個來得低。而最根本的問題——標籤一致性——在 Obsidian 裡沒有任何機制可以在底層保證，光靠提示詞說清楚是不夠的。

帶著這些經驗開始做思藏之後，架構也不是一開始就確定的，而是在開發過程中跟 AI 反覆討論，一步步收斂出來的。比如 metadata 到底存在哪——最初我設想沿用 Obsidian 的做法，放在 markdown 的 frontmatter 裡，但做到後來發現外部編輯器打開檔案就可能破壞 metadata，同步邏輯也越來越複雜。跟 AI 把各種方案攤開來看之後，最後收斂到一個更乾脆的方向：資料庫作為 metadata 的唯一來源，markdown 只放正文。這個決定一下子把整個系統的複雜度砍掉了一大半。

另一個討論出來的重要決定，是日記和知識庫要不要放在一起。我的日記內容異質性很高——技術除錯、家具採購、健身心得、書評什麼都有。如果讓這些內容的標記自動流入知識庫，搜某個遊戲公司的時候可能會跑出我買椅子的心得，整個專業語境就亂了。最後的設計是讓兩邊獨立運作，需要橋接的時候手動建立連結，而不是讓系統自動去猜。

做了一段時間之後，最近我看到 AI 研究員 Andrej Karpathy 分享他的知識庫工作流——他說他用 LLM 把原始資料「編譯」成一個結構化的 wiki，所有打標、分類、連結都交給 AI 做，最後說了一句話：「我覺得這裡有空間做出一個很好的產品，而不是一堆拼湊起來的腳本。」

看到這段話的時候，我有一種很具體的感受：我在解決的，正是這個缺口。不是因為看到 AK 才去做，而是做了一段時間之後，看到一個你尊敬的人在說同一件事，確認了這個方向不只是我的個人需求，而是一個真實存在、還沒有好答案的問題。

四、在實作中釐清「我到底想要什麼」

正因為是從自己的日常裡挖出來的需求，你才會對產品該是什麼樣子有最直接的感受。但說實話，一個人其實很難明確說出自己到底想要什麼——對大多數人來說，把內心的感受轉化成精確的描述，本身就是一件很難的事，我自己也是如此。

Vibe coding 在這裡幫上了一個很關鍵的忙：你可以透過跟 AI 討論，把那些模糊的「感覺不太對」一步步推向具體的描述，最終變成一個真的滿足你感受的成果。而要觸發這個過程，有一件事是省不掉的——你得親自坐下來，用你做出來的東西，走一遍真實的使用流程。這件事沒辦法透過看別人的教學來替代。網路上有大量的 vibe coding 教學影片，但那是別人在做的東西，解決的是別人的問題。你可以從中學到工具的操作方式，但「我到底想要什麼」這個問題的答案，不會出現在任何人的教程裡。

這聽起來像是廢話，但很多人跳過了這個步驟。看著 AI 跑完一輪、功能上線了、介面也出來了，就覺得這個階段完成了，可以繼續往下一個功能推進。但實際坐下來用，感覺往往完全不同。思藏的開發過程中這種狀況一再發生——某個功能的流程在設計時完全合理，但實際點進去操作，才發現繞得莫名其妙；某個介面看著整齊，但資訊的顯示順序根本不符合使用時的思考邏輯。這些問題很多時候不是技術問題，而是「我想像中的使用方式」跟「我實際使用時的感受」之間的落差。只有真的用過，你才知道哪裡不對，然後才有辦法跟 AI 說清楚要改什麼。

思藏的大方向就是這樣調整了好幾次。開發到中期的時候，我一度把它的完成度看得太重——覺得只有把工具做到一定的完整程度，才有辦法開始真正的深度思考和內容產出。後來我意識到這是一個「完美容器謬誤」：我不是在等工具完成，我是在用「工具還沒完成」當藉口迴避眼前真正該面對的問題。想通這件事之後，我對思藏的定位也跟著調整了——它不需要是一個完美的系統，它需要的是在每個階段都能解決當下最迫切的那個問題。

另一個例子是 AI 在思藏裡的角色。最初的想法是讓 AI 盡量多做一點——自動打標、自動分類、自動建立關聯。但經歷過 Obsidian 的教訓之後，我跟 AI 討論出了一個三層的設計：最底層是純資料庫操作，零 AI 依賴，永遠可用；中間層未來可以接本地模型做打標建議；最上層才是雲端 AI 的增強。核心原則就一句話：每個功能在沒有 AI 的情況下，都必須能完整運作。AI 只是加速器，不是必要條件。

每次走到這種岔路口，我的習慣是先停下來和 AI 討論：接下來這個功能，我的原始想法是什麼、為什麼想要這個、可能的實現方式有哪幾種、各自有什麼代價。你在解釋自己想法的過程中，你自己也想得更清楚了。討論完之後常常會發現，我以為我想要的東西其實不完全是我需要的，或者我對一個功能的設想跟實際使用情境裡的行為根本是矛盾的。

當然，這些反覆討論和迭代都需要成本，而 AI 工具的費用是一個繞不開的現實。

五、用有限的預算把事情做出來

各家 AI 工具的訂閱加起來，每個月是一筆不小的支出。我在開發初期就踩過一次坑——用 Claude Pro 跑週報素材整理，任務才進行到一半，月度用量限額就被觸發了，剩下的工作直接卡住。那次之後我開始認真面對一件事：如果你的開發流程重度依賴 AI，額度見底就等於停工，這個風險不能不管。

我的應對方式是根據每個工具的特性和計費邏輯做分工。現在大致上是這樣：Claude 負責規劃、設計和審查，它在理解複雜需求和做架構決策上最強；Jules 負責有明確規格的實作任務，它按對話窗數計費而不是按用量，跑有範圍的任務很划算；Gemini CLI 負責大範圍的偵錯和重構，速度快而且額度充裕。每個工具都有自己最適合的場景，組合起來比單押一個更經濟，效果也更好。

不過我也走過彎路。最早的做法是讓一個 AI 產出詳細的執行計劃，再自動傳給另一個 AI 去執行，中間盡量不經手。聽起來很美，但自動化的環節越多，出問題的時候越難追。後來反而「返璞歸真」了——讓 Claude 產出規劃文件，然後由我自己來做中間的橋樑，手動引導其他工具去讀取和執行。效率看起來低了一點，但可控性高了很多，實際算下來反而更快。

說白了就是「用時間換金錢」：你花心力去理解各個工具的適用邊界和計費結構，換取更高的整體效率。這個策略本身也有成本——你同時維護多個工具的對話狀態，協調本身就是一種消耗。願不願意投入這個腦力，取決於你的預算有多緊。

六、以人為本永遠是核心

回頭看這段經歷，有一個時間點讓我印象特別深。大概是今年三月的時候，我寫了快五十期週報，卻有一種越來越強的空轉感——持續在輸出，但感覺不到自己在成長。後來我意識到，問題不在產量，在定位。我一直在做的事情本質上是「解說員」——廣泛覆蓋遊戲新聞然後給評論。但解說員這個角色，在大模型時代進入門檻極低，任何人丟一條新聞給 AI 都能產出一段像樣的點評。我真正想做的是「主治醫師」——拆解產業問題的結構，給出只有實戰經驗才拿得出來的診斷。

這個認知轉折跟思藏的開發其實是同一件事的兩面。思藏讓我驗證了一個信念：人機協作的核心，是人決定方向、AI 加速執行。週報的轉型也是——AI 可以幫我整理素材、討論大綱、校對文字，但「這篇文章要說什麼、為什麼這件事重要、讀者讀完應該帶走什麼」，這些判斷只能是我自己的。

在整個 vibe coding 的討論裡，我覺得最容易被忽略的一件事是：AI 讓寫程式變容易了，但它讓「知道要做什麼」變得更重要了。當執行的門檻降低，產品判斷力反而成了更稀缺的東西。前面提到的那位朋友，走的恰好是另一條路——從保母級教學開始，買網課、看影片，一步步學工具的用法。但他跟我說，照做了一輪之後，很多概念他還是不清楚。他感受最深的是：工作上的實際應用跟個人能力的提升，正在變成兩條有很大鴻溝的路。工具怎麼操作可以學，但「拿這些工具來做什麼」，沒有任何教程能替你回答。

非工程師在 AI 輔助開發裡的優勢，從來都不是學會了怎麼跟 AI 溝通——那是工具技能，人人都能學。真正的優勢是你帶進來的那個視角：你對這個產品要解決什麼問題有第一手的感受，你在使用的過程中能直接辨認出哪裡不對勁，你能在「這個功能做出來了」和「這個功能真的有用」之間做出判斷。

思藏到現在，結構化標記、知識庫視圖、相關內容推薦、主題管理都已經到位了，離能用的 0.1 版本不遠了。它不是一個完美的產品，但它確實在解決我自己的問題，而且每一次迭代都讓我對「人和 AI 之間應該怎麼合作」這件事理解得更具體一點。

如果你也對這個方向有興趣，我的建議只有一個：從一個你自己就是第一使用者的需求出發。只有這樣，你才有足夠可靠的判斷力去駕馭 AI 這個強大但不會自己辨別方向的工具。

📰 本期推薦

• GameLook - 遊戲策劃深度分享：深度的遊戲策劃分享，值得所有想當遊戲策劃的人都看看。
• 少數派 - 談談 Windows 的視覺風格與交互演變：雖然不是遊戲新聞，但 Windows 從過去到現在的 UI 演變史，是一篇有趣的文章。
• GameLook - 《哀鴻：城破十日記》爭議：《餓殍：明末千里行》續作因更加黑暗的歷史改編而站上風口浪尖。我之前在萊斯的節目中曾藉由《明末：淵虛之羽》聊過明末歷史在歷史改編領域的特殊性，當時《餓殍》的安全下莊與《明末》形成鮮明對比。而這次的爭論在我看來還是回到了老問題——遊戲作為娛樂作品可以嚴肅，但它終究是個娛樂，創作者不論如何都需要在遊戲中設計一個情緒出口，讓玩家得以獲得足夠的正反饋。