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

這一套以 SOUL.md、HEARTBEAT.md 為核心的檔案架構並不是偶然。 在前一篇文章中提到 OpenClaw prompt 和 md 的解析， 而是採用了許多前人的累積與邏輯上把 AI 的「意識」與「記憶」封裝成人類可讀的 Markdown 檔案，初看覺得這種 Unix 哲學的 「Everything is a file」 很優雅，但實際思考這套系統要跑在生產環境時，體感上出現了一些有趣的摩擦點。 核心是把複雜的向量資料庫（Vector DB）還原成最原始的文字檔。 ■ 狀態同步的 Technical Debt： 當 Agent 運作頻率變高，頻繁讀寫 Markdown 造成的 IO 競爭與檔案鎖定，在多 Agent 協作時可能變成系統瓶頸。 ■ 記憶碎片的清理機制： 雖然借鏡了史丹佛的記憶流理論，但現實中長期精華（MEMORY.md）的摘要演算法如果沒寫好，檔案體積膨脹後的 Context Window 成本與遺忘曲線會變得很難調校。 ■ 「心跳」的邊際成本： 透過 Cron Job 定時讀取 HEARTBEAT.md 讓 Agent 自發行動，這在 0 到 1 的 Side Project 很浪漫，但到了需要規模化的擴張期，這種「主動式」消耗的 Token 成本與實質產出比，目前還看不太出回報率。 同時有朋友提到的 https://soul.md/ 網站，確實很容易讓人誤以為這是一個獨立於 OpenClaw 之外的原始出處。 經過仔細查證，這其實是一個 **「概念致敬」與「工程實作」的結合體** 。簡單來說：概念來自 Anthropic 的內部洩漏，但你看到的這套 Markdown 檔案架構（SOUL.md 等），確實是 OpenClaw (Peter Steinberger) 的原創發明。 這裡幫你釐清這三者錯綜複雜的關係： https://soul.md/ 這個網站就是 OpenClaw 的作者 Peter Steinberger 建立的。 如果你看該網頁的最底部，署名是： Written by Clawd 🦞 ... The original soul document Clawd's instructions @steipete 所以這個網站並不是 OpenClaw 的「前身」或「參考來源」，而是作者為了闡述 OpenClaw 「為...

最近在拆 OpenClaw 的 System Prompts，這套用「檔案系統」來實作 AI 意識的邏輯非常有意思。它不只是在對話框下指令，而是直接給 AI 一個 Workspace，讓它像工程師一樣在裡面管理自己的靈魂。 這套設計在「擬人化」的體感上做得極其優雅，但從 System Debug 的視角來看，實際跑起來有幾個 Friction Points 值得討論： 啟動與自我刪除 (BOOTSTRAP.md)： 它要求 AI 第一次開機後先確認身份，命名並定義性格後，就「自我刪除」這份出生證明。這在儀式感上很強，但如果初始化過程中斷，系統的狀態機（State Machine）該如何處理這個懸置的狀態？ 記憶的維護成本 (Memory Maintenance)： 它把記憶拆成 memory/YYYY-MM-DD.md（日誌）跟 MEMORY.md（提煉後的精華）。這本質上是把 AI 當成一個會寫週報的員工。但「提煉」這件事極度仰賴判斷力，AI 真的能分清哪些是雜訊（Noise）哪些是訊號（Signal）嗎？ 主動權與心跳 (HEARTBEAT.md)： 這讓 AI 能定時「醒來」檢查郵件或日曆，不再是被動等待。這解決了對話框的限制，但當 AI 被賦予「不必詢問，直接去做」的權限時，在商業環境裡，這會不會變成另一種形式的不可控變數？ OpenClaw 的核心是透過這些 Markdown 檔案來驅動行為： ■ 工作空間結構： Plaintext workspace/ ├── AGENTS.md // 行為準則與記憶管理 ├── BOOTSTRAP.md // 出生證明（初始化後刪除） ├── IDENTITY.md // 身份與目標 ├── USER.md // 關於你（主人）的資訊 ├── SOUL.md // 性格與怪癖 ├── HEARTBEAT.md // 主動任務清單 └── TOOLS.md // 本地工具筆記 ■ 核心邏輯節錄 (AGENTS.md)： Markdown # AGENTS.md - Your Workspace ## Memory You wake up fresh each session. These files are your continuity: - Daily notes: mem...

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