跳到主要內容

部落格

不定期分享最新資訊文章

Frank Chiu

徐享／享哥

AI應用規劃師

具有 10 年經驗在數位行銷與電商廣告領域，專精生成式AI應用與個人資料保護，致力於以獨特商業洞察與實戰案例研討，助力品牌突破成長瓶頸。

分類

標籤

AI工具 (94) ChatGPT (21) 商業策略 (34) AI自動化 (95) AI Agent (51) SEO (13) AEO (8) 內容行銷 (28) Cursor (2) Vibe Coding (45) Codex (17) MCP (3) 職場溝通 (3) 影音行銷 (56) AI Coding (2) Gemini (12) Meta Ads (1) Higgsfield (1) AI風險控管 (5) NotebookLM (1) GEO (1) AI繪圖 (9) n8n (29) API串接 (13) 社群行銷 (4) 自動化講師應用 (6) 社群自動化 (1) Facebook機器人 (1) RAG (1) VLM (1) 向量資料庫 (1) Cloudflare (6) Claude (6) Claude API (1) AI創業 (1) 工作流 (1) 享哥宇宙 (10) 科幻喜劇 (8) AI故事 (8) Seedance (2) 技術選型 (1) Electron (1) Tauri (1) 奇幻喜劇 (2) 台灣民間信仰 (2) Git (1) 知識變現 (4) Google (1) Google Colab (1) Google Vids (1) GSAP (1) n8n新手教學 (11) Zeabur (1) Remotion (2) Antigravity (1) 前端架構 (1) PWA (1) 資料處理 (1) 個人品牌 (1) Power Automate (1) Playwright (1) LINE (1) 雲端部署 (1)
  • article-Vibe Coding 新手教學：Void 是什麼？Vinext 又是什麼？用 Codex 建站與選擇 Cloudflare 部署

    2026/10/18

    AI工具 Vibe Coding Cloudflare
    Vibe Coding 新手教學：Void 是什麼？Vinext 又是什麼？用 Codex 建站與選擇 Cloudflare 部署

    最近看到 MUKI WU 分享影片《Vite 被 Cloudflare 買了？Void 開源能取代 Vercel 嗎？》，我也開始研究 Void 和 Vinext。 這兩個名稱都和 Vite 有關，也都出現在 Cloudflare 的開發工具消息裡，但它們解決的問題並不相同。Void 適合從 Vite 專案開始，整合全端功能與部署；Vinext 則讓既有 Next.js 專案改用 Vite 工具鏈。 這篇會用一個新手能跟上的例子，帶你用 Codex 建立 Void 練習網站，再認識什麼時候才需要研究 Vinext。安裝與指令依本文整理時的官方文件編寫；文章中的範例不是每種環境都已實機驗證，實際操作仍要以所安裝版本的文件為準。 Vite、Void、Vinext、Vercel 和 Cloudflare 有什麼不同？先把幾個常一起出現的名稱分開看： 名稱 主要工作 可以先這樣理解 Vite 網頁開發伺服器與建置工具 協助開發、即時預覽和打包網頁 Vite+ 整合 JavaScript 開發工具鏈 把建置、測試與程式碼檢查等工具放在一起 Next.js React 全端框架 提供頁面路由、伺服器渲染等網站開發功能 Vinext 以 Vite 重新實作 Next.js API 的外掛 讓既有 Next.js 專案有機會改由 Vite 工具鏈執行 Void Vite 全端 SDK、CLI 與部署平台 協助建立 API、連接資料資源並部署 Vite 應用 Vercel 雲端部署與代管平台 提供部署、預覽和團隊開發流程 Cloudflare 雲端基礎設施與全球網路平台 提供 Workers、D1、KV、R2 等服務 **Void 和 Vinext 不是同一種工具。**Void 的重點是從 Vite 應用出發，建立全端功能並管理部署；Vinext 的重點是讓 Next.js 專案沿用熟悉的應用目錄結構，改由 Vite 處理建置與執行。 Cloudflare 在 2026 年 10 月介紹 Void 時，說明 VoidZero 已加入 Cloudflare，並公開 Void SDK、CLI 和 Platform。這不代表 Vite、Void 和 Vinext 是同一個產品，也不代表原有的 Vite 專案會自動變成 Void 專案。Cloudflare 的 Void 公告 用一句話記住它們的差異 Vite：負責開發和建置前端應用。 Void：在 Vite 工作流上加上全端路由、資源管理與部署。 Vinext：讓 Next.js 專案改用 Vite 工具鏈，並保留大量 Next.js 開發介面。 Vercel 和 Cloudflare：提供網站部署及執行所需的雲端服務。 Void 不是 Vercel 的直接替代品，Vinext 也不是把所有 Next.js 專案自動搬到 Cloudflare 的保證。選擇時應先看手上的專案、需要的功能和可接受的遷移成本。 為什麼 Void 適合拿來學習 Vibe Coding？假設你想請 Codex 做一個活動報名網站。它可能需要網頁表單、API、資料庫和部署環境。過去，這些部分常要分別設定；Void 的目標是把 Vite 應用和 Cloudflare 資源放進較連貫的開發流程。 Void 主要由三個部分組成： Void SDK：在 Vite 專案中開發前端、伺服器路由及資源操作。 Void CLI：初始化專案、建置、建立或綁定 Cloudflare 資源、套用資料庫遷移並部署。 Void Platform：供團隊共用的部署平台，可自行架設並設定使用者權限和資源限制。 初學者通常可以先從 SDK 和 CLI 開始，不需要一開始就安裝團隊用的 Platform。你可以先在自己的 Cloudflare 帳號裡建立一個小型練習，再視需要研究共用平台。 Void 的功能可以組合使用，也能和一些既有的 Vite 架構合作。不過官方目前將 Vinext adapters 列為實驗性支援；第一次學習時，先分開理解 Void 和 Vinext，會更容易判斷問題來自哪一層。Void Cloudflare 整合說明 如何在 Mac 安裝 Void 並建立第一個專案？以下範例以 macOS 和 npm 說明。你需要 Node.js、終端機和 Void；若要部署到 Cloudflare，還需要 Cloudflare 帳號。Void 官方目前要求 Node.js 24.21.0 以上版本，其他作業系統也可依官方支援條件操作。Void 官方 GitHub 先確認 Node.js 版本打開 Mac 的「終端機」，輸入： 12node -vnpm -v 若 Node.js 版本低於 Void 目前要求的版本，請先更新。若你電腦上有其他 Node.js 專案，可以用 nvm 管理多個版本，避免更新後影響舊專案。 建立練習資料夾並初始化在終端機輸入： 1234mkdir void-playgroundcd void-playgroundnpm install -D voidnpx void init 初始化指令會啟動設定流程，讓你選擇 UI 框架、起始範本和部署目標。Void 的 Vite+ 工具鏈是預設選項；如果只想先在本機學習，可以先略過部署設定。Void Quickstart 這篇用活動報名系統作為範例，可以選擇下列方向： 設定項目 練習選擇 適合原因 Toolchain Vite+（預設） 使用 Void 提供的整合工具鏈 Frontend React 建立常見的互動式網頁 Starter D1 練習網站、API 與 SQL 資料庫 Deployment Cloudflare 之後可部署到自己的 Cloudflare 帳號 初始化時，Void 也會準備 Agent 可讀的專案指引。若要重新設定 Codex 等 Coding Agent，可以在專案根目錄執行： 1npx void init --agents 它會建立或更新 AGENTS.md，並依照可偵測到的 Agent 設定連結對應技能；這樣 Codex 可以讀取專案所安裝版本的 Void 文件，而不是只依賴模型記憶。Void Coding Agents 指南 在本機啟動網站和 API初始化完成後，在專案資料夾輸入： 1npm run dev 依照終端機顯示的網址開啟瀏覽器，Quickstart 範例通常使用： http://localhost:5173 如果範本沒有 API 範例，可以新增 routes/api/hello.ts： 1234567import { defineHandler } from 'void';export const GET = defineHandler(() => { return { message: 'Hello from Void' };}); 再打開： http://localhost:5173/api/hello 你會看到類似以下 JSON： 123{ "message": "Hello from Void"} 這個路由的檔案路徑對應到 /api/hello，而 GET 表示用讀取方式回傳資料。Void 的官方 Quickstart 使用相同的入門範例；各種範本的檔案是否已預先建立，則要依初始化結果確認。Void Quickstart：呼叫伺服器路由 如何用 Codex 開發一個報名網站？先把剛剛的 void-playground 專案開在 Codex。接著可以把以下提示詞貼給 Codex，請它先閱讀專案說明和已安裝版本的 Void 文件： 1234567891011121314151617181920212223242526272829你是一位熟悉 Void、React、TypeScript 與 Cloudflare Workers 的全端工程師。請先閱讀專案中的 AGENTS.md，以及 node_modules/void/ 內目前安裝版本的官方文件，再開始修改程式。我要建立一套簡單的活動報名網站。前台功能：1. 顯示活動名稱、日期和地點。2. 提供姓名與 Email 欄位。3. 在瀏覽器與伺服器端檢查必填欄位和 Email 格式。4. 成功寫入資料後，再顯示報名完成訊息。後端功能：1. 使用 Void 官方伺服器路由。2. 使用 Cloudflare D1 儲存報名資料。3. 使用資料庫 migration 管理結構變更。4. 防止同一個 Email 重複報名。管理功能：1. 管理頁必須有身分驗證和權限檢查。2. 未完成授權前，不能公開報名名單或 Email。開發規則：1. 優先使用專案已安裝版本的官方 API。2. 不要使用過時的 Void 語法。3. 不要建立不必要的第二套伺服器或部署流程。4. 先在本機完成開發與檢查，不要直接修改正式環境，也不要擅自部署。完成後請說明建立了哪些檔案、API 如何運作、資料存在哪裡、如何在本機測試，以及部署前還需要確認什麼。 接著你可以在瀏覽器測試表單，並確認資料真的寫進本機 D1。不要只看畫面有沒有出現「報名成功」，還要檢查 API 回應和資料庫內容。 正式網站也需要補上個資告知、垃圾報名防護和管理者權限。練習時不要使用真實的客戶資料，也不要把公開的名單頁當成登入驗證。 如何將 Void 網站部署到 Cloudflare？本機功能確認完成後，若初始化時已選 Cloudflare 作為部署目標，可執行： 1npx void deploy 若當時略過部署設定，也可以指定 Cloudflare： 1npx void deploy --platform cloudflare 首次部署時，Void 可能會開啟瀏覽器要求登入並選擇 Cloudflare 帳號。CLI 會建置應用、建立所需資源、套用 migrations 並回報部署網址。Void 的 Cloudflare 部署指南 部署後可到 Cloudflare 控制台的 Workers & Pages 檢查 Worker 狀態；若使用 D1，也要確認資料庫已建立並收到測試資料。本機 D1 與正式環境的 D1 是不同資料庫，本機測試資料不會自動複製到正式環境。 部署前也要檢查 migration。程式碼回復到舊版本，不代表資料庫結構會自動回到舊狀態。第一次公開部署前，先理解哪些資源會建立、資料存在哪裡、帳號目前使用的方案與額度。 Vinext 是什麼？什麼時候才需要它？Vinext 是一個以 Vite 重新實作 Next.js API 的 Vite 外掛。它的目標是讓既有 Next.js 專案能保留許多熟悉的路由、元件和設定方式，再透過 Vite 建置並選擇合適的部署平台。 **如果你從零開始做一般 Vite 網站，通常不需要先安裝 Vinext。**它主要適合已經有 Next.js 專案、想評估 Vite 工具鏈或 Cloudflare Workers 部署的開發者。 怎麼辨認既有專案是不是 Next.js？可以查看專案根目錄的 package.json。如果依賴中有 next，通常就是 Next.js 專案。app/、pages/ 和 next.config.js 或 next.config.ts 也常見於 Next.js 專案。 如何先檢查相容性，再試用 Vinext？不要直接在正式專案上遷移。先建立 Git 備份或測試分支，再在專案目錄執行： 1npx vinext check 這會掃描部分已知相容性問題。檢查結果不能代替完整測試，但可以先找出值得注意的差異。 若要建立 Vinext 設定，可接著執行： 1npx vinext init Cloudflare 文件中的典型流程會加入 dev:vinext 和 build:vinext 等 scripts。初始化後請先檢查 package.json，再依實際產生的指令啟動開發伺服器與正式建置： 12npm run dev:vinextnpm run build:vinext 部署到 Cloudflare Workers 的範例指令是： 1npx @vinext/cloudflare deploy 詳細流程請參考Cloudflare 的 Next.js／Vinext 指南。Cloudflare 也提供建立 Cloudflare-ready 專案的 C3 流程；若你是在既有 Next.js 專案上遷移，請以目前文件和 vinext init 的輸出為準。 Vinext 1.0 是否代表完全相容 Next.js？不是。Vinext 在 2026 年 9 月發布 1.0，代表它自身的公開 API 開始依循穩定版本規則；這不等於所有 Next.js API 和功能都已完整相容。官方文件仍列出部分功能差異，包括 Cache Components 和 Partial Prerendering，遷移正式網站前應查看相容性差異並實際測試。Vinext 1.0 說明・Vinext 相容性差異 Cloudflare 目前推薦在 Workers 上評估 Vinext；如果既有應用仍有相容性缺口，也仍保留 OpenNext adapter 等其他路徑。若網站只需要靜態輸出，Cloudflare Pages 也是另一種情境。選擇前先看專案實際用到的功能，不要只根據版本號或建置速度決定。 Vibe Coding 專案該選哪一種架構？可以先用下面幾種情境縮小範圍： 專案情境 可以先評估 選擇時要注意 品牌網站、作品集、簡單活動頁 Vite + 靜態網站代管 如果沒有後端資料需求，不必增加全端架構 從零開始做表單、預約或內部工具 Void + Vite + Cloudflare Workers + D1 確認資料庫、使用權限、個資與資源額度 已有 Next.js 專案，想評估 Workers Next.js + Vinext + Cloudflare Workers 先跑相容性檢查，測試實際使用到的功能 已有穩定的 Worker + D1 維持現有架構，按需要改善 不要只為了新框架而重寫 有會員、訂單、金流或多人維護需求 先定義資料、權限、金流與維運需求 需要比較完整架構與維護成本，不能只看部署一鍵化 簡單來說：從零開始、想在 Cloudflare 上建立 Vite 全端應用，可以研究 Void；已經有 Next.js，才需要評估 Vinext；既有系統運作正常，就先確認遷移能解決什麼問題。 若專案已經使用 Next.js 並依賴特定功能，可以比較 Vinext 的相容性差異，或繼續評估 OpenNext 等現有部署方式。Void 對 Vinext 的 adapter 目前仍是實驗性支援，正式系統要先做獨立驗證。Void Cloudflare 整合說明 開始寫程式前，先請 Codex 做技術選型把需求交給 AI 後，不一定要馬上讓它寫程式。你可以先請 Codex 說明架構選擇、風險和還需要確認的資訊： 123456789101112131415161718你是一位熟悉 Vite、Next.js、Void、Vinext、Cloudflare 與 Vercel 的技術架構顧問。我準備建立一個網站。請先詢問並整理：1. 網站主要用途。2. 是否需要會員、資料庫、檔案上傳或金流。3. 是否已有現成專案，以及目前使用的框架。4. 是否指定部署平台、團隊流程或預算範圍。在開始寫程式前，請評估以下選項是否符合需求：A. Vite + 靜態網站代管B. Void + Cloudflare WorkersC. Next.js + Vinext + Cloudflare WorkersD. Next.js + VercelE. Cloudflare Worker + D1請比較學習成本、現有專案相容性、部署與維護需求、資料庫和權限設計，以及遷移風險。區分官方已說明的能力和仍需實測的部分。先提出推薦方案、理由和待確認事項；等我確認後再開始修改程式。不要直接部署正式環境。 這段提示詞不保證 AI 每次都選對架構，但能讓你在程式碼產生前先看見方案取捨。架構不複雜時，也可以直接沿用熟悉且已運作穩定的工具。 新手可以怎麼安排學習順序？如果要安排一門 Vibe Coding 入門實作課，我會拆成四個階段： 先做一個簡單網站：用 Codex 和 Vite 建立互動網頁，認識本機開發與正式網站的差異。 再加入 API 和資料庫：用 Void 建立表單、路由和 D1，確認資料如何從前端寫進資料庫。 了解部署與環境：學習 Workers、D1、環境變數和 migration，理解測試資料與正式資料的區別。 最後看既有 Next.js 專案：用測試分支檢查 Vinext 相容性，再比較不同部署路徑。 這個順序會先建立網站與資料的基本概念，再逐步加入部署和遷移。新手不必在第一天就同時學會 Vite、Void、Vinext、Next.js、資料庫、Docker 和雲端維運。 常見問答 (FAQ)Q1：Void 免費嗎？使用 Void 會不會產生 Cloudflare 費用？Void SDK、CLI 和 Platform 的原始碼以 MIT 授權公開，但 Cloudflare Workers、D1、R2 等雲端服務仍有各自的方案、額度和使用條件。軟體開源不代表雲端資源無限制免費；部署前請查看 Cloudflare 目前的方案與服務用量。 Q2：使用 Void 一定要架設 Void Platform 嗎？不需要。個人專案可以用 Void SDK 和 CLI，部署到自己的 Cloudflare 帳號。Void Platform 主要提供團隊共用的部署環境、權限和資源管理功能。 Q3：Void 可以完全取代 Vercel 嗎？不能一概而論。Void 適合需要 Vite 全端功能並希望部署到 Cloudflare 的情境；Vercel 有自己的 Next.js 整合、預覽部署和團隊工作流程。應依專案需求、既有架構和維護方式比較，而不是只看平台名稱。 Q4：Next.js 專案可以直接改用 Vinext 嗎？不能保證直接替換就能運作。Vinext 提供相容性檢查與遷移指引，但仍有尚未完整支援的 Next.js 功能。先備份專案、執行 npx vinext check，再在測試分支驗證實際使用的頁面、資料載入、快取與部署行為。 Q5：Void 和 Vinext 可以一起使用嗎？可以把兩者放在同一個架構評估中，但 Void 官方目前將 Vinext adapters 標示為實驗性支援。入門時先分開學習兩者；若要整合到正式專案，請查閱相同版本的官方文件並自行完整測試。 結語：AI 幫你寫程式，選型仍需要理解Void 和 Vinext 代表兩種不同的開發需求：Void 把 Vite 全端應用、Cloudflare 資源和部署流程連在一起；Vinext 則讓既有 Next.js 專案有機會改用 Vite 工具鏈。 使用 Codex 或其他 Coding Agent 時，不妨先確認網站是否需要後端、資料應存在哪裡、誰能存取資料，以及部署後由誰維護。AI 可以協助你寫程式，工具可以簡化部署，但是否值得採用某個架構，仍要回到專案本身。 如果你想先補上 Vibe Coding 的基礎，可以接著閱讀從零開始用 AI 寫程式的 Vibe Coding 指南；若想了解 Cloudflare 專案的 API 與安全考量，也可以參考Vibe Coding、Cloudflare API 與安全設定。 官方學習資源本文依據 2026 年 10 月 18 日可查閱的官方文件整理；指令和功能可能隨版本更新，請以安裝版本的文件為準。 Void 與 Cloudflare： Void 官方網站 Void Quickstart Void Coding Agents 指南 Void Cloudflare 整合與限制 Void 官方 GitHub Cloudflare：Deploy with Void Cloudflare Workers 文件 Cloudflare D1 文件 Vinext： Vinext 官方網站 Vinext 1.0 說明 Vinext 文件 Vinext 相容性差異 Cloudflare：Next.js 與 Vinext 部署指南 Node.js： Node.js 下載頁面

  • article-AI 讓寫程式越來越便宜，但真正值錢的是產品判斷力

    2026/10/16

    AI工具 Vibe Coding AI Coding
    AI 讓寫程式越來越便宜，但真正值錢的是產品判斷力

    AI Coding、Vibe Coding 讓更多人做得出網站、系統，甚至一個完整的 SaaS。當開發速度愈來愈快，真正該問的問題也跟著改變：我們做出來的功能，真的有人需要嗎？ 我最近讀到一篇文章，標題是〈功能變便宜了，判斷力變貴了：AI 時代的兩張地圖〉。文中用一個產品團隊的情境開場：導入 AI Coding Agent 後，團隊每個 Sprint 能完成的功能增加了，轉換率卻沒有提升，客訴反而增加。有人因此說：「我們好像只是把『做錯的東西』做得更快而已。」 這是原作者設定的情境，不是實際研究數據；但它提醒了我，做得出來，不代表有人需要。 AI 降低了實作門檻，沒有替我們確認需求以前做網站或開發系統，常見的難題是「做不出來」。現在有了 Codex、Claude Code 等 AI Coding 工具，即使不是專業工程師，也能更快做出過去需要整個團隊才能完成的功能。 但技術門檻降低，不會自動讓產品更符合需求。若只是把想像中的功能快速做完，可能只是更快地解決一個尚未證實的問題。 先用兩張地圖看清楚問題與解法Customer Journey Map：找出使用者在哪裡卡住Customer Journey Map（顧客旅程地圖）從使用者的角度，整理他接觸產品、評估、購買、使用到後續服務的過程。它協助團隊找到使用者在哪一段遇到疑問或阻礙，而不是一開始就列出想開發的功能。 例如，有人看到 AI 課程介紹後進入網站，可能想知道課程適不適合初學者、實體課與錄播課有什麼差別、購買後能觀看多久，或臨時無法上課時該怎麼辦。這些疑問不一定需要新功能；清楚的文案、簡化的購買流程或一段 FAQ，也可能更直接地解決問題。 User Story Map：把使用者目標拆成可交付的步驟User Story Map（使用者故事地圖）則從使用者想完成的目標出發，把過程拆成活動、步驟與支援功能，接著安排 MVP 先做哪些、哪些留待後續。 以報名課程為例，學員可能需要瀏覽課程、比較方案、完成付款、收到通知，最後取得上課權限。整理出這些步驟後，團隊才能討論第一版要支援哪些必要流程。 簡單來說，Customer Journey Map 協助我們發現問題，User Story Map 協助我們規劃解法，AI 則可以協助實作。 AI 能整理需求，也會把假設寫得像事實假設你告訴 Codex：「我要開發線上課程平台，學員應該很在意學習證書，請幫我規劃完整的證書系統。」AI 可能很快列出自動發證、QR Code 驗證、證書下載、公開查詢與管理後台，而且規格看起來完整又合理。 但在投入開發前，仍要確認學員是否真的需要證書。如果他們更在意課程內容是否實用、影片能不能重複觀看，那套證書系統可能只是解決了我們想像中的問題。 AI 可以協助整理需求，卻不能代替真實資料。沒有訪談、客服紀錄、行為數據或其他證據支持的需求分析，仍然只是待驗證的假設。使用者遇到問題，也不代表一定要增加功能。 從 Story Map 再往下寫成開發規格User Story Map 能說明使用者想完成什麼，卻未必包含 AI Coding Agent 實作所需的細節。 例如，「身為學員，我希望購買課程後可以觀看教學影片」還需要回答：影片放在哪裡？付款失敗怎麼處理？觀看權限如何判斷？課程到期後會發生什麼事？直播回放尚未發布時要顯示什麼？ 這些細節需要進一步整理成開發規格（Spec）、業務規則與驗收標準。可以先用 Journey Map 和 Story Map 理清方向，再讓 AI 協助產出詳細規格，而不是直接開始寫程式。也可以把產品規劃整理在 docs/product/，並透過 AGENTS.md 指引 Codex 閱讀相關背景，讓它理解功能的目的與前後流程。 再加一張成果地圖，確認功能是否真的有用我還會多問一個問題：功能完成後，我們怎麼知道它改善了使用者的處境？我把這個思考方式稱為 Outcome Map（成果地圖）；這是本文用來描述成果導向規劃的方式，不是某套特定的標準工具。 假設學員常因為看不懂購買方案而猶豫，團隊決定把三種方案的權益說明得更清楚。完成方案比較頁只是交付了功能，接著還要觀察學員是否更容易選擇、付款完成率是否有改善、詢問方案差異的客服訊息是否減少。這些是要驗證的結果，不是預先保證會發生的成效。 規劃工具 協助回答的問題 Customer Journey Map 使用者在哪個階段遇到問題？ User Story Map 使用者要完成目標，需要哪些步驟與支援？ Outcome Map（本文的延伸用法） 我們要觀察什麼，才能判斷改善是否有效？ 根據實際觀察再決定下一個版本要改什麼，才不會落入「想到功能、交給 AI、開發完成、再想到新功能」的循環，讓網站愈做愈大，卻說不清楚改善了什麼。 下次使用 Codex，先請它協助規劃與其一開始就說「幫我做一個有會員、金流、後台和課程管理的網站」，不妨先用一段提示詞，要求 AI 整理需求、假設、MVP 與驗收方式： 先不要寫程式。請扮演產品經理與 UX 顧問，協助我分析目標使用者、使用情境及主要痛點。請區分已知事實與待驗證假設，建立 Customer Journey Map 和 User Story Map，規劃 MVP，並提出每項功能的驗收標準與成功指標。最後告訴我哪些功能目前不建議開發，以及原因。等我確認規劃後，再開始寫程式。 這樣可以讓 AI 先協助思考需求、檢查假設與規劃產品，再進入開發。最後是否採納規劃、是否真的要做，仍然需要由我們判斷。 功能愈容易開發，愈要考慮維護成本程式碼變便宜，不代表維護系統也變便宜。每增加一個功能，都可能帶來資料庫、權限、測試、資安、客服與後續維護工作。透過 AI Coding 一個人能做更多事，也可能變成一個人要維護更多複雜系統。這和我在 AI Coding 技術債：寫程式快 10 倍，Temporary Fix 也可能快 10 倍 談到的維護問題相通。 AI 時代需要培養的不只是 Prompt 技巧或寫程式的能力，也包括產品判斷力：理解使用者遇到什麼問題、判斷哪些事情值得做、哪些可以先不做，並設法驗證結果。若你正在從想法評估產品，也可以延伸閱讀如何從產業痛點找到值得做的微型 AI 產品。 以前軟體開發最怕「想得到，卻做不到」。現在更值得警惕的是「想得到，也做得到，卻沒有人需要」。未來厲害的 AI 開發者，未必是一天讓 Codex 寫出一百個功能的人，也可能是能判斷哪些功能根本不需要寫的人。 產品的價值，從來不是功能有多少，而是解決了多少真正的問題。 📌 閱讀啟發：〈功能變便宜了，判斷力變貴了：AI 時代的兩張地圖〉。本文從原作者對 Customer Journey Map 與 User Story Map 的討論出發，延伸分享我對 AI Coding、需求驗證、開發規格與產品成果衡量的看法。 標籤： #AICoding #Codex #ClaudeCode #VibeCoding #產品思維 #CustomerJourneyMap #UserStoryMapping #AI應用 常見問答 (FAQ)Q1：Customer Journey Map 和 User Story Map 有什麼不同？Customer Journey Map 從使用者經歷出發，幫助找出旅程中的疑問與阻礙；User Story Map 則把使用者目標拆成活動、步驟與支援功能，協助安排 MVP 與後續工作。 Q2：User Story Map 可以直接交給 AI Coding Agent 開發嗎？它能提供使用者目標與流程脈絡，但通常還需要補上開發規格、業務規則、錯誤情境與驗收標準，例如付款失敗、觀看權限或課程到期時要如何處理。 Q3：文中提到的 Outcome Map 是標準產品工具嗎？不是。本文以 Outcome Map 稱呼「定義功能完成後要觀察哪些使用者或業務結果」的思考方式，並明確將它作為作者的延伸用法，而非特定標準工具。 Q4：AI Coding 讓開發成本趨近於零了嗎？AI Coding 可以降低部分實作成本，但不會讓資料、權限、測試、資安、客服與維護工作自動消失。每個新功能仍要評估它帶來的長期成本與實際價值。

  • article-Codex 新手教學：用 3 個 Markdown 檔案讓 AI 接續你的專案

    2026/10/16

    AI工具 Vibe Coding Codex
    Codex 新手教學：用 3 個 Markdown 檔案讓 AI 接續你的專案

    昨天才和 AI 討論好網站要做什麼，今天開啟新對話，它卻又問：「你想做什麼網站？」 或者，原本用 Claude Code 寫到一半，想換 Codex 接手，卻得把需求、決策和目前進度重新說一次。更麻煩的是，明明已經說過某個功能不要做，換個對話，AI 又把它加回來。 對剛開始學 AI Coding 的人來說，有個實用的習慣：把重要的專案資訊寫進檔案，讓每次工作的 AI 都能重新讀取。 這篇不教複雜語法，也不需要先安裝外掛。我們會用一個簡單的網站練習，建立三份 Markdown 文件，並準備「初始化、開工、收工」提示詞，讓新對話有機會從上次的進度繼續。 三個 Markdown 檔案各自負責什麼？這個做法參考三師爸 Sense Bar 在「AI Agent 基本功」EP06 分享的跨電腦專案管理流程，再加上一份 project.md，把長期需求和每天的工作進度分開。 檔案 可以把它想成 記錄內容 project.md 專案企劃書 專案目標、使用者、已確認需求、暫不處理的項目、重要決策和驗收標準 AGENTS.md AI 工作守則 AI 在這個專案裡要遵守的規則，以及需要讀取哪些文件 handoff.md 工作交接簿 目前進度、已驗證與未驗證項目、問題、下一步和最後更新時間 三份檔案都是純文字 Markdown，可以用文字編輯器打開。你不必先學會 Markdown；用一般文字和標題整理內容就能開始。 其中，AGENTS.md 是 Codex 支援的指示檔，Codex 會依照檔案所在位置讀取適用的專案指示。project.md 和 handoff.md 則是我們自行約定的檔名；若希望 AI 使用它們，請在提示詞中要求讀取，或在 AGENTS.md 裡清楚指示何時讀取。OpenAI 官方文件也說明了 Codex 如何發現 AGENTS.md。 第一次實作：先建立專案文件我們用「製作一個 AI 入門課程介紹網站」當作練習。先在 Finder 建立一個資料夾，例如 my-first-ai-website，接著在 ChatGPT 桌面版中選擇這個資料夾作為工作位置，並在新對話中選擇 Codex。介面名稱可能隨版本調整；官方 Codex Quickstart 有目前的桌面版入門說明。 第一步先不要叫 AI 寫網站，請它建立需求和交接文件。可以貼上這段提示詞： 提示詞 ①｜初始化我的第一個專案 12345678910111213141516171819202122232425262728293031323334353637383940414243你現在是我的 Codex 入門教練。我完全不懂程式設計，請用台灣繁體中文、新手能理解的方式協助我。我要建立一個「AI 入門課程介紹網站」。目標：讓一般人可以透過網站了解課程內容，包含課程介紹、學習特色、適合對象、常見問題及聯絡方式。請先不要製作網站程式。第一步，請確認目前專案的工作目錄。第二步，在專案根目錄建立三份 Markdown 文件：1. project.md記錄專案目標、目標使用者、確定要做的功能、暫時不做的功能、重要決策及驗收標準。2. AGENTS.md記錄 AI 工作規則。要求 AI 在接續任務時，按需要讀取project.md 和 handoff.md。不得擅自增加功能、改變已確認需求，或把尚未完成的工作說成已完成。3. handoff.md記錄目前進度、完成事項、驗證狀態、待辦事項及下一步工作。第三步，說明這三份文件各自的用途。要求：- 不要安裝任何套件- 不要部署網站- 不要推送到 GitHub- 不要修改專案資料夾以外的檔案- 如果已有同名文件，先檢查，不要直接覆蓋- 完成後確認三份檔案確實存在 這段提示詞也要求 AI 確認工作目錄、檢查同名文件，並在完成後確認檔案確實存在。AI 在聊天裡說「完成」不代表檔案已經寫入；可以回到 Finder，確認資料夾裡看得到： 1234my-first-ai-website/├── AGENTS.md├── project.md└── handoff.md 文件準備好後，再請 AI 製作網站三份文件建立後，請 AI 先讀取規格，再依規格動工。這能讓已確認的需求和限制比較容易帶進下一步。 提示詞 ②｜按照專案規格製作網站 12345678910111213141516171819202122請先讀取 project.md、AGENTS.md和 handoff.md，確認目前的專案目標與限制。接著開始製作第一版網站。需求：1. 使用 HTML、CSS 和必要的 JavaScript2. 暫時不使用資料庫或後端服務3. 網站要有課程介紹、課程特色、 適合對象、常見問題、聯絡方式4. 使用繁體中文5. 電腦與手機都要能正常閱讀6. 版面簡潔、專業，適合 AI 入門課程7. 聯絡功能先使用示範內容， 不要假裝已經完成正式報名或付款系統完成後：- 確認程式檔案已建立- 檢查是否有明顯錯誤- 告訴我如何在 Mac 上開啟網站- 區分已驗證與尚未驗證的功能- 用新手能理解的方式解釋結果 網站完成後，可以依照 AI 提供的方法預覽，再把瀏覽器視窗縮小，檢查手機版是否容易閱讀。如果發現 FAQ 字太小，可以具體要求：「手機版 FAQ 文字太小，請加大字體、調整行距，但不要修改其他區塊。」 用自然語言描述想看到的結果，是 AI Coding 對初學者很有幫助的地方；仍要親自檢查畫面和功能，不能只看 AI 的完成摘要。 每天結束前更新交接簿準備休息時，請 AI 根據專案檔案和實際成果更新 handoff.md。交接內容要分清楚哪些已完成、哪些真的驗證過，以及哪些還沒檢查。 提示詞 ③｜收工，保存交接進度 12345678910111213141516171819202122今天先做到這裡，請幫我收工。請檢查目前專案檔案與實際工作成果。更新 handoff.md，包含：- 這次完成了什麼- 哪些功能已驗證- 哪些功能尚未驗證- 有哪些問題或阻礙- 下次建議先做的三件事- 最後更新時間如果本次沒有改變已確認的需求，就不要修改 project.md。如果有重要需求變更，先列出差異供我確認，不要自行定案。請不要刪除檔案、部署網站，也不要自動推送到 GitHub。最後告訴我文件實際更新了哪些內容。 例如，「表單介面已經寫好」不代表「報名資料已成功送出」。這兩種狀態分開記錄，下一次接手時才不會把未驗證的功能誤認為完成。 隔天開新對話時，先開工再修改隔天重新開啟同一個專案資料夾，開始新對話。先請 Codex 讀取三份文件，並檢查專案目前的 Git 狀態，再決定今天要做什麼。 提示詞 ④｜開工，接續昨天的工作 12345678910111213141516171819202122今天要繼續這個專案，請幫我開工。先確認目前工作目錄。讀取：1. AGENTS.md2. project.md3. handoff.md如果專案有使用 Git，也請檢查目前版本與未提交的變更。請先不要修改程式。告訴我：- 這是什麼專案- 已經完成了什麼- 哪些地方還沒驗證- 上次停在哪裡- 今天最適合先做哪三件事請不要重新製作已完成的功能。 這份交接不是昨天聊天紀錄的摘要，而是要求 AI 對照專案目前的檔案與變更。若交接文件已經過期，或實際程式和文件不一致，就要先核對再動工。 想自動化開工和收工時，再了解 Skill每次複製長提示詞可能有點麻煩。熟悉基本流程後，可以再研究把常用指示整理成 Skill，減少重複輸入。 三師爸 Sense Bar 開源的 cross-device-agent-skills 提供三個流程：project-init（初始化專案）、startup（開工）和 shutdown（收工）。它也介紹 GitHub 和 Obsidian 等延伸整合，實際效果會依安裝、設定和可用工具而不同。 要先看清楚 Skill 會讀寫哪些檔案、需要哪些權限，以及是否會操作 Git。該專案 README 說明 shutdown 流程可能執行 git commit 和 git push；如果你不希望 AI 自動提交或推送，就要在使用前檢視流程並調整規則。想延伸了解 Skill 與 Plugin 的差異，可以參考站內的 Codex Skill 與 Plugin 指南。 GitHub 和 Google Drive 要一開始就設定嗎？剛開始練習時，可以先只在本機完成三件事： Codex 在正確的資料夾建立了專案文件。 新對話能照指示讀取前一次的進度。 收工時能根據實際成果更新交接簿。 熟悉之後再學 GitHub。GitHub 能保存版本歷史，也可讓不同電腦取得專案；但「本機 commit」只代表建立了一筆本機版本紀錄，還要成功 push 才會送到遠端。 Google Drive 桌面版可以同步一般檔案，但若多台電腦同時修改同一個專案，可能發生同步衝突。跨裝置工作前，先了解雲端同步和 Git 的使用方式；不要把「檔案在雲端資料夾」當成「版本備份和同步都已驗證」。 已經寫一半的專案，也能補上交接文件嗎？可以。先請 AI 檢查目前專案和既有文件，再根據實際內容整理，不必從頭重做。遇到資訊不足的地方，標記「待確認」，不要猜測，也不要覆蓋原有設定。 提示詞 ⑤｜替舊專案補上交接機制 12345678910111213141516171819202122232425262728我已經有一個正在開發中的專案。請先檢查現有的資料夾、程式檔案和專案文件。不要重新製作網站，也不要覆蓋原有設定。請根據實際內容，協助我整理：- project.md：專案目標、需求、限制、 已確認決策及驗收標準- AGENTS.md：AI 工作守則和文件入口- handoff.md：目前進度、驗證狀態與下一步如果已經存在相關文件，請優先整合，避免產生互相矛盾的規則。請嚴格區分：使用者已確認的要求、AI 自己提出的建議、實際完成的功能、尚未驗證的工作。不確定的事項請標記「待確認」，不要自行猜測。完成後提供文件摘要與差異，不要擅自變更功能或部署網站。 專案文件讓接手更清楚，仍要核對實際成果project.md、AGENTS.md 和 handoff.md 不會自動讓 AI 永遠記得所有事情。它們的用途是把重要需求、工作規則和目前進度放在容易找到的位置，讓每次接手時有一份可查閱的依據。 文件可能過期，AI 也可能漏讀；開始修改前仍要對照程式、版本控制狀態和實際驗收結果。對 AI Coding 新手而言，先學會保存需求、標示驗證狀態和更新交接內容，往往比多背幾段提示詞更能讓專案順利延續。 常見問答 (FAQ)Q1：project.md 和 handoff.md 會被 Codex 自動讀取嗎？預設情況下，Codex 會依規則發現適用的 AGENTS.md。project.md 和 handoff.md 是自訂檔名，應在提示詞中明確要求讀取，或透過 AGENTS.md 指示 Codex 何時讀取。 Q2：不會寫程式，也能使用這三份文件嗎？可以。你可以用一般文字描述目標、限制和進度，再請 Codex 協助整理文件。仍要親自確認需求和驗收結果是否正確。 Q3：建立 handoff.md 就等於已經備份專案嗎？不是。handoff.md 只是記錄工作的文字檔。若要保存程式版本或在不同裝置取得專案，還需要設定 Git、遠端儲存或同步工具，並確認相關操作確實成功。 Q4：已經開發一半，還能開始使用嗎？可以。先檢查現有檔案和文件，再整理專案目標與進度；不確定的內容標記待確認，避免把建議誤寫成已確認需求。 Q5：交接文件可以完全避免 AI 重做或誤解需求嗎？不能保證。文件能降低重新交代的成本，但仍需要定期更新，並在每次工作開始時對照實際檔案、程式狀態和驗收結果。 參考資料與延伸學習三師爸 Sense Bar｜AI Agent 基本功 EP06：如何讓多個 AI Agent 跨電腦協作專案 影片：https://www.youtube.com/watch?v=mnFdJaAmeUM cross-device-agent-skills 開源專案 GitHub：https://github.com/mathruffian-dot/cross-device-agent-skills OpenAI｜Codex AGENTS.md 官方文件 OpenAI｜Codex AGENTS.md 官方文件 OpenAI｜Codex／ChatGPT 桌面版入門文件 OpenAI｜Codex／ChatGPT 桌面版入門文件 #Codex #AICoding #VibeCoding #AI教學 #AGENTSmd #ChatGPT #ClaudeCode #AI工作流

  • article-我現在做 Vibe Coding，不會只靠 Playwright 驗收了：SuperDesign × DESIGN.md × Codex Browser

    2026/10/2

    AI工具 Vibe Coding Playwright
    我現在做 Vibe Coding，不會只靠 Playwright 驗收了：SuperDesign × DESIGN.md × Codex Browser

    最近我一直在整理自己的 Vibe Coding 工作流。 以前的想法很單純：AI 寫完網站後，用 Playwright 跑一次；網站能開、按鈕能點、測試有過，大概就可以交差。 但最近接連研究 SuperDesign、Google 的 DESIGN.md，再加上 Codex 的 Browser use，我開始重新思考：AI 寫完網站之後，應該怎麼驗收？ 程式正確，不等於畫面正確。Build、TypeScript 與單元測試可以都通過，但它們不一定會告訴你手機版 CTA 是否被擋住、卡片間距是否一致，或頁面有沒有符合原本的視覺語言。 我現在會把流程拆成不同角色： 1SuperDesign → DESIGN.md → Codex 實作 → Codex Browser 動態驗收 → Playwright 核心回歸 → Deploy 這些工具不是互相取代，而是各自處理設計探索、規格、實作、人工判斷與重複測試。 為什麼只跑 Playwright，還不算完成 UI 驗收？Playwright 很適合確認固定流程能不能一再成功。例如使用者能不能登入、完成預約、修改資料，或走完結帳。這些條件可以明確寫成測試，也能放進每次 Pull Request 或部署流程裡。 但「按鈕是不是歪了」「手機版有沒有溢出」「畫面看起來是否符合品牌」通常需要結合上下文判斷。程式可以編譯成功，功能測試也可能通過，視覺層仍然不理想。 Playwright 也支援 Visual Comparison，可以用 toHaveScreenshot() 建立基準畫面並在後續執行時比對。這很適合穩定、重要而且值得守住的畫面；不代表每一個頁面、每一個 hover 狀態都要做成快照測試。快照基準仍需人工檢視與更新，而且不同作業系統、瀏覽器版本與字型可能造成差異。Playwright 官方文件 所以我不會把 Playwright 全砍掉，而是讓它專注在可以明確定義、必須重複通過的 Regression Test。 讓 SuperDesign、DESIGN.md、Codex 與 Playwright 各自負責一段 工具 在流程中的工作 適合處理的問題 SuperDesign 探索與比較設計方向 新頁面要採取什麼視覺方向？哪些設計變體值得比較？ DESIGN.md 記錄可重用的設計規格 顏色、字體、間距、元件與品牌原則要怎麼維持一致？ Codex 依規格實作並修正程式 如何把選定的設計方向落進現有程式碼？ Codex Browser 動態檢查實際畫面與互動 RWD、流程、Console 或 Network 是否有可見問題？ Playwright 自動守住關鍵 Regression 登入、預約、Checkout 或 CRUD 是否持續正常？ SuperDesign：先探索方向，再開始寫 UI以前我可能會直接跟 Coding Agent 說：「幫我把這個 Dashboard 做漂亮一點。」但「漂亮」的判斷太開放，Agent 可能直接選一套通用風格開始寫，最後很難確認它是否理解我的方向。 SuperDesign 可以放在實作前，協助分析既有介面、整理設計系統，並探索或比較不同的 UI 設計草稿。先看過幾個方向、選定適合的方案，再交給 Coding Agent 實作，會比要求它憑一句形容詞猜設計更容易對齊。SuperDesign Skill 官方專案 我會把這一步理解成「負責想」：先決定要往哪個方向走，不急著把第一個生成結果當成定案。 DESIGN.md：把視覺共識寫成可讀規格SuperDesign 解決的是「設計方向可以長怎樣？」；DESIGN.md 則可以接著回答「選定的設計規格是什麼？」 它以 Markdown 搭配結構化資料描述視覺識別與設計系統，例如色彩、字體、間距、圓角與元件。專案中的人和 Coding Agent 都可以查閱，也能透過工具檢查格式、比較版本，或匯出 Design Token。 不過，規格檔不會自動成為 Single Source of Truth。工作流程需要明確要求 Agent 先讀取它，也要維護規格與程式碼的一致。撰寫本文時，Google Labs Code 的官方專案仍把 DESIGN.md 格式標為 alpha，規格與 CLI 都還在發展中；實際支援內容可能改變。Google Labs Code：DESIGN.md Codex Browser：讓 Agent 實際打開頁面檢查以前常見的迴圈是：Playwright 失敗、Agent 看 Log、猜測原因，再修改程式。現在 Codex 也可以使用 Browser 打開頁面、操作互動，並在實際畫面中發現 UI 問題。 Codex Browser 適合做偏動態的檢查：桌機和手機版版面是否合理、文字或圖片有沒有被切掉、表單能不能完成、導覽順不順。若啟用 Browser Developer Mode 的完整 CDP 存取，還能檢查 Console、Network、頁面狀態與 JavaScript 效能。這項存取要由使用者在桌面 App 設定中開啟，使用完整 CDP 檢查網站前也會要求明確核准；不能假設它預設就能讀取所有瀏覽器內部狀態。OpenAI：Browser Developer Mode 我會把 Browser 想成「會實際操作網站的動態驗收員」。它可以幫忙看出問題、定位問題，再配合修改與重新載入，確認修正有沒有生效。 Playwright：把最重要、可重複的流程留下來以預約 SaaS 為例，我會優先保留這些不能壞的流程： 登入 查詢可預約時段 建立預約 修改預約 取消預約 後台看得到這筆預約 這些流程有明確成功條件，適合交給自動化測試。相較之下，卡片 padding、手機排版、文字是否被裁切等視覺問題，通常更適合在每次實作後用 Browser 實際檢視。 123456test('使用者可以完成預約', async ({ page }) => { await page.goto('/booking'); await page.getByLabel('姓名').fill('測試使用者'); await page.getByRole('button', { name: '下一步' }).click(); await expect(page.getByText('選擇預約時間')).toBeVisible();}); 我的個人做法是把大部分一次性的 UI 檢視交給 Browser，再把真正不能壞的使用者旅程留給 Playwright。文中提到的「80% 動態驗收、20% 自動回歸」只是我用來說明分工的個人粗略比例，不是研究數據或通用標準。 我會怎麼安排 Vibe Coding 的 UI 驗收流程？123456789101112SuperDesign ↓ 探索並選定設計方向DESIGN.md ↓ 明確定義色彩、字體、間距與元件原則Codex ↓ 依規格實作網站Codex Browser ─── Playwright ↓ 動態檢查 ↓ 核心 Regression修正 UX／RWD 守住固定流程 └───────┬───────┘ ↓ Deploy 這個流程把每個階段要回答的問題拆清楚： SuperDesign： 要探索哪些設計方向？最後選哪一個？ DESIGN.md： 顏色、字體、間距和元件原則如何描述？ Codex： 如何把選定的方向與規格實作進程式碼？ Codex Browser： 頁面實際打開後看起來如何、互動有沒有問題？ Playwright： 哪些不能靠目測、每次改版都必須重新通過？ 可以直接交給 Coding Agent 的 Browser 驗收要求完成前端實作後，可以要求 Agent 依照專案的 DESIGN.md 檢視實際頁面。若有問題，要繼續定位、修改、重新載入並複查，而不是只列出缺陷： 12345678910111213141516171819完成實作後，請使用 Browser 驗收，不要只回報程式已完成。1. 先閱讀專案中的 DESIGN.md。2. 打開本機網站，實際操作主要頁面與表單。3. 檢查色彩、字體、間距、版面、圓角、元件與 RWD。4. 檢查 Hover、Active、Focus、Overflow、文字裁切與圖片載入。5. 若目前 Browser 權限允許，檢查 Console 與失敗的 Network Request。6. 發現問題時，定位對應的 DOM、CSS 或 Component，修正後 Reload 並重驗。最後分別回報：DESIGN.md PASS / FAILDesktop PASS / FAILTablet PASS / FAILMobile PASS / FAILConsole PASS / FAIL / 未檢查Network PASS / FAIL / 未檢查Interaction PASS / FAIL列出為了通過驗收而修改的檔案與尚未解決的問題。 結論：不要問 Browser 能不能取代 Playwright我現在會先問：「哪些驗收需要理解畫面與上下文？」以及「哪些驗收應該固定、可重複地執行？」 需要判斷視覺、UX 與不同裝置呈現的部分，交給 Browser 輔助檢查；登入、預約、Checkout、CRUD 等有明確條件的核心流程，留給 Playwright 穩定回歸。SuperDesign 先探索，DESIGN.md 記錄規格，Codex 負責實作，Browser 負責動態檢視，Playwright 守住關鍵流程。 以前的 Vibe Coding 是「AI 幫我把網站寫出來」；我期待下一階段是：AI 不只把網站寫出來，也要在能力與權限允許的範圍內，協助確認它做得如何。 常見問答 (FAQ)Q1：Codex Browser 可以取代 Playwright 嗎？不適合把兩者當成互相取代的工具。Browser 適合檢視畫面、互動與上下文；Playwright 適合反覆驗證登入、預約、結帳等明確流程，也能比對選定的視覺基準。 Q2：DESIGN.md 和 SuperDesign 有什麼不同？SuperDesign 用來探索、比較設計方向與設計草稿；DESIGN.md 用來把選定後的設計系統整理成規格，讓人和 Agent 可以依據它協作。前者偏探索，後者偏記錄與對齊。 Q3：Codex Browser 一定能檢查 Console 和 Network 嗎？不一定。較深入的瀏覽器診斷需要支援的 Browser use 環境、已啟用 Developer Mode 的完整 CDP 存取，且檢查網站時仍可能需要使用者明確核准。驗收報告應區分已檢查與因權限未檢查的項目。 Q4：哪些測試最值得保留在 Playwright？優先保留重要、可明確描述成功條件，而且改版後必須重複通過的使用者旅程，例如登入、建立或取消預約、結帳和核心 CRUD。探索性的視覺問題則可在 Browser 驗收時檢視。 Q5：每個頁面都要建立 Screenshot Regression 嗎？不用。挑選穩定且值得保護的核心頁面或元件即可，並在相同的瀏覽器、作業系統、字型與測試資料環境下比對。快照能指出畫面改變，但仍需要人判斷改變是預期還是缺陷。 參考資料 OpenAI Help Center：Codex Browser use 與 Developer Mode Google Labs Code：DESIGN.md 格式、CLI 與專案狀態 SuperDesign Skill：Coding Agent 的設計探索與系統工作流 Playwright：Visual Comparisons

  • article-Claude Skill 可以用在 Codex 嗎？Claude → Codex Agent Skills 遷移指南

    2026/10/2

    Vibe Coding Codex Claude
    Claude Skill 可以用在 Codex 嗎？Claude → Codex Agent Skills 遷移指南

    最近看到六角學院卡斯柏整理的「Claude Code Skill 設計風格圖鑑」，我第一個念頭是：這些設計方法都包成 Claude Skill 了，如果我平常主要用 Codex，還能不能拿來用？ 簡單說：**很多 Skill 的核心方法可以沿用，但不代表 Claude 與 Codex 的功能可以直接一鍵互換。**如果內容主要是設計規則、檢查清單和工作步驟，通常很容易搬；如果它仰賴特定工具權限、Hook、子代理或插件設定，就要逐項調整並實際驗證。 本文用卡斯柏的圖鑑當例子，整理如何把一份 Claude Skill 轉成 Codex 可發現、可執行，也方便持續維護的工作方法。 本文依 2026 年 10 月 2 日可查到的官方文件整理。Agent Skills 與 Codex 插件規格仍會演進；安裝或遷移前，請再核對當下文件與工具版本。 先分清楚 Skill 格式和執行平台Agent Skill 通常是一個資料夾，核心是 SKILL.md，可以再附上 references/、assets/ 和 scripts/。SKILL.md 描述何時使用這份 Skill，以及 Agent 要遵循的工作方法。這套目錄概念採用開放的 Agent Skills 標準，Claude Code 和 Codex 都有自己的 Skill 支援方式。 兩邊載入本機 Skill 的路徑不同。Claude Code 的專案 Skill 常放在 .claude/skills/<skill-name>/；Codex 則會從專案中的 .agents/skills/ 掃描。Codex 的官方文件也說明，這個目錄適合專案內使用；若要散布給其他人，則可把 Skill 包裝成 Plugin。 所以，看到兩邊都有 SKILL.md，可以先把它理解成「可攜的工作方法格式」，不要直接推論裡面的每個欄位、指令或執行行為都相容。 只有 SKILL.md 和參考資料時，怎麼搬？如果 Skill 的內容是設計原則、操作步驟、範例和檢查清單，通常可以先做小幅遷移： 讀完 SKILL.md，確認它要求 Agent 做什麼、何時啟用。 一併保留 Skill 用到的 references/、assets/ 和 scripts/。 複製到 Codex 專案的 .agents/skills/<skill-name>/。 把 Claude 專屬路徑、工具名稱和呼叫方式改成 Codex 可用的寫法。 在實際任務中明確呼叫一次，再檢查產出是否遵循 Skill 的規則。 例如，先確認目標資料夾不存在，再複製整個 Skill 資料夾： 12mkdir -p .agents/skillscp -R .claude/skills/<skill-name> .agents/skills/<skill-name> 若 Skill 原本就在個人目錄或某個插件裡，來源路徑要依實際位置調整。複製前先看過其中的腳本與外部依賴；不要只因為資料夾名稱叫 Skill，就直接執行裡面的程式。 以設計風格 Skill 為例，核心內容可能是字體層級、版面網格、留白、圖片運用、動態效果、響應式規則與反模式。這些方法通常不依賴特定模型，搬移後仍然有參考價值。 哪些 Claude 設定不能直接照搬？實際要花心力的地方，往往是 SKILL.md 的前置資料，以及文字背後預設的產品行為。 allowed-tools 不等於 Codex 的權限設定。 Agent Skills 標準將這個欄位列為實驗性項目，各家支援程度可能不同。Codex 的遷移參考也提醒，工具清單可以轉成文字指引，但不會因此成為嚴格的權限邊界。真正的權限要在執行環境或平台設定中處理。 **model、effort、context、user-invocable 和 disable-model-invocation 等欄位，可能是 Claude 專屬或語意不同的設定。**逐項查清楚它們在來源平台控制什麼，再決定要刪除、改寫為一般指引，或放到 Codex 支援的設定中。 **Hooks、子代理與指令需要分開檢查。**例如，Claude 的 Slash Command 可以轉成 Skill 的概念，但參數代換、工具呼叫和執行時機未必相同；Hook 的事件種類與行為也不保證一對一對應。 **MCP 設定不是 Skill 內容本身。**Skill 可以說明如何使用工具，但伺服器設定、認證與工具權限要在 Codex 支援的整合方式中另外處理。 若原本的 Claude Skill 帶有 hooks、agents、.mcp.json、commands/ 或 plugin.json，先列清楚每一項功能，再決定要手動改寫、用 MCP／Plugin 重建，或保留為人工處理事項。不要只移動資料夾就宣稱遷移完成。 官方遷移工具可以參考，但要先檢查新舊版本OpenAI 的舊版 Skills Catalog for Codex 曾提供 migrate-to-codex Skill。它設計的流程包含掃描來源、產生計畫、檢查風險、Dry Run、執行遷移，再驗證目標檔案。 **時效提醒：截至本文查核日，該 GitHub 專案首頁已標示 deprecated；其中的遷移 Skill 仍可查閱，但不應把它當成保證持續更新的安裝或遷移入口。**它的差異參考文件也標註最後檢查日期為 2026 年 4 月。若要用這份工具，先確認目前版本、命令選項和 Codex 官方文件，再檢查 Dry Run 的檔案清單；不要未審查就執行會寫入或刪除檔案的步驟。 目前 OpenAI 的文件說明 Codex 可從 .agents/skills/ 載入本機 Skill；若要跨專案散布或搭配連接器，則可依現行 Plugin 文件打包。OpenAI 也提供 Claude Code Plugin 遷移指引，逐項說明哪些 skills/、commands/、Hook 和設定需要保留、改寫或另外處理。這些文件比沿用舊版範例更適合當下的檢查起點。 我會採用的遷移工作流把 Skill 當成程式一樣檢查，比「搬過去應該就能跑」可靠： 1234567891011盤點來源 ↓確認 Codex 支援範圍 ↓複製 Skill 和必要資源 ↓改寫平台專屬欄位與呼叫方式 ↓檢查腳本、路徑和權限假設 ↓用一個真實任務驗證 只有單一 SKILL.md 的情況，可以手動遷移並逐段檢查；如果整個 Claude Plugin 還包含 MCP、Hook、Subagent 和 Marketplace 設定，就先分拆成不同能力處理。每完成一類設定，都要確認它在 Codex 端的實際替代方式，並檢查遷移後的 Skill 能否找到原本依賴的檔案。 完成檔案搬移後，不要只看資料夾出現就算過關。先確認 Codex 能發現這個 Skill，再用明確的提示詞呼叫它；觀察它是否真的套用設計規則、遵循限制並找到參考資料。遇到結果不符時，修正 Skill 後再跑一次相同任務。 npx skills add 是社群工具，不是 OpenAI 官方指令另一種常見做法是使用 Vercel Labs 維護的 Skills CLI： 1npx skills add OWNER/REPO 它可以協助從 GitHub 等來源安裝 Skill，不過這是第三方工具，不是 OpenAI Codex 的官方指令。使用前先確認來源 Repo、版本、Skill 實際內容、會執行的腳本、權限和檔案寫入位置。若只是移轉單一 Skill，手動檢視及複製往往更容易知道哪些內容真的進入 Codex。 把設計風格圖鑑變成自己的 Design Skill Library我覺得卡斯柏圖鑑最值得帶走的，不是收集一大堆別人的 Skill，而是拆解它們背後的設計方法。看到喜歡的網站時，可以問：它怎麼使用字體、留白、網格、層次、圖片、動態、互動與響應式版面？哪些反模式值得寫進檢查清單？ 再把反覆會用到的方法整理成小而清楚的 Skill，例如： 123456.agents/skills/├── editorial-web-design/├── landing-page-design/├── dashboard-design/├── motion-design/└── design-review/ 開始設計頁面時，按需求組合相關 Skills，再請 Agent 依 design-review 檢查層級、留白、手機版與動畫。這種模組化方式比較容易逐項維護，也比把 UI、UX、SEO、動畫、框架、文案和部署全塞進一個超大型 Skill 更清楚。 Skill 累積的是可重複執行的工作方法，不是某個模型的永久能力保證。模型和產品功能會改版，Skill 的路徑、工具與規則也要跟著實際環境檢查；能跨平台重用的部分，才是真正留下來的專業方法。 如果你也在整理 Codex 和 Claude 的工作流程，可以延伸閱讀我把 ChatGPT 接上開發台 MCP，讓 Codex 接手實作的流程。 常見問答 (FAQ)Q1：Claude 的 SKILL.md 可以直接放進 Codex 嗎？若內容主要是一般文字指令、範例與參考檔案，通常可以先複製到專案的 .agents/skills/<skill-name>/ 再測試；但 Claude 專屬的 frontmatter、Hook、工具權限與呼叫方式需要檢查，不能假設完全相容。 Q2：Codex 專案 Skill 應該放在哪個資料夾？Codex 官方文件列出的專案 Skill 位置是 .agents/skills/。每個 Skill 資料夾至少要有含 name 與 description 的 SKILL.md；參考資料、腳本和資產可依需要放在同一個資料夾。 Q3：Claude Plugin 的 Hooks、MCP 和 Subagents 也會一起搬過去嗎？不一定。這些功能和 Skill 指令使用不同的執行方式，要依 Codex 支援的 Hook、MCP、Plugin 或 Agent 設定分別檢查；有些行為沒有直接對應，需要人工重寫或保留為手動步驟。 Q4：npx skills add 是 Codex 官方安裝工具嗎？不是。它是 Vercel Labs 維護的跨 Agent Skills CLI。它可以安裝 Skill，但使用前仍要檢查來源與內容；Codex 本身也有官方文件描述本機 Skill 的位置和 Plugin 發佈方式。 參考資料 卡斯柏｜Claude Code Skill 設計風格圖鑑 Anthropic｜Claude Code Skills OpenAI｜Build skills for ChatGPT and Codex OpenAI｜Skills Plugin concept OpenAI｜Submit your Claude Code plugin Agent Skills｜Open Standard OpenAI｜舊 Skills Catalog 與 migrate-to-codex 資料（查閱時請留意該 Repository 的 deprecated 標示） Vercel Labs｜Skills CLI

  • article-GSAP AI Skills 教學：我把官方 Skills 裝進 Codex，讓 Vibe Coding 網站動起來

    2026/10/2

    AI Agent Vibe Coding GSAP
    GSAP AI Skills 教學：我把官方 Skills 裝進 Codex，讓 Vibe Coding 網站動起來

    最近看到 GSAP 官方推出一組 AI Agent Skills，我第一個反應不是「又多一個 AI 工具」，而是：這很適合放進 Vibe Coding 工作流。 現在用 Codex、Claude Code 或 Cursor 做網站，AI 通常很快就能生出 Landing Page。但開始要求它加上文字進場、卡片依序出現或 Scroll 動畫時，會動不代表動得好：動畫可能搶走閱讀焦點、手機版跑出畫面，或因為缺少清理而影響效能。 我想研究 GSAP，正是因為網站互動不只要「有動」，還要知道什麼時候動、怎麼安排節奏，以及怎麼照顧不同裝置的使用者。 GSAP 是控制網頁即時動畫的 JavaScript 函式庫如果你不是專門做前端動畫的，可以先把 GSAP 想成一套用來安排網頁元素動作的工具。它控制的是使用者瀏覽網站時，瀏覽器即時呈現的動畫；它不是 AI 影片生成器，也不負責把動畫輸出成 MP4。 像是標題逐行出現、圖片滑進畫面、卡片依序浮現、數字往上遞增、SVG 路徑動畫、按鈕微互動，或畫面隨著使用者捲動而演出，都是 GSAP 常見的使用情境。 如果你正在做 Landing Page、產品官網、活動網站、作品集或一頁式銷售頁，GSAP 可以幫你更精準地控制動畫的順序、時間與互動方式。它的 官方文件 也整理了 Core、Timeline、ScrollTrigger 與各類 Plugins 的使用方式。 GSAP 官方 AI Skills 把動畫實務帶進 Coding Agent以前請 AI 用 GSAP 做動畫，通常得自己描述需求，再期待模型能正確找出文件、安排程式結構並處理框架細節。現在 GSAP 官方把常見用法整理成 AI Agent Skills，可透過 npx skills add https://github.com/greensock/gsap-skills 安裝到 Codex 等支援的 Agent。 官方 repository 將 Skills 分成幾個方向： GSAP Core：gsap.to()、from()、緩動、stagger 等核心 API。 Timeline：管理多段動畫的先後、標籤與時間軸。 ScrollTrigger：處理捲動觸發、pin、scrub、refresh 與清理。 Plugins：說明各種 GSAP 外掛的使用方式。 React：涵蓋 useGSAP()、scope、cleanup 與 SSR 注意事項。 Frameworks：介紹 Vue、Svelte 等框架的生命週期與清理。 Performance：優先使用 transform，減少不必要的版面計算。 Utils：提供 clamp、mapRange、interpolate 等工具函式。 這件事值得注意的地方，不只是多了一套動畫函式庫，而是可以把官方累積的使用方式與常見注意事項，交給 AI Agent 在工作時參照。Skill 提供的是工作指引，不代表生成結果自然就正確；仍要看實際畫面、程式碼與裝置表現。 第一步：先請 AI 規劃，不要一開始就叫它加特效我會先把 AI 當成「動態設計顧問」，請它分析目前網站哪裡值得動。這一步能避免 Hero、卡片、按鈕和背景全部同時飛進來，讓動畫反而打斷閱讀。 可以先這樣下指令： 12345678910分析目前網站，找出 3 個最適合加入 GSAP 動畫的位置。不要為了動畫而動畫，先不要修改程式碼。優先評估：1. Hero 首屏進場2. 使用者 Scroll 時的內容節奏3. CTA 與卡片微互動請說明每個建議想改善的體驗、觸發時機、動畫順序與可能風險。同時考慮手機版、避免 layout shift、動畫效能與 prefers-reduced-motion。 第二步：依照規劃實作並照顧不同裝置確認動畫規劃後，再請 Agent 按範圍實作。多段動作用 Timeline 管理，Scroll 動畫交給 ScrollTrigger，並要求它把清理與無障礙需求一起納入： 12345678910按照剛才確認的動畫規劃開始實作，參照 GSAP 官方 Skills 的建議。- 多段動畫使用 Timeline 管理，不要用大量 delay 硬接。- Scroll 動畫使用 ScrollTrigger，版面改變後確認是否需要 refresh。- 優先使用 transform 與 opacity，避免不必要的 layout reflow。- 確認手機版不會爆版或遮住重要內容。- 支援 prefers-reduced-motion，讓偏好減少動態效果的使用者能正常閱讀。- 若使用 React，處理好動畫 scope 與 component cleanup。完成後檢查 console error、ScrollTrigger refresh、動畫清理和效能問題。 prefers-reduced-motion 是需要明確考慮的使用者偏好。可以請 AI 為減少動態效果的情境提供較安靜的呈現方式，也可以直接讓內容以靜態狀態呈現；重點是不能讓動畫成為閱讀內容的門檻。 第三步：請 AI 用 Performance Skill 再 Review 一輪程式寫完還不算結束。AI 很容易把「做動畫」解讀成讓更多東西動起來，所以我會再開一輪 Review，要求它只找問題，不增加特效： 123456789101112現在不要增加任何新動畫。請參照 GSAP Performance Skill 與相關官方建議，Review 目前所有動畫。檢查：- 手機效能與不必要的 layout reflow- ScrollTrigger 的使用與 refresh- Timeline 管理方式- 事件監聽器與 React cleanup- prefers-reduced-motion 的處理- 動畫是否干擾 CTA、內容閱讀或操作只修正發現的問題，不增加新特效；完成後列出修改處與仍需人工確認的項目。 好的網站動畫不是動得越多越好，而是出現得恰到好處。多一輪 Review，可以讓動畫重新回到它該服務的目標：引導視線、補足回饋，或讓內容更容易理解。 Vibe Coding 下一步，是讓 AI 做出更好的互動體驗Vibe Coding 一開始常從「AI 幫我把網站做出來」開始，接著是「AI 幫我把 UI 做漂亮」，現在也可以往前一步，請 AI 一起規劃和實作互動體驗。 我會把三者想成這樣：LLM 負責理解需求與撰寫程式；GSAP 提供動畫工具；Skill 則把專業做法、Coding Standard 和檢查步驟整理成 Agent 能參考的工作方式。把能力裝進工作流後，AI 不只知道「可以怎麼寫」，也多了一套更有方向的實作參考。 如果你已經在用 Codex、Claude Code 或 Cursor 做網站，可以從一個做好的頁面開始，依序跑過「動畫規劃 → Hero 或卡片實作 → ScrollTrigger → 手機與效能檢查 → AI Review」。先從一兩個真正能改善體驗的位置開始，通常就能看出差異。 若你也在整理 Agent 的工作方式，可以延伸閱讀從 Skill 到 Agent Harness與Codex Skill 與 Plugin 的差異。 延伸閱讀 GSAP 官方 AI Skills GSAP 官方 GitHub GSAP 官方文件 常見問答 (FAQ)Q1：使用 GSAP AI Skills 前，需要先學會 GSAP 嗎？不必先把 GSAP 全部學完才開始。你可以先讓 Agent 根據網站提出動畫規劃，再從它產生的 Timeline、ScrollTrigger 或 React 實作反向學習。不過仍建議閱讀重要程式碼、確認執行結果，逐步建立判斷能力。 Q2：GSAP AI Skills 會自動替網站加入動畫嗎？Skill 是提供給 AI Agent 參照的說明與實務指引，本身不會替網站修改程式碼。你仍要提出需求並確認修改範圍；安裝後的生成結果也要經過程式碼與畫面檢查。 Q3：怎麼避免 Scroll 動畫在手機上卡頓或影響閱讀？先減少動畫數量，優先選擇能改善資訊節奏的區塊，並檢查手機上的捲動、效能與內容可讀性。也要考慮 prefers-reduced-motion，並在框架元件卸載時清理動畫與事件監聽器。

  • article-AI Coding 技術債：寫程式快 10 倍，Temporary Fix 也可能快 10 倍

    2026/9/25

    AI工具 Vibe Coding
    AI Coding 技術債：寫程式快 10 倍，Temporary Fix 也可能快 10 倍

    最近看到一則工程師笑話：一家公司發現訂單偶爾會「消失」，工程師一路追查 Cache、Database、Replication、Redis、Kubernetes、Message Queue…… 查到最後才發現，整套龐大的企業架構，其實都在保護八年前的一個 Prototype。 最經典的是當年的 Commit： quick prototype, will redesign later 八年後，還是沒有 redesign。 我看完笑得很開心，笑完卻想到一件更可怕的事：如果這個故事發生在 AI Coding 時代呢？ AI 讓 Prototype 更快，理解系統卻沒有變快以前，一個工程師可能花兩個星期寫出 Prototype。現在用 Codex、Claude Code 或其他 AI Agent，一個下午就可能做出雛形：需求丟進去，Agent 開始寫程式、建立資料庫、串 API、部署 Cloudflare、接 Google Sheet、做登入、補後台。 跑起來、測一下、能用、上線。爽。 問題是，我們把「做出軟體」的速度提高了，不代表「理解系統」的能力也跟著提高。以前自己寫三千行程式碼，至少大概知道東西放在哪；現在 Agent 一個晚上可能改了幾十個檔案、加上套件、補 Issue，隔天打開 GitHub，看起來很厲害，卻只能祈禱不要壞。 AI Coding 加速的是產出，不會自動替你補上理解、判斷與維護能力。 真正麻煩的不是程式寫錯，而是沒人知道它為什麼能跑AI 寫錯程式，通常還有訊號：測試失敗、CI 變紅、網站掛掉。至少我們知道某處出了問題。 更難處理的是一個「現在可以跑，但沒有人真正理解為什麼可以跑」的系統。它可能沒有明顯錯誤，還開始接到客戶、處理預約或帶來收入。這時候有人提議重構，第一個反應常常不是「好」，而是「現在不是能跑嗎？」 恭喜，第一筆技術債誕生了。 接著需求和臨時修補一層一層疊上去： 「這裡先加個判斷。」 「那邊先 Workaround。」 「這個欄位先不要動。」 「這個 Workflow 不知道為什麼不能刪。」 「這段是 AI 寫的，先不要碰。」 最後 README 可能出現一句 DO NOT MODIFY THIS SECTION. 沒有人知道原因，但大家都很尊重它。 Prototype 最危險的時刻，未必是它出 Bug，而是它開始被依賴、開始賺錢，卻沒有人敢改。 AI 降低開發成本，沒有自動降低維護成本以前一年可能做三個 Prototype，現在一年可以做三十個。這些雛形不一定都會留下來，但只要其中一部分開始接觸真實使用者、營運流程或收入，它們就從「先試試看」變成需要長期照顧的系統。 如果每次都只追求先跑起來，AI 就可能讓臨時作法累積得更快：一年多做了十倍 Prototype，也可能多留下十倍需要理解和維護的東西。效率提高了，技術債也能跟著自動化累積。🤣 所以 Vibe Coding 下一階段重要的能力，不只是「怎麼叫 AI 幫我寫程式」，而是「怎麼讓 AI 幫我建立一套未來還敢修改的系統」。這兩件事差很多。 把專案記憶留在 Repository，讓下一個 Agent 接得住比較大的 AI Coding 專案，我會開始要求 Agent 做幾件以前覺得很囉嗦的事： 先寫規格、拆 Issue： 把目標、範圍與完成條件留下來，讓每次修改都有依據。 記錄架構決策： 說明為什麼採用某個做法，以及有哪些限制，避免未來的人只看到程式碼、看不到背景。 補測試並做 Code Review： 不只確認功能能跑，也檢查變更有沒有破壞原本行為；重要修改還可以請另一個模型做對抗性驗證。 重要修改先 Commit： 留下可追蹤的變更邊界，搞砸時才知道從哪裡回復。 更新 README 與必要文件： 把執行方式、關鍵流程和已知限制放在下一個接手者找得到的地方。 更重要的是，別只問 AI：「可以跑嗎？」也問：「半年後，另一個完全不知道背景的 Agent 接手，它看得懂嗎？」 未來維護程式碼的人可能不是現在的你，也可能是下一代 Codex、Claude Code，或另一個從沒參與過這個專案的 Agent。Git、Issue、README、測試與 Architecture Decision Record，不只是寫給工程師看的文件，也是留給下一個 Agent 的專案記憶。 以前寫文件，是怕工程師離職；未來寫文件，可能是怕 AI 換模型。模型會變，Agent 的 Session 也可能重新開始。真正能留下來的，不是它「記得什麼」，而是 Repository 裡留下了什麼。 所以我現在看 Vibe Coding，已經不只是： Prompt → Code → Deploy 而更像： Spec → Issue → Agent → Test → Review → Commit → Documentation → Deploy AI 可以讓每一步都變快，但不能因為變快，就把那些步驟全部刪掉。 八年後，某個新人打開 Git，看到一段奇怪的程式碼。Git blame 一查：作者是享哥，Commit message 寫著 temporary fix。 新人問：「為什麼這段不能改？」 資深工程師喝一口咖啡：「不知道。」 「那為什麼還留著？」 「因為刪掉會出事。」 「會出什麼事？」 「不知道。」 「那到底誰知道？」 資深工程師指向 Git 紀錄：「可能要問 2026 年的 Codex。」 問題是，那個 Session 早就不見了。😂 常見問答 (FAQ)Q1：AI Coding 為什麼可能讓技術債累積得更快？AI 能加快 Prototype 和功能的產出，但不會自動增加人對系統的理解，也不會替未來維護補上文件、測試和架構決策。當更多雛形開始被客戶或營運流程依賴，沒有整理的臨時修補就可能變成更難修改的技術債。 Q2：Prototype 已經可以跑、也開始有使用者，還需要重構嗎？能跑和容易維護是兩件事。當系統開始被依賴時，應持續補上規格、測試、決策記錄與必要文件，並為重要修改保留可追蹤的 Commit；是否重構則要看實際風險與變更需求，不應只因為「現在能跑」就假設它永遠不需要整理。 Q3：怎麼讓下一個 AI Agent 看懂現有專案？把背景和理由留在 Repository：用規格與 Issue 說明目標和完成條件，用架構決策記錄說明取捨，維護 README、測試與清楚的 Commit。這些內容能讓沒有參與前一個 Session 的工程師或 Agent 有線索理解系統。

  • article-【AI Agent 也需要漂亮的協作介面：我開始把「看懂」當成 Vibe Coding 的一部分】

    2026/9/25

    AI工具 AI Agent Vibe Coding
    【AI Agent 也需要漂亮的協作介面：我開始把「看懂」當成 Vibe Coding 的一部分】

    最近讀到 Jackle 的〈好設計，反饋優質上下文〉，他分享一個我覺得很值得注意的 Skill：html-visualizer。 一開始我以為，它只是把 AI 的文字回答排版成漂亮的 HTML。研究後我反而覺得，它碰到的是一個更重要的問題： AI Agent 越來越會做事，但我們跟 AI 協作的介面，還停留在聊天室和終端機。 這可能會成為下一階段 Vibe Coding 很重要的一塊。 AI Agent 越會做事，協作介面也得跟上我現在越來越常用 Codex、Claude Code 這類 AI Agent 寫程式。以前比較像是我問一句、AI 回一句，再由我下一個指令；現在一個任務可能先拆需求、開 GitHub Issue、分析架構、查程式碼、提出方案、跑測試，再交給另一個模型 Review。 Agent 一次可能回傳幾千字。它寫得完整，不代表我真的有看完。 尤其做到半夜，Agent 列出 A、B、C 三種做法，後面還有架構差異、資料流、相容性、Migration、Trade-off 和 Edge Cases，最後問我：「請選擇你希望採用的方案。」 人最容易回什麼？ 「照你的建議。」「OK。」「繼續。」 看起來 Human in the Loop 還在，但有時候那個 Human 只是累到不想再讀。這不一定是人不負責任，而是確認事情本身太費力。 html-visualizer 把長篇回答變成可互動的頁面html-visualizer 的想法不只是「幫我排版漂亮一點」，而是讓 Agent 依內容選擇更適合閱讀與回應的 HTML 呈現方式。需要看關係時可以畫流程或架構，需要做選擇時可以把方案並排，需要討論 UI 時則可以直接把幾種畫面做出來比較。 Jackle 的示範裡，像是比較手機和桌面版的「縮小」按鈕：把不同做法放在畫面上之後，使用者能直接看出哪個位置不明顯，或哪種安排可能讓人誤按。這類想法光看文字不一定會出現；看到原型，意見才會具體。 頁面也可以承接回饋。你能選方案、填補充意見，或反白某段文字留下評論；接著按一下複製彙整結果，再貼回 Agent。這一步目前仍是複製貼上，不是頁面自動把決策送進 Agent，但它已經替人省下重新整理答案與描述上下文的力氣。作者的介紹文章有完整示範。 流程因此可以從： 需求 → AI 分析 → 視覺化協作頁面 → 人類 Review → 結構化 Feedback → AI 開始實作。 這不只是「看」的介面，也是一種讓回饋更容易回到工作流程裡的方法。 三種時候，先請 Agent「畫給我看」看架構或流程時如果 Agent 開始用大量文字說明系統架構、模組關係、資料流或 User Flow，可以請它把現況、修改後的樣子和受影響範圍放在一頁。圖上呈現全貌，細節再透過說明或互動補充，比一邊讀一邊在腦中拼圖容易。 要比較方案或 UI 時A、B、C 不要只停留在文字描述。把方案優缺點並排，或直接做出畫面給我看。我看到實際配置後，可能會發現某顆按鈕容易誤按、某段流程讓人困惑，這些 Feedback 往往不是讀文字時就想得到的。 意見需要回到 Agent 時選項、補充欄位和段落評論能保留決策的上下文。複製出彙整結果貼回對話後，Agent 比較容易知道我選了哪個方案、補了什麼條件，以及評論指向哪一段內容。 正式 Coding 前，先加一關 Visualization Review我最近很喜歡把大型 Coding 任務拆成 GitHub Issues，也會讓不同模型互相 Review： 需求 → 拆 Issue → Sub Issues → 模型 A Review → 模型 B 反駁 → 修正 Spec → 再交給 Coding Agent。 現在中間可以再加一關：Visualization Review。在正式開工前，請 Agent 讀目前 Repo、整理問題，先產出一份可供人檢視的 Review Page，內容可以包含： 現況架構與修改後架構 User Flow、Data Flow 和 Database 影響 功能範圍與可行方案比較 Edge Cases 需要我決定的問題與 Agent 的建議 例如可以這樣交代： 先不要修改程式碼。讀完目前 Repo 後，使用 html-visualizer 建立 Review Page，整理現況架構、修改後架構、User Flow、Data Flow、Database 影響、三種可行方案、Edge Cases、需要我決定的問題和你的建議。等我 Review 完再開始實作。 這一步不能保證每個決策都正確，但它讓我有機會在程式改動前看清楚方向。大型任務最怕的情況之一，是第一個方向就偏了，Agent 還很認真地往下做了好幾個小時。 新手可以怎麼開始？不用一開始就研究 Skill 的每個功能。可以先把 html-visualizer 的 GitHub Repo交給支援 Skill 的 Coding Agent，請它先讀 README 和安裝說明，再說明會安裝到哪裡、是否需要執行腳本，確認清楚後再依專案說明安裝。這樣也能避免還沒弄懂來源與安裝範圍，就直接執行不熟悉的指令。 裝好之後，照平常說話就行，例如： 不要用一大堆文字解釋，使用 html-visualizer 把目前系統架構做成網頁給我看。 我看不懂你剛剛提出的三個方案，使用 html-visualizer 做成比較頁面。 先不要 Coding，讀完目前 Repo 後，做一份包含流程、資料庫影響、方案、Edge Cases 和待決問題的 Review Page，等我看完再開始實作。 新手可以先從三種情境練習： 看不懂時： Agent 開始講一堆架構、流程或資料庫，就請它畫出來。 要做選擇時： 不只比較文字，請它把方案或畫面並排給我看。 正式 Coding 前： 大型功能先做 Review Page，確認方向後再開工。 好的 AI 工作流，也要讓人更容易思考我覺得 html-visualizer 最有意思的地方甚至不只是 HTML，而是背後的觀念： 好的 AI 工作流，不只是讓 AI 更容易做事，也要讓人更容易看懂、判斷和回應。 以前談 Human in the Loop，我們常想到「重要決策要讓人確認」。現在我還會多問一句：確認這件事，有沒有被設計得夠簡單？ 如果要讀五千字才知道該確認什麼，那個 Human in the Loop 很可能變成 Human Skip the Loop。😂 AI Agent 接下來一定會越來越自主，所以我也開始在意它要怎麼把事情呈現給我看。我的 Vibe Coding 工作流可能會慢慢變成： Planning Skill → Research Skill → Visualization Review → Human Review → Coding Agent → Testing → Code Review。 AI 負責大量執行；人類保留看懂、判斷與拍板的位置。不要只讓 AI 變得更聰明，也要讓我們更容易跟聰明的 AI 一起工作。 常見問答 (FAQ)Q1：html-visualizer 是什麼？html-visualizer 是一組供支援 Skill 的 AI 工具使用的工作指引，目標是把長篇回答依內容整理成較容易閱讀的 HTML，例如流程圖、方案比較、原型或互動式決策頁面。 Q2：互動頁面裡選完方案，Agent 會自動收到嗎？依作者示範的流程，使用者在頁面選擇、補充或評論後，先複製彙整結果，再貼回 Agent 對話；目前不要把它理解成自動把決策傳回 Agent 的整合。 Q3：什麼時候適合在 Coding 前做 Visualization Review？當任務涉及多個模組、資料流、資料庫變更、不同方案或不容易用文字描述的 UI 時，可以先請 Agent 做 Review Page，讓人確認問題範圍與方向，再開始實作。 Q4：裝了 html-visualizer 後，每次回答都會變成網頁嗎？不一定。呈現方式會依工具規則和任務內容而定；如果希望某次回答直接做成網頁，可以明確要求 Agent 使用 html-visualizer，或直接說「做成網頁給我看」。實際行為仍以目前 Repo 的說明為準。 延伸閱讀 好設計，反饋優質上下文｜Jackle Chen html-visualizer｜GitHub AI Agent 也能直接操作網站：Agent-native Website

  • article-【GPT-6 Astra 正在把 Vibe Coding，推向 Vibe World Building】

    2026/9/14

    AI工具 AI Agent Vibe Coding
    【GPT-6 Astra 正在把 Vibe Coding，推向 Vibe World Building】

    以前我們講 Vibe Coding，常見的想像是：「一句話，AI 幫我做網站、寫 App。」 但最近看到幾個 GPT-6 Astra 搭配 Unreal Engine、Blender 與 Three.js 的案例，我開始覺得，下一階段可能不只是 Vibe Coding，而是 Vibe World Building。 你不只是叫 AI 寫程式，而是讓 Agent 進入專業工具，協助建立角色、遊戲與可以互動的世界。更有意思的是：AI 越能操作專業軟體，我反而越覺得 Domain Knowledge 會變得更重要。 以下案例依照作者公開展示整理，重點是觀察工作方法，不代表每個人使用相同模型、方案與工具設定都能得到相同結果；實際能力也會隨版本、權限與專案環境變動。 AI 開始進入專業工具，而不只生成程式碼Vibe Coding 把「描述需求、產出程式」變得更容易；而這幾個 3D 案例再往前一步：Agent 開始操作 Unreal Engine、Blender 或 Three.js 專案，建立內容、反覆修改，並把場景、規則與互動組合在一起。 這個轉變不只是「AI 會不會 3D」，而是工作環境開始從人操作的軟體，變成 Agent 也能操作與檢查的執行環境。 案例一：從一個物件，走向逐街建構曼哈頓Matt Shumer 分享 GPT-6 Astra 在 Unreal Engine 中建構曼哈頓場景的過程，並描述它花了一週逐街完成細節。這已經不是只要求 AI「放一棟房子、加幾棵樹」，而是把工作尺度拉到街道與街區。 他也展示過另一個 Unreal Engine 世界：場景裡有以 Astra 驅動的角色 Agent，並以共同生存為目標互動。這讓「建構世界」不只包含空間，也開始包含世界中的行動者與互動規則。 當場景從單一物件擴大到街區，問題自然會延伸到道路與建築的空間關係、資產管理、場景分工與驗收方式。若要進一步投入正式製作，效能、碰撞、載入策略與可維護性仍需要另外檢查；一段令人驚豔的展示，不等於所有製作環節都已完成。 來源：Matt Shumer 的曼哈頓建構展示、Astra Agent 世界展示。 案例二：拓撲不一致，就改用離散 Mesh 切換角色表情常用 Blendshape 做平滑變化，但這類頂點形變通常仰賴相容的網格拓撲與頂點對應。若不同 AI 生成的表情 Mesh 拓撲不一致，就不一定能直接做傳統的平滑 Morph。 Nano 分享的 Blender 做法不是硬把所有網格變成同一種拓撲，而是換個解題方向：先把不同表情的 Mesh 對齊；切換時顯示目標表情，並把未啟用的 Mesh 縮小、藏進角色頭部，再透過 Blender Driver 控制切換。 這不是 Blendshape 的平滑融合，而是離散表情切換。它用明確的取捨避開拓撲限制，適合某些表情展示情境，卻不能因此宣稱能取代所有臉部動畫流程或提供連續的表情過渡。 我覺得這個案例特別值得看，不是因為 Astra 知道 Blender 哪個按鈕在哪裡，而是 Nano 知道問題來自哪裡，並知道還有哪些方法可以繞過去。 來源：Nano 在 Blender 中切換角色表情的展示與提示詞。 案例三：一款跑酷遊戲背後，是一整套產品規則MSB 使用 GPT-6 Astra 搭配 Three.js 分享豎屏跑酷遊戲《THE LAST GATE》。看起來是讓角色往前跑，拆開需求後卻是一組完整的遊戲系統： 玩家通過加減乘除算術門時，隊伍人數會即時改變。 撞上障礙物會造成實際隊員損失，而且畫面人數要和遊戲中的真實人數一致。 終點遭遇會依最後存活的隊員人數決定。 需求包含三條短路線、即時重試，以及帶 Seed 的輸入回放。 這已經不是「幫我做一個 Three.js Demo」，而是把玩法規則、3D 場景、互動、狀態變化與可重現測試一起交給 Agent 處理。作品是否能投入正式產品，仍要再驗收效能、操控手感與程式維護性；但需求本身已經從一句畫面描述，長成可檢查的產品規格。 來源：MSB 的《THE LAST GATE》公開貼文。 三個案例，代表三種建構尺度 尺度 案例 真正要處理的問題 世界級 Unreal Engine 曼哈頓與 Agent 世界 空間關係、場景組織、資產與行動者 角色級 Blender 離散表情切換 拓撲限制、替代方案與表情控制 產品級 Three.js《THE LAST GATE》 遊戲規則、互動狀態、重試與回放 我看到的不是「GPT-6 Astra 很會 3D」而已，而是 AI 開始透過專業工具，把世界、角色與產品的不同層次串起來。 AI 越會操作軟體，Domain Knowledge 為什麼越重要？很多人看到 AI 越來越會用 Blender，第一個反應可能是：「那以後是不是不用學 Blender 了？」 我反而覺得，答案可能剛好相反。 真正厲害的不是 Agent 知道哪個按鈕在哪裡，而是有人知道問題為什麼發生、有哪些限制、什麼 workaround 可行，以及最後怎樣才算完成。 如果你知道 Blendshape、Topology、Mesh、Driver 是什麼，才比較可能看出表情網格不相容的原因，並想到可以改用離散切換。若連問題的語言都不熟悉，就很難把這種解法交代給 Agent，也不容易判斷結果有沒有真的做到。 所以 AI 淘汰的可能不是「懂 Blender 的人」，而是只知道 Blender 按鈕在哪裡、卻說不清楚問題與完成標準的人。 以前你懂 Blender，還得親手操作每一步；懂遊戲設計，也可能得等工程師把規則寫出來。Agent 改變的是專業知識的產能：你可以把問題、限制、不要採用的方法、可行的 workaround 與驗收標準交給 Agent，再由專業工具把它落地。 Domain Knowledge × Agent × Professional Tools 專業知識負責判斷，Agent 負責執行，專業工具負責把想法變成可以檢查與迭代的成果。 如果你想延伸看「如何把領域經驗交給 AI 軟體化」，可以讀我之前寫的把專業知識變成軟體；關於 Vibe Coding 如何改變軟體價值，也可參考專業知識與 Vibe Coding 的商業機會。 Vibe Coding 的下一階段，可能是 Vibe Anything以前學 Photoshop、Blender 或 Unreal Engine，常常代表自己要親手完成大量操作。未來你或許不必逐一操作每個按鈕，但仍需要理解這個領域有哪些物件與規則、問題通常出在哪裡、有哪些解法，以及如何驗收。 Vibe Coding 可能只是第一站。接下來還會有 Vibe 3D、Vibe Game Development、Vibe Animation，甚至 Vibe Engineering 與 Vibe World Building。關鍵不是「每套軟體的按鈕都記熟了沒」，而是當 AI 已經能操作工具時，你知不知道該交代什麼、該限制什麼，又該如何判斷它做得對不對。 常見問答 (FAQ)Q1：Vibe World Building 和 Vibe Coding 有什麼不同？Vibe Coding 通常聚焦於用自然語言描述需求、讓 AI 產生或修改程式；Vibe World Building 則把 Agent 帶進 Unreal Engine、Blender、Three.js 等專業環境，處理場景、角色、規則與互動，目標尺度從一段程式碼擴大到可探索或可玩的世界。 Q2：為什麼 AI 越會操作 Blender，專業知識反而越重要？專業知識能幫你定義問題、提供限制、選擇 workaround，並訂出驗收標準。Agent 可以執行很多操作，但仍需要有人判斷網格、表情或動畫是否符合實際用途。 Q3：不同拓撲的表情 Mesh 可以直接做平滑 Blendshape 嗎？不一定。傳統 Blendshape 的頂點形變需要相容的網格與頂點對應；若拓撲不同，可能要先整理網格，或採用像案例中的離散 Mesh 切換。離散切換不等於平滑表情融合，也不是適用所有角色動畫的通用替代方案。 Q4：AI 做出的 3D 遊戲展示，就等於可以正式上線嗎？不等於。除了畫面與主要玩法，仍要測試效能、操控、錯誤狀態、裝置相容性與後續維護。案例呈現的是 Agent 能協助建構與實作的範圍，正式產品仍需要明確的驗收與測試。 Q5：想開始用 Agent 建立 3D 或遊戲專案，最先要準備什麼？先把目標拆成可檢查的規則：有哪些物件、它們如何互動、哪些限制不能違反，以及怎樣算完成。從小範圍任務開始，讓 Agent 執行後再用專業知識檢查結果，會比只要求「做得漂亮」更容易迭代。

  • article-【AI 會寫 API 還不夠：Vibe Coding 下一個機會，是把台灣產業經驗做成 Skill】

    2026/9/14

    商業策略 AI Agent Vibe Coding
    【AI 會寫 API 還不夠：Vibe Coding 下一個機會，是把台灣產業經驗做成 Skill】

    最近看到一個很有意思的開源專案：ecommerce-cia。 它不是另一套電商系統，也不是幫你做購物車，而是一套專門給 AI Coding Agent 使用的「台灣電商 Skill」。 看到這個專案，我第一個想到的是：Vibe Coding 發展到現在，真正的瓶頸可能已經慢慢從「AI 會不會寫程式」，轉移到「AI 懂不懂這個產業」。 因為現在要 AI 幫你寫一個購物車，其實已經不難。商品頁、購物車、會員、訂單後台，甚至串 API，AI 都可以很快幫你生出來。 真正痛苦的是後面。 「我要接綠界。」「我要用藍新。」「LINE Pay 怎麼串？」「7-11 取貨付款怎麼做？」「ATM 付款超過三天沒付，訂單怎麼辦？」 然後你會發現一個很有趣的狀況：Coding Review 沒有 Error，API 文件也看了，每一段程式碼單獨看，好像都沒有問題。 但真的把整間商店跑起來，就是不順。😂 最麻煩的 Bug，可能發生在兩個正確的 Function 之間一般我們叫 AI Review 金流，很容易只檢查幾個局部問題： API 呼叫對不對？ 簽章對不對？ Callback Route 有沒有建立？ 資料庫有沒有寫入？ 庫存 Function 有沒有執行？ 每一個地方都可能是對的，但問題可能發生在兩個「正確的 Function」中間。 以一筆交易為例，流程可能像這樣： 客人建立訂單。 系統保留庫存。 客人前往金流服務付款。 金流通知商店付款結果。 系統驗證通知並更新訂單狀態。 庫存、顧客通知與出貨流程依照訂單狀態接續處理。 如果 Callback 重送兩次呢？客人付款成功，但瀏覽器沒有跳回網站呢？ATM 建立虛擬帳號後幾天都沒有付款，庫存要什麼時候釋出？如果付款成功但庫存更新失敗，或訂單取消時付款通知剛好進來，系統又該怎麼辦？ 這些才是真正把電商系統跑起來後，會遇到的問題。 所以 Review 金流不該只逐個看 Function，而要沿著「錢」和「貨」走過完整流程：下單、訂單、庫存、金流、Callback 驗證、狀態更新、出貨，到交易完成，逐段找可能的斷點。 ecommerce-cia 示範了另一種 AI 稽核方式ecommerce-cia 不是另一套購物車或電商平台，而是給 AI Coding Agent 使用的台灣電商 Skill。它有意思的地方，在於把注意力放到金流、庫存、訂單等環節如何互相影響。 依照專案 README 的說明，它有檢查既有交易流程的 Audit Mode，也有引導新手準備與串接金流的 Setup Mode；文件提到藍新、綠界、PAYUNi、TapPay 與 LINE Pay 等台灣常見情境。這些內容呈現了一個值得參考的方向：除了問 AI「這段程式碼有沒有寫錯」，也可以要求它沿著整條交易生命週期檢查系統行為。 這已經不只是一般的 Coding Skill，而是把產業流程和判斷方式整理成可重複使用的 Domain Engineering Skill。 AI 會看 API 文件，稀缺的是踩過坑的經驗這件事讓我想到我之前一直在談的「把專業知識軟體化」。 假設一個台灣電商工程師做了十年。他真正值錢的可能不是「我知道怎麼呼叫綠界 API」，因為這件事情 AI 看文件就能協助。 真正值錢的，是這些踩過坑才知道的事： 綠界或藍新的 Callback 曾經出過什麼狀況。 ATM 訂單逾期後，何時釋放庫存才符合商業規則。 超商取貨付款訂單的狀態該怎麼轉換。 使用者付款成功但沒有跳回網站，不能因此就判定付款失敗。 Webhook 重送不能重複扣庫存或重複通知。 退款、取消與付款通知同時發生時，訂單狀態要如何處理。 這些東西通常不會完整寫在 API 文件裡。它們存在工程師的腦袋裡，來自踩坑、Debug、客訴、事故，以及凌晨三點修 Production 的經驗。😂 API 文件能說明端點、欄位和簽章方式；把這些技術細節放進真實商業情境後，流程上的例外與判斷往往還要靠產業經驗補足。 專業知識除了軟體化，也可以 Skill 化以前我們會想：我做了十年房仲，可不可以把我的判斷方法做成一套房仲 SaaS？我做了十年行銷，可不可以把我的 SOP 做成一套行銷系統？ 我之前也寫過把專業知識變成軟體，讓產業專家成為下一代產品經理。現在可能又多了一條路：不一定要先做 SaaS，也可以先把專業知識整理成 Skill。 從產業經驗到 AI 可執行 Skill 的概念示意。 一個資深電商工程師的經驗，如果要整理成 AI 能使用的 Skill，可以從常見情境開始，逐步寫清楚： 什麼情況下要啟動檢查。 要沿著哪些訂單、金流和庫存流程追蹤。 哪些例外狀況需要特別確認。 要用什麼證據判斷流程真的完成，而不是只看單一測試顯示綠燈。 如此一來，AI 就不只是「會寫程式」，還能重複參照一套做過許多台灣電商專案的人累積的判斷方式。 下一波 Vibe Coding 機會，可能是台灣產業 Domain Skills未來 Skill 最有價值的地方，不一定是 React Skill、Next.js Skill 或 Python Skill。這些通用技術知識，模型本身會越來越強。 更可能形成差異化的，是懂得台灣產業實際怎麼運作的 Domain Skills，例如： 台灣電商金流與物流。 台灣電子發票、統編與發票規則。 LINE 官方帳號與會員流程。 政府 Open Data 與台灣個資保護情境。 房仲成交流程、補教招生、餐飲訂位、美容預約與傳統產業報價。 這些領域的共同點是：模型可能知道技術，但不一定知道台灣的商業流程、例外情境與在地作法。而真正掌握這些 Know-how 的人，往往是已經在產業裡工作十年、二十年的實務工作者。 Skill 不只是提示詞，而是可以交給 Agent 使用的 SOP我現在看 Skill，已經不只把它當成「提示詞」，而是可以被 AI Agent 使用的產業 SOP。 以前經驗存在腦袋裡，後來我們把它寫成 SOP，再把 SOP 做成軟體。現在又多了一種形式：把 SOP 整理成 AI Agent 能參照與執行的 Skill。 Vibe Coding 的競爭，可能不只是誰比較會下 Prompt、誰比較會用 Claude Code 或 Codex，而是誰能把自己十年、二十年的產業經驗，整理成 AI 可以重複使用的能力。 模型會越來越強，寫程式會越來越便宜，API 串接也會越來越簡單。但有一件事情不會因此自動出現：你踩過的那些坑。 而那些坑，可能才是 AI 時代真正值得被「程式化」的專業知識。 這也是我看到 ecommerce-cia 之後，覺得最值得研究的地方。它表面上是在處理台灣電商金流、物流與流程稽核，背後示範的也許是一個更大的方向：下一波 Vibe Coding，不只是讓 AI 幫我們寫軟體，而是開始把一個產業真正的 Know-how，寫進 AI 裡。 常見問答 (FAQ)Q1：什麼是台灣產業 Domain Skill？台灣產業 Domain Skill 是把在地產業常見的情境、判斷方式、執行流程與例外處理整理成 AI Agent 可重複參照的規範。它能補足通用技術知識與實際商業流程之間的落差。 Q2：Domain Skill 和一般 Code Review 有什麼不同？一般 Code Review 多半檢查程式碼或單一 Function 的正確性；Domain Skill 可以引導 AI 沿著跨系統流程檢查狀態如何傳遞，例如金流通知、訂單更新、庫存處理與出貨。兩者處理的問題不同，實務上可以搭配使用。 Q3：如何把產業經驗整理成 AI Agent Skill？先整理常見情境與踩坑案例，再把觸發條件、判斷方式、處理步驟、例外狀況與驗證證據寫清楚，最後交由熟悉該產業的人用真實案例檢查。這樣的 Skill 才能承載可重複使用的專業判斷，而不只是一段泛用提示詞。