# Dcard 的 100 個 Agent：從「買工具」到「變流程」，AI 轉型的真正戰場
同一天，另一場演講
2026 年 7 月 21 日，我在世貿中心待了一整天。
早上聽了 BCG X 吳學林談 AI 轉型的戰略層次——Deploy、Reshape、Invent——我花了好幾個小時消化，回家後連夜寫了兩篇文章分享。本來以為這就是今天最大的收穫了。
結果下午其中一場講座，Dcard 執行長林裕欽（Kytu Lin）走上台，用一句話就把我從椅子上拉了起來。
「我們內部現在有超過 100 個 AI Agent 在生產環境中運行，超過 90% 的團隊成員每週透過 Agent 完成任務。」
一百多個 Agent。不是實驗、不是 prototype、是真正跑在生產環境裡的。
這篇文章，我想用 CJ 哥的視角，把這場演講最有價值的內容拆給你看——因為這不是 Dcard 的故事，而是每一位企業主、每一位經理人接下來兩年內都必須面對的真實課題。
不是「外掛」AI，是長出 Agent 的骨架
林裕欽提出的第一個觀點，就點出了多數企業轉型卡關的核心原因：
如果你只是把 AI 當成一個「外掛」貼在既有的流程旁邊，你什麼也不會改變。
這完全呼應我早上從 BCG X 聽到的 Deploy 層次——把 AI 疊加在現有流程上，效率可能提升 5% 到 10%，但這個改善很快就會被競爭對手追平。
Dcard 的做法完全不同。他們選擇的不是「導入 AI 工具」，而是讓 Agent 直接重構工作流程本身。
舉三個內部案例，我認為非常有啟發性：
案例一：新人 Onboarding
過去一個工程師加入 Dcard，要花好幾個月才能搞清楚程式碼架構、開發流程、各團隊的協作方式。這不只是 Dcard 的問題，任何科技公司、甚至任何有技術團隊的傳產企業都有這個痛。
Dcard 用 Agent 串接 Quip、GitHub、內部分散式文件，讓新人可以直接透過 Agent 查詢研發文件與實作指南。
結果呢？新人的 Time-To-Value——從入職到實際產生價值的時間——從數個月縮短到數天。
案例二：數據分析
數據這條路，我相信所有做過轉型的人都有共鳴。企業裡最常見的場景是：業務端想要一個數字，要等 BI 團隊排期、來回確認定義、最後拿到報表的時候決策時機已經過了。
Dcard 用 Agent 視覺化數據血緣關係，前端夥伴可以直接用自然語言查詢內部數據與報表關聯。不用開 ticket、不用等排期、不用來回確認定義。
CJ 哥點評： 這件事情背後的關鍵不是技術，是「數據定義的標準化」。很多企業連自家系統裡的「活躍用戶」定義都還沒統一，就想一步登天做 AI——這才是真正的瓶頸。
案例三：商業提案
Agent 綜合客戶歷史、競品資訊、內部資源與市場趨勢，自動生成提案初稿。業務團隊不再需要花三天整理資料、一天寫報告——他們可以把精力花在真正重要的事情上：了解客戶、建立關係、策略思考。
Meta Data：AI 從「閱讀器」變「同事」的關鍵
林裕欽分享了一個我認為非常有深度的觀點。
原始的數據對 AI 來說就像一本看不懂的書——它看得到字，但讀不懂意思。要讓 AI 從「閱讀器」轉變為可以協作的「智慧同事」，你需要餵給它的不只是數據，還有情境知識（Meta Data）。
什麼是情境知識？就是那些老員工腦袋裡知道、但從來沒有被寫下來的東西：
- •這張報表的數據是在什麼情境下產出的？
- •這個欄位的業務定義是什麼？
- •這條規則在什麼條件下會被觸發？
- •這個流程有哪些例外情況？
Dcard 的做法是盤點並串聯這些 Meta Data——業務規則、流程邏輯、權限設定、業務定義——全部餵給 Agent。當 Agent 理解了這些情境知識，它才能真正理解企業在做什麼，而不只是執行 FAQ 式的問答。
CJ 哥點評： 講到這個我就很有感觸。很多老闆來找我，劈頭就問「CJ 哥，我們導入哪套系統好」。我通常會反問：「你知道你公司的業務規則，有幾成是寫在系統裡的？幾成是在老員工腦袋裡的？」多數人回答不出來。因為他們連 Meta Data 是什麼都沒想過。但這個問題不回答，你花再多錢買 AI 工具，效果也只是把錯誤的流程加速而已。
Time-To-Value：新的衡量標準
傳統的 AI 衡量指標是 Token 用量、API 呼叫次數、模型準確率。
林裕欽說：在 Agent 時代，這些都不重要了。真正要看的只有一個指標——Time-To-Value。
從提出需求到解決問題，需要多久？從新人入職到能獨立貢獻，需要多久？從客戶拜訪到提案產出，需要多久？
這個指標的轉變，其實代表著更深層次的認知升級：我們不再問「AI 的表現如何」，而是問「AI 讓人的表現變得多好」。
CJ 哥點評： 這個觀點讓我想到，很多企業導入 CRM 的時候，衡量標準是「導入完成率」和「使用者覆蓋率」，而不是「業務達成率提升多少」和「客戶滿意度改善多少」。類似的錯誤正在 AI 領域重演。如果你還在用 Token 用量來衡量 AI 投資回報，你很可能已經在錯誤的方向上跑了很久。
擺脫「沒有案例」的惡性循環
林裕欽提出了台灣企業轉型最真實的困境：
沒有案例 → 不相信 → 不重構 → 生不出案例 → 更沒有案例。
這個死循環，我見過太多次了。中小企業主說「等我們看到別人成功再做」，問題是別人也跟你說一樣的話。全台灣都在等第一個人跳下去。
Dcard 的做法很聰明。他們創造了一個叫做 前線部署工程師（Forward Deployed Engineer，簡稱 FDE）的角色——不是空降的顧問，而是真正進場、動手做出案例的人。FDE 進到各團隊，用小規模的 Agent 實驗證明效果，讓團隊親眼看到 Agent 能做什麼。
等到案例做出來了、團隊相信了，再透過 GNTC（Dcard 在 2026 年 5 月成立的企業 AI Agent 事業體）提供的工具將這些案例規模化，複製到更多場景。
從「證明給你看」到「讓你自己做」，這就是突破死循環的實際路徑。
CJ 哥點評： 這就是為什麼我總跟客戶說，不要一次規劃一年的數位轉型計畫。與其花三個月寫厚厚一本白皮書，不如花一週做一個最小的實證（Proof of Concept），讓老闆親眼看到成果，再決定要不要繼續投。從「做一個案例」開始，不要從「寫一份策略報告」開始。
取代的是 Task，不是 Job
演講最後，林裕欽提到一個我認為每一位經理人都應該貼在辦公室的觀點：
AI 取代的是任務（Task），不是整個職位（Job）。
但這不表示一切安好——因為當 AI 可以執行某些任務之後，人類的工作結構就改變了。原本工程師做 A、B、C 三件事，現在 AI 取代了 B，工程師的職責就變成了 A、C、D，其中 D 是全新的任務。
這導致了團隊成員之間的職能邊界開始模糊。工程師需要理解 BI 分析，行銷人員需要懂技術邏輯，營運團隊開始涉足數據管理。
林裕欽用一句話總結了這個趨勢：「角色融合是必然的。問題不是要不要，而是你準備好了沒有。」
CJ 哥點評： 今年以來，我輔導的每一間企業都在面對這個問題。技術部門說「這些 AI 工具我們來管」，業務部門說「但數據是我們的」。界線越來越模糊，衝突也越來越多——但這個模糊，恰恰是組織長出新能力的起點。作為領導者，你的任務不是畫清界線，而是建立一個讓大家願意跨界合作的文化。
對台灣企業的三個提醒
從 BCG X 的 10-20-70 到 Dcard 的 100 個 Agent，一整天聽下來，我歸納三個今天最想對你說的話：
1. 起點是實驗，不是戰略規劃
不要寫半年的 AI 轉型白皮書。找一個最痛的問題，用一週做一個 PoC。三個月後再來看該不該規模化。
2. 重點不是 AI 工具，是情境知識
你要盤點的不是「該買哪個模型」，而是你的業務規則、流程邏輯、老員工腦袋裡的經驗——這些才是 AI 能不能真正幫上忙的關鍵。
3. 衡量標準從「技術指標」轉向「價值實現時間」
不要問 Token 用了多少、API 叫了幾次。問：這件事以前做多久，現在做多久？
你的企業現在在哪個階段？正在做 AI 實驗？已經有 Agent 在跑？還是還在等「別人的案例」？
留言告訴我，我們一起討論。