如果 PM 準備好產品規格書、wireframe，
甚至設計稿，AI 能不能接著拆任務、分工開發，
把產品逐步做出來？
這是我最近在做的實驗。
我先規劃工作藍圖，建立八個 AI 角色，
再替它們做一間像素虛擬辦公室。
我可以看看誰在工作、產品做到哪裡。
需要我看設計、做決定或驗收時，畫面就提醒我，
我再看成果、給意見，接著往下做。
讓 PM 的產品規劃，接得上開發
PM，也就是產品或專案經理，
會整理需求、安排功能與優先順序。
我希望 PM 規劃好產品後，
能操作這套 AI 開發流程，
依需求增加角色、調整分工與工作步驟，
讓虛擬團隊把規劃做成可用的產品。
我想透過這個實驗驗證：
PM 能不能不必另外找工程師接手，
也能用這套流程，完成規劃的產品？
規格書說明產品功能與完成標準；
wireframe 是線稿，
交代畫面有哪些內容、怎麼安排；
設計稿則畫出顏色、字型與元件。
我希望把這些資料交進去後，
AI 能先檢查缺漏、整理各角色的材料，
再拆解工作、分派任務，接著實作、測試與審查。
我仍然要決定產品方向、確認設計，
最後看過成果。
流程裡能接著完成的工作，
則由 AI 自己往下推進。
第一個試跑題目是我的產品首頁。
從規格一路推進到可驗收成品，
是我想持續驗證的目標。
PM操作流程：提供資料、設定團隊與流程、看成果並給回饋。
Loop Engineering：讓工作接著走
這種安排可以用 Loop Engineering
（迴圈工程）來理解：先定目標與完成條件，
讓 AI 執行、檢查結果、調整做法，再繼續下一輪，
直到達標或遇到需要人處理的問題。
IBM 的〈What Is Loop Engineering?〉
把這個概念整理得很清楚：
流程包含「目標、行動、觀察、調整」四個步驟。
開發者的工作，也會轉向設計一套系統，
由系統提示、檢查與引導 AI。[1]
參與 Claude Code 開發的 Addy Osmani，
也在〈Loop Engineering〉中談到：
把分派工作、檢查成果、記錄進度與決定下一步，
放進一套系統。[2]
他的文章還引述 Claude Code 負責人
Boris Cherny 的說法：
他的工作逐漸轉向設計驅動 AI 的迴圈。
這裡引用的是 Addy 的文章轉述。[2]
我把這個方向用在自己的產品開發上：
先把團隊怎麼合作規劃好，
再讓它們接手一件具體的工作。
規劃藍圖：技能、模型與個性
派工人員分派工作；介面示範。
我先設定八個角色：
專案經理、規格整理員、設計師、前端與後端工程師，
以及測試工程師、檢查員、設計審查員。
每個角色要知道職責與修改範圍，
遇到問題向誰回報，以及做到什麼程度才能交出去。
技能是寫成檔案的工作方法與規範。
例如設計師、前端工程師和設計審查員，
讀同一份設計規範，讓設計、實作與驗收有共同依據。
模型也依工作配置。
這次藍圖中，後端工程師使用 Sonnet，
前端、設計、測試和審查等角色使用 Opus；
專案經理沿用主對話的模型。
這是目前的安排，之後還要觀察品質與 AI 用量。
我也替角色設定個性與工作態度。
例如專案經理要專業、有品味，先想清楚為什麼，
看到更簡單的做法就提出來，
並把卡住的地方直接說清楚。
共同的工作原則則是：
先想清楚再動手、越簡單越好，
只改必要的地方，先定好完成條件。
這些設定會影響它們怎麼提出建議、處理問題和回報。
做、測、查分開，沒通過就退回修改
設計師與測試工程師走去白板認領；介面示範。
工作進來後，規格整理員先對照規格書與線稿，
列出矛盾、缺漏和需要我決定的事情。
專案經理再訂目標、拆任務，
寫下測試情境與預期結果。
我看過拆法之後，工作才開始。
新的線稿先確認架構，設計稿改到我滿意，
前端才進場；後端可獨立做的部分，與設計並行。
測試工程師依案例寫好自動化測試，
工程師實作，再由測試工程師跑測試、檢查員審查。
有畫面的工作，還要由設計審查員對照定稿檢查。
沒通過就退回修改。
測試結果與審查回報都要留下來，
才算這一段完成。
反覆修改到上限仍沒過，就停下來告訴我卡在哪裡。
實作、測試、審查與調整：未通過就退回修改。
產品首頁試跑時，
檢查員抓到一個不會報錯的問題：
更新紀錄遇到壞掉的標題時，
會把下一則紀錄悄悄併進上一則。
這一段共修了五輪才通過。
設計審查也挑出中文詞被拆成兩行、動畫沒動，
以及日文替代文字與圖片不符。
這些紀錄讓我看見，驗收條件需要寫到哪些細節。
加點遊戲感，像大家一起做產品
角色交回成果並微笑；介面示範。
流程開始運作後，我想把它畫出來。
於是，我替它們做了一間像素辦公室，
加一點遊戲趣味，讓進度更容易掌握。
每個角色有自己的樣子和座位。
工作時背後冒出光焰，頭上顯示正在處理的事情；
角色接到任務就走去白板認領，完成後再交回。
需要我核准時，腳下亮起紅色虛線，
黑貓 ZERO 跳上經理桌，陪著一起等。
辦公室裡也有一些小動畫：
泡咖啡、滑手機和趴著睡。
這些是我加的生活感，寵物也是裝飾。
看著它們忙碌，像小隊在做任務，
獨自開發，也有大家一起的感覺。
這個辦公室已接上我自己的
Claude Code 開發事件紀錄，
能呈現角色工作、交回、出錯和等待我核准的狀態。
辦公室在我的電腦上運作，
事件紀錄也只保存在這台電腦。
本文搭配的 45 秒影片與截圖，
是用來展示介面的示範情境，
展示派工、認領、交回與等待核准。
下一步：驗證從規格到成品能走多遠
這套流程目前還在試跑。
我已看到分工審查抓出的具體問題，
接下來要看它能否穩定交付，
以及多出的協調與 AI 用量是否划算。
IBM 與 Addy 的文章也都提醒，
迴圈仍然需要人把關。[1][2]
對我來說，PM 要把需求、取捨與驗收標準說清楚，
也要理解交回來的成果，
才能決定產品是否符合原本的目的。
接下來，我想驗證這套流程能不能讓 PM
從提供資料，進一步掌握開發過程。
產品需要什麼角色、工作怎麼安排，都能依需求調整，
再看過成果、給出回饋。
讓產品想法，從規劃走到可以使用，
是我想和這群虛擬員工一起完成的事。
如果你也有一間 AI 辦公室，
最想先交給它哪一項產品工作？
等這輪實驗告一段落，我會再寫一篇心得，
分享實際跑起來的結果，
哪些安排有用、哪些還需要調整。
參考來源
[1] IBM｜What Is Loop Engineering?（2026-07-17）
https://www.ibm.com/think/topics/loop-engineering
[2] Addy Osmani｜Loop Engineering（2026-06-07）
https://addyosmani.com/blog/loop-engineering/
