vibe coding 實驗：自幹一套 Obsidian 網頁版，讓手機也能免費同步+編輯筆記

數位囤積症患者碰上 Obsidian 這種產品真是非常舒服，所有資料都可以是本機的獨立檔案，或是把整個資料夾備份到任何地方，完全不怕被平台鎖死。

甚至操作上有任何不滿意的地方，都可以 vibe coding 自幹一套。

本文就來做一個實驗，vibe coding 一個網頁版的 Obsidian 筆記，在電腦、手機、iPad 上都可以輕鬆新增、修改、瀏覽筆記。

Obsidian 的跨裝置同步難題

Obsidian 有跨裝置同步功能，但我不愛用。官方在 2020 年左右就推出了，要付費。記得當時市場上還有其它筆記軟體，差不多價位，但功能更多、同步額度更大。老實講，要是不放圖片，額度也許根本用不完，但就是怕會用完。

後來 Obsidian 在去年(2024 年 3 月)又出了一個更便宜的同步服務套餐，月費要 4 美元，付費之後方案也不是無限使用的，vault 數量、儲存容量、修改紀錄保存時間都有限制。另外還有一個更高階的 Plus 方案，使用額度更大，但仍然不是無限。

• 1 synced vault
• 1 GB total storage
• 5 MB maximum file size
• 1 month version history

一般人看的是月費 4~8 美元，我看到的是人家團隊要整年監控機器運作狀態、萬一筆記臨時要用時打不開，準備被使用者罵得狗血淋頭。要負擔使用者各種客服問題，要開發 Android, iOS, macOS, iPadOS, Windows 等各種平台的 app，還要提心吊膽保證每次出新的 os 版本，app 不會閃退會或幹嘛的，還要保障資訊安全。

網路上找一些 Obsidian 大神如何處理跨裝置筆記這回事，大致有三種:

• 把筆記放在 iCloud 或各種雲端硬碟，然後用麻煩的方式來同步。
• 把筆記同步到 GitHub 上，然後在手機或平板上安裝各種 git 客戶端，然後讓官方的手機 app 來讀檔案。
• 碰到喜歡玩開源的工程師，寫給工程師，或寫給 Android 手機使用者看的，還會有各種花式雜耍技巧。

可以到一些國外論壇爬文，看看大家對於 Web Version of Obsidian 或是 A Hacky Solution for Obsidian Sync 有些什麼奇思妙想。

以第二種方法而論，稍微用過 git 的人，尤其是那些常常在解 merge conflict 的，都心知肚明，雖然也許比較不會遇到雲端同步災難「軟體卡住一直轉圈圈，轉了 2 天不知道到底在同步什麼?」或是「莫名其妙檔案被刪光光/檔案被回溯」的問題，但 git 操作邏輯和一般的雲端同步軟體相比，在這種使用情境也絕對談不上什麼無縫絲滑、輕鬆無腦。

如果我是什麼心靈健康主題類的部落格，這時候應該要提倡什麼工作之餘就放下手機好好休息，Obsidian 就在電腦上使用就好。然後開始放一些心靈成長課程、宗教師父的話、旅遊分潤連結、推銷 eSIM、VPN...

既然沒有官方 Web 版本，那就自幹一套

理由一大堆，什麼官方付費方案有限制，什麼 git 在這種場景不好用，反正數位客家人是不想花這筆錢的，Obsidian 好像也根本沒有出什麼 web 網頁版本。

突然想到，既然我是把筆記備份到 GitHub 私人 repo，然後我之前有用過 GitHub 的 API，它的 API 也有各種檔案操作功能，那我直接自幹一套網頁筆記程式不就好了嗎? 然後弄成 PWA，操作起來可以滿足 87% 的需求。

醜話講在前面

為了怕大家一時衝動，覺得這個辦法可以完全替代官方的 Obsidian Sync 或其他跨裝置同步筆記的奇巧淫計，先把醜話講在前面:

GitHub API 的限制

這個實驗的概念是透過 GitHub API 去操作檔案，所以要看人家 API 的臉色，GitHub API 有 rate limit 跟一些限制，而且不是付錢就能解決的。

如果沒有 rate limit 等相關概念，建議先去理解搞懂再繼續看下去，以免筆記跑不出來，還以為程式有問題、ChatGPT 有問題。

其他的限制在後面的段落中會再提，例如剛剛新增的筆記內文，無法馬上被搜尋到之類的。

當然 GitHub 也是會三不五時故障，越依賴他們的服務，就會發現故障頻率不算低。要是剛好程式用到 GitHub 故障的部分，這個 Obsidian 網頁版就無法使用。

碰到故障我們可以 PUA GitHub，叫他們派人來跟我們開會，說你們做線上服務要有責任感，不能常常故障，以後有很多檔案要放在他們上面，誇說他們產品很厲害(但沒有打算要付錢)......之類的幹話，這樣有用才怪。

總之備案之一，就是記得在自己的電腦留一份 Obsidian 筆記的 vault。

GitHub 平台的爭議

GitHub 現在是微軟的，宣稱不會拿 private repo 去訓練，個人帳號預設也不會開啟拿資料去訓練的設定(在帳號設定層級有Allow GitHub to use my data for AI model training，而不是在 repo 個別控制)，

GitHub 也讓大家有那種擔心哪天會被平台封鎖帳號的刺激感，就是有人會被 GitHub 莫名其妙封帳號。不過在本文的情境來說，至少電腦本地還有一份 Obsidian 的 vault，比較不用擔心。

前幾年 GitHub 因為美國的一些政策，禁止伊朗等一些國家的使用者使用 private repo，把功能鎖起來，雖然後來解開了，後來俄羅斯開戰後，在美國制裁名單上的俄羅斯公司與相關的開發者帳號，也無法使用 GitHub。難保自己的帳號未來不會因為政治問題再度發生。

使用 Git 當版控，但不要用 GitHub? 的確還有很多替代方案，但不在本文討論範圍內。本文就是要把 GitHub API 用爆。

運作成本

這套網頁程式需要找到地方佈署，和維持它的運作，前後端程式有各種地方需要維護，我只是順便利用一下手上的機器資源，用起來不爽的時候就讓 AI 去改程式，看到有什麼低成本又好用的東西就趕快加進來，沒有產生什麼額外成本。

普通人如果想要這樣搞，會有以下成本:

• 到一個月動輒 $5 美金起跳的 PaaS 平台開幾個服務，讓這套程式跑起來
• 網頁發生任何前後端或 SRE 問題，還要再花個美金幾十塊起跳的月費讓 AI 去處理
• 去學程式設計，知道如何好好讓 AI 寫程式，跟 AI 溝通需求。
• 在 stackoverflow 或各大技術討論區每天蹲點爬文，看看各種實際使用開發技術的人都碰到什麼問題，判斷自己的技術選型適不適合。在一些電腦補習的 FB 廣告被吹到飛天，什麼又快又好的網頁程式語言，在實際工程師的討論區可能被嫌到連狗都不用。
• 去學 git 怎麼用，程式改壞了還可以想辦法退回去之前的版本。
• 去學 E2E 測試之類的軟體開發技能，以免每次 AI 改一個東西，就要緊張的人工測試有沒有哪邊壞掉。
• 關注產業最新消息，知道哪邊有更好用又更低成本的東西可以利用。
• 去學更多技能，不會被 AI 的人云亦云、false alert 騙到，知道哪些是真的重要的問題，擴大對於軟體開發領域的認知邊界。

如果有成本考量，而且沒有技術能力，資料量不大，那還是乖乖用官方的 Obsidian Sync 就好了。

只有筆記功能

承上點，主要只有先做處理 markdown 純圖文筆記的功能，其它 Obsidian 的功能都沒做。

其他像是無限畫布的 Canva、把檔案開頭的各種 YAML 格式資訊互相連來連去的 Database 或 DataView、各種有的沒的 Link 功能，各種社群插件能做到的功能，本文完全沒有去碰。

主要設計在有網路的環境使用

可以透過 PWA 和 Service workers 的功能，讓有些筆記不用連網路也能瀏覽(但實際上用起來比較像時間暫停器...按重整都還是一直顯示舊的，要再多做一些機制去避免看到暫存舊筆記)。

設計邏輯主要還是透過線上網頁程式直接讀寫 GitHub repo 的檔案，沒考慮沒網路要如何使用，也沒有考慮切換應用程式時被殺後台時，編輯到一半的內容怎麼辦...之類的問題。

替代方案的替代方案

本來討論的是自幹一套網頁筆記程式，來替代 Obsidian Sync 或各種麻煩的跨裝置的同步方式。

但有可能我們根本不用自幹一套筆記軟體，這種 File over app 的邏輯有其他的替代方案。

用網頁編輯器去改 GitHub 的檔案

如果 vault 放在 GitHub 或相關服務上，理論上可以用網頁瀏覽器直接檢視跟修改筆記檔案，GitHub 網頁版的 online editor，或是 https://vscode.dev/ 這種 cloud IDE 都能輕鬆辦到。

其他可以編輯 Markdown 的跨平台 app

另外還有 GitJournal 這種產品，專門設計給手機用，可以跟 git repo 同步檔案，還有一個基本的檔案編輯器功能，專為 Obsidian、Notable 這種筆記軟體設計。
不過 GitJournal 的 Android 版本免費，iOS 版本美金 $3.99，一次性付費，不用每個月繳費，非常佛心。

但畢竟它不是 Obsidian，操作起來有說不出的難受，而且很多 Obsidian 的功能都不支援。

還有 SilverBullet 這種產品，提供一套 Docker 自架程式，或雲端版的程式，讓人管理自己的 Markdown 筆記。在 Deploy your own Notes 之類的清單上，也可以看到不少獨立開發者做的筆記軟體。

自架伺服器

還有 Local REST API for Obsidian 這種直接把電腦變成伺服器，然後透過這個套件的 API 去操作 Obsidian 內的資料。

這個只是讓資料流不用透過其他雲端服務，上面跟本文後面提到各種 GitHub 問題通通迎刃而解。也可以和更多外部程式整合，例如 n8n 跑完某些流程，把資料寫入這個本地 Obsidian 筆記內。

不過在手機平板上讀寫 Obsidian 筆記的程式還是要自己寫。如果要把這些 API 通到外網(WAN)，即使外出也可以用，那就會面臨更多的資安風險。

自幹網頁版筆記軟體的好處

講完缺點講優點，最大的好處當然就是自由度，操作介面可以自己亂改、隨意加功能，按鈕位置要放哪就放哪，文字樣式要怎麼就怎樣。

不佔儲存空間

這大概是我想做這個網頁版的初衷，這種玩法沒有占裝置儲存空間的問題，反觀其他 Obsidian 跨裝置同步方法，會在每個裝置保存整個 vault 的所有檔案，三不五時還要同步，非常占手機跟平板的空間，還有浪費網路流量。

當然後續可能因為夢想無限膨脹，例如想要離線閱讀筆記，或是用量大到要減少呼叫 GitHub API，或是要加速檔案搜尋，導致又要留一堆檔案在本地，或是在網頁程式的伺服器上產生一堆索引用途的檔案...

電腦上也能用

理論上電腦也可以用這個網頁版，這樣電腦上就不用多開一個 Obsidian 程式，而是多開一個瀏覽器分頁而已。

變成網頁之後好處多多，例如可以利用瀏覽器的內建翻譯功能，或第三方翻譯擴充套件，把內容輕鬆翻成其他語言。

也能在打開筆記後，再叫出各種瀏覽器側邊欄的 AI，讓他根據當下視窗內容生成一些東西。

但是這件事會隨著各家瀏覽器 AI 的實作機制不同而定，例如 Microsoft Edge 是會把網址拉去遠端分析，AI 會被卡在網頁版筆記的登入畫面，回答不出任何問題。Perplexity Comet 的 AI 助理是會直接讀取網頁當下的 DOM，所以不會被卡在登入畫面。

因為是私人用途，沒有做出什麼分享連結、共同編輯、收費閱覽、自動每日把筆記轉成社群貼文之類的功能。相比單純將筆記資料關在一個筆記軟體裡，這些資料流的應用能發揮更多用途。

GitHub REST API 的好處

GitHub API 實測之下算是非常的 vibe coding friendly:

• 似乎是 2022 年出的，市面上的幾個大模型(GPT5, Claude 4)的 knowledge cutoff 大都在 2023~2024 年間，符合年份。
• 近幾年官方比較常在搞 GitHub Actions 那邊的東西，還有到處塞 AI，其它功能比較少頻繁大改版，不然一般當 LLM 寫出執行失敗的 code，人類都要確認是 AI 幻覺亂寫不存在的東西，還是寫法不符合新版 API，花不少時間排查。
• API 提供的搜尋功能非常強大，有一堆篩選條件，也不用擔心內文的大小寫差異，都可以輕鬆搜尋到。

驗證機制比較沒這麼複雜，差不多就是呼叫的時候帶上一組 token 而已，也沒有 domain 限制，而且可以從 GitHub 那邊直接把 token 註銷或增減權限。

所有操作都有紀錄

無論是檔案整個誤刪，內文有一段誤刪還是怎樣，只要沒有人為下一些可怕的 git 指令，基本上都可以找回來。

我也完全不需要自己設計複雜的 version history 跟 log 機制，畢竟這都是 git 天生就有的功能嘛。

反觀在電腦上使用 Obsidian ，操作了一整天可能才手動 push 幾次，碰到問題想要找回途中遺失的內容? 希望非常渺茫。或是要安裝一些編輯記錄相關的社群外掛，但有時候「編輯紀錄」跟「復原內容」是兩回事。

用免費的 AI IDE 做出初代版本

當時 AWS 團隊新出的 Kiro 剛好發布不久，還在新產品甜蜜期，免費帳號有好幾十次的 Claude Sonnet 使用額度，剛好拿來用一下 vibe coding 免費。

Kiro 主打的是有一個 Spec Mode，大概跟 AI 說了一下:

• 指定前後端技術(Vue3+TailwindCSS+PHP)。
• 技術概述需求，先做一個精簡的功能測試版本 SPA，先不用任何需要 build 的開發方式，CSS&JS 直接引入套件的 CDN 路徑。也不用設計任何 router 機制。
• 操作 GitHub API，做出一個類似檔案瀏覽器、筆記瀏覽器的網頁程式。
• 一些一定要有的功能，要有一個檔案樹狀圖介面，筆記要可以新增跟修改，UI 要設計成大小螢幕都能正常操作...blahblah。

(原始的 prompt 是英文的，大概比上面更長，只是本文為了方便表達，換成中文要點清單)

Kiro 的 Spec AI 很快出了一套規劃，我仿效網路上常看到的vibe coding 的三不一沒有精神，

• 不需要看 API 文件
• 不需要學程式語言
• 不需要理解運作邏輯
• 沒有要負任何責任。任務失敗都是 AI 太爛或編輯器太爛，絕對不是自己需求亂開，有哪邊需要檢討。

AI 做的 design.md, task.md, requirements.md，我連看都沒看，脫下孔乙己的長衫，把什麼精神都拋在腦後。多花時間去看這些東西就輸了!

現實也是一樣荒誕，有些客人或主管就是想到什麼做什麼、隕石開發法；根本不需要學習理解任何東西，需求張嘴就來，基層工作人員能拿他們怎樣?

感覺社會上對於 vibe coding，講究的不是學習 coding，而是不 coding 就可以創造程式。程式只要會動就好，不用管它怎麼動的。也不用去考慮有什麼發生在認知範圍外的問題。

回到正事上，因為 GitHub 也是存在已久的 API，不需要把文件整理弄成機器可以方便讀取的格式，也不需要準備幾包官方 SDK 或 sample code 給 AI 參考，直接就可以開工了。

很快 AI 就出做了第一版...那時候忘記仔細截圖，就想像有個 web 版的 Obsidian。

(假裝這裡有一張圖片)

細修才是痛苦的開始

稍微試了一下新增、修改、檢視檔案，看起來這概念是真的能用之後，就開始細修。功能開始無限膨脹，也請 AI 整個重構成 Vue 元件，把程式做成需要編譯與建置的。

然後像是按鈕跟訊息常常一下有中文一下有英文的，UI 對齊跟間距有許多不滿意的地方。
因為 Kiro AI 當時的使用額度是算次數的，而且 TailwindCSS 的前端架構，除了按鈕跟一些區域，大部分的東西都是一堆 atomic CSS 名稱，每次要改什麼都要 hashtag 檔案，選取起來或是報行數也很累，所以有些 UI 問題還是自己調比較快，省得來回反覆修改浪費次數。

但還是有幾次比較嚴重的災難。

登入之亂

最崩潰的一次修改是加上身分驗證，
先讓 AI 把未登入前不該被使用的東西都藏起來。
OK，確實很快藏好了。

接著 AI 經過漫長的來回修改，把登入驗證做完了。
OK，終於可以登入了。

登入之後一看，嗯? 怎麼之前正常的功能通通都壞了?
diff 之後發現「把未登入前不該被使用的東西都藏起來」那時候就把一堆東西都直接刪了。
但又不想退回好久以前的版本，於是又再慢慢補回來，並測試...

圖片無法顯示之亂

還有一次是圖片功能，關於插入圖片我有做各種「原圖上傳/壓縮」*「留檔案/不留檔案」*「OCR 成各種格式」的排列組合，但有些圖片就是無法正常顯示，非常奇怪

人類肉眼到 GitHub 網頁上檢查 repo 的檔案，檔案是有正常上傳的，圖片也可以正常打開&顯示，初步排除上傳時把圖片壓壞/傳壞，或是檔案 MIME 的問題。

結果這又浪費不少 tokens 和時間，一開始 AI 的修正方向是調整請求時的檔名或路徑編碼、增加 log、檢查檔案是否存在 blah blah，這些部分不只是顯示圖片，很多地方都會用到，所以調整時都有機會讓本來好好的功能故障，讓整個筆記系統都無法使用(喔對，我直接改線上的程式版本，沒有另外的測試區)。但其實問題跟這些完全無關。

後來發現叉燒包的圖片都有個特徵，就是大小超過 1MB。查閱 Repository limits 官方文件，只有很客氣寫個:

The recommended maximum limit is 1MB. This is enforced at 100MB.

聽起來就沒什麼強制性? 結果檔案超過 1MB 就出問題。後來依照這個方向，改成要先偵測檔案大小，然後用 git/blobs 那支 API 來拿大檔案，才讓圖片顯示正常。

使用 AI 寫程式的靈異現象就不多談了，本文主要是來分享用 GitHub API 直接讀寫 Obsidian 筆記檔案這回事，甚至以後要用 GitHub API 作其他用途可能會發生什麼事。

GitHub API 的限制

GitHub 很不會做生意，沒有搞什麼要先付費升級到某個方案，才能申請 API，然後還要每個月依照用量算錢那套商業玩法。反正就是免費的，感謝微軟爸爸。

REST API 基本功能

剛剛有寫到關於單檔大小的限制 Repository limits，還有一個 repo 最多可以多大，一個資料夾內可放多少檔案，一個帳號可以開多少 repo，一秒鐘可以讀取幾次，這些限制都在 repo limit 裡面有寫。

接著還有關於 GitHub REST API 的限制，可參考官方說明 Rate limits for the REST API，摘錄幾個要點:

• 個人版: rate limit of 5,000 requests per hour，組織帳號的額度會更高
• 每分鐘上限不能超過 900 點，它有一個點數表的機制，有些 endpoint 跟 methods 耗費的點數特別高。
• 同時併發請求不能超過 100 個
• 會建立內容的，有 80 RPM 跟 500 RPH 的限制

因為筆記是放在 private repo，一定要驗證後才能撈，所以那些什麼未登入的使用額度就不用看了，詳情可參閱 About secondary rate limits 章節。

GitHub 官方也很貼心，有直接提供方式讓人查剩餘額度，不用自幹一堆莫名其妙的東西。

另外不得不提一下 GitHub 這種版本控制服務的機制，雖然搬移檔案、檔案改名之類的操作，很像在操作 object storage 服務的 API，但這些東西之間無法類比，還是有很多不一樣的:

• 執行速度問題，有幾支 API 回應速度似乎特別慢，撈資料時要撈特別久，跟高貴的雲端服務不一樣，這不是錢可以解決的問題。
• 檔案搬完後，馬上根據新路徑去要內容顯示? 可能會暫時要不到檔案，要等一下下才會出來，畢竟這是一個實驗性質的專案，忍耐是一種美德。
• 要搬移檔案或新增檔案，如果碰到目標路徑已經有同名的檔案? 系統的預設行為不會直接覆蓋檔案，會給個錯誤訊息。要嘛另外多帶參數當成更新來處理，要嘛自己設計其他機制，讓新舊檔案合併。

搜尋 API

筆記軟體一定會有個搜尋功能，好消息有 2 個:

• 每個檔案的原始字串非常乾淨，不是亂七八糟的 html，也不是像區塊編輯器軟體，原始資料是一堆謎之 json。搜尋起來可以少費一點功夫。
• API 提供的搜尋功能不用擔心英文大小寫問題，無論內文是 "SEO" 或 "seo"，不用設計什麼奇怪機制，預設都能輕鬆搜尋到。

不過搜尋有更多限制，額度跟剛剛另一邊是完全分開計算的，可參考 REST API endpoints for search

同樣摘錄幾點:

• search 的 RPM 是 30，code search 的 RPM 只有 10。
• 每次搜尋最多返回 1000 筆結果，而且如果同一個檔案中有 N 條符合，它會顯示成 N 條項目，我沒有仔細測，但實際能用的額度可能比想像中還少很多。
• 系統有查詢超時的設計，也許 repo 中確實有符合查詢條件的內容，但因為花太長時間查詢了，後面還沒查到的它就不管了，會直接回應已查到的內容，然後給個 incomplete_results:true。

有些拿 LLM 搞過一些功能的人，可能有寫過一種機制，當使用者輸入一個關鍵字，然後程式會將它拆解成 N 個查詢，然後讓 LLM 整理這 N 個查詢的結果，這是當下許多 AI 資料研究助手的背後設計機制之一。在 GitHub API 的限制之下，我們先單純的管理&檢視筆記就好，沒事最好不要加入其它的特別功能。

還有一大問題是搜尋索引時間，檔案推上去之後，就是搜尋不到? 這個在官方文件沒特別提，但是在 Reddit 和 GitHub Community 上有一堆災情，甚至索引時間要等好幾天的都有，乖乖等就對了。

慶幸的是 API 的行為跟直接上去 GitHub 用網頁版，差不多是一致的，有時候晚上還找不到，隔天早上就有了。

也許有人想到了，那不要用 GitHub 的搜尋 API，而是把所有資料夾的所有檔案遍歷一次，把每個檔案的內容取出來比對?
那首先會被 5000 RPH 的限制卡到，檔案非常多的就不用想了。
然後這樣搞的話查詢一次要花很久時間，檔案有幾個，就要打幾次去要檔案然後比對內容，主機網路傳輸跟 CPU 資源用量圖表會瞬間上升，影響效能。

其實 AI 一開始寫的搜尋功能根本沒用到 search API，而是直接遍歷比對所有檔案，我還詫異為什麼這樣寫? 後來碰到索引問題，才發現 AI 真是有大智慧...。反正現在是在搜尋功能上面還做一堆選項，手動選擇要不要查詢所有檔案、選擇只搜尋哪些資料夾。

當然我想應該有人是用 Gitlab 之類的服務，或自架 git server 的，上文的限制根本不是問題。反正我先把問題擺在這，以後有人有大膽想法時，減少踩坑。

用 iOS 捷徑把分享的連結或文字傳給筆記

在電腦上可以使用 Obsidian Web Clipper 瀏覽器擴充套件，把網頁內容存起來。
但是在 iPad 跟 iPhone 上就武功全廢，因為只是一個 PWA web app，不是真的 APP，所以選「分享」，APP 不會出現這個網頁筆記程式。

後來想到用蘋果系統強大的捷徑功能，拉一套 shortcut:

iOS 捷徑負責接收分享資料、詢問筆記名稱、把內容用 JSON 格式發到網頁程式去，

人類要再做一支網頁程式去接收捷徑發來的資料，還要幫程式做個 log 介面，方便 debug。

實際使用大概像這樣

捷徑這邊也有不用不知道，一用嚇一跳的問題，例如在 Safari 把網頁連結分享到捷徑，跟在 Facebook 或其他 app 裡面把連結分享到捷徑，後者能拿到的東西少很多。

只能在捷徑多拉幾段流程，然後把接收分享資料的網頁程式裡面再好好設計一番，例如根據 URL 抓網頁標題&內文，是圖片就自動 OCR 擷取文字，標題如果是某一個字元，就自動用 AI 生筆記標題......之類的。

再講下去又要長篇大論了，就此打住。

結語-vibe coding 這回事

目前的版本長這樣，程式碼已經堆積如山了了。

閒暇時就上去改改，或是丟幾個需求看 AI 會如何達成，連 Obsidian for Windows 原來的官方程式也越來越少用了。寫這篇的時候還在想說塞一些有的沒的功能上去。

還要寫什麼呢? 對了，vibe coding 的心得文通常都會說...這種東西以前找公司做要好幾萬塊，然後日後維護和修改的維護都是無底洞之類的，可惜我本來就是做這個的，沒辦法說這種幹話。

vibe coding 好玩嗎? 好玩的可能是不用管成本，不用管別人怎麼想，做自己要用的東西，回到解決問題的初衷，而不是先考慮這件事划不划算，有什麼價值。碰到 AI 改不動，人類也不想接手的 code，就不好玩了。

本來是沒有要寫這篇的，覺得不會有人想要操作 GitHub API 當雲端空間，聽起來跟拿 Excel 當繪圖軟體、ChatGPT 對話紀錄用來記帳、npm 被拿來放連續劇影片、GitHub issue 當成部落格或留言板之類的用法一樣好笑。

直到前幾天看到 Huli 大大曾想過 自己做一個筆記軟體出來......拿 git 當 storage 用，自用所以不用考慮多裝置衝突的問題......，糟了，得趕快阻止他。

他想的可能是自幹整套筆記軟體出來，我想的是解決跨平台使用跟 UI 自由度的部分。如果有人也想這樣玩的話，出發點很好，但是建議不要出發。除了本文的 GitHub API 限制，編輯器本身就是水很深的東西，可以挑其它在行動裝置上設計得更好的筆記服務。

談到更好用的筆記服務，這幾天看到 Notion 3.0 的 Agent 功能，想到坊間有一堆教人用筆記軟體的課，以前要弄個某某資料管理系統研究老半天，現在只要跟 AI 對話，它就會自動把欄位開好、選擇的項目加上去，設定好資料關聯，設定好檢視功能和篩選器。

當然可能也跟 vibe coding 一樣，如果有人真的不知道 Notion 有什麼功能，也不知道某某資料管理系統應該有什麼資料，從零開始製作時，提出的需求可能會亂七八糟。

然後在後續使用階段，當 Notion 放了滿滿的資料，人類還敢隨便讓 AI 亂動整個資料庫結構嗎? 就不怕改一改之後某些欄位直接不見，還要想辦法復原? 那人類自己手工調整呢? 一開始的 Notion 關聯資料庫是 AI 幫忙建的，人類根本無法理解 AI 把東西跟選項是藏在哪裡? 而因為軟體的封閉性，也不能找其他 AI 來幫忙...

結語-寫筆記這回事

前陣子又開始用 Obsidian 當筆記軟體，File over app 的設計概念在這個時代剛好成為它的核心優勢，資料夾結構和純文字檔(Markdown 或各種格式)不只在 Obsidian 裡使用，隨便用個 AI IDE 或 CLI 工具，打開筆記檔案所在的資料夾，輸入一些 prompt，就能生成一些新內容，甚至連上其它自動化流程。

小時候第一個用的筆記軟體應該算是 Evernote，後來它的「商業化發展」，讓人對這種線上服務多少都有點心理陰影。
這幾年陸續又用了不少方式來記錄筆記，有時候隨著平台結束服務或政策大改變，又要連夜跑路。

或是某天用一用會突然進入賢者模式，覺得奇怪，筆記用意是想要有一天可以派上用場，為什麼花這麼多時間在「學習筆記軟體如何操作」跟「整理資料」勒?

我的意思不是軟體應該設計到不用學就能用，整理資料也牽涉很多圖書館學、教育領域的知識，肯定都需要學習才能做得好的，但有時候似乎有點本末倒置了?

在 LLM 的時代，我想有些筆記其實沒有存在的必要，有時候不需要再回頭翻閱冗長的參數表、逐一確認參數與指令的用途，也不必重看自己過去踩過的坑，有些知識與經驗可以即時被 AI 重建、優化。

講直白一點，有些事物的迭代速度和資訊量，遠比單一人類做筆記還快，一個人類是有多能學、多會背? 讓筆記的角色逐漸從「死板的紀錄」轉向「提供上下文，幫助 AI 產生更好輸出」的工具。

prompt

能看到這裡真不簡單，文末提供這個網頁筆記最基本功能的 prompt，一些比較進階或個人化的部分沒寫，括號內的請依照自己的開發習慣和需求填上。

有需要的人可以拿回去，再延伸出 todo 跟 test 項目，讓 AI 開發一個偽 Obsidian 網頁版。

## Overview
- The core idea of this project is to provide a GitHub repo file reader, fully relying on a GitHub repository as the file storage backend.
- All file operations (create, read, update, delete) are done via the GitHub API, with commit records required.
- The functionality is a lightweight private note-taking web app, with authentication using ().
- Repo information, tokens, and API keys are loaded via ().
- Uses a single-page application (SPA) architecture with frontend-backend separation.
- Backend: written in (), using () framework, running on ().
- Authentication between frontend and backend uses (), with data format ().
- Project naming rules: ().

## Frontend Requirements
- Frontend: built with (), ensuring efficient development and excellent performance. Build method: ().
- Since this project is for private notes, add proper no-referrer and noindex configurations.
- Consider responsive design (RWD) for both desktop and mobile devices.
- Add PWA and apple-touch-icon settings to ensure icons display properly and the app runs when added to iOS/iPadOS home screen.
- As an SPA, no need to design routing to jump to specific pages or files.
- File and folder names may contain spaces, symbols, emojis, or Chinese characters — make sure encoding is handled correctly.
- Show a loading indicator after sending requests or fetching data to make progress clear.

## Feature Overview
### Login & Logout
- Authenticate with (), hide all content until the user is logged in. The following content is only visible after login.

### File Tree
- Display the repo directory structure and files, with subfolders collapsed by default.
- Prefer fetching the entire directory tree at once to avoid repeated API calls when expanding folders.
- Implement caching to avoid calling GitHub API every time. Provide a button to clear cache and reload the tree.

### Recent File Updates
- Fetch files modified in the past () days via GitHub API. Each item links to the file view.

### File Tabs Bar
- Since this runs in PWA fullscreen mode without browser navigation or tab tools, create a custom file tab bar.
- Each opened file shows as a tab. Tabs have equal width; long filenames truncated with CSS. Each tab has a close button. Duplicate tabs should be avoided.
- Save opened tabs using (), so they persist across sessions or devices.
- Switching tabs while editing should not affect other tabs’ editing states.

### Delete Notes
- Allow deleting files, with confirmation before deletion.

### Move Notes
- Move files to another folder via a modal showing the directory list.
- Check for duplicate filenames in the destination folder: if exists, ask to merge. Otherwise, copy content to new path and then delete the original.

### Create New Notes
- Use a modal to select the destination folder when creating a new note.

### Edit Notes
- Do not use modal windows or textarea to edit (to avoid multiple scrollbars). Use a `contenteditable` area to display raw Markdown. After saving, render it back to HTML.
- On iOS/iPadOS, symbol input is inconvenient. Provide a toolbar with quick Markdown buttons: H2, H3, ordered list, unordered list, quote, code block. Hitting Enter in a list should auto-generate a new list marker.

### View Notes
- Separate viewing mode and editing mode — don’t combine them.
- Notes are stored as Markdown strings; render them into HTML on the frontend. Even without `\n`, line breaks should display correctly.
- If the content includes raw HTML, display it as code instead of rendering it.
- Automatically detect and linkify URLs in the content.
- In the side panel, provide a collapsible and resizable TOC list automatically generated from H2 & H3 headings in the note.
- Convert Markdown image syntax to HTML img elements.

### GitHub API Status Panel
- Display API usage quotas and reset times.

### File Content Search
- Provide a modal for search interface and results.
- Use GitHub API to search file names and contents.
- Add folder filter to limit search scope.
- Add a checkbox for per-file matching. By default unchecked; when enabled, compare every file’s content against the keyword.
- Clicking a result should also open it in the file tab bar.

### Create Notes via iOS Shortcuts
- Accept POST requests with `content-type: application/json`.
- Fields: `title` (note name), `key` (for auth), `content`, `url`. Either `content` or `url` may be empty.
- Use GitHub API to create a new note in the root directory.
- Apply basic security: sanitize input strings. Respond with "success" or "failure".

## Security Requirements
- All sensitive keys like GitHub tokens, API keys, or LLM credentials, Do not expose them in the frontend code or client storage.
- Validate all API requests and sanitize inputs server-side to prevent abuse and injection attacks (e.g., replay of stolen API calls).
- All API endpoints must validate the user’s session to prevent forged payloads from browser dev tools or other sources.