領域專家直接用 AI 做出可操作的原型，再交給 IT 團隊整合，可以減少需求在口述、文件、開發之間反覆轉譯造成的落差。我訪談的一位具財經背景的社工，所屬的社會企業花了兩年轉型，把分工改成社工與領域專家定義需求並建立原型、AI 快速生成與修改、IT 團隊負責整合架構與正式上線。這篇文章整理導入前後的差異、雙方各自負責什麼，以及這個做法要成立需要哪些條件。
這家社會企業是什麼背景？
受訪者任職的馴錢師財商研究中心，是一間以科技賦能社會工作的社會企業，創辦人同時經營一家做人工智慧影像辨識的公司，因此組織本身有相當的資訊技術與資源。
這位受訪者擁有財經背景，工作身分是社工，所服務的馴錢師財商研究中心的經營理念，是希望用科技讓專業服務更有溫度、助人工作更有力量，官網是 familyfinhealth.com。他學習 Vibe Coding 的過程完全由公司安排，歷時兩年。書稿特別強調，這段時間不是單純導入工具，而是一場從工作流程到思考模式的全面重塑。
這一點很重要：這個案例的前提，是組織本來就有技術資源，也有人願意花兩年時間調整做法。
導入之前，社工與 IT 怎麼合作？為什麼慢？
導入前的流程是社工提出需求，經過會議討論與文件整理後交給工程師開發，一個功能從提出到上線常要數週甚至更久，對需要即時回應個案的助人工作來說節奏太慢。
上圖畫出書稿所稱的「翻譯流失」。同一個需求要走過四關：社工的敘述、PM 的規格化、工程師的開發、最後的結果，每一關都有一種損耗。
| 環節 | 發生的損耗 |
|---|---|
| 社工敘述 | 敘述發散，社工不懂程式邏輯，需求難以量化 |
| PM 規格化 | 嘗試轉成文字規格時資訊流失 |
| 工程師開發 | 知識斷層，例如工程師不理解為什麼流程裡要畫三代家系圖 |
| 結果 | 做出不合用的功能，要再開會、修改、再開會 |
圖中的案例（「流程要溫暖一點」、三代家系圖）是書稿的示意，用來說明領域知識不容易被文字規格完整保存。這也是為什麼同一個需求常常要來回確認好幾輪。
導入 AI 之後，社工做了什麼不同的事？
社工開始把日常反覆出現的需求，先用 AI 做成簡單可操作的雛型，讓同事直接試用、依回饋調整，最後才交由 IT 團隊整合進正式系統。
受訪者陸續做出幾類原型：
- 財務評估與計算工具
- 社工訪談輔助工具
- 語音轉文字與會議摘要
- 個案資料整理與風險評估流程
他不再只是提出需求的人，而是能把需求變成可測試原型的橋梁角色。過去要經過多次會議與文件往返才能確認的需求，現在拿一個能操作的原型就能驗證。當討論的基礎從抽象描述變成具體可操作的工具，跨部門之間的理解落差明顯降低，決策速度也變快。書稿以描述方式呈現這項改善，沒有提供具體天數或次數的對照數據。
領域知識是這個做法最重要的資產。例如開發財務評估工具時，許多判斷標準與計算邏輯來自多年實務經驗。如果交給工程師從零理解，要花很多溝通與修正；由熟悉領域的社工先建立初步功能，再交 IT 優化整合，不僅減少溝通成本，也提升開發的準確度。
領域專家與 IT 團隊如何分工？
領域專家負責確保領域知識正確並建立原型，AI 負責快速生成與修改功能，IT 團隊負責程式碼審查、系統整合、資安與法規合規、權限控管與整體架構穩定。
下表是書稿整理的雙方工具與職責分界。
| 類別 | 領域專家 | IT 專業團隊 |
|---|---|---|
| 主要工具 | v0（開版與 UI）、Cursor（邏輯修改）、ChatGPT 與 Claude（流程拆解）、Markdown（規格定義） | GitHub（版本控制）、雲端架構、資安規範、資料庫 |
| 主要職責 | 確保領域知識正確，例如債務公式、輔導語氣與服務邏輯 | Code Review、系統整合、GDPR 合規、權限控管與整體架構穩定 |
| 關注重點 | 功能是否真正解決社工或使用者的實務痛點 | 系統是否安全、穩定，並具備長期可擴充性 |
這張表裡最值得注意的是界線：領域專家的原型只負責驗證「這個功能對不對」，而不負責「這個系統穩不穩、安不安全」。後者交還給 IT 團隊。如果少了這道界線，原型很容易被直接當成正式系統使用。
領域專家做的原型，不能取代 IT 團隊的什麼？
領域專家的原型只能驗證功能對不對，不能取代 IT 團隊對安全、權限與長期維護的把關；涉及個案資料的系統，仍要由 IT 團隊審查後才能正式使用。
雲端安全聯盟（Cloud Security Alliance）AI 安全倡議的研究筆記指出，Vibe Coding 的應用常缺少基本的資安控制，組織有時要等到出事才發現這些應用存在；現有的 AI 風險管理框架，也沒有針對非資訊背景、自行開發與部署 AI 應用的人提供專屬指引，筆記主張要有一條讓這類開發者也能遵守的分級治理途徑（Cloud Security Alliance，2026 年 6 月）。這是該機構的研究觀點，不是對本案例的評價。
Anthropic 的 Claude Code 官方文件也提醒，要給 AI 一個它能自己執行的檢查，例如測試；若無法驗證，就不要上線（Anthropic，Claude Code Best practices）。這兩項提醒放在一起，正好說明為什麼本案例的 IT 團隊要保留程式碼審查、權限控管與合規這幾件事：原型能快速讓專家確認需求，但上線的把關需要另一組人。
這個做法成立需要哪些條件？
領域專家先做原型的做法，條件是組織有可以接手整合的 IT 團隊、領域專家願意花時間學會拆解流程與選擇模型，而且管理層接受用原型取代文件作為溝通基礎。
| 條件 | 案例中的情況 | 缺少時的風險 |
|---|---|---|
| 有 IT 團隊接手整合 | 創辦人另有 AI 影像辨識公司，技術資源充足 | 原型停在試用階段，無法安全上線 |
| 領域專家具備實務深度 | 受訪者有多年社工實務與財經背景 | 原型只是看起來能用，邏輯不可靠 |
| 專家習慣結構化描述需求 | 他把日常流程拆成步驟，並用條列方式描述 | AI 產出不穩定，反覆修改 |
| 組織給予轉型時間 | 公司安排了長達兩年的轉型 | 期望短期見效，容易半途停止 |
受訪者在這兩年裡也養成工作習慣：把日常流程拆成清楚的步驟，用條列與結構化方式向 AI 描述需求，並逐漸熟悉不同模型的特性與限制，依任務性質選擇合適工具。
常見問題
社工或其他非工程人員，可以自己做出可用的工具嗎？
可以做出可操作的原型，例如計算工具、訪談輔助工具與資料整理流程。但正式上線前，仍需要 IT 團隊處理安全、權限、整合與長期維護。
領域專家做的原型，可以直接當正式系統使用嗎？
不建議。原型的目的是驗證功能是否符合實務需求。涉及個案資料的系統，還必須由 IT 團隊確認資安、權限與法規合規。
為什麼用原型溝通，比寫文件更有效？
因為文字描述容易漏掉隱性的專業判斷與語氣要求，工程師與專家的理解也可能不同。可操作的原型讓雙方對著同一個東西討論，落差更容易被發現。
這種分工適合所有組織嗎？
不一定。這個案例的組織本來就有技術資源，也投入兩年時間轉型。沒有 IT 團隊可接手整合的組織，需要先決定由誰負責安全與維護。
導入這種協作方式，第一步該做什麼？
可以先挑一個領域專家每天重複遇到、規則清楚的小需求，讓專家用 AI 做出原型，再請 IT 人員評估整合方式，確認雙方的職責界線後再擴大。
資料來源與說明
本文整理自我在撰寫書稿期間，對十多位具有 Vibe Coding 或 AI 寫程式經驗的使用者所做的訪談，內容為受訪者及其組織的自述。「溝通效率顯著改善」未提供量化數據；訪談時間書稿未標示。
參考資料
- Cloud Security Alliance AI Safety Initiative，〈The Vibe Coding Governance Gap（研究筆記）〉，2026 年 6 月 2 日，存取日期：2026 年 10 月 19 日。
- Anthropic，〈Best practices for Claude Code〉，現行文件，存取日期：2026 年 10 月 19 日。
延伸閱讀
- 不懂程式語言，也能做合約系統嗎？一位法律背景工作者用 Lovable 的 AI 開發經驗：另一位非工程背景者，用平台做出內部系統的做法與上線前要檢查的事。
- AI 時代，為什麼懂工作流程的人也能參與系統開發？：從職務能力角度看領域知識的價值。
- 程式寫得更快，專案為什麼仍然很慢？從等待與交接找瓶頸：為什麼交接次數是專案變慢的主因。
關於作者
Claire Chang ｜ 企業 AI 導入與流程轉型顧問。專注於 AI Agent 架構設計、ERP 系統整合與企業 AI 治理。
首次發布：2026-10-19