前幾天看到Karpathy的〈2025LLMinReview〉，我有一種被「年度回顧」正面擊中的感覺。
但更精確地說：這一年我最大的改變，不是「我更會用AI」——而是Dcard的工作方式，開始被Agent重新定義。無論是經營管理、工程開發，或是我們看待世界怎麼運作的方式，都發生了很大的改變。
儘管身為Dcard CEO，多數時間不直接寫code，但因為背景與興趣，我一直緊貼最前沿的AI發展。
從寫出Dcard到今天超過1,300萬註冊會員，因為量級跟需求，我有機會把軟體開發的各個面向都走過一輪：前後端、Scaling、iOS／Android、Machine Learning、Data Infra。
也因此，當Agent真的開始「會做事」的那一刻，我比大多數人更快意識到：這不只是工具升級，而是工作模式即將大幅改變。
第一次被擊中：我不是在用工具，而是在跟它一起工作
最深刻的開頭，是從年初開始接觸到Claude Code。
隨著團隊規模跟codebase規模擴大，公司內部數百個repo、上億行程式碼，要了解每個服務具體的實作細節變得更加困難。
我永遠忘不了2025年2月底第一次用Claude Code的時刻。
那時候我想研究一個首頁推薦算法的架構。我不好意思第一時間去打擾工程夥伴，想著自己先用AI研究看看，多了解細節，好讓我能站在工程與產品的角度做更好的決策。
那時既有的codingtool體驗都不盡人意，很多時候我都是手動複製貼上到ChatGPT效果最好。於是我想著：先讓Claude Code試試看。
我原本以為又會是老樣子：我複製一段code、貼到聊天框、等它猜。
結果Claude Code直接開始「自己看repo」：自己讀檔、自己追套件相依性、自己補上下文，甚至還會反過來問我：
「你要確認的是架構取捨？」
「還是線上效能？」
主動意識到我漏掉的許多面向。那一刻我才意識到：我不是在用聊天機器人，我是在跟一個能在真實環境裡「行動」的助手一起工作。
不到幾分鐘，我想研究的問題就被它整理得清清楚楚：脈絡、取捨、風險、甚至還順便幫我排版成「可以拿去討論」的樣子。
那種震撼我記到今天。
這是一種我很想要的「刻意練習」時刻：像是有個專屬教練，先替你把脈、把資料翻完，再用你的情境手把手教你。差別在於：它不是只給你答案，而是把你帶進「做事的流程」裡。
而且那個流程，是專屬於你的——不是教科書的統一答案，而是屬於此時此刻、根據你卡住的點、綜合當前情境而生。
還記得那幾個晚上我幾乎沒什麼睡。我只要有問題就會去問Claude Code，瘋狂嘗試各種可能性。
那種感覺很明確：未來真的已經來了，只是還沒有均勻分布。
神奇感從哪裡來：從回答，走向做事
後來我才想清楚這種「神奇感」從哪來：
LLM正從「一次寫出答案」（one-shotanswer）走向「多次調用工具去完成任務」（toolcalling／agentic workflow）。
你只要講清楚意圖（intent），它就能一邊探索、一邊修正，把事情做完——這對不熟領域的人尤其關鍵。因為人最大的問題常常不是不會問，而是不知道自己還缺哪一塊資訊；當你只要表達意圖，剩下的探索交給工具鏈，效率會直接換一個級別。
為了跟朋友分享這個發現，我在2025年3月寫下《MCP是怎樣讓世界又更好一點點》。
先別談願景：把阻力拿掉才是真的開始
我那時遇到我們家工程師逢人就分享我最近的收獲，我也想聽聽大家怎麼用、卡在哪。
結果我發現多數工程師應用AI coding的比例不高，頂多用ChatGPT查查問題。追問下去，原因其實很務實：
一來是不確定公司的資安政策、二來是訂閱費就是門檻。
20美金的阻力，會讓很多人永遠不會開始；200美金的Max方案更不用說，絕大多數人根本不會考慮。
很快地，身為CEO，我做了兩個直接的決定：
- 訂定明確公司的AI使用資安政策，並公告出去，積極鼓勵大家使用
- Dcard全體工程師無上限補助使用Claude Code
為了塑造彼此分享的文化，我們持續分享實際案例，我也親自分享了第一場。慢慢地夥伴們彼此看到更多情境，應用比例也逐漸提高。
很多朋友聽到我這樣補助都會訝異我怎麼計算ROI。
但我自己因為親自體驗過很清楚：那數倍的生產力提升乘上人力成本，Token成本在組織尺度上根本不是問題。更重要的是：這不是成本，是下一代工作方式的「基本配備」。
如果你從未開始，你就不會發現。
Agent進組織，卡的不是模型，而是手腳與治理
接著我開始思考：如果這就是人類未來的工作方式，要怎樣把這樣的體驗複製到工程以外的團隊？
這不只是生產力，而是關乎每個人未來的職涯。
我很快發現，Agent要進組織，卡的從來不是模型能力，而是三件事：工具（Tools）、權限（Permissions）、平台（Platform）。
白話文而言：不是AI不夠聰明，是組織沒有給它「做事的手腳」，也沒有一套能放心放權的治理（governance）。
工具：先挑最痛的地方下手
最初我希望為公司內部許多系統撰寫工具讓AI可以調用。儘管開源的MCP很多，但真正能用、能穩定帶來效果的並不多。
我意識到必須要有針對性地，按照公司重要序來開發。
很快地我在公司內部調查一輪重要情境。我發現查數據、開數據埋點規格、實際執行這一整條價值鏈牽涉到很多角色：營運、PM、BI、Data Engineer、前後端工程師……原本流程相當繁雜。
於是我開始為公司的報表系統、數據系統、文件系統寫第一批工具擴充ClaudeCode。
很快地在我電腦裡運作良好。「啪」的一聲——那不是魔法，是流程被壓縮、跨角色對齊被折疊的聲音。原本需要好幾天、跨好幾個角色反覆對齊的數據追蹤規格文件，現在我只要講清楚需求，10分鐘就能產出一份可review的雛形：
事件命名、欄位定義、驗收方式、甚至連可能踩雷的邊界案例都先列出來。
權限：要能做事，也要能控風險
接著是權限。要完成上面體驗，涉及報表、數據、文件等系統權限，這些都不是ClaudeCode或MCP既有提供的能力。
於是我開始設計一套給內部夥伴用的MCP Gateway：夥伴只需要用公司內部的Google登入、連上內網，就能快速拿到公司內專屬的MCP，同時有安全的權限保護。
平台：把「會用的人」變成「每個人都能用」
但下一個問題更棘手：就算有工具與權限，要妥善調用Agent還需要安裝Claude Code或Claude Desktop。
每個人20分鐘的部署時間，乘上數百人的教育成本，是非常可觀的摩擦。導致前期我們投入相當多時間在一個一個溝通，推廣速度緩慢。
跟資安與IT夥伴討論一輪，我萌生了做一個全公司都能用的內部Agent平台的想法：Agent-v1。
很快地，我們用了不到兩週做出第一版，開始在內部使用。從原本20分鐘安裝，變成「一鍵登入」；所有夥伴都可以透過Agent-v1快速查找公司內的重要資訊。
到這裡，我第一次真正感覺到：事情開始不一樣了。
一個意外，打開了我對Agent的想像：Real Hard Problem
最初我對Agent的想像，主要在產品、數據、工程領域。
但2025年中，一個小意外擴大了我的視野。
那段時間剛好碰到部分會計夥伴產假、人員離職，每個月結帳跟財務作業壓力都增加不少。看著夥伴每到月初辛苦加班，我在想著是否能幫上忙。於是我花很多時間跟會計夥伴一起把財會的整體運作拆開來看。
我才意識到：會計很重要的是從最上游的規章與單據，一步步整理成不同的傳票、中繼表，再到下游的管報與財報。而這一切，涉及大量的Excel、Google Sheet、ERP、數據系統之間的交互查詢跟彙整。
這不是「AI幫你快一點」的問題，這是典型的企業內部Real Hard Problem。
於是我開始架構一整套Dcard Finance的AI Agent體系：把公司內部ERP系統設計成一組可調用的工具，讓原本偏靜態、需要大量人工操作的系統，轉變成一個可以「對話、查詢、推理」的智能系統。
其中的秘訣是：財務處理常常伴隨超大規模數據量，遠超LLM能容納的上下文窗口。但如果把問題轉成撰寫程式碼、編寫Excel／Sheet流程，就能大幅提高正確率跟執行效率，而且可重複驗證。
在Finance這條線，AI帶來的不只是「快一點」，而是「少痛很多」。
過去月結最折磨的，是資料散在Excel／Google Sheet／ERP／數據系統之間：每一次查核都像在手動拼拼圖，還很難保證不漏、不錯。
我們把這些動作變成可調用的工具，把問題轉成可驗證的查詢與表格流程——用code／spread sheet as executable spec。
結果是：會計夥伴結帳期的加班明顯下降，而且錯誤率更可控，財務團隊更快完成財報管報分析，而我也第一次可以用「問的」直接拿到關鍵財務數字。
意想不到的是，廣告團隊也可以透過系統，更即時掌握自己客戶的客戶歷史與財務進度狀況。這對開發與銷售都極其有幫助。
類似這樣攻克一個難題，就跨部門受益的場景屢屢發生。
AI導入：從一個人到一群人
這件事讓我意識到：全公司可能有更多高價值場景，已經能被AI很好地解決，只是我們還沒發現。
於是我開始在更大範圍推廣這套概念、在全公司講解AIAgent，並且積極鼓勵大家來許願——只要大家敢許願，公司就會安排資源去實現。
很快地，大家許願的場景超過我一個人能負荷的開發範疇。
為此我開始在內部找有意願一起投入的夥伴。隨著大家逐步加入，內部的AI服務團隊從最初我一個人開發、資安跟IT大力協助，到後來組建Core Product與FDE（Forward Deployed Engineer）團隊。
在Core Product，我們需要時時刻刻了解最新的Agent技術：Context Engineering、各類大小模型特性、最新協議……經常是有一個模型剛釋出，不到幾個小時內部平台就能用上；或是一項新協議、新技術，短短幾週內就出現在內部平台裡。
比如說10月16日Anthropic發佈的Skills相當重要，多數人會忽略甚至沒用過，但卻是Enterprise場景數一數二關鍵的能力。當週內部就有prototype可參考，11月就開始在Dcard大量測試與使用。（目前OpenAI Codex也剛宣布支援，預期其他大廠會陸續跟進。）
FDE：最稀缺的不是寫多快，而是往哪寫
而在這整體裡面，FDE的角色又更重要。
AI大幅加快開發速度，但前進方向永遠取決於對落地場景的理解。FDE就是那個把「一線場景」翻譯成「可落地系統」的人。
在Agent時代，FDE不是職稱，而是一種工作方法。
在Dcard，對一位FDE而言——那個最前線的人，常常就是身為CEO的我。
這對我來說是莫大的恩賜。因為AI讓開發速度大幅提升，最初多數時間我反而是在等待大家提需求。內部客戶的需求與回饋變成我每天進步的動力：我期待每個業務場景遇到什麼挑戰，我又可以怎樣用AI快速解決、幫助大家。
這過程中除了自己的進步、公司的效率提升，還有一件我很珍惜的事：我跟夥伴的距離變近了。
我越做越確定：在Agent時代，最稀缺的不是做事情的速度，而是知道該往哪個方向前進。
我甚至覺得，下一代最高效的職場人，很可能都會長得像某種FDE——不一定是工程師，但一定能把需求拆解，並重構成可執行流程的專家。
回頭看，2025只是剛剛開始
回頭看這一年，有太多年初無法意料到的事情。
我們盤點出數百個落地情境，直到12月仍持續上升的週活躍比率與對話數，Agent對夥伴生產力的提升顯著且在加速。
就我們可看見的未來，2025只是剛剛開始，2026會有更多事情發生。
下面是Dcard內部在2026正在打造的未來工作樣貌：
▶串聯公司的元數據層（Company-scale Meta Layer）
我們想把「公司怎麼運作」變成一張可以被查詢、被理解、被驗證的地圖。
具體來說，是把公司內的顯性結構（系統、資料表、文件、流程）與隱性知識（決策脈絡、慣例、角色分工）逐步抽象成一個可被理解與查詢的數位孿生（digital twin）。
這讓數據、知識與流程不再分散，而是形成一個「數據×知識一體化（data–knowledgeunification）」的基礎層，使Agent能真正理解公司是如何運作的，做到過去做不到、但同時可驗證、可追溯、可靠的事情。
▶多端超融合的工作介面（cross-surface work interface）
我們不再把工作綁定在單一工具或單一裝置上。
工作會自然地發生在Web、Desktop、Mobile、Browser、Terminal與各類Internal Platform之間，而Agent會成為橫跨這些介面的協作層。
它不是一個新的App，而是融入每一個工作現場，讓人與系統之間的工作流不中斷，不需要在不同工具與介面之間來回切換。
▶多模態輸入輸出，重構傳統Office流程（multimodal workflow）
我們正在重構的是「從想法到產出」的整段距離。
從文字、表格、圖表、簡報，到語音與視覺理解，工作成果不再需要人工反覆轉譯或重做格式。
NotebookLM直接產生簡報的能力只是其中一個縮影。Dcard內部在第一週就已實際落地這類流程，讓「數據整理」、「內容生成」到「決策表達」之間的距離大幅縮短。
▶Agent從「被動回應」走向「主動探索」（agentic discovery）
Agent不再只是等人下指令才開始工作。
它會更高比例地主動探索資料、發現異常與潛在洞察，並將結果整理成可行動的建議。
在組織層級上，Agent將逐漸成為一個「第二層感知系統（second-order sensing system）」，協助人類更早看見問題、也更早看見機會。
有人說LLM沒有什麼新鮮、或能力放緩。但很多進步只是我們感知能力有限。很多做事方式只是我們習以為常。
在LLM已經能通過多數人類考試的今天，你在Google Images打「shirts without stripes」還是會出現超過一半的橫條紋襯衫。這是模型成本帶來的場景限制。
隨著模型迭代與基礎建設（可能過度但必要）的投資，成本量級的變化會帶來更多我們沒想到的應用場景；人類也會隨著時間摸索出更多範式，帶來更多進步。
以上是我跟Dcard的2025。
這一年讓我慢慢體會到：Agent並不是一個單點技術，而是一種新的工作介面（work interface）。
它改變的，不只是效率，而是我們如何理解問題、如何協作、如何學習。
我越來越相信，未來真正重要的，不是誰最早用到最強的模型——而是誰願意花時間，把這些能力變成組織裡每一個人都能自然使用的日常。
我最佩服的，是Dcard夥伴們願意把新工具真的拿去做事、探索下一代的工作方式。
2025是一個開始。接下來的2026，我很期待這個世界會如何變化。
我相信，加速才剛開始。
本文授權轉載自林裕欽臉書
林裕欽
