你的 AI 工作流程正在運作中。
你只是不知道它三天前就停止正常運作了。
它還在執行。還在燒 API 額度。還在產出沒有人看的內容。你花了兩個週末建置的 Agent，正在以每堆垃圾 0.40 美元的成本製造垃圾——而你直到某個週二客戶截圖傳給你才會發現。
這不是運氣差。這是預設結果。
存下這篇。你會讀兩遍的。
30 天的墳場
每週，數百位創辦人建立 AI 工作流程，然後發到 Twitter 上。
展示看起來很順。貼文得到很多讚。回覆說「這是未來」。
三十天後，那個工作流程就死了。
不是被刪除。不是被取代。是死了但還在跑。持續扣款。產出毫無用處。創辦人已經轉移注意力。Agent 沒收到通知。
今天建立的 AI 工作流程，有 90% 無法撐過上線後的第一個月。不是因為模型差。不是因為點子錯。而是因為建置者犯了三個註定失敗的錯誤——而在他們上線之前，沒有人告訴他們那些錯誤是什麼。
這就是那篇文章。
為什麼它們會死
這是工作流程死亡的解剖結構。永遠是同樣的順序。
第 1 天：你建立它。它在示範中完美運作。你覺得自己解鎖了什麼。
第 3 天：它還在運作。你開始沒那麼仔細檢查了。
第 9 天：有些事情變了。API 回應格式稍微改變。某個它讀取的來源被封在登入牆後面。模型對某個邊界案例的解讀和第一天不一樣了。輸出悄悄地劣化。沒有人注意到。
第 14 天：工作流程現在產出的東西技術上算是一份回應，但實質上毫無用處。它還在跑。你還在付錢。
第 23 天：某個客戶或同事提到有點不對勁。你調查。發現了 12 天的錯誤輸出，你本來以為它會處理好的。
第 30 天：你殺掉它。你告訴自己 AI 還不夠成熟。然後繼續前進。
模型沒有讓你失望。是你的建置方式辜負了模型。
讓那 10% 與眾不同的 3 條規則
那些工作流程撐過 30 天、90 天、一年的創辦人——他們並不更聰明。他們沒有更好的提示詞。他們用大家都忽略的三條規則來建置。
規則 1——沒有職位描述，就沒有 Agent
大多數人用一種模糊的感覺來建置 Agent。
「幫我做內容。」「監控競爭對手。」「處理客戶郵件。」
那不是職位描述。那是個願望。而願望撐不過週末。
一份職位描述包含五個部分：
它監控什麼。特定的觸發條件或排程。「每週一早上 7 點」或「每次有新的 GitHub issue 被打上 bug 標籤」或「每次有來自不在聯絡人名單中的網域的郵件到達」。不是「有時候」或「相關時」。
它讀取什麼。確切的來源。不是「檢查網路」。「從這三個 RSS 來源、這個 Airtable 基礎、以及這個 Slack 頻道過去 7 天的內容中提取。」明確、有邊界、沒有模糊地帶。
它產出什麼。確切的輸出格式。不是「一份摘要」。「一份三部分簡報：一句話的標題發現、三個支援要點（各附一個來源）、一個建議行動。少於 300 字。放在這個 Google 文件中。」
它不做什麼。護欄。「未經人工核准，絕不發送外部郵件。」「絕不修改正式資料庫。」「絕不直接發布。一律先存為草稿。」那些你認為理所當然的事，就是會燒到你的地方。
你如何知道它成功了。成功條件。「如果簡報為空，傳送 Slack 訊息給我說『找不到相關更新』。不要傳送空白的簡報。」
模糊的感覺撐不過週末。職位描述才會。
從今天起你建立的每一個工作流程，都從一份職位描述開始。不是提示詞。是職位描述。
規則 2——無聲失敗才是唯一能殺死你的失敗
大聲的失敗沒問題。大聲的失敗會送出錯誤。它們會停止工作流程。它們會叫醒你。你會修好它們。
無聲失敗才是真正會毀掉事業的那種。
無聲失敗看起來像是成功。工作流程在跑。輸出送到了。格式正確。但內容錯了——一開始一點點，然後越來越多，到最後完全錯了——而且因為它看起來沒錯，所以沒人檢查。
以下是無聲失敗在實際運作中發生的方式：
你的內容 Agent 寫了 30 篇文章。你設定它自動排程那些在你的內部評分標準中超過 80 分的文章。那個評分標準是在你前 20 篇文章時校準的。到了第 15 天，模型開始用不同的方式解讀你的評分標準。分數 82 的文章現在以你的真實標準來說其實很普通。但它們還是發出去了。你的互動率下降。你怪演算法。
你的研究 Agent 每週送一份簡報。到了第 11 天，它讀取的其中一個來源改了網址結構。Agent 默默地讀取失敗。它用較舊的快取資料填補缺口，而且沒有標示這個缺口。你讀了一份基於過時資訊的簡報，然後根據它做了決策。
你的收件匣分類 Agent 草擬回覆。到了第 8 天，它開始把某種類型的郵件歸類為低優先級，因為寄件者的名字符合它訓練資料中的某個模式。你錯過了來自一位新客戶的三封重要郵件，而那位客戶剛好和一份你從沒讀過的電子報同姓。
在每個案例中：工作流程都有執行。沒有拋出任何錯誤。但你還是輸了。
解決方案是強制輸出驗證。每個 Agent 都需要三樣東西：
一個金絲雀輸出。每個輸出中都有一個容易驗證且難以偽造的欄位。它最近一次讀取來源的時間戳記。它處理過的項目數量。一個信心分數。某個你可以在兩秒鐘內瞄一眼就知道 Agent 確實有做事的東西。
一個無聲失敗警報。如果 Agent 沒有產出任何東西，或者產出低於某個門檻，它不會送出空白的輸出。它會送你一個警報。「這個週期沒有找到結果——這是我檢查過的內容，以及我可能什麼都沒找到的原因。」什麼都沒有永遠比一個看似合理但實則空洞的結果更有用。
一個每週抽檢。每週每個 Agent 選一個輸出。完整讀一遍。和你自己會寫的東西比較一下。這只需要四分鐘。它能在偏離變成失敗之前抓住偏離。
Agent 不會大聲失敗。要為那種安靜的故障做準備。
規則 3——你的筆電不是基礎設施
這就是 90% 的建置者會陣亡的地方。
他們在本機建置。示範沒問題。他們發了 Twitter 文章。有人問這是不是在正式環境中運作。他們說對。但他們的意思是：它正在他們的 MacBook 上跑，而 MacBook 現在是開著的，放在他們公寓的桌上，連著家裡的 WiFi，而且會在星期四他們闔上蓋子去機場的時候停止運作。
你的筆電不是基礎設施。它只是一個開發環境，碰巧現在在跑一些重要的東西。
以下是筆電代管的 Agent 會發生的事：
macOS 在凌晨 4 點推送更新。機器重新啟動。Agent 停了。沒人知道，直到星期一。
你在飛機上闔上蓋子。六個小時的工作流程錯過。收件匣分類 Agent 沒有分類。錯誤搜尋 Agent 沒有搜尋。站立會議 Agent 什麼也沒送。
你家裡的 WiFi 斷了二十分鐘。Agent 重試。失敗。繼續。沒有記錄任何東西。它應該要抓住的那個時間窗口已經消失了。
你去度假。筆電留在家裡。所有東西都留在家裡。
真正的基礎設施在你沒看的時候也會運作。它在你睡覺、在飛機上、在吃飯、週末聯絡不到的時候也會運作。它不需要你把蓋子開著。
規則很簡單：如果工作流程需要執行超過一次，而且你無法承受它漏掉一個週期，那它就不能住在你的筆電上。
真正可行的三種基礎設施選項：
一台裝有程序管理器的 VPS。一台每月 12 美元的伺服器，執行 PM2 或 Supervisor。你的 Agent 以受管理的程序執行。如果它當機，PM2 會自動重新啟動它。如果伺服器重新開機，PM2 會在開機時啟動它。便宜、可靠、不花俏、有效。
一個受管理的 Agent 平台。專為此設計。處理重啟、監控、警報。比 VPS 貴。但省下你週末除錯程序為何當機的時間。一旦你的 Agent 開始產生真正的價值，就值得了。
無伺服器搭配排程器。由 EventBridge 或 Cloud Scheduler 觸發的 AWS Lambda 或 Google Cloud Functions。不需要管理任何基礎設施。按執行次數付費。沒有在跑的時候縮小到零。最適合以固定排程（而非持續）執行的 Agent。
這些都不複雜。全部只需要十五分鐘的設定。每一個都能讓你免於凌晨 4 點 macOS 更新殺掉你的 Agent、毀掉你的星期一早晨。
闔上筆電。Agent 應該繼續跑。
能夠存活的工作流程
以下是當三條規則都應用時，一個能撐 90 天的工作流程長什麼樣子。
職位描述：每週一早上 7 點，讀取這 5 個競爭對手帳號和這 3 份業界電子報過去 7 天的文章。提取任何產品公告、價格變動、或互動超過 500 的內容。與上週的簡報比較。標記任何新東西。輸出三部分簡報：什麼變了、什麼正在獲得關注、他們留下了什麼缺口。如果沒有找到變化，送出警報：「安靜的一週——已檢查以下內容。」傳送到這個 Notion 頁面並發送 Slack 通知。
金絲雀輸出：每份簡報都包含：「已檢查來源：8。已處理項目：[N]。最新項目時間戳記：[timestamp]。」如果 N 是 0 或時間戳記超過 8 天，它會送出警報而不是簡報。
基礎設施：在每月 12 美元的 VPS 上執行。PM2 管理程序。如果當機，30 秒內重新啟動。每週五花 3 分鐘檢查日誌。
抽檢：每週五完整讀取一份簡報。花 4 分鐘。六個月內抓到了兩次偏離。
這個工作流程已經跑了六個月。它錯過了兩個週期——兩次都送出警報說明原因。它從來沒有無聲失敗過。
這就是一個能存活的工作流程和一個在第 9 天就死掉的工作流程之間的差別。
讓人不舒服的真相
大多數人讀到這裡會點頭，然後用和上次一樣的方式建立他們的下一個 Agent。
一個提示詞。一個展示。一篇 Twitter 文章。三十天的沉默。一個沒人正式終止的死亡工作流程。
這三條規則並不複雜。一份職位描述只要二十分鐘就能寫完。輸出驗證只需要一個欄位和一個條件判斷。基礎設施只要十五分鐘就能設定好。
差距不在知識。差距在於你是在上線前就做這些，還是等工作流程失敗後再做。
每一個你沒有職位描述就建立的 Agent，都是你將來要重做的 Agent。每一個沒有輸出驗證的 Agent，都是會無聲失敗的 Agent。每一個在你筆電上的 Agent，都是你下次闔上蓋子就會死的 Agent。
一次就把它們建對。它們就會永遠跑下去。
追蹤 @sairahul1 以獲得更多關於建立能在現實世界存活下來的 AI 工作流程的完整手冊。
TL;DR
90% 的 AI 工作流程在 30 天內死亡。永遠是同樣的三個原因。
規則 1——沒有職位描述，就沒有 Agent。模糊的感覺撐不過週末。定義它監控什麼、讀取什麼、產出什麼、避免什麼，以及你如何知道它成功。在你寫任何一個提示詞之前。
規則 2——無聲失敗才是唯一能殺死你的失敗。大聲的失敗沒問題。無聲失敗看起來像成功，直到客戶發現它。在每個 Agent 中建立一個金絲雀輸出、一個無聲失敗警報、和一個每週抽檢。
規則 3——你的筆電不是基礎設施。它只在蓋子打開時運作。真正的 Agent 在你睡覺、在飛機上、週末聯絡不到的時候也會運作。VPS、受管理平台、或無伺服器。選一個。在上線之前設定好。
能存活的 Agent 並不更聰明。它們只是被正確地建立。
