做 AI 產品時，先想清楚模型能按哪些按鈕
很多團隊做 AI 產品時，第一個問題還是：要用哪個模型？
這問題當然重要。模型速度、價格、上下文長度、工具支援、回答品質，都會影響產品體驗。但我越來越覺得，真正讓使用者緊張的地方，通常不是模型名字。
而是它突然做了一個動作。
它幫你改了檔案。它幫你送出表單。它幫你產生一組素材。它幫你開了一個遠端 session。它說「已完成」，但你不知道它碰了什麼、略過了什麼、哪一步其實只是猜的。
AI 從回答問題變成呼叫工具之後，產品設計的重點就變了。以前你可以把錯誤答案當成內容品質問題。現在一個錯誤動作可能改掉資料、消耗預算、送出通知，或留下需要工程師收拾的狀態。
所以在選模型之前，小團隊更早該問的是：這個模型到底能按哪些按鈕？
回答和動作要分開看
聊天式 AI 很容易讓人把所有輸出都看成同一件事。
模型回答一段文字，模型呼叫一個工具，模型修改一個設定，模型幫使用者發布內容，在畫面上可能都只是幾行訊息。但它們的風險完全不同。
回答可以被忽略，可以再問一次，可以讓使用者自己判斷。動作就麻煩多了。動作會改變世界，至少會改變你的產品狀態。
這也是為什麼 tool call 不應該只是工程實作細節。它是產品介面的一部分。
一個 AI 功能如果只是「模型可以呼叫 createCampaign()」或「模型可以呼叫 updateFile()」，那其實還沒設計完。你還要知道：
這個工具能讀哪些資料
它能寫哪些資料
它會不會觸發外部服務
使用者能不能在動作前看到預覽
動作完成後會留下什麼收據
做錯時能不能取消或復原
這些問題聽起來很基本，但很多 AI demo 會直接跳過。因為 demo 要展示魔法，產品要處理後果。
權限不是等出事才補
工具權限最好一開始就設計得很無聊。
無聊的意思是：範圍小、名字清楚、輸入輸出可預期。不要一開始就給模型一個「幫我處理專案」的大工具。把它拆成比較窄的動作：讀取檔案清單、產生修改建議、建立草稿、套用已確認的修改、匯出結果。
每個工具都應該像一個普通產品功能，而不是一個神祕後門。
這裡最容易犯的錯，是把工具權限設計成工程師自己看得懂就好。反正 function schema 有寫，log 也查得到，失敗時工程師可以去後台追。
但使用者需要的是產品層的邊界，不是後台層的證據。
如果 AI 要改一份文件，使用者應該先看到 diff。如果 AI 要整理圖片，使用者應該先看到預覽。如果 AI 要發布內容，使用者應該看到標題、平台、時間和可取消的最後確認。如果 AI 要花掉額度或呼叫付費 API，那更不應該藏在一句「我來幫你處理」裡。
你可以把它想成一條很短的規則：
會改變狀態的 AI 動作，都要先被看見。
中間狀態比漂亮文案有用
很多 AI 介面很會顯示「正在思考」、「正在處理」、「已完成」。
這些字不太夠。
使用者真正想知道的不是模型有沒有在忙，而是它忙到哪裡、接下來要做什麼、目前結果能不能檢查。
所以中間狀態要具體。
例如 coding agent 不是只顯示「正在修改」。它可以顯示目前讀了哪些檔案、準備改哪些檔案、測試跑到哪裡、失敗原因是什麼、下一次嘗試會不會擴大範圍。
影像工具也一樣。假設一個產品讓 AI 幫使用者產生社群素材，真正讓人放心的未必是「一鍵完成」，而是每一步都看得見：原圖在哪裡、要裁成什麼比例、輸出尺寸是多少、會不會上傳到伺服器、下載前能不能預覽。
像準備 Instagram 圖片時，用 Resize Image for Instagram 這類瀏覽器本地的尺寸工具，信任感不來自它講了很多保證，而是邊界很窄：上傳圖片、選 square、portrait、story 或 reels 尺寸，先看預覽，再下載輸出。來源圖片留在瀏覽器裡，動作本身也很容易理解。
這就是好的工具邊界。不是因為它很炫，而是因為使用者知道自己把什麼交出去、工具做了什麼、結果長什麼樣。
AI 產品也該往這個方向靠。不要只讓模型講得像它很可靠。讓動作本身變得可檢查。
Agent 不是黑箱同事
最近很多 AI coding 工具都在往 agent workflow 前進：遠端 session、session history、auto-review、custom tools、headless execution、同步狀態、背景任務。
這些能力很實用。小團隊以前做不起來的內部工具、重複維護、跨檔案整理，現在可能真的可以交給 agent 先跑一版。
但 agent 越像同事，越需要工作規則。
人類同事會被要求寫 ticket、開 PR、留下測試結果、說明風險、標示還沒做完的部分。Agent 也一樣。甚至更需要，因為它很容易產出一堆看似完整、其實沒有人掌握脈絡的東西。
一個長 session 如果沒有任務名稱、停止條件和輸出收據，很快就會變成黑箱。
它可能真的做了很多事，但 reviewer 只看到一包 diff。它可能修了 bug，也可能順手改了不該改的範圍。它可能通過了某個測試，也可能沒有跑關鍵驗證。它可能遇到阻礙後自己繞路，而這條路根本不是團隊願意接受的產品方向。
所以 agent UI 不應該只追求「更自動」。它還要回答幾個很普通的管理問題：
這個 session 的任務是什麼
它被允許碰哪些範圍
它什麼時候該停
它做完後要交回哪些證據
哪些動作需要人類確認
這些東西看起來不像 AI 功能，卻決定 AI 功能能不能被團隊長期使用。
小團隊可以先做一張邊界表
不用一開始就做很重的治理系統。
對小團隊來說，先在每個 AI tool call 前寫一張簡單的邊界表，就已經能避開很多麻煩。
第一欄：允許讀取。
模型能不能讀使用者資料？能不能讀私有檔案？能不能讀第三方 API 回傳？如果可以，哪些欄位要遮掉？哪些內容只能摘要，不能原樣帶進模型？
第二欄：允許修改。
它能不能直接寫入資料庫？能不能改檔案？能不能建立草稿但不能發布？能不能改設定但需要確認？這裡不要用「之後再補權限」的心態。之後通常就是出事之後。
第三欄：使用者可見狀態。
動作前看得到什麼？動作中看得到什麼？動作後看得到什麼？如果只有一句「處理中」，那還不夠。
第四欄：可復原方式。
能 undo 嗎？能取消嗎？能回到上一版嗎？如果不能，至少要不要先建立草稿、先產生 preview、先讓人按確認？
第五欄：失敗時交回證據。
失敗不要只說「發生錯誤」。要留下工具名稱、輸入摘要、哪一步失敗、是否已經造成副作用、使用者接下來能做什麼。
這張表不需要很漂亮。它的價值是逼團隊承認：AI 不只是在回答，它正在進入產品的動作層。
自動化越強，邊界越要清楚
AI 產品的方向很明顯。模型會更常呼叫工具，工具會更常改變狀態，agent session 會更常在背景執行，使用者會越來越習慣把一整段工作交出去。
這不是壞事。
真正危險的是產品還停留在聊天框思維：只要模型看起來會講、會做、會完成，介面就算成功。
我不太相信這會撐很久。使用者一開始會被自動化吸引，但真正留下來，是因為他知道這個自動化不會亂碰東西。它有範圍，有預覽，有確認，有收據，有停下來的方式。
所以做 AI 產品時，不要只問「模型能不能做到」。
先問一個比較土、但比較有用的問題：如果模型真的能做到，它可以按哪些按鈕？
把這件事想清楚，AI 功能才不會只是另一個黑箱。它會變成產品裡一個可以被信任、被檢查、被收回的工作流程。
Source notes
OpenAI, "Codex for every role, tool, and workflow", 2026-06-02, https://openai.com/index/codex-for-every-role-tool-workflow/
GitHub Changelog, "GitHub Copilot in Visual Studio Code, May releases", 2026-06-03, https://github.blog/changelog/2026-06-03-github-copilot-in-visual-studio-code-may-releases/
Cursor Changelog, June 2026 entries, https://cursor.com/changelog
Vercel AI SDK / Chat SDK, https://ai-sdk.dev/
OpenAI, "Running Codex safely at OpenAI", 2026-05-08, https://openai.com/index/running-codex-safely/
Resize Image For local product notes, /Users/hefty/Project/imageresizerfor/public/llms.txt