跳到主要內容

部落格

不定期分享最新資訊文章

  • article-【別再一鏡一鏡抽卡:我整理出一套真正能拍完整故事的 AI 短片製片 SOP】

    2026/10/4

    AI工具 AI Agent 影音行銷
    【別再一鏡一鏡抽卡:我整理出一套真正能拍完整故事的 AI 短片製片 SOP】

    最近我一直在研究 AI 影片。研究到後來,我發現真正困難的,早就不是「哪個模型生成的影片最好看?」而是:怎麼把十幾個 AI 生成鏡頭,變成一支角色一致、空間合理、故事看得懂,而且可以持續修改的影片? 最近看到漢森建築整理的 Kling AI 母女短片製作案例:從 12 格分鏡到 V2。再加上我前陣子研究的多人同場戲、平面圖與空間一致性、Blender 灰模、角色一致性、Risk Shot、AI 影片逐鏡生成、DaVinci Resolve MCP 和 AI Agent 自動粗剪,我開始把它們接成一套完整的 AI Film Pipeline。 以下是我整理給自己反覆使用的「享哥 AI 短片製片 SOP」。它不是綁定某個模型的提示詞大全,而是把故事、鏡頭、參考資料、版本和驗收接起來的製片流程。 先把故事拆成 Shot List,再開影片模型很多人做 AI 影片時,會直接對模型說:「一個媽媽看著多年沒回家的女兒,感動流淚,電影感。」生成不滿意就再抽一次。這樣很容易把時間和生成額度花在還沒定義清楚的故事上。 比較穩定的起點是先寫劇本,再拆成 Shot List。以兩分鐘短片為例,可以先列出 Shot 01 到 Shot 12,再為每一鏡定義: 時間與地點 出場人物、景別與鏡頭位置 人物在畫面中的位置、動作和視線 台詞、情緒,以及鏡頭結束時的狀態 例如 Shot 08 可以寫成:「地點是客廳;女兒站在玄關右側,母親坐在沙發左側。女兒停下腳步,轉頭看向母親,保持眼神接觸並說:『媽,我回來了。』母親不說話,停頓兩秒,眼眶開始泛淚。」 「母親不說話」和「停頓兩秒」都是製片規格的一部分。若不寫清楚,模型可能自行加上台詞或動作。Shot List 的目的不是寫得更像小說,而是讓每一鏡都有能執行、能驗收的條件。 建立 Character Bible,先穩住角色角色一致性是多鏡頭影片最容易失控的地方。主要角色可以先建立 Character Bible,整理正面、左右 3/4 側面、半身與全身參考,以及年齡、髮型、服裝、身高比例和表情特徵。 角色跨越不同年齡時,分開整理,例如 Mother_Young、Mother_MiddleAge、Mother_Old,以及 Daughter_Child、Daughter_Teen、Daughter_Adult。每次生成只提供當下鏡頭需要的角色參考,避免把所有版本都塞進同一個 Context,讓模型多做不必要的判斷。 用 Location Bible 和 Spatial Map 固定空間單張圖漂亮,不代表剪在一起會像同一個地方。沙發、窗戶、門和主要光源若在不同鏡頭裡反覆換位置,觀眾會感覺空間跳掉。 重要場景可以建立 Location Bible,列出大門、沙發、電視、窗戶、餐桌、光源和人物活動區域,並畫一張 Top View 平面圖。多人同場戲再加 Spatial Map,固定人物 A、B、C 的站坐位置、彼此視線、前後景、攝影機位置,以及換機位後不能改變的相對關係。 三個人以上、走位、遮擋或多機位的場景,可以先在 Blender 做灰模 Blocking。放入房間、家具、人物方塊和 Camera,確認人物會不會被擋、構圖是否合理、攝影機高度是否適合,再截圖作為 Composition Reference。這一步的重點不是做出漂亮模型,而是先把空間和機位講清楚。 Storyboard 是 Keyframe,不只是分格漫畫規格和空間建立後,再為每個 Shot 製作 Keyframe,例如 shot_01_keyframe.png、shot_02_keyframe.png。需要控制重要動作時,可以再補 Start Frame、Middle Frame 和 End Frame。 這些圖像參考要一起沿用 Character Bible、Location Bible、Spatial Map 和需要的 Blender Blocking,讓生圖模型有明確的構圖與人物依據。此時目標不是讓模型自由改編,而是先建立剪接時能接得起來的畫面。 先測 Risk Shot,別按順序一路生成12 個鏡頭不一定要從 Shot 01 開始做。先找出最可能失敗的 Risk Shot,例如多人互看、擁抱、手碰臉、擦眼淚、嘴型、快速走位,或鏡頭和人物同時移動。 假設 Shot 03、08、12 最難,就先做這三鏡的測試。若最難的鏡頭目前拍不出來,趁早改劇本、鏡位或表演設計;不要等前面十一鏡都完成,才發現結尾無法成立。順序應該是: Storyboard → Risk Shot Test → Production 把 Prompt 寫成可以驗收的動作序列「電影感、溫暖、感人、細膩」可以描述氣氛,但很難用來判斷生成結果哪裡出錯。更可控的寫法,是把鏡頭拆成連續動作: 女兒停下腳步。 慢慢轉頭看向母親。 維持眼神接觸,再開口說:「媽,我回來了。」 說完自然閉口,保持視線,不再說話。 每個鏡頭的 Prompt 可以依序整理成: Subject + Position + Camera + Action Sequence + Eye Contact + Dialogue Timing + Emotion + End State 這樣比較容易判斷問題出在轉頭、視線、嘴型,還是結尾多出不需要的動作。模型版本和功能會變,鏡頭規格與驗收邏輯則可以保留下來。 逐鏡生成並管理版本Risk Shot 通過後,再逐鏡進入正式 Production。Kling、Google Flow、Veo、MiniMax 等可以是不同階段的候選工具;具體能力、開放狀態和方案限制會隨版本變動,選擇時要以當下實際可用的功能為準。 每個 Shot 都保留規格、參考圖、Prompt、模型、版本和狀態,例如: 1234shot_08_v01.mp4 人物正確,視線錯shot_08_v02.mp4 視線正確,嘴型錯shot_08_v03.mp4 Passshot_08_final.mp4 記下每次失敗的具體原因,之後才知道要改提示詞、參考圖、運鏡還是表演,而不是讓整支影片反覆重生。 先完成 Rough Cut V1,再修單鏡第一輪素材不用每鏡都做到滿分。先把 Shot 01 到 Shot 12 放進 Timeline,完成 Rough Cut V1,再從整支影片檢查節奏。剪在一起後,可能發現 Shot 03 太長、Shot 06 可以刪掉、Shot 08 情緒不足,或 Shot 11 和 Shot 12 應該交換。 先看整體,再修局部。單看一鏡覺得漂亮,不代表它適合整支影片的節奏和情緒。 讓 AI Agent 和剪輯工具協助管理素材當每一鏡都整理成結構化資料,AI Agent 才有條件協助管理影片。例如為每個 Shot 記錄: 12shot_id, duration, character, location, prompt, model,version, status, issue, selected_version Agent 可以依 Shot List 檢視時長、黑畫面、重複畫面、音訊斷裂、字幕缺漏和對白 Timing,也可以協助標記待人工確認的角色或畫面問題。這些檢查結果是 review 線索,不能直接當成最終判斷。 若手上已有可用的 DaVinci Resolve MCP 或其他剪輯操作介面,可以把 Shot Metadata、素材搜尋、selected_version、時間軸排列、字幕和 Rough Cut 輸出接成一條流程。工具串接方式會依實際環境而異;每次操作仍應保留人工檢查和可回復的版本。 V1 之後只修有問題的 ShotReview 時逐鏡記錄問題,例如 Shot 03、04 通過,Shot 05 嘴型不準、Shot 07 手部異常、Shot 08 節奏太慢。接著只處理需要修的鏡頭:嘴型問題可評估 Audio Fix 或 Lip Sync,手部問題可重生 Shot 07,節奏問題則可 Trim、調速或重生 Shot 08。 替換後輸出 Rough Cut V2,再重新檢查前後鏡的銜接。保留其他已通過的鏡頭,才能把修改成本集中在真正出問題的地方。 Technical QA 通過後,仍要 Human Final Review影片輸出後,先做 Technical QA:解析度、FPS、Codec、Bitrate、Duration、音訊取樣率、字幕數量、黑畫面、靜音與完整解碼。這些檢查能確認檔案是否符合技術條件。 Technical QA Pass 不等於影片好看。最後還是要從頭看到尾,確認角色有沒有變臉、視線和空間方向是否合理、嘴型自然不自然、情緒有沒有中斷、音樂音量是否合適,以及故事是否看得懂。 把流程接成一套 AI Film Production System整套流程可以整理成: 123456789101112131415161718192021Idea ↓Script → Shot List ↓Character Bible → Location Bible → Spatial Map ↓Blender Blocking(複雜鏡頭需要時) ↓Storyboard / Keyframe ↓Risk Shot Test ↓逐鏡生成 → Version Management ↓Rough Cut V1 → AI Agent Review → 剪輯工作流 ↓局部修正/重生 → Rough Cut V2 ↓字幕/BGM/混音 → Technical QA ↓Human Final Review → Master Export 研究到這裡,我反而覺得「AI 導演」比「AI 生影片」更值得學。模型會換,提示詞寫法也會變;但怎麼說故事、拆 Shot、控制角色和空間、安排鏡位、驗收素材與管理版本,仍然是製片能力。 我想把 Shot List、Character Bible、Prompt、Reference、Version、Issue、Status 和 Selected Clip 都整理成結構化資料,再讓 AI Agent 協助管理。理想分工是:人負責導演和決策,Agent 協助製片管理,生成模型提供鏡頭素材,剪輯工具完成後期。這不是按一下就能完成整部片,而是一套能持續修正的 AI 影片工作流。 想先從故事本身開始,可以接著讀AI 影片新手最容易學錯的:把「高級感」當成影片能力;想把鏡頭描述得更清楚,也可以看AI 攝影語言與 Google Flow 運鏡提示詞。 常見問答 (FAQ)Q1:製作 AI 短片前,應該先生成影片嗎?建議先寫劇本和 Shot List,為每鏡定義人物、位置、動作、視線、台詞與結束狀態,再建立角色和場景參考。這能讓影片生成有明確規格,也方便判斷結果要修哪裡。 Q2:什麼是 AI 短片的 Risk Shot?Risk Shot 是整支影片中最可能失敗的鏡頭,例如多人互看、擁抱、手部接觸、嘴型或複雜走位。先測這些鏡頭,可以在大量生成前調整劇本、鏡位或表演。 Q3:Blender 灰模是 AI 影片製作的必要步驟嗎?不是。單人鏡頭或簡單對話通常可用平面圖和空間參考處理;多人、遮擋、走位或多機位等複雜場景,才值得用 Blender 灰模預演人物位置與構圖。 Q4:AI Agent 可以直接決定哪些鏡頭要保留嗎?Agent 可以整理 Shot Metadata、標記技術問題或提供 review 線索,但角色一致性、情緒、空間連戲和故事可讀性仍需要人工從頭檢視,不能把自動檢查結果當成最終通過。 Q5:Rough Cut V1 之後,要整支影片重新生成嗎?通常先定位有問題的鏡頭,再局部修正或重生並輸出 V2。保留已通過的版本,能避免把修改成本擴大到整支影片。

  • article-AI Coding 成本最佳化:多模型分工取代單一高價方案

    2026/10/3

    AI工具 AI Agent AI Coding
    AI Coding 成本最佳化:多模型分工取代單一高價方案

    最近我一直在想:AI Coding 有沒有必要每個月都花到 200 美元?我曾同時使用好幾個高階方案,處理 ERP、電商、遊戲化功能、自有平台,以及已上線的商用專案。按我當時的帳號組合計算,相關月費一度超過 1,100 美元。這是我的實際成本背景,不是各家目前的統一價目表。 實際開發一段時間後,我開始重新拆解工作流程。我的結論不是「便宜模型比高價模型聰明」,而是:不要讓最貴的模型長時間處理它不必親自完成的重複工作。 AI Coding 最花錢的,不一定是第一次寫程式一個功能通常不只包含產生程式碼。開發過程還要理解需求、讀取 Repository、找出相關檔案、建立上下文、執行測試、閱讀錯誤、修改,再跑一次回歸檢查。 以我的工作經驗,成本容易在這些反覆往返中累積。程式碼第一次產生出來,只是整個交付循環的一部分;「確認它有沒有做對」也需要時間、工具使用量與人工注意力。 如果同一個模型從規劃一路做到測試、Debug 和 Code Review,它當然可能全部完成,但每個回合都可能重新讀取大量脈絡。這就像讓資深技術主管每天親自改 CSS、修 lint、重跑測試和讀 log:做得到,不代表每件事都值得用同一種成本處理。 先分配工作,再挑選模型我現在會把 AI Coding 流程拆成幾個角色。Claude、Codex、DeepSeek、Kimi 等名稱只是我使用過或評估過的例子;模型能力、工具整合與方案額度會變動,分工原則比固定排名耐用。 角色 主要工作 交付內容 規劃者 釐清需求、找出限制、設計模組邊界、拆分任務 SPEC、Issue、驗收條件 獨立審查者 從另一個角度找邏輯漏洞、權限與資料風險、測試缺口 有證據的問題清單與修正建議 實作者 按照明確範圍完成程式碼、測試與必要修正 可檢查的程式碼差異與測試結果 最終驗收者 核對需求、測試結果與整體風險,決定是否合併 驗收紀錄與合併決策 讓強模型把方向想清楚規劃階段會影響後續每一個 Issue。這時我會優先使用自己熟悉、能處理複雜上下文的模型,請它整理需求、資料流、模組邊界、依賴條件與可能的失敗情境。 SPEC 不必很長,但要讓下一個角色能知道要改什麼、不能改什麼,以及如何判斷完成。把模糊的「做一個登入功能」改成明確的行為與驗收條件,通常比不停追加長提示更容易控制工作範圍。 請另一個模型獨立找問題規劃模型很容易沿著自己的假設往下推。讓不同模型閱讀同一份 SPEC 與 Issues,可以增加一個獨立檢查角度,但不保證一定找到所有缺陷,也可能產生不成立的疑慮。審查者應指出依據,最後仍由人判斷並透過測試確認。 我會用類似以下的任務說明: 12345678910請獨立檢查這份 SPEC 與工作項目,先不要開始實作。請找出:- 未定義的邊界情況- 權限與資料一致性風險- API 或模組設計上的衝突- 測試條件不足或互相矛盾之處每個問題請附上對應段落、影響與可驗證的修正建議。不確定的地方請標明假設,不要把推測寫成已確認的缺陷。 同一個模型自行規劃再自行審查,也可能有幫助;只是它未必能跳出先前採用的假設。換一個模型是增加檢查角度,不是把責任交出去。 把明確的實作工作交給合適成本的模型當需求、檔案範圍和驗收方式已經清楚,實作者不一定每次都要重新推演整個產品背景。可以把工作拆成一個有邊界的 Issue,附上必要檔案與驗收條件,再依任務風險選擇模型或 API。 12345Issue:新增訂單狀態篩選依驗收條件實作,只修改訂單列表相關模組。新增或更新對應測試,執行測試並修正失敗。回報修改檔案、測試指令與結果;不要變更無關功能。 如果便宜模型無法完成,或實作牽涉安全、付款、資料遷移等高風險範圍,就應提高模型能力或安排更多人工審查。省下的 API 費用若換來大量重工,整體成本仍可能更高。 一套可試跑的多模型工作流程123456789101112131415需求 ↓規劃模型:釐清需求、整理 SPEC 與 Issues ↓另一個模型:獨立審查假設、風險與驗收缺口 ↓修正規格,由人確認範圍 ↓實作模型:逐項完成工作並執行測試 ↓獨立檢查:核對差異、測試與風險 ↓必要時請規劃模型處理重大設計問題 ↓人工決定是否合併 高價模型集中在開始前的關鍵決策與結束前的重要審查;大量、界線清楚的實作與修正,則可由成本較低且足以勝任的模型處理。不同任務的比例不必相同,也不需要為了湊出「三個模型」硬加一個角色。 $20、$60 與 $200 要怎麼比較?「20 美元團隊打敗 200 美元方案」比較像工作流的比喻,不是每個人都能複製的保證結果。比較方案時,先把固定月費、API 用量、超額費用和人工檢查時間一起算進去。 截至 2026 年 10 月 3 日,官方頁面列出的美國月繳價中,Claude Pro 為每月 20 美元,ChatGPT Plus 也為每月 20 美元。ChatGPT 方案的 API 用量另計,Codex 的可用功能與使用額度會依方案及帳戶狀態變動;DeepSeek API 則依模型與 Token 用量計價。地區定價、稅金、額度與方案內容可能不同,請以自己帳戶當下顯示的資訊為準。 因此,20 + 20 + 20 = 60 只有在第三筆 API 預算實際用了 20 美元時,才是當月約 60 美元的情境估算。API 並不是固定每月 20 美元的訂閱;不用或少用時可能低於預算,長任務也可能超出預算。若把比較基準設成 200 美元月費,60 美元確實是算術上少 70%;這不代表每個專案都能以相同品質和時間完成。 本文提到的高階方案支出是作者當時的個人經驗;上述方案資訊是依官方頁面於 2026 年 10 月 3 日查閱的美國月繳標價整理。價格、額度與模型可用性可能變動,應以官方頁面和帳戶實際顯示為準。 更實用的比較單位是「每個通過驗收的工作項目花多少成本」。可以先挑一種低風險、可重複的任務,記錄 API 費用、修正回合、人工檢查時間與測試結果,再比較單一模型和分工流程。只看 Token 單價或訂閱金額,容易忽略重新交代上下文與返工的成本。 怎麼開始試,而不讓多模型增加混亂? 選一個低風險任務。 暫時不要把付款、權限或正式資料遷移當成第一個試驗。 先寫好規格與驗收條件。 明列目標、修改範圍、不能變動的內容,以及要執行的測試。 讓審查者先看規格。 要求它列出有依據的風險與缺口,先由人確認哪些需要修正。 把實作切成小工作項目。 每項工作都應能單獨檢查,並有明確的完成條件。 記錄總成本與結果。 除了 API 帳單,也記下返工時間、失敗案例與人工驗收時間。 依數據調整分工。 如果模型切換讓你花更多時間搬運上下文,合併角色或改用單一模型可能更有效率。 把程式碼、Issue 或內部文件交給不同服務前,也要先確認公司的資料政策與各服務的資料使用設定,不要把金鑰、.env 或不該外傳的內容放進提示。多模型協作會增加資料流向的服務數量,資料邊界應一起納入架構決策。 如果想看更具體的需求討論、建立 Ticket,再交由 Codex 實作與 Review 的接力方式,可參考我把 ChatGPT 接上開發台後整理的 AI Coding 工作流。 不需要把 200 美元方案視為浪費如果高階方案每月替你省下的時間或帶來的價值遠高於費用,它可能很划算。當下時間有限、專案複雜、需要更高使用額度,或一個錯誤的代價很高時,集中使用能力更強的模型也有合理性。 我真正想改變的是「唯一最強模型包辦全部」這個預設。規劃、審查、實作和驗收是不同工作;先定義角色,再看現有模型與方案能不能勝任。模型是可以更換的供應者,流程、驗收條件和風險控制才是團隊長期要維護的資產。 常見問答 (FAQ)Q1:多模型分工一定比單一 AI Coding 方案便宜嗎?不一定。多模型可能降低高價模型處理重複工作的支出,也會增加 API 用量、切換上下文和人工整合成本。應以通過驗收的成果、API 帳單與人工時間一起比較。 Q2:每月 60 美元就能取代 200 美元的高階方案嗎?這是 20 + 20 + 20 的情境算術,第三筆若是 API 預算,實際帳單會按用量變動。模型額度、任務複雜度和返工時間也會影響結果,因此不能把 60 美元當成固定套餐或品質保證。 Q3:為什麼要讓另一個模型審查規格或程式碼?不同模型可能採用不同假設,獨立審查有機會發現規劃階段漏掉的邊界條件、風險或測試缺口。但審查也可能誤報,必須提供依據並以程式碼、測試和人工判斷確認。 Q4:怎麼判斷哪些任務可以交給較便宜的模型?先從範圍小、驗收明確、出錯容易回復的任務開始。觀察它能否在可接受的修正次數內完成,並確認測試、權限和資料要求都符合專案標準。 Q5:ChatGPT Plus 月費是否包含 OpenAI API 使用?不包含。OpenAI 說明 Plus 訂閱與 API 計費分開;Codex 功能和額度則依方案、帳戶及當下可用性而異。採用 API 工作流前,應分開估算訂閱費和 API 帳單。 官方方案與 API 資訊以下官方頁面用來確認本文的方案/計費邊界,查閱日期為 2026 年 10 月 3 日。實際使用前請再次查看最新資訊: Anthropic 方案價格 ChatGPT Plus 方案與 API 計費說明 Codex 與 ChatGPT 方案的可用性和額度 DeepSeek API 模型與 Token 價格

  • article-不要再蒐集 Skill 了:我開始建立自己的 Skill Factory

    2026/10/3

    AI工具 AI自動化 AI Agent
    不要再蒐集 Skill 了:我開始建立自己的 Skill Factory

    最近我一直在研究 Agent Skill。GitHub 上每天都有人分享新的 Skill,從「必裝清單」到上百個 Skill 的合集,我自己也常常看到不錯的就安裝。 前陣子算了一下,我裝的 Skill 加上 Plugin 指令已經超過 100 個。但我開始問自己:裝了這麼多,AI 真的有變得比較懂我嗎? 答案沒有想像中明顯。 最近看到理工威森分享〈不用懂技術,3 步把一本書蒸餾成你的 AI 技能〉,他談到把書中的方法 Distill 成 Agent 能使用的規則。我很喜歡這個方向,也開始想:蒸餾的材料,為什麼只能是書? 我真正想建立的,可能不只是 Skill Library,而是一座會把知識、經驗和工作紀錄轉成可用能力的 Skill Factory。 Skill 越多,為什麼 AI 不一定更懂我?看到 GitHub 上不錯的 Skill,就安裝;看到別人推薦,又安裝。Skill Library 很容易變成另一種「稍後閱讀」:收藏了一大堆,真正工作時卻不確定該用哪一個。 更重要的是,那些 Skill 描述的是別人的工作方法。它可能很好,卻不一定符合我的寫作方式、課程設計流程、簡報架構、網站驗收標準、Agent 工作流程或客戶溝通方式。 所以我現在更在意的,不是「我安裝了多少 Skill」,而是: AI 到底學會了多少我的工作方法? Skill 的價值,在於它能不能讓 Agent 理解一項工作何時開始、該怎麼判斷、如何完成,以及什麼情況才算驗收通過。 蒸餾的不是摘要,而是判斷規則假設讀完一本談判的書,請 AI 摘要,可能會得到幾個核心觀念、金句和技巧。看完當下覺得有收穫,過一段時間卻不一定記得怎麼用。 如果我希望 AI 學會用這本書的方法處理客戶殺價,問題就不只是「這本書在講什麼」,而是「遇到這種情境時,AI 要怎麼判斷與行動」。 例如客戶說太貴,Agent 可以先協助釐清:是真的預算不足、還沒理解價值、正在測試議價空間,還是拿競爭對手比較?可能原因不同,下一步就不該一律回覆同一句話。 這類「遇到什麼情況、先確認什麼、依什麼條件分流、最後如何檢查」的規則,才比較接近能放進 SKILL.md 的工作方法。一本書最後留下的,不必是完整摘要,而可以是 Agent 在實際任務中用得上的流程。 真正值錢的,也許是我自己的工作經驗一本暢銷書或熱門 Skill,很多人都能取得;但我過去十幾年的工作經驗,只有我自己有。 我長期做 AI 教學、企業內訓、數位行銷、網站、AI Agent、Vibe Coding、LINE API 和自動化流程。這些經驗的價值,不只在於我知道哪些工具,更在於遇到不同狀況時,我會怎麼判斷。 例如製作一套課程,我逐漸形成了這樣的流程: 需求分析 → 學員分析 → 課程架構 → 實作設計 → Slide Manifest → 簡報 → 講義 → Prompt Card → 實際操作 → 驗收 這套流程不是哪一本書直接教我的,而是做過許多次後慢慢磨出來的。如果每次開新的 Agent Session 都要從頭解釋,這些方法就沒有真正累積下來。 把「我糾正 Agent 的地方」留下來建立 Skill 時,我不想只靠回想「自己通常怎麼工作」。人描述自己怎麼做,和實際工作時做出的選擇,有時並不完全相同。 更直接的材料,是我和 Agent 一起完成工作的 Session。過程裡,我可能會說: 「這頁不對,實作比例太低。」 「這個提示詞要給建議填值。」 「簡報大綱跟講義對不起來。」 「先做 Slide Manifest。」 「新手在這裡一定看不懂。」 這些修正看起來只是聊天紀錄,背後卻可能藏著課程比例、教材一致性、提示詞易用性和讀者理解門檻等專業判斷。 如果我反覆要求 Agent 修改同一類問題,或每次都得重新解釋相同規則,那就值得回頭檢查:這是一次性的需求,還是已經穩定到可以成為工作規則? 我會從三種來源蒸餾 Skill1. Knowledge Distill:把外部知識變成可執行方法材料可以是書籍、YouTube、Podcast、課程、文章或研究報告。目標不是把來源濃縮成摘要,而是抽出適用情境、判斷方式、步驟和限制,讓 Agent 能在工作中使用。 2. Experience Distill:把實務經驗整理成自己的 Know-how把自己做過多次的工作拆開來看,例如如何設計 AI 課程、規劃企業內訓、寫粉專文章、驗收網站、設計 Agent Workflow,或拆解 Vibe Coding 專案。 這些經驗不必一開始就寫成很大的 Skill。先把一項工作中反覆出現的判斷和品質標準說清楚,就已經是有價值的原料。 3. Session Review:從和 Agent 的工作紀錄找出規則回顧過去的 Session,觀察自己反覆要求修改、最常否決、重複說明或固定採用的決策。這些重複出現的訊號,可以幫助我找到那些平常不一定會主動說出口的工作方法。 把 Skill Library 變成 Skill Factory我想把建立 Skill 的流程整理成五個階段: Capture:先留下真實工作過程先照常完成一項真實任務。讓 Agent 參與實際工作,保留足以看出需求、修改、判斷與結果的過程,不急著在開始前猜測自己應該怎麼做。 Distill:抽出能重複使用的規則任務完成後,請 Agent 協助找出自己曾經糾正、修改、否決、補充或重複要求的地方,再把它們整理成偏好、SOP、判斷規則、品質標準、禁止事項和驗收條件。 一條規則最好能說清楚觸發情境、要採取的行動,以及怎麼判斷結果合格;遇到例外時,也要知道何時該停下來確認。 Test:拿另一個真實任務試用寫完 Skill 不代表它已經有效。可以把它用在另一個相似但不同的工作上,觀察自己是不是少講了重複要求、Agent 是否更接近預期,以及規則有沒有造成新的問題。 例如,若以前一份教材要反覆修改很多次,套用 Skill 後所需的修正明顯減少,這是值得追蹤的訊號;但重點不是達到固定數字,而是確認工作結果與協作過程是否真的改善。 Review:請另一個模型找出盲點我也想使用多模型做對抗性 Review。例如一個模型協助規劃,另一個模型負責執行,再請第三個模型檢查完成的 Skill。不同模型可以從不同角度找出規則衝突、描述模糊、無法執行、限制過多、缺少例外或難以驗證等問題。 模型提供的是審查意見,最後仍要回到實際工作驗證:規則是否符合我的目的、是否改善結果、是否保留了必要的彈性。 Promote:通過驗證後再納入穩定版本Skill 可以先放在 Experimental,經過實際任務測試後進入 Testing,確認適用範圍、品質和例外都清楚,再升級到 Stable。 不是每個聊天指令都要變成 Skill。單次需求可能只適用於那個任務;經常重複、可清楚描述而且能在別的任務中驗證的方法,才比較值得正式留下來。 GitHub 不只是放 Skill 的地方如果持續累積,Skill 的組織方式也會慢慢清楚。初期可能有課程設計、文章寫作、簡報 Manifest、網站 Review 和 Agent Workflow;之後再依工作領域整理: 教學:課程設計、實作活動、Prompt Card。 內容:部落格文章、Facebook 貼文、教學文件。 開發:專案規劃、對抗性 Review、驗收。 商務:提案、客戶需求、報價。 這時 GitHub 就不只是擺放 Skill 的地方,也能協助記錄每個工作方法如何形成、如何修改,以及目前驗證到什麼程度。它逐漸累積的會是「我的數位工作方法」。 AI 之間的差距,可能也來自它有多了解你以前我常比較 GPT 和 Claude 哪個比較強、不同模型寫程式的能力如何。隨著模型能力演進,我也開始思考:另一個差異會不會是 Agent 已經掌握多少你的工作方法? 兩個人即使使用同一個模型,一個每次都要從零說明,另一個已經累積多年工作規則和經過驗證的 Skill,實際合作起來可能就會很不一樣。 因此我現在不只把 Skill 看成外掛或工具清單,也把它當成一種能被整理、測試和更新的經驗。若你想先了解我對 Skill 與 Skill Library 的想法,可以接著閱讀從 Prompt 到 Skill Library:我從 Agent Skill 講座學到什麼。 以後完成一件工作,我想多問自己一句: 這次有沒有什麼值得留下來,變成 Skill? 看到一本好書,可以 Distill;完成一個專案,可以 Distill;和 Agent 來回修正很多次,也可以回頭檢查那些反覆出現的判斷。 我不再只追蹤「我有幾個 Skill」,而想知道:「有多少原本要我親自判斷的事情,Agent 已經真正學會了?」 當這個數字慢慢增加,我建立的就不只是 AI 工作流,而是一套越來越像我的 AI 工作系統。 常見問答 (FAQ)Q1:Skill Factory 和 Skill Library 有什麼不同?Skill Library 著重收納 Skill;Skill Factory 則著重把知識、實務經驗和工作紀錄,經過整理、測試與 Review,逐步製作成可重複使用的 Skill。 Q2:什麼樣的工作經驗值得整理成 Skill?如果一項判斷或要求在多次工作中反覆出現,而且能說清楚適用情境、處理方式與驗收條件,就值得評估是否整理成 Skill。只適用於單一任務的指令,不一定需要升級成固定規則。 Q3:要怎麼知道 Skill 有沒有用?把它用在另一個真實任務,觀察 Agent 是否少了重複提醒、結果是否更符合預期,以及 Skill 是否帶來新的錯誤或限制。用實際工作表現來修正規則。 Q4:可以把每一次糾正 Agent 的內容都寫進 Skill 嗎?不必。先分辨那是單次需求,還是跨任務都適用的工作方法。反覆出現、能清楚說明並且可以驗證的規則,通常更適合成為 Skill。 Q5:多模型 Review 可以取代實際測試嗎?不行。其他模型可以幫忙找模糊描述或規則衝突,但是否符合你的工作方式,仍要透過真實任務驗證,再決定要不要升級到 Stable。

  • 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-Custom GPT 要退場了,真正值得學的不只是 Plugin:開始打造自己的 Skill Library

    2026/10/2

    AI工具 ChatGPT AI Agent
    Custom GPT 要退場了,真正值得學的不只是 Plugin:開始打造自己的 Skill Library

    最近看到《數位時代》談到 Custom GPT 遷移 Plugin,我第一個想到的不是「Custom GPT 要消失了」,而是 OpenAI 正在把工作流程、工具和可重複使用的指引放進同一套架構。 如果你也在研究 AI Agent、Codex、Claude Code、Skill 或 MCP,這次轉變值得關注。不過我認為最值得學的不是趕快做一個 Plugin,而是把平常怎麼工作的經驗整理出來,讓 AI 能在類似任務中重複使用。 以前我們常想:「我要做一隻幫我寫文章的 GPT。」現在可以多問一題:「我寫文章時有哪些步驟、判斷和檢查,值得整理成一套工作方法?」 Custom GPT 何時退場?先看適用帳號與公告依 OpenAI 目前的Custom GPT 退場與遷移說明,Custom GPT 預計在 2026 年 12 月 11 日退場;符合條件並取得核准延期的 Enterprise 工作區,時程可延至 2027 年 2 月 11 日。官方也提醒,遷移和功能開放時間可能依帳號或工作區而不同,應以自己的產品通知為準。 另一個容易混淆的日期是 2026 年 10 月 26 日。依目前 FAQ,這是受影響 Enterprise 工作區預計停止建立新 GPT 的日期;這項建立限制不等於所有方案都在同一天停止建立。官方公告可能調整,準備遷移前最好再看一次自己帳號收到的通知。 已遷移的 GPT 在適用的退場日前仍可使用,但會變成唯讀。也就是說,遷移不是按下按鈕後就能永遠保留原本的編輯方式;先確認重要指示已更新,再遷移和測試會比較穩妥。 遷移會搬什麼?哪些要另外處理?依官方規劃的遷移流程,原本的 GPT 指示會變成 Plugin 裡的 Skill,Knowledge 檔案會複製為參考檔案,已連接的 App 則會加入 Plugin。這讓原本集中在一隻 GPT 裡的內容,開始拆成工作流程指引與外部工具兩個部分。 但遷移不會完整保留所有東西: Custom GPT 原有內容 遷移後的安排 需要留意的地方 Instructions 變成 Skill 檢查指示、範例與輸出要求是否正確 Knowledge Files 複製到 Plugin 的參考檔案 確認檔案內容與引用方式都符合原本用途 已連接的 App 加入 Plugin 的 App 仍要確認帳號授權、工作區權限與可用功能 指定模型 不會隨遷移保留 重新檢查替代工作流程使用的模型 Custom Actions 不會自動遷移 評估現有 App,或另行重建 MCP 整合並測試 對話紀錄與分享設定 不會搬到新 Plugin 確認哪些人需要存取新版本,並重新安排分享 所以,不要把遷移想成「GPT 按一下就變成 Plugin,而且每個地方都一樣」。比較實際的做法是把 GPT 當作一份流程草稿:盤點內容、確認缺漏,再驗證新的 Skill 和工具能不能完成原本的工作。 Plugin、Skill、App 和 MCP 怎麼分工?可以先用這幾句話理解: Skill 說明工作應該怎麼做,例如先蒐集哪些資訊、如何判斷例外、最後用什麼格式交付。 App 讓 ChatGPT 或 Codex 連接外部服務與資料,例如雲端文件或工作平台;連線仍受帳號授權和工作區權限限制。 MCP 是提供模型工具、即時資料與受控動作的一種介面。MCP 服務提供「可呼叫什麼」,Skill 則可以描述「何時呼叫、依什麼順序、結果不完整時如何處理」。 Plugin 可以把一個或多個 Skill、連接的 App,以及相關設定組合成可安裝與重用的工作流程套件。有些 Plugin 只有 Skill,不一定要連 App。 Agent 根據任務與可用能力判斷怎麼進行,再呼叫需要的 Skill 和工具。 這些概念有關聯,但不該直接畫上等號。OpenAI 的Plugin 說明指出,Plugin 可以包含 Skills、連接的 Apps 和其他設定;Skills 開發文件則說明,Skill 能為 MCP 工具提供可重複使用的流程指引。Skill 也可以在不連接 MCP 的情況下工作。 在支援 Skills 的 ChatGPT 帳號中,已安裝的 Skill 可能在適合時由 ChatGPT 自動使用;功能開放仍依產品、方案與工作區設定而異,也不代表每次對話都會呼叫同一個 Skill。官方 Skills 說明有列出目前的開放條件與使用方式。 舉例來說,一個客戶預約 Skill 可以寫下:先判讀需求、查看客戶紀錄、列出可選時段、等使用者確認後才建立預約。查詢行事曆或寫入 CRM 則需要相應的 App 或工具;流程指引本身不會憑空取得服務權限。 Skill 不只是把 Prompt 存成檔案Prompt 通常是在描述「這一次要做什麼」。SOP 把反覆工作的步驟和檢查條件整理下來。Skill 則可以把流程、判斷方式、範例和參考資源包成一份,讓 AI 在遇到相似任務時能重複使用。 以部落格寫作為例,單次 Prompt 可能只說「幫我寫一篇文章」。成熟的工作方法還會包含: 文章要給誰看,解決什麼問題? 如何確認事實、保留來源與區分推論? 標題、段落和 FAQ 要符合什麼格式? 哪些語氣或說法要避免? 交稿前要檢查哪些欄位與連結? 這些規則如果每次都要重新貼上,就還是一次性的指令。把它們整理為可呼叫、可維護的流程後,才開始接近 Skill。 我會把這段演進理解成: 1Prompt → SOP → Skill → Skill Library → Plugin 需要操作外部服務時,再接上 App 或 MCP。這不是每個人都必須照著走的產品安裝順序,而是把個人經驗整理成可重用能力的一種方法。我先前也寫過如何從 Prompt 整理出自己的 Skill Library,這篇則聚焦在 Custom GPT 遷移後,這些工作方法要如何拆開與驗證。 為什麼我開始整理自己的 Skill Library?我前陣子算了一下自己的環境,Skill 加 Plugin 指令已經裝超過一百個。工具多了,不代表 AI 就更懂我;如果沒有自己的流程與判斷準則,裝再多別人的 Skill,也只是多了一堆尚未融入工作的選項。 真正值得留下來的,常常是每天會用到的方法:我怎麼研究工具、準備課程、規劃簡報、整理客戶需求、寫文章,還有哪些容易出錯的地方。這些經驗可以逐步整理成一個自己的 Skill Library,例如: 123456789101112131415161718享哥 Skill Library├── Writing│ ├── blog-writing│ ├── facebook-post│ └── course-copywriting├── Teaching│ ├── course-outline│ ├── slide-manifest│ └── hands-on-lab├── Research│ ├── fact-check│ └── tool-research├── Video│ ├── short-video-script│ └── storyboard└── Coding ├── vibe-coding └── deployment-check 這是一份可以逐步發展的示意清單,不必一開始就把所有工作分類完成。先找出一件高頻、步驟穩定、自己常要重新解釋的工作,寫清楚輸入、判斷、例外與輸出,再用實際任務修正。 將來真正有價值的,可能不是一份幾千字的 Prompt,而是把多年工作經驗整理成 AI 可以理解、重複使用,也能檢查結果的工作流程。房仲可以整理房源分析與客戶跟進;會計師可以整理財報閱讀與文件檢查;講師可以整理課程規劃與實作設計。這些例子都要從自己的實際流程開始,不能只套用別人的模板。 Custom GPT 遷移前,先做這五件事1. 盤點自己建立或依賴的 GPT列出 GPT 的用途、使用頻率、維護者和需要使用它的人。幾乎沒在用的,可以先不遷移;只是一段簡單 Prompt 的,可以先保存指示;每天工作都會用到、含有穩定流程的,才值得花時間測試替代方案。 2. 拆出流程、資料與工具把 Instructions 中的步驟、判斷、例外和輸出規格整理出來,再分別核對 Knowledge 檔案、App 連線與 Custom Actions。尤其有 Custom Actions 時,要先確認新的 App 或 MCP 整合是否具備需要的功能,不要假設舊 API 串接會自動保留。 3. 在遷移前完成必要編輯官方說明指出,遷移會使用 GPT 最新的已發布版本;未發布的草稿修改不會直接搬過去。需要保留的規則和檔案,先整理並確認版本,再開始遷移。 4. 用熟悉任務和困難案例測試先用平常最常做的任務檢查替代 Plugin 是否選對 Skill、引用到預期的參考檔案、產出正確格式,再拿一個較難的案例測試例外處理。若有連接 App,也要另外檢查授權、可讀寫範圍和動作確認設定。 5. 重新確認分享與權限遷移不會自動把原本 GPT 的分享設定帶到 Plugin。個人 Plugin 預設為私人,讓同事或客戶使用前,要確認他們能安裝、連線並取得需要的權限。 新手不用一次學完 Plugin、MCP 和 Agent如果這些名詞讓人覺得太多,我會建議按照自己的工作慢慢累積:先把需求寫清楚,再把常做的工作整理成 SOP;SOP 穩定之後,挑一段做成 Skill。當工作需要讀寫外部資料時,再評估 App 或 MCP;需要把多項流程組合、分享或提供安裝時,才考慮 Plugin。 至於 Agent,則是協調模型、Skills 與工具完成任務的執行方式。可以先從一個可重複驗證的小流程開始,不必為了跟上名詞而把每一層都裝齊。 真正值得累積的是可執行的經驗Custom GPT 的遷移提醒我們:一個好用的 AI 助手,不只有幾句 Instructions。它可能還包含參考資料、工具連線、權限設定,以及人們多年累積的判斷方式。 Plugin 是把工作能力組合與分享的容器;Skill 承載可重複使用的流程;App 和 MCP 提供連接資料與操作工具的能力。對我來說,最值得先做的仍是把「自己怎麼工作」整理清楚。Prompt 可以告訴 AI 這一次做什麼,而一套經過檢查、持續修正的 Skill,才能把經驗帶到下一次相似的工作裡。 常見問答 (FAQ)Q1:Custom GPT 什麼時候會停止使用?OpenAI 目前規劃 Custom GPT 於 2026 年 12 月 11 日退場;符合資格並取得核准延期的 Enterprise 工作區,規劃日期為 2027 年 2 月 11 日。時程可能依帳號與工作區公告調整,請以自己的產品通知為準。 Q2:遷移到 Plugin 後,原本的 GPT 內容會全部保留嗎?不會。依目前遷移說明,Instructions 會成為 Skill、Knowledge Files 會成為參考檔案、已連接的 Apps 會加入 Plugin;指定模型不會保留,Custom Actions、對話紀錄與分享設定也不會完整遷移。 Q3:遷移後的 Plugin 會和原本 GPT 完全一樣嗎?不能假設兩者完全相同。官方建議使用熟悉的任務和較困難的案例測試 Skill 選擇、參考資料、輸出格式與工具整合,確認行為符合需求後再依賴新版本。 Q4:Skill 一定要連接 App 或 MCP 才能使用嗎?不一定。Skill 可以只提供流程指引、範例和參考資源;只有需要查詢外部資料或執行服務動作時,才需要適當的 App、MCP Server 或其他工具,而且仍受帳號與工作區權限限制。 Q5:如果我的 GPT 使用 Custom Actions,遷移前要做什麼?先列出每個 Action 使用的服務、輸入資料與必要動作,再確認是否有合適的 App;若需重建 MCP 整合,要分開設計並測試。Custom Actions 不會自動遷移,因此在替代方案完成驗證前,不要假設原本的 API 流程已經可用。 延伸閱讀 OpenAI:Custom GPT 退場與遷移 FAQ OpenAI:ChatGPT 中的 Skills OpenAI:ChatGPT 中的 Plugins 從 Prompt 到 Skill Library:如何打造自己的 AI 工作能力庫

  • article-ChatGPT Plugin 這波,我想先丟 5 個產品上去測水溫

    2026/10/2

    AI工具 ChatGPT 商業策略
    ChatGPT Plugin 這波,我想先丟 5 個產品上去測水溫

    最近看到有人把 ChatGPT 裡的工具生態,比喻成早期的 App Store 或 Facebook 應用程式。這個類比未必代表它們會走向同一種結果,但我看完後開始想另一件事:我手上是不是早就有很多可以重新包裝的產品? 我不是想直接 All in,也不想先猜哪一個一定會紅。我比較想趁著做產品的成本降低,挑幾個真實工作裡反覆出現的需求,試著放進新的對話入口裡測一輪。 這篇說的「Plugin」,先把名稱講清楚我這裡先用「Plugin」當一般說法,指的是讓使用者在 ChatGPT 對話裡叫得動的工具或工作流程。實際開發時,產品形式和上架流程要先分清楚:OpenAI 現行文件把 Plugin 描述成可組合 Skills、連接 App 等能力的工作流程;開發者也可以透過 Apps SDK 建立在 ChatGPT 中運作的 App,並了解如何提交到 ChatGPT app directory。OpenAI 的 Plugin 說明 與 Apps SDK 介紹 是兩條值得先讀的官方資料。 官方說明也提到,ChatGPT 會在相關情境使用已安裝的 Plugin,並可能在對話中推薦 Plugin。這讓我想到一個新的產品入口:使用者先說出需求,對話工具再協助他找到能完成工作的能力。**這是一個值得驗證的可能性,不代表每支產品都會被推薦或自然取得流量。**產品能否上架、被看見、被使用,仍要看平台當時的規則與實際數據。查看 Plugin 的使用與推薦方式。 我以前做過的工具,換個角度看都像產品雛形這一兩年,我為了課程、客戶和自己的工作,做過不少小工具: 個資去識別化工具 LINE OA 預約系統 客戶名單整理與報名資料處理 活動核銷文件整理 講師查詢系統 報價、請款和行政文件 Google Sheet 自動化與 AI 客服 B2B 名單開發流程 以前我會把它們分成 Vibe Coding 專案、小型 SaaS,或課程案例。現在我開始想:如果使用者不用先找到我的網站,而是先在 ChatGPT 說出需求,這些工具能不能從新的入口被找到? 我不是說工具做完就能自動找到客人。對 SaaS 來說,產品開發常常只是第一關;接下來還要面對 SEO、廣告、社群、內容行銷、業務開發和留存。若一個工具能進入使用者本來就在工作的對話情境,也許可以減少「先知道網站在哪裡」這一道門檻。至於能不能因此獲得流量,仍要實際測試。 我想先測的五個產品方向01|Privacy Cleaner:把個資整理成可分析的資料很多人想用 AI 分析 Excel,卻會先卡在姓名、電話、Email、身分證字號或地址能不能直接提供給 AI。 使用者真正會說的可能是: 幫我把這份資料裡的個資移除,我想交給 AI 分析。 初版可以讓使用者上傳 Excel 或 CSV,選擇要遮罩或替換的欄位,再輸出一份處理後的檔案。若產品需要保留日後還原的對照表,就要把它和處理後的資料分開保管,並限制存取;不能只把「可以還原」當成預設功能。 我想先從它開始,是因為自己已經做過類似問題,而且一句話就能說清楚工具要幫什麼忙。若想延伸了解企業使用 AI 時的個資與風險控管,也可以讀個人資料保護與 AI 風險控管。 02|Customer List Cleaner:整理亂七八糟的客戶名單真實世界的名單常有電話格式不一、姓名多空白、Email 前後有空格、公司名稱寫法不同,或同一個人重複報名等狀況。 使用者只要說「幫我整理這份客戶名單」,工具就可以先辨識欄位,再清除多餘空白、統一格式、標記可能重複的資料,最後輸出整理結果。重複資料如何判定、哪些內容可以合併,應該讓使用者檢視或設定,避免把不同的人誤合成一筆。 這種工具一點都不性感,卻有機會處理每天都會重複發生的小麻煩。 03|Taiwan Expense Assistant:整理台灣活動核銷資料做政府計畫、協會活動、職訓、講座或補助案的人,活動結束後常要整理簽到表、照片、發票、收據、講師鐘點費、領款憑單和支用單據。 工具可以協助列出目前收到哪些資料、還缺什麼、金額是否需要人工核對,以及哪些文件尚未簽名。它也可以依照特定案件需求產生核銷清單。它能協助檢查與整理,不應把 AI 判讀當成正式核銷審核或憑證效力的保證。 這類產品的價值不只在模型能力,而在於理解台灣在地流程與文件習慣。對大型國際產品來說可能太細,對每天在處理這些文件的人卻很具體。 04|Taiwan Business Docs:先把報價和行政文件做好「幫我做一張報價單」可能比「幫我打造企業級營運平台」更接近小公司老闆每天會說的話。 第一版可以從報價單、估價單、請款單、領據或活動簽到表等固定格式開始,讓使用者提供項目、數量、金額和客戶資訊,再產出可編輯的文件。之後才視需求串接 Gmail、Google Drive 或付款追蹤。 先把一份文件做好,再確認使用者是否願意反覆使用,比一開始就建置整套 CRM、文件管理和付款流程更容易驗證。若你也在探索 AI 如何降低小型 SaaS 的開發門檻,可延伸閱讀AI 讓程式碼越來越便宜,但知道什麼值得做正在變得越來越貴。 05|LINE Booking Manager:有價值,但整合成本較高我做過 LINE OA 預約流程,包含 AI 意圖判斷、查詢 Google Calendar 和人員時段、建立預約、寫入資料,再回覆 LINE。 未來如果能透過對話查詢「星期六還有哪些教練有空」,或調整某一筆預約,確實很有意思。但它也牽涉 LINE API、Google Calendar、OAuth、資料庫、租戶隔離與權限設定。這些都是產品要面對的工作,不是把現有系統接上一個 Plugin 名稱就會消失。 若這次的目標是測試使用者會不會從 ChatGPT 入口找到工具,我會把這個方向排在後面,先測小而明確的任務,再評估複雜整合是否值得投入。 五個產品不等於五套大工程我想測的不是五個做到完美的產品,而是五個清楚的使用情境。能重用的帳號、資料處理或文件輸出能力就盡量共用;每個方向先定義一個使用者需求、一個最小任務,以及怎樣算完成。 除了曝光、安裝或啟用等平台實際提供的資料,我還想觀察: 使用者有沒有完成第一次任務? 任務完成率如何?中途卡在哪一步? 使用者是否回來再次使用? 7 日或 30 日後是否仍有需求? 哪些需求是使用者主動反覆提起的? 平台未必提供所有分析數據,所以能取得什麼訊號、如何合規記錄使用情形,也要列入實驗設計。不要先用自己的喜好判定哪個方向最好,讓可取得的使用資料和實際回饋幫忙篩選。 新的產品入口,也許需要研究「人話」以前做 SEO,我們常研究使用者會搜尋什麼關鍵字。若使用者開始在對話裡直接說需求,我想還要多研究另一件事:他會怎麼把工作說出口? 我暫時把這件事叫作 Intent SEO。這是我對可能出現的產品發現方式的稱呼,不是說它已經有一套公認的排名規則。 以 Privacy Cleaner 為例,工程師可能會說「企業級去識別化服務」,一般使用者更可能說: 幫我把名字遮掉。 這份資料可以匿名化嗎? 我想把電話換成假的,再交給 AI 分析。 Excel 有個資,怎麼處理比較安全? 這些說法可以整理成 Prompt Intent Library,拿來設計工具描述、範例提示與任務流程。技術名詞要不要放在說明裡,可以再測;第一步是先確定使用者真的會用什麼語言描述問題。 Plugin Idea 可能就在自己的工作紀錄裡如果現在要開始找方向,我不一定會先打開排行榜或再腦力激盪十個新創點子。我會先回頭看自己的工作紀錄: 哪件事我問過 AI 好幾次? 哪個 Excel 我每個月都要重整? 哪份 SOP 每次都要重新解釋? 哪個流程我已經做過工具,但還需要別人找到它? 哪些客戶、講師或協會反覆遇到同一種麻煩? 這些紀錄至少說明有真人遇過這個問題,值得進一步訪談和測試。它們不保證市場夠大,卻比只靠想像產品點子更接近真實工作。 我不會 All in,但會趁成本低時下注我現在不是要預測 ChatGPT Plugin 或 App 生態一定會成為下一個 App Store。平台入口能不能帶來穩定流量,現在都還需要實際驗證。 我想做的比較像一次產品實驗:從已經解過的工作問題出發,選五個小任務,跑過需求、最小版本、平台上架、使用回饋和迭代。若有方向被持續使用,再集中資源;如果沒有,至少多學會一套把工作流程變成可用產品的方法。 這一路也可能變成教材:先自己踩一次,再把 Vibe Coding、既有工具產品化、Prompt Intent 設計和市場驗證的過程整理出來。 看完這波 ChatGPT 工具生態的變化,我現在更想問的不是「Plugin 一定會不會紅」,而是:我手上還有多少已經解決過的工作問題,可以換一個入口再測一次? 如果要先選一支,我會從 Privacy Cleaner 開始。不是因為我知道它會成功,而是因為我已經碰過這個問題,也知道可以先從哪個小任務動手。平台是不是新的流量入口,最後還是要讓使用者的行為來回答。 常見問答 (FAQ)Q1:ChatGPT Plugin 和 ChatGPT App 是同一件事嗎?OpenAI 的文件把 Plugin 描述成可組合 Skills 和連接 App 等能力的工作流程;Apps SDK 則提供開發 ChatGPT 內 App 的工具與提交 app directory 的指引。兩者相關,但產品形式和發布方式應依官方當下文件分別確認。 Q2:為什麼要先測五個方向,而不是只做一個完整產品?這篇文章的做法是先比較五個範圍明確的小任務,觀察哪個方向有人完成任務並持續回來使用,再決定是否加大投入。五個點子本身不會保證成功,也不表示要先打造五套大型系統。 Q3:測試 ChatGPT 工具應該看哪些數據?可以先定義首次任務完成率、使用者卡住的位置、再次使用,以及 7 日或 30 日後是否仍有需求。平台未必提供所有指標,應依當時可取得的數據與合法合宜的紀錄方式調整。 Q4:五個方向裡,哪一個適合先做?作者目前想先測 Privacy Cleaner,因為已有相關工具經驗,而且使用者需求容易用一句話說清楚。這是作者的起點選擇,不代表它已經被市場驗證或一定比其他方向更有需求。 Q5:為什麼 LINE 預約系統先不做?LINE 預約牽涉 API、行事曆授權、資料庫、租戶隔離與權限等整合工作。若目標是先驗證新的對話入口是否有人使用,先測單一、明確、較少前置整合的任務會更容易看出需求。

  • article-Public APIs 開始收錄 MCP Server:48 萬 Star 的工具清單怎麼用?

    2026/10/1

    AI工具 AI Agent MCP
    Public APIs 開始收錄 MCP Server:48 萬 Star 的工具清單怎麼用?

    最近整理 Skill Library 時,我發現自己收藏了不少 MCP,真正要做事時卻還是得重新搜尋:「有沒有 Gmail MCP?」「哪個 MCP 能查 YouTube?」接著逐一看 README、確認維護狀況、安裝方式和需要的權限。 這讓我重新注意到 GitHub 上的 public-apis/public-apis 專案。它原本以公開 API 分類清單聞名,現在也加上 MCP Servers 區塊。我查閱時,GitHub 顯示約 48.5 萬顆 Star;電腦王阿達在 2026 年 9 月 5 日的介紹則記錄當時已超過 47 萬顆。Star 數會變動,這裡的數字只是查閱時的快照。 比起多收藏一個目錄,我更想建立一個流程:先說清楚工作需要什麼能力,再讓 Agent 找候選工具、比較限制,最後才決定要不要安裝 MCP。 Public APIs 的 MCP 清單有什麼不同?Public APIs 原本把公開 API 依用途分類,例如 Weather、Finance、Email、Geocoding、Government、Video 等。清單除了名稱與說明,也會列出驗證方式、HTTPS 和 CORS 等資訊,方便開發者先篩選資料來源。 README 現在另有 MCP Servers 表格,欄位包含名稱、用途、驗證方式、Transport 和安裝入口。查閱時可看到 OpenSwissData、IPstack MCP、GitHub、Filesystem 等項目。這些資料讓讀者先比較需要什麼驗證、支援哪種傳輸方式,再前往專案或安裝目錄查看細節。 它的特色不是 MCP 數量最多,而是從「我需要天氣、金融或檔案能力」這類需求出發,再找可能的 API 或 MCP。要做天氣網站,直接呼叫 API 也許就夠;若 Agent 要在多次任務中反覆查詢或執行操作,MCP 才可能比較合適。 另外,清單名稱裡的「免費 API」不代表每個服務都能無限制免費使用。實際費率、免費額度、API Key 和使用條款都要再到服務官方文件確認。 API、MCP 和 Skill 各自負責什麼?這三者不是互相取代的工具,而是處理不同層次的問題: 元件 負責的事情 常見用法 API 服務提供的資料或操作介面 網站或程式依服務文件發送請求、處理回應 MCP Server 依 MCP 協定,把工具或其他上下文能力提供給相容的 Agent 讓 Agent 透過標準介面呼叫搜尋、檔案或服務工具 Skill 說明 Agent 怎麼完成一類工作 把需求拆解、檢查步驟和交付格式整理成可重複使用的 SOP MCP Server 有時會在背後呼叫 API,但 MCP 並不是 API 的另一個名稱;有些 API 也沒有對應 MCP。Skill 則可以教 Agent 如何呼叫已設定的 MCP,也可以規定何時直接用 API。 若你還想釐清 MCP、Skill 與 CLI 的分工,可以接著看一次搞懂 MCP、Skill 與 CLI 的差異。Skill 與 Plugin 的組合方式則整理在從個人工作流到團隊交付。 找 MCP 時可以先看哪幾個地方?我會依照需求和想確認的資訊,從以下入口開始找。它們的定位不同,搜尋結果也不等於品質或安全保證。 1. Official MCP Registry:查官方登錄資料Official MCP Registry 是 MCP 專案提供的公開 Server 目錄,可以搜尋 Server 名稱與版本,並查看其 metadata。它適合用來確認某個項目是否有公開登錄,以及對應的專案或套件資訊。 不過,「出現在 Registry」不等於「經過完整安全審核」。Registry 的資料由 Server 維護者發布,使用者仍要核對來源、版本和權限;官方說明也提到社群可檢舉違規項目,由維護者處理。 2. Public APIs:從需要的能力開始找如果你還不確定該找 API 還是 MCP,可以先按資料類型或用途查 Public APIs。MCP 區塊的清單目前較精簡,優點是會把 MCP 放在原有 API 資源旁邊,讓你比較是直接呼叫 API,還是透過 Agent 使用 MCP。 3. Glama:用搜尋與篩選比較大量候選Glama MCP Servers 提供伺服器索引與搜尋,頁面可按更新日期、GitHub Star、套件下載量等條件排序。網站在 2026 年 10 月 1 日查閱時顯示約 94,668 個 Server。索引數量會改變,應以網站當下顯示為準,也別只看總數或 Star 就決定安裝。 4. Smithery:搜尋並查看伺服器管理入口Smithery 提供類別與條件篩選,並展示部分 Server 的使用資訊。頁面在 2026 年 10 月 1 日查閱時顯示 13,151 個搜尋結果。平台和目錄功能可能持續調整,因此安裝方式、方案和服務狀態要回到當下的官方說明確認。 5. GitHub 與服務官方文件:確認實作細節找到候選項目後,接著查它連結的原始 Repository 和服務官方文件。目錄摘要可以幫你發現項目,卻無法代替版本紀錄、License、安裝需求、OAuth 範圍、API 費用及原始碼審查。 用 MCP Scout 把搜尋變成工作流程與其在看到「必裝 MCP 清單」時一律先收藏,我會希望 Agent 在開始實作前先做需求分析:完成任務需要哪些資料、外部服務和操作權限?是否已經有可用的 MCP?直接呼叫 API 或使用 CLI 會不會更簡單? 這個想法可以整理成一個 MCP Scout Skill。它不負責直接替你安裝工具,而是先找候選、標示來源與限制,再提出方案供你決定: 1234567891011121314151617181920你是我的 MCP Scout。我要完成以下工作:{{工作需求}}先分析需求並搜尋工具,不要直接開始實作、安裝或執行候選項目。第一階段:拆解需求列出完成工作需要的資料、操作與外部服務,例如搜尋、檔案、Database、Email、Calendar、Browser 或 SaaS。第二階段:搜尋候選依序查看 Official MCP Registry、public-apis/public-apis、Glama、Smithery、GitHub 與服務官方文件。最多列出 3 個候選,附上來源連結;清楚標示官方或社群專案,找不到證據時不要猜。第三階段:比較限制逐一整理提供的 Tools、Repository、License、最近更新、Transport、Agent 相容性、API Key 或 OAuth、費用、權限範圍,以及是否會讀寫本機檔案或執行 Shell。每個判斷都附上可查證的來源。第四階段:提出選擇比較使用現有 MCP、直接使用 API/SDK/CLI,或自行建立 MCP 的建置時間、維護成本、安全性、穩定性與可移植性,說明適合的方案與原因。先交付搜尋結果與建議,等待我確認後才進行安裝或授權設定。 這段流程的重點是先把需求和風險攤開來,不要讓搜尋結果直接變成安裝指令。MCP Scout 可以協助找資料,但不能只憑目錄標籤就替候選項目背書。 不需要為每件事都加上 MCP我會用三個問題快速選擇: 只是要取得一份資料或完成一次操作? 先看 API、SDK 或 CLI 是否更直接。 Agent 是否要在不同任務中反覆使用同一項能力? 再評估 MCP 的介面和維護成本。 真正需要保存的是工作步驟嗎? 把判斷方法整理成 Skill;需要工具時,再讓 Skill 指向 API 或 MCP。 例如天氣網站可以直接呼叫天氣 API;如果多個 Agent 都要在對話中查詢天氣、比較時段並安排活動,MCP 可能更容易重複使用。工具是否值得封裝,仍取決於實際使用頻率、權限需求和維護成本。 最後,我想收藏的不是更多 MCP 名稱,而是一條遇到需求時找工具、核對來源、比較限制的路徑。當 Skill 知道何時呼叫 MCP,Agent 又知道缺工具時該去哪裡找,工具庫才會從收藏清單變成真正能使用的工作流程。 常見問答 (FAQ)Q1:Public APIs 的 MCP Servers 清單適合拿來做什麼?它適合從 API 類別或能力需求出發,快速發現少量相關 MCP,並查看簡介、驗證方式、Transport 和安裝入口。找到候選後,仍應到 Repository 和官方文件確認細節。 Q2:要去哪裡搜尋 MCP Server?可以先看 Official MCP Registry 的登錄資料,再用 Public APIs 按需求找候選,或用 Glama、Smithery 搜尋和篩選。最後回到 GitHub Repository 及服務官方文件確認版本、授權、費用與權限。 Q3:怎麼判斷 MCP Server 是否適合安裝?至少要確認維護者與 Repository、License、最近更新、安裝程序、Transport、憑證和費用,以及它要求的檔案、網路或 Shell 權限。目錄列出項目不等於安全認證;對高權限工具,應先檢查程式碼並在受限環境評估。 Q4:MCP、API 和 Skill 要怎麼選?一次性或單純的資料請求可先用 API、SDK 或 CLI;需要讓 Agent 以一致介面反覆呼叫的能力,可評估 MCP;需要重複遵循的工作方法則適合整理成 Skill。三者也能搭配使用。 Q5:MCP Scout 可以自動安裝它找到的 MCP 嗎?MCP Scout 可以整理需求、搜尋候選和比較限制,但搜尋結果不能代替程式碼審查或權限判斷。建議先讓它提交來源和評估結果,經人確認後再安裝、提供憑證或授予本機權限。 參考資料 電腦王阿達|Public APIs 免費 API 資源庫介紹 GitHub|public-apis/public-apis MCP 官方專案|Introducing the MCP Registry Official MCP Registry Glama MCP Servers Smithery

  • article-Claude 程式碼動畫怎麼做?從 Prompt 拆出 Motion Design Skill

    2026/10/1

    AI Agent 影音行銷 Claude
    Claude 程式碼動畫怎麼做?從 Prompt 拆出 Motion Design Skill

    最近看到一個很有意思的 GitHub 專案:awesome-opus5-5-videos。 截至 2026 年 9 月 29 日,專案 README 列出 475 個 Prompt 檔,並從中精選 100 個案例展示。它的特別之處,是把動畫成品和創作者分享的 Prompt 放在一起,讓人有機會研究這些作品是怎麼被描述、再被做出來的。 先補上一個容易誤會的地方:這不是 475 份都完整公開的 Prompt。專案也註明,有些創作者只分享了部分 Prompt,或只留下原始貼文連結。至於 Claude 產生的實作程式碼,也不一定附在每個案例裡;如果創作者沒有另外公開,你可以重跑 Prompt,再觀察自己得到的 HTML、Canvas、SVG 或 Three.js 程式碼。 我最近也一直在研究 Claude 用「寫程式」做動畫。看得越多,我越覺得這個集合真正值得看的,不是能不能一次複製大量 Prompt,而是我們可以從成品回頭研究:一句動畫需求,如何變成有時間、有物件、有動作的可執行規格? 這些案例走的是程式碼動畫路線這批作品不是把一句描述直接交給影片模型,再由模型輸出一段影片。依專案的說明,創作者會請 Claude Opus 5.5 把動畫寫成程式;常見做法包括 HTML、Canvas、SVG 和 Three.js。瀏覽器負責執行動畫,若需要影片檔,再把播放畫面錄製或輸出成影片。 可以先用這個流程理解: Prompt → Claude 寫動畫程式 → 瀏覽器執行 → 需要時錄成影片 因此,Claude 在這個流程中同時接到導演、動畫師和前端工程師的工作:它要理解畫面、安排動作,也要把想法轉成瀏覽器能執行的程式。 一支動畫可以拆成畫面、動作與聲音從案例可以看出,程式碼動畫大致有三個互相配合的部分: 部分 常見技術 主要負責的內容 畫面怎麼畫 Canvas、SVG、Three.js、GLSL 文字、圖形、粒子、3D 場景、材質與光影 畫面怎麼動 CSS Animation、GSAP、JavaScript timeline 元素何時出現、移動路徑、縮放、速度與緩動 聲音與節奏 Web Audio API 或音訊素材 音效、節拍與畫面轉場的搭配;也可以完全不加聲音 有些作品把樣式、動畫與程式包進單一 HTML,打開瀏覽器就能預覽;要分享成影片時,再另外錄製播放結果。重點不是一定要採用哪個框架,而是讓畫面、動作和節奏彼此對得上。 好的動畫 Prompt 更像一份 Motion Design 規格寫程式做動畫時,cinematic、dramatic lighting 或 epic 這類形容詞仍能傳達美術方向,但通常不足以告訴模型一支動畫要怎麼走。更有用的資訊是時間、物件、動作和輸出方式。 先安排時間,再描述每段畫面例如,想做一支 10 秒的科普動畫,可以先列出節奏: 時間 畫面與動作 0–2 秒 主視覺淡入,主題物件由小放大 2–4 秒 標題從側邊滑入,停在畫面安全區 4–7 秒 圖表逐步成長,重點數字依序出現 7–10 秒 鏡頭拉遠,收束成結尾畫面 這比只說「做一支很有電影感的動畫」更能讓模型掌握段落長度、先後順序和畫面轉換。 說清楚畫面有哪些物件把文字、圖表、角色、圓形或背景元素列出來,並說明它們的位置、大小關係和視覺層級。若標題要優先被讀到,可以直接交代標題與圖表不要互相遮擋,重要內容要留在畫面中央的安全範圍。 描述物件如何移動除了「要出現什麼」,還要指定誰先動、往哪裡移動、移動多久、是否放大或淡出,以及動作要急促還是平滑。這些都是動畫規格的一部分,能幫助模型把靜態構想轉成有節奏的畫面。 補上風格與輸出條件最後再補色彩、字體感受、比例、背景、是否需要聲音,以及希望怎麼預覽。若想快速在瀏覽器查看,可以要求輸出單一 HTML 檔;如果結果要再剪輯,也要先想好影片比例和結尾如何銜接。 為什麼不該只複製 Prompt?只收集提示詞,很容易變成「看過很多範例,卻不知道怎麼自己改」。更有效的讀法是把成品、原始 Prompt 和自己重跑後的程式碼對照起來: 先看成品: 留意它為什麼順、哪裡吸引你,以及畫面如何轉場。 再看 Prompt: 找出創作者如何描述時間、構圖、物件與動作。專案也提醒,有些檔案只提供節錄或原始貼文。 自己重跑一次: 觀察模型選了什麼技術、如何切分動畫,以及結果和原始成品有哪些差異。 一次只改一個條件: 例如配色、文字、速度或畫面比例,才看得出修改造成的差異。 整理有效規則: 記下哪些描述能穩定改善節奏、版面或可讀性。 先挑和自己用途相近的案例就好。README 目前精選的分類包括 Motion Graphics、Explainers、3D Scenes,以及 Games & Interactive。若目標是做 AI 科普短片,可以先從 Explainers、Typography 和 Data Visualization 類型找靈感,不需要依序研究所有案例。 把反覆驗證過的方法整理成 Animation Skill當你研究過一批相似作品,就可以把有效的方法整理成自己的 Skill。它不只是保存一段長 Prompt,而是說明 Agent 每次接到任務時要如何完成工作,例如: 輸入與目標: 影片主題、觀眾、時長、比例和發布平台。 畫面規格: 場景、物件、文字層級、構圖與色彩方向。 時間軸: 每段的開始與結束時間、動作順序、轉場和節奏。 實作與輸出: 選擇 Canvas、SVG、CSS 或 Three.js 等合適方式,交付可預覽的檔案。 驗收方式: 檢查文字、時間軸、畫面比例、播放效果與需要修正的地方。 等這些規則經過幾次實際製作與修正,你就可以把文章、課程或數據內容交給 Agent,再要求它依照自己的 Explainer Animation Skill 開始規劃。模型和工具可能改變,但你整理出的判斷方法、範本與驗收步驟仍然可以繼續累積。若你也在整理 Skill 與 Agent 工作方式,可以延伸閱讀從 Skill 到 Agent Harness和Codex Skill 與 Plugin 的差異。 新手可以怎麼開始? 從專案中挑三個和自己目標相近的案例。 先完整看完成品,再讀它附的 Prompt 或原始貼文。 用相同 Prompt 跑一次,觀察模型實際產生的程式和動畫。 每次只改一個變數,記錄畫面和節奏怎麼變。 把反覆有效的規則整理起來,再逐步形成自己的 Skill。 最後要建立的,不是「我收藏了多少 Prompt」,而是自己能否把作品拆成規格,再把有效做法整理成可重複使用的 Library、Skill 和 Workflow。這才是這批程式碼動畫案例最值得研究的地方。 專案連結:awesome-opus5-5-videos。專案 README 指出,影片與 Prompt 歸原創作者所有,並在各案例連回原始來源;公開可看不等於可以任意重用素材。 常見問答 (FAQ)Q1:這些案例是 Claude 直接生成影片檔嗎?不是。專案介紹的是 Claude 先把動畫需求寫成程式,再由瀏覽器執行;若需要影片檔,還要錄製或輸出播放結果。 Q2:專案裡的 475 個 Prompt 都能看到完整內容嗎?不一定。截至 2026 年 9 月 29 日,README 列出 475 個 Prompt 檔,但也說明部分創作者只分享節錄或原始貼文。每個案例可取得的資訊要以該項目的連結為準。 Q3:研究案例時,為什麼還要自己重跑 Prompt?專案提供案例和創作者分享的提示詞,但不保證每筆都附上生成後的完整程式碼。自己重跑後,才能檢視實際實作方式,並比較它與原始成品的差異。 Q4:Prompt 和 Animation Skill 有什麼不同?Prompt 通常描述一次任務的需求;Animation Skill 則把可重複的方法整理成流程,包含輸入、規格、實作方式和驗收步驟,讓 Agent 能依同一套方法處理不同內容。