現在很多人每天都在使用 ChatGPT、Claude、Gemini，工程師也開始使用 Claude Code、OpenAI Codex 等工具協助開發。但我發現，大家對 AI 的理解經常停留在「輸入問題，然後 AI 給我答案」。
其實我們平常使用的 AI 助理，背後包含了模型、上下文管理、工具系統與執行環境。這些東西會直接影響 AI 能做到什麼、為什麼有時候會忘記事情，以及為什麼同樣一個需求，交給不同工具執行會有不同結果。最近也看了一支 Anthropic 工程主管 Felix Rieseberg 的訪談，裡面提到不少我覺得值得重新思考的 AI 使用方式。
這篇先整理 AI 的基本運作原理，再從訪談談到實際工作流程，以及軟體工程師可以把力氣放在哪裡。
一、我們每天使用的 AI，到底是怎麼運作的？
LLM 是什麼？先從預測下一個 Token 理解
以常見的自回歸文字生成模型來說，LLM（Large Language Model，大型語言模型）的生成方式，可以先理解成根據已經看到的內容，計算下一個 Token 的機率，再依生成設定選出接下來的內容。
大家常用「一個字接著一個字猜」來形容，雖然方便理解，但技術上沒有那麼簡單。Token 不一定等於一個中文字，也可能是一個英文單字、一部分單字、標點符號或空白。實際怎麼切分，會依模型使用的 tokenizer 而不同。
模型在訓練過程中學習了大量資料中的關聯與模式，在生成文字時，根據目前的上下文逐步預測後續 Token。所以這裡的「猜」，也不是隨機亂猜。想實際看看文字怎麼切分，可以用 OpenAI 的 Tokenizer。
模型確實能從訓練中學到語言、知識、推理模式等能力，但產生的內容不保證正確。它有時候會生成看起來很合理、實際卻不存在的資訊，也就是大家常說的幻覺（Hallucination）。如果目前的上下文沒有最新資料，也沒有使用外部工具查證，模型回答最新新聞、即時天氣或系統目前狀態時，就可能出現問題。用了工具也不保證正確，還是要看來源、時間和它有沒有讀對資料。
我們平常使用的 AI，還包含 Harness
這是我覺得很多人容易忽略的地方。平常我們使用 ChatGPT、Claude Code 或 Codex，實際操作的是一整套 AI 應用，不單單只有模型。以現在常見的 AI Agent 為例，可以先用以下幾個概念理解。它們不是完全分開的元件，例如 Prompt 本身就是 Context 的一部分：
Model（模型）：負責理解輸入、生成內容，以及判斷接下來可能需要執行的動作。
Prompt（提示詞）：給模型的指令或輸入；日常討論時常指使用者提出的問題與需求，也可能包含系統提供的指令。
Context（上下文）：模型這次生成時實際收到、可以參考的內容，包含提示詞、對話紀錄，以及被載入的工具結果、程式碼與文件。放在資料夾裡，不代表模型已經讀過。
Harness（執行與協調系統）：模型外圍的執行程式，負責組織 Context、處理工具呼叫與執行流程，並配合執行環境落實權限和核准機制。不同工具的實際分工不一定相同。
Tools（工具）：讓 AI 可以搜尋網頁、讀取檔案、執行程式、查詢資料庫或操作外部服務。
可以把一個 AI Agent 的工作流程簡化成：
使用者提出需求 → Harness 整理 Context → Model 產生回答或工具呼叫 → 執行系統檢查權限並呼叫 Tools → 將結果放回 Context → Model 回答或繼續下一步。
例如，當你叫 Codex 修改一個專案的程式碼時，背後可能會經過讀取原始碼、分析依賴、修改檔案、執行測試，再根據錯誤重新調整的過程。這些檔案操作和測試工作，需要外部工具與執行環境配合才能完成。所以 Claude Code 跟 Codex 即使收到相同的 Prompt，也可能因為使用的模型、Harness、工具、權限設定及上下文管理不同，最後產生不一樣的結果。
這也是為什麼我認為現在比較 AI 工具，不能只看模型本身的能力，還要看整個執行環境怎麼設計。OpenAI 在 Codex harness 的介紹裡，也把維護上下文、工具執行與權限控制列為這層系統的工作。
AI 為什麼有時候記得你，有時候又忘記了？
這就要談到 Context Window（上下文視窗），以及產品怎麼保存和取回資料。模型有能夠處理的上下文長度限制，通常使用 Token 數量表示；實際可用範圍也會受到產品設定影響，生成的內容同樣需要預留空間。
當我們不斷跟 AI 對話，歷史訊息、系統指令、工具回傳資料，都可能占用 Context Window。如果內容太長，系統可能會開始摘要、壓縮或移除部分歷史內容。這時候 AI 就可能不記得先前討論過的細節。
而且即使某些資訊還存在 Context 裡，也不代表模型每次都能正確找到或使用那些資訊。那 ChatGPT、Claude 等產品為什麼又能記住我們之前聊過的事情？因為 AI 產品可以在模型之外建立記憶機制，例如保存重要資訊、使用者偏好或摘要，儲存到檔案或資料庫，並在需要時搜尋先前紀錄。這些是可能採用的設計，不表示每個產品都採用同一套方法。
當系統判斷這些資料與目前任務相關，就可以重新提供給模型。不同產品實際使用的記憶機制不完全相同。這也說明了為什麼聊天記錄保存了很久，不代表模型每次回答時都完整讀取了所有歷史內容。
對於需要長期執行的 AI Agent，Context 管理與外部記憶設計，其實會直接影響整個系統的可靠性。Anthropic 的 Context engineering 說明也談到摘要壓縮和外部筆記，以及壓縮時遺失細節的問題。
二、現在應該怎麼使用 AI？從 Anthropic 工程主管的訪談談起
最近看了 Silicon Valley Girl 對 Felix Rieseberg 的訪談：
Claude Engineering Lead: “Stop Using Claude Like It’s 2024” | Felix Rieseberg。也可以對照主持人官網的逐字稿。
依節目介紹，Felix Rieseberg 在錄製訪談時，是 Anthropic 負責 Claude.ai、Cowork 與 Claude Code Desktop 的工程主管。訪談談到他如何使用 Claude、AI Agent 的工作方式，以及軟體開發和知識工作正在發生的改變。以下是我整理的幾個重點，也穿插自己的工程與維運觀點，不是逐字翻譯。
AI 的用途，可以從自動化和能力增強來看
Felix 在訪談中把 AI 的使用方向區分成 Automation（自動化）和 Augmentation（能力增強）。自動化應該是目前大家最熟悉的用法。例如整理會議記錄、彙整 Email、產生報表、協助修改程式碼，或處理原本需要花很多時間的重複性工作。
這些應用的價值很直接，就是降低時間與人力成本。但另一個我覺得更有意思的方向，是 Augmentation。例如你原本不懂 3D 動畫製作，現在可以透過 AI 協助操作 Blender 等工具，先製作出能實際觀看和調整的原型。
或者你熟悉系統架構，但不熟悉某種前端框架，也可以利用 AI 快速建立可操作的介面，再根據需求修改。原本需要跨越很多專業技能才能開始的工作，現在可以更快進入實作階段。不過，能做出原型跟能夠交付正式產品，仍然是兩件事情。
從工程角度來看，系統的可靠性、維護、安全性與實際使用體驗，都還是需要驗證。Felix 也提到，現在應該重新思考整個 Workflow（工作流程）。以前我們可能先決定每個工作步驟，再逐項交給 AI 處理。
現在則可以先定義最終目標，提供適當的工具與資料，讓 AI 自行規劃部分處理過程，再透過驗收標準確認成果。
好的 AI 結果，不應該只看答案對不對
訪談裡有個查氣溫的例子，我覺得很容易理解。下面用假設的數字重述他的意思，不是訪談原話中的溫度：假設今天請 AI 查詢某個地方的氣溫。第一個 AI 沒有查任何資料，直接猜出 28°C，結果剛好完全正確。
第二個 AI 先確認地點，再查詢可靠的氣象資料來源，最後得到 27.5°C。雖然第二個 AI 跟實際溫度有一點誤差，但如果我們要建立可以長期運作的系統，第二種處理方式顯然更值得信任。因為它有可以檢查、重複執行的方法。
我們不能只因為 AI 產出一個正確答案，就認為它已經掌握了可靠的解決方法。如果結果涉及商業決策、技術問題或正式文件，就應該要求它說明資訊來源、驗證方式，以及有哪些地方仍然不確定。
不要只要求 AI「幫我寫好一篇文章」
Felix 分享了作家 Adam Davidson 使用 AI 的方式。一般人可能把文章交給 Claude，然後說「幫我改得更專業」、「幫我寫得更好」。但這類要求其實很模糊。
Adam Davidson 的做法，是透過不同指令來檢查文章論點。例如要求模型放大某個觀點、提出最有力的反駁，或找出文章中最值得質疑的地方。我們看到一篇好的技術文章，通常不是因為作者用了很多專業術語，而是他真的理解問題、查過資料、驗證過結果，也知道哪些內容應該刪掉。
所以如果今天要讓 AI 協助寫作，可以把原本的工作流程拆開。先確認事實與資料來源，再檢查論點、找出反例，最後才進行文字整理。這會比單純要求 AI 一次生成一篇「完整又專業」的文章，更容易控制品質。
用不同的 AI 會話，進行對抗式審查
這是整段訪談中，我覺得很值得實際導入工作流程的一個方法。Felix 提到 Adversarial Review（對抗式審查）。假設第一個 Claude 已經完成一份系統規劃或技術文件。
接下來可以另外啟動幾個獨立的 AI 會話，要求它們從不同角度找出問題。例如檢查技術假設是否合理、是否缺少證據、安全性是否有漏洞，或有沒有被忽略的使用情境。這些審查者的工作不是稱讚原本的結果，而是嘗試證明它有問題。
最後再交給另一個獨立會話，判斷哪些批評成立、哪些只是誤解，並把有價值的意見送回原本的工作流程進行修正。這個概念跟資安領域的 Red Team 有點類似。Felix 也提到，找出問題有時候比從零開始創造東西容易，因此部分審查工作可以試著交給能力低一級的模型。至於能不能省下成本，還是要看實際用量、價格和審查品質。
不過我認為，這不代表每個任務都需要同時開五個、十個 AI。可以先從一個負責生成、一個負責獨立審查開始，再看品質改善的程度是否值得額外成本。另外也要注意，多個 AI 都同意，不代表結果一定正確。
遇到重要的技術決策，還是要回到外部證據、測試結果或人工驗證。
「你是一位資深工程師」可能沒有想像中重要
以前大家學習 Prompt Engineering，經常會看到這種寫法：「你是一位擁有 20 年經驗的資深軟體工程師，請協助我……」Felix 在訪談中提到，現在的通用模型已經具備相當廣泛的能力。
如果只是要求模型扮演專業人士，有時候它會產生很多專業術語，但不一定真的使用專業人士的工作方法。他更傾向要求 Claude 找出該領域頂尖從業者會使用的工具、技術和流程，再實際運用這些方法完成工作。例如與其只說「你是一位資深資安工程師」，不如直接要求 AI 根據官方公告、受影響版本、實際設定與測試證據，判斷一個漏洞是否影響目前的環境。
角色設定不是完全沒用，它仍然可以幫助模型理解溝通對象與任務背景。但如果只有角色，卻沒有可靠的資料、工具與驗收方式，就很容易產生看起來專業、實際上沒有解決問題的內容。
Skills 不是越多越好
另一個值得注意的是 Skills。現在許多 AI 開發工具都支援 Skills，讓我們可以把特定工作流程、操作規則、參考資料，甚至腳本整理起來，交給 AI 在適當時機使用。但 Felix 提到，模型進步速度很快。
上一代模型需要大量指令才能完成的事情，下一代模型可能已經可以自行處理。有些過去寫下的限制，反而可能干擾新模型的執行能力。所以我覺得 Skills 應該定期檢查。
如果是組織既有的作業流程、系統特殊限制，或需要精確執行的操作步驟，這些內容當然有保留價值。但如果只是重複提醒模型要認真思考、扮演專家，或遵守一堆沒有驗證過的通用規則，就值得測試刪掉之後，結果會不會反而更好。
最重要的還是要有可以比較的測試案例，而不是只憑感覺判斷 Prompt 或 Skills 有沒有效果。
讓 AI 自己查資料，而不是每次都人工整理給它
Felix 分享他以前處理系統錯誤的方式。當時系統出現 Crash，他會先自己查看錯誤紀錄，挑出需要修復的項目，再把資訊交給 Claude。後來他發現，自己其實花了很多時間在搬運資料。
既然 Claude 已經有能力分析錯誤，為什麼不直接讓它使用適當的工具，取得相關的 Crash Data，再自行判斷哪些問題需要優先處理？這個觀點對系統維運很有意思。因為很多時候我們給 AI 的資料，其實已經被人為篩選過。
如果一開始的判斷就有偏差，AI 也可能因此看不到真正有問題的地方。但這裡我會補充一個很重要的前提：資料存取權限。讓 AI 自行查詢資訊，不代表應該無限制地開放所有資料庫、正式環境或管理權限。
實務上可以透過唯讀 API、受到限制的 SQL 帳號、日誌查詢工具或 MCP，讓 Agent 在授權範圍內取得資料。涉及敏感資訊、密碼、個資或正式環境修改時，仍然需要做好權限隔離、操作紀錄，以及必要的人工核准。
AI 有能力自行判斷要查什麼資料，是很有價值的進步，但也讓權限設計變得更加重要。
把自己的判斷標準整理給 AI
另外一個我覺得很實用的觀點，是讓 AI 學習我們平常審查工作的方式。例如同事完成一份文章、簡報或報告，最後通常還是需要主管審查。因為每個人對品質的要求不一樣，有些標準甚至很難直接說清楚。
Felix 提到，可以先蒐集過去留下的修改意見與歷史回饋，讓 AI 整理成一套判斷原則。再進一步請它分析，有哪些規則是我們一直在使用，但從來沒有明確寫下來的。整理完成後，先不要直接把所有審查交給 AI。
可以讓人工審查與 AI 審查同時進行，拿同一份內容分別給出意見，再比較兩者的差異。如果 AI 持續漏掉某些重要問題，就調整規則或補充案例。透過這種方式，逐步建立比較可靠的品質審查流程。
我覺得這對文章編輯、程式碼審查、客服品質管理，甚至企業內部的文件審核，都很有參考價值。
三、如果 AI 已經能完成這麼多工作，軟體工程師的價值在哪裡？
這也是我看完訪談後一直在思考的問題。Felix 提到，現在製作軟體原型的成本已經大幅下降。以前可能需要花不少時間才能完成一個概念驗證，現在可以透過 AI 快速建立多種版本，再交給使用者實際操作。
他判斷原型有沒有價值的一個重要訊號，是使用者能不能很快理解這個工具，並且完成原本做不到的事情。我們現在可以很快建立網站、寫出程式，甚至整合幾個原本不熟悉的系統。但如果沒有解決真正的使用需求，做出來的東西仍然沒有太大的價值。
對軟體工程師而言，熟記某個 API 的所有參數，或是記住一套框架的每個指令，重要性可能會逐漸下降。理解系統架構、找到正確問題、判斷技術選擇，以及把不同系統整合成可維護、可交付的產品，反而會變得更加重要。
尤其在企業環境裡，很多問題都不只是寫一段程式就能解決。還要考慮資料如何交換、權限如何設計、舊系統如何整合、出錯時怎麼恢復，以及正式上線後誰來維護。AI 可以加快實作，但這些問題仍然需要有人負責決策與驗收。
技術門檻的降低，也代表我們有更多機會去嘗試以前因為成本太高而沒有實作的想法。
四、現在的 AI 使用方式，可能很快又會改變
訪談最後，Felix 用智慧型手機發展前的時代，來形容現在的 AI 產品。當時大家已經很習慣使用實體鍵盤手機，很難想像後來智慧型手機會把整個使用方式改變。他認為現在的 AI 產品，也可能還處於類似的階段。
因為現在大家討論的 Prompt Engineering、Agent、Skills、MCP、Harness，以及各種最佳實踐，可能都還會隨著模型能力與產品設計持續改變。一套今天很有效的流程，幾個月後不一定還是最好的選擇。
所以我覺得，比起記住一堆固定的提示詞，更值得花時間理解 AI 的基本運作方式，以及怎麼評估它有沒有真的完成任務。模型能力會改變，工具也會更新。但對工作而言，仍然要知道自己想解決什麼問題、要提供哪些資料、怎麼確認結果，以及哪個環節需要人工介入。
最後補一個訪談中比較有趣的小細節。Felix 說，即使知道會額外消耗 Token，他還是習慣對 Claude 說「請」和「謝謝」。他的理由很單純：這樣做是為了維持自己與外界互動時的態度。
他談的是自己的習慣，並不是說對 AI 客氣就能提高答案正確率。畢竟 AI 工具會一直改變，而我們怎麼使用工具，最後還是會影響自己的工作習慣。
參考資料
Claude Engineering Lead: “Stop Using Claude Like It’s 2024” — Felix Rieseberg 訪談
OpenAI — Key concepts：Token 與上下文長度
OpenAI — Tokenizer：查看文字的 Token 切分
OpenAI — Codex as a Platform：Agent Harness 的運作設計
Anthropic — Building Effective Agents