第一次真正做Codex技能：把「我會做」變成「AI也會做」

前面幾篇筆記，我先認識了 Codex 可能帶來的工作變化，也學會安裝、設定，接著又搞懂智能體背後的 CLI、API、規劃、記憶、反饋與大模型。

到了第四篇，終於正式進入我非常期待的實作：怎麼用 Codex 做出自己的第一個技能？

這堂課一開始，老師先用「重複工作」來解釋技能到底有什麼價值。

例如今天要製作一支影片，工作流程可能是先寫劇本、再做圖、做影片，最後剪輯。如果只做一支，其實人工一步一步做也沒有什麼問題。

但是如果同樣的流程要重複做100次呢？

難道每次都重新告訴 AI：第一步寫劇本、第二步生成圖片、第三步做影片、第四步剪輯？

這時候，「技能」的價值就出現了。

先把整套流程完整跑通一次，再讓 Codex 把這套做事方式整理、封裝成一個可以反覆使用的技能。

以後只要提供新的主題或新的輸入資料，就不需要再重新教一次。

我覺得這也是技能和一般 Prompt 最大的不同。

什麼叫做Codex技能？我把它理解成「AI版SOP」

以前我們在工作上談 SOP，通常是寫給人看的。

例如新人進公司後，只要按照第一步、第二步、第三步執行，就能完成一件固定工作。

但是智能體時代，SOP開始多了一個新的用途：不只可以教人，還可以教AI。

老師在課程裡示範的第一個技能，是「歷史人物內容生成」的流程。

例如輸入李清照、諸葛亮或嬴政的名字，Codex就按照事先教好的方法，自動完成幾項固定工作。

第一，產生一個符合要求的標題。

第二，整理人物的重要生平經歷。

第三，把每一段經歷轉換成較詳細的畫面描述，方便未來繼續拿去生成圖片或影片。

第一次建立這個技能時，老師仍然是一個步驟、一個步驟告訴 Codex 要怎麼做。

但是當流程跑成功之後，就請 Codex：「把剛才這整套流程封裝成一個技能。」

下一次，就不需要再次把所有 Prompt 重寫一遍。

技能真正節省的，不只是時間，而是「重複教AI」的成本

聽到這裡，我其實非常有感。

因為現在使用 AI 工作，我們每天都在重複做一件事：重新告訴AI，我喜歡它怎麼做。

例如寫文章時，我可能每次都要重新說：標題怎麼寫、段落怎麼安排、內容至少多少字、要使用什麼語氣、最後要不要加入 Hashtags。

• • 做短影音也一樣。
  • 影片要幾秒？
  • 分成幾段？
  • 一段多少字？
  • 畫面提示詞怎麼寫？

如果這套做法已經測試很多次，而且每次都差不多，理論上就不應該永遠重新輸入。

技能真正要做的，就是：把已經驗證有效的方法保存下來。

以後只需要改變真正會變動的東西。

例如人物名稱、商品名稱、影片主題、SEO關鍵字或文章網址。

剩下的固定流程，讓 Codex 自己照著做。

建立技能之前，先把三件事情想清楚：輸入、流程、輸出

這堂課我覺得最值得記下來的地方，就是老師一直強調：一個技能一定要知道輸入是什麼、中間怎麼做，以及最後輸出什麼。

我現在會直接把它整理成一個非常簡單的公式：輸入 → 工作流程 → 輸出

第一：輸入是什麼？

輸入，就是使用這個技能時，我要提供給 Codex 的東西。

例如老師這次做的歷史人物技能，輸入就只有一個：人物名字。

但未來不同技能的輸入可能完全不一樣。

• • • 有些技能可能需要一張圖片。
    • 有些可能需要一個商品網址。
    • 有些可能是一份 Excel。
    • 也可能是一支影片、一組關鍵字，甚至是一整個資料夾。

所以建立技能時，第一件事情不是急著想 Prompt，而是先確定：「以後每次使用這個技能時，我到底要給它什麼？」

第二：中間流程怎麼做？

中間流程，就是這個技能真正的 SOP。

例如歷史人物案例裡：

• • • 先根據人物名字產生標題。
    • 接著整理八段重要生平經歷。
    • 再依照每一段經歷產生更詳細的畫面描述。

這就是完整流程。

未來如果技能愈來愈複雜，流程當然也可能更長。

例如先分析資料，再呼叫 API，再建立資料夾，再產生圖片、影片，最後剪輯與輸出。

前面第三篇學到的 CLI、API、規劃，到這裡就開始真正串在一起了。

第三：輸出是什麼？

最後還要定義這個技能執行完之後，到底應該交給我什麼。

課堂案例裡，輸出是標題、生平經歷與畫面描述。

未來也可能是：

• • • 一篇文章。
    • 一份 HTML。
    • 一份 Excel報表。
    • 一批圖片。
    • 一支影片。
    • 或者直接是一個完成的軟體。

輸入、流程、輸出三件事情愈清楚，技能未來執行起來就愈穩定。

建立第一個技能，其實不用自己寫程式

我原本會以為，既然叫做建立 Skill，是不是要先學一大堆程式碼？

結果這堂課的做法反而比我想像中簡單很多。

第一個技能不需要自己硬寫。

老師的方式是先正常跟 Codex 對話。

第一步想怎麼做，就跟它說。

第二步再增加新的要求。

結果不滿意，就繼續修改。

直到整套工作流程真的跑通。

最後再告訴 Codex：「請把我剛才教你的方法，整理成一個技能。」

也就是說，一開始我們真正需要學的並不是「怎麼寫技能文件」，而是：怎麼把自己的工作方法教清楚。

這對一般工作者來說，我覺得非常重要。

我會記住一個原則：先跑通，再封裝

這堂課讓我建立了一個很重要的觀念：不要一開始就急著做技能。

因為如果自己的工作流程都還沒想清楚，直接封裝，只是把一套不成熟的方法固定下來而已。

所以正確的順序應該是：

• • 先測試。
  • 再修改。
  • 再測試。

確定整個流程真的符合自己的需要。

最後才封裝成技能。

我覺得這跟我們以前建立公司的 SOP 完全一樣。

一定是先有人把事情做成功，才把成功的方法整理成標準流程。

技能不是做好就結束，它還可以一直修改

老師在課堂裡另外示範了一件我覺得很重要的事情。

第一次建立技能之後，實際測試時，Codex會先產生幾個標題，再要求使用者自己選一個。

老師覺得這樣太麻煩。

因為如果真正目標是自動化，每次跑到這裡都還要人工選擇，流程就會被打斷。

所以老師直接要求：不要再讓我選標題，直接替我決定一個最好的即可。

Codex接著就把原本的技能修改掉。

這讓我發現，技能並不是建立之後就完全固定。

反而應該邊用邊改。

第一次可能只有60分。

第二次發現問題，再改。

第三次又發現有地方可以少一步，再繼續優化。

技能其實也是一套可以持續進化的SOP。

第二支影片開始拆技能：到底一個Skill裡面放了什麼？

第一支影片主要在教怎麼做出第一個技能。

第二支影片則打開剛才生成的技能資料夾，開始觀察裡面到底有哪些東西。

這一段技術味稍微重一點，但是老師一直提醒：前期不要一次記太多。

先理解最重要的幾個概念就可以。

第一個核心：技能主Markdown檔

每一個技能裡，都會有一個最主要的 Markdown 文件。

課程把它視為技能最重要的入口。

我現在會把它理解成：這個技能的「說明書＋工作規則」。

裡面會寫這個技能的名字、描述、什麼情況使用、使用者需要提供什麼，以及實際執行時應該遵循哪些流程。

對我們一般使用者而言，不需要一開始就研究非常複雜的格式。

先知道它是負責「告訴智能體這個技能到底怎麼使用」即可。

技能名稱重要，但「技能描述」更重要

課堂中特別花了一大段時間講技能描述。

原因是：技能描述不是主要寫給我們看的，而是寫給智能體看的。

例如未來我建立了200個技能。

有SEO技能、Facebook貼文技能、圖片生成技能、短影音技能、商品文案技能、資料分析技能。

當我跟 Codex 說：「幫我處理下一篇SEO文章。」

它怎麼知道200個技能裡應該用哪一個？

其中一個重要判斷依據，就是技能描述。

技能描述比較像摘要，而不是完整說明書

老師用「論文摘要」來比喻，我覺得非常容易理解。

技能描述不應該寫成一大篇文章。

只要簡單讓智能體知道：

• • • 這個技能是做什麼的？
    • 什麼情況適合使用？
    • 大概可以完成什麼工作？

這樣就足夠。

智能體先看每個技能的簡短描述。

確定哪一個技能適合目前任務之後，才去讀那個技能更詳細的內容。

這樣也能避免一次把所有技能的完整內容全部放進上下文，浪費大量記憶空間。

技能正文沒有唯一格式，重點還是「把事情說清楚」

課程裡有提到 Markdown 裡的標題、子標題與不同層級。

但是老師真正強調的不是排版規則。

而是：只要人能看懂、智能體能理解，正文其實可以按照自己的方式設計。

• • 可以寫觸發條件。
  • 可以寫輸入格式。
  • 可以寫輸出格式。
  • 可以寫執行流程。
  • 也可以加入範例。

但是最後還是回到同一件事情：輸入什麼、中間做什麼、輸出什麼。

Markdown是什麼？我暫時把它當成「AI很好讀的筆記格式」

另外特別介紹 Markdown。

例如使用#號建立標題，再用不同數量的#號建立下一層標題。

對沒有程式背景的人而言，一看到 .md 這種副檔名，很容易覺得又要開始學技術。

但是我覺得老師這裡的意思其實很簡單。

Markdown就是一種結構很清楚的文字筆記格式。

人容易閱讀，電腦與 AI 也容易理解。

現階段我根本不需要背很多語法。

只要知道：技能的規則與說明，會透過這類結構化文字保存下來。

這樣已經足夠。

技能變複雜後，會開始需要Scripts

目前課堂示範的第一個技能，主要還是在生成文字。

但是未來如果技能要做更複雜的事情，例如：

• • 生成圖片。
  • 生成影片。
  • 自動剪輯。
  • 整理電腦檔案。
  • 呼叫外部 API。

就會開始需要 Scripts，也就是可以真正執行的腳本。

我會把 Scripts 理解成：技能真正的「執行工具」。

例如程式碼、CLI命令、API呼叫等，都可能透過腳本完成。

技能主檔負責說：「這一步應該做什麼。」

Scripts則負責：「真正把這一步做出來。」

這時我才發現，第三篇學的 CLI 與 API，原來不是單純理論。

到了真正建立技能時，它們就會開始成為技能裡的一部分。

References：讓技能有自己的參考資料

另外一個老師特別提到的部分，是 References。

我會把它理解成：這個技能執行工作時，可以拿來參考的資料庫。

例如歷史人物技能。

如果以前已經做過一個效果很好的成吉思汗案例，就可以把成功的標題、生平內容與畫面描述留下來，作為之後生成其他人物時的參考。

又例如要呼叫一個圖片 API。

這個 API 有哪些尺寸？

支援哪些圖片比例？

有哪些參數可以設定？

這些操作說明，也可以放進 References。

未來技能真正需要使用時，就可以先讀這些資料，再決定怎麼執行。

Skill和Prompt最大的差別，我現在終於比較清楚了

學完這堂課，我現在會用一句話區分 Prompt 和 Skill。

Prompt是在告訴AI：「這一次請你這樣做。」

Skill則是在告訴AI：「以後遇到這類事情，都照這套方法做。」

所以技能保存的並不只是提示詞。

它還可以保存流程、規則、參考資料與執行工具。

換句話說，它保存的開始是：人的工作經驗。

Tina學姐的學習心得：我第一個真正想做的，是SEO技能

雖然老師用的是歷史人物案例，但我一邊聽課，一邊想到的其實全部都是自己的工作。

尤其是 SEO。

因為我現在做 SEO文章優化，本身就已經是一套非常固定的流程。

• • 先看 Search Console。
  • 排除已經完成的網址。
  • 再從剩下的文章裡挑下一篇。
  • 找主要關鍵字。
  • 設定SEO標題與中繼說明。
  • 重寫文章。
  • 加入商品推薦。
  • 加入延伸閱讀。
  • 補內部連結。
  • 最後把這篇記錄成已完成。

以前我只是把它當成自己的工作方法。

但現在看來：這其實就是一個非常適合封裝成技能的完整SOP。

如果未來可以教 Codex 完整跑過一次，再把流程封裝好，也許下一次我只需要告訴它：「開始處理下一篇。」

它就知道自己要先看什麼資料、排除哪些網址、怎麼挑文章，以及最後應該交給我什麼結果。

如果真的能做到，我覺得這就不是單純「AI幫我寫文章」了。

而是我把自己長期累積的工作邏輯，轉換成 AI 可以執行的流程。

未來真正值得累積的，也許是一整套「Tina工作技能庫」

這堂課聽完，我腦袋裡其實已經出現很多可以製作的技能。

• • 咖啡SEO文章優化技能。
  • Dosha Facebook貼文技能。
  • 短影音腳本技能。
  • AI漫劇分鏡技能。
  • 商品頁文案技能。
  • Search Console資料整理技能。
  • 圖片與影片素材分類技能。

這些事情其實我現在本來就會做。

所以未來真正要學的，不是讓 Codex 憑空替我創造工作方法。

而是：怎麼把「我已經知道怎麼做」，轉換成「Codex也知道怎麼做」。

如果一個一個慢慢建立起來，最後累積的就不只是文章、圖片和影片。

而會是一整套屬於自己的 AI 工作技能庫。

Tina學姐的Codex筆記04｜我的結論

第四堂課學完，我覺得自己終於開始碰到 Codex 真正有意思的地方。

前面學 CLI、API、規劃、記憶與反饋，是在理解：智能體為什麼能做事？

而技能這一堂開始變成：我要怎麼把自己的方法教給它？

我現在會把 Skill 記成一句最簡單的話：Skill就是一套被保存、封裝，而且可以反覆使用的工作SOP。

先把工作流程真的跑成功。

• • 把輸入定義清楚。
  • 把中間每一個步驟整理清楚。
  • 把最後輸出定義清楚。
  • 再請 Codex 把這套方法封裝起來。

之後實際使用時，就不需要每一次重新教。而且技能還不是一次做好就不能再碰。

實際使用之後發現哪裡不好，就修改、再測試、再優化。

我現在反而覺得，真正把 AI 用進工作裡，可能不是每天不停追新的 Prompt，也不是看到新的 AI 工具就全部去學。

真正值得累積的，是：把自己已經驗證有效的工作方法，一個一個變成AI可以重複執行的技能。

當 Codex 開始學會你的工作方法，它才真正開始從「一個很厲害的AI工具」，變成「真正屬於你的AI工作助手」。