從重複工作中抽身，把決策留給人
活動行銷的日常充滿了「不難但容易出錯」的步驟：複製登陸頁、產生 UTM 連結、寄邀請信、每天整理報名名單、會後上傳 CRM。GitHub 日本與韓國市場的行銷負責人在 GitHub Blog 上分享，這些任務單獨看都不難，但疊加起來就是貼錯連結、漏掉一天、或打錯 campaign 名稱的溫床。
他的解法不是引進一套新的行銷自動化平台，而是把工程師熟悉的 GitHub 原語拿來用：Issue、Labels、Actions。一個活動就是一個 Issue，標籤是觸發開關，Actions 是執行機器。當 event-setup 標籤貼上 Issue，工作流就會在幾分鐘內完成過去要花大半天的事：複製活動頁、產生全組 UTM 連結、把邀請信存成 Word 檔、開立請求 Issue、更新專案看板，最後在 Issue 上留下摘要。
把 runbook 交給 Copilot，用對話保留彈性
自動化的起點不是寫程式，而是寫 runbook。他把團隊的作業手冊放進 repository 根目錄的 AGENTS.md，定義 campaign 命名規則、季度對應日期、各地時區、邀請信格式。接著用 GitHub Copilot 對話：「我想在十一月辦一場關於 AI 輔助開發的網路研討會。」Copilot 會讀取 runbook，參考過去類似活動，提出符合命名規則的 campaign 名稱、草擬兩版邀請信，並問出 runbook 規定的問題。
這個設計刻意把「對話」放在管線最前面。全自動會失去彈性，全人工會出錯；對話剛好卡在中間。Copilot 草擬，人做決定，最後由 Copilot 把正確格式的資料填進 Issue。對照先前討論過的 把測試證據放進開發流程，這裡同樣是把「人該在哪裡介入」當成架構問題，而不是事後補救。
DRY_RUN 開關與平台內建的護欄
他最自豪的設計是一個 repository variable：DRY_RUN。每個工作流在執行前都會檢查這個開關，打開時就只跑流程、不碰任何外部系統——不建立登陸頁、不開 Issue、不分享名單。這讓團隊可以放心排練，也讓實驗不再可怕。
平台內建的護欄比自建的更重要。GitHub 的 secret scanning 與 push protection 會在 API token 被 push 進 repository 之前就擋下來；Copilot 商業方案不保留 prompt、不用來訓練模型，所以遇到一次性資料分析需求時，可以直接在 Copilot 裡做，而不是把客戶資料貼到隔壁分頁的消費級 chatbot。模型選擇也由組織政策決定，不是個人判斷。
用 Markdown 寫 skill，把彈性留給在地市場
會後工作原本是最痛苦的部分：匯出出席者、調整欄位格式、比對公司名稱、寫報告。現在只要兩個 slash command：/lead-upload 和 /event-report。這兩個指令背後是 GitHub Copilot agent skills——每個 skill 就是一個 SKILL.md 檔案，用散文寫成的程序，告訴 Copilot 做什麼、依什麼順序、注意什麼。
「如果你能寫 runbook，你就能寫 skill。」這句話點出了門檻之低。更重要的是，skill 讓系統保持彈性。亞太區每個市場的追蹤流程都不一樣，硬編碼的工作流會強迫所有人套同一個模子；寫在 Markdown 裡的程序可以讓每個市場調整自己的 runbook，不必動到底層機器。新 skill 透過 pull request 合併，並由 CODEOWNERS 指定審核者——行銷自動化也有了審核流程。
從工具到心態：可程式化的入口就夠了
這套做法能成立的前提，不是活動平台或 CRM 有多先進，而是它們提供了「可程式化的入口」：活動平台有 API，CRM 有官方 CLI（甚至不用設定 API key，瀏覽器登入就處理好認證）。只要你的重複性工作經過任何提供 API 或 CLI 的工具，這個模式就適用。
對產品開發者來說，這篇文章示範了一種把「維運」變成「程式碼」的思考方式：不是去買一個號稱能涵蓋所有變化的套裝工具，而是用既有的開發平台，把工作流程的改變變成 pull request。當流程改變時，你描述想要的結果、有人審核、合併到 main branch——和改軟體一模一樣。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。