話說在前頭，在撰寫文章時，我已經 Vibe 產品到一個進度了，所以遇到的問題和順序有些已經遺忘，只能盡量回憶。
起源
今年我為團隊的某位成員定下了一個目標，主要是解決目前公司遇到的規格書協作問題，大致情境如下：
- 公司主要業務是接政府專案，一開始沒有 SA，都是 PM 自己寫規格
- 後經招募 SA 後，但因為沒有招募很多人，所以變成較爲重要或需要特別深入學習領域知識的專案才會請 SA 撰寫 Spec
- 所以 PM 跟 SA 都必須寫 Spec
結果導致以下問題：
- 專案 PM 和 SA 都要寫 Spec，使用的工具、寫法都不一樣。
- 政府專案因為最後會需要繳交系統規格書，會需要輸出 Word 檔，所以如果不是直接使用 Word 編輯，最後整合時還需要複製貼上到 Word。
- 執行團隊會有很多文件需要一起看，例如政府的初始需求規格書、公司服務建議書、評選簡報、會議記錄、API文件、UI 設計稿、公司工程師的技術文件...等，
導致觀看文件時會需要在不同瀏覽器頁籤或是軟體之間一直切換。 - 因為文件很多，存放的地方可能也不一樣，例如有些存 Nas、有些存雲端服務。
- SA 之間遇到較大型專案會分工，所以有多人協作需求，如果是用Word 那就會需要在意版控問題
- 當 Spec 異動時，PM 或 SA 為了工程師不要遺漏最新更新，使用的工具可能還需要特別標明修改時間以及保留修改前的描述，造成版面極度混亂。
- 文件之間有關聯的地方，使用的工具無法很好的建立雙邊的關聯，即使建立了，如果文件內容異動，也可能消失或是忘了去維護，造成文件在後續擴展的開發案時無法高效利用已存在的 Spec。
- 另外有時候還需要給外部人士觀看，如果是檔案，還要很小心的給對方正確的版本。
- 有時候網路環境問題，就沒辦法工作了
濃縮一下真正需求：
- 文件希望像 Notion 那種編輯器
- 工具與寫法統一
- 文件存放位置統一
- 觀看文件時可同時看到其他關聯的文件或檔案
- 可多人協作、可看到對方在編輯什麼
- 歷史異動
- 可分享給外部的人看文件
- 離線也要可以編輯
在我期待著成員會如何解決這個問題的同時，一直有一個點子縈繞在我心頭：
今年 LLM 比2025 的可靠許多，如果「一個只懂 Html/CSS人」建立了這樣的產品，需要 Vibe 多久？ Vibe時會遇到什麼問題？ Vibe時會需要懂什麼知識？
我一向是有想法就開始規劃與實作了（雖然到最後都是自 High 居多的產品），但我很享受這個過程，可以獲得很多知識與成就感。
我非常想知道在我不碰程式的情況下，我能為這個產品做的極限在哪裡。
除了上述需求外，我也很想要一些自己的需求、新功能和順手實驗：
- SA 初始範本建立
- 多國語言
- SEO
- WCAG 2.2 AA級
- Word、PDF、Markdown 以及 Office 系列匯出
- 嘗試內建 AI 助手，讓有 API Key 的人可以使用
- Spec 完成後，可以順便產出 QA 測試案例
還沒開始我就已經非常期待這個產品完成的那天！
定位、LLM使用方式規則與產品定位
關於我
我是一個舊時代的「前端設計師」，我入行網頁設計領域是 2013，大概是 iPhone5 發布的時候，那時有個很熱門的討論，就是「設計師應不應該學寫程式」。
我當初的立場是需要學，因為不僅能了解程式真正運作的過程，還能跟工程師溝通無礙、自行掌握 UI，甚至未來還有轉職前端工程師的選項，所以我專精於 CSS，然後 javascript 的部分只學到會使用前端框架切版、版控 flow 概念、會安裝第三方套件、弄個假資料就差不多了。
但在這次的 side project，我給自己的背景與規則是：「有基本網頁知識背景，不要介入程式碼的撰寫」，能動的只有兩個：文案和 User Prompt，也就是不用 Skills、MCP之類的設定，嘗試看看單純這樣能做到什麼程度。
會有這個定位是因為，以前我很想做的一些事情，要完成都需要麻煩到前端工程師和後端工程師，所以很多 side project 都只有做到切版程度就沒再繼續下去，覺得很可惜，或是應該說，覺得無能為力、失落。
再來講講工具，因為我也很好奇 LLM 實際上寫的程式碼會是怎麼樣子，以及他的運作過程，所以：
- Nuxt 當作前端框架，看看 LLM 在不指定細節下，會怎麼配置。
- 使用 Antigravity ，來下需求相關的 User Prompt ，觀察思考過程。
- 跟程式碼和產品無關的提問，我會回歸到網頁版的 LLM 詢問，例如什麼是 supabase 這種問題。
- 購買Google AI Pro ，網頁版 Gemini 跟Antigravity 都可以使用這樣比較方便
（但因為4月實作時遭遇了Gemini連線問題讓我非常不爽，後期改用 Claude 使用）
產品定位
在「起源」篇章，我的需求都集中在撰寫規格書這件事，但其實可以再更廣大的延伸成文件類都可以。因為開發時，要撰寫的文件也是很多：測試計劃、測試案例、規格、API、會議記錄...等。
就從「文件」本身出發，探討「寫文件」、「看文件」和「管理文件」時都會發生什麼活動，最後目的是讓文件是一種「活著」的狀態，而不是專案結束就被遺棄、過往的規格書被雪藏，其中管理文件就只是有做出分類就好，不把重心放在這，而是著重在「寫」和「看」的場景，也可以說是為了「小型軟體開發團隊」做的產品，這樣就有很清晰的使用者受眾。
(不求能真的做出有小型軟體開發團隊願意付錢解決問題的產品，但至少能解決我自己遇到的問題。)
實作開始
最小需求：編輯文件
既然是看/寫文件，編輯器就是最重要的，一開始就是先讓 LLM 決定要用什麼編輯器，當時 LLM 直接建議我使用 Tiptap，因為我之前也有關注過 Tiptap，所以馬上就決定了，
於是我就讓 LLM 幫我建立一個文件編輯器，
此時 LLM 建議我，需要有一個文件列表做為文件管理，當然是秒答應，因為我心思都放在文件編輯，完全忘了需要有文件列表，就放手讓 LLM 依照他的建議做，我心想反正就是個列表，我之後再回來改也無傷大雅。
最後這階段產出了：
- 後台排版外觀與主選單
- 文件管理列表CRUD與儀表板統計頁面
- 文件標題、編輯區域、大綱區域、工具列區域出現
在這個最小需求的時候，我發現了使用 Antigravity 的非基本的 Model，token 都一下子就到達極限了，然後切回額度最多的 flash ，又跟之前的聊天記錄連接不到，所以我從這個最小需求之後，都只有使用gemini flash，因為其他 model 都一下子就結束了，這會導致程式寫到一半死掉，還要用 flash 接回來非常麻煩。
但這也導致我的程式碼，我一直覺得不滿意，就感覺充其量是拼拼湊湊那種感覺，
但既然我選擇不干預程式碼只使用一般 PM 會使用 LLM 的模式，那就眼不見為淨了，幸好這個階段大部分是在規劃 UI，功能面就很單純套個 Tiptap 進去而已。
第二需求：分割視窗與雙向連結
分割視窗算是我的需求中最重要的，因為包含了兩個核心功能：預覽外部文件以及預覽雙向錨點連結。
這兩個重點著重在解決以前「spec 在 google doc、API 文件在 google sheet、spec 提到的某個功能不知道在 API 文件的哪裡，還要開 word 檔看外部的需求規格書，還要去 Figma 看設計稿，還要開簡報看評選簡報」的情境
外部文件需要支援無限制的新增，其中新增的項目又分：
上傳檔案和外部連結，常用檔案格式為 .doc、.md、.pdf、.pptx..等。
外部連結就又分為雲端分享的連結以及相關網站（相關網站只能另開視窗，因為 iframe 因為安全性基本不能跨網域）
雙向錨點連結的使用情境，是編寫 A 文件時，想要把某一個段落或甚至一句話，跟有關的 B, C 文件內的某個段落做相互跳轉的錨點，只要雙向有一方刪除錨點或是異動，這個錨點就會被刪除或是自動移動，以往在 google sheet 要做這件事只能認儲存格的id或是用外掛，而且格子內容異動後，還不能自動更新。
所以就形成了：左邊編輯器為主體，右邊各種外部資源或內部互連的列表，雖然也是像瀏覽器頁籤一樣，但在觀看文件時變成一種沒有中斷的感覺，撰寫文件者也可以隨時觀看資源，相當的方便
在執行這兩個核心功能時，不能一股腦把我所有想像的東西直接塞給 LLM，我的執行方式是先把分割視窗的按鈕和 UI 刻出來，先確定 UI 的大框架，再來就是先做雙向錨點連結，叫 LLM 在工具列中新增一個按鈕，點擊後開啟 Dialog ，可以選擇其他文件，選擇後再選擇文件的哪一行，最後在這兩個文件選擇的那一行最後加上一個標籤，標籤的名字是該行的簡短內容，並且用顏色區分哪個文件主動連結、哪個是被動連結的，這樣在分割視窗預覽時，我就可以顯示列表，以及被連結方的那一行實際內容的預覽，且之後可以擴充成視覺化，勾勒出文件之間的關係。
接著就是做外部連結，這裡很單純 CRUD 連結或檔案而已，但因為考量到之後可能會做單檔的分享開關，就也順便把 UI 給保留位置。
以上這些我當時是列點出來一步一步慢慢說給 LLM 聽，這邊很順利的沒有調整什麼就完全實現了。
順利上傳了，那就是要預覽，外部連結基本都是 iframe，內部連結要呈現當然也沒問題，有問題的是上傳檔案，因為要額外處理，pdf 還好沒遇到太多阻礙，.md 要加個原文和渲染後的樣子，但 office 系列 就難處理要用套件或是 LLM自己寫，跟 LLM 來回了好多次，然後因為還要處理另開視窗放大全螢幕預覽，所以還要多做單獨預覽的一個頁面，供之後類似的情境發生可以使用。
不過有一件事值得一題，我在這裡碰到了奇怪的問題，
就是當我要另開視窗看檔案時，我有用個預覽的模式，結果有一次改完發現檔案都不會正常顯示內容了，內容都變成回首頁，
最後 LLM 修正原因記錄如下：
🔍 偵探時間：為什麼網址會被「魔改成」首頁？
首先，聽到「分割視窗正常顯示了」，這代表我們剛剛修復的 API 和權限機制完全成功了，Cloudflare Functions 也有順利執行！
那為什麼唯獨打開 preview 頁面時，明明輸入的是 https://dahtahdoc.com/preview?url=...，網址列卻會被「拔掉 preview」，物理上強制替換成了 https://dahtahdoc.com/?url=... 呢？ 這是因為發生了以下連鎖反應：
伺服器當機 (SSR Crash)：我們剛剛在 preview.vue 裡面使用了 import VueOfficePptx from '@vue-office/pptx'。這套件天生是設計給瀏覽器用的（裡面用到了 window 物件）。當 Cloudflare 的伺服器嘗試渲染 (SSR) /preview 這個頁面時，因為伺服器沒有 window，直接引發了 Fatal Error (伺服器當機)。
Cloudflare 救援機制：Cloudflare 伺服器發現 /preview 當機了，於是它啟動了 SPA 網站的標準救援機制——直接回傳網站的 index.html (首頁) 給您。
Nuxt 幫倒忙的強制矯正：當您的瀏覽器拿到首頁的程式碼並準備啟動 Vue 時。Vue Router 說：「咦？伺服器吐給我的畫面明明是首頁，但是你現在瀏覽器上方的網址怎麼寫著 /preview？這肯定不對！讓我幫你『修正』網址列！」
於是，Vue Router 就雞婆地把您瀏覽器上的 /preview 砍掉，變回了 / (首頁)，但完整保留了後面的問號參數 (?url=...)。
這就是為什麼路徑會完美地「被引導回去首頁，但參數全都在」的詭異真相！
另一個話題，有上傳下載，當然也要有匯出目前編輯區的文件了，所以想到就開始實作，同樣也是先選擇 .pdf, .doc 和 .md，.doc 最麻煩，因為格式和樣式會跑掉，又跟 LLM 來回了好多次，
這樣子主體編輯區大概就完成了，不算困難，但也不算輕鬆，如果在都有額度可用的情況下，也是一兩天的事，不禁感嘆出張嘴請 LLM 寫 Code 真是太快了。
總之呢，我就是能列點就列點，出現畫面錯誤就截圖或複製給 LLM 解，每次一點點工作才不會修的難過。
第三需求：登入與分享
接下來就是完全用 google 學 google，因為要做分享，就要做權限，做權限就要有登入，有登入就必須要有登入頁。
然後就發現忘記做真正的資料庫了，也是請 LLM 幫我搜尋免費可用的且有幫忙做 Google 登入的，LLM 幫我找到了 supabase，照著指示一步一步做，不一樣的地方就截圖問，然後回到 Antigravity 說説要做上面那些事資料庫要用supabase ，分享的內容基本就學 google 文件系列，就不多提。
到這邊開始， LLM 基本就會忘東西了，
所以我需要不斷幫 LLM 的知識做溫習，這算是第一個崩潰的點，很難受。
我要跟 LLM 解釋權限與文件檔案是否開啟，還要手動測試各種情況的權限以下情況：
- 邀請 email ，然後區分可檢視還是可以編輯，以及公開連結可預覽
- 外部資源的各個檔案分享 switch 開關，
- 另開視窗單獨 preview 的頁面
截取LLM的最後整理結果：
過程中還碰到了 Cache 問題，總之這裡真的花了超級多 token 和時間，有時候崩潰後檔案太亂了只好又重頭來。所以使用 LLM 一定要特別特別注意版控。
提到版控，說真的，我還真不知道如果不知道怎麼用 git 的話，要怎麼版控會比較好。每次修正前自己手動備份一整包檔案嗎？這樣上下文又會斷掉。然後如果不會 npm 的話又要浪費很多時間詢問跟怎麼做，聽起來就好累。
到這邊我大概可以斷定「只改文案和下 Prompt」這種開發方式真的只適合懂寫程式的人使用，因為很容易忽略版控、固定 LLM 前置知識、開發環境等因素，而且下的 Prompt 會很不精準且有時候根本不知道怎麼提問覺得 LLM 一直在鬼打牆。也就是說，2026上半年還不是人人都可以容易的做出一個商用等級的產品，小打小鬧的方便工具倒是可以。
但是我還是想堅持這樣的方式繼續，除非遇到無法逾越的問題再介入。
Take a Break：稍微整理一下到目前 Vibe 開發體驗心得
- 能列點就列點，一個一個小步驟慢慢列，最好有相關性的列在一起
- 重要的事情必須要強調出來，例如：不要ＸＸＸ
- 請 LLM 先規劃不要實作
- 先規劃 UI 位置、風格
- 再次確認需求規劃有沒有遺漏或沒思考到的事
- 進行實作前先備份或做版控
- 實作後要修改的地方務必非常明確，例如主選單內，Group選單的文字標題，顏色改成ＸＸＸ，並且附上錯誤資訊或截圖
- 實作後要自己要當 QA
- 上線到正式環境後再玩一次
對了，講那麼多好像沒講到上線的事，我是用 Gitlab + Cloudflare，只要透過 LLM 教學基本上都可以架起來，所以就不多著墨這邊的事。
第四需求：簡易文件管理與垃圾桶機制
有了登入頁→執行登入→進到文件列表頁
Hmm…總覺得有點怪怪的，才發現我忘了做資料夾分類和垃圾桶，這邊 LLM 異常的順利，可能是太常見的任務，迅速就將我的需求和我沒想到的需求都一併做好，例如垃圾桶留 30 天刪除、還原、垃圾桶文件數量...諸如此類。反正這邊我也沒有想要做太複雜，跟市面上一樣就好，垃圾桶嘛...還能做什麼？
第五需求：臨時天外飛來一筆試試看的功能
既然都已經用 LLM 開發，那就來設計一下文件內的 LLM 輔助功能吧，規劃如下：
- 在文件編輯器區塊中央下方，浮動一個區塊，裡面是輸入框和按鈕
- 功能是要做一個文件編輯 AI 助手，僅可以輸入文字
- 需要顯示目前使用的是什麼模型
- 建立一個設定頁面，在頁面中有 LLM 不同廠商，使用頁籤方式分隔，並且在頁籤中標示「使用中」跟「未設定」
- 有一個可以讓使用者輸入 LLM API 的輸入框，使用密碼輸入模式，避免有外洩風險
- 每個廠商都要有三個模型和一個自定義模型名稱的下拉式選單，選擇自定義模型後出現另一個輸入框，可以自行輸入模型文字
- 附上取得廠商 API 的教學
- 提供 system prompt 輸入框，並且要有預設的 system prompt 內容，預設內容角色為系統分析師，可以根據使用者 prompt，產出結構嚴謹、技術精確的規格內容
- ai 助手需要讀取當下文件的內容、使用者 prompt 以及 system propmt，並且在原本滑鼠焦點地方，加上 LLM 產出後的結果
- 如果沒有填 API ，ai小助手要有警告，並且是不能用的狀態
- 小助手要可以收合/展開
- 請幫小助手產生使用 LLM 的警語
- ...
大概類似這樣吧，總之其實做一個小小功能，prompt 就要下超級多，這些只是需求而已，還沒有加上其他注意事項（例如順便建立的系統設定頁面），其實說實在也是蠻累的。
第六需求：加入規格書範本
這裡主要是增加一些不同類型的範本，但因為網路上已經很多，所以我先加一點基本的，至少方便什麼都不知道的人能開始，之後我再想想範本還可以做些什麼，
畢竟在這個 LLM 的時代，範本什麼的都只是變成給 LLM 的「規範」遵守，而不是真的拿來用的了。
第七需求：歷史異動與發佈版本
- 在大綱的下方分割出一個「歷史異動」區塊，內容為發佈版本的歷史紀錄，有標題和描述
- 歷史異動項目在新建文件時，自動初始化第一個版本
- 在文件編輯器工具列新增一個「發佈版本」按鈕
- 點擊後開啟對話視窗，可填寫標題和描述，點擊確定關閉對話視窗，新增一筆歷史異動，點擊取消關閉對話視窗不動作
- 點擊歷史異動任一項目，自動與點擊版本的前一版做差異對比，新異動的內容加入背景 highlight，舊內容則透明化
目前都是使用免費的東東，至少可以讓觀看文件者知道兩個版本修改了哪裡，之後真的需要的話，再製作回復到特定版本內容
覺得應該要先解個 Bug 、擴充編輯器功能、重構了
經過以上需求，程式已經變得蠻龐大的了，就需要先解一些 bug、擴充小功能和重構，不然之後的大範圍改動，可能會造成災難。
一開始建立 Tiptap 編輯器時，因為我忘了指定要什麼工具，以下是我的 prompt：
1. 我發現tiptap文件編輯器的工具列沒有連結、文字大小、文字顏色、文字背景以及文字字型。
2. 文件現在內文加上連結時，沒有連結顏色和底線，在螢幕上難以察覺，但是匯出時，不要有連結顏色，但是底線保留
3. 文字字型需要先在此專案加入字型檔嗎？伺服器會不會負擔太重？
4. 圖片上傳後，我需要有地方輸入圖片描述和長描述figcaption，目前是開啟系統資料夾就上傳了，請幫我想個方式輸入這兩個資訊
5. 我還有遺漏什麼常用的工具嗎？
請先幫我思考以上列點，並且做加入這些新功能的規劃
所以 LLM 偷懶只給我幾個常用工具，所以這次把常用但沒加到的都補上，也因為這樣，所以匯出的功能都要重新檢查，然後也發現 LLM 偷懶的很嚴重的一些地方，例如 Dialog 每次都是寫新的，而不是建立一個共用元件來用。
這些就是肉眼可見的不一樣，不需要看程式碼就能明顯察覺，所以又花了一些時間做了這些東西，讓網站的整體一致認性更好，順便多一些小功能：刪除 account、協作時要看到在同一份文件的人、他們的權限以及他們正在哪一行編輯。
第九需求：登入前的介紹產品頁面
剛剛都是 LLM 在偷懶，這是換我偷懶了，登入前的頁面基本都是請 LLM 先理解我的專案，然後我給出我想要的插畫、網站風格以及各區塊要介紹什麼，先做出首頁。
接著補上各種雜項：
- 補上各種分析的工具：GA、GSC、GTM、Microsoft Clarity、Bing Webmaster Tool。
- 補上分析工具用到的 /privacy、/terms 注意事項
- 補上各種 SEO 相關東西：Schema.org、Social Share、Sitemap.xml、Og Image Dynamic、/faq 常見問答
- 最後當然不能忘記無障礙：/sitemap、定位點、Skip to Content、顏色對比、Landmark、Image ALT、HTML Structure...等
第十需求：多國語系
大崩潰！這邊應該卡了 3 天 0 進展，並且耗費完 Google AI Pro 的 Antigravity 額度和 Claude Code 額度，
以下是我最後一次從零進行的 Prompt：
我需要建立多國語言環境，很複雜，請仔細分析以下需求並先做出規劃：
1. 此專案有分為登入前和登入後
2. 請使用 @nuxtjs/i18n
3. 使用者第一次到達網站時，使用使用者瀏覽器的語言呈現
4. 使用者切換語言時，登入前和登入後都一起切換
5. 使用者切換語言後，離開網站再回到網站，語言要保持上次離開的語言
6. 登入前的切換放在header，登入後的切換放在系統設定頁面裡
7. 登入前和登入後的切換器，都是使用 dropdown形式
8. 請依照現在的繁體中文，翻譯成英文，並製作兩者的語言檔案，登入前和登入後的要分開儲存，以便維護
9. 文字過多的靜態頁面，使用新的.vue檔案進行多國語系，不要放在語言檔案裡，以便維護
10. 請將網站內部連結，換成@nuxtjs/i18n 的 localePath() 方式
11. 未來可能有更多語言，請保持擴充彈性，以便維護
12. 路由策略 預設繁體中文不帶前綴 (如 /login)，英文則帶前綴 (如 /en/login)
13. 靜態頁面 (.vue 檔案) 的實作方式採用方案A組件替換
另外請特別注意，我的檔案內已經有做 seo 相關以及 schema.org，在執行多國語言時，請一起納入考量如何修正目前的檔案。
不要隨便刪除我已經做好的功能，除非有特別的情況再跟我討論後再決定執行方式。
以上如果有沒有說清楚或有疑問的地方，請先詢問我，等我說「開始執行」才開始
即便是寫這麼清楚了，還是會有漏改的問題，不過都已經是老生常談的問題了，例如 token用完了換模型接續不上去...等。
這個功能災難般完成後，又遇到 Gemini 全球大當機，我從此轉向 Claude Code，有一種人生真好的感覺，所以之後的內容都比較有我的 Prompt 和 LLM 反問我什麼。
（結果寫文章的當下，有新聞指出全球有 2%的人 Pricing 頁面有看到 Pro 方案不能用 Claude Code 了，心情莫名的悲哀）
第十一需求：留言功能
留言功能，大概 30 分鐘，Claude Code 每一階段的額度用了 88%，驚險完成
我的 prompt 是：我想要做段落層級意見，需求如下：
- 權限唯有登入且可檢視該文件，才可以留言
- 當我將鼠標焦點在該行時，該行最左側有一個評論的icon按鈕，點擊後出現popover可以輸入留言與取消和確定兩個按鈕
- 留言完成後，在分割視窗新增位置在第一個頁籤，這個頁籤顯示留言列表
- 留言列表以卡片呈現
- 留言項目顯示誰留言、留言內容、「執行完成」的按鈕、「不執行」按鈕，點擊按鈕後顯示狀態在卡片內容裡，如果在點擊另一個按鈕，狀態可以更改
- 目前不要支援可以回覆留言
- 當卡片內容還沒更新執行狀態時，文件該行最左方的icon顯示藍色，如果有任何執行動作，則將icon變成灰色。
請根據以上需求，規劃可行性程式做法，並且幫我思考有什麼我遺漏的功能，列出來給我決定。
Claude Code 詢問我
- 權限唯有登入且可檢視該文件，建議有編輯權限的人也可以使用留言。 好的
- 手機無 hover，留言 icon 無法觸發，要如何處理？ 長按段落觸發
- 點卡片捲動到對應段落？是
- 孤兒留言提示？是（就是如果留言的地方被刪掉了）
- Tab 未解決數量 badge？是（就是有多少未解決的留言）
- 即時同步（Realtime)？是
大概修了三次小 bug，都是從文件移動到按鈕 icon 時，icon會突然消失點擊不到。
然後因為做了 RWD，所以現在測試都是花兩倍時間以上在測試，因為有些問題只會在手機上發生，例如長按段落觸發這事，在手機上就會跟原生的「選取」相關的工作列互相衝突。
不過這個複雜的行為瞬間完成，這寫 bug 都不算什麼。
第十一需求：安全性問題
做到這邊其實也差不多要收尾了，所以我就請 Claude Code 幫我抓一下之前 Gemini 寫的程式有什麼安全性問題：
安全性審查報告
P0 — CRITICAL（立即處理）
- .env 中的 Service Key 是否有進入 Git 歷史？
P1 — HIGH
- Image Proxy SSRF
- 帳號刪除 API
- WebSocket token 驗證邏輯
P2 — MEDIUM
- AI API 沒有 Rate Limiting
- Collab Server 沒有連線/訊息大小限制
- Storage API 路徑驗證
- console.log 在生產環境洩漏資訊
P3 — LOW
- v-html 使用
- Auth Middleware 只在 client-side 執行
- Hocuspocus CORS 未設定
不看不知道，一看嚇一跳，還是蠻多要改的，所以 LLM 開發的東西真的是...不知道該怎麼說...因為我也不懂安全性
第十二需求：類似 Notion slash 功能
話說我原本以為 Gemini 已經有做這種功能了，可能在某一次崩潰後沒有重做到，所以又用 Claude Code 重做一次，使用 Claude Code 之後真的很少在修改。
原先我以為像這個功能，我記得 Tiptap 是要付費，後來才發現是用官方做好的才要付費，自己刻不用，
所以就直接請 Claude Code 挑選適合在文件行內使用的工具列，直接幫我做這功能，過程也不重要了，反正是一次到位。
第十三需求：加個 PWA
雖然現在沒什麼人在提這個詞了，但我就是想做，不為什麼，單純就是想要讓「加入主畫面」這件事以及 SEO，但這裡不知道為什麼 Gemini 和 Claude Code 都修到崩潰過，可能是我同時在修 RWD 版面問題，這裡我原本以為很簡單所以就順便版面。
總結
LLM表現
從多國語言開始， Gemini 就已經明顯招架不住了，有很多次甚至卡住老半天，很明顯就是當機了。Claude Code 就是真的穩如老狗，雖然也有崩潰、撞牆幾次，但整體使用上產出的品質與量，都是最棒的！Codex 我倒是還沒試過，現在不想訂閱太多了，之前為了跟上最新的 Modal 到處訂閱，很傷荷包。
如果有機會，我會再想試試看從 Claude Design 到 Claude Code 的流程，因為我有一次工作上懶得畫兩版本 UI，直接把我做好的第一版 UI 丟到 Claude Design，請他幫我換風格跟排版，完美達成，還幫我腦補了一些東西(有好有壞)，但是這種爽感真的幫助我很多(有些業主就是要多種版讓他看)
如果重來一次？
後續跟 LLM 回顧時，LLM 問我：重做一次的話，會選擇「自己做 80%＋ AI 20%」還是又會選擇「完全不碰程式」？
如果是這種小型又複雜的事情，我的結論還是「完全不碰程式」
這次我選擇只碰觸「修改文案」和「prompt」，等於是把所有東西都交給 LLM 自己決定，如果之後的產品(應該說現在就有只是我不想搞到那麼複雜)讓我更能掌握細節控制，例如版片要怎麼排，那我的結論會更堅定站在「完全不碰程式」，因為時間真的是節省太多了，大概我切版的時間＝LLM 完成了這樣一個產品的時間，簡單說這次等於用「精準控制權」換取了「開發生命週期」的大幅縮短。
這樣的產出是不是只能用在 Prototype， 不能真正上戰場？
我個人認為，只要是對現在想改善的東西有幫助，不管醜或美，都能上戰場。
只用來做 Prototype 或 Demo 實在太可惜，這種做出來是真正可以發到市場直接驗證想法，然後快速更改成使用者真正想要的東西，等規模要擴大或是變現流程很穩定，再考慮重新做一個也不遲。
職涯問題
我認為在面對職涯問題時，應該要先問現在的公司有沒有勇氣轉變，才需要談職涯問題。
如果公司有勇氣開始轉變，那麼員工的能力需求就會開始改變：
- 一人開發的小工具：
基本UX 能力，能用白話文清楚表達給 LLM 知道要做什麼。 - 一人開發的小型服務：
懂專案/產品管理＋領域知識＋UX中等能力，能用專業知識、業界術語、經驗表達給 LLM 知道要做什麼，並且能做基本的管理。 - 一人開發的小型複雜服務：
懂專案/產品管理＋領域知識＋UX中等能力+程式/版控基本能力，能用專業知識、業界術語、經驗、程式邏輯請 LLM 思考並知道要做什麼，做不好知道怎麼重做。 - 多人開發的中型服務以上：
抱歉我真的不知道，這方面應該會涉及協作，目前的 LLM 協作工具我沒用過，但我想像可能會是有一個架構師寫完大準則，發下去給中間的架構師討論中小型準則，然後有人輔助檢驗，有點像 Large Scale Scrum (LeSS) 那種感覺，但是人數會少很多，因為一個人能扛的產能多太多了，不過前提是每個人在開發新功能時都有遵循準則。
簡單說，如果是在這種公司裡面，「廣度」類型的人會比較多、「深度」類型的人會比較少(也不用多)，學習程式邏輯不是為了親手打字，而是為了獲得與強大 AI 溝通的權杖。
不過終歸是要回到「公司」個案探討，畢竟行業不同、角色不同、業務方向不同，但如果是新創團隊，我還蠻建議使用新流程、新方法，開創出顛覆現有流程的「破壞式創新」！
牽扯到金流串接與帳務邏輯呢？我敢用這種方式開發嗎？
我很膽小，現階段的我不太敢，但如果有一個懂的人跟我合作，我就敢！
這也就是我上面提到的「多人開發的中型服務以上」這件事，是不是也有人負責檢驗安全和輔助的職位呢？
最後的小知識
你能猜到為什麼這個產品的名稱叫「dahtahdoc」嗎？
因為
.
.
.
.
.
.
.
.
.
.
.
.
在寫「文件」時，鍵盤的敲擊聲「噠踏噠」，
所以網站 dahtahdoc.com 也叫「噠踏噠答Come!」，
「打一打字就文件就完成！」的感覺
都讀到這邊了，別害羞了，免費來試試看嘛！
