熱血漢誌 - 技術新鮮人到技術經理人，必懂的事

這段時間比較多在深入了解 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

最近在看 Anthropic 剛推的 Claude Skills，官方文件把這東西定義成「AI 的職前訓練手冊」。 根據 Anthropic 官方定義與技術文件，所謂的「Claude Skill」（正式名稱通常稱為 Agent Skills ）是一個非常獨特且強大的功能模組。 關於 Claude Skills 的官方技術文件，看完後確實很有意思。 特別是它提到的核心概念： 「漸進式揭露 (Progressive Disclosure)」 。 簡單說，以前我們寫 Agent，是把所有規則一次塞給它；但 Claude Skills 是讓它像人類員工一樣，平常只知道自己「有這個技能」，等到真的要寫信、分析報表時，才去打開那個 SKILL.md 檔案讀 SOP。 這在邏輯上非常合理，把 Token 省下來，準度也提高。但當我試著把官方範例那個 professional-email-writer 真正放進商業流程跑過後，發現這中間有些「理論與實戰」的摩擦點 一、 Claude Skills 有什麼特別之處？ 與一般 LLM 的「Tool Use (Function Calling)」不同，Claude Skills 的設計核心在於 「漸進式揭露 (Progressive Disclosure)」 與 「情境注入」 。 漸進式揭露 (Progressive Disclosure) - 最核心的差異 一般做法： 通常我們會把所有規則寫在一個超長的 System Prompt 裡，這會佔用 token 且讓模型分心。 Claude Skills： 技能以資料夾形式存在。Claude 平時只知道「我有這個技能的名稱與簡介」 。只有當你要求它執行相關任務時，它才會「打開」這個資料夾，讀取裡面的 SKILL.md (詳細指令) 與相關檔案。這極大地節省了上下文空間，並提高了執行精準度。 檔案系統導向 (Filesystem-based) 一個 Skill 就是一個資料夾。裡面可以包含說明書 ( SKILL.md )、範本 ( templates/ )、甚至可執行的程式碼 ( scripts/ )。Claude 可以像人類員工一樣，去翻閱這個資料夾裡的參考資料或執行裡面的腳本。 模組化與可攜性 你可以把「撰寫 Code...