AI 寫得越來越多，我反而更在意自己怎麼判斷。

最早從日文翻譯與文字確認開始，之後隨著學習，逐漸延伸到 Coding、SQL 與學校課題，也開始嘗試 Cursor、Copilot。

專案變大、Context 拉長之後，需求容易被忘記，已完成的部分也可能被改壞。真正改變我的不是某個模型突然變強，而是開始思考怎麼安排 AI 參與工作。

使用方式的變化概念圖

我會先在 Chat 模式持續討論，透過 AI 提問、自己回答，逐步整理需求、使用情境、Scope、技術方向與 UI。重要專案也會請另一個 AI 提供不同觀點，找出自己可能忽略的地方。

視覺方向則先做出接近想法的圖像與 Demo，再把確認過的決策整理成 Plan、AGENTS.md、DESIGN.md、Scope 與 Evidence，讓 Agent 不必每一輪都重新猜測。

討論與定義概念圖

小型、明確、邊界清楚的修改，通常直接用 Codex 快速處理並確認即可。若每個小任務都載入大量 Context、啟動完整 OMO 流程，準備本身反而會變得太重。

跨模組、重要或風險較高的工作，才採用 Brainstorm、Spec、分工實作、獨立 Review 與 Evidence。流程應該配合任務，而不是每次都一樣。

依任務選擇流程概念圖

AI 在我的流程裡可以一起思考、協助實作，也能幫忙 Review。人則負責 DEFINE、DECIDE、DIRECT、VERIFY。

Human as PM 不是完全離開技術，而是把重心放在需求理解、結構判斷、Scope、優先順序與驗收。AI 擴大執行能力，但最後要做什麼、能否接受，仍由人決定。

複雜專案會把實作、Debug、UI、Visual QA、Review 等工作拆開。重點不是 Agent 越多越好，而是讓確認者不只是沿用實作者的同一條 Context。

Review 時也會限定資料範圍，例如 DESIGN、PLAN、變更檔案、測試結果與截圖，讓結論建立在看得到的內容上。

依照任務查看 Typecheck、Tests、Build、Diff、截圖等 Evidence。若是 UI，也要確認 Reviewer 實際看到了圖片，而不是只有檔名或文字描述。

AI 回報 Visual QA PASS 並不能取代人的驗收。我會打開實際結果檢查，有問題就回去修正，最後再自己決定是否接受。

測試通過，不代表畫面就符合設計。

日誌 / Lab

早期使用 Cursor 時，Context 變長或中斷後，Agent 有時會忘記先前確認的方向，重做已完成的部分，甚至做出互相干擾的功能。

後來逐步加入 Plan、Scope、Git 邊界、獨立 Review 與 Evidence，把可以讓 AI 自由探索的部分，和必須由人先定義的部分分開。

從經驗改變的流程概念圖

以前

PROMPT → GENERATE → FIX → 重做

現在

DEFINE → BOUNDED BUILD → REVIEW → EVIDENCE

Local AI 實驗讓我理解，模型能力之外，VRAM、量化、Context 長度、速度、穩定性與成本都會影響實際使用。現階段大型複雜專案仍以雲端模型為主，本地 AI 則持續作為研究與實驗方向。

我理解的 AI-assisted Engineering，是人負責問題、方向、邊界與最後決策，AI 放大思考與執行能力。工具會繼續變，但我仍需要親自確認結果。

從翻譯開始，慢慢走到設計開發方式。