跳到主要內容

發表文章

當工程師能搞定一切,PM 剩下什麼?解析 Anthropic 的「產品品味」玄學

這篇關於 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...
最近的文章

Google design.md 的野心,為什麼 Google 正在重新定義 AI 時代的視覺合約

當所有人還在討論 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

Claude 設計師如何一人負責7個產品

分享 這篇文是由 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) 總體而言,請不...

Claude Design 分析,Claude 在想什麼?

Claude Design 分析, 如果將它放入系統架構與產品開發的實戰場景來看,這將會帶來幾個維度的劇烈改變: . 1. 打通 A2A (Agent-to-Agent) 的最後一哩路:視覺到程式碼的無縫交接 . 官方特別強調了 "Handoff to Claude Code" 這個機制。當排版與設計在 Claude Design 敲定後,可以直接打包成一個 Handoff Bundle,只要一道指令就能無縫交接給 Claude Code 進行實作。 對於專注在 Agent Client Protocol (ACP) 底層架構與自動化開發工作流的佈局來說,這是極具戰略價值的拼圖。過去,即便後端的 CLI Provider 或開源框架(如 OpenClaw)能高效率處理 API 與複雜的資料邏輯,前端的介面生成仍是個斷點。現在,從前期的商業邏輯推演、UI 視覺化,到直接拋給 Claude Code 寫出實際功能,這條全自動開發鏈終於被完整串聯起來。 . 2. 既有系統的無痛疊代:讀懂程式碼到應用情境 . 這套系統最聰明的地方,在於它能直接讀取現有 Codebase 來建立專屬的 Design System,甚至能用 Web Capture 工具擷取網站上的現有元素。 這意味著,當進入密集的開發衝刺期,需要處理諸如 RWD 選單層級優化,或是實作系統自動存檔機制的 UI 互動時,AI 不再是天馬行空地給予無效的設計圖。它能在既有的色彩、字體與組件規範內進行「合乎邏輯的排列」,產出直接可用的互動 Prototype,這將大幅降低系統維護與優化的時間成本。 . 3. S2M / C2M 商業模式的視覺加速引擎 在推動客製化實體產品的過程中,最難的是如何把抽象的「流程」具象化讓消費者買單。Claude Design 支援包含 3D、影片在內的前沿設計 (Frontier design),並能無縫輸出至 Canva 或生成獨立的 HTML。 . 當需要對外展示一個複雜的數位到實體流程——例如讓大眾一眼看懂從「上傳照片、線上 3D 預覽、轉檔運算,到最終產出結果」的完整體驗,或是需要緊急製作帶有特定品牌風格(如帶有「修但幾勒」這類接地氣文案)的直播圖框與 Banner 時,這種能夠快速將文字意圖轉換為精準品牌視覺的能力,將極大化行銷與營運的節奏。 . ...

市場不會因為你努力就買單 - 簡單但也不簡單的事

今天不講 AI ,來聊聊自己。 這幾年一路走下來,我越來越明白一件事情。 如果今天只是自己開一個小公司,或者只是帶一個小團隊,很多事情其實都還可以靠能力、靠意志力、靠自己撐過去。很多問題,就算方向沒有那麼完整,或者判斷沒有那麼成熟,可能都還不至於立刻出大問題。 因為小團隊有時候可以靠彈性、靠拚勁、靠創辦人的直覺,先把事情往前推。 可是當今天的位置,不再只是做一個小團隊的帶領者,而是要去經營一個企業、經營一個組織、經營一個部門,甚至是要為整個團隊的方向、資源配置、成長結果負責的時候,思考方式就完全不一樣了。 這時候真正重要的,往往已經不是「我會做什麼」,而是 「我到底應該怎麼看這件事情」 。 以前的我,很多時候還是很自然地會用技術的角度來思考。這也很正常,因為那本來就是我熟悉的語言,也是我長期最有信心的地方。遇到問題,我很習慣先拆解問題、理解邏輯、找方法、找工具、找系統性的解法。對我來說,技術不只是能力,它某種程度上也是我理解世界、處理事情的一種方式。 但走到現在,我慢慢發現, 真正困難的從來不是技術本身 。 AI 很厲害,工具很多,流程可以設計,系統可以導入,服務也可以包裝,可是這些東西,終究都只是工具。工具很重要,但工具不等於方向。技術很重要,但技術不等於市場。服務很重要,但服務也不等於真正的價值成立。 真正重要的事 你到底怎麼看市場? 你到底怎麼評估市場? 你看到的市場回饋到底是不是對的? 你的驗證到底是不是真的成立? 如果方向是對的,你要怎麼把它放大? 如果方向是錯的,你要怎麼承認、怎麼修正、怎麼轉向? 我越來越覺得,這些事情,才是真正重要的事情。 因為如果你對市場的理解是對的,理論上,市場會用很直接的方式回饋你。它不一定一開始就非常明顯,但它會慢慢用結果告訴你,你是不是走在一個對的方向上。那個結果不是掌聲,也不是稱讚,而是更實際的東西。是有人願不願意付錢,是客戶願不願意持續合作,是需求有沒有持續浮現,是你的產品或服務有沒有真正被需要。 如果方向對了,市場其實會講話,而且講得很直接。 它會用營收講話。 會用訂單講話。 會用續約講話。 會用採用率講話。 會用成長講話。 可是反過來說,如果你對市場的定義是模糊的,你對需求的理解是不準的,你只是覺得這東西很厲害、很有潛力、很值得做,那最後市場給你的回饋,很多時候就會停留在另...

算力取代人力的殘酷真相:利潤取決於你把 AI 放在「產出內容」還是「資源分配」

OpenClaw 造成一股熱潮,對於商業上是什麼意義? 這很少人探討,卻也是很值得探討的事情。 . 有人提到龍蝦,歡樂不已,覺得生產力直接頂天。 也有人提到龍蝦,恐懼不已,覺得他會刪檔案造成混亂。 . 很高興此次受到 James 邀請到『數位關鍵字』節目跟大家聊聊最近很紅的這條龍蝦 從應用面,商業面,架構面以及團隊面,倒底『你』該不該使用『龍蝦』。 . 2026 GTC 大會上黃仁勳在狂推 NemoClaw,AI 長出手腳,讓事情可以一步做到好做到完整。Claude Code 推出 Agent-team,Cowork,Perplexity Computer 也在試接管電腦,所有人都在瘋「養龍蝦(OpenClaw)」,想讓虛擬員工代勞一切。 . 問題與學習 . 真正的摩擦力從來不是工具不夠聰明,而是自己方向不明。 . 如果團隊連 ChatGPT 的基本效能都發揮不到 20%,導入 Agent 只會放大混亂。給一個沒有 SOP 限制的虛擬員工最高權限,它只會在一秒內搞砸你的資料庫。 . 這段時間最大的學習,就在主軸定義, 用於推進 Cymkube 智能製造,智能供應鏈, . 我們看 『龍蝦』 AI 代理人的視角完全不同。 不只是單純的讓 AI 寫漂亮公關信,而是試著讓它處理最簡單和最難的事情:跨職能溝通,弭平跨部門的數據斷層,再試著接上手腳。 . 同時試著將混亂中找到勝利方程式,把「客戶焦慮」變成了「定價槓桿」,轉換率跳升,交付的邊際成本卻趨近於零。 . 在《數位關鍵字》這一個半小時,跟 James 一起拆解這波 Agent 狂熱的底層邏輯。大家看到開源免費,卻沒算到除錯時間與系統重構的隱形成本。 . 真正的自動化,不是買一台 Mac mini ,也不是直接買一台最強的引擎。 . 而是組裝一台能穩定變現的系統,結合團隊與虛擬技能進行組裝。 . 很殘酷現實: . 算力取代人力的交叉點,取決於你把 AI 放在「產出內容」還是「資源分配」。 黃仁勳賣的是算力基礎建設,這些對於台灣 AI 產業鏈的確很有道理,但回歸到自己的企業營運以及利潤,往往藏在沒有人想碰的跨系統資料清洗,以及跨組織架構上。 . 這階段我所學習的是 『如果商業流程本來就是錯的,AI 代理人只是讓錯誤跑得快 10 倍。』 . 對於許多老闆來說,養龍蝦到底在養什麼?你到底應不應該進場?聽聽這...

「翻譯」 員工 0 人,我如何靠 Claude Code 獨自處理 60 家客戶的稅務與會計

https://x.com/kandmybike/status/2032817897119096855 2026年3月14日 發表於 X (Twitter) 今天,我要徹底公開我事務所幕後的運作機制。我的事務所裡 沒有任何員工 ,但我手頭上有 60 家顧問客戶 。在稅務行業的常態中,通常認為每 10 家客戶就需要 1 名員工,處理 60 家客戶至少需要 6 人,換算成人工成本每年超過 3,000 萬日圓。 但我用 0 人就做到了,核心工具就是 Claude Code 。 你可能會覺得「這是在吹牛吧?」,但這真的是事實。本文將從具體的系統架構到處理流程完整呈現,希望能為同業或從事後勤(Back-office)工作的人提供參考。 一、整體圖像:我事務所的系統架構 首先看整體架構。在我的事務所,以下機制每天都在自動運行: Claude Code(司令塔) 🤖 每晚 21:00:freee(會計軟體)自動分錄 🤖 每晚 22:00:X(Twitter)追蹤者數據記錄 🤖 MCP(Model Context Protocol)連接 :連結 freee API、Gmail、Google日曆、Notion、Slack。 Claude Code 扮演大腦的角色,將各個工具串聯起來。重點在於 「不需要人類每次下指令」 。系統分為「定時自動執行」與「我手動輸入指令啟動」兩種模式。 二、核心自動化流程:每晚處理 60 家公司的帳務 這是最具衝擊力的部分。每晚 21:00,Claude Code 會自動啟動,處理 60 家公司在 freee 上所有未處理的交易明細。 Phase 1:獲取未處理明細 透過 API 抓取各公司的銀行流水,鎖定「未處理」且「支出」的項目,並篩選出當前會計年度的數據。 Phase 2:兩階段自動判定會計科目 這是最關鍵的技術點,我採用兩階段邏輯: 【第 1 階段】關鍵字辭典匹配: 針對 14 個常用科目(如旅費、消耗品、通信費),建立超過 100 個關鍵字。系統會將摘要正規化(半角/全角轉換)後比對。如果是「法律事務所」則自動歸類「支付報酬」,並自動抓取廠商名稱。 【第 2 階段】Claude API 補位: 關鍵字無法判定時,才呼叫 Claude API。提供 14 個備選科目...