這段時間比較多在深入了解 AI 可能性，以及製造未來有什麼可能，透過 Cymkube 這樣個人化製造來進行不斷的實驗和創新，同時感謝各位朋友的支持，這邊簡單做個回饋。 相對的 B2B 創業，這段時間找了一下資料，有個影片很值得品味一下（最底下連結），對比了 Salesforce（快、標準化）與 Epic Systems（慢、封閉客製）兩條截然不同的路徑。 邏輯梳理得很漂亮，對照我自己這 15 年的 B 端經驗，卻逐漸釐出一個很有趣的心理矛盾。我發現自己雖然做了這麼久，其實我很擅長「服務」B 端客戶、很會解決眼前的問題（Bug），但對於「什麼是產品」這件事，什麼是自己的產品，其實還在重新打磨，持續省思，持續 Compile。 看著這兩種極端模式，我有幾個系統層級的觀察： 小生意靠技術與獨特性，大生意靠模式與架構。 工程師性格很容易沈迷於把技術磨到極致，但在商業擴張的 System Design 裡，有時候「模式」的相容性比單點技術更重要。 「服務思維」可能是做「產品」最大的技術債 Technical Debt。 當你太習慣滿足每一個客戶的客製需求（Service），就很難狠下心來定義標準（Product）。結果往往是，每解決一個客戶的問題，產品的邊界就模糊一次。 重點不是選哪條路，而是 User（創業者）本身的屬性。 硬要一個喜歡 Deep Dive、講究深度控制的人（像 Epic），去跑快速擴張的資本局（像 Salesforce），本身就是一種架構上的 Mismatch。 測試邊界在哪裡？ 這陣子為了重新理解「產品」，我試著把過去的經驗做 Refactor（重構）。目前比較強烈的體感是，與其盯著轉換率那些冰冷的數字，最終發現，一切回歸到最底層的協定 Protocol —— 人性。 最熟悉的例子，在課程、工具滿天飛的現在，客戶為什麼最終選擇跟你買？ 或許不是因為你的 Feature 比較多，而是因為「信任」。要先捨棄舊的慣性，才能看清楚這點。 這是我目前的體悟，不知道在 B 端打滾的朋友們，是怎麼定義你們的「產品」與「服務」界線？ Ref, https://www.youtube.com/watch?v=WOIpt9uNQ-I
Linus Torvalds 的這個 repo，真的有種「Debug 完成」的通透感. 連寫 Linux 作者，半年前打死不用的人，都承認自己用 Vibe-coding 來搞定不熟悉的 Python visualizer，甚至直說他是 "cut out the middle-man -- me"。我們過去總覺得資深工程師的價值在於「手刻的精準度」，但看到這段，邏輯雖然通，實際體感卻是一種巨大的典範轉移。 -- 這不只是省時間，更像是把原本卡在「實作細節」的摩擦力直接歸零。 -- 資深開發者的槓桿率 AI Coding 對新手的幫助是補齊能力，但對資深開發者來說，它是直接省略了 "Google -> Monkey-see-monkey-do" 的過程。你只要懂系統邏輯（Analog filters），剩下的語法轉換（Python），AI 處理的效率遠高於人類。 . 工具鏈的迭代速度已經超越教學 從 Claude Code、Gemini CLI 到最近的 MCP 整合，現在的瓶頸已經不是「怎麼寫 Prompt」，而是你有沒有足夠複雜的場景讓 Agent 去跑。如果還停留在研究「如何提問」，可能連車尾燈都看不到了。 溝通層級的位移 以前我們還在談 User to Agent，但這幾個月觀察下來，越來越多場景是 Agent to Agent 在協作。人類的角色，正在從「撰寫者」轉變為「驗收者」或如 同半年前所演講的部分，任何一位專業的角色 都會成為該領域的 System Architect 系統架構師 / 流程架構師。 這點在初期可能還覺得只是多了個助手，但隨著 Workflow（ AI 工作流程） 越來越完整，那個體感差異會是指數級的。如果不現在進場去習慣這個「被 AI 推著跑」的節奏，過幾個月要補的可能不是技術債，而是「認知債」。 或許我們該關注的，已經不是 AI 能不能寫出完美的 Code，而是我們準備好把多少核心工作流交接出去了？ 這波 Vibe-coding 的浪潮，各位實戰派的體感如何？ Ref: https://github.com/torvalds/AudioNoise