前言
去年底，高階主管突然發信成立專案小組，並指派我協調會議時間。起初我以為這只是身為資淺人員的行政庶務，但在會議結束的當下，我才意識到這並非一場討論，而是既定的佈達——不出所料，我成了部門的 AI 導入窗口。
驚訝之餘，我也意識到這將是一段未知的旅程。這四、五個月的經歷，從最初的錯愕到後來的摸索，正是我希望記錄下來的實戰心得。窗口之外的視野
作為 AI 導入窗口，我不希望自己僅止於訊息的轉接者。尤其在 AI 生態快速演進的當下，能在企業資源支持下，接觸第一手的合規 AI 工具，是極為難得的契機。
然而，大企業的導入不同於新創的靈活，我們必須在人員結構、工具限制與技術債之間尋求平衡。這讓我學會從更高的視角，去審視新技術如何軟著陸。
團隊結構下的導入思考
我們部門的開發與規劃人員比例約為 7:3。對開發者而言，AI 的價值直觀地體現在程式碼分析與重構；但對規劃人員來說，長期依賴 Word、PPT 的工作流，若強行要求轉換至 Markdown 等 AI 友善格式，容易引發反彈。
此外，侷限於對話框（Chat-based）的多模態提示詞工程，成果上下限極大，若期待過高，反易造成落差。因此，我的策略轉向「分眾引導」：針對技術人員強調效率解放，針對規劃人員則著重降低門檻，兼顧不同職能的接受度。
IDE 雙軌制的現實
There are only two kinds of languages: the ones people complain about and the ones nobody uses. ——Bjarne Stroustrup
這句話放在 IDE 之爭同樣貼切。最深刻的體會來自 Eclipse 的滯後——直到 2025 年 2 月 13 日，官方才推出 GitHub Copilot 的擴充套件。即便功能逐步補齊，但與 VS Code 相比，同樣的提示詞在 Eclipse 上往往顯得笨拙。
這迫使我採取「IDE 雙軌制」的折衷方案：不奢望將舊專案全面遷移至 VS Code，而是引導同仁依場景切換工具。既然訂閱費已經投入，身為窗口，我的責任就是在工具的限制中挖掘最大潛能，避免資源閒置。
內部培訓與知識共享
為了讓工具落地，我規劃了部門內部的教育訓練，從安裝設定到程式輔助、邏輯分析，甚至是用 AI 寫測試與註解的實務演示。同時，我也展示了如何利用 AI 處理日常文書腳本，讓非開發人員也能看見可能性。
此外，我將外部廠商的培訓資源與內部分享內容，逐步彙整至共享知識庫。這些累積讓 AI 的導入不再是個人的單打獨鬥，而是轉化為部門可持續查詢與迭代的共同資產。
導入過程的反思
回顧這段時間，我逐漸理解 AI 的價值不僅在於程式碼生成的快慢，更在於它如何衝擊既有的工作文化。作為窗口，我的角色與其說是「導入工具」，不如說是「管理預期」——在技術的許諾與現實的限制之間，協助團隊找到最舒適的施力點。
這場旅程才剛開始，而核心始終不變：技術只是槓桿，如何讓「人」願意使用並從中獲益，才是導入成功的關鍵。
