在企業內部推廣跨部門 AI 工作坊時，許多人得知後的第一個疑問往往是：「既然你在帶大家用 VS Code 和 AI 做自動化，為什麼不把 IT 部門裡的專業程式設計師、軟體工程師一起找來？有他們在旁邊指導，非技術同仁不是能學得更快嗎？」

甚至連幾位同在 IT 單位的工程師同事，私下也曾好奇地問我：「這種課程怎麼沒發給我們？我們也想看看能怎麼玩。」

面對這些詢問，我的態度始終非常堅決：在現階段的非技術賦能工作坊裡，專業的程式開發者絕對不能進場。

這項決定看似不近人情，甚至違反了傳統企業培訓「大家一起學、互相切磋」的直覺。但在 IT 系統架構與組織心理學的深層視角下，這是一道經過深思熟慮、為了保護非技術同仁初生學習火種的「無形防火牆」。

一、兩個維度的世界：軟體工程標準 vs 業務原型探索

第一個將兩者分開的原因，在於工作任務的本質、安全等級與驗收標準存在著天壤之別。

專業 IT 工程師在企業內開發程式碼，面對的是極其嚴苛的「企業級軟體工程體系」：

系統必須直接連線生產環境（Production Database）、調用核心業務 API；

程式碼必須遵守嚴格的架構規範，經歷 Git 分支管理、代碼審查（Code Review）、弱點掃描（SonarQube）、靜態資安檢測；

任何功能上線，都必須通過單元測試（Unit Test）、整合測試、迴歸測試，以及長達數週的使用者驗收測試（UAT）。

在這種高壓環境下，工程師必須對每一行程式碼的穩定性、擴展性與合規性負全責。哪怕只是少加了一個例外處理（Exception Handling）或資料庫鎖定機制，都可能導致核心服務中斷或資料毀損。即便工程師導入了 AI 協同開發，他們的思維依然被深深刻上「嚴謹、規範、零失誤」的工程烙印。

但我們跨部門工作坊的初衷是什麼？

我們是在完全隔離的本機沙盒中，引導非技術同仁解決他們手頭上的日常雜務——把混亂的文字轉成報表、比對兩份合約的差異、從繁雜的會議記錄中抓出待辦事項。

這本質上是「敏捷的個人業務原型探索」，追求的是「能不能在五分鐘內幫我省下半小時」，而不是「這段程式碼能不能承受每秒一萬次的高併發請求」。

如果把這兩群人放在同一個教室：

對工程師而言，非技術同仁用自然語言拼湊出的微型腳本簡直是「毫無章法、缺乏架構的玩具代碼」，工程師會本能地想去修正語法、重構架構、要求加上嚴謹的型別定義；

對非技術同仁而言，工程師隨口丟出的「這沒有做例外捕獲」、「資料庫連線池會爆掉」、「缺乏單元測試」等專業術語，會像迎頭痛擊的悶棍，瞬間將他們初次體驗 AI 的成就感擊得粉碎。

標準錯位，只會帶來彼此的折磨。

二、「權威在場」的沉默螺旋：專業碾壓對心理安全感的致命打擊

比起技術標準的落差，更致命的摧毀力量來自於心理層面。

社會心理學中有一個著名的概念叫「評價顧慮（Evaluation Apprehension）」：當一個人在嘗試新事物時，如果現場存在被公認的「專家或權威」，當事人會產生強烈的焦慮與被審視感，進而本能地退縮到最保守的防衛姿態中。

試想一下這個場景：

一位完全不懂寫程式的行政或後勤同仁，好不容易鼓起勇氣在終端機裡按下一段由 AI 產生的指令。這時，如果隔壁坐著一位天天在敲代碼的軟體工程師，這位同仁的第一反應是什麼？

他會極度害怕犯錯。他會擔心自己提的 Prompt 顯得很愚蠢、擔心自己看不懂終端機的報錯會被看不起。本來可以在螢幕前放膽亂試、大笑著除錯的輕鬆氛圍，在專業審視的無形目光下，瞬間變成了令人窒息的「技術考場」。

緊接著發生的，就是「對標準答案的盲目依賴」。

一旦專家在場，非技術同仁會立刻放棄自主思考與試錯的過程。只要一遇到報錯，他們的直覺不是去看 AI 給的錯誤提示，也不是嘗試用自然語言去引導 AI 修正，而是轉頭求助：「工程師，這段報錯是什麼意思？你直接幫我改好不好？」

「代勞」是學習最大的毒藥。

當非技術人員開始依賴工程師給出「正確答案」，他們就徹底失去了親手駕馭工具的肌肉記憶。沒有親自跌倒過、沒有親自抓到過 AI 的幻覺破綻，他們永遠無法建立起真正的人機協同直覺。

三、扼殺「100 倍思維」的元兇：過早的技術可行性審查

我們在 Day 04 談過「跳脫線性工時，啟動 100 倍思維」的心法。100 倍思維的核心，在於敢於打破現有流程的邊界，大膽重構問題的定義。

在推動 AI 落地時，非技術同仁最寶貴的資產，恰恰是他們的「非專業性」。因為他們不懂底層程式的限制、不知道傳統系統介接的困難，他們往往能憑藉對業務的深刻理解，提出極具顛覆性與想像力的需求：「能不能把全年度上百份不同格式的專案請款單，一口氣全部餵進去，直接幫我產出審計風險報告？」

這種天馬行空的發想，正是業務創新的起點。

但如果現場有資深工程師在場，傳統的技術工程思維往往會第一時間跳出來踩煞車：

「這行不通，格式不統一 LLM 會解析失敗。」

「系統 API 根本沒有開這個接口。」

「Token 限制會超過，成本太高不符合效益。」

工程師說的句句屬實，在大型系統架構的維度上完全正確。但「過早的技術可行性審查，是扼殺微型創新最鋒利的屠刀。」

在探索的最初期，我們需要的是保護那些看似荒謬、卻直擊業務痛點的想像力。哪怕一開始只能做到 30%、哪怕只是一個漏洞百出的原型（PoC），它都為團隊點燃了一盞燈。如果一開始就讓工程思維的條條框框介入，大家就會退回「只敢讓 AI 寫寫客套回信」的低階應用，先前建立的 100 倍思維將在瞬間蕩然無存。

四、架構師的溫室哲學：分軌並行，各得其所

作為一名長年在 IT 底層維運基礎設施的架構師，我無比敬重軟體工程的嚴謹與規範。我不讓開發同仁進場，絕非輕視工程專業，而是深知「生態的演化需要適當的棲地隔離」。

這就像一座森林植物園：

參天古木有它抵抗狂風暴雨的深厚根基，必須遵從嚴苛的自然法則（企業級軟體工程與 UAT）；

但那些剛剛破土而出的脆弱幼苗，必須被悉心安放在溫室之中，給予足夠的陽光與泥土，容許它歪斜生長，容許它自由抽芽（跨部門工作坊）。

在我們的企業藍圖中，這兩群人終究會在高處相會。但絕不是在第一天。

唯有讓非技術同仁在沒有審視眼光的安全空間裡，狠狠地跌倒、興奮地試錯、親手養出自己的第一位專屬助理，他們才能真正長出面對技術的自信與底氣。

當有一天，業務同仁拿著自己跑順的微型架構原型，主動敲開 IT 部門的門，用清晰的邏輯與工程師探討「我們如何把它規格化、接入公司的正式 API」時，那才是兩股力量真正完美融合、引爆組織變革的最佳時刻。