Day 5｜我的 AI 工作流：從一句需求，到網站與文章草稿

前面幾篇聊了個人網站的架構、後端和成本。這篇分享我怎麼跟 AI 一起做事：從提出需求、討論方向，到實際動手，最後把成果存下來。

整個流程：

提出需求 → Brainstorming 釐清需求與方案 → 確認完成條件 → 用 goal 執行與檢查 → 保存成果 → 我接手驗收。

項目	工作流
AI 模型	理解需求、分析資料、產生內容與決定下一步
Harness	模型外圍的執行系統，管理對話脈絡、工具互動、權限與執行流程
Superpowers brainstorming	釐清需求、討論方案，形成可確認的設計
Codex / Claude goal	追蹤目標，執行後檢查是否需要繼續
專案文件與 skill	提供工作規則、格式和交付方式
CLI 等工具	實際讀取、修改或保存資料
Studio	集中放置文章草稿，讓我閱讀與編輯

AI 呼叫工具、拿到結果、再決定下一步，靠的都是 Harness 這層執行系統。OpenAI 對 Harness 的說明

一、提出需求：方向是在對話裡慢慢確定的

這篇文章本身就是例子。我原本想寫 Supabase MCP，後來補充要談 AI 怎麼查資料、我怎麼同意修改，再改成從編輯文章的角度切入。最後決定把這個題目留到第十天，第五天改成分享工作流。

需求很少一次就說完整。我負責說明這次想完成什麼，再陸續補上限制：從哪個角度切入、排在哪一天、先存成草稿。AI 要跟上這些調整，知道哪些決定已經改了，接著處理同一份稿件。

二、Brainstorming：先把問題講清楚

碰到需要先討論的任務，我會用 Superpowers 的 brainstorming。它會先了解現有專案和我的目的，透過提問釐清需求，再討論方案與取捨。比較大的任務，它會把決定整理成規格，讓我確認後再往下做。

這個階段我要確認三件事：這次要解決什麼問題、哪些事情要做，以及做到什麼程度才算完成。以文章為例，就是確定寫的是網站長文還是社群草稿、保存到哪裡，以及是否包含發布。

三、規則寫在文件裡，不用每次重講

我的網站專案裡有 AGENTS.md 和 CLAUDE.md 記錄工作規則，畫面設計放在 DESIGN.md。例如改介面前要先讀設計規格，手機版另有檢查要求。AI 改功能時就有依據，我也能直接改文件，把之後要遵守的決定留下來。

寫文章則有 Studio 寫作 skill，規定公開內容怎麼整理、各平台有哪些格式限制、草稿送到哪裡。文章還會經過一次中文潤飾，刪掉重複和空話，保留我原本的意思。

分工很簡單：專案規則管網站怎麼做，寫作規則管文章怎麼交付，這次具體要做什麼，由對話決定。

四、用 goal 推進，並且自己檢查

方向和完成條件確認後，我用 /goal 推進需要持續處理的任務。

Goal 會主動檢查目標達成了沒有，還沒完成、也還有可行的下一步，就繼續做。

碰到預算上限、使用者中斷，或需要外部協助的阻礙時，也可能停下來。所以設定 goal 時，要寫清楚預期成果、驗證方式和工作範圍。（Codex Goals 官方說明）

以文章草稿為例，完成條件可以這樣寫：

把確認過的大綱整理成繁體中文文章，保存到指定的 Studio 草稿，重新讀取並確認正文一致。維持待審狀態，不發布；如果無法保存，交代卡住的原因並保留稿件。

成果放哪裡、怎麼確認存對了、哪些操作不在範圍內，都要寫清楚，AI 才有依據判斷自己做完了沒有。網站功能也一樣，可以用操作流程、測試結果和實際畫面當完成條件。

執行時，AI 透過工具讀檔、改程式、跑指令。Studio 另外有一套 CLI，可以查詢文章、讀取版本，再把整理好的文字送進待審佇列。

五、保存與驗收：「說寫好了」不等於「存好了」

工具回報完成後，還得檢查結果。程式修改要跑對應的測試，畫面調整要看實際呈現，文章則要確認正文有存進去、平台沒選錯、仍然是待審草稿。

這就是我把 Studio 做進個人網站的原因。對話用來討論方向，稿件則有固定的位置可以繼續處理。同一個主題可以有網站版和社群版，各自保留內容和狀態。