OpenAI onepage/ AI Coding Workflow
Matt Pocock · YouTube · 17:17
mattpocock/skills：把 AI Coding 變成可交接的工作流程
這支教學的核心不是「叫 agent 寫程式」，而是先把模糊需求透過訪談、規格與小 ticket 拆成可檢查的工作，再讓實作與 review 有清楚的交接點。
Published: 2026-07-16Video ID: M6mYodf0dJMSource: Matt Pocock
01 / 先準備
先建立共用起點
影片從安裝與設定 skills repo 開始。重點在於讓專案有一組可重複使用的流程入口，而不是每一次都從零開始發明 prompt。
02 / 再釐清
用訪談取代猜規格
「grill with docs」階段將已有文件與提問結合，逼近真正問題、邊界與取捨；這是避免 agent 很快寫出錯誤方向的前置工作。
03 / 後執行
規格、tickets、實作與 review
先把決策沉澱成 spec，再拆成可完成、可驗收的 tickets。實作完成後仍要 review，讓速度不以放棄驗證為代價。
Key signals
影片給 AI coding 的四個流程訊號
Input
Docs + 問題
先讀已有脈絡，再以訪談補足未知；不要把需求空白直接交給實作。
Artifact
Spec
規格是人與 agent 都能回看的決策記錄，而不是一次性的聊天內容。
Unit
Ticket
小而明確的任務讓執行、驗收與重新取 context 都有邊界。
Gate
Review
產出程式碼不等於完成工作；review 仍是品質與意圖的檢查點。
Workflow
把「幫我做功能」拆成一條可回看的路徑
01
建立環境與共用慣例
先做設定，讓不同任務沿用相同的工作語言與起始點。這降低每次換 agent、換對話或換人時重新對齊的成本。
02
訪談需求，並用文件校準
把問題問深：使用者真正想解決什麼？哪些既有約束不可碰？成功的樣子是什麼？文件提供事實，訪談補出選擇。
03
將決策寫成 spec，再拆為 tickets
規格先固定範圍與驗收條件；ticket 再把它切成可獨立推進的單位。這也讓每輪執行可以用較乾淨的 context 回到同一份目標。
04
實作後讓 review 成為關卡
review 不只找語法錯誤，也確認實作有沒有偏離 spec、是否留下維護風險，以及下一張 ticket 的假設是否仍成立。
Practical reading
這套流程為何比一次塞進長 prompt 更可靠
把隱性理解變成可檢查文件需求訪談與 spec 讓人可以反駁、補充與確認假設；這比只在聊天脈絡裡「感覺講過了」更可追溯。
讓任務有適當粒度ticket 不是待辦清單的裝飾，而是把工作切到足以實作、驗收與交接的尺度，降低一次做太多造成的偏航。
讓 context 重置有依據當每個任務能回到同一份規格與明確驗收條件，換一次對話不必等於重新理解整個專案。
保留人類的審查責任agent 可以生成與修改，工程師仍應掌握產品意圖、架構取捨、測試證據與可維護性。
Takeaways
可以立刻帶走的四個做法
先問「驗收是什麼」在開始實作前，寫下可觀察的成功條件；它會反過來決定 spec 與 ticket 的邊界。
把研究與實作分開交付先讓 agent 協助釐清現況與選項，再進入修改；不要把未知的設計決策藏在一個「直接做完」的任務裡。
每張 ticket 都附回到規格的連結讓任務在新 context 下仍能找到目標、限制與驗收條件，避免靠記憶補全上下文。
把 review 當作流程，不是補救預先安排檢查規格符合度、測試與變更影響，才能把 AI 的速度轉化為可靠交付。
Timeline
17 分鐘影片的閱讀路線
介紹 workflow 與目標從「完整 AI coding workflow」切題，說明這是端到端流程，而非單一工具示範。
安裝 skills repo先建立可重用的工作起點與設定。
設定與準備把工具與專案流程放到可以開始工作的狀態。
從 Ask Matt 開始以提問協助理解工作入口與需求脈絡。
主 workflow進入從需求探索到交付的核心路徑。
Grill with docs 訪談結合文件與追問，將模糊的需求變得可描述。
建立 specs 與 tickets把決策與工作單位寫下來，形成可交接工件。
實作與 code review以 review 作為品質與方向的最後關卡。
References