摘要： 作者把 AI Native 開發定位成讓工具進入構想、實作、測試與部署的往返流程，而不是外包工程判斷。他以 Codex、Claude Code、Gemini CLI、Bun 與 Cloudflare Workers 串接工作流，並用 build、route、live URL、meta 與 console 檢查把速度轉成可靠度。
對我而言，AI Native 開發並不是把寫程式這件事整包外包給 AI，而是讓 AI 工具融入產品開發的每一個環節，縮短想法、設計、程式、測試到部署之間的往返距離。
我目前的工作模式，是將 OpenAI Codex、Claude Code、Gemini CLI、MCP workflows、Bun、React 與 Cloudflare Workers 接成一條能夠快速迭代的生產線。關鍵不在於囤積了多少工具，而在於每一個工具是否確實幫我更早看到實際成果。
先問三個問題
面對新的產品想法，我通常不急著寫出完整規格，而是先把它拆解成三個必須回答的問題：
- 這個頁面或功能到底要解決什麼
- 使用者打開頁面的第一眼應該看到什麼
- 哪個版本能夠以最快速度上線做驗證
照這個順序想，專案初期就不會跌進過度龐大的架構設計。對產品來說，最要緊的是先長成一個打得開、點得動、測得出的成品。
AI 扮演的位置
在我的流程中，AI 工具更像一起共事的夥伴，而非全自動的代工廠。Codex 用來處理 repo 內的實際修改、檢查檔案與執行 build；Claude Code 適合承擔規模大一點的實作與重構；Gemini CLI 則負責快速查證想法、梳理方向，以及分擔命令列上的工作。
重複性高、上下文龐雜的任務，我放心交給 AI；產品層面的判斷則始終握在自己手裡——要不要新增一個頁面、文案該怎麼下筆、使用者點進來時會看到什麼、哪些內容得先收斂，這些都不外包。
挑 Bun 與 Workers 的理由
本地開發的速度感主要由 Bun 帶來：安裝、build、執行 script 都相當俐落。部署這一端則交給 Cloudflare Workers 維持簡潔——先把 dist build 出來，再透過 Wrangler deploy 到 Workers Static Assets 即可。
個人網站、Blog、作品展示頁這類專案特別適合這套組合：起步時完全不需要複雜後端，之後若想補上表單、AI endpoint、登入或資料庫，也都能一步一步擴充上去。
上線前的自我檢查
每輪修改結束，我不會只盯著程式碼，而是把實際輸出逐一驗過：
bun run build能不能順利通過- 頁面 route 有沒有真的被產出
- live Workers URL 打不打得開
- SEO meta 與 OG image 的內容正不正確
- 瀏覽器 console 是否出現 error
正是這些檢查，讓 AI-assisted 開發變得可靠。速度提升之後，品質反而更該用真實畫面與真實部署結果來把關。
這套流程想達成的目標
我想達成的並非展示手上有幾套 AI 工具，而是靠它們把產品更快做出來。一套好的工作流，應該讓 idea 更快長成 prototype，prototype 更快推進到 production，production 也更快收到下一輪回饋。
我心目中的 AI Native 開發便是如此：AI 不去取代工程判斷，而是讓這些判斷能夠更快付諸實現。