Dcard GNTC 轉型解剖：台灣第一家 Agent-Native 企業，你能複製的 Playbook

2026 年 5 月，Dcard 宣布成立 GNTC 企業 AI 代理業務，林裕欽花一年跑遍財會、廣告、產品、行銷各部門，把廣告部門的流程時間縮短逾八成，再把這套方法論產品化賣給其他企業。這件事的真正意義不在於「又一家 AI 新創」，而在於：這是台灣第一次有科技公司把 agent-native 轉型的內部 playbook 拆解公開。本文不重複媒體報導的新聞事實，而是從從業者視角問：這套邏輯中小企業能複製嗎？一個人能用嗎？哪些地方最容易出錯？

TL;DR

• Dcard 廣告部門用 EntryDesk 建立 AI Center 後，整體流程處理時間縮短逾八成，但這是廣告部門的數字，不是全公司平均
• GNTC 真正在賣的是 FDE（Forward Deployed Engineer）方法論，EntryDesk 是載體，諮詢能力才是 IP
• Discover-Build-Scale 三段框架可縮比例到一人：從一個最耗時的重複流程開始，不需要顧問
• 根據 xtract.io 產業分析，2025 年 40% 企業嘗試 agentic AI，但只有 11% 到達 production，最大陷阱是 agent washing
• EntryDesk 有免費版可自助起步，但跑通第一個場景預計需要 2 到 4 小時的設定投入

Dcard 為什麼做 GNTC？從流量變現到 B2B SaaS 的策略邏輯

很多人看到 GNTC 的第一反應是：「Dcard 跟風 AI 熱潮」。但從林裕欽接受 bnext 和 meet.bnext 的多篇專訪來看，背後邏輯其實更務實。

Dcard 的廣告平台業務高度依賴台灣年輕族群流量，流量變現有自然天花板。2025 年 3 月起，林裕欽決定親自擔任全公司 FDE（Forward Deployed Engineer），逐一拜訪各部門，尋找可以用 AI agent 改造的工作流程。這不是管理層派下去的任務，而是 CEO 親自做的田野調查。

一年後，廣告部門、財會部門、產品部門都各自跑出了具體成果。這套在內部反覆驗證過的 know-how，自然成為可以對外販售的服務。GNTC 是把這個過程產品化的結果，不是憑空創業。

值得注意的是，GNTC 在 2026 年 5 月才正式對外，林裕欽本人親任第一位業務員。現階段公開資料中，Dcard 本身就是最完整的客戶案例，外部企業的成效紀錄仍在積累中，這是評估 GNTC 服務時需要帶著的意識。

另一個常見問題是：做 GNTC 會不會分心害到 Dcard 本業？根據 bnext 專訪的說法，林裕欽採用「75%+75%」的精力分配框架，GNTC 開發的工具本身直接在 Dcard 內部持續使用，兩者是互利關係而非零和競爭。

廣告流程縮短逾八成，實際上改了什麼？

「逾八成」是 GNTC 對外報導中最常被引用的數字，但它的範圍比多數讀者以為的要窄。

根據 INSIDE 和 bnext 的報導，這個數字指的是廣告業務部門使用 EntryDesk 建立 AI Center 之後，整體廣告流程的處理時間縮短幅度。具體改了三個層次：

第一層，資料查詢自動化。過去廣告人員需要人工拉取各平台報表，現在用自然語言提問即可取得整合後的數據，不需要等 BI 團隊或手動整理 Excel。

第二層，提案流程加速。資料規格文件的產出從過去需要數天多人協作，縮短為 10 分鐘內可以產出可 review 的草稿。提案時間整體從一週縮短為數天。

第三層，素材上架自動化。重複性的廣告素材操作被 agent 接管，減少手動點擊的工作量。

財會部門的改造成果是另一個維度：月結流程改造後，加班時間減少，同時提升了錯誤偵測能力。這兩個部門的成果性質不同，前者是速度指標，後者是品質和工時指標，不能直接套用「八成縮短」去類比。

對其他行業的讀者來說，最有參考價值的邏輯是：如果你的工作流程中有「需要查多個資料來源，整合後才能產出一份報告」這種模式，這類任務最接近廣告部門被改造的場景，最容易 agent 化。文案、財務、行銷分析都有類似的流程結構。

Agent-Native vs 買一堆工具，本質差異是什麼？

理解 GNTC 的定位，需要先釐清三個層次的區別。

工具採購是最初級的：你把 ChatGPT 或 Notion AI 加進工作，但工作步驟本身沒有改變，只是單點任務被 AI 接管。

流程重構是中間層：你重新設計工作步驟，讓 AI 協助完成某些環節，但仍然由人做最終確認和串接。

Agent-native 是最高層：agent 成為工作流程的執行主體，人負責監督和例外處理。工作流程的設計邏輯從「人做什麼」變成「agent 做什麼，人在什麼時候介入」。

這也解釋了為什麼 GNTC 和傳統 RPA 導入不同。RPA（機器人流程自動化）走固定腳本，能處理結構化、步驟明確的任務，但遇到例外就會卡住。AI agent 能推理、處理非結構化資料，在執行過程中動態調整。根據 xtract.io 的產業分析，企業資料中有約 80% 是非結構化的，這是 RPA 應付不了的地方。2026 年的最佳實踐是混合架構：RPA 處理固定流程，AI agent 處理需要推理的例外部分。

常見的比較問題是：EntryDesk 和 n8n、Make，或是和 Claude Projects + Notion AI 組合有什麼差異？

EntryDesk 的核心差異是企業級 governance 層：內建權限管理（誰能存取哪個 agent）、audit trail（每次執行有完整紀錄）、ISO 27001 認證、支援私有部署。這些功能對需要合規的企業（金融、醫療、政府）有實際意義，對個人工作者則可能是過度設計。

n8n 更自由、可高度客製化，但需要技術能力。Claude Projects 適合個人知識管理和對話式工作流，但缺乏跨工具串接的 governance 機制和完整 audit log。

如果你是一個人在用，Claude Projects 加上 Zapier 或 Make 通常已經夠用。如果你是企業、需要讓多個部門共用 agent 並追蹤執行記錄，EntryDesk 的定位才真正有意義。

想更深入了解 AI agent 的選型邏輯，可以參考 AI Agent 入門指南：新手從哪裡開始。

FDE 思維是什麼？一個人能用嗎？

FDE（Forward Deployed Engineer）原本是矽谷新創的常見角色，指嵌入客戶組織內部、用工程師思維解決業務問題的工程師。林裕欽把這個角色移植到 Dcard 內部：自己扮演全公司的 FDE，逐一拜訪各部門，找出可以轉換為 agent 的工作流程。

FDE 思維的核心邏輯在 bnext 專訪中有一句很清楚的描述：「抓資料就是你用自然語言問問題，把它變成一段程式碼。」把這個邏輯展開，就是 Discover-Build-Scale 三段框架：

Discover（發現）：用自然語言描述你的工作需求，找到「我需要哪些輸入，我要哪種輸出」的固定模式。這個過程不需要工程師，只需要你能清楚描述自己的工作流程。

Build（建置）：把這個固定模式轉換為可重複執行的 agent，串接你需要的工具和資料來源。

Scale（擴展）：讓更多人（或更多流程）複用這個 agent，累積使用數據並持續優化。

這個框架的核心不依賴團隊規模。企業版和個人版的差異只在執行層面：

企業路徑：有專職 FDE 角色（或指定一個人兼任），多部門同步做 Discover，再由 FDE 統籌 Build 和治理架構。

個人路徑：你自己同時是 FDE 和執行者。從一個最耗時的重複流程開始，不需要 20 人團隊，也不需要顧問。

我在試著理解 FDE 思維時，發現最有用的起手方式是強迫自己寫下一個流程的輸入和輸出。以撰寫每週工作摘要為例：輸入是「Slack 訊息記錄 + 完成的 GitHub PR + 行事曆事件」，輸出是「200 字的週報草稿」。一旦寫清楚這個結構，就能判斷它能不能被 agent 化。

個人版 FDE 起手式三步驟：

1. 列出每週做超過兩次的重複任務
2. 用一句話描述每個任務的輸入和輸出格式
3. 用 EntryDesk 免費版或 Claude Projects 建第一個 agent 測試

如果對 Claude 在 agent 架構中的角色有更多興趣，可以參考 Claude Managed Agents 台灣實用指南。

起步指南：EntryDesk 免費版能做到什麼？現實設定成本是多少？

EntryDesk 的官方網站確認有免費版，功能包含 30+ 工具整合（Slack、Gmail、Salesforce、BigQuery、Notion、Jira 等）、no-code agent 建置、ISO 27001 認證，並支援 Claude、GPT-4、Gemini 等主流模型。

聽起來很全面，但有幾個現實成本需要誠實說清楚。

第一，設定時間不是零。根據 bnext 的 365 天實戰紀錄，Dcard 在早期導入時遇到的真實障礙之一，是「20 分鐘安裝時間讓員工感到挫折」。對於有工程師支援的科技公司尚且如此，對於完全沒有技術背景的用戶，跑通第一個場景預計需要 2 到 4 小時，包含理解工具邏輯、串接整合和測試流程。

第二，CEO 親任業務員意味著企業版仍需人工接洽。GNTC 目前已對外服務，但並非線上直接購買，需要與業務端接觸。對預算有限的中小企業，建議先用免費版建立一個具體場景，累積真實問題後再接洽諮詢，溝通效率會高很多。

第三，vendor lock-in 的風險需要自行測試。目前已驗證的公開資料中，EntryDesk 的資料匯出政策沒有明確說明，這是真實的待確認風險。建議在試用期間主動測試：你建立的 agent 邏輯、整合設定、歷史執行記錄，能不能匯出到其他平台？

建議第一個場景：把 Gmail 收件匣的關鍵主旨摘要，自動推送到 Slack 指定頻道。這是一個 30 分鐘內可以驗收的場景，能幫你測試整合是否順暢，也能讓你的團隊看到具體成果。

風險揭露：三個讓轉型失敗的陷阱

根據 xtract.io 的產業分析（2026 Q1，Tier 3 產業觀察），2025 年有 40% 的企業嘗試 agentic AI，但只有 11% 真正到達 production。失敗率接近九成，主要來自三個反覆出現的陷阱。

陷阱一：Legacy Friction（舊系統阻力）

現有的系統和工具，很多是為「人點擊」設計的，不是為「agent 調用 API」設計的。當你試圖讓 AI agent 接管一個流程，卻發現核心工具沒有 API、或者需要 VPN 才能存取，這就是 legacy friction。Dcard 能相對順利轉型，部分原因是本身是科技公司，技術棧相對現代化。傳統企業面對的這個障礙會大很多。

解法：在 Discover 階段，就要確認你要 agent 化的流程，其中的每一個工具都有可調用的 API 或 webhook。

陷阱二：Agent Washing（偽 Agent）

這是 2026 年最需要警惕的認知陷阱：把能接受提示詞的 chatbot 包裝成「AI agent」，名字很炫，但實際上每個步驟都需要人工確認，沒有真正的跨工具自主執行能力。

測試一個工具是否真的是 agent，可以問三個問題：（1）它能呼叫外部工具嗎？（2）它能在沒有人監督的情況下完成 3 步驟以上的任務嗎？（3）它有記錄每次執行的 audit trail 嗎？三個都是「是」，才算真正的 agent。

陷阱三：Data Bottleneck（資料不 AI-ready）

agent 的能力上限由資料品質決定。如果你的資料分散在多個系統、格式不統一、沒有搜索性，agent 能做的事就非常有限。Dcard 的廣告部門之所以能縮短逾八成，很大程度上是因為他們本身就有結構化的廣告資料和清晰的 KPI 定義。

解法：在導入任何 agentic 工具之前，先盤點你的資料現狀：核心業務資料在哪裡？有沒有 API 可以查詢？格式是否一致？

最後回應一個合理的懷疑：GNTC 目前有沒有台灣外部企業的真實案例？根據目前已驗證的公開資料，Dcard 本身是最完整、最具說服力的案例，GNTC 是 2026 年 5 月才對外的新服務，外部客戶的成效紀錄正在積累中。這不是理由不去嘗試，而是提醒你在評估時，帶著這個資訊，而不是把 Dcard 自己的成果直接套用為「外部客戶平均值」。

結論：Agent-Native 的終點不是工具，是思維方式的重設

Dcard GNTC 的真正貢獻，不是又一個 AI 平台，而是第一次把台灣企業 agent-native 轉型的完整路徑公開拆解，讓中小企業和獨立工作者有具體的參照點。

從這個案例中，最值得帶走的不是「用 EntryDesk」，而是 FDE 思維本身：先 Discover（把工作流程用輸入和輸出描述清楚），再 Build（從最小的一個 agent 開始），最後 Scale（讓更多流程可以複用）。這套邏輯不依賴大公司資源，一個人也可以從今天開始。

至於 GNTC 和 EntryDesk 是不是適合你的工具，答案取決於你的流程性質、技術棧現代化程度，以及對合規的要求。不需要現在就決定。

今天花 15 分鐘，列出你每週做超過兩次的重複任務。 這就是你的 Discover 清單。從清單最上面的那件事開始，描述它需要哪些輸入、要什麼輸出，然後問自己：這能被 agent 做嗎？

如果你的答案是「可能可以」，那就已經是最難的一步了。