AI 生成圖片自動排程發布至 Instagram 與 Facebook：完整工作流程

一、規劃目標與建議邊界

本方案的目標，是把你目前已經產生的 AI 圖片，整理成可重複執行的社群內容流程：先匯入與分類素材，再產生 Instagram 與 Facebook 文案，經過人工審核後排入發布時間，最後由發布服務送到指定帳號，並將貼文網址、平台編號、錯誤訊息與成效資料回寫到內容資料表。第一階段建議採用「AI 協助產製、人工最後核准、系統自動發布」，不要一開始就讓系統完全無人審核地公開發文。

以下規劃假設你要發布的是自己的 AI 生成圖片，主要格式為直式 9:16，目標帳號是 Instagram 專業帳號與 Facebook 粉絲專頁。Instagram 的發布 API 僅適用於專業帳號，也就是 Business 或 Creator；若採用 Facebook Login 路徑，Instagram 專業帳號必須連結 Facebook Page，且授權使用者需要具備該 Page 的相應內容管理權限。3

重要原則： Manus 負責理解資料、產生文案、整理素材與協助審核；真正固定時間的發布，應交由已授權的 Meta 發布服務或穩定的後端排程器執行。這樣可以避免把每一次單純的定時發布都變成一次完整的 AI 工作階段，也比較容易處理重試、重複發布與錯誤通知。

二、兩種可行的落地方式

你可以依照技術能力、是否需要內容日曆，以及願意投入的設定時間，選擇下列其中一種方式。第一種適合先快速上線；第二種適合長期經營多個系列、帳號或品牌。

建議的決策方式是先用第一種方案驗證內容節奏與審核規則，累積兩至四週的實際資料；當你需要多個品牌、多人協作、內容日曆、成效回收或自訂規則時，再升級成第二種方案。無論選哪一種，Instagram 與 Facebook 的帳號授權都應採用官方 OAuth 或官方合作服務，不應把個人密碼交給自製腳本。

三、整體系統架構

完整流程可以拆成六個區塊：素材庫、內容資料表、AI 產製、人工審核、排程發布、結果與成效回收。資料的核心不是圖片檔本身，而是「每一張圖片對應哪一則內容、要發布在哪個平台、何時發布、目前處於哪個狀態」。

AI 圖片／品牌素材
        ↓
素材庫與內容資料表
        ↓
Manus：分類、產生文案、ALT 文字、標籤與發布建議
        ↓
人工檢查：人物、版權、文字、品牌語氣、AI 揭露、平台尺寸
        ↓
核准後進入排程佇列
        ↓
Instagram 發布服務 ─────┐
                         ├─ 發布結果、網址、平台 ID、錯誤狀態
Facebook Page 發布服務 ─┘
        ↓
通知、重試、成效回收與每週報告

對於你目前的 9:16 AI 圖片，最重要的前置處理是保留原圖，另外建立平台版本。Meta 官方文件指出，Instagram 單張圖片發布使用 JPEG，檔案上限為 8 MB，圖片比例須介於 4:5 至 1.91:1，寬度需介於 320 至 1440 像素，並使用 sRGB 色彩空間。1 因此，9:16 原圖比較適合保留給 Story 或 Reel 封面；若要做 Instagram 一般 Feed 單圖，應另做 4:5 版本，避免重要人物或文字被裁切。

四、Manus 專案畫面各區的設定方式

1. 「指令」：寫入長期固定規則

「指令」適合放跨所有任務都不應改變的工作規則，例如社群語氣、品牌名稱、圖片使用原則、審核門檻與輸出格式。不要把某一天的活動文案、單一圖片的描述或一次性的發布日期寫在這裡；那些內容應放在內容資料表或當次任務中。

可使用下列內容作為社群小編的長期指令範本：

你是品牌的 AI 社群小編。只使用「文件和資源」中標記為 approved 的圖片、品牌資料與活動資訊，不得自行捏造產品價格、日期、地點、優惠、人物身份或合作關係。每則內容先產生草稿，不得直接公開發布；必須等到 approved=true 才能進入排程。Instagram 與 Facebook 的文案分別輸出，Instagram 偏精簡、具畫面感並附 ALT 文字，Facebook 補充較完整的故事與行動邀請。每則貼文都要說明是否為 AI 生成內容，遇到人物肖像、未確認版權、未確認品牌合作、敏感議題或資訊不一致時，標記 NEEDS_HUMAN_REVIEW。發布後回寫平台、排程時間、成功狀態、貼文網址、平台 ID 和錯誤訊息。不可重複發布同一個 idempotency_key 的內容。

2. 「連接器」：只連接真正需要發布的服務

連接器的設定重點不是「越多越好」，而是只開啟目前流程需要的服務，並採最小權限。如果使用第三方社群排程服務，通常只需要連接該排程服務，再由它完成 Meta 授權；如果直接使用 Meta API，則需要 Meta App、Instagram 專業帳號、Facebook Page 與相應權限。

Instagram 官方內容發布流程需要先建立 media container，再透過 media_publish 發布；媒體檔案必須在發布嘗試時位於公開可存取的伺服器。官方文件列出的核心端點包括建立 /media container、查詢 container 狀態、發布 /media_publish，以及檢查內容發布限制。2 Facebook Page 則可透過 Pages API 建立 Page 貼文或照片貼文；照片發布使用 Page 的 /photos 端點，並提供公開圖片 URL。4

若使用自有 Meta App，Instagram 官方文件目前列出的權限會依登入方式不同而變化；Facebook Login 路徑常見的發布相關權限包括 instagram_basic、instagram_content_publish、pages_read_engagement，而 Page 發布則需要 Pages API 所列的內容管理權限。3 實際申請前應依 Meta 當時的權限頁面與應用程式設定再次核對，不要直接複製過時的範例。

3. 「文件和資源」：建立可被查找的內容資料庫

這個區域應放入可重複使用、且會影響所有社群內容的資料，例如 AI 圖片、品牌標誌、色彩規範、人物肖像授權紀錄、文案語氣、常用標籤、禁用詞、活動資料與內容日曆。圖片檔名要穩定，避免使用手機自動產生的模糊檔名。

建議資料夾結構如下：

social_content/
├── 00_brand_guide/
│   ├── tone_of_voice.md
│   ├── hashtag_policy.md
│   └── visual_rules.md
├── 01_original_assets/
│   ├── rainbow_sky_surf_01.png
│   ├── light_shadow_focus_01.png
│   └── ...
├── 02_platform_derivatives/
│   ├── instagram_feed/
│   ├── instagram_story/
│   └── facebook/
├── 03_content_calendar/
│   └── content_calendar.csv
└── 04_approval_records/
    └── approval_log.csv

4. 「技能」：放置重複流程，不放置一次性指令

可把「AI 圖片社群貼文產製流程」整理成一份可重複使用的工作規格，例如：讀取內容資料表、檢查圖片比例、產生兩種平台文案、產生 ALT 文字、檢查禁用詞、輸出待審核內容。不要把特定日期、單一活動或某一張圖片的臨時要求固定在可重複流程裡，否則後續容易誤用。

5. 「網站」：需要內容日曆時才建立

如果只是每週發布數篇內容，可以先用資料表管理，不一定要建立專用網站；如果未來要管理多個系列、多人協作、審核紀錄、平台狀態、失敗重試與成效圖表，才值得建立一個簡單的內容日曆與審核介面。網站介面至少應有日曆、素材預覽、平台切換、文案編輯、核准／退回、發布狀態與錯誤詳情。

6. 「定時任務」：安排產製與發布，而不是取代審核

建議把定時任務分成兩個節奏。第一個是「內容準備任務」，例如每週一上午產生未來七天的候選貼文；第二個是「發布任務」，在已核准內容的排程時間執行發布。若系統只能設定一個重複任務，優先把它用在低頻率的內容準備，並讓外部社群排程服務處理精確發布。

排程資料應固定使用台北時區與明確的 ISO 8601 時間，例如 2026-09-01T10:00:00+08:00，不要只寫「明天早上」。每一筆排程都要包含平台、帳號、素材 URL、文案、AI 揭露欄位、排程時間、審核者、狀態與唯一鍵。Facebook Page API 的官方文件指出，若以 API 排程 Page 貼文，發布時間需位於 API 請求後 10 分鐘至 30 天之間，並以 published=false 搭配 scheduled_publish_time 傳入。4

五、內容資料表設計

內容資料表是整個自動化系統的核心。建議先用 Google Sheets、CSV 或資料庫實作，欄位名稱保持固定，讓 Manus、排程服務與發布後端都能使用相同的資料。

建議採用下列狀態機，任何內容都不得直接從 draft 跳到 published：

DRAFT → REVIEW → APPROVED → SCHEDULED → PUBLISHING → PUBLISHED
                  ↓                       ↓
               REJECTED                FAILED → RETRY

六、每日實際運作流程

步驟一：匯入與分類圖片

把 AI 圖片上傳至原始素材資料夾，立即產生穩定的 content_id。依系列、日期、主題與平台版本建立檔案名；不要把同一張圖片複製成多個沒有關聯的檔案。若圖片中包含真人，尤其是兒童，先確認你擁有適當的使用同意與公開發布權限，再讓素材進入 approved 素材庫。

步驟二：建立平台衍生版本

先保留原始 PNG，再輸出 Instagram Feed、Instagram Story／Reel 封面與 Facebook 版本。Instagram 單張圖片發布需要公開 URL、JPEG、sRGB、符合尺寸與比例限制；因此在發布前必須進行格式、大小、比例、色彩空間與 URL 可讀性檢查。2 如果原圖是 9:16，不要直接硬塞到 Feed；應另外產生 4:5 版本，並以人工預覽確認人物臉部、簽名、相框與其他重要元素沒有被裁切。

步驟三：由 Manus 產生文案與 ALT 文字

每張圖片建議同時產生兩個版本的文案。Instagram 文案著重畫面氛圍、短句與互動問題；Facebook 文案則可以增加創作背景、系列故事與較完整的行動邀請。ALT 文字只描述圖片中真正可見的內容，不要加入沒有出現在畫面裡的品牌、人物或商品資訊。

可以要求 Manus 固定輸出以下欄位：

{
  "content_id": "rainbow_sky_20260901_01",
  "caption_ig": "Instagram 草稿",
  "caption_fb": "Facebook 草稿",
  "alt_text": "一名女孩在彩虹星星形成的天空河流上衝浪，旁邊有一隻彩色小馬，遠方可見彩虹瀑布與天空城堡。",
  "hashtags": ["#AI藝術", "#奇幻攝影", "#彩虹天空"],
  "is_ai_generated": true,
  "review_flags": [],
  "approval_status": "review"
}

Instagram 官方文件列出圖片、影片或輪播 caption 的上限為 2200 字元，最多 30 個 hashtags 與 20 個 @ tags；輪播最多 10 個媒體項目。1 實務上建議文案遠低於上限，以免在不同客戶端預覽時過於冗長。

步驟四：人工審核

審核者至少要檢查五件事：人物身份與臉部是否被錯置、畫面文字與簽名是否正確、圖片裁切是否安全、文案是否有捏造資訊，以及 AI 生成內容是否依品牌政策揭露。若圖片使用真實人物照片作為生成基礎，還要確認公開發布的授權範圍；若涉及兒童肖像，建議把「是否可以公開發布」設定為必填核准欄位。

審核結果只允許三種：approved、rejected、needs_edit。只有 approved 且 scheduled_at 已填寫的內容，才可以進入發布佇列。

步驟五：提前預檢

在發布前 15 至 30 分鐘執行預檢。系統應確認圖片 URL 可以從公開網路取得、HTTP 回應正常、Content-Type 正確、檔案大小符合平台限制、圖片為 sRGB、文案未超過限制、內容尚未發布，以及 idempotency_key 尚未成功使用。

Instagram 的標準流程是先建立 media container，再等待媒體可發布，最後呼叫 media_publish；官方文件也列出 FINISHED、IN_PROGRESS、ERROR、EXPIRED 等狀態，並建議在影片處理期間約每分鐘查詢一次、最多查詢五分鐘。2 對單張圖片而言，也應保留 container ID 與最終 media ID，以便排查問題。

步驟六：分平台發布

Instagram 端應使用平台適用的衍生圖片與 is_ai_generated=true 欄位；如果是單圖，建立單一 image container；如果是輪播，先建立最多 10 個子媒體 container，再建立 carousel container。Facebook Page 端可使用 Page 的照片發布端點傳送圖片 URL，或使用 Page feed 端點建立文字／連結貼文；若使用 Facebook API 內建排程，要遵守官方文件所列的 10 分鐘至 30 天時間範圍。4

Instagram 與 Facebook 的貼文不要只依賴「同時發布」的畫面效果，應分別記錄兩個平台的結果。Instagram 成功但 Facebook 失敗時，狀態應是 partial_success，而不是整筆內容標記為成功；這樣才能只重試失敗的平台，避免產生重複貼文。

步驟七：通知與回寫

成功發布後，系統應回寫 platform_post_id、permalink、實際發布時間、發布平台與內容版本。失敗時要回寫錯誤類型、錯誤訊息、重試次數與下一次重試時間，並通知負責人。通知內容不要包含 Access Token、完整私人 URL 或其他敏感資料。

七、錯誤處理與重試規則

自動化流程最容易出錯的地方，不是文案生成，而是授權過期、媒體 URL 不可讀、圖片格式錯誤、容器處理中、排程重複與部分成功。每類錯誤應有不同處理方式，不能全部無限重試。

Instagram 官方內容發布文件說明，帳號有 API 發布數量限制，且建議應用程式自行管理發布速率，尤其是允許未來排程的系統。2 因此，內容資料表應加入每日發布計數與平台限制檢查，不要等 API 回錯才處理。

八、建議的第一版設定

第一版不要同時自動處理所有內容類型。建議先只做「Instagram Feed 單圖 + Facebook Page 單圖」，每週 3 至 5 則，每則都必須人工核准；Story、Reel、輪播與自動留言可以放到第二階段。

九、四週導入計畫

第一週先整理素材與規則。完成原始圖、平台衍生圖、品牌語氣、禁用詞、ALT 文字格式、AI 揭露規則與內容資料表，並選出 10 至 20 張圖片作為測試集。

第二週建立人工審核與預覽流程。讓 Manus 只產生草稿，不連接公開發布；審核者確認人物、文字、尺寸、文案與標籤後，手動把狀態改為 approved。

第三週接入發布服務，先用測試帳號或低風險時段發布。測試單圖成功、圖片 URL 失效、權限失效、重複排程、平台部分成功與人工取消等情境。

第四週才開啟固定排程與成效回收。每週檢查成功率、失敗類型、平均處理時間、最常被退回的文案問題與不同主題的互動表現，再調整發布時間與內容比例。

十、上線前檢查清單

十一、最終建議

最穩妥的第一階段是：在 Manus 專案中建立固定社群小編指令，將 AI 圖片與品牌資料放進文件和資源，使用內容資料表保存每筆貼文，再連接一個可正式授權 Instagram 與 Facebook Page 的發布服務。Manus 只負責產生文案、ALT 文字、標籤與審核旗標；人工確認後，發布服務按照 scheduled_at 執行，成功或失敗再回寫資料表。

若未來需要多品牌、多帳號、團隊審核、自訂報表或更精密的重試邏輯，再改成自有發布後端，直接依 Meta 官方文件處理 Instagram container、media_publish、Facebook Page /photos 或 /feed 流程。這樣能保留最大的控制權，但也必須自行承擔 OAuth、權限審查、公開媒體 URL、Token 更新、錯誤監控與維護工作。

References