我做 Pocketool 口袋工具 的時候，一開始沒想那麼多。
只是每隔一陣子，就會遇到一件「明明不大，處理起來卻有點煩」的事：想算一下複利、找個顏文字、產生 QR Code，或是查一筆郵遞區號。網路上通常找得到工具，但有些廣告很多、有些得先註冊，還有些會把輸入的資料送去哪裡也說不清楚。
既然一直找不到完全順手的，我就自己做。後來這個口袋越塞越滿，除了計算、文字與查詢工具，還放進了英語口說練習，甚至有一款可以雙人連線的戰鬥陀螺。從一開始東做一個、西做一個，到後來才發現，原來已經累積成一系列的工具（可參考 Pocketool 首頁與開站筆記）。
Pocketool 把原本散落的工具集中到同一個入口。
如果把 AI Coding 解釋成「叫 AI 幫你寫程式」，不能說錯，只是少講了一大半。
我認為更完整的說法是：讓 AI 真的參與軟體開發的過程。它不只在聊天視窗裡丟一段程式碼給你，而是可以進入專案、找出相關檔案、修改內容、執行測試，再根據結果繼續調整。OpenAI 對 Codex 的介紹也包含理解程式庫、開發與測試功能、修正錯誤，以及檢查修改內容（來源：OpenAI ChatGPT Learn）。
整個過程比較像這樣：
這也是 AI Coding 和單純問問題最大的差異。最後拿到的不只是一份「你可以這樣做」的建議，而是一組真的改在專案裡、可以打開檢查的成果。
不過，這不表示只要輸入一句「幫我做一個工具站」，AI 就會吐出現在的 Pocketool。至少我的運氣還沒有好到這種程度。
真正的工作往往藏在需求裡。以郵遞區號工具後來加入的「中文地址轉英文」為例，看起來好像只是把地址丟給 AI 翻譯，實際上第一個決定卻是：地址不能翻得像英文就算了，必須盡量符合中華郵政的正式寫法。
光是路名，就有三萬多筆官方中英對照資料。沒有對照的內容可以用音譯補上，但畫面必須老實標示「非官方譯名」；官方查詢頁又有驗證碼，沒辦法讓程式自動把每一筆答案抓回來比較，所以最後還得另外設計測試與抽樣驗證。功能完成時，專案已經跑過數百項單元測試，瀏覽器也被我來來回回測到快認得我了。中間的開發細節太長，這裡先不提（延伸閱讀：郵遞區號站的英文版是怎麼蓋的：官方對照檔、組合引擎與「沒有標準答案」的驗證）。
這一段很能說明我怎麼看 AI Coding：AI 可以協助整理資料、修改程式、補測試，也能在看到錯誤後繼續修正；但「資料應該相信誰」「什麼結果才敢交給別人使用」，還是得由人決定。方向如果一開始就錯了，AI 只會很勤勞地把錯的方向做得更完整。
Pocketool 裡的戰鬥陀螺也是從一個「如果做成網頁應該很有趣」的念頭，慢慢長成真的能玩的線上遊戲。
可以。但我會建議先把「我要做一個很厲害的平台」收起來，從一個你真的遇過的小麻煩開始。
先試著回答四個問題：
這四題如果答得出來，就已經有一份比「幫我做一個超強網站」好得多的起點。接著才是請 AI 建立畫面、處理資料、修改功能與執行測試。你不必先背完所有語法，但要願意看它改了什麼、打開成果實際操作，並在不對的時候把問題講清楚。
Coding Agent 可以直接修改專案，但畫面能打開不代表功能一定正確。修改紀錄、測試結果與實際操作都要看。圖片來源：OpenAI Codex。
最適合第一個練習的題目，通常小到有點不起眼：一張報名表、一個費用計算器、一頁可以搜尋的資料，或是一個自己真的會打開來用的按鈕。先讓一件小事順利運作，再決定要不要把它長成下一個 Pocketool。
這個系列不會整理 30 句「神 Prompt」，也不打算假裝 AI 從此不會出錯。我比較想做的，是把自己實際開發時會經過的路拆開來：先認識模型、Chat、Agent 與 Harness，再走進網站、開發環境、版本控制、外部資料與雲端部署。
我希望讀到後面時，你不只知道該怎麼請 AI 動手，也大概看得懂它正在碰哪一塊；作品壞掉時，不會只剩下重新問一次同樣的 Prompt；真的做完時，也知道怎麼把它安全地交給別人使用。
所以 Day 1 先記住一件事就好：AI Coding 不是讓你跳過所有學習，而是讓你可以帶著一個真實問題開始學。
下一篇，我們先拆開幾個最容易混在一起的角色：AI 模型、AI Chat 與 AI Agent。畢竟在請 AI 幫你蓋工具以前，最好先知道你是在跟它討論，還是真的把工具箱交到它手上。
文章同步發表於 https://book.casper.tw/it2026/what-is-ai-coding
iThome鐵人賽
看影片追技術