Factory Automations 是甚麼？用自然語言讓 Droid 代理自動跑重複工作

工程團隊的時間，很多時候不是花在寫新功能，而是花在「又來了」的工作上：追 pull request、查 CI 失敗、跑安全掃描、隨功能上線更新文件。Factory 在 9 月 30 日把 Automations 正式推出，讓你把這些反覆出現的流程，交給 Droid 代理按時間或事件自動執行。這篇解釋 Factory Automations 是甚麼，以及它怎麼替你把「回頭再做」變成「交給它做」。

Factory Automations 是甚麼

Factory Automations 是 Factory 平台上的自動化功能，讓使用者用自然語言描述一個反覆出現的工作流，然後選擇時間表或事件觸發，由 Droid 執行到指定的結果。這套 Factory Automations 功能的核心，就是把自然語言自動化帶進日常開發流程。

Factory 本身是做軟件開發代理的公司，它的 Factory Droid 代理能跨整個軟件開發生命週期工作。Automations 把這些代理從「你叫它做」升級成「它自己按規則做」，而且已經有不少企業客戶在組織內部署。這種以 AI 軟件開發代理為核心的自動化，正是它跟一般排程工具的差別。

每個 Factory 自動化工作流由四部分組成：觸發方式（時間表、Slack、GitHub 或 webhook）、指令（提示詞或範本）、模型（任選模型與推理等級），以及執行機器（你自己的機器或 Droid 的電腦）。模型與推理等級可以逐個設定，日常摘要用便宜模型、關鍵任務用強模型，成本與能力自己拿捏。

Factory Automations 怎麼建立

建立流程比設定傳統 CI 簡單得多，重點是描述而不是配置。

選擇 Create with Droid，用自然語言描述工作流與想要的結果，Droid 會主動問你缺漏的細節，然後建立自動化。這套 Factory Automations 用法也能從既有工作階段延伸，例如你在週末剛分析過錯誤記錄，直接說「把這份分析改成每週一早上九點跑一次」就行。

不想從零寫的人，可以用 Automations Marketplace，裡面有熱門用例的預填設定，包括 Code Review、Security Audit、PR Babysitter 等。挑一個接近的範本改幾句，比全部自己來快很多。這就是自然語言 自動化 最實際的好處：你不必先學會一套配置語法，才能讓工作跑起來。

如果你卡在怎麼描述，一個好用的做法是把「輸入是什麼、做完要長什麼樣、出事時找誰」三件事寫進指令，然後先跑一次看結果，再逐句收緊。用自然語言 自動化 寫流程，跟寫一封清楚的交辦訊息其實是同一件事。

Factory Automations 常見用法

官方端出的用例，幾乎都是工程團隊每天都在做的雜事。

• Ticket to PR：Droid 從 Linear 或 Jira 拿取準備好的工單，實作變更並開 pull request 待審
• Code Review 與 Fixer：代理審查 pull request 並在 PR 上留下發現，再用 Review Comment Fixer 依要求補上 commit
• Security Audit：排程的 GitHub Actions 每週審核一個倉庫，對照程式碼檢查潛在安全問題並回報
• PR Babysitter：檢查未合併 pull request 的 CI 失敗並著手修正，搭配 CI Failure Triage 把失敗管線分類為不穩定、基礎設施或回歸
• Morning brief：早上用一則私人 Slack 訊息，彙整需要你注意的討論串、pull request 與工單
• 本週發佈了甚麼：自訂自動化把一週內合併的 pull request 整理成 Slack 摘要，還能用圖像生成配一張自訂梗圖

其他範本包含把可執行的 Slack 訊息轉成 Linear 工單、調查事故警報、同步會議記錄與行動項目，或在程式碼變更時更新文件。

自選模型與執行機器是甚麼意思

這是 Automations 跟一般 CI 腳本最大的差別。

模型與推理等級由使用者逐個自動化設定。你可以讓每日摘要用較低成本的模型處理，把能力與預算花在真正需要判斷的任務上。執行機器也能選：跑在你自己的機器上，或交給 Droid 的電腦。這種彈性讓同一個平台同時應付輕量例行與重量級分析。

自動化可以以你的身分或服務帳號執行，權限範圍自己決定。對需要把關的團隊，這比讓代理拿到全權限更安全。

誰適合用 Factory Automations

如果你的團隊每天都要重複回答「這條 CI 為什麼紅了」「這張單誰在處理」，Automations 就有用。

適合的場景有三種。第一種是純排程的例行工作，例如每天早上彙整待處理的工單。第二種是事件驅動的反應，例如 PR 一開就自動跑審查。第三種是跨工具的搬運，例如把 Slack 上可執行的訊息變成 Linear 工單。這三類的共同點是規則明確、重複發生、不需要每次重新判斷。

不適合的，是只有一次、或每次條件都不同的任務。這種事描述規則的時間，可能比直接做還久。

Factory Automations 的限制與注意事項

它省的是重複勞動，不是判斷責任。

自動化按你給的指令與觸發方式跑，指令寫得含糊，產出就會含糊，所以描述工作流時要把想要的結果講清楚。代理會動用倉庫與工具權限，權限範圍與敏感資料的存取值得先設好界線。另外，自動化取代的是流程執行，最終的審查與合併決定，仍然需要人來做。

如果你期待它自動搞定一切，會失望。它的價值在於把定義明確、反覆出現的工作穩定執行，讓你專注在需要思考的部分。

Factory Automations 對開發團隊的價值

一句話：把又來了的那些工作，從你的待辦清單移到排程器裡。

當 pull request 追蹤、CI 失敗調查、每週安全掃描、文件同步這些事有了固定觸發與固定流程，團隊的注意力就能集中在真正需要人腦的地方。實際的差別是心力的分配：過去工程師得記住十件「等下要做」的瑣事，現在這些事自己按時跑完，人只要看結果。

想實際試用的話，可以到 Factory 官方網站下載並安裝 Droid，註冊一個工作區、連接你的倉庫，從一個最常重複的流程開始：描述它、設好觸發，看看一週後你能省下多少切換工作的時間。安裝後先在單一倉庫小範圍試跑，確認權限邊界沒問題，再推廣到整個團隊，這樣最穩。

權限與資料安全值得多花一點心思。讓代理碰生產環境之前，先想清楚它該讀哪些倉庫、能不能寫入、會不會接觸客戶資料，把範圍收在必要的最小集合，這是部署這類自動化時最基本的把關。

Factory Automations 是甚麼？它是讓代理按規則自己跑起來的那一層，補上了「叫它做」與「它持續做」之間的缺口。

想動手的人，可以先到 Factory 官網取得試用帳號，連接你的倉庫，從一個最常重複的流程開始。動手前記得檢查權限範圍與敏感資料的存取設定，先設好界線再放手讓代理執行。