2025 年度回顧：慢下來，才能更快

Published:
  Lastmod: 2026-01-02
Year In Review
by Ernest Chiang

2025 Year In Review: Slow Down to Go Fast (圖說：刻意用銀杏相機 GR IV拍的東京銀杏。圖片來源：Ernest Chiang。)

「Sometimes you got to slow down to go fast.」

這句話在 2025 年不斷迴響在我的腦海中。當各行各業都在追逐 AI 帶來的效率提升、各行各業對未來以及人工智慧充滿焦慮，我的腦海中一直想著筆記本裡頭的這句話：「真正的進步，往往來自於刻意的停頓與深度的思考。」

有難度的不是停下來、不是慢下來，而是那個刻意。

刻意的練習，刻意的思考，刻意的連結，刻意的驗證。

✳️ tl;dr

  • 思路核心主軸從「動腦想程式、動手寫程式、動眼審程式」轉變為「建構讓 AI 自主迭代的知識與流程系統」。
  • 2025 Vibe Coding (Agentic Coding) 工具使用歷程：Cline/RooCode → Cursor → Claude Code → Claude Code + Kiro。
  • 核心領悟：Coding is Easy, Context is Hard。工程瓶頸解開後，產品思考、與人類溝通、上下文情境的瓶頸才正要開始 (人累…)。
  • 將知識管理品牌化為「土炮工作法 (Humbled Productivity)」，強調 People, Workflow, System 三支柱。
  • 健康與生活的平衡：二月開始的每週重訓習慣、手寫筆記、認知資訊物理框架 (CIP)、家庭、旅行、在地、美食、儀式感。
  • 2026 方向：以基礎設施，搭配 Agents 和 Skills 圍繞 Humbled Productivity 協助團隊與客戶往目標推進。

✳️ 前言：這一年重新學習寫程式

回顧 2025 年，我最大的改變不是「更會用 AI」，而是角色定位的轉變。

因緣際會（privilege ?!）三歲有機會摸到電腦而開始學 BASICA 程式設計的我，國小時期不是看大家都在看的漫畫、而是在看 MS-DOS 操作手冊的我，國中時期大家在準備考試、卻在翻譯 PHP3 教學文件的我，高中時期大家繼續在焦慮聯考、卻因翻譯電腦書籍而喜獲一本絕版 FreeBSD 黑皮書的我… 從最早期的軟體開發者、半導體製程整合工程師，到技術管理者，再到產品與技術整合，一路到創業者 —— 這條路走了幾十年。儘管還在路上（還在吧？！），但 2025 年是個轉折點：我不再只是「動手做」，而是除了動手之外連結深入思考「如何設計讓事情有更高機率被做好的系統於無形之中」，並且保持拉著客人（陪著客人）一起動手實作與落地實測。

這種轉變，某種程度上是被 AI 浪潮推著走的。當 AI (LLM) 能夠快速產生程式碼時，我發現自己的價值不能只是「想得快」「寫得快」「講得快」，而是「想得清楚」「寫得清楚」並且「講得清楚」。或者更精確地說：是能夠將模糊的需求，轉化成為 AI Agents 以及人類可以理解並執行的結構化規格與工作流程。

以協助客戶痛點為主軸，我運用 Working Backwards 方法開始建構一套營運框架：從客戶的問題出發，往回推導可能需要什麼樣的產品、什麼樣的流程、什麼樣的系統、如何讓利害關係人們之間對齊、如何簡化理解消化吸收的成本。這不是新概念，但在 AI 時代，這套思維變得更加重要 —— 因為 AI 可以加速「做」，但無法替我們決定「該做什麼」。

「Slow Down to Go Fast」這句話，大概是我 2025 年這一年的主旋律。

當大家都在追求更快、更多、更自動、更焦慮時，習慣於追求效率的我選擇刻意慢下來，刻意思考：我知道我和團隊可以處理、解決、搞定大部分的任務類型，但是，什麼才是真正重要的？哪些才是真正本質的？該怎麼選擇？哪些能夠持續累積價值？

答案逐漸清晰：

  • 刻意對問題的深度理解、
  • 刻意跨領域的連結、
  • 刻意將隱性知識系統化的能力。

（圖說：如果各位有興趣的話，那就跟著我穿上打工服一起來回顧 2025 年吧！）

1️⃣ 技術與產品的平衡：Vibe Coding (Agentic Coding)

1.1 2025 Q1：YC RFS 2024 的啟發 — 重新想像 ERP

去年，研究 Y Combinator 的 Requests for Startups 2024 的時候，其中一個方向特別吸引我們團隊的注意：NEW ENTERPRISE RESOURCE PLANNING (ERP) SOFTWARE。

YC 的 Dalton Caldwell 這樣描述：

「ERP 是企業的作業系統，但普遍昂貴、導入痛苦、使用者不喜歡，卻又絕對必要且關鍵。我們希望看到新創公司打造能讓企業喜愛的軟體——靈活、易用、被客戶喜愛。」

這段描述讓我想起過去十年在傳統產業看到的場景：複雜的 ERP 系統、難以整合的資料孤島、以及被流程綁架的員工。如果 AI 能夠重新定義軟體開發，那麼 ERP 這個「企業作業系統」是否也能被重新想像？這個題目我們在近三年的閒暇之餘與其中兩個客戶夥伴一起深入訪談、拆解組織工作流程、最後整合出整個組織跨部門能共用的基礎物件，最後仿照 Jeff Bezos 於 2002 年發布的一份內部備忘錄「Amazon API Mandate」，為客戶的所有團隊、（幾乎）所有工作流程都以 API 方式提供服務。目前已經逐步發展成為 Kyklosify Consulting 這家美國精品顧問公司的其中一個核心產品線「Kyklosify BusinessSuite」。

隨著 Q1 這個季度身邊朋友陸續轉介，至少五家電子廠和傳產公司詢問能否幫忙更新他們老舊的 ERP。帶著這個問題，儘管知道這類核心系統的轉換不能只依賴技術，但如果當年的技術瓶頸可以突破，那是不是可能會是一個我們擅長拆解深挖與整合導入的機會點？伴隨著此時眾人對 vibe coding/agentic coding 能有多少能耐的好奇心，我們開始與合作夥伴們一起進行田野調查與各種實驗。

（圖說：Q1 用紅通通且燙金的 Firefox 紅包來跟大家拜個年。）

1.2 2025 Q2：與合作夥伴拆解傳統 ERP 的田野調查

第二季，我們花了幾週的閒暇時間，深入拆解了一套傳統 ERP 系統 —— 包括它的資料庫結構、業務邏輯、例外處理、如何處理客製化。

這個過程讓我們團隊累積了大量使用 AI vibe coding 多種開發工具的經驗與痛點。我們各自分工，分頭把玩各種不同工具，當時我主要使用 Cline/RooCode with Amazon Bedrock 和 Cursor（前者感謝台灣 AWS 贊助研究用 credits、後者直接入金實作），嘗試讓 AI 幫助我們快速理解複雜的 legacy code 和 database schema。

坦白說，初期的體驗並不順利（別忘了此時約莫 2025 年初，Amazon Bedrock 剛可以使用 Sonnet 3.7 模型、Claude Code 剛發佈之際）。AI 常常會「迷路」 —— 給出看似合理但實際上偏離目標的建議（老實說，而且是過度多到太多的建議與意見）。或者在處理多維度任務時，深陷細節而忘了原始目標，越調整越糟的情況時常出現（非常需要修身養性，而且對罵不行）。

過程中還是有一些順利產出的亮點與成就感，例如不到幾週時間，就在交叉參照另一個 ERP 系統文件的情況下（是的，平常就要累積知識領域、知識庫，書到用時方恨少，文件也是），仿製出部分幾個核心模組的前端介面，讓客戶以及整個團隊為之興奮。

這些踩坑經驗，反而讓我跟團隊更清楚地理解：AI 工具的價值不在於「給答案」，而在於「加速探索」「加速試錯」「加速驗證」。關鍵是人類要能夠設定正確的邊界、提供足夠的上下文、並且知道什麼時候該停下來重新思考。（此時我們多年累積的各種文件與流程規範逐漸變成優勢，原本不一定有人類會閱讀，但現在可以交給 AI Agents 來閱讀。）

（圖說：Q2 收到來自法國由 Asendia 處理過的信件。Asendia 在歐洲的 hub（如法國巴黎）可以幫客戶印刷、分流、貼標籤、發貨，等於是郵件界的 AWS。）（身為鐵粉，連收到一封信都要找出跟 AWS 之間的關係，是要升級成鋁粉了嗎…）

1.3 2025 Q3/Q4：嵌入式系統與雲端開發的實戰成果

到了下半年，我們團隊開始將這套 AI 輔助開發的方法論，大量運用在嵌入式系統與雲端基礎設施的開發上。

成果頗為顯著：

  • 開發進度大幅提前
    • 原本預估需要數月的功能，在幾週內就完成了可運作的版本。
  • 同時推進多個產品
    • 因為單一功能的開發時間縮短，團隊有餘裕同時處理多條產品線。
  • 加快與客戶的迭代週期
    • 更快的 prototyping 意味著更快的回饋、更快的修正、更快的收斂。
    • 前提是客戶願意跟上且能夠跟上迭代週期，最常卡關的地方是給予回饋並在週期中進行決策。
    • 也因此我們多半選擇與組織單位中最高權限者作為客戶夥伴，例如董事會、CEO、事業群副總裁。

但這裡有一個重要的前提：這些成果的背後，是大量的「規格撰寫」工作。我們花在寫各種廣義 Spec 的時間，不比 coding 時間少。只是這些投入，換來了更高品質、更可預測、更易維護的產出。當年在 tsmc 製程整合工程部門、以及在 Bluetooth SIG Working Group 參與國際規格制定的經驗，大量派上用場。

（圖說：年底 Q4 難得的加班熬夜，還是早起前往台中第二市場探訪在地早餐，有了在地的美味大早餐，瞬間振奮了起來，哈哈）

1.4 Vibe Coding 工具演進與踩坑歷程

回顧 2025 年，我的 AI 開發工具使用經歷了明顯的演進：

  • Cline/RooCode → Cursor → Claude Code → Claude Code + Kiro
  • ChatGPT Pro
    • (USD 200/month; 印象很深刻 2025-02-03 OpenAI 在東京發佈 Deep Research，我就從 Plus 升級到 Pro。後來 Claude Code 太香，降回 ChatGPT Plus 挪去 Claude Max 跑 Claude Code。)
  • Claude Max
    • (USD 100/month; 心頭好，很推薦！)
  • Gemini Pro, NotebookLM
    • (USD 16.8/month; Google Workspace Standard 內含)
  • Amazon Bedrock, Google AI Studio
    • (for infra projects)
  • LM Studio
  • Apple Intelligence

每一次轉換，都不是那麼的直接切換，比較像是邊實驗邊驗證的漸進式過渡。

初期使用 Cline 和 RooCode 時，我還停留在「把 AI 當作聰明的 autocomplete」「prompt 要怎麼寫才能有較好的產出」的思維。丟一段 prompt，看它能產生什麼。這種方式在小任務上很有效，但在複雜專案中很快就會碰壁。

轉到 Cursor 後，我開始理解「上下文 (context)」的重要性。Cursor 能夠索引整個專案，讓 AI 更理解程式碼之間的關係。但即便如此，在處理跨模組、跨系統的任務時，AI 還是容易失焦。（一方面也是當時的我自己太容易跳入雕琢細節，AI 就被我帶走了…）

真正的轉折點是 Claude Code 的出現。它不再只是一個 IDE 插件，而是一個能夠「自己看 repo、自己讀檔、自己追相依性」的 agent。第一次使用時，我原本以為又會是老樣子——手動複製貼上程式碼，等它猜，結果 Claude Code 直接開始自主探索。

那一刻我意識到：我不是在用工具，我是在跟一個能一起動腦討論的 agent 一起工作。（所以馬上開始轉換心態，跟團隊成員一起共事的框架，也要拿來讓 AI agent 一起理解、甚至迭代。）

到了下半年，當 Kiro 推出後，我們看到了更完整的願景。Kiro 不只是一個 coding 工具，而是嘗試建構一套「意圖導向程式開發 (Intent-Driven Development)」的框架。它有 Specs（結構化規格）、Steering（專案指導原則）、Hooks（事件觸發）——這些元件組合起來，形成了一個完整的人機協作開發環境。

（推薦大家可以參考 Pahud 於 2025-08-13 的這個影片「Multi-Role Development using Kiro」。此時距離我前往西雅圖參與 AWS Heroes Summit 2025 與 AWS CDK Team 以及其他 service teams 深入討論約莫只有幾週時間，而且在八月底九月初拜訪矽谷南灣、北加州台灣工商會、和西雅圖之後，看到美國各種領域各種企業已經在嘗試落地運用各種 AI Agents 而更加確定未來方向。）

更多關於這些 AI 開發工具的深度分析，可以參考我的筆記：Kiro AI: 代理式整合開發環境 與 Claude Code 學習筆記。不需要是工程師，大家都能使用這些工具。歡迎鼓勵各種想像力。

（圖說：探訪 Kiro 鬼屋！The house of Kiro！）

1.5 從「Vibe Coding」到「Spec-Driven Development」

這一年最重要的觀念轉變，是從「Vibe Coding」走向「Spec-Driven Development」。（我是覺得叫什麼名稱都無所謂，別太糾結，反正永遠都會遇到「你的 A 不是他的 A」。本質來看，該發生的事情還是得要發生，該做的事情還是不要省略，但有個大致一致的名詞，也許比較容易收攏相關經驗的分享或搜尋這樣。）

有人說所謂 Vibe Coding，就是丟一個模糊的 prompt 給 AI，看運氣能產生什麼。這種方式在小範圍小規模的快速原型階段很有用 (prototying)，就算提供很具體的 prompt 或相關文件給 AI，都可能因為所選用的模型、context size limit、rate limit、以及摸不到的 system prompts 而無法預測產出的品質，很難融入正式產品。（在這個階段我們的控制方法主要是切分夠小的任務範圍，並且搭配 multi-shot。）

Spec-Driven Development 則是另一種思維角度：先用人類的語言，盡可能的清晰地定義「要做什麼」和「為什麼要做」，然後讓 AI 負責「怎麼做」的執行細節。（很適合文件相對完整的產品團隊，但專業服務公司可能就很需要倚重甲方客戶窗口的溝通與表達能力。）

這讓我想起了十多年前在 Bluetooth SIG Working Group 參與制定國際標準的經驗。當時我們花大量時間撰寫規格文件 (FRD, specification)，定義每一個協定的使用情境、行為、邊界條件、錯誤處理。這些文件看似枯燥，但正是因為有了清晰的規格與測試計劃，全球不同廠商才能開發出彼此相容的藍牙產品。

這些文件看似枯燥，但正是因為有了清晰的規格與測試計劃，全球不同廠商才能開發出彼此相容的藍牙產品。

Spec 其實就是產品開發中的 PRD (Product Requirements Document) 和 FRD (Functional Requirements Document)。只是在 AI 時代，這些規格文件有了新的意義：它們不只是給人類讀的，更是給 AI 執行的指令與上下文情境。（這個在 Transformer 架構的 LLM AI 時代應該會持續好一陣子，且應該會隨著時間點更換名詞 (e.g. Context, MCP, Skills, etc) 直待下一代架構或浪潮來襲，然後會再次重演（習慣就好，無需焦慮，名詞錯開都是為了 namespace））。

這種思維轉變，與深度學習先驅 Yann LeCun 的觀點不謀而合。他強調從「指令式程式開發 (Imperative Development)」走向「意圖導向 (Intent-Driven)」的典範轉移。開發者專注於清晰地表達「為什麼而做」和「做到什麼」，而將「如何做」的繁瑣交給更智慧的系統。

延伸閱讀：關於意圖對齊的框架之一（還沒起個名字，但比較常拿出來用的圖是這張），放在 2025 年 6 月的 台灣產品年會 「互通、整合、迭代：傳統產業 產品與技術整合 之 十年生存指南」 演講投影片中。

1.6 核心領悟：工程瓶頸解開後，產品思考的瓶頸才剛開始

這一年關於 vibe coding 或 agentic coding 比較深刻的領悟，大概會是這句話：

Coding is Easy, Context is Hard.

抽象化來看，跟還沒有 AI 的當年大家會說技術不是最重要的，屬於同一個脈絡。

當 AI 能夠快速產出程式碼時，瓶頸不再是「寫不出來」，而是「想不清楚」「連不到位」。這與 Amazon CTO Werner Vogels 在他最新一次（也是最後一次，哭哭） re:Invent 2025 Keynote with Dr. Werner Vogels 上的核心呼籲不謀而合。他提出了一個關鍵概念：「驗證債」(Verification Debt)。

Werner 指出：「AI 產生程式碼的速度比你理解它的速度還快。程式碼瞬間就來了，但『理解』卻無法跟上。」這與 Anthropic CPO Mike Krieger 的觀察一致：Anthropic 內部超過 70% 的 Pull Request 都是 AI 產生的，甚至他們的 Claude Code 工具本身，大約有 95% 也是由 AI 自己寫出來的。

但弔詭的是，當程式碼產出速度暴增時，團隊的 Merge Queue 直接爆掉了。這像極了經典管理學著作《目標》(The Goal) 提到的「瓶頸理論」：你解決了一個瓶頸，其他瓶頸就會浮現。Werner 引用生態學家 Donella Meadows 的系統思考 (Systems Thinking) 來解釋這種現象——就像黃石公園引入狼群會改變河流流向一樣，大量引入 AI 程式碼，會徹底改變軟體交付系統的平衡。

現在的瓶頸變成了：

  • 上游（決策與對齊）：
    • 如何減少自然語言的歧義？
    • Werner 提到了 “Vibe Coding”（憑感覺寫扣） 的風險，並強調我們需要轉向 「規格驅動開發」(Spec-driven Development)。
    • 與其讓 AI 猜測你的意圖（或是抱怨 AI 都不懂你），不如先投資時間撰寫清晰的規格與需求。
  • 下游（協調與交付）：
    • 怎麼確保系統的韌性？
    • Werner 強調 “The work is yours, not the tools."（工作是你的，不是工具的）。
    • 當 AI 寫得越多，人類的角色就必須從「寫作者」轉變為「擁有者 (Owner)」與「審查者」。

我們面臨的風險是：如果人類不再逐行理解程式碼，那 Codebase 會不會變成只有 AI 能懂？

這確實是巨大的挑戰。但正如 re:Invent Keynote 所提倡的 「文藝復興開發者」(The Renaissance Developer) 精神，解法不是退回「人工手寫」的時代，而是建立更強的 「機制」(Mechanisms) —— 例如更嚴謹的規格文檔、更自動化的測試、以及將人類智慧集中在 AI （暫時？）無法取代的跨領域系統設計上。

真正的競爭力，在於「領域洞察 (Domain Insight) × 系統思考 (Systems Thinking) × 驗證能力 (Verification)」的交集處。未來的產品經理與架構師，戰場不只是功能規劃，而是要像 Werner 所說的，學習如何用精準的規格與 AI 溝通，並對最終的系統行為負起完全的責任。

（圖說：Amazon CTO Werner Vogels 說這是他最後一場 AWS re:Invent Keynote，我人就在台下，強烈感受到他的不捨與期許。有影片大家可以開聲音感受一下。）

1.7 分享與交流

這一年我有幾次公開分享與私下分享的機會，讓我能夠將這些實踐經驗與更多朋友交流，非常很感謝邀請我前往分享的單位與企業，讓我有機會將這些第一手資訊分享並獲得跨領域的回饋，這使得我們團隊得以驗證想法、加速迭代，期待下次的見面。

以下是幾場規模較大的公開場次：

2️⃣ 知識與營運的平衡：土炮工作法 (Humbled Productivity)

2.1 從資訊累積到系統化輸出

2025 年另一個重要的嘗試，是嘗試（且緩慢地）將我的知識管理方法論打包為「土炮工作法 (Humbled Productivity)」，大家別著急，目前先只有小部分的實驗性釋出，希望 2026 年能有逐步擴大的範圍釋出。（但歡迎來約當白老鼠，專注本質分析，不會散播焦慮。（希望啦））

  • 「土炮」這個詞，來自於我們團隊對「接地氣」的堅持（算是種文化？！）。不追求最炫的工具、最新的框架，而是尋覓與驗證最適合客戶以及團隊的解決方案。
  • 「Humbled」則強調謙遜的態度 —— 面對新技術時，承認自己的不足（各種不足、各種冒牌者症候群、哎），願意歸零從基礎重新學習。
  • 在 AI 時代，一個很容易掉入的陷阱是：遇到問題就直接問 AI。但這種習慣會慢慢侵蝕我們的思考能力。
  • Anthropic CPO Mike Krieger 在談到教育孩子時，提到一個我很認同的觀點：

「在問 AI 之前，先問『我們怎麼自己找出答案？』

可以做什麼實驗？可以觀察什麼？」

這與我一直在想可以如何「優先於 AI 思考」是類似的概念。AI 可以是強大的工具，但如果我們把所有思考都外包給它，我們會漸漸失去獨立解決問題的能力。AI 也可以是強大的夥伴，但也可以藉由與 AI 來回的討論、鍛鍊我們的思考、強化解決問題的思路。沒有優劣，端看取捨與目的。

大家可能會有興趣抽離掉 AI 之後如何鍛鍊思考的延伸閱讀：

2.2 手寫筆記與 Context Engineering 的連結

今年我讀到一篇關於手寫筆記的研究，研究顯示，手寫比打字更能促進大腦連結性。手寫時的 theta/alpha 頻率連接性模式，對記憶形成至關重要。

  • 這解釋了為什麼我在遇到複雜問題時，總是會拿起 reMarkable Paper Pro 或 Field Notes 手寫思考 —— 這不是「復古」，而是認知科學的最佳實踐。
  • 我另外覺得有趣的是，某種程度這與 AI 時代的「Context Engineering」形成了呼應。Context Engineering 強調如何有效管理 AI 的上下文 —— 什麼資訊該餵給 AI、什麼該省略、如何組織才能讓 AI 更好地理解我們的意圖。
  • 手寫筆記的過程，其實就是在做「人腦的 Context Engineering」：篩選、整理、建立連結、強化記憶。這些經過人腦處理過的知識，再輸入給 AI，品質會比直接丟一堆原始資料好得多。
  • 手寫也是今年我讓自己慢下來的方式之一。（另一個方式是跟家人朋友好好吃飯、專心吃飯。只拿相機、不滑手機。）

（圖說：在 AWS re:Invent 2025 CEO Keynote 現場只帶 reMarkable Paper Pro 手寫筆記。）

（圖說：手寫筆記有助於聽完主題演講之後只隔一個半小時，就跟 Jayson 和 Terry 一起上場 podcast。）

2.3 Knowledge Base 與 Workflow Orchestration 的整合思路

在實際工作中，我持續將知識管理與工作流程整合在一起。

  • 以 Kiro 的 Steering 功能為例。它允許開發團隊將專案的架構規範、設計模式、首選函式庫、命名慣例等「團隊知識」寫入 .kiro/steering/ 目錄下的檔案中。AI 在執行任何任務前，都會優先參考這些「指導原則」。
    • 這可以被視為一種「可執行的架構文件 (Executable Architecture Documentation)」。過去的架構文件常常與實際程式碼脫節——文件寫了一套，實作是另一套。但當這些文件直接影響 AI 的行為時，它們就有了實際的約束力。
  • 我會將各種原則堆積到這類指導檔案中：
    • 「中文字元和英文字元之間，請加上一個半形空白字元」
    • 「有疑慮就問我問題，以釐清我沒有說明清楚的地方」
    • 「請完整處理每一個細節，不要跳過、不要省略」
    • Amazon Working Backwards 的思維框架
    • Domain-Driven Design (DDD) 的設計原則
  • 這些看似瑣碎的指引，累積起來形成了一套「團隊的 DNA」。新人加入時（或新的 AI Agent 加入時），不需要靠口耳相傳，直接讀這些檔案就能理解團隊的工作方式。
  • 接下來應該會陸續整理成 Skills。

（圖說：聆聽 AWS re:Invent 2025 CEO Keynote 時，投影牆角落出現躲貓貓的 Kiro！）

2.4 People, Workflow, System 三支柱

我把這個框架分享給客戶時，總是強調：這只是一個範例模板，你可以依照你的場景、你的經驗，修改成你覺得舒服的模樣。重點不是照抄框架，而是透過框架來引導思考。

  • 土炮工作法導入時，會使用 Humbled Transformation Framework，整個框架設計的核心，是三個相互關聯的支柱：
    • People（人）：以人為本、解決問題、發展策略、當責團隊
    • Workflow（工作流程）：工作日常、探究細節、拆解步驟、基於事實
    • System（系統）：退後一步、綜觀全局、整合流程、創造價值
  • 這三者缺一不可。
    • 只有 People 沒有 Workflow，會變成「光說不練，執行不足」。
    • 只有 Workflow 沒有 System，會變成「見樹不見林」，缺乏回饋平衡機制。
    • 只有 System 沒有 People，會變成「紙上談兵，脫離現實」。

（圖說：今年五月在香港分享 Humbled Transformation Framework 與現場的開發者與管理者交流。）

2.5 Kyklosify 的服務思考

這些年度累積的實踐，逐漸收斂成 Kyklosify 的服務框架，暫時以 side project 形勢逐步釋出與客戶一起探索永續及解決問題。

  • Kyklosify 這個名字來自希臘文「Kyklos」（循環），代表拆解、理解、整合、湧現的持續循環。這不是一次性的轉型專案，而是持續迭代、持續學習的過程。
  • 核心思維是「探索本質工作流程」，而非只是「導入工具」。
  • 根據 McKinsey 和 Accenture 在 2025 年初發布的報告，90% 的大型組織計劃增加 AI 投資，80% 已在至少一個功能領域使用 AI。但只有約 20% 的組織實際重新設計了工作流程來實施生成式 AI。
    • 這意味著大多數組織只是把 AI 當作「更快的工具」，而沒有思考如何改變工作的方式。這就像買了跑步機卻只用來晾衣服——工具再好，如果使用方式不對，效益就會大打折扣。
    • 而我們團隊所認為的「對」，往往是在層層深挖之後，回歸企業原創使命，結合當前市場參數，微調組織和工作流程，確認解決真實痛點。過程中確保大部分工作任務都可以經由 API 呼叫、確保留下歷史資訊，為接下來的 Agent 和 Digital Twins 預先鋪路。
  • 值得延伸閱讀的有：
    • Dcard CEO Kytu 在他的年度回顧中提到，Agent 進組織卡的三個障礙：
      • 工具 (Tools)：不是 AI 不夠聰明，是組織沒有給它「做事的手腳」。工具除了能打通 API、metadata、MCP、Skill 之外，大家最常忽略也是台灣企業多半缺乏關於治理 (governance) 的定義與落實。
      • 權限 (Permissions)：需要一套能放心放權的治理機制，這也是我們溝通過程中相對有挑戰性的地方，也因此我們暫時只能選擇有權限調整權限的客戶。
      • 平台 (Platform)：降低使用門檻，讓每個團隊成員（人類）都能使用、都能參與，將工作流程與組織知識融合到日常工作之中。
    • Karpathy 的年度回顧 = 2025 LLM Year in Review

Kytu 這三點與我們在自家現場以及客戶現場所遇到的挑戰幾乎契合。技術問題往往是最容易解決的；真正困難的是組織變革、權限設計、以及使用習慣的養成（或調整）。

另一個我很認同的觀點是 FDE (Forward Deployed Engineer) 的角色定位，以及在 Agent 時代：

「最稀缺的不是做事情的速度，而是知道該往哪個方向前進。」 – Kytu, Dcard CEO

在 Agent 時代，最有價值的人才，可能不是寫程式最快的，而是最能夠「把需求拆解、重構成可執行流程」的人。這種能力，不限於工程師，產品經理、業務夥伴、財務夥伴、行政夥伴都可以培養。

（圖說：關於 digital twins 我還在想像著，今年釋出的照片最接近 digital twins 的一張如下。猜猜，哪一面才是 reality？誰是誰的 reality？還是這一切都只是 symbols for conscious entities’ communication？）

3️⃣ 健康與生活的平衡：慢下來的儀式感

3.1 身體健康：每週健身養成習慣

談了這麼多技術與工作，其實 2025 年對我影響最深的改變之一，是從二月開始養成的每週重訓習慣。

  • 每週至少一次、雷打不動的重訓時間，成為了我的「強制重開機」機制。不管前一天加班多晚、專案壓力多大，到了重訓時間就是放下一切，專注在身體的感受上。這種「刻意的斷線」，反而讓我在其他時間更有效率。身體疲累時，硬撐著工作只會產出低品質的成果。不如休息好、運動好，用更飽滿的狀態面對挑戰。
  • 運動後補充一盆沙拉，帶著 Paper Pro 或 iPad 手寫手繪一些想法，或與 AI Founders Meetups 朋友交換意見。雖然滿多回饋資訊都是以我這個年紀一週只動一次太少了，但我今年的小目標是養成運動的習慣，連出差時都有記得去飯店健身房（我絕對不會說我只去裝水 XDD），建立運動習慣的低標有達到了很開心這樣。
  • 雖然有教練看著調整與確認運動姿勢，但畢竟是久坐型的職業副作用，Q2 出差時搭了來回各四個小時的火車 + 背包包一直走路，回來之後居然在彎腰提背包時，「喀」的一聲，經歷了人生難得可以體驗一下的「閃到腰」… 細節就不提了，總之感謝 W 的細心照顧、以及大家推薦的各種復健，接下來就比較認真提醒自己調整桌椅的高度與坐下的姿勢與時間長度。
  • 閃開閃到腰之後，Q4 又因為同時單肩背負 Macbook Pro + Paper Pro 而造成某一邊肩膀的某個肌肉差點爆掉，好險在發炎階段就提問而被發現，提早照護。差點不能出差跑行程，真是感謝。

（圖說：運動後的咖啡儀式感，嗯，這張沒拍到咖啡，但總之，你懂 XDD）

3.2 心理健康：閱讀與意識探索

今年閱讀的書裡頭，對我影響最深也最喜歡的一本書是 Federico Faggin 的《Irreducible: Consciousness, Life, Computers, and Human Nature》。

  • Faggin 是發明微處理器的傳奇人物，但這本書談的不是技術，而是意識 (consciousness) 的本質。他從物理學、資訊理論、量子力學 (CIP) 的角度，探討意識為何是「不可化約的 (Irreducible)」 —— 也就是無法被簡化為純粹的計算或物理過程。
  • 在 AI 快速發展的今天，這本書給了我很多反思。我們很容易把 AI 的能力與「智慧」甚至「意識」劃上等號，但 Faggin 的論述提醒我：人類意識的獨特性，可能遠超我們目前的理解（我是覺得一直沒有理解，所以其實應該不是遠超，而是除以零的概念吧）。
  • 這不是要否定 AI 的價值，而是要對「人」的價值有更深的認識。AI 可以處理資訊、產生內容、甚至模擬對話，但「體驗」、「感受」、「意義」——這些可能是 AI 永遠無法真正擁有的。
  • 推薦給也被資訊轟炸、社會壓力轟炸、焦慮或是疲憊但願意踏出一小步探索的你、妳。
  • （我有製作英文繁中翻譯本自用，如果你有需要、且已經有在 Amazon 購買這本書、且有 Kindle device or app、且物裡上我們見過面，我們可以討論討論怎麼製作。）
  • 喔對 btw 我趁黑五期間入手了一台 Amazon Kindle Colorsoft，原本不期不待，但拿到手之後搭配閱讀彩色雜誌、以及有顏色的劃線筆記，還是滿有感覺的，翻頁速度也很可以接受，成了接下來的隨身閱讀機。

另外關於聲音、頻率、高敏症狀，原本使用降噪耳機來緩解，但有時候還是會想聽到小孩在做什麼的聲音（另外就是較大較重，除了上飛機不然不一定會帶出門）。

  • 感謝在西雅圖過感恩節時跟朋友聊到這個困擾，好友推薦了 loop earplugs，有不同系列對應不同的降噪程度。
  • 剛好在黑五期間，馬上 Amazon 下訂 Loop Engage 2 Ear Plugs，然後在 AWS re:Invent 收貨立刻愛上。
  • loop earplugs 上頭有個小孔是可以聽到外界聲音的。我就這樣帶著聽課和逛小巨蛋規模的攤位，非常有效，不用一直跑 reflection room 了 :)

（圖說：想說放一張應該會讓大家心情愉悅的照片。）

3.3 家人與朋友

回頭看，這些時光是一年中最珍貴的回憶。工作上的瑣碎會被遺忘，但與家人好友們共度的時光會一直留在心裡。

  • 喜歡帶著家人到各種巷弄裡頭探險、或是隨機挑選一個捷運站出站走走。
  • 超愛每次外出都被家人好友們帶著走當地在地行程，非常感謝，每次相聚總是珍惜。
  • 其實大家不論是移動或是落地深耕，多少會遭遇不同的挑戰和心情起伏，很佩服在各地耕耘的大家，祝福大家都要一起平安健康。

（圖說：計劃趕不上變化而被隅田川河畔公園給吸引走的石頭兄妹）（原本石頭爸想帶全家去隅田川另一頭某個公園拍溜滑梯配晴空塔，但其實盪鞦韆配晴空塔也很不錯，重點是跟誰一起，而不用執著於在哪裡，對吧？）

3.4 美食與廚房

喜歡玩弄食物（帶著尊敬的心）這個習慣大概從我媽教我煮了第一個荷包蛋之後就開始啟蒙，先是歷經大學時期玩咖啡、畢業後跟著前輩們走訪法國波爾多品嚐葡萄、自助與出差時探訪歐陸料理與在地小吃、一直到近年比較常造訪美國與日本，有在地家人朋友帶著探訪當地美食，逐步建構美國西岸墨西哥菜系、以及位於日本的義法料理。將這些味蕾與口感帶回家嘗試烹飪給家人享用，所以有時會在我的照片中看到 #kitchenlab 或 #軟軟配脆脆就會好吃 之類的 hashtags。

（圖說：有點傷心的是這個從疫情期間陪著 WE+we 一起吃飯照相玩食物的 life goes on 磁盤今年不小心打破了…）

3.5 深度聚會

今年延續去年的調整，80% 時間分配給能深度交流的聚會場合或一對一深聊，20% 的時間參與觀察新領域資訊的聚會場合。

每個月固定參加的聚會涵蓋自己以及工作上最需要的領域：Product, Technology, Knowledge, Infrastructure, AI。

  • Proudct People monthly meetup
    • 七人小隊，這一群最嚴格哈哈，大家彼此規定不能缺席、以及幾乎不能新增成員，連續已經紀行超過 25 次聚會。
    • 因為大家某些屬性很契合、超自律，加上時間相對最長（我們只約了開始時間，沒有預設結束時間），是目前所有聚會裡頭討論深度最深的。
    • 形式跟好幾年之前參加 FounderSqaud 某部分很像，每個人每個月帶一個問題來參加，然後大家展開討論。
    • 很推薦大家可以自組這樣的小型互助討論小隊。
  • TGONetworks monthly dinner
    • 雖然有時戲稱為 CTO 取暖會，但來自各種產業以及之前設下的進入門檻 (e.g. 旗下部門超過 15 人)，使得整體討論深度與經驗值相仿，省下許多溝通等待時間，能夠直打問題。
  • AI Founders Meetups
    • 一開始是開源社群幾位老朋友大家互約（互相提醒）每週運動，有運動後就在群組打個卡，相互激勵。
    • 漸漸也有實體聚會，聚會有時候約在健身房，運動後聊聊最近的進度。有時候約在咖啡店，一言不合就開電腦，誒不是，是打開電腦直接 live demo。
    • 例如表演在文件齊備的狀況下 60 分鐘，從無到有，vibe coding 一個研究機構的靜態網站，然後接通 Cloudflare DNS 部署到 GitHub Pages。（就先不談那 60 分鐘以外多年的血與淚了…
    • 這群 founders 移動的地理範圍很廣闊，有一次也約了在東京碰頭、有人跑去歐洲設立公司、有人有營運多個地區工程部門辦公室的經驗、我則大略分享設立與營運美國公司的經驗。

（圖說：從 2013 年在 BELP 碰頭暢聊、相見恨晚之後，十幾年沒好好坐下來一起吃飯聊聊的Richard 強哥，剛剛加入美國 Datastrato 擔任生態副總裁，負責全球開源生態業務，正巧都參加了位於拉斯維加斯的 AWS 年度開發者大會 re:Invent 2025，於 MongoDB Private Lounge 相聚暢聊）（能與強哥暢聊也是種 privilege 吧 XDD）

✳️ 結語：持續循環的下一圈

回顧 2025 年，如果要用一個詞來總結，那就是刻意「循環 (Kyklos)」。

拆解、理解、整合、驗證 —— 然後再次循環。

從技術工具的演進，到知識管理的系統化，到生活習慣的建立，每一個領域都在經歷這樣的循環。沒有一勞永逸的解答，只有持續迭代的過程。

2025 年讓我察覺與複習了：

  • 工具會變，但底層能力不會過時。
    • Spec 撰寫、系統思維、跨領域連結 —— 這些能力在任何時代都有價值。
    • 但時間有限，所以要做出選擇，在有限的時間獲得這些能力，並累積經驗獲得維度與參數。
  • 效率很重要，但方向與決策也很重要。
    • 當代 AI (LLM) 可以讓我們做得更快，但也會增加檢視與驗證的時間。
    • 效率能否提升，其實取決於呼叫 AI 之前的架構、規劃、方向的決策。
  • 慢下來不是浪費時間。
    • 財務有 TCO (Total Cost of Ownership) 和 ROI (Return on Investment) 指標，時間也是。
    • 深度的思考、刻意的休息、有品質的陪伴 —— 這些「慢」的投入，會換來更持久的「信任與連結」。

2025 年我們看到的，可能只是 AI 時代的序幕。接下來幾年，變化的速度只會更快、影響的範圍只會更廣。

除了逃避以及各種躺平之外，也許現階段的我，還是會選擇繼續嘗試以「Slow Down to Go Fast」的方式來面對當前世界的流動。在加速的洪流中，保持清醒的思考、明確的方向、穩定的節奏 —— 也許是某種程度的競爭力吧？！ 至少過程中有著家人朋友與神隊友們的陪伴，會在力量中生出力量吧 :)

就這樣了，定稿，送出。別再糾結了，回顧 2025 是為了踏實地邁出步伐，踐踏 2026，喔不，我是說，邁進 2026！

  • 2026, I’m not chasing – I’m choosing.
  • Sometimes you’ve got to slow down to go fast, and let the cloud fireworks remind you, magic is already there.
  • Less noise. More signal. Same curiosity.
Cloud Fireworks, Magic, at Disney