他把 Fable 5
接成一座
AI 軟體工廠

Every 這支影片不是在炫耀模型又會寫多少程式，而是在展示一條新產線：同事在 Slack 丟回饋，AI 整理、下載錄製檔、開 PR、批次修正，人再用影片、截圖和 CI 驗收。

來源：Every YouTube 頻道

SCROLL
PART 1 ｜ 工廠的起點

他正在重做一個產品，
但影片真正展示的是交付方式

影片主角說自己使用 Fable 5 大約一週，很多以前想做卻做不順的工作突然跑起來。他正在重建 Kora v2，一個會變成完整 inbox 的產品。畫面上看起來是產品開發，背後其實是一套把回饋變成改動的流程。

他沒有把 Fable 5 說成唯一答案，只說這套方法目前對自己有效。它像一座工廠，很多事情會自動跑起來：讀 Slack、整理問題、下載錄製檔、產生 PR，再把一批改動交給模型修。

影片的核心不是「AI 幫我寫功能」。更精確地說，是 AI 開始接住軟體公司最耗注意力的一段流程：從使用者回饋到可審查的產品改動。

這對創業者和產品團隊很重要。當開發速度被模型拉快，瓶頸不再只是誰會寫程式，而是回饋怎麼進來、怎麼被整理、怎麼形成任務、怎麼驗收，最後怎麼讓下一輪更準。

PART 2 ｜ 回饋不是一句抱怨

Slack 裡的訊息、截圖、錄影，
都變成 AI 可以處理的原料

Every 內部有人使用 Kora alpha 版，也會在 Slack 頻道分享回饋。有人丟截圖，有人丟 RFR 錄製檔，有些項目前面會有「正在看」或「已解決」的標記。這些訊號讓回饋不只是聊天紀錄，而是可以被追蹤的工作佇列。

RFR 是他做的一個 React app wrapper。使用者按下錄製後，它會記錄點擊、語音、網路請求和錯誤，停止後產生檔案，再分享到 Slack。這比單純影片更有用，因為模型不只看到畫面，也能看到互動和錯誤脈絡。

Slack
回饋入口
同事把問題、截圖和補充說明丟進同一個頻道。
RFR
行為錄製
記下點擊、語音、請求和錯誤，讓問題可重播。
MCP
資料讀取
排程透過 Slack MCP 抓訊息，判斷哪些需要處理。
PR
任務容器
整理後的回饋會進入 pull request，等待批次修正。

這裡的產品策略不是發明一個更漂亮的回饋表單，而是把回饋做成模型可讀、可重播、可分類的資料。當 AI 能處理更長任務，回饋的品質直接決定產線能不能運轉。

PART 3 ｜ 排程把混亂變成任務

每天早晚掃一次，
把 Slack 裡的訊號整理成 PR

他設定了一個 Claude Cowork 排程，早上和晚上各跑一次，有時也會手動啟動。這個 routine 會讀 Slack 頻道，抓取訊息，用技能分類，檢查哪些已經處理，遇到 RFR 或影片錄製檔就下載下來，讓後續代理人分析。

排程跑完後，系統會留下 YAML 和 Markdown 檔案。YAML 用來記錄哪些項目已報告、哪些還沒報告；Markdown 則描述它理解到的問題、可行的修正、需要人工判斷的地方。這些檔案讓回饋不再散落在聊天紀錄，而是變成可追蹤的工作資料夾。

這座軟體工廠的五個站點
收集Slack 接住回饋
錄製RFR 補上現場
整理排程分類與去重
修正Fable 5 批次處理
驗收人看影片與 CI

關鍵在於中間層。沒有這層整理，Fable 5 只能面對一堆混雜訊息；有了這層整理，模型接到的是一批有脈絡、有附件、有狀態的工作項目。

PART 4 ｜ 批次修，不是逐張票

17 個回饋不開 17 個 PR，
而是合成一批可審查的改動

排程整理出 PR 後，他會到 Cursor 裡要求模型針對 PR 中的每個 Every item 跑 LFG flow。指令很直接：修好所有項目，遇到需要人類輸入的地方留下筆記；如果策略文件已經足夠，模型可以自己做決定。

這裡的變化是批次。逐字稿提到一次在 Slack 找到約 17 個項目。以前如果每個都變成一個 pull request，人要審 17 次，切換成本很高。Fable 5 擅長長時間處理一批相關任務，讓人回來審一個更完整的改動集合。

流程
傳統 issue 處理
Fable 5 工廠模式
回饋入口
使用者各自描述問題，工程師再追問細節。
Slack、截圖、錄製檔和錯誤資訊一起進入同一條線。
任務整理
人手動判斷重複、優先順序和可修範圍。
排程先分類、去重、下載附件，留下 YAML 與 Markdown 紀錄。
修正方式
一張票一個 PR，審查次數增加。
一批相關問題集中修，產生影片、截圖和說明。
人的工作
追需求、補脈絡、寫修正、檢查每個 PR。
檢查分支、看 walkthrough、確認策略和合併風險。

他甚至說自己第一次看到結果時，並不完全知道所有被回報的項目。模型已經修了一批問題，並用 walkthrough 影片展示自己改了什麼。人的工作往審查、取捨和責任移動。

PART 5 ｜ 驗收仍然是人的責任

速度變快之後，
最重要的不是放手，而是看懂結果

修正跑完後，他會 checkout 分支，檢查影片，必要時用 slashf polish 開 server，比對 app 畫面和改動內容。影片和截圖在這裡很關鍵，因為 AI 批次改很多東西，人不能只靠 commit 訊息猜測品質。

他喜歡把項目批次處理，原因是審查量變得可管理。17 個回饋如果拆成 17 個 PR，人的注意力會被切碎；合成一批後，人可以從產品效果、策略一致性和 CI 結果一起判斷。

🎞️
看 walkthrough
模型用影片展示它修了哪些流程，讓人先看產品行為。
🧪
跑 CI
自動測試和建置要過，才有資格進入合併判斷。
🧭
查策略
模型可自行做小決策，但方向和取捨仍要符合產品策略。

這也是軟體工作的分工變化。工程師不一定每一行都自己打，但仍要知道這批改動解決了什麼、留下哪些需要人工判斷、會不會和產品方向衝突。

PART 6 ｜ 隔夜合併的意義

他睡覺時工廠還在跑，
早上同事已經看到產品變好

影片最後的畫面很直接。他晚上啟動流程，告訴系統如果一切看起來沒問題，而且 CI 是綠的，就合併。隔天早上醒來，同事 Brandon 說設計看起來很好、東西變順了。他的感受是，自己睡覺時系統仍在工作。

這不代表可以無條件自動合併所有東西。它代表一個更成熟的方向：AI 不是只在聊天框裡回答，而是在一套有輸入、有紀錄、有驗收、有回饋修正的產線裡運轉。它也會透過 compound step 學到先前犯過的錯，下次不要重複。

能力
只是會寫程式
變成軟體工廠
輸入
一段 prompt 或一張 ticket。
真實使用回饋、錄製檔、錯誤、策略文件和歷史紀錄。
執行
完成單一要求，等人下一步指示。
批次處理一組問題，留下說明與可審查成果。
改進
每次都像重新開始。
把錯誤寫回流程，下一輪避免重複踩坑。

對台灣的新創和科技團隊來說，這支影片的啟發不是立刻追同一套工具，而是先找出自己的回饋斷點。你能不能把使用者看到的問題，變成代理人可以理解、執行、驗收、改進的材料？這件事會比單純購買最強模型更有差異。

AI 軟體工廠的價值，不是讓模型多寫幾行程式碼，而是讓回饋能沿著產線一路走到可合併的改動。

Fable 5 讓長任務變得可行；真正的槓桿來自回饋、脈絡、批次修正和驗收流程被接在一起。

如果你要打造自己的 AI 工廠，
第一站會先改哪裡？

選完之後，分享你的觀點

你的觀點

想看原始示範？

這頁整理自 Every YouTube 頻道。原始影片展示了 Slack alpha 回饋、RFR 錄製檔、Claude Cowork 排程、Cursor 裡的 LFG flow、walkthrough 影片和隔夜合併流程。

前往 YouTube →
本頁整理自 Every YouTube 頻道影片〈How I Built an AI Software Factory With Fable 5〉。來源：YouTube。