07人在迴圈中
AI DEVELOPMENT WORKFLOW
一套由人保有判斷與責任的 AI 協作流程；不是完成的方法論，而是邊做邊整理的學習記錄。
2025 - 2026
HOW I WORK WITH AI
AI 不是另一個作品，而是幫助我思考、實作與驗證的工具。方向與最後判斷仍由自己負責。
方法迴圈
- 01DIRECTION
定義方向與範圍
- 02PLAN
確認邊界與分工
- 03BUILD
小步實作
- 04REVIEW
以不同觀點審查
- 05VERIFY
親手操作與確認
- 06DECISION
決定採用或退回修改
小修改直接做、直接確認。複雜的工作先定好範圍，再把實作和檢查分開。AI 說完成了，我還是會親手操作、看過畫面，再決定是否採用。
Agent 分工、Context、Review、Visual QA 與失敗經驗，完整記錄於 Journal。
閱讀開發筆記01
我怎麼一路用到現在
一開始只是拿 AI 翻譯日文、修句子，後來拿來寫程式、做課題，也試了本機模型。做的東西變大後，我才發現：光描述想法還不夠，得先把規格和分工寫清楚。
演化
- 01LANGUAGE TOOL
翻譯・修文
從日文翻譯與文句修正開始。
- 02CODING ASSISTANT
Coding / SQL
延伸到 Coding、SQL 與課題，從 Tab Completion 與修改請求開始。
- 03VIBE CODING
描述即實作
速度快，但 Context 一長就失控。
- 04LOCAL AI
本機實驗
從 VLM、OCR 與量化中理解資源取捨。
- 05SPEC / AGENT
參與的設計
以 Spec 與多 Agent 拆分工作。
工具會一直換，留下來的是參與的設計。
展開完整開發筆記
我仍在學習開發的途中。因此使用 AI 不是為了裝成經驗豐富的人，而是把不懂的地方問清楚、把實作切小來試，再由自己確認結果。
最早只是翻譯日文與修正文句的工具。後來延伸到 Coding、SQL、課題與小型專案：從 Tab Completion 開始，接著問問題、請 AI 修改程式。
Cursor 讓「描述想法 → AI 直接實作」變得自然，我用這種方式做過很多課題。但專案變大、Context 拉長之後，前面的需求被忘掉、做好的東西被重新改壞、功能重複、不同實作互相干擾。這是 Vibe Coding 的極限。
之後接觸本機 LLM、VLM 與 OCR，直接理解算力、Context、量化、速度、穩定性與成本之間的取捨。像 NOTERA 這類專題，也讓 AI 從「幫我寫」變成產品功能本身的一部分。
再往後開始嘗試 Spec Kit、Superpowers 這類規劃方式，以及把工作拆給不同 Agent 的開發方式。複雜專案會拆分工作；範圍明確的小任務則用輕量流程。現在在意的不是工具數量，而是怎麼設計 AI 的參與方式。
02
先把模糊想法聊清楚
想到新功能時，我通常先和 AI 聊：要解決什麼問題？有沒有更簡單的做法？哪些地方我還不懂？把這些弄清楚，再決定要不要做。
01
模糊的想法
只有方向，需求還沒定型。
02
讓 AI 提問
讓 AI 提問，我回答。
03
反覆討論
把使用情境與限制說出來。
04
整理成需求
把需求、Scope、技術方向與 UI 定下來。
05
第二意見
交給另一個模型，找出盲點。
06
確定方向
把共識方向交給 Demo 與設計規則。
模糊的想法讓 AI 提問
先從提問開始。
讓 AI 提問反覆討論
提問與回答往返。
反覆討論整理成需求
把說清楚的限制變成需求。
整理成需求第二意見
把定案的方案交給另一個視角。
第二意見確定方向
把盲點帶回來，再定方向。
展開完整開發筆記
我不會在想到的瞬間就讓 Coding Agent 開始寫。先在 Chat 模式長時間討論：讓 AI 不斷提問，我回答，逐漸把需求、使用情境、Scope、技術方向與 UI 想清楚。這是一種類似 Brainstorm 的往返。
重要專案會把整理後的方案交給另一個 AI 看，取得 Second Opinion。目的不是投票，而是用不同模型找出自己沒想到的地方。UI 與視覺方向則先用圖像生成做出感覺，不對就改，接近方向後再做 Demo。
03
把討論變成 Agent 能遵守的邊界
討論清楚後，我會把需求、設計和不能改的範圍寫進文件。下一輪 Agent 接手時，就能接著做，不必重新猜整個專案。
權威文件
01PLAN
計畫
先寫下 Plan / Implementation Plan。
02AGENTS.md
作業約定
把 Agent 要遵守的規則放在一處。
03DESIGN.md
視覺權威
把視覺判斷固定成文件。
04SCOPE
不可修改範圍
先決定不做什麼、不改什麼。
05EVIDENCE
已確認的前提
留下已確認的需求與驗證紀錄。
06GIT
變更的邊界
先決定 branch 與 commit 的單位。
展開完整開發筆記
現在重要專案會先把討論結果整理成正式的開發 Authority：Plan / Implementation Plan、AGENTS.md、DESIGN.md、Scope 與不可修改範圍、已確認的需求與驗證紀錄、Git branch / commit 邊界。
這些文件不是為了讓 Prompt 變長，而是避免每一輪 Agent 都重新猜一次「現在到底要做什麼」。Agent 可以自由實作，但自由度應該存在於已經確認的邊界裡。
04
小任務不用啟動整支隊伍
小 Bug 或單一修改，直接處理、確認就好。跨模組或重要的設計變更，才需要更完整的計畫、分工和審查。流程要跟工作大小一起調整。
| 小型 / 明確任務 | 複雜 / 重要專案 |
|---|---|
| 單一修改、小 Bug | 新專案、跨模組變更 |
| 輕量流程、快速確認 | Brainstorm / Spec / Multi-Agent / Review / 驗證的完整流程 |
| Context 足夠完成任務即可 | 不無差別全給，依階段切出邊界 |
展開完整開發筆記
小 Bug、單一修改、邊界很明確的工作，直接用輕量流程快速處理。這種工作若還啟動完整流程、載入大量 Repository Context，不只流程變重，也消耗大量 Token。
只有新專案、跨多個模組、重要 UI、架構調整或風險較高的修改——Complex 且重要的工作——才使用完整流程。原則是：More context is not always better context。Context 應該足夠完成任務，而不是把整個專案、歷史討論與所有文件無差別塞給每個 Agent。
05
AI 是手，也可以一起想
我會讓 AI 幫忙找方法、實作和檢查，但需求、優先順序和最後採不採用，還是自己決定。遇到不熟的寫法，會請它解釋，再回到實際功能確認。
責任分配
01
AI
THINK WITH ME：一起思考，找出盲點。 BUILD FOR ME：實作、Debug、Refactor、Test、Documentation。 REVIEW WITH ME：架構、Code、Visual QA、Regression、整理驗證紀錄。
02
人
DEFINE：定義問題與範圍。 DECIDE：決定採用、退回或整合。 DIRECT：指示優先順序與方向。 VERIFY：驗收最後的結果。
報價單 AI 開項 — 建立工項的輸入畫面。
展開完整開發筆記
在我的工作流程裡，AI 大致有三種角色。THINK WITH ME：Brainstorm、Research、Second Opinion、找盲點。BUILD FOR ME：Coding、Debug、Refactor、Test、Documentation、Implementation。REVIEW WITH ME：Architecture Review、Code Review、Visual QA、Regression Check、整理驗證紀錄。
人則負責 DEFINE → DECIDE → DIRECT → VERIFY。所謂 Human as PM，並不是人完全不碰技術，而是人的價值逐漸往需求理解、架構判斷、Scope、優先順序與驗收移動。
06
不讓同一個 AI 包辦所有判斷
重要的修改，我不只讓寫程式的 Agent 自己檢查，也會交給另一個 Agent 看。多一個視角不保證正確，但比較容易找出同一段對話裡沒注意到的問題。
獨立審查
- 01PLAN
計畫
先決定範圍與分工。
- 02BUILD
實作
分擔的角色推進實作。
- 03INDEPENDENT REVIEW
以另一視角審查
由不同 Context 的 Agent 審查。
- 04FIX
退回並修正
把指摘退回實作修改。
- 05VERIFY
重新驗證
修正後再確認一次。
把寫的人與審查的人分開。
展開完整開發筆記
複雜專案中，我會把不同工作拆開：不同模型負責自己比較擅長的部分，例如 Implementation、複雜 Debug、UI、Visual QA 或 Review。更重要的是：Implementer 不應該是唯一的 Reviewer。An independent review from another context keeps one judgment source from deciding everything。
有時會在架構討論完成後，再讓另一個模型看一次；開發完成後再交給不同 Agent 檢查架構、變更範圍與驗證紀錄。這不是因為多一個 AI 就一定比較正確，而是避免所有判斷都來自同一條 Context。
07
讓 AI 看到正確的東西
審查畫面就給設計、改過的檔案和截圖；查功能就加上測試結果。資料不是越多越好，重點是讓 Agent 看到這次工作真正需要的內容。
有限脈絡
01
提供的資料
DESIGN PLAN CHANGED FILES TEST RESULTS SCREENSHOTS
02
不提供的資料
整個 Repository 的掃描 全部歷史討論 無關的服務連接
展開完整開發筆記
而是能更明確控制 AI 到底看到了什麼。例如 Review 任務，我可以只提供 DESIGN、PLAN、CHANGED FILES、TEST RESULTS、SCREENSHOTS，而不是讓 Reviewer 自己掃完整個 Repository。
這樣比較容易控制 Scope，也能知道 Review 的結論到底建立在哪些資料上。加入無關資訊，除了浪費 Token，也可能把舊需求與現在的 Authority 混在一起。
08
我已經不會逐行看所有 AI Code
我不會假裝每一行 AI 產生的程式都看過。我的做法是先跑檢查，再理解整體架構、親手操作功能，重要變更多找一個視角檢查。有問題就回去修。
審查順序
- 01AGENT CHECKS
先讓 Agent 跑
LSP、Tests、Typecheck、Build 與既有審查。
- 02STRUCTURE
看整體架構
檢查多餘檔案、重複功能與合理性。
- 03EXPLAIN
請 AI 濃縮說明
請它說明用了什麼架構與寫法。
- 04OPERATE
實際操作
親手操作功能與 UI。
- 05FIX
退回修正
把問題退回 Agent，修正後重新驗證。
- 06INDEPENDENT
交由另一個 AI 確認
只有重要變更，才用獨立視角確認。
展開完整開發筆記
我的 Review 偏向：先讓 Agent 自己跑 LSP、Tests、Typecheck、Build 與既有審查流程；檢查整體架構是否合理、是否出現多餘檔案或重複功能；請 AI 用濃縮方式說明用了什麼架構、哪些寫法；實際操作功能與 UI；有問題就回到 Agent 修改，再重新驗證；重要變更再透過其他 AI 做 Independent Review。
我不是用「我看過每一行」來建立信心，而是用架構理解 + 自動檢查 + 實際操作 + 多來源 Review 來判斷結果。
09
PASS 要有可以看到的依據
一句『完成』還不夠。後端要看測試和實際回應，畫面要打開來看，手機功能要走過真正的操作流程。檢查方式要能回答：它到底有沒有做好？
確認記錄
01
依任務所需的確認方式
LSP、Tests、Typecheck、Build、Diff、Changed Files、Screenshots、Device Test、Review。
02
畫面截圖與實機結果的檢查方式
畫面要直接查看實際 Pixel，實機結果則由人親自走過流程確認。
展開完整開發筆記
不同任務需要不同的驗證依據：LSP、TESTS、TYPECHECK、BUILD、DIFF、CHANGED FILES、SCREENSHOTS、DEVICE TEST、REVIEW。Backend、Frontend、設定修改與 Mobile App 的驗證方式本來就不同。
UI 就算 Build 與 Test 全綠，也不代表畫面符合設計；Mobile 功能也不能只看 Widget Test，還是需要在實機上走一次真正的流程。工程結果不能只靠相信 AI，而要留下足以判斷的驗證紀錄。
10
Pixel PASS 仍然不是 Human PASS
測試全綠，也可能是一個不好讀的畫面。我會直接看截圖，再開頁面檢查字級、間距、圖片和手機版。最後的設計判斷，還是得由自己來。
最後，自己確認再決定。
- 01BUILD
實作
先完成這次範圍內的修改。
- 02SCREENSHOT
取得實際畫面
桌面、平板與手機都打開來看。
- 03REVIEW
另一個視角
把真正的截圖交給 AI 檢查。
- 04HUMAN
自己做判斷
確認好不好讀、是否符合想法。
- 05VERIFY
採用或再修改
不合適就回去改，再看一次。
案件管理 — 回看案件與狀態。
展開完整開發筆記
AI 可以檢查 Screenshot、Spacing、Typography、Responsive，也可以回報 Visual QA PASS。但只要我自己打開頁面後覺得整體方向不對，這個 PASS 就不能取代我的判斷。
另一個很重要的經驗是：Visual Reviewer 必須真的拿到圖片 Pixel。如果它只讀到檔名、路徑、Manifest 或文字描述，就不能把結果當成真正的視覺驗收。所以流程最後仍然是 IMPLEMENT → SCREENSHOT → AI VISUAL QA → HUMAN REVIEW → ACCEPT / REVISE。
11
我從失控的 Context 學到什麼
最困擾我的不是 AI 寫不出來，而是它忘了前面的決定，又把做好的地方改掉。後來我把規格、修改範圍和版本記錄寫清楚，讓每次修正都知道從哪裡開始。
失敗 → 學習
變更前
- PROMPT
- GENERATE
- FIX
- GENERATE
- FIX
變更後
- DEFINE
- PLAN
- BOUNDED BUILD
- REVIEW
- EVIDENCE
- DECIDE
先把邊界定下來，失敗就成為退回的訊號。
展開完整開發筆記
早期開發時，長 Context 斷掉之後，Agent 可能忘記前面已經確認的方向，把做好的東西重新改掉；不同輪次也可能做出功能重複或互相干擾的實作。
後來加入 Plan、AGENTS.md、DESIGN.md、Git、Scope Boundary、Independent Review 與新的驗證紀錄後，整體開發穩定很多。流程也從 PROMPT → GENERATE → FIX → GENERATE → FIX，慢慢走向 DEFINE → PLAN → BOUNDED BUILD → REVIEW → EVIDENCE → DECIDE。
12
我持續實驗，但不把它神化
本機模型是我一直有興趣的實驗。實際跑過才知道，顯示記憶體、量化和上下文長度都會影響速度與穩定性。複雜開發目前仍以雲端為主，本機則繼續拿來研究。
本機定位
持續實驗，但複雜開發現階段仍以雲端為主。
- 本機讓資料留在自己的環境、成本容易控制，也適合實驗。
- 模型能力不是唯一變數：VRAM、量化、Context、速度與穩定性都會左右體驗。
- 不斷定當前配置或機型。
展開完整開發筆記
我用本機的 VLM、OCR 與 Coding Harness 實際跑過開發工作。這些實驗讓我更直接理解：模型能力不是唯一變數，VRAM、量化、Context 長度、推理速度、穩定性與電腦資源都會直接影響實際體驗。
本機模型的優點是資料可以留在自己的環境、使用成本容易控制，也很適合實驗；但現階段大型與複雜專案，我仍主要使用雲端模型。Local AI 對我比較像持續研究與實驗的平台，而不是宣稱所有東西都必須 Local-first。
13
從 Vibe Coding 到 AI-assisted Engineering
小想法可以和 AI 快速試；專案變大，就要把問題、範圍、分工和驗收做清楚。我還在學，但越是 AI 幫忙完成的部分，越需要自己理解、操作和判斷。
自問
01DEFINED
問題有沒有被定義清楚
不是方向，而是被寫成一個問題嗎。
02BOUNDARY
知不知道什麼不能碰
Scope 與不可修改範圍是否共享。
03CONTEXT
Context 是不是正確的
舊需求與現在的 Authority 有沒有混在一起。
04SOURCE
是不是同一個判斷來源
寫的人與 Review 的人是否分開。
05EVIDENCE
有沒有 Test、Screenshot、Device
是否只停在 Build 與 Test。
06HUMAN
人有沒有真的看過結果
有沒有把 PASS 當成人的判斷。
人在迴圈中
- 01DEFINE
定義
由人決定問題、方向與邊界。
- 02PLAN
計畫
先把範圍與分工定下來。
- 03BUILD
實作
分擔的角色推進實作。
- 04REVIEW
驗證
從另一個 Context 確認，留下可核對的記錄。
- 05HUMAN
人的判斷
決定採用、退回或整合，並交給下一階段。
展開完整開發筆記
正因為還在學習途中，越是交給 AI 的部分，越要自己看過一次。比起把完成的事情說得很大，我更在意留下下一次能修正的形狀。
小型 Prototype、快速實驗、突然想到的新功能，本來就很適合直接和 AI 一起快速做出來。這也是我最早大量接觸 AI Coding 的方式。
但專案一旦變大，我越來越在意的不是「Prompt 寫得多厲害」，而是：問題有沒有被定義清楚？AI 知不知道什麼不能碰？Context 是不是正確的？寫的人與 Review 的人是不是同一個判斷來源？最後有沒有 Test、Screenshot、Device 等可核對的結果？人有沒有真的看過最後結果？
所以我現在理解的 AI-assisted Engineering 是：人負責問題、方向、邊界與最後決策；AI 負責放大思考與執行能力。AI 寫下的程式可能會越來越多，但人的工作不是消失，而是把判斷放到更重要的位置。