最近我在整理自己在Github上的靜態網頁。以往要修改網頁內容，例如調整一個導覽列的顯示問題，我必須到Github打開原始碼，找到對應的 CSS 或 HTML 標籤，修改後存檔，再推送到 GitHub 。這個過程說不上難，但對於經常需要更新資訊的人來說，確實十分瑣碎。
我就想，既然現在的 AI 工具（例如 Codex）已經具備強大的程式理解能力，如果我直接開放瀏覽器的權限給它，讓它自己上去看問題、自己改代碼、最後自己推送到 GitHub，這會省下多少功夫？為此，我進行了一次實作。
我打開了 Chrome 瀏覽器的遠端偵錯功能（Remote debugging），Chrome將端點設在 127.0.0.1:9222。這個動作等於是把這個 Chrome 實例的控制權交給了外部工具。接著，我給 Codex 一個明確的指令：修改我個人網站頂部導覽列無法固定，以及標籤點擊失效的問題。
接下來的幾分鐘，Codex 就像一個坐在我旁邊的工程師。它透過瀏覽器實際檢視了網頁，找出兩個根本原因：後段 CSS 設定衝突，以及右側區塊攔截了滑鼠點擊事件。查出原因後，它確認了這是放在我的Github的網頁，它下載了html檔案，並著手修改。
過程中，我看到它打開了瀏覽器，要了更多本機修改的權限，然後看著它即時改著網頁、測試。這一件就在我眼前發生，然後看到網頁就逐步改好了。
在我確認本機測試沒問題後，我直接下令「推到 Github」。在這過程中，它發現系統被 Git 擋住，因為這台機器的環境沒有設定使用者名稱與信箱。它沒有停下來等我救援，而是自動去查了這個專案過去的 commit 紀錄，抓出我的作者資訊並補上設定，最後順利完成推送。整個煩人的除錯與上傳過程，在幾分鐘內一氣呵成。
10多秒後，我開了我的網頁，是的，就是我本機修改的新版本，上線了。
我呆了一會，「啊，好絲滑～但是，管理者、職場人士需要知道這種東西嗎？」
再認真想一想，也許有些可談的議題！
過去，一個簡單的數位產品修正需要經過「發現問題 → 提報需求 → 工程師尋找錯誤 → 修改 → 測試 → 部署」的冗長流程。跨部門溝通的成本，往往遠遠高於實際修改代碼的時間。
當 AI 取得系統操作權限，它將除錯、修改與部署整合成一個單一且連續的動作。這代表企業在處理明確且例行性的任務時，可以大幅縮短反應時間。管理者的焦點可以從「追蹤進度」轉移到「確認目標是否達成」，因為中間的執行落差被機器搞定了。
也就是說，如果，一位主管懂得利用AI與自動化工具，也「敢」下指令，那麼，自己部門的「小事」就自己搞定了啊（通常對資訊單位同仁，這實在是不緊急也不太重要的任務）。
但是，主管真的敢這樣這樣做？
在我個人的情境，我開啟 `chrome://inspect/#remote-debugging`，等於讓外部程式可以讀取我這個瀏覽器上的所有資料，包含 Cookie、已儲存的密碼、登入狀態與瀏覽紀錄。在這次的個人實作中，Codex 順利幫我修好網頁。
若是在中小企業的工作情境，業務主管真的這樣幹了（假設他莫名其妙有了很多權限），改完了他部門的網頁與產品頁面，一切都搞定了，接下來可能是一連串的混亂與爭吵：「你知道這樣很危險嗎？」、「你知道AI還改了什麼嗎？你又不懂我們的架構！」、「不然咧，一點小事，ticket都開出去多久了，你們做了什麼？」、「很行，很好，以後你就自己搞吼，出事你自己扛喔！X！」
所以，我們該給主管、同仁這樣的「力量」嗎？還是，避免衝突，乖乖的回到專業分工，各自顧好自己的小天地？
我覺得，這就是現在我們看到「AI賦能」這個理想無法落實在企業流程、造成規模化改變的根本議題。
當技術走得比組織架構與工作流還快，那就先從「沙盒」開始。對於想要打破僵局的主管，或是希望提升整體反應速度的企業，其實不需要一開始就全面開放權限：
以我之前的範例，別一開始就拿正式上線的產品或對外官網開刀。資訊單位可以切出一個測試環境，或是一個不會影響主系統的行銷活動靜態網頁專案。在這個「就算弄壞也無所謂」的區域裡，讓業務或行銷主管帶著 AI 去實作。這能讓非技術人員熟悉 AI 的能力邊界，也讓 IT 人員觀察 AI 到底會搞出什麼破壞。
當然，前提是資訊人員願意花點時間開一個「沙盒」給大家玩（資訊人員：不要搞我好嗎？）。
若有機會雙方主管坐下來，列出一份明確的白名單。例如：修改網頁文案、替換圖片、調整按鈕顏色或是單純的版面微調。這些不涉及核心資料庫與商業邏輯的任務，就開放讓業務單位用 AI 工具自己處理。超過這條線的，就乖乖按流程開 ticket。
也或許我太悲觀，IT人員或許很歡迎前線部門自己搞定？與其讓 IT 每天花時間處理那些不緊急又沒成就感的微小修改，不如讓業務單位自己用 AI 改好代碼，然後發出合併請求。IT 只需要花幾分鐘檢查程式碼有沒有安全漏洞或明顯的架構錯誤，確認沒問題就放行。
若是對於大家坐下來談、畫定權限，總覺得困難重重（光是開口就覺得很累很累…）。那就找一個科技接受度高、平常就喜歡嘗試新工具的小團隊，配上一位思維比較開放的 IT 人員，讓他們跑個一個月。看看實際能省下多少時間，又會碰到什麼困難。把這份實戰經驗整理出來，再來決定要不要擴大到其他部門。
這樣想一想，組織的未來運作想像是非常不同的！
