跳到主要內容

部落格

不定期分享最新資訊文章

  • article-Open Pose & Costume 教學:用免費姿勢與服裝圖庫做 AI 換裝與角色設計

    2026/11/6

    ChatGPT 影音行銷 AI繪圖
    Open Pose & Costume 教學:用免費姿勢與服裝圖庫做 AI 換裝與角色設計

    幫 AI 網紅換一套韓系穿搭,結果衣服換好了,臉也跟著變了。下一次想讓同一個人坐在咖啡廳喝咖啡,又得重寫一遍髮型、衣服和手腳的位置。遇到這種情況,可以把要保留的人物、要更換的服裝和要模仿的動作分開,各用一張圖交代。 這個免費圖庫整理了人物、姿勢與服裝素材。你可以用自己的角色當母圖,從圖庫選服裝或姿勢,再交給支援多張參考圖的生圖工具。這篇從兩張圖換裝開始,再加上第三張姿勢圖,最後延伸到動漫角色和短影音。 Open Pose & Costume 有哪些參考圖? 類型 可以拿來做什麼 姿勢參考(Pose) 選站姿、坐姿或行走動作,規劃人物構圖與分鏡 服裝參考(Costume) 挑上衣、裙裝、鞋子和配件,規劃寫實或動漫角色的穿搭 人物參考(Character) 探索臉型、髮型和整體造型,作為設計新角色的靈感 專案 README 在 2026 年 11 月 2 日記載,含擴充分類共有 5,855 張參考圖。其中有 312 組姿勢、共 1,559 個視角,另有 2,769 套服裝與 1,527 張人物圖。總數按姿勢視角計算,不含配套深度圖和預覽副本。介面上的筆數也會受分類、篩選和更新影響。專案統計與計算方式 怎麼用人物母圖和服裝圖替 AI 網紅換裝?1. 到圖庫挑一套看得清楚的服裝進入圖庫後,可從側欄切換全部、姿勢、服裝與人物參考,也可以用關鍵字找圖,把候選加到「我的收藏」。第一次換裝可以從一套輪廓清楚的穿搭開始,例如短版外套、百褶裙和樂福鞋。平拍服裝圖適合辨認剪裁和配件,模特兒穿搭圖則能看出衣服上身後的比例。Open Pose & Costume 圖庫 如果想用網站內建的「一鍵生圖」,依專案文件須先設定生圖服務,並選擇姿勢與服裝,人物參考可另外加入。瀏覽圖庫是免費的,生成費用取決於所設定的服務。本篇的兩圖換裝範例則使用 ChatGPT 或其他接受多張參考圖的生圖工具。專案生圖說明 2. 準備一張固定的人物母圖用一張已定稿的全身照固定臉型、五官、膚色、髮型和身材比例。建議選正面站立、光線均勻、臉部和身體沒有遮擋的版本。每次換裝都回到同一張母圖,可以減少上一輪生成的外貌偏差一路傳下去。 3. 上傳兩張圖,清楚指定各自的用途圖片 A 是人物母圖,圖片 B 是服裝參考。上傳後可以用下面的提示詞。畫面比例寫進提示詞後,若工具另外提供尺寸設定,再選最接近的版型。 12345678910請根據我上傳的兩張參考圖片,製作一張寫實風格的全身人物照。圖片 A 是人物身分參考。請保留 A 的五官、臉型、膚色、髮型和身材比例,維持原本的年齡與人物特徵。圖片 B 只用來參考服裝與配件。請將 B 的穿搭套用到 A 的人物身上,盡量還原款式、顏色、材質、剪裁和配件。服裝要自然貼合身體,呈現合理的布料皺褶與光影。採用時尚攝影風格,人物自然站立,全身入鏡。使用乾淨背景和柔和光線,畫面比例 2:3,維持自然人體比例,盡可能輸出高解析度。 成圖後先比對臉型、髮際線和五官,再檢查衣長、配件和鞋子。若衣服對了、臉卻走樣,可以換一張臉部更清楚的母圖,或先簡化背景和動作,找出最容易影響一致性的條件。 加入第三張圖,指定人物姿勢當同一位 AI 網紅要在街頭走路、坐著喝咖啡、拿手機自拍,或回頭看鏡頭時,姿勢圖可以交代文字難以描述的重心、手腳位置和身體朝向。第一次嘗試可以挑四肢輪廓清楚、視角接近預期構圖的圖。 上傳順序 圖片 用途 A 人物母圖 固定臉孔、髮型與身材比例 B 服裝參考 決定款式、配色與配件 C 姿勢參考 指定身體朝向、動作與手腳位置 12345678請根據三張參考圖片,生成一張寫實風格的全身人物照。A 是人物身分參考。保留 A 的五官、臉型、髮型、膚色和身材比例。B 是服裝參考。盡量還原 B 的顏色、材質、款式和配件。C 是姿勢參考。依照 C 的身體朝向、重心、手部位置和腿部角度安排動作。優先順序為人物身分、服裝設計、姿勢。姿勢可依人體結構自然調整。請檢查手指、關節和肢體遮擋,使用 9:16 直式構圖,讓人物全身入鏡。 參考圖能提供構圖依據。需要精準控制手肘、膝蓋或身體朝向時,可以改用支援 OpenPose 骨架等姿勢條件的工作流,再逐一比對關節位置。圖庫中的一般參考圖或深度圖,在一般生圖服務裡仍以圖片參考處理。若要使用專門的深度控制,須由工作流提供對應的條件輸入。專案的深度圖說明 用同一張動漫角色設定圖做不同服裝版本做動漫 IP 時,可以把同一張角色設定圖分別搭配日常服、校園制服、戰鬥服、古風服或節慶造型。每次先固定角色的髮型、輪廓和畫風,讓服裝成為主要變因。選定造型後,可先生成三視圖草稿,再統一配色、配件位置和衣服結構。 12345678請以圖片 A 的動漫角色作為唯一人物身分參考,保留五官、臉型、髮型、髮色、身材比例與原本的美術風格。請參考圖片 B 的服裝設計,將主要配色、剪裁、裝飾和配件轉成符合 A 的畫風與身材比例的造型。請製作角色的正面、側面和背面三視圖。三個視角使用相同的服裝設定、配色和人物比例,並以純色背景完整呈現角色,供後續角色設定與動畫製作。 原參考圖若只有正面,背部接縫、扣件和圖案通常要由模型推測。正式定裝前,建議把三個視角並排,確認領口、袖長、配件和鞋子都能對上。有明確設計要求時,可以補上背面參考或文字規格。 把定裝圖變成 15 秒 AI 網紅短影音以街頭 Vlog 為例,可以先用同一張人物母圖挑一套韓系穿搭,選一張站姿或行走參考,再加入街景生成一張直式關鍵畫面。確認臉、穿搭和動作後,把定稿畫面交給 Google Flow 或其他支援圖生影片的工具,生成街頭開場、行走或回頭等短鏡頭,最後再安排字幕、配音和剪輯。 製作順序可以記成 人物母圖 → 服裝 → 姿勢 → 場景 → 關鍵畫面 → 圖生影片 → 剪輯。如果下一支改拍咖啡廳或捷運站,可以沿用同一套人物和穿搭,再根據場景換動作與鏡頭。先把靜態定裝確認好,回頭調整影片時也有一張圖可以比對。 Codex 可以幫忙挑圖和整理提示詞嗎?專案文件提供一個獨立的 Open Pose Costume Skill,作者說明它可將選定的姿勢、服裝與人物參考組合後,交給已設定的生圖服務。本文以文件為依據,實際安裝、選圖、API 呼叫和批次生成尚未測試。配套 Skill 專案 如果想請 Codex 規劃五套秋冬穿搭,可以先讓它整理主題、列出候選搭配、為每套寫好 A/B/C 的參考圖用途和生成提示詞。接著由人挑圖、核對素材條款,再用一套穿搭試跑。要把選圖、呼叫生圖服務、檢查結果和歸檔接成自動流程,還要確認 Skill 的能力、工具相容性、圖片存取權限與各來源對自動下載的規定。 免費圖庫可以拿來做商業作品嗎?先看你選的是哪一類素材。專案程式碼使用 MIT 授權,圖片另外依原站或專案自建素材條款處理。專案授權與素材來源 素材來源 專案文件記載的使用範圍 上游姿勢、服裝圖 原站允許作品創作時使用,包括商業作品,但限制圖片本身的再散布、轉載和轉售。部分圖庫另禁止批次下載。 上游人物圖 原站標示 CC0 1.0,同時列有真人冒用等使用限制,並請求避免再散布原圖。使用時查閱原站完整條款。 專案自建擴充 可供個人學習及非商業使用。商用或再散布,包括文件所列的衍生圖情形,應先取得維護者的書面授權。 用在客戶廣告、付費教材或公開下載包之前,建議先記錄素材編號、來源與核對日期。將圖片當作創作參考、把原圖附在教材裡,或把多張圖打包供下載,分別要依各自的使用方式確認。 享哥的建議:先把一個角色的三套穿搭做穩如果你想長期經營 AI 網紅或動漫 IP,我會先用一張人物母圖,手動做三套造型。把每套的服裝來源、提示詞和定稿圖存好,挑出最能保留同一張臉的做法,再加入不同姿勢和場景。做過幾次就會知道,哪些欄位適合做成模板,哪些細節仍要靠人挑圖和確認。 角色素材庫可以從一個小資料夾開始,依人物母圖、服裝、姿勢、場景和提示詞分類。這樣下一次想讓同一個角色出現在新的故事裡,就有可以直接沿用的設定。 參考資源 Open Pose & Costume 官方圖庫 Open Pose & Costume GitHub 與操作文件 素材來源與使用條款 Open Pose Costume Skill 常見問答 (FAQ)Q1:Open Pose & Costume 可以免費使用嗎?圖庫可免費瀏覽與挑選。網站內建的生圖功能須設定相容的生圖服務,生成是否收費取決於該服務。素材用於商業作品或再散布時,須另外查看各來源的使用條款。 Q2:用同一張人物母圖,可以讓 AI 換裝後完全不變臉嗎?同一張人物母圖能提供一致的外貌依據,結果仍受模型、視角和提示詞影響。建議指定母圖負責身分、服裝圖負責穿搭,成圖後比對五官、髮型與身材比例,再決定是否採用。 Q3:姿勢參考圖和 OpenPose 骨架控制有什麼差別?姿勢參考圖提供動作和構圖的視覺線索,模型仍會自行解讀。OpenPose 骨架控制需要支援骨架條件的工作流,可用身體關節位置引導生成,適合動作或分鏡要求較精準的情況。

  • article-1,407 套免費 AI 服裝參考圖:用 AI Costume Gallery 搭配 ChatGPT 替虛擬人物換裝

    2026/11/5

    AI工具 ChatGPT 影音行銷
    1,407 套免費 AI 服裝參考圖:用 AI Costume Gallery 搭配 ChatGPT 替虛擬人物換裝

    AI 生圖的人物,為什麼總是穿那幾套衣服?如果你也遇過穿搭靈感不足的問題,可以認識這個免費資源:AI Costume Gallery。 原始資源分享資訊提到,這個網站整理了 1,407 套 AI 服裝參考圖,涵蓋春夏秋冬、派對等不同穿搭風格。本文查核時,官網可讀文字未列出總數,因此 1,407 套保留為分享資訊,實際數量以網站當下顯示為準。 最方便的地方是,你不必懂服裝設計,也不用從零描述領口、剪裁、材質與配色。選好服裝參考圖,再搭配自己設計的成人虛擬人物母圖,就能請支援圖片編輯的 ChatGPT 協助換裝。 先提醒:這套圖庫明確禁止用於表現真人或未成年人。 因此,本文教學一律以成人虛擬人物為例;完整限制整理在後面的使用規範段落。 對正在製作 AI 網紅、AI 短影音、虛擬角色或虛擬品牌形象照的人來說,這是一個值得收藏的創作資源。不過,「一鍵換裝」不代表每次都能完整還原,仍要檢查人物身份與衣服細節。 AI Costume Gallery 是什麼?有哪些服裝分類?網站連結:AI Costume Gallery(衣装集 COSTUME-DB-01)。 依官網說明,參考圖是 2:3 直式、沒有實際人物的服裝圖,以文字生成圖片的方式製作,並非實際商品照片。分類包括以下八種: 服裝分類 可發想的成人虛擬角色情境 春季 日常穿搭、踏青、咖啡廳 夏季 旅遊、街拍、戶外生活 秋季 文青風格、城市街拍 冬季 大衣、毛衣、冬季旅行 派對 晚宴、活動、時尚攝影 內衣 符合圖庫與生成工具規範的成人虛擬服飾展示 泳裝 海灘、度假、成人虛擬泳裝展示 性感 符合圖庫與生成工具規範的成人虛擬時尚造型 這類圖片的重點是呈現服裝本身。我的理解是:它可以減少另一張人物照片中的臉孔與姿勢干擾,讓你更清楚地指定「這張圖只用來參考衣服」。但這不保證 AI 一定能把人物身份與服裝完全分開處理。 官網也提供 ID 與服裝關鍵字搜尋,例如 denim、lace、白。如果中文詞找不到結果,可以試著改用網站示範的字詞。 比起只說「幫我換一套時尚的衣服」,我更建議提供具體參考圖,再說明需要保留與替換的部分。 如何用 ChatGPT 完成 AI 換裝?三個步驟開始不必另外安裝修圖軟體,但使用的 ChatGPT 帳號與當前功能必須支援圖片上傳及圖片生成或編輯;可用額度與功能依方案及服務當下狀態為準。 OpenAI 的圖片功能說明也介紹了上傳既有圖片後,透過文字描述修改需求的方式。 STEP 1:挑選喜歡的服裝參考圖打開 AI Costume Gallery,從八大分類中挑選適合的穿搭。 例如今天要製作 AI 網紅的秋季咖啡廳形象照,可以先找大地色系、針織衫或長裙。選好後,使用網站提供的原尺寸 PNG 下載功能,一次取得所需的單張圖片,不要整批抓取圖庫。 STEP 2:準備已確定身份的成人虛擬人物母圖接著準備一張自己有權使用、且不代表真人或未成年人的成人虛擬角色圖片。建議具備以下條件: 正面或四分之三側面,臉部清晰可辨。 半身或全身構圖,能看見需要替換的服裝區域。 光線自然,身體沒有被大量遮擋。 角色身份已確定,可作為後續系列作品的共同基準。 如果是 AI 網紅,最好沿用已選定的「角色母圖」,避免每次重新生成都換了一張臉。即使你有權使用某位真人照片,也不代表這套圖庫允許你拿它替真人換裝。 STEP 3:上傳兩張圖,明確指定各自用途開啟 ChatGPT,先上傳人物母圖,再上傳服裝參考圖,確認兩張圖的順序與用途後,貼上以下提示詞。如果介面中的排序不明確,就用檔名補充指認。 AI 換裝提示詞: 1234567891011請以第一張圖片作為成人虛擬人物的身份參考,以第二張圖片作為服裝設計參考。保持第一張圖片人物的五官、臉型、髮型、膚色、身材比例與辨識特徵,不要改變人物身份。將人物原本的服裝替換成第二張圖片的完整穿搭,盡可能還原服裝的款式、顏色、材質、剪裁、層次與配件。請依照人物姿勢與身形自然調整衣服的穿著效果,保留合理的布料皺褶、光影與遮擋關係。採用寫實時尚攝影風格,保持自然光線與真實布料質感。除服裝與必要的配件外,不要任意改變人物的臉部、背景或其他元素。 生成後,先比較臉型、五官與髮型,再檢查領口、袖口、下襬、圖案、配件及手部遮擋。複雜刺繡、細小圖案、特殊剪裁或多層配件,仍可能需要局部修改或重新生成。 這是一份可嘗試的操作範本,本文沒有提供這組提示詞的實際換裝對照圖;封面為原創概念示意,並非圖庫或 ChatGPT 的實測成果。 如何讓同一個 AI 網紅換造型,仍維持角色一致?如果只是偶爾換裝,前面的提示詞可以作為起點。但如果你和我一樣,正在經營 AI 網紅,就需要考慮系列內容的一致性。 我們希望同一個角色可以拍攝: 今天在咖啡廳喝咖啡的生活 Vlog。 明天到海邊度假的旅遊短片。 後天參加品牌活動的時尚影片。 下週穿冬季服裝到日本旅行。 觀眾需要一眼認出這是同一個人。所以我的建議是:先鎖定人物身份,再決定服裝,最後才決定場景與動作。 例如我的 AI 網紅「許米樂」,就可以把製作流程拆成: 角色身份母圖 → 服裝參考圖 → 換裝定裝照 → 場景首幀 → AI 影片生成 每一階段先檢查,再進入下一步,可以避免把換臉或服裝錯誤一起帶進影片。 AI 網紅專用提示詞123456789101112131415你是一位專業 AI 虛擬人物造型師與時尚攝影師。請以第一張圖片作為唯一成人虛擬人物身份基準,第二張圖片作為服裝設計參考。這是同一位虛擬人物的系列形象照,請優先維持人物身份一致性。保留人物的臉部骨架、五官比例、膚色、髮型與整體身材比例。將服裝更換成參考圖中的完整穿搭,呈現真實的布料材質、剪裁與穿著效果。場景設定為:秋日下午的質感咖啡廳。人物自然站立,姿勢放鬆,呈現生活 Vlog 的真實攝影感。使用自然柔和光線、真實皮膚紋理與合理的衣物陰影。請輸出 9:16 直式全身構圖,適合後續製作短影音。不要改變人物身份,不要額外增加服裝圖中沒有的主要配件。 這份進階提示詞會同時改變場景,適合在換裝定裝照確認後使用。若一次修改太多導致人物漂移,就先完成單純換裝,再把通過檢查的定裝照作為場景生成參考。 通過審閱的圖片,可以再交給支援圖片轉影片的工具,例如 Google Flow、Seedance 等,依各工具當時的功能、格式與使用規範製作動態短片。 想進一步規劃角色經營,可延伸閱讀:從 HAC 談 AI 網紅與虛擬 IP:如何打造能長期經營的角色?。 如何把服裝、動作與場景分開控制?除了服裝,AI 人物還有另一個常見問題:動作太單調。例如每次都是站著、看鏡頭、雙手自然垂放。 如果搭配自己有權使用、且符合相關規範的姿勢參考,就能更明確地指定角色怎麼站、怎麼坐。完整流程可以拆成六個部分: 人物母圖:決定這個人是誰。 服裝參考圖:決定這個人穿什麼。 動作參考圖:決定這個人採取什麼姿勢。 場景描述:決定人物出現在哪裡。 AI 圖片生成:整合參考條件,檢查身份、服裝及肢體。 AI 影片生成:再指定動作方向、速度與鏡頭運動。 靜態姿勢圖只能提供姿態線索,不能保證影片會照著完成整段動作。若需要明確的動作順序,仍要補上分鏡或動作描述。 我會把這種做法當成一套方便比較與修正的工作流:當結果不對時,較容易找出是人物身份、服裝、姿勢還是場景出了問題。 使用前要確認哪些授權與使用限制?免費不代表所有用途都沒有限制。以下依 AI Costume Gallery 官網「注意點」整理,查核日期為 2026 年 11 月 5 日;使用前仍請重新閱讀網站最新說明。 可免費用於作品製作,包括商業製作、編輯與參考使用;不強制署名。 禁止轉載、散布或販售圖片資料本身,包含原尺寸及加工後版本。 禁止整批下載,包含透過工具自動取得;可為生成參考逐張使用。 禁止用於表現真人、未成年人或違反公序良俗的用途。 網站不保證不涉及第三方權利,使用者仍須自行確認。 因此,本文以符合網站規範的成人虛擬人物為主要應用對象。即使生成工具技術上能替真人換裝,也不能推定圖庫同意這種用途。 商業製作可用,也不等於任何生成結果都已取得完整權利保證。若畫面出現疑似品牌標誌、特殊圖案或他人設計,正式使用前仍需確認;圖庫許可與生成工具的規範也要分別遵守。 享哥的延伸應用:讓 AI Agent 協助規劃穿搭對我來說,這個資源最有價值的地方,是讓 AI 角色製作多了一組可以明確控制的造型素材。 過去我們常直接說:「幫這個女生穿一套時尚的衣服。」結果生成來生成去,就是那幾種常見穿搭。現在可以先挑好服裝,再依照服裝安排角色造型與拍攝情境。 未來,我想把這套流程整合進 AI Agent。例如只要交辦: 幫米樂規劃五套秋季穿搭,分別適合咖啡廳、逛街、約會、旅遊與品牌活動。 Agent 可以先整理穿搭需求與選圖條件,由我到網站逐張挑選、提供允許使用的參考圖,再協助產生提示詞、整理定裝照與檢查項目。圖片生成仍需接上具備相應能力的工具,這裡描述的是延伸構想,並非已建置完成的自動化服務。 這套流程不需要 Agent 自動爬取整個圖庫。 使用者選圖後,Agent 就能協助後續的造型規劃與素材整理。 接著將通過審閱的定裝照交給影片生成工具,便能繼續製作不同主題的生活短影音。 把參考圖整理成可以重複使用的創作流程以前使用 AI 生圖,我們常想著如何把提示詞寫得更長、更詳細。但我越來越覺得,重要的是能不能建立一套穩定、可重複使用的創作流程。 人物身份用母圖控制,服裝用參考圖指定,動作用姿勢圖說明,場景用分鏡與首幀安排,最後再讓 AI 整合,並逐步審閱結果。 如此一來,我們就有機會更有系統地掌握角色、造型、畫面與故事。相關思路也可以參考:從 Prompt 到專家 Skill 的 AI 製片工作流。 如果你也正在研究 AI 網紅、AI 短影音或虛擬角色製作,可以收藏 AI Costume Gallery,從一套服裝、一張母圖開始練習。 感謝願意整理與分享資源的開發者,讓 AI 創作者多了更多靈感與可能性。 常見問答 (FAQ)Q1:AI Costume Gallery 免費嗎?可以用在商業作品嗎?依本文查核時的官網說明,可免費用於作品製作,包括商業製作、編輯與參考使用,不強制署名。但不能轉載、散布或販售參考圖片本身,也不能整批下載;商用前仍要確認最新規範及生成結果是否涉及第三方權利。 Q2:可以用這套圖庫替自己的真人照片換裝嗎?不可以依本文流程這樣使用這套圖庫。官網明確禁止用於表現真人或未成年人,即使照片是本人、或已取得人物同意,也不能據此推定圖庫允許使用。本文教學以符合規範的成人虛擬人物為對象。 Q3:ChatGPT 換裝後臉變了,或衣服細節不對,怎麼辦?先確認兩張參考圖的用途已分別標明,並用清晰的角色母圖重新指定身份。把換裝、換場景與改動作拆成不同階段,逐步比較五官、髮型、領口、袖口、圖案及配件;複雜服裝可嘗試局部修改,但提示詞無法保證百分之百還原。

  • article-【六首歌如何寫成一季故事?用 ChatGPT、Suno 規劃 AI 音樂 MV】

    2026/10/18

    AI工具 ChatGPT 影音行銷
    【六首歌如何寫成一季故事?用 ChatGPT、Suno 規劃 AI 音樂 MV】

    最近看到有人分享一個 GitHub 開源專案,搭配「金曲獎作詞家秘訣也開源了」這類說法,讓人忍不住想點進去看看。 先說明:目前不能只憑這份文件確認作者具有金曲獎作詞家身分,也不適合把它說成官方作詞秘訣。真正值得看的,是如何先規劃一整季的歌曲與 MV,再一集一集製作。 這個專案叫 autoip-mv-maker。它的 README 介紹的是一套 AI 音樂 MV 製作流程;本文聚焦在其中獨立的系列企劃文件,並把觀念改寫成新手可以用 ChatGPT 和 Suno 練習的步驟。這些提示詞是入門練習,不代表必須先安裝該專案。 以前用 AI 寫歌,常常是想到一個主題,就請它「寫一首關於失戀的歌」,再把歌詞交給音樂生成工具。第一首完成後,下一首又從零開始想,歌與歌之間未必有關聯。 另一種做法是先規劃整個系列:六首歌可以各自成立,也能依序講完一段故事。第一首相遇、第二首曖昧、第三首告白,直到最後一首重逢。當故事主軸、角色、音樂特色和畫面方向先有共識,後續寫歌詞、生成歌曲與安排 MV 都比較容易接起來。 先認識這個 GitHub 專案與系列企劃文件GitHub 專案本身涵蓋歌曲分析、分鏡、影像生成、剪輯、字幕與上架素材等 MV 製作流程;SERIES_PLANNING.md 則是規劃一季內容的文件。兩者的用途不同:你可以先讀系列規劃文件、用 ChatGPT 和 Suno 做創作練習;如果之後要執行專案中的完整自動化流程,再依 README 準備需要的環境。 初學時先搞懂這幾個詞就夠了: 名詞 白話解釋 GitHub 放置程式碼與開源文件的平台 Prompt 你交代 AI 工作的指令 Hook 歌曲中容易被記住、可能反覆出現的一句歌詞或旋律 Suno 可依文字描述生成歌曲的 AI 音樂工具 系列企劃 開始做第一首歌前,先定義整季的故事與共同特色 第一步:替整季歌曲定主軸系列企劃文件建議先用一句話說明整季,再找一條能把各集排出順序的主軸,接著挑出幾個跨集固定的風格錨點,並為每集寫企劃卡。季數、題材與故事結局都可以自行決定;文件中的 4 到 8 集只是系列規劃的例子。 例如: 都市愛情流行 × 六首歌,每首歌推進兩個人之間的距離,從相遇走到重逢。 這句話同時交代題材、形式、集數和故事變化方向。接著可以把六首歌排成一條故事線: 集數 歌曲概念 故事位置 可發展的 MV 畫面 EP01 那天的雨 雨天第一次相遇 捷運出口、雨傘、街燈 EP02 多走一站 兩人開始曖昧 一起搭車、錯過下車提醒 EP03 我想告訴你 終於鼓起勇氣告白 夜晚散步、停在路口的對話 EP04 沒說出口 誤會讓兩人分開 沒有送出的訊息、空下來的座位 EP05 你的城市 分開後各自生活 兩個城市、相似的雨景 EP06 還好是你 多年後再次相遇 熟悉的街角、再次撐起的雨傘 每首歌都可以自己聽,但角色與事件會逐步往前走。除了愛情故事,也可以用季節、一天的時間、人物選擇、距離變化或逐步揭曉的線索當主軸。 用幾個穩定錨點保留系列感系列企劃文件把固定項目稱為「錨點」。你可以挑 3 到 5 個跨集保留,例如:同一組主角、固定的歌曲段落結構、某個反覆出現的物件、相似的 MV 畫面語言,或固定的縮圖與標題格式。其他項目仍可依每首歌的故事調整。 這樣做是為了讓觀眾感覺「這些作品屬於同一個系列」,不代表每首歌都要使用一模一樣的曲風、場景或旋律。 四種可以自行採用的歌曲敘事練習以下是把系列故事轉成歌曲的創作方式,供新手練習;它們不是原專案規定的固定結構。 練習方式 怎麼使用 簡單例子 問答式 讓前後兩首歌互相回應 男生唱「如果那天我沒有轉身,你會不會等我?」;下一首由女生回答「我其實一直都在等。」 變形 Hook 保留熟悉句型,依劇情改變結尾 「如果時間能夠重來」,從「我還是會遇見你」變成「我依然會選擇你」 章回式 每首歌代表故事的一個階段 相遇、靠近、衝突、分開、重新選擇 首尾呼應 讓最後一首回到第一首的場景或意象 開場在雨中相遇,結尾多年後又在雨中相逢 新手可以先試「章回式+變形 Hook」:前者幫你排故事順序,後者讓觀眾在不同歌曲裡聽到熟悉的線索。實際創作時仍要讓旋律、節奏和編曲有變化,避免每首歌聽起來只是同一首歌的改寫。 第二步:先請 ChatGPT 規劃歌曲清單先不要一次寫完六首歌詞。打開 ChatGPT,請它先做系列企劃卡,讓你確認故事方向、歌曲情緒與畫面是否合理。 提示詞:規劃一季歌曲12345678910111213141516你是一位華語流行音樂企劃人、作詞人與音樂製作人。我是沒有作詞經驗的新手,想製作一個六首歌的音樂系列。系列主題:從相遇到重逢的都市愛情故事。請幫我規劃六首歌,每首歌列出:1. 歌曲名稱2. 主要故事與它在整季中的位置3. 情緒氛圍與建議曲風4. 男聲、女聲或男女合唱5. 一句可以發展成 Hook 的歌詞概念6. 未來製作 MV 時可以呈現的視覺場景六首歌要有連續劇的感覺,但每首也能獨立欣賞。請使用自然的台灣繁體中文,不要過度文青或生硬。先用表格提供企劃,不要直接寫完整歌詞。 收到企劃後,先檢查每一集是否真的改變了故事狀態。例如第二首是否讓兩人更靠近、第四首是否有足以造成衝突的事件、最後一首是否回應前面留下的問題。若只是六首歌都在重複「很愛你、很想你」,就回頭調整主軸或每集企劃卡。 第三步:挑一首歌,分段寫歌詞先挑 EP01 試做,確認角色、語氣與 Hook 是否自然,再把相同的系列設定帶到下一首。提示詞可以像這樣: 提示詞:寫第一首完整歌詞12345678910111213141516171819202122請根據剛才規劃的六首歌系列,開始寫 EP01《那天的雨》。故事:男女主角在雨天的捷運出口第一次相遇。曲風:華語流行抒情,溫暖自然,帶一點電影感。演唱:溫暖的男性聲線。歌詞要求:1. 使用自然的台灣繁體中文。2. 句子長短可以有變化,不要為了押韻使用奇怪的詞。3. 副歌有一句容易記住的 Hook。4. 使用雨傘、捷運出口、街燈等具體畫面,避免空泛形容。5. 歌曲要能接上後續五首的故事。請用以下段落標籤輸出,並檢查唱起來是否自然:[Verse 1][Pre-Chorus][Chorus][Verse 2][Chorus][Bridge][Final Chorus][Outro] Verse 是主歌、Pre-Chorus 是預副歌、Chorus 是副歌、Bridge 是橋段、Outro 是結尾。這些標籤可以協助描述歌曲段落,但生成結果仍要實際聽過再調整。 第四步:把歌詞交給 Suno 生成歌曲打開 Suno,使用目前介面中可以自行輸入歌詞與音樂描述的創作方式。按鈕名稱與功能可能隨平台更新而變動;先確認現在的介面支援你要使用的輸入方式。 準備三項內容: Title:例如「那天的雨」。 Lyrics:貼上整理好的歌詞和段落標籤。 Style:描述曲風、樂器、情緒與演唱方向。 例如: 123Mandarin pop ballad, warm male vocal, emotional storytelling,soft piano, acoustic guitar, gentle drums, cinematic atmosphere,memorable melodic chorus, natural vocal delivery. 也可以用中文描述: 12華語流行抒情,溫暖成熟男聲,鋼琴與木吉他編曲,柔和鼓組,有電影感,副歌旋律容易記住,演唱自然有情緒。 生成後先聽歌詞是否順口、Hook 是否記得住、情緒是否符合這一集。若不滿意,先找出問題來自歌詞、旋律、演唱或編曲,再針對該項修改,不必立刻把整首歌全部推倒重來。 第五步:整理系列風格設定在繼續做 EP02 前,把整季固定的錨點整理成一份 style.md。不需要把所有細節鎖死;保留幾個跨集共同點,讓每首歌仍有自己的變化。 提示詞:建立系列風格設定1234567891011請根據這六首歌的企劃,整理一份系列風格設定草稿 style.md。請先挑出 3 到 5 個值得跨集固定的錨點,例如:- 整季故事主題與主軸- 主角外觀或人物關係- 歌曲段落結構、人聲配置或反覆出現的聲音記號- 歌詞用字與語言風格- MV 的共同視覺元素或包裝方式另外列出每集可以自由變化的項目,例如曲風、場景、主色或象徵物。說明每首歌如何連到下一首,並保留人工調整空間。 相同的曲風文字不保證每次生成都會得到完全相同的歌聲或編曲。若你需要較一致的人聲,請依目前平台提供的設定測試,並以實際生成結果為準。 第六步:從歌曲企劃發展 MV 分鏡先完成歌曲,再把故事和歌詞拆成畫面。初學可以先用簡單流程: 歌曲 → 故事分鏡 → 角色參考圖 → AI 影片片段 → 剪輯成 MV 以 EP01《那天的雨》為例,可以從下列畫面開始: 分鏡 畫面內容 01 台北雨夜,行人穿過捷運站出口 02 男主角走出車站,發現有人在屋簷下躲雨 03 他把雨傘往對方身邊移了一點 04 兩人在街燈下對視,音樂進入副歌 05 女主角離開,男主角回頭看向她的方向 提示詞:把歌曲轉成 MV 分鏡123456789101112131415我已經完成歌曲《那天的雨》。請根據歌詞設計一支 AI 音樂 MV 分鏡表。影片比例:16:9。視覺方向:台灣都市愛情電影、寫實攝影、溫暖色調。場景:捷運站出口、雨天街道、便利商店、夜晚街燈。請依歌曲實際長度安排每個分鏡,列出:1. 開始與結束時間2. 對應歌詞3. 畫面與角色動作4. 攝影機運動5. 靜態圖片提示詞與影片提示詞以 5 到 10 秒片段作為初步規劃單位,維持角色外觀、服裝與場景連續。先給我分鏡表審核,不要直接生成影片。 依照歌曲時間安排畫面,也要考慮生成片段可能需要裁切、延長或重新剪接。不要期待每段 AI 影片剛好符合節拍;最後仍要在剪輯軟體中調整鏡頭長度、音樂進點與轉場。 進階:再考慮使用完整 MV 自動化專案如果只是練習系列企劃、寫歌詞和生成歌曲,可以先不下載或安裝 autoip-mv-maker。若要實際執行該專案,請先讀取它的官方 README:目前文件提到 AutoIP API、ffmpeg、字型與 API key 等前置條件,生成影像任務會使用點數。請在送出前查看靜圖與成本資訊,並依專案文件保管 API key;不要把 key 寫進一般檔案或貼進提示詞。 若你只是想用 Codex 整理自己的企劃,也可以先建立簡單資料夾,管理故事設定和素材版本: 1234567891011121314151617my-ai-music-series/├── README.md├── style.md├── research.md├── characters/│ ├── male.md│ └── female.md├── episodes/│ ├── EP01/│ │ ├── lyrics_v1.txt│ │ ├── suno_style.txt│ │ └── storyboard.md│ └── EP02/└── assets/ ├── images/ ├── audio/ └── videos/ 這只是方便自己管理的資料夾範例,不是 autoip-mv-maker 安裝後自動建立的目錄。你可以請 Codex 協助整理企劃、比對每首歌是否符合 style.md,或把歌詞改寫成分鏡表;真正的歌詞、生成歌曲與影片仍要逐項檢查。 開始前,先確認這四件事 用一句話說清楚整季的題材與變化方向。 每首歌都有自己的故事位置,而不是重複同一種情緒。 選出 3 到 5 個跨集錨點,其他細節保留變化空間。 先完成一首歌和一支 MV 的分鏡,再決定如何延伸整季。 AI 可以幫忙發想、整理和生成素材,但歌曲是否自然、故事是否說得通、角色是否連貫,仍要由創作者檢查。製作或發布作品前,也要確認歌曲、角色圖、字型與其他素材的使用權,並遵守所用平台的內容揭露規範。 常見問答 (FAQ)Q1:這個專案證實作者是金曲獎作詞家嗎?不能只憑系列企劃文件確認作者具有金曲獎作詞家身分。本文聚焦的是文件中的系列規劃方法,不把網路貼文的說法當成已證實事實。 Q2:只用 ChatGPT 和 Suno 練習,需要安裝 GitHub 專案嗎?不需要。你可以先用 ChatGPT 整理故事與歌曲企劃,再用 Suno 試做歌曲;若要執行 autoip-mv-maker 的完整 MV 流程,才依官方 README 準備 API、ffmpeg、字型等環境。 Q3:把相同的 Style 提示詞貼給 Suno,就能固定歌手聲音嗎?不能保證。相同的描述可能產生不同的聲音或編曲;可依平台當前提供的聲音或延續功能測試,並以實際生成結果確認。 Q4:一定要做六首歌,才能叫音樂系列嗎?不一定。六首只是本文的示範規模。你可以依故事調整集數,重點是有清楚的共同主軸,並讓每一集既能獨立欣賞,也能推進整體內容。

  • article-365 個免費 AI 行銷 Skills 開源了!我用一個賣雞排的案例,帶你實際玩一次

    2026/10/11

    AI工具 ChatGPT 商業策略
    365 個免費 AI 行銷 Skills 開源了!我用一個賣雞排的案例,帶你實際玩一次

    最近看到行銷人邱煜庭分享了一個很有意思的開源專案,叫做 Marketing Skills for Everyone。 他把十幾年來的行銷實戰與教學經驗,整理成 365 個免費的 AI 行銷 Skills,放到 GitHub 開放大家使用。 我覺得這件事最有價值的地方,不是「哇!竟然有 365 個提示詞可以免費拿」。而是它想解決一個很多人在使用 AI 時都會遇到的問題: AI 很會給建議,但我們怎麼知道它的建議到底能不能用? 例如,你問 ChatGPT:「我開了一家雞排店,最近生意不好,該怎麼做行銷?」 AI 可能馬上給你十個建議:拍短影音、經營 Instagram、找網紅合作、推出會員制度、投放 Facebook 廣告……聽起來都很合理。 但問題是,你一個月只有 5,000 元行銷預算,這十件事情到底應該先做哪一件?而且,你連一份雞排賣出去到底賺多少都還沒算清楚,就開始花錢打廣告,真的適合嗎? 這就是我覺得這套 Skills 值得研究的原因。 它把行銷工作拆成具體的方法,包含需要什麼資料、怎麼分析、最後要交付什麼結果,以及怎麼檢查答案。今天就用一個簡單案例,帶大家試試看。 一、如何下載並使用免費的 AI 行銷 Skills?這套工具的使用方式,其實沒有想像中困難。不需要先學會寫程式,也不一定需要訂閱昂貴的 AI 服務。只要你使用的 AI 工具能上傳並讀取 Markdown 檔案,就可以照著以下方式操作;實際檔案上傳額度與支援情況,依工具當下的方案為準。 第一步:下載教材 GitHub 開源專案:Marketing Skills for Everyone 官方教學網站 進入 GitHub 後,點選綠色的 Code,再選擇 Download ZIP,下載後解壓縮。 第二步:找到 INDEX.md這個檔案可以把它想成 365 個行銷方法的目錄。你不用自己一個一個研究,先把 INDEX.md 上傳到 ChatGPT 或 Claude。 第三步:告訴 AI 你遇到的問題讓 AI 幫你找出適合使用哪個 Skill。 第四步:上傳對應的方法包依照 AI 找到的路徑,從下載的資料夾中找到對應的 Markdown 方法包,上傳到同一段對話。這樣 AI 就能根據方法包中的步驟進行分析。 需要哪個方法,就讀取哪個方法,不必把 365 個檔案全部上傳。 索引用來選方法;還沒讀到方法包全文時,不要讓 AI 只靠索引摘要就宣稱完成分析。 二、實際情境:一家雞排店,想用 5,000 元增加業績我們來設計一個虛構案例。假設我開了一家「阿亮炸雞排」,最近發現平日生意普通,想拿 5,000 元做促銷。 老闆原本的想法很簡單:「不然買兩份雞排折 20 元,再花一點錢投廣告好了!」 但如果你是行銷顧問,應該不會直接說好。你可能會先問:「老闆,你一份雞排到底賺多少?」 因為有些活動看起來營業額增加了,實際上卻可能越賣越虧。所以這次我們不急著叫 AI 寫廣告文案,先讓 AI 幫我們算清楚獲利,再決定要不要做促銷。 準備測試資料以下數字全部是教學用的假設資料,不是真實店家的營運數據。 項目 金額或方案 一份雞排售價 90 元 雞肉及醃料 35 元/份 炸油、粉料、調味 8 元/份 包裝袋 3 元/份 每份額外變動人工成本 4 元/份 預計行銷預算 5,000 元 促銷方案 買兩份折 20 元 這些資料已經足夠讓我們進行第一輪簡單試算,但還不能直接視為完整的店家淨利分析。 三、第一個提示詞:讓 AI 幫我們選 Skill先將 INDEX.md 上傳到 ChatGPT,接著輸入: 提示詞 1:選擇合適的行銷方法123456789101112131415我經營一家雞排店,想用 5,000 元行銷預算增加銷售。目前一份雞排售價 90 元,正在考慮推出買兩份折 20 元的活動。請根據我上傳的 INDEX.md,幫我找出最適合分析這個問題的 2~3 個 Skills。這一步只比較候選方法,不要直接執行多項工作。請告訴我:1. 每個 Skill 的名稱與檔案路徑。2. 為什麼適合我的情境。3. 我需要準備哪些資料。4. 建議先執行哪一個。請只使用索引中確實存在的 Skills,不要自行編造名稱。尚未讀取方法包全文時,請先等我上傳,不要用索引摘要代替方法。 這一步最重要的概念是:先選方法,再解決問題。 就像看醫生,不是看到病人就直接開藥,而是先確認問題在哪裡。 在這個案例中,我們可以優先尋找與「單品貢獻毛利計算」及「檔期預算與獲利預估」相關的方法。實際名稱和檔案路徑,請以下載版本的 INDEX.md 為準。 四、第二個提示詞:上傳 Skill,開始計算找到適合的 Skill 後,把對應的 Markdown 方法包上傳到同一段 AI 對話,然後輸入: 提示詞 2:執行雞排獲利分析12345678910111213141516171819202122請依照我上傳的行銷 Skill 方法包,分析以下雞排店的促銷方案。商品售價:90 元。每份成本:- 雞肉及醃料:35 元- 炸油、粉料、調味:8 元- 包裝:3 元- 額外變動人工:4 元促銷方案:買兩份折 20 元。行銷預算:5,000 元。請幫我:1. 計算原價與促銷後的單份貢獻毛利。2. 比較每賣出兩份雞排的獲利差異。3. 計算需要增加多少銷量,才有機會回收 5,000 元行銷費用。4. 提醒我哪些成本還沒有納入。5. 提供是否值得推出活動的初步建議。請依方法包的規則執行,列出計算公式、假設條件與檢查結果,不要把未知數字當成已知事實。若問題超出已上傳方法的範圍,請指出需要補充的資料或方法包。 五、手動核對:AI 應該得到什麼結果?這一步很重要。因為我們不應該只看 AI 寫得有沒有道理,還要檢查它算得對不對。 原價一份雞排 90 元,已知每份變動成本合計 50 元: 12每份已知變動成本 = 35 + 8 + 3 + 4 = 50 元原價每份貢獻毛利 = 90 − 50 = 40 元 如果推出買兩份折 20 元,兩份雞排原價 180 元,折扣後收 160 元,成本合計 100 元: 12促銷後每兩份貢獻毛利 = 160 − 100 = 60 元促銷後每份平均貢獻毛利 = 60 ÷ 2 = 30 元 比較項目 原價 促銷後 每份平均收入 90 元 80 元 每份變動成本 50 元 50 元 每份貢獻毛利 40 元 30 元 貢獻毛利率 44.4% 37.5% 也就是說,折扣之後,每份雞排的貢獻毛利少了 10 元,下降 25%。這裡的貢獻毛利率以成交收入為分母;它不是扣完租金、固定薪資等支出後的淨利率。 5,000 元行銷預算,需要賣出多少雞排才能回收?如果全部都是新增銷量,而且全部以促銷價格成交: 1235,000 ÷ 30 = 166.67 份每筆促銷訂單為兩份,因此須以雙份套餐進位:5,000 ÷ 60 = 83.33 組 → 至少 84 組 = 168 份 至少需要額外賣出 168 份雞排,也就是 84 組雙份套餐,才有機會以新增貢獻毛利回收這筆行銷費用。 小心:原本就會買的客人,也可能使用折扣如果原本就會買原價雞排的客人,也跑來使用折扣,實際效果就會不一樣。例如原本會買兩份的客人,現在少付 20 元,店家就少賺 20 元。 所以 168 份不是活動保證回本的數字,而是在特定假設下的試算門檻。 這也是為什麼做行銷不能只看營業額,還要看新增銷量、原有訂單被折扣取代的比例,以及真正增加的貢獻毛利。 目前也還沒完整納入可能存在的稅費、金流或外送平台費、耗損、額外能源成本、加班或產能變動,以及租金與固定薪資等支出。應先確認哪些會隨訂單增加,哪些屬於固定成本,避免漏算或重複扣除;5,000 元行銷費用在本例另外扣除。 六、第三個提示詞:檢查促銷是否真的值得做接著,我會再問 AI 一個問題;若需要另一份方法包,就先依索引找到並上傳,再繼續分析。 提示詞 3:檢查促銷活動風險123456789101112131415161718請繼續依照行銷 Skill 的分析方式,幫我檢查這次雞排促銷的風險。假設活動期間有部分消費者原本就會購買雞排,只是因為折扣而改買促銷套餐。每筆促銷訂單均為兩份雞排。請比較以下三種情境:1. 所有促銷訂單都是新增購買。2. 50% 的促銷訂單原本就會以原價購買兩份。3. 80% 的促銷訂單原本就會以原價購買兩份。請以「沒有促銷時的貢獻毛利」為比較基準,分別計算回收 5,000 元行銷費用所需的促銷訂單數,並說明:- 哪種情況下活動比較有價值?- 哪些數字需要實際測試才能確認?- 有沒有比全面打折更好的促銷方式?若每筆平均新增貢獻為零或負數,請明確說明無法靠增加同類訂單回收費用。請區分數學試算與實際營運建議。 這時候 AI 就不只是幫你計算,而是開始協助你判斷行銷活動的可行性。 用新增貢獻檢查三種情境我們也可以先建立核對基準。令 p 為原本就會以原價購買兩份的促銷訂單比例: 12345真正新增的雙份訂單:每筆增加 60 元貢獻毛利原有雙份訂單改用折扣:每筆減少 20 元貢獻毛利每筆促銷訂單平均新增貢獻 = (1 − p) × 60 − p × 20 = 60 − 80p活動新增貢獻淨額 = 促銷訂單數 × (60 − 80p) − 5,000 情境 每筆平均新增貢獻 回收 5,000 元所需促銷訂單數 全部是新增購買 60 元 至少 84 筆,共 168 份 50% 原本就會買兩份 20 元 250 筆,共 500 份 80% 原本就會買兩份 −4 元 依此假設無法回收;每增加一筆促銷訂單,平均新增貢獻反而減少 4 元 這是固定比例與固定成本假設下的數學試算,不是實測成果。尤其第三種情境,促銷訂單本身仍有 60 元貢獻毛利,但相較於沒有活動時的訂單組合,平均反而少了 4 元;兩者的比較基準不同。 也許最後你會發現,比起全面買兩份折 20 元,更值得測試的是平日離峰時段優惠、新客限定優惠,或搭配其他商品提高客單價。但這些都需要實際測試,不能光靠 AI 推測。 七、這套 Skills 真正值得學習的地方:建立判斷很多人使用 AI,都是從「我要什麼答案」開始,例如:「幫我寫一篇雞排店促銷文案。」 但有經驗的行銷人,可能會先問:「這個活動有沒有賺錢的機會?」這兩種提問方式,最後產出的價值差很多。 我覺得 Marketing Skills for Everyone 很值得借鏡的地方,就是把行銷工作從「產出內容」往前推到「建立判斷」。 而且作者選擇用 Markdown 方法包公開,不一定要懂程式、不一定要串接 API,也不需要一開始就建構複雜的 AI Agent。只要 AI 工具能讀取檔案,就可以先從一個真實問題開始練習。 當然,Skill 不是魔法。資料不完整、假設錯誤,AI 還是可能算錯或給出不適合的建議。 所以最好的用法,是讓 AI 幫我們整理問題、選擇方法、進行分析,再由人來核對與決定。如果你想進一步理解如何把工作經驗整理成方法包,也可以閱讀:從 Prompt 到 Skill Library:如何打造自己的 AI 工作能力庫。 這次用雞排店只是示範。同樣的流程,也可以拿來分析電商商品定價、課程招生預算、LINE 會員回購活動,甚至企業的年度行銷計畫。 如果你從來沒用過 AI Skills,我建議先不要急著研究全部 365 個。先挑一個你現在真的遇到的行銷問題,下載方法包,照著做一次。 你會發現,AI 真正有價值的地方,不只是讓我們把事情做得更快,而是讓我們有機會把事情想得更清楚。 免費開源專案與教學來源 GitHub:Marketing Skills for Everyone 官方教學:365 個免費 AI 行銷 Skills 方法索引 INDEX.md 也感謝邱煜庭把多年累積的行銷經驗整理開源,讓更多人可以從實際問題開始學習。 如果是你,你會想先拿 AI Skills 解決什麼行銷問題?歡迎留言分享,我也想看看這套方法還能用在哪些有趣的情境。 常見問答 (FAQ)Q1:使用這 365 個 AI 行銷 Skills,需要寫程式或付費訂閱嗎?本文示範的是下載 Markdown 方法包,再上傳給能讀取檔案的 AI 工具,不需要寫程式或串接 API。方法包本身免費開源;AI 工具是否提供檔案上傳、可用額度與方案限制,仍須依當下服務確認。 Q2:為什麼先上傳 INDEX.md,而不是一次上傳全部方法包?INDEX.md 是選擇方法的目錄,讓 AI 依問題找出確實存在的方法名稱與完整路徑。選定後再上傳對應方法包全文,才能依具體步驟執行與核對,避免只靠索引摘要猜測分析方式。 Q3:雞排店額外賣出 168 份,就一定能回收 5,000 元嗎?不一定。168 份的門檻假設所有促銷訂單都是新增購買、每筆兩份、每份變動成本固定為 50 元,且沒有其他未計入的變動成本。若原本就會買原價雞排的客人改用折扣,新增貢獻會下降,甚至無法靠增加促銷訂單回收費用。 Q4:貢獻毛利等於店家最後賺到的淨利嗎?不等於。本例貢獻毛利是成交收入扣除已列出的變動成本,仍需要用來支付租金、固定薪資與其他固定支出。完整營運判斷也要確認稅費、耗損、平台費和產能變動等成本是否適用。 Q5:AI 依照 Skill 算出結果後,還需要人工檢查什麼?至少核對資料來源、公式、成本有無漏算或重複扣除、訂單與份數的單位,以及新增銷量和原有訂單折扣替代的假設。方法包能提供分析步驟與核對依據,實際促銷效果仍需以測試和營運資料確認。

  • 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-當 ChatGPT 可以接上 Pi:AI Agent 正在走向「模型與 Harness 分離」

    2026/9/30

    AI工具 ChatGPT AI Agent
    當 ChatGPT 可以接上 Pi:AI Agent 正在走向「模型與 Harness 分離」

    最近看到 OpenAI 推出 Sign in with ChatGPT,並開始讓符合資格的開源工具串接 ChatGPT 方案用量。官方目前列出的開源工具範例包含 Pi by Earendil。 一開始我也以為,這只是「Pi 現在可以更方便使用 GPT」。但把 OpenAI 的整合說明和 Pi 的登入方式放在一起看,我更在意的其實是另一件事:我們過去常綁在一起看的模型與 Agent Harness,正在變成可以分開選擇的兩層。 這可能改變我們挑選 AI Agent 工具的方式。 為什麼我開始把模型與 Agent 分開看?這兩年挑 AI Coding 或 Agent 工具時,我們很容易先從模型開始想:想用 Claude,就想到 Claude Code;想用 OpenAI,就想到 Codex;想用 Gemini,就去找 Google 生態系裡的工具。 久了容易覺得模型就是 Agent。其實模型比較像負責理解、推理、規劃與生成的大腦。要讓它讀檔、改程式、執行 Shell、呼叫 MCP、操作瀏覽器、載入 Skill,還需要一套把模型接到電腦、工具和工作流程上的系統。 這一層通常稱為 Agent Harness。 Harness 負責把模型接到工作現場假設我們請 Agent 檢查專案、找出 Bug、修改程式碼、執行測試,再整理報告。真正完成任務時,除了模型本身,背後還有許多部分一起運作: 上下文管理與檔案系統 Shell、Terminal 與工具呼叫 MCP、Skills、Browser 或 Computer Use 權限控制、錯誤處理與 Agent Loop 工作狀態保存、模型切換與記憶機制 這些能力如何串接,會影響模型能看見什麼、可以採取哪些行動,以及出錯後能不能修正並繼續。Harness 不只是聊天介面,而是模型的執行環境和工作規則。 同一個 GPT,換一套 Harness 也會有不同體驗假設兩套 Agent 使用能力相近的 GPT 模型。A Harness 可能會先搜尋專案、整理計畫、修改程式碼、自動執行測試,發現錯誤後再回頭修正與驗證;B Harness 可能只讀幾個檔案、修改一次就回報完成。 最後使用者感受到的「AI 好不好用」,不一定全是模型能力的差異,也可能是 Harness 怎麼安排模型工作的結果。 Pi × ChatGPT 值得注意的是什麼?OpenAI 的 Sign in with ChatGPT 把兩種權限分開處理:使用者可以用 ChatGPT 身分登入,也可以另外選擇是否讓符合資格的應用程式使用方案內的 AI 用量。使用 ChatGPT 方案用量需要獨立授權;目前官方說明限定 Plus 與 Pro 等符合資格的方案,而且這不會把 ChatGPT 對話或 API Key 交給應用程式。OpenAI 使用說明 也列出 Pi by Earendil 作為開源工具範例。 這不只是第三方工具自己接上一個模型 API。OpenAI 已提供讓開源工具使用者以 ChatGPT 帳號登入,並在同意後使用方案用量的整合方式;開發者文件也說明,登入身分與使用方案用量是不同能力,後者是可選權限。 不過「列在支援範例」不等於每種登入方式對所有使用者都已順利可用。Pi 既有的文件也列出 ChatGPT Plus/Pro(Codex)訂閱登入;此外,Pi 專案在 2026 年 9 月 29 日有使用者回報,新版 Sign in with ChatGPT 的 Pi 登入出現 invalid_client,而舊的 Codex 訂閱登入仍可用。這是一則使用者回報,不能推論成所有帳號都遇到相同問題;但它提醒我們,整合方式和實際可用狀態可能還在演進。Pi 登入文件 · Pi issue #10184 模型與 Harness 可以分開組合過去模型、帳號、額度和 Agent 工具常被包成一套產品。現在可以想像不同的組合:ChatGPT 方案連上 Pi,Pi 再接 Skills、MCP、CLI 或 Browser,最後串成自己的 Workflow。 我也可能在某些工作使用 Claude Code,在另一些工作使用 Codex;需要自訂流程時,再選 Pi、OpenClaw 或 Hermes 等其他 Harness。這些工具的能力和整合方式會隨版本變動,但「模型與執行環境可以分開思考」是更值得留下的觀念。 因此,選 AI Agent 時只問「要用哪一個 AI?」可能不夠。還可以接著問: 你使用什麼 Model? 你使用什麼 Harness? 你裝了哪些 Skills、接了哪些 Tools? 這些元件最後如何組成 Workflow? Harness 也是一條重要的信任邊界Agent 不只回答問題。依照授權,它可能讀寫檔案、執行指令、連接服務、操作瀏覽器、使用憑證或呼叫 MCP。因此除了問「這顆 LLM 安不安全?」,也要了解「這套 Harness 在我的電腦上能做什麼?」 Harness 決定模型可用的工具和權限,也要負責把操作結果與錯誤交回模型。選擇工具時,可以檢查它會讀取哪些資料、哪些地方會執行 Shell、網路請求送往哪裡、憑證如何保存,以及 MCP 或擴充套件擁有哪些權限。 開源代表多了一個檢查入口,不代表自動安全Pi、OpenClaw、Hermes 這類開源 Harness 有一個優點:原始碼可以檢查。開源不等於安全,專案仍可能有漏洞,第三方 Skill、Plugin 或 MCP 也可能帶來風險。 但我們可以把「完全不知道它在做什麼」往前推一步,改成檢查它的資料流、Token 儲存、Shell 執行點、網路請求、遙測、相依套件與敏感檔案存取。也能請 Codex 或 Claude Code 協助做安全檢視,再由人確認重要結果。這不能保證百分之百安全,卻增加了理解和審查的機會。 Skill Library 比 Prompt 收藏更容易累積工作方法我最近整理 Agent Skill 時,越來越不想只收藏「一百個超強 Prompt」。Prompt 容易散落各處;比較有價值的,是把自己的工作方法整理成可重複使用的能力。 例如簡報、文章、社群內容、研究、影片分鏡、資料整理、Vibe Coding 或課程設計 Skill,都可以說明 Agent 遇到這類工作時,先做什麼、要遵守哪些規則、參考哪些資料、輸出成什麼格式,以及如何驗收成果。 每個 Skill 不只是放一句提示詞,而是逐步累積判斷方式與 SOP。這也延伸了我在整理自己的 AI 工作能力庫時的想法:把工作方法留下來,才能在模型更新時繼續使用。 用五層架構理解 AI Agent剛開始研究 Agent 時,可以先用五層架構來看: Model:GPT、Claude、Gemini 等模型,負責理解與推理。 Harness:Pi、Codex、Claude Code、OpenClaw、Hermes 等工具,負責讓模型在環境中工作。 Skills:把專業知識、規則與 SOP 包成可重複使用的能力。 Tools:MCP、CLI、Browser、Computer Use、API 等,讓 Agent 接觸外部工具和資料。 Workflow:把前面各層組合起來,完成一項真正的工作。 最後產生價值的,通常不是單獨某一顆 LLM,而是 Model、Harness、Skills、Tools 與 Workflow 的組合。 哪些人值得研究 Pi 這類開源 Harness?如果平常只是偶爾問 ChatGPT 問題,不需要因為一則整合消息就立刻更換工具。但如果已經開始做 AI Coding、MCP、Skills、自動化、長時間任務或多工具工作流,Pi 這類開源 Harness 值得研究。 重點不是把所有工作搬到同一個工具,而是理解模型、執行環境與工作方法可以分開評估,再依任務組合。 Agent 下一戰也許是工作系統GPT、Claude、Gemini 都會持續更新,模型排行榜也會一直變。我現在更在意的是:工作流程有沒有留下來?Skill 能不能重複使用?工具能不能替換模型?資料能不能掌握?Harness 能不能檢查?Agent 能不能真正完成工作? 以前我會想「選一個最強的 AI,把工作交給它」。現在更傾向先建立自己的 AI 工作系統,再選合適的模型進來工作。 模型會換,Harness 也會進化;更值得自己留下來的,是 Skills、Tools、Workflow,以及累積下來的工作方法。也許以後大家討論 AI Agent,不只問「你用 GPT 還是 Claude?」,還會問「你現在用哪個 Harness?你的 Skill Library 裡有什麼?」 參考資料 OpenAI:Using your ChatGPT plan in other apps and sites OpenAI:Integrating Sign in with ChatGPT in your Open Source App Pi:Provider Authentication Pi issue #10184:Sign in with ChatGPT 登入回報 常見問答 (FAQ)Q1:Agent Harness 是什麼?Agent Harness 是讓模型在電腦與工具環境中執行任務的系統,通常包含上下文管理、檔案與 Shell 工具、權限控制、Agent Loop、錯誤處理及工作狀態等部分。 Q2:使用 Pi 連接 ChatGPT 方案一定要準備 API Key 嗎?Sign in with ChatGPT 的開源整合可讓符合資格的使用者登入,並在另外授權後使用方案內的 AI 用量,不需要自行建立或提供 OpenAI API Key。是否能使用仍取決於方案資格、工具整合與當下登入狀態。 Q3:Sign in with ChatGPT 會把我的 ChatGPT 對話交給 Pi 嗎?不會因登入或使用方案用量就取得 ChatGPT 對話或 API Key。登入身分與方案用量授權是不同權限;使用者仍應逐項檢查應用程式要求的權限及其資料處理方式。 Q4:開源 Agent Harness 就代表安全嗎?不代表。開源讓人有機會檢查原始碼,但不能保證沒有漏洞,也不能替第三方 Skills、Plugins 或 MCP 背書。使用前仍要檢查程式行為、資料流、工具權限與相依套件。

  • article-我把 ChatGPT 接上自己的開發台 MCP,AI Coding 開始變成一條「軟體開發流水線」

    2026/9/14

    ChatGPT AI Agent Codex
    我把 ChatGPT 接上自己的開發台 MCP,AI Coding 開始變成一條「軟體開發流水線」

    最近我開始把 ChatGPT 接進原本提供給 Codex、Claude 使用的開發台 MCP。最有意思的地方,不是讓 ChatGPT 跟 Codex 搶著寫程式,而是把需求討論、工作規劃、程式實作與 Review 拆成不同角色。 我可以先讓 ChatGPT 查看開發台允許提供的專案脈絡,協助分析問題、整理風險與驗收條件,再透過 MCP 建立 Ticket,交給 Codex 接手。完成後,再把差異與測試結果交回來 Review。 以這個工作方式來看,分析和由 ChatGPT 發起的 MCP 操作使用 ChatGPT 端的可用額度,Codex 的工程執行則在 Codex 的工作環境中進行。乍看之下,好像終於能把 ChatGPT 每月訂閱用得更完整了 😂。但額度和費用會依方案、整合方式與工具呼叫而變化,這不是接上 MCP 就一定省錢的保證。 真正值得注意的,是 AI Coding 開始從「一個 Agent 包辦所有事」,走向「一組 Agent 按照分工接力完成工作」。 ChatGPT 不一定要寫程式,也能參與開發使用 Codex 時,我們常把需求理解、讀取 Context、規劃、修改、測試、Review 和下一步討論,全塞在同一個 Agent 裡。專案越大,耗費的時間和額度往往不只來自寫程式,也包括理解專案、追蹤進度、檢查結果和重新安排工作。 如果有一套開發台 MCP 能提供必要的專案狀態、Session 摘要或 Ticket 操作,ChatGPT 就可以先負責需要大量溝通和判斷的工作:釐清需求、找出風險、拆出可執行的工作,再把任務交給 Codex。 以一次長時間的工作樹合併任務為例,當 Codex 已經執行很久,我不一定要繼續在同一個 Agent 裡討論下一步。我可以請 ChatGPT 根據開發台提供的狀態,檢查目前結果、列出可改善處與潛在風險,再整理成一張 Codex 能接手的票。 這樣一來,ChatGPT 的價值不在於「代替 Codex 寫另一份程式」,而在於把模糊的討論轉成清楚、有優先順序、可以驗收的工作。 把不同角色接成一條開發流程如果把工作拆開來看,分工可以是: ChatGPT:需求分析與 Review。 協助釐清問題、檢查現況、拆解任務、補充驗收條件,並Review Codex 回報的結果。 開發台 MCP:提供連接與操作能力。 依照開發台實際設計,讀取被允許的 Context、建立或更新 Ticket、傳遞執行結果與工作狀態。 Codex:工程實作與驗證。 根據 Ticket 修改程式、執行測試,並回報差異、失敗項目和未解風險。 人:決定優先順序與重要操作。 確認需求、核准高影響變更,決定是否 Commit、Merge 或關閉 Ticket。 整體流程就會像這樣: 12345678910111213人提出需求 ↓ChatGPT 取得允許使用的專案脈絡並分析 ↓MCP 建立 Ticket,記錄工作範圍與驗收條件 ↓Codex 實作並執行測試 ↓開發台回報差異、測試結果與阻礙 ↓ChatGPT Review,整理下一步 ↓人確認是否 Commit、Merge 或關票 這條流程不代表每個 MCP 都有 Session、Ticket 或 Git 管理功能。MCP 規格提供的是連接模型應用與外部能力的通用介面;例如伺服器可以依實作提供可呼叫的 Tools、可讀取的 Resources 和 Prompts。開發台是否保存狀態、能不能開票或執行 Git 操作,仍要看實際 MCP Server 和周邊系統怎麼設計。MCP 官方規格:Server Features 因此我會把 MCP 想成這條流程的「連接層」,而不是整套開發管理系統本身。Session 保存、Ticket 欄位、權限控管、測試流程與工作狀態,都是 Harness 和開發台需要另外規劃的部分。 Agent Harness 讓模型有地方工作這個分工也呼應我最近一直在研究的觀念:Agent = Model + Harness。 大家常比較 GPT、Claude、Gemini 或 Codex 的模型能力。模型當然重要,但如果整條流程、專案脈絡和驗收方式都綁在單一模型裡,每次換模型都可能得重新建立工作方式。 如果自己的開發 Harness 已經整理好 Context、Tools、Ticket、Memory、Test、Git 和 Review Loop,模型就比較像其中一個可以調度的元件。今天可以 ChatGPT 規劃、Codex 執行;明天也可以換成另一個模型負責分析或 Review,再由適合的 Agent 實作。 這種可替換性不是插上另一個模型就會自動發生。不同模型可用的工具、輸入輸出格式和權限都可能不同,還是要有穩定的工作契約:任務怎麼交接、結果怎麼回報、測試如何判斷通過、失敗時誰要處理。 如果你想延伸理解 Harness 在 AI 開發流程中的位置,也可以閱讀從 Skill 到 Agent Harness:讓 AI 從知道怎麼做,走到真正完成工作;MCP、Skill 與 CLI 的分工則可參考AI 工具名詞全解析。 把 Ticket 寫成 Agent 能接手的工作Ticket 是這條流程能不能穩定運作的關鍵。若只有一句「幫我改善這段程式」,接手的 Agent 仍要猜背景、範圍和完成標準。每張票可以固定包含: 12345678910111213ticket_id: 自動產生title: 清楚描述要交付的結果background: 相關的專案脈絡problem: 目前遇到的問題priority: 優先級affected_files: 已知的相關檔案dependencies: 前置工作或相依項目acceptance_criteria: - 可明確驗收的條件test_requirements: - 完成前必須執行的檢查review_notes: 已知風險、限制或 Review 重點 其中 affected_files 可以列出已知範圍,但不應阻止 Codex 在檢查專案後指出還有其他必要檔案。真正重要的是 problem 說得清楚,acceptance_criteria 可以驗收,test_requirements 也符合專案實際狀況。 當 Ticket 結構固定,ChatGPT 就比較能把分析結果轉成工程任務;Codex 也能根據明確的交付條件回報完成、未完成與阻礙,而不是只回一句「已處理」。 下一場競爭可能是誰的 Harness 更完整當多個 Agent 開始分工,真正需要設計的就不只 Prompt,還包括它們共同使用的工作環境: Agent 能讀到哪些 Context,哪些資料不能取用? 誰能建立 Ticket、修改程式或執行 Git 操作? 測試失敗時,系統如何保留輸出並回報阻礙? 每個階段的完成條件是什麼,由誰 Review? Agent 交接時,下一位能否知道前一位做過什麼、為什麼這樣做? 當 MCP 工具可以建立或改變外部資料時,也要設計清楚的權限與人工確認邊界。不要只因為模型「做得到」,就讓所有操作都自動執行。 這些環節加起來,才是 Agent Harness 真正提供的工作條件。若系統有持續的 Context、明確的 Ticket、可執行的測試與可靠的回報方式,就能讓模型專注在任務,而不是每一輪都重新猜專案發生了什麼事。 從一張結構化 Ticket 開始如果你也想嘗試這種 AI Coding 工作方式,可以先挑一個範圍小、容易驗收的任務,整理出背景、問題、優先順序、驗收條件和測試要求,再觀察 ChatGPT 與 Codex 分工後有哪些地方仍需要人工補充。 接著再逐步加入專案 Context、Ticket 狀態、工具權限與 Review 流程。先讓交接清楚、失敗能回報,再決定哪些步驟適合自動化。 AI Coding 正從「我跟一個 AI 一直聊天,直到網站做完」,走向「我在管理一條由多個 AI Agent 組成的軟體開發流程」。ChatGPT 不一定要負責寫程式,Codex 也不必負責想完所有事情;把規劃、執行、測試和 Review 拆開,再讓 Harness 接得住每次交接,才會真正累積成自己的 AI 開發台。 常見問答 (FAQ)Q1:在這種 AI Coding 流程裡,ChatGPT 和 Codex 怎麼分工?ChatGPT 可以負責需求討論、專案分析、Ticket 規劃與結果 Review;Codex 可以接手明確定義的實作與測試工作。實際分工仍取決於各自可讀取的 Context、可用工具和權限。 Q2:MCP 會自動替我保存 Session 或建立 Ticket 嗎?不會。MCP 提供模型應用與外部 Tools、Resources、Prompts 溝通的介面;Session 保存、Ticket 系統與 Git 操作必須由實際 MCP Server 或周邊開發台提供。 Q3:把規劃交給 ChatGPT,能保證省下 Codex 額度嗎?不能保證。不同產品方案、帳戶額度、工具呼叫方式和任務執行環境都會影響使用量。這種分工可以把分析與工程執行分開觀察,但是否省錢要依自己的實際方案和用量判斷。 Q4:想開始使用多個 AI Agent 協作,第一步該做什麼?先挑一個小型、可驗收的任務,寫清楚背景、問題、完成條件與測試要求,再讓不同 Agent 接力執行。確認工作交接和失敗回報可靠後,再逐步擴充工具權限、Ticket 狀態與自動化程度。

  • article-【ChatGPT Sites 真正適合的角色,不是正式網站,而是產品驗證層】

    2026/9/12

    ChatGPT Vibe Coding Cloudflare
    【ChatGPT Sites 真正適合的角色,不是正式網站,而是產品驗證層】

    最近看到 ChatGPT Sites 上線三個月後,使用者已建立超過 500 萬個 Sites。OpenAI 在 2026 年 9 月 11 日的更新中,也提到團隊協作、私密分享、資料庫檢視、自訂網域,以及從提示到部署速度提升等功能。官方公告 這些更新很容易讓人想到另一個問題:ChatGPT Sites 是不是準備和 Wix、Webflow、Vercel 競爭? 我反而覺得,它最有價值的角色不是取代傳統網站平台,而是成為 AI 時代的產品驗證層。 先釐清兩件事:500 萬是 OpenAI 公布的 Sites 建立數,不能直接當成活躍使用者、持續使用的產品或市場需求已驗證的證據;「產品驗證層」則是我對 Sites 的定位,不是官方替產品命名的功能。Sites 不會自動替你驗證需求,它的價值是讓你更快做出可以交給使用者試用的版本。 以前做 MVP,程式碼還沒開始就得先準備一大堆事以前有個產品想法,就算只做 MVP,也可能先卡在一串工程工作: 選 Framework、建立 GitHub Repository。 設定 Cloudflare 或 Vercel、決定資料庫與 Auth。 管理環境變數、串接 API、建立 Admin。 準備部署、測試與後續維護。 等到真的能交給使用者操作,往往已投入不少時間。最可惜的是,忙完才發現沒有人需要它。 最大的浪費不一定是選錯 Framework,而是還沒確認問題是否存在,就先為一個未驗證的想法付出正式工程成本。 Sites 把「做出一個可操作版本」提前了用 Sites,可以先用自然語言描述想解決的問題,再透過對話調整畫面、互動與資料。驗證流程因此可以縮短成: 123456789想法 ↓描述需求、產生介面 ↓加入互動與必要資料 ↓交給目標使用者試用 ↓依回饋修改,或決定停止 你不必一開始就決定要用 React 還是 Next.js,也不用先把整套正式環境建好。先讓某個人能完成一件具體的事,再觀察這個流程是否真的有用。 不過,Sites 裡的「部署」不等於隔離的測試環境。OpenAI 文件說明,每個部署網址都是 production URL;若要先檢視變更,可以先儲存版本,確認後再部署。因此,拿給使用者試用前,也要確認分享對象、存取權限與資料內容。ChatGPT Sites 使用說明 Sites 適合承載 Prototype 與早期 MVP你提供的展示圖裡,有像素寵物遊戲、3D 模型上色工具和計算機。這些作品的重點不只是資訊展示,而是有人可以打開頁面後實際操作的小型 Web App。 因此,Sites 可以用來測試不少概念: 簡易 CRM、活動管理系統或 Dashboard。 計算工具、預約流程或測驗系統。 客戶 Portal、內部資訊站或 AI 小工具。 Micro SaaS 的第一版核心流程。 這些用途仍要看產品需求是否符合 Sites 支援的執行環境。Sites 目前處於 Beta,使用額度會依方案或工作區而異;部分框架、資料庫、私有網路與背景服務可能不受支援,也不提供資料所在地或推論所在地保證。OpenAI Sites 開發文件 驗證時也不要只問自己「我覺得好不好用」。把版本交給目標使用者,觀察他能不能完成核心任務、是否願意再用一次,以及這個問題是否值得投入下一階段。 Sites 目前不是一鍵匯出到 GitHub這一點值得說清楚。目前公開的 Sites 文件描述了從提示開始建立,也能將相容的既有本機專案交給 Sites 建置與部署;本機來源專案的版本也可以連結到建置時使用的 Git commit。但文件沒有描述把已建立的 Sites 一鍵匯出成 GitHub Repository 的操作流程。 所以我不會把它想成「按一下 Export、整個專案進 GitHub,再按一下就搬到 Cloudflare」。比較務實的做法,是把 Sites 當成已驗證的產品規格、UI Reference 與功能 Prototype。需求成熟後,再請 ChatGPT 或 Codex 根據使用情境、畫面、資料結構與流程,重建正式版本。 這也是我偏好 Productionize 而不是 Migration 的原因:Migration 聽起來像把原始程式碼原封不動搬出去;Productionize 則是保留被驗證過的產品設計,再用合適的正式架構重新實作。 你提供的資訊圖整理了這段思路。它呈現的是產品驗證到工程化的概念流程,不代表 Sites 內建一鍵匯出,或能自動把整套產品搬到 Cloudflare。 從 Idea 到 Production,可以拆成九個階段 Idea:描述想解決的問題,以及現在是誰、在什麼情境下遇到它。 Sites Prototype:快速做出可以點、可以玩的原型,先呈現核心使用流程。 MVP:加入驗證核心任務所需的表單、資料、Dashboard、Admin 或 AI 功能。 Validation:交給真正的目標使用者測試,記錄他們是否完成任務、在哪裡卡住,以及是否願意再使用。 Freeze Spec:整理並凍結 UI、User Flow、Database Schema、Business Logic、API、權限與已驗證的需求。 Codex Productionize:由 Codex 根據已驗證的規格重建正式專案,補上工程結構與必要檢查。 GitHub:從這一步開始,讓 GitHub 成為正式程式碼的 Source of Truth,管理版本、審查與自動化流程。 Cloudflare:依產品需要選擇 Workers、D1、R2、KV、Queues、Durable Objects 或 Cron Triggers;這些是可組合的 Cloudflare 平台服務,不代表每個 Site 都會用到它們。Cloudflare Workers 文件 Production:補上 Authentication、RBAC、Rate Limit、Logging、Monitoring、Backup、Analytics、CI/CD,以及 Dev、Staging、Production 等環境。 如果你想看 Vibe Coding 如何落在一個真實系統,也可以延伸閱讀打造線上報價單與電子簽署系統的實作經驗。 搬到 Cloudflare 後,控制權增加,工程責任也回到自己身上當正式版本改由自己維護,就能依需求決定資料庫、Auth、AI 模型、檔案儲存、Log 保存方式、排程、Queue、Rate Limit 與備份策略。這些自由度比只使用受支援的 Sites Runtime 大得多,但每個選擇也會變成需要設計、驗證與維護的工程責任。 更精確地說,離開 Sites 後,消失的是 Sites 本身的限制,不是所有平台限制。Cloudflare 各服務仍有不同的適用情境與操作邊界;你需要根據資料量、流量、權限、可靠性與維護能力選擇組合,而不是把 Workers、D1、R2、KV、Queues、Durable Objects 和 Cron 全部加進第一版。 如果一開始就把所有正式產品要求塞進 Prototype,反而會失去 Sites 最有價值的速度。先確認有人需要、真的會用,再判斷這個產品值不值得工程化。 ChatGPT Sites 是 Production 前的產品驗證層我會把 ChatGPT Sites 定位為產品孵化器,而不是正式產品架構的終點。先快速做、快速改、快速測,也可以在發現沒人需要時及早停下;等到核心流程被驗證,再把規格交給 Codex、GitHub 與 Cloudflare,用正式工程方式重建。 我現在會把這套 Vibe Coding 流程整理成: Sites → MVP → Validate → Codex → GitHub → Cloudflare → Production 以前 AI 幫我們解決的是「怎麼更快寫程式」;現在它也開始降低另一種成本:怎麼更便宜地知道,這個程式到底值不值得寫。 常見問答(FAQ)Q1:ChatGPT Sites 可以取代 Wix、Webflow 或 Vercel 嗎?這篇文章的定位不是比較平台功能,而是建議先把 Sites 用在 Prototype 與早期 MVP 驗證。當產品需求、資料與維運責任逐漸明確,再決定正式網站或系統要採用什麼架構與平台。 Q2:OpenAI 說建立了 500 萬個 Sites,代表有 500 萬個活躍使用者嗎?不代表。OpenAI 公布的是 Sites 建立數,不是活躍使用者數、留存率或付費需求。它能反映建立行為的規模,不能單獨證明這些產品有人持續使用。 Q3:ChatGPT Sites 可以直接匯出成 GitHub 專案嗎?目前公開文件沒有描述從已建立的 Site 一鍵匯出至 GitHub 的流程。文件有說明 Sites 可從提示或相容的本機專案開始,因此要區分「把本機專案部署到 Sites」和「把 Site 專案匯出到 GitHub」這兩件事。 Q4:Sites 部署網址是測試站還是正式站?OpenAI 文件將每個部署網址視為 production URL。你可以先儲存版本供檢視,再決定是否部署;分享給使用者前,也要確認權限、資料和預期使用對象。 Q5:把產品重建到 Cloudflare 後,平台限制就消失了嗎?Sites Runtime 的限制不會原封不動跟著搬過去,但 Cloudflare 服務有各自的功能範圍與操作邊界。正式版本也需要你負責 Auth、權限、監控、備份、資料保護與維運。 參考資料 OpenAI:ChatGPT Sites 功能更新與建立數 OpenAI Help Center:建立與管理 ChatGPT Sites OpenAI:ChatGPT Sites 開發文件 Cloudflare:Workers 文件

  • article-Learning OS 是什麼?AI 如何打造專屬自己的個人化學習系統

    2026/8/14

    AI工具 ChatGPT AI自動化 AI Agent
    Learning OS 是什麼?AI 如何打造專屬自己的個人化學習系統

    昨天看到朱騏分享一篇文章,看完之後,我最大的收穫不是 ChatGPT Sites,而是突然想到一件事: AI 正在改變的,也許不是「課程」,而是「學習」本身。 這個想法讓我重新思考,我們未來真正需要的,可能不只是更多內容,而是一套能夠陪著自己持續運作、持續調整的學習系統。 以前我們找課程,未來我們建立課程以前想學一項技能,我們第一個反應通常是: 「有沒有推薦的線上課程?」 於是開始搜尋 YouTube、買課、看書、找部落格。最後收藏了一大堆內容,卻還是不知道: 到底該先學哪一個? 真正缺少的,其實從來不只是知識,而是一條適合自己的學習路徑。 每個人的背景、目標、程度與可投入時間都不一樣。對別人來說很適合的課程順序,未必適合現在的自己;一套設計給大多數人的教材,也不一定能回應每個人的實際問題。 AI 開始把零散知識整理成個人課程朱騏分享了一個很有啟發性的做法:利用 ChatGPT Sites 搭配 AI Agent,替自己建立一套專屬的穿搭課程。 輸入自己的身高、體重、身形特徵、常穿品牌與想改善的地方之後,AI 不只是推薦幾支 YouTube 影片,而是重新整理整個知識架構,依照難度安排順序,將原本散落在網路上的內容,整理成一套真正適合自己的課程。 我覺得,這才是 AI 最有價值的地方之一。 它不只是幫你找到資料,也可以協助你回答幾個更重要的問題: 我現在在哪一個程度? 我真正想解決的是什麼問題? 哪些內容應該先學,哪些可以晚一點再學? 我怎麼知道自己是真的理解,而不是只看過? 當 AI 開始處理這些問題時,它扮演的角色就不再只是搜尋工具,而更接近學習流程的規劃者。 Learning OS 是什麼?我想到的不是 Sites 本身,而是更大的概念:Learning OS(學習作業系統)。 Learning OS 不只是存放影片、文章或筆記的地方,也不只是一份課程清單。它更像是管理整個學習流程的一套個人系統,會把目標、資源、任務、測驗與成果串在一起。 一套理想的 Learning OS,可能包含以下能力: 學習流程 Learning OS 可以協助處理的事情 了解起點 分析目前能力、背景與程度 設定方向 建立符合目標的個人化學習地圖 整理資源 整合 YouTube、書籍、文章與最新資料 安排行動 設計每天或每週的學習任務 檢查理解 透過提問、練習與測驗確認是否真的學會 累積證據 記錄作品、心得與實作成果 持續調整 根據進步、弱點與新目標重新規劃內容 今天你是新手,它可以先協助你建立基礎;三個月後,它知道你已經進步,就能安排進階內容;半年後,它也可以根據你的作品與弱點,重新規劃下一階段的學習方向。 它不是一門上完就結束的課,而是一套會隨著你改變的學習流程。 從線上課程到 Learning OS,差異在哪裡?傳統線上課程通常先設計好內容、順序與進度,再交給一群背景不同的學習者使用。這種方式適合建立共同基礎,但不一定能即時回應每個人的差異。 Learning OS 的重點,則是把客製化從「教材內容」延伸到「學習流程」: 比較面向 傳統線上課程 Learning OS 內容安排 先由課程設計者固定 依照個人目標與程度調整 學習順序 大多數人共用同一條路徑 可以依照弱點與進步重新排序 資源來源 以課程內提供的內容為主 可整合影片、書籍、文章與其他資料 完成標準 看完課程或完成章節 以理解、練習與作品成果為依據 使用期限 課程結束後通常告一段落 持續追蹤並規劃下一階段 這不代表傳統課程沒有價值,而是兩者解決的問題不同:課程提供結構化內容,Learning OS 則試著管理從起點到成果的完整學習循環。 如果你想先建立一個明確的學習起點,也可以參考既有的結構化資源,例如 微軟《Generative AI for Beginners》課程。而當學習目標是 SEO 時,新手學 SEO 完整指南 也呈現了如何把免費資源、AI 工具與階段任務整理成學習地圖。 AI Agent 在 Learning OS 裡扮演什麼角色?AI Agent 最大的價值,不只是回答問題,而是協助執行一連串有前後關係的任務。 放進 Learning OS 裡,它可以成為一位會持續工作的 AI 教練,協助完成以下流程: 先理解學習者的目標、程度與限制。 將零散資料整理成可理解的主題與學習順序。 根據可投入的時間安排每日或每週任務。 用提問、練習或小測驗檢查理解程度。 根據作品、筆記與錯誤紀錄找出弱點。 依照學習成果調整下一階段的內容。 這種工作方式,和單次問答最大的差別在於:它關注的是整段學習流程,而不是某一個當下的答案。 未來真正客製化的,不只是教材,而是學習流程過去的線上課程,只能設計給大部分的人。但每個人的背景、目標與程度都不同。 有人缺理論,需要先補基礎概念;有人缺實作,需要直接做出作品;有人只想解決眼前的一個問題,不需要從頭看完一套完整課程。 AI Agent 的價值,就是能依照每個人的需求,重新建立一套屬於自己的學習流程。真正被客製化的,不再只是教材,而是: 學什麼 先學什麼 用什麼方式學 何時練習 如何驗證理解 下一步要往哪裡走 同樣的概念,也可以應用在不同主題: 想學 AI:從基本概念、工具操作到實作專案。 想學英文:依照程度、使用情境與口說弱點安排練習。 想學攝影:從構圖、曝光到拍攝作品與回饋。 想學健身:依照目標、經驗與可投入時間安排訓練。 想學寫作或簡報:從模仿、練習到作品修正與發布。 每個主題的內容不同,但核心都是同一件事:讓學習從「收藏資料」變成「持續完成任務並產生成果」。 Learning OS 仍然需要人的參與Learning OS 可以協助整理、規劃與追蹤,但知識被整理好,不代表能力就自動建立了。 學習者仍然需要做幾件重要的事: 說清楚自己真正想達成的目標。 真的完成練習,而不是只閱讀學習計畫。 提供作品、筆記或測驗結果,讓系統知道目前狀態。 判斷哪些建議符合自己的情境,必要時修正方向。 AI 可以讓學習流程更容易開始,也能降低整理資源與安排順序的成本;但最後能不能學會,仍然取決於是否持續練習、接受回饋與把知識用出來。 AI 的下一個戰場,也許就是教育我一直認為,AI 真正厲害的地方,不只是回答問題,也不是生成內容,而是幫我們建立一套可以持續運作的系統。 工作有 Workflow,開發有 Coding Workflow,未來學習也會有自己的 Learning Workflow。 想學 AI、英文、攝影、健身、寫作、投資或簡報,都可以建立一套專屬自己的 Learning OS。它會隨著你的程度、作品、弱點與目標變化,持續調整下一步。 未來我們買的可能不是一門「上完就結束」的線上課程,而是一套能陪著自己一起成長的學習作業系統。 最後,也謝謝朱騏分享這篇文章。好的文章,不一定是直接給你答案,而是讓你開始思考更多可能性。 如果你也對這個主題有興趣,可以看看朱騏分享的原文,也許會得到不同的啟發。 常見問答 (FAQ)Q1:Learning OS 和一般線上課程有什麼不同?一般線上課程通常提供固定的內容與學習順序;Learning OS 則把個人目標、程度、學習資源、任務、測驗與成果串在一起,並根據學習進度持續調整路徑。 Q2:建立個人化 Learning OS 需要先提供哪些資訊?至少需要提供學習目標、目前程度、背景、可投入時間、想改善的問題與偏好的學習資源。若能持續提供練習作品、筆記或測驗結果,系統就更容易依照實際進步調整內容。 Q3:AI Agent 可以保證我真的學會嗎?不能。AI Agent 可以協助規劃內容、安排任務、設計問題與追蹤成果,但真正學會仍需要學習者完成練習、接受回饋,並把知識應用在作品或實際問題上。 Q4:Learning OS 適合哪些學習主題?Learning OS 適合有明確目標、需要持續累積能力的主題,例如 AI、英文、攝影、健身、寫作與簡報。只要能定義學習階段、安排練習並留下成果,就有機會建立對應的學習流程。 Q5:Learning OS 會取代老師或線上課程嗎?不一定。線上課程仍然可以提供系統化教材,老師也能提供經驗、示範與深度回饋;Learning OS 比較像是把不同資源與學習行動串起來,協助學習者更有方向地使用課程與內容。