摘要： GitHub 日本與韓國行銷負責人分享一套行銷維運流程：一場活動對應一個 Issue，貼上 event-setup 標籤就由 Actions 產生活動頁、UTM 連結、邀請信與看板更新。DRY_RUN 變數讓所有工作流先空跑演練，不觸及外部系統；Copilot skill 則是可經 pull request 審核的 Markdown 程序。整個模式要求活動平台與 CRM 都提供 API 或 CLI。
從重複工作中抽身，把決策留給人
活動行銷每天要處理的雜事，單項都算不上困難，卻很容易出錯——複製登陸頁、產生 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 開關與平台內建的護欄
在他眼中最得意的設計，是一個名為 DRY_RUN 的 repository variable。每個工作流在動工前都會先檢查這個開關；一旦開啟，流程只會空跑一輪，完全不觸及外部系統——不會建立登陸頁、不會開 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——整個過程和修改軟體沒有兩樣。