這幾年只要談到 AI，第一時間想到的通常都是 ChatGPT、Claude、Gemini，接著開始比較哪個模型比較聰明、哪個模型寫程式比較厲害。

我自己思考的問題其實也差不多：

AI 到底可以怎麼幫我寫 Code？

怎麼讓 AI 幫忙補程式、查 Bug、寫測試、整理文件，甚至直接幫忙完成一部分功能。

但前陣子去聽了一些企業 AI 相關的講座後，我開始覺得，這個問題可能正在慢慢改變。

因為當 AI 已經可以幫忙寫 Code、跑測試、整理文件，甚至開始操作工具與企業內部系統時，真正麻煩的問題好像已經從：

AI 能不能幫我們做事？

慢慢變成：

我們要怎麼把需求、流程、資料與環境整理好，讓 AI 知道自己應該做什麼？

甚至還有更重要的一個問題：

AI 到底可以做到哪裡，又有哪些地方不能讓他碰？

這也是我這次聽完幾場分享後，自己最有感的一個轉變。

---

AI 會寫 Code 之後，工程師是不是就沒用了？

這大概是 AI Coding 出現之後，最容易被拿出來討論的問題。

以前可能會想：

AI 可以補 Code，但真正的功能還是工程師自己寫。

後來變成：

AI 可以寫一些簡單功能，但複雜功能還是工程師比較可靠。

再繼續到現在，Coding Agent 已經開始可以讀 Repository、修改多個檔案、執行測試，甚至把一整段開發流程串起來。

一些企業導入經驗也開始把人的角色保留在規劃、方向確認與最後把關，中間的實作、測試與部分 Review 則交給 AI 與自動化流程處理。

所以我現在反而覺得：

問「AI 會不會取代工程師」可能有點太簡化了。

比較值得思考的問題是：

當 AI 開始承擔越來越多實作工作後，工程師剩下來的工作會往哪裡移？

---

Prompt 可能不是最重要的，Context 才是

剛開始使用 AI Coding 時，很容易陷入一個狀況。

我跟 AI 說：

幫我做一個登入功能。

然後 AI 做出來的東西跟我想的不一樣。

第一個反應可能是：

你怎麼連這個都做錯？

但後來想想，「幫我做一個登入功能」這句話其實什麼都沒講。

登入方式是什麼？

Token 放在哪裡？

原本專案有沒有既有的驗證機制？

失敗怎麼處理？

哪些 API 要限制？

哪些檔案可以修改？

哪些地方不要動？

如果這些東西都沒有交代，AI 很可能只能自己猜。

以前我們常常會開玩笑說：

需求寫不清楚，工程師只能靠通靈。

現在好了。

連 AI 都開始一起通靈了。

而且 AI 的執行速度比人快得多，方向一旦猜錯，可能不是慢慢錯一點，而是很有效率地一次幫你錯到底。

這時候問題可能就不只是：

Prompt 要怎麼寫得更厲害？

而是：

AI 在開始工作以前，到底知道多少事情？

一些 Agentic Coding 工作流現在甚至會先要求釐清目標、理解既有程式、確認影響範圍、規劃驗證方式，再產生 Plan，最後才真正進入實作。

這讓我開始覺得，未來所謂的 Prompt 能力，可能不只是：

誰比較會下漂亮的指令。

而是：

誰比較能把問題說清楚，並且把 AI 真正需要的 Context 準備好。

你真正想解決什麼？

現有系統長什麼樣？

有哪些限制？

什麼可以改？

什麼不能碰？

有哪些既有規則需要遵守？

最後怎樣才算完成？

這些東西，其實都比：

請幫我用最佳實踐完成以下需求。

重要得多。

因為 AI 能力越來越強之後，一個模糊的需求未必會讓 AI「做不出來」。

更麻煩的反而可能是：

AI 很順利地做完了，但做的根本不是你真正想要的東西。

Tips：Context 是什麼？

Context 可以先理解成：

AI 在執行工作以前，能夠取得的背景資訊。

可能包含需求、既有程式碼、文件、專案規範、資料結構、API 規格，甚至過去的設計決策。

白話一點：

Prompt 比較像是「這次叫 AI 做什麼」，Context 則是「AI 在做以前，到底知道多少事情，像規範、規則、歷史概念等等」。

---

AI 開始從「回答問題」進入「工作流程」

以前使用 ChatGPT，我自己的感覺比較像：

我問問題，AI 回答。

例如：

這個錯誤是什麼？

這段 SQL 可以怎麼改？

幫我產生一個 API 範例。

但 Agent 開始普及之後，事情有點不一樣。

AI 不單是告訴你應該怎麼做，而是開始動手了。

例如：

讀取需求
↓
理解 Repository
↓
修改 Code
↓
執行 Test
↓
檢查錯誤
↓
再次修改
↓
建立 Commit 或 PR

甚至還可能串接 Jira、Git、企業文件與其他內部服務。

這時候 AI 的角色已經慢慢從：

問答工具

變成了：

可以參與工作流程的可靠執行者

Agent Skill 與 MCP 這類技術，也開始被拿來整理「AI 應該怎麼做」以及「AI 可以接觸哪些外部服務」。

Tips：Agent Skill 是什麼？

Agent Skill 可以先想成：

把團隊做事情的方法整理成 AI 也能照著執行的操作說明。

例如團隊可能有固定流程：

先確認需求
↓
建立 Plan
↓
修改程式
↓
執行測試
↓
Code Review
↓
建立 PR

以前這些流程可能存在工程師腦袋裡。

現在開始可以把這些經驗整理成 AI 能使用的規則與流程。

Tips：MCP 是什麼？

MCP，全名是 Model Context Protocol。

這篇不探討 Protocol 本身，先理解成：

讓 AI 用比較標準的方式連接外部工具與服務。

例如：

AI Agent
↓
MCP
↓
Git / Jira / 文件 / 企業內部服務

所以 Agent 不只知道「怎麼回答」，也開始知道「可以去哪裡取得資料、可以使用哪些工具」。

---

AI 有能力，他也需要韁繩

如果今天只是問 AI：

幫我解釋這段程式。

風險相對單純。

最糟大概就是 AI 講錯，而我們信了。

但如果今天變成：

幫我修改這個 Repository，跑完測試，建立 Commit，更新 Jira，然後呼叫公司內部 API。

事情就完全不一樣了。

因為這時候 AI 手上開始有：

萬能鑰匙。

他可以讀資料。

他可以修改資料。

他可以操作工具。

甚至可能碰到企業內部系統。

所以問題就不能只停留在：

AI 很方便。

而開始要問：

AI 到底可以碰哪些東西？

使用誰的身分？

權限到哪裡？

做過什麼事情有沒有留下紀錄？

如果做錯事情，可以不可以阻止？

這些問題其實都不是 AI 出現以後才突然發明的。

Authentication、Authorization、Token、Audit Log、權限管理，本來就是企業系統一直存在的問題。

只是當 Agent 大量開始串接工具與內部服務後，這些問題被放大了。

所以未來企業導入 AI 很重要的一件事情是：

不要只想著怎麼讓 AI 做更多事情，更要想想怎麼為 AI 套上韁繩。

如果治理方式只剩：

我相信 AI 應該不會亂搞。

那你信我是秦始皇，還是信 AI 永遠不會亂搞。

這跟把 Production DB 密碼貼在桌上一樣，然後相信大家應該不會亂動是一樣的概念。

---

先決定 AI 可以做什麼，再決定怎麼讓他做到

例如公司今天希望 AI 可以協助查詢訂單。

那第一個問題不一定是：

要用哪個模型？

或：

要怎麼把 API 接給 Agent？

而可能應該先問：

AI 可以查哪些訂單？

所有使用者都可以查嗎？

能讀取哪些欄位？

可以修改資料嗎？

如果可以修改，哪些操作需要再次確認？

誰做過哪些操作，要不要留下紀錄？

這些事情其實和傳統企業系統非常像。

差別只是以前權限主要是給：

人
帳號
後端服務
系統

現在又多了一個新的角色：

AI Agent

所以 AI 能力越強，權限邊界反而越不能模糊。

Tips：Least Privilege 是什麼？

Least Privilege 通常翻譯成「最小權限原則」。

白話來說就是：

只給完成工作真正需要的權限，不要為了方便就都開給 AI。

例如 AI 只是要查詢訂單狀態。

那可能只需要：

讀取訂單

絕對不是直接給出一大堆功能，比如：

修改訂單
刪除訂單
建立退款
修改會員資料

白話來說就是：

你今天只是請一個人進倉庫幫忙拿箱子，沒有必要順便把整座工廠的萬能鑰匙一起交給他。

---

除了權限，還要知道「AI 做過什麼」

另一個很重要的事情，是可追蹤及可觀察性。

假設今天 Agent 修改了一筆資料。

出問題之後，如果最後只知道：

好像是 AI 改的。

只知道這樣確實不夠。

因為我們需要知道一系列：

是哪一個 Agent？

使用誰的身分？

當時收到什麼任務？

使用了哪個工具？

修改了哪些資料？

什麼時間執行？

最後結果是什麼？

所以當 AI 開始操作企業系統之後，Log、Audit Trail 這些原本就存在的系統概念，只會變得更重要。

Tips：Audit Trail 是什麼？

Audit Trail 可以理解成「操作軌跡」。

也就是把重要操作留下紀錄，讓之後可以回頭確認：

誰在什麼時間，做了什麼事情。

AI 也是一樣。

能力越強，就越需要留下足夠的軌跡讓人知道到底做了些什麼。

---

有些事情可以自動做，有些事情還是應該停下來問人

另外一個邊界是：

AI 什麼時候可以直接執行？

例如：

整理文件
產生測試
查詢公開資料

這樣可以相對自由一點。

但如果今天變成：

刪除正式資料
付款
修改權限
部署 Production
大量寄送郵件

就不應該讓 Agent 自己一路油門催到底。

此時會需要加入人工關卡去卡控：

AI 發現需要修改正式資料
↓
提出修改內容
↓
等待人工確認
↓
通過後才執行

並不是 AI 一定會犯錯，

是 AI 怕你又把錯丟到他身上(x。

偏題了...咳，

原因是有些事情本來就需要更高的責任門檻。

就算今天執行的人不是 AI，而是一套普通的自動化系統，也應該有類似的限制。

---

集中管理可能是一種答案

當企業裡的 Agent、工具與服務越來越多時，另一個問題也會開始出現。

不同部門甚至不同使用者，都可能建立自己的 Agent、MCP、Skill，以及各自的相關設定與管理方式：

不同的 Token 或憑證
不同的權限設定
不同的連線方式
不同的 Log
不同的規則
不同的工具版本

一開始各自使用可能沒什麼問題。

但當數量越來越多，如果工具的分類、權限隔離、版本與使用範圍沒有整理清楚，就可能開始出現一些很麻煩的情況。

例如 A 部門的 Agent 看到了不該使用的工具、連到錯誤環境、用了已經過期的 MCP Tool，甚至套用了原本是為 B 部門流程設計的 Skill。

這產生出來的結果絕對會令人鼻酸。

所以實務上逐漸需要某種統一治理的方式，把身分、權限、工具、版本與操作紀錄整理起來。

概念上可以先想成：

AI Agent
↓
企業治理層
↓
身分 / 權限 / Policy / Log
↓
MCP / API / Internal Service

這裡的「企業治理層」不代表一定所有企業最後都必須長成一套架構或平台。雖然最後成功建置的大概也會變成一個平台或一個可遵守的架構就是了。

整體來說是一個概念：

在 AI 真正接觸企業工具以前，先有一層機制負責確認他是誰、能做什麼、可以使用哪些資源，以及做過哪些事情。

真正重要的是：

AI 不應該因為有能力連接工具，就代表什麼工具都可以直接使用。

企業需要知道：

誰可以使用？

可以使用哪些能力？

可以看見哪些工具？

使用的是不是正確版本與正確環境？

哪些操作需要人工確認？

做過哪些事情？

發生問題後能不能追蹤？

這些問題，才是所謂「替 AI 套上韁繩」真正要解決的事情。

Tips：MCP 不等於 AI 治理

這裡也要稍微區分一下。

MCP 主要處理的是：

AI 怎麼用比較標準的方式連接外部工具與服務。

但 MCP 本身不等於完整的治理機制。

身分驗證、權限管理、最小權限、操作紀錄、人工確認、資源限制，仍然是企業在系統設計時需要另外考慮的問題。

所以真正的概念不是：

有 MCP，就把企業 AI 管好了。

而是：

MCP 可以讓 AI 更容易使用工具，但權限、身分、操作紀錄與人工確認，仍然是另外一層企業治理問題。

---

所以，AI 治理最核心的問題可以濃縮成一句：

我們不只要知道 AI 能不能做到，也要知道 AI 如何做到。

但世有伯樂，然後有千里馬。
千里馬常有，而伯樂不常有。

AI 不斷在進化，大家也都在用同樣的 AI，

所以企業真正需要的，是這個懂得栽培千里馬的伯樂。

---

企業 AI 也不是「全部上雲」或「全部留在公司」

以前可能會把問題想得比較簡單。

公司資料很敏感？

那全部放地端。

雲端模型比較強？

那全部上雲。

但實際的企業環境好像沒有這麼爽快。

企業可能同時面對：

資料敏感程度、模型能力、延遲、Token 成本、GPU 成本、尖峰流量，甚至不同工作負載對模型能力的需求。

所以最後比較可能變成：

敏感資料 / 即時需求
↓
偏向地端或私有環境

複雜推理 / 新模型能力
↓
使用雲端模型

高頻但簡單的工作
↓
使用較小模型

流量突然增加
↓
使用雲端彈性資源

混合式 AI 架構的核心也正是在不同部署位置之間取捨，而不是認定所有工作負載只能放在同一個地方。

所以：

模型要放在哪裡，本身也是系統設計的一部分。

這也是以前單純使用 ChatGPT 時，不會去思考的事情。

---

AI 不只可以寫新的東西，也可能幫我們重新看懂舊的東西

另外一個滿有感的方向，是 Legacy System。

很多公司的麻煩可能根本不是：

新功能怎麼寫？

而是：

這個老古董系統誰敢優化？

可能是：

舊 Java
舊 .NET
大量沒有整理的文件
VBA 的功能要改寫成程式

真正了解整個系統的人可能已經離職，甚至退休。

剩下的人只知道：

能跑就不要動

因為動下去會發生什麼沒有人知道。

企業現代化的案例中，AI 已經開始被拿來協助從 Legacy Code 重新整理 Spec、流程、API 與資料關係，再讓工程師進一步確認與重構。

所以 AI 不一定只是：

幫我們更快寫新的 Code。

另一個可能很實際的價值反而是：

幫我們重新讀懂那些已經沒有人想碰的 Code。

例如：

Legacy Code
↓
AI 協助盤點
↓
整理 Spec
↓
整理流程 / API / DB 關係
↓
工程師確認
↓
再決定要不要重構

這可能比單純叫 AI 幫忙生一個新頁面，更接近很多企業真正會遇到的問題。

---

AI 越會寫 Code，工程師越需要管「方向」和「邊界」

這裡會再更主觀一點。

兩、三年前常常會看到一種說法：

AI 可以幫忙寫 Code，但工程師還是必須有足夠深的程式能力，才能在 Code Review 時判斷 AI 寫出來的東西到底對不對。

這個說法現在當然還是成立。

但我認為，這絕不會是未來工程師最主要的價值。

因為 AI 寫 Code 的能力只會越來越進步。

今天 AI 可能還會寫出一些很奇怪的東西：

明明可以直接處理，卻硬寫了一個迴圈

條件判斷塞了一大堆if

重複的邏輯沒有抽出來

蘋果給你寫成拔辣

但我相信，這類問題未來只會越來越少。

甚至很多時候現在就可以再補一句：

幫我重新檢查這段程式，有沒有重複邏輯、過度複雜的判斷或不必要的迴圈，並在不改變原本功能的前提下重構。

AI 自己就能再檢查一次。

所以未來 Code Review 時以下問題只會越來越少：

這裡為什麼用了三層 if？

這個 for 可以改掉吧？

這裡可以再抽一個 function。

不是因為這些知識沒用了，而是 AI 自己會越來越擅長處理這類問題。

---

真正需要看的，可能變成「他到底改了什麼？」

所以 Code Review 的重點可能會慢慢從：

這段 Code 寫得漂不漂亮？

昇華到：

這次到底改了什麼？

以及：

這個修改是不是我們原本要的方向？

例如一個 Agent 一次修改了十幾個檔案。

這時候真正想知道的可能不是：

第 284 行這個 if 能不能再漂亮一點？

而是：

為什麼要動這十幾個檔案？

原本需求真的需要修改資料庫嗎？

API Contract 有沒有被改掉？

權限判斷有沒有受到影響？

原本沒有要求修改的功能為什麼也被碰到了？

這次修改和一開始下的需求到底一致不一致？

這時候 Review 的層級就已經不只是 Code 了。

而是在確認：

AI 執行出來的結果，有沒有符合我們原本想解決的問題。

而如果最後 Review 發現 AI 整個方向都做錯了，有時候問題可能根本不是最後那幾行 Code，而是一開始我們就沒有講清楚。

這也回到了前面談過的 Prompt、Plan、Spec 與 Context。

---

工程師的工作是在「幫 AI 鋪路，但也要把路圍好」

一個工程師，

以前可能比較像：

需求
↓
工程師寫 Code
↓
工程師測試
↓
上線

慢慢可能變成：

需求
↓
工程師整理方向與 Context
↓
AI 規劃 / 實作
↓
工程師確認修改範圍與方向
↓
AI 修正 / 測試
↓
權限與治理機制把關
↓
上線

工程師當然還是需要懂一點 Code，可以不用太深，但至少要有點皮毛。

整體重點會逐漸從：

我能不能比 AI 更會寫這段 Code？

移到：

我能不能讓 AI 往正確的方向工作，而且不要讓他跑到不該去的地方？

這兩件事的層級其實差很多。

當 AI 越來越會寫 Code，工程師真正需要掌握的，可能已不是 Code 本身，而是：

需求的方向、系統的邊界，以及 AI 到底被允許做多少事情。

---

最後，我們把 AI 當成一個新的系統角色

以前想到 AI，容易把 AI 想成：

一個很厲害的工具。

需要時叫出來問問題。

用完就關掉。

但 Agent、MCP、企業知識、內部 API 與各種 AI Workflow 開始出現後：

AI 正在慢慢變成系統裡的一個新角色。

而且這個角色：

可以讀資料。

可以使用工具。

可以產生 Code。

可以執行流程。

甚至可能修改企業內部的東西。

既然如此，我們就不能只思考：

怎麼讓 AI 更聰明？

更重要的問題已經變成：

我們到底要怎麼設計一個環境，讓越來越強的 AI 能夠真正替我們工作，同時又不會失控。

這可能也是我聽完這些企業 AI 分享後，自己最大的收穫。

以前想的是：

AI 可以幫我做多少事情？

現在開始想的是：

如果 AI 真的可以做這麼多事情，我們準備好讓他進來了嗎？