理解現場問題
先把「工具很多」翻成管理問題：找不到、看不懂、不敢用、難維護、無法衡量。
Series 02 / 建造方法
我如何建造 SKILL HUB
AI 協助產出規格、實作草稿、測試情境與文件第一版。
方向、邊界、風險收斂與驗證，仍由產品判斷和工程紀律決定。
這一頁不是功能清單，而是建造過程紀錄。它說明我如何把「AI 工具越來越分散」這個部門問題，拆成使用者角色、上架流程、資料欄位、審核狀態、稽核紀錄與導入文件，再逐步補成內部產品。
Field
從現場問題定義產品
AI
輔助規格與文件草稿
Tests
回歸測試保護關鍵流程
Docs
把產品交給不同角色理解
01 // WORKING MODEL
我先把現場問題拆成產品切片
重點不是套用職稱，而是看使用者在哪一步卡住，再把問題切成可以驗證的流程。
這個作品從現場問題開始
一開始的題目不是缺一個網站。問題是 AI Skill、script 和自動化流程開始散落在個人電腦、聊天紀錄、共享資料夾或 repo 裡。團隊需要知道有哪些工具、誰維護、是否經過審核、能不能採用，以及改版後是否影響使用者。
拆出角色流程
把一般使用者、工具作者與管理者分開，避免 catalog、上架與審核流程混在一起。
用 AI 加快草稿
AI 協助規格、欄位、測試情境與文件第一版；重要決策仍回到可驗證的產品邊界。
小步補齊系統
從登入、瀏覽、上架、詳情、審核，到 AI 補值、版本、稽核與後台分析逐步補上。
用測試與文件收斂
當產品變大後，用 node tests、UI tests、e2e、lint、build 與手冊保護可維護性。
02 // CASE NOTES
四個能代表建造方式的例子
這些例子來自產品接近真實使用時遇到的限制：上傳大小、改名回歸、AI 補值邊界與導入文件。
上傳限制不是只改錯誤訊息
我檢查作品上傳流程時，發現產品說法、前端限制、API 行為和 Vercel Functions request body ceiling 沒有完全對齊。
最後把 same-origin package / media upload 的安全上限收斂到 4 MB，並留下 direct-to-storage upload 作為大型封裝的後續方向。
改名後不能只搜尋取代
產品從 vibeHub 轉成 SKILL HUB 時，影響不只頁面文案。環境變數、cookie、header、下載包、helper script 與測試都可能被牽動。
我保留 `VIBEHUB_` env var 作為部署契約，並修掉 rename 後 hyphen 在 JavaScript 使用上的 runtime 風險。
AI 補值要有可控邊界
SKILL HUB 會讀作者上傳的 `SKILL.md` 並用 AI 協助產生摘要、標籤與速讀欄位，但上傳內容本身不可信。
因此 AI 只產生草稿與輔助說明；上架仍由掃描、審核、版本快照、稽核紀錄與人工確認收斂。
同一個產品要講給不同人聽
我整理了快速手冊、作者上架指南、管理者後台說明、主管推廣稿與策略筆記，讓產品不是只有功能可以打開。
這些文件讓使用者知道怎麼開始，管理者知道怎麼審核，主管知道它解的是哪一段組織問題。
03 // AI BOUNDARY
AI 幫我加快，但不替我做最後判斷
這段交代責任分工：AI 可以產草稿，我負責範圍、邊界、測試與最後發布判斷。
AI 協助規格與文件第一版
整理需求、起草手冊、生成測試情境、輔助欄位補值與流程摘要。
我負責問題定義與產品範圍
決定平台先做治理、知識化、分發與採用追蹤，不急著做完整 execution engine。
AI 提供實作選項與草稿
協助產生 UI copy、欄位模型、測試草稿與文件架構，縮短探索時間。
我負責架構取捨與驗證
用 same-origin BFF、審核狀態機、稽核紀錄、quota、lint、build 與 e2e 測試保護邊界。
AI 幫作者減少填表負擔
從 `SKILL.md` 產生摘要、標籤與速讀欄位，讓作者從空白表單改成覆核草稿。
人保留審核與發布責任
AI 分析結果不是上架權威；正式公開仍要經過 server-side scan、Admin review 與版本紀錄。
04 // PROOF
我用驗證與文件保護成果
SKILL HUB 不是展示完就結束的 demo。它會持續改、被使用、被審核，也會遇到平台限制和 rename 這類回歸風險。
- 近期驗證包含 node tests 414 passed、UI tests 107 passed、critical upload-scan-approve e2e 2 passed。
- `npm run lint` 與 `npm run build` 已納入週期性驗證紀錄。
- README、快速手冊、上架指南、後台說明與主管推廣稿同步維護。