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

SAP、Shopify 和 Salesforce 等軟體巨頭近期積極擁抱或建立 MCP (Model Context Protocol, 模型上下文協定) ，不僅僅是技術上的跟風，更是 企業軟體商業模式與互動典範的重大轉移 。 這些 SaaS 巨頭（或是其生態系開發者）陸續宣布支援或整合 MCP 時， 股票市場並沒有出現像「發布全新殺手級產品」那樣一夜暴漲的戲劇性波動。 在華爾街與機構投資人的眼中，支援 MCP 屬於「底層基礎設施升級」 與 「防禦性護城河策略」，它不是短期的炒作題材（不像推出某個冠上 AI 名稱的聊天機器人那麼吸睛），而是確保公司未來五到十年不會被 AI 時代淘汰的關鍵保命符。 大家心中的問題，這些大廠放棄掙扎了嗎？ 先說結論： 他們絕對沒有捨棄原有的 UI（使用者介面）和系統流程。 相反地，他們是在做「系統擴容」——把原本「 只給人類操作的軟體 」，升級為「 也能讓 AI 代理（AI Agents）無縫操作的基礎設施 」。 1. 意義上有什麼不同？為什麼是現在？ 在過去，企業軟體的護城河是「功能齊全的 UI」加上「綁定用戶的專屬工作流」。但隨著大型語言模型（LLM）的崛起，互動模式改變了，這帶來了幾個根本性的差異： 統一對接標準，終結 API 碎片化： 過去如果要讓 AI 幫忙查 Salesforce 的資料，開發者必須針對 OpenAI、Anthropic、Google 各寫一套 API 串接邏輯。MCP 就像是「AI 界的 USB Type-C」，提供了一個標準協定。Salesforce 或 SAP 只要提供一個 MCP Server，所有的 AI 模型就能以安全、標準化的方式讀取其上下文與數據。 從「軟體作為目的地」到「資料即服務」： 過去，業務員必須「打開（登入）」Salesforce 才能工作。未來，業務員可能在 Slack 或自建的 AI 助理中打字：「請幫我總結客戶 A 昨天的會議，並更新他在 SAP 裡的報價單。」AI 透過 MCP 在背景完成一切。SaaS 巨頭意識到， 未來的入口可能不再是他們自家的 App 畫面，而是各種對話框 。 捍衛「真實資料來源 (System of Record)」的霸主地位： 這些公司知道，他們真正的價值不在於「按鈕設計得多好看」，而是裡面儲存了企業最核心的客戶、庫存、財...

過去，你需要親自登入 Meta Ads Manager，在複雜的介面中點擊數十次來設定受眾、調整預算、下載 CSV 報表來分析。現在，Meta Ads MCP (Model Context Protocol) 就像是給了 AI（例如你熟悉的 Claude 或是 Cursor）一把直通你廣告帳戶後台的專屬鑰匙，以及一本完整的操作手冊。 等於讓你把 Meta Ads 變成一個可以用程式碼和自然語言呼叫的函數。你目前會想先拿哪一個項目來測試這個整合？是想先讓 AI 幫忙分析現有的廣告數據，還是直接嘗試為某個專案建置一套自動化的投放流程？ 在 Meta 的系統架構中，「Meta Ads」本身就是一個涵蓋旗下所有社交平台的統一廣告投放中樞。當這個 MCP (Model Context Protocol) 伺服器與你的「Meta 廣告帳號」連線時，它接管的是整個底層的 Ads API。 這意味著，只要是 Meta Ads Manager 能投放與管理的版位，這個 AI 代理 (Agent) 都能直接存取與操作，這包含了： Instagram: 動態消息 (Feed)、限時動態 (Stories)、Reels、探索區塊 (Explore)。 Facebook: 動態消息、Reels、Marketplace、右側欄位等。 Messenger: 收件匣廣告、贊助訊息。 Audience Network: Meta 的外部合作應用程式與網站聯播網。 實際應用上的意義 這代表你可以透過自然語言，非常精準地控制 AI 針對特定平台進行操作： 精準設定版位 (Write)： 你可以直接告訴 AI：「幫我建立一個全新的廣告組合，預算每天 20 美金， 版位只要鎖定 Instagram 的 Reels 和限時動態 ，不要投放到 Facebook。」AI 就會在後台自動將 Placement 設定為純 IG 平台。 跨平台數據拆解 (Read)： 你可以詢問 AI：「幫我拉出上個月的廣告報表，並 對比 Facebook 動態消息與 Instagram 限時動態的點擊成本 (CPC) 與轉換率 。」AI 會直接調閱詳細報表並幫你總結出哪個平台的成效更好。 至於 可以做到什麼程度 ？我們可以從輕到重分成四個層次來看： 1. 深度數據洞察與即時診斷 (Rea...

深度解析 Hermes Agent Curator：AI 代理的自我維護與技能生命週期管理 在構建與研究 AI Agent（如 Claude Code、OpenClaw 等）的自動化工作流時，代理的「長期記憶」與「技能維護」一直是一大挑戰。Nous Research 為 Hermes Agent 推出的 v0.12.0「Curator」更新，正式補齊了技能生命週期管理系統的最後一塊拼圖。 本文將詳細解析 Curator 的核心能力、解決的痛點、實作方式、目前的社群回饋，以及未來可改進的方向。 為什麼需要 Curator？（解決的核心痛點） 在 Curator 推出之前，Hermes Agent 擁有強大的自我改進迴圈（Self-improvement loop）：當代理成功解決複雜任務或修正錯誤後，會自動將經驗寫成「技能（Skills）」保存下來。然而，這個機制存在一個致命缺陷—— 技能只會單向增加，缺乏「遺忘」或「淘汰」機制 。 隨著自動化工作流的持續運行，這會帶來以下嚴重問題： Token 消耗與上下文污染 ：社群用戶回報，當代理累積了上百個技能後，系統提示詞（System Prompts）的體積會暴增，每次對話可能白白消耗掉 4,000 多個 Token。 技能碎片化與衝突 ：代理可能會為了微小的差異，生成數十個高度相似的狹隘技能，導致代理在選擇工具時產生混淆。 習得性無助（Learned Helplessness） ：如果代理在某次任務中因為暫時性的網路或環境問題失敗，它可能會記錄下「這個工具不能用」的過時經驗，並長久受到這個錯誤的負面規則影響。 Curator 可以做什麼？他做到了什麼事情？ Curator 是一個作為背景守護行程（Background Maintenance Pass）運作的自主代理。它會在不干擾主要對話的情況下，定期幫代理「打理」工具箱。 1. 雙階段的技能淘汰與封存機制（確定性狀態機） Curator 會追蹤每個代理生成技能的使用數據（包含讀取、使用、修改次數與最後使用時間），並執行無 LLM 介入的自動轉換： Stale（過期） ：超過 30 天未使用的技能，將被標記為過期，降低其在提示詞中的優先級。 Archived（封存） ：超過 90 天未使用的技能，將被移出運作...

這篇關於 Anthropic 產品負責人 Cat Wu 的訪談，不僅僅是揭秘一家頂尖 AI 實驗室的內部運作，它更像是一份 寫給新時代產品開發與管理的宣言 。 我自己覺得實在太精彩，務必要翻譯出來，擷取裡面重點讓自己記錄一下，和自己跟 AI 互相聊之下的摘要整理。 以下是這場訪談的核心要義，以及我這段時間對於 AI 時代下 PM 職位的短暫解讀，和此篇對談的解讀 告別冗長 PRD 路線圖 過去 PM 習慣以 6 到 12 個月為單位制定產品路線圖（Roadmap），因為寫程式成本很高。但在 Anthropic，功能的交付週期被壓縮到一個月、一週，甚至 一天 。冗長的 PRD（產品需求文檔）大多被淘汰，取而代之的是清晰的團隊原則（Team Principles）與每週的數據檢視。 深度解讀：Less is More 的極致體現 當 AI 大幅降低了「寫程式」的門檻與時間成本，開發的瓶頸就不再是工程產出，而是 決策速度 。傳統跨部門對齊、層層審批的重型管理模式已經失靈。這印證了高效能營運的核心：將開發任務拆解為以「天」為單位的極簡衝刺（Sprint）。與其把時間花在寫厚重的規格書，不如專注於打造無摩擦的發布流水線，用最短的時間驗證核心邏輯。這是一種「少即是多」的開發管理美學——砍掉多餘的行政流程，直擊目標。 職務邊界消失：懂技術邏輯才能掌握「產品品味」 工程師、PM 與設計師的界線正在消失。Anthropic 的 PM 幾乎都有工程背景，甚至直接寫 Code。Cat Wu 認為，未來的核心競爭力在於「產品品味（Product Taste）」。擁有工程背景之所以重要，是因為你能精準判斷一件事的「開發成本」，進而做出正確的優先級決策。 深度解讀：拒絕只做「報表管理者」 這戳破了許多傳統管理者的盲點。在技術驅動的時代，缺乏技術底蘊、只會畫大餅的「純管理職」將被邊緣化。真正的技術領導力，往往建立在對底層架構與數據邏輯的深刻理解上（例如深諳廣告演算法或 SEO 底層邏輯）。當代優秀的產品人，必須具備工程師的務實與設計師的敏銳，能一眼看穿哪些功能是只需一小時搞定的順手之勞，哪些是會拖垮系統效能的無底洞。 「適度信仰 AGI」：專注當下轉換，而非等待完美逼真 做產品最難的，是具備「恰好正確程度的 AGI 信仰（The right amo...

當所有人還在討論 claude design, 且同時看待 figma 與 adobe 股價低落的同時，Google 悄悄地從規範出發 design.md 的出現，標誌著設計系統從「人類看的視覺規範」正式演進為「機器執行的視覺代碼（Design as Code）」 如果我們把產品開發看作是一場工業革命，design.md 就是那套 「單位」 。在單位普及前，零件無法通用；有了它，前端組裝線才能真正實現自動化。 Google 很清楚，誰定義了 規範（Schema），誰就定義了工作流。當所有的 AI Agent 都優先支援 design.md 時，設計師在 Figma 裡畫得再漂亮，最後還是得匯出成 Google 定義的規格才能落地。 設計師的身份轉變：從「創作者」到「品管員／架構師」？ 針對你最後的問題：設計師是在做設計，還是在做 AI 的品管？ 這可能是一個職能重組的過程： 低階設計的消亡： 調整圓角、對齊邊距、更換 HEX 色碼這類「體力活」，將完全被 design.md 自動化。 設計即「規則定義」： 未來的設計師更像是一位 Protocol Engineer（協議工程師）。他們的工作是定義：在什麼情境下（Context），系統應該如何反應？（例如：當使用者感到焦慮時，UI 的節奏與飽和度應如何自動縮減？） 品管（QA）的昇華： 設計師不再是檢查像素，而是檢查。邏輯的一致性 對於 Cymkube 或 Cympack 來說，這種技術變革意味著：一人研發團隊的產能將再次擴張。 當你把品牌感覺轉化為機器可讀的契約，你省下的不只是 30% 的重工成本，而是贏得了 「快速市場反應」 的能力。在 AI 時代，產品的勝負不在於誰的 UI 畫得更美，而在於誰能以最快速度、最低成本，把正確的品牌體驗精準地交付到用戶面前。 當設計流程完全被「規格化」後，下一個會被 AI Agent 攻克的「溝通摩擦力」會出現在哪個環節？ 是後端的 API 協議，還是產品經理的 PRD？ ref https://github.com/google-labs-code/design.md

分享 這篇文是由 Anthropic 的設計師 Ryan Mather (@flomerboy) 所發表，他在文中分享了自己如何利用剛發布的 Claude Design ，以「一人之力負責公司 7 個產品線設計」的心得與建議。 📝 推文核心內容翻譯（使用 Claude Design 的 7 個建議）： 設定好你的設計系統和核心畫面 (Design System & Core Screens) 這裡非常值得你花上一個小時的時間進行前期的設定與最佳化。把你現有的程式碼庫、設計檔和品牌素材都餵給 Claude，讓它自動建構出一套設計系統。之後的每個專案都會自動套用你的顏色、字體和組件，長期下來能帶來極大的複利效應。 與你的工程師即時迭代 (Iterate in real-time) 過去那種「設計師出圖 → 丟給工程師實作 → 來回修改」的模式已經過時了。現在最好的方式是，開個會與工程師一起看著畫面設計新功能。Claude 製作原型的速度極快，你們可以在對話中持續迭代、圍繞概念與限制即興發揮，看著想法當場成形。 使用評論工具進行快速精準的修改 (Comment tool for precision) 在產出粗略的初稿後，你可能會有數十個細節想要微調（例如按鈕間距、顏色更改等）。用文字去描述所有想要的變更是很麻煩的——所以千萬別那樣做！直接在元素上點擊評論並給出具體的修改指示即可，精準又快速。 讓 Claude 為你的想法製作影片展示 (Video Demos) 一般來說，Claude Design 幾乎可以實現任何你能想到的事情。老實說，它的運作邏輯其實更像是 Claude Code（程式碼代理），而不是傳統基於畫布 (canvas-based) 的設計工具。 善用連接器 (Connectors，尤其是 Docs/Slack) 一旦設定好連接器，你可以丟給它這樣的提示詞：「請閱讀這份產品吐槽大會 (product roast) 的會議記錄，並針對裡面提到的所有問題，製作一份探索不同設計解決方案的簡報 (Deck)。」然後你就可以出門散個步放鬆一下，帶著全新的視角回來看它自動生成的結果，把複雜的腦力活交給它。 讓 Claude 建立客製化的即時工具 (Custom on-the-fly tools) 總體而言，請不...