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

AI 第二大腦，其實沒那麼玄

noreply@blogger.com (Caesar Chi) — Sat, 30 May 2026 15:50:02 +0800

最近看到很多人在討論：

Obsidian + Claude Code 可以打造 AI 第二大腦。

聽起來好像很硬、很技術、很像工程師才會用。

但如果用簡單一點的方式講，其實它在做的事情是：

把你散亂的筆記、資料、靈感、專案，整理成 AI 看得懂的知識庫。

這樣之後 AI 就不只是回答你通用答案，而是可以根據你的資料，幫你整理、查找、產出內容。

為什麼這件事值得關注？

因為現在大家不是沒有資訊。

反而是資訊太多。

我們每天可能都有：

會議紀錄、課程筆記、文章收藏、靈感備忘、專案資料、聊天紀錄、AI 對話、客戶需求、研究資料、內容素材。

但問題是：

真正要用的時候，常常找不到。

就算找到了，也要重新整理一次。

更麻煩的是，每次問 AI，都要重新解釋背景。

所以很多時候不是 AI 不夠強，而是我們自己的資料沒有整理成 AI 可以使用的樣子。

這件事可以解決什麼？

簡單說，它可以幫你把「散亂資訊」變成「可用產能」。

例如：

把課程筆記整理成重點
把會議紀錄整理成待辦
把靈感整理成文章大綱
把專案資料整理成進度報告
把研究資料整理成簡報或企劃
把過去的 AI 對話變成可重複使用的知識庫

重點不是多學一個工具。

而是讓你手上的資料，真的可以被再次使用。

誰適合？

我覺得特別適合這幾種人：

常常做筆記的人
資料很多但很難整理的人
內容創作者
學生、研究者
PM、行銷、顧問
老師、講師
創業者
想把 AI 放進工作流程的人

尤其是這種人：

明明累積很多資料，但一直沒有把資料變成成果。

這套方法可能會很有幫助。

可以怎麼開始？

其實不用一開始就搞得很複雜。

可以先分三步：

第一步：先把資料集中

先找一個地方放資料。

例如 Obsidian 這類筆記工具。

把你的筆記、靈感、專案、素材、課程內容，先集中起來。

不用一開始整理得很完美。

先做到一件事就好：

之後找得到。

第二步：讓資料有一點基本結構

不用很複雜。

先簡單分成幾類就好：

工作
學習
專案
靈感
素材
已完成資料

重點不是分類漂亮，而是你自己看得懂，AI 也看得懂。

第三步：讓 AI 幫你整理和產出

當資料有基本結構之後，就可以用 Claude Code 這類工具協助：

幫你找資料
幫你整理重點
幫你產出摘要
幫你檢查缺漏
幫你把素材變成文章、簡報、企劃或報告

這時候 AI 才會開始變得真正好用。

因為它不是憑空回答，而是根據你的資料工作。

有興趣可以先查這些關鍵字

不用一次全部看懂。

先知道方向就好：

Obsidian
Claude Code
AI 第二大腦
Second Brain
Personal Knowledge Management
Obsidian AI workflow
Obsidian + Claude Code

如果想再深入一點，可以查：

Obsidian Dataview
Obsidian Dashboard
CLAUDE.md
Obsidian MCP
Claude Code MCP

最後想說

我覺得這件事不是要製造更多資訊焦慮。

相反地，是希望破除資訊壁壘。

很多東西其實沒有那麼神秘，只是以前被講得太複雜。

Obsidian + Claude Code 這件事也是。

如果大家有興趣，我們可以來揪一團研究看看。

不一定是我講，重點是找真的懂、真的做過的人，把這件事講成正常人聽得懂的版本。

不要玄學，不要堆名詞。

歡迎讓我知道，留言給我 https://www.facebook.com/clonncd

In the AI Era, We Do Not Lack Output — We Lack Verifiable Output

noreply@blogger.com (Caesar Chi) — Fri, 29 May 2026 23:46:18 +0800

In the AI Era, We Do Not Lack Output — We Lack Verifiable Output

If we agree that AI can produce different thinking models and working methods when it takes on different roles and identities, then we should no longer use the old PM, RD, and Designer workflow to structure how work should happen in the AI era.

Traditional workflows were essentially formed because humans have limited role flexibility and cannot freely switch between different areas of expertise. Over time, this created a collaboration structure based on fixed roles and handoffs.

But with the emergence of AI, output capability has been greatly amplified. The real question is no longer “Who will do the work?” but rather:

Who can verify whether the output is correct, feasible, and deliverable?

From Prompt Output to Domain Calibration

In the past, many people believed that the key to AI was the prompt.

But in enterprise and manufacturing contexts, the real focus is not the prompt.

The real questions are:

After AI generates an output, who will verify it?
Who will calibrate it?
Who will turn mistakes into rules?
Who will turn experience into a system?

This is the capability that an enterprise can truly accumulate.

When someone uses AI to enter a field they are not familiar with, AI can generate results that appear complete and professional. However, the user often cannot determine whether the underlying logic is actually correct.

This is similar to Vibe Coding. It can quickly produce a product that looks functional, but without engineering expertise, security awareness, system architecture, and testing capabilities, the final result may only look polished on the surface while carrying significant risks underneath.

The same applies to manufacturing.

AI can generate designs, specifications, quotations, manufacturing processes, and proposals. But if these outputs are not verified through real manufacturing experience, they are only “seemingly feasible” content. They may not actually be manufacturable, quotable, scalable, or deliverable.

Therefore, the new workflow should not be:

PM → RD → Designer → Factory → Customer

Instead, it should become:

Requirement / Problem
↓
AI generates multiple possible solutions
↓
Professional roles verify, calibrate, and refine the output
↓
The system records feasible parameters and constraints
↓
A reusable AI capability is formed
↓
The result is delivered to customers or used in internal workflows

The most critical new role here is not the traditional PM, nor the traditional Designer. It is a work model focused on validating and improving output.

Therefore, in the AI era, the core human capability is not simply generation.

It is verification.

The goal is not to let AI replace PMs, RDs, or Designers. Instead, the goal is to build a working system where AI-generated outputs can be professionally calibrated, constrained by data, verified through process, and improved through feedback.

This is the essence of Manufacturable AI:

AI should not merely generate answers.
It should generate results that can be verified, corrected, manufactured, and delivered.

Prompting is a one-time output.
Calibration is an accumulative capability.

AI should not only be able to generate answers.

It should generate results that can be verified, corrected, manufactured, and delivered.

This is the core of Manufacturable AI.

AI 時代不是缺產出，而是缺「可驗證的產出」

noreply@blogger.com (Caesar Chi) — Fri, 29 May 2026 23:41:29 +0800

AI 時代不是缺產出，而是缺「可驗證的產出」

如果我們同意 AI 在不同角色與身份下，會產生不同的思考模型與工作模式，那我們就不應該再用舊有的 PM、RD、Designer 流程去組建 AI 時代的工作方式。

傳統流程其實是人類因為角色能力有限、專業無法自由切換，而長期形成的協作結構。但 AI 的出現，讓產出能力被大幅放大，真正的問題不再是「誰來做」，而是「誰能驗證它是否正確、可行、可交付」。

從 Prompt 產出，走向 Domain Calibration

過去大家以為 AI 的重點是 prompt。

但在企業與製造場景裡，真正的重點不是 prompt，而是：

AI 產出後，誰來驗證？
誰來校準？
誰來把錯誤變成規則？
誰來把經驗轉成系統？

這才是企業真正能累積的能力。

當一個人使用 AI 進入自己不熟悉的領域時，AI 可以產生看似完整的結果，但使用者往往無法判斷其底層是否正確。就像 Vibe Coding 可以快速做出看似能運作的產品，但若缺乏工程、安全性、架構與測試能力，最後可能只是表面漂亮，實際上充滿風險。

製造業也是一樣。AI 可以生成設計、規格、報價、製程與提案，但這些結果若沒有被真實製造經驗驗證，就只是「看起來可行」的內容，而不一定真的能被製造、報價、量產與交付。

所以新的工作流程不應該是：


PM → RD → Designer → Product → Delivery

而應該變成：


需求 / 問題
   ↓
AI 產生多種可能解法
   ↓
專業角色進行驗證、校準、修正
   ↓
系統記錄可行參數與限制條件
   ↓
形成可重複使用的 AI 能力
   ↓
交付給客戶或內部流程使用

這裡最關鍵的新角色，不是傳統 PM，也不是傳統 Designer，而是前面提到的會是專注於結果產出的工作模式。

因此，AI 時代的人類『核心能力』不是單純的生成，而是『驗證。』

不是讓 AI 取代 PM、RD、Designer，而是建立一套能夠讓 AI 產出被專業校準、被數據約束、被流程驗證、被結果回饋的工作系統。

這就是「可製造 AI」的本質：
讓 AI 不只是產生答案，而是產生能被驗證、能被修正、能被製造、能被交付的結果。

Prompt 是一次性的產出。
Calibration 是可累積的能力。

AI 不只是要會生成答案，
而是要產生能被驗證、能被修正、能被製造、能被交付的結果。

這就是可製造 AI 的核心。

Figure AI 這場直播，讓企業看見下一個競爭門檻：AI 從回答問題，走向親自上工

noreply@blogger.com (Caesar Chi) — Sun, 17 May 2026 23:58:41 +0800

Figure AI 這場直播，表面上看起來像是在做一件很直白的事：

把 humanoid robot 放進真實場景裡，讓大家看它怎麼工作。

它不只是一種「機器人 demo」，也不只是有趣這件事情而已。

它真正想測試的，是企業會不會開始改變一個更根本的認知：
AI 到底只是軟體工具，還是已經開始具備「勞動單元」的雛形。

重要分水嶺

因為過去兩年，市場對 AI 的想像大多還停留在 LLM / AI 回應內容

寫文案、寫 code、做摘要、做客服、做知識助手。
這些都很重要，但它們本質上仍然停留在「資訊處理層」，數位流程上。

Figure 想往前推的，不是另一個更會講話的模型，

而是讓市場開始重新思考：

當 LLM 負責語意推理，AI 負責感知判讀，Agent 負責流程編排，而 Robot 負責實體執行時，企業裡有沒有一些原本只能靠人撐住的流程，開始可以被重新定義？

這場直播真正的價值

它不是在證明「機器人很酷」，
而是在試圖證明另一件更接近商業本質的事：

AI 不再只是幫白領提高效率的工具，而是有可能慢慢變成企業可採購、可管理、可衡量報酬的執行基礎設施。

有更多細節可以從中探索，也更多可以知道為什麼中國一直搶佔這個機器人賽道領域。

直播連結，

https://www.youtube.com/watch?v=luU57hMhkak

川習會後判斷：台灣在談判桌的哪個位置

noreply@blogger.com (Caesar Chi) — Sun, 17 May 2026 23:55:00 +0800

川普這次真正丟出的訊號，不只是「沒對習近平承諾什麼」。

更值得警覺的是：台灣議題正在被放進美中談判框架裡，而美國對台軍售的確定性，被刻意保留。

表面上，川普說他和習近平談了很多台灣，但沒有做任何承諾，並表示對台軍售很快會有決定。但深一層看，這句話的意思不是「我明確挺台」，而是：*我兩邊都不把話說死。*

這釋放了幾個訊號：

第一，川普沒有承諾北京，但也沒有明確承諾台灣。他保留的不是立場，而是談判空間。

第二，對台軍售被放進了交易語境。過去美國通常避免讓北京介入對台軍售決策，但現在這件事被直接拿到美中領袖對話裡談，這本身就是變化。

第三，這碰到「六項保證」的敏感邊界。因為其中一項精神，就是美國不應就對台軍售與北京協商。

第四，美國制度上並沒有放棄台灣。《台灣關係法》仍在，台灣的防衛承諾不是一句話就能推翻。

第五，川普同時也在提醒台灣：不要主動改變現狀。也就是說，美國支持防衛，但不想被拖進一場由台灣主動升級的戰爭。

第六，北京正在把台灣問題推向美中關係核心。意思是未來不只安全議題，連經貿、科技、地緣談判，都可能被綁進台灣條件。

第七，台灣政府正在努力把焦點拉回「嚇阻」而不是「交易」。因為軍售如果被視為交易籌碼，台海穩定就會開始變質。

所以，這件事最值得記住的一句話是：

台灣沒有被直接拋棄，但正在被放上談判桌。

接下來真正要看的是三件事：

1. 美國是否正式推進下一批對台軍售 2. 白宮或國務院是否重新確認六項保證 3. 北京是否利用這種模糊空間，加大對台軍事或外交施壓

Claude code 政策調整，請大家務必要注意 6 月份重點

noreply@blogger.com (Caesar Chi) — Fri, 15 May 2026 01:55:48 +0800

很多人最近應該都收到這封信，會以為重點是：
「Claude 每個月多送你 200 美元可以用。」

如果講白一點，事情其實是這樣：

Anthropic 發現，越來越多人不是只拿 Claude 來聊天，
而是拿它去接別的工具、別的服務，甚至包成別的產品在用。

以前這些用法，有些人其實是在用原本的訂閱額度，
去放大 Claude 在外部服務上的能力。

所以官方現在做的事，就是把這條線劃清楚。

之後你平常聊天、互動，用的是原本訂閱額度。
如果你要把 Claude 接到其他工具、跑自動化、當成別的服務背後的能力，就改用另外一筆 credit。

說得好聽，這叫「規則更清楚」。
說得直接一點，就是：

以前大家有機會用訂閱方案，把 Claude 的能力接出去放大用。
現在這個口子，被補起來了。

所以這不只是送你 200 美元。
而是官方開始把：

- 一般聊天
- 自動化使用
- 外部服務串接

這三種用法，正式分開算。
這代表一件事：
Claude 還是能用，但平台開始更認真管理「你怎麼用它賺價值」這件事了。
---

你的錢，就是我的錢，薛翻啦！

什麼是 DESIGN.md？

noreply@blogger.com (Caesar Chi) — Sun, 10 May 2026 13:49:42 +0800

什麼是 DESIGN.md？

DESIGN.md 是由 Google Stitch 推出的一種開源格式，專門用來讓 AI 撰寫程式的 Agent（如 Claude Code、Cursor、Windsurf 等）理解專案的設計系統。它可以被理解為視覺設計領域的 AGENTS.md 。

它的核心精神在於將設計視為嚴謹的邏輯與系統工程。這份文件結合了機器可讀的 YAML 設計標記（Design Tokens）與人類可讀的 Markdown 說明文字。YAML 負責給予 AI 精確的數值（例如色碼、字級），而 Markdown 則賦予這些數值語意和使用情境。

DESIGN.md 的核心設計方法與技巧

要讓 AI Agent 完美遵循品牌邏輯，撰寫 DESIGN.md 時需要掌握以下技巧：

雙層架構（YAML + Markdown）：不要只給 AI 數值，要給予脈絡。在 YAML 區塊定義像 #1A1C1E 這樣的精確標記，並在 Markdown 中說明「這是主背景色，傳達科技與冷靜感」。
遵循標準的 8 大區塊：根據官方規範，依序定義：品牌總覽、色彩系統、字體階層、版面與留白、深度與陰影、形狀、元件樣式，以及 Do's and Don'ts 。
定義語意化標記（Semantic Tokens）：使用變數參照（如 {colors.primary}）而非寫死色碼。這能讓 AI 知道該在主要按鈕上使用「主色」，而不是隨機挑選顏色。
善用 Do's and Don'ts 設立護欄：大型語言模型對於「負面指令」的反應非常好。明確告訴 AI「不要亂加額外顏色」、「不要過度裝飾」，能有效約束 AI 的發散行徑。
搭配 CLI 工具驗證與輸出：官方提供了 @google/design.md CLI 工具，你可以使用 lint 指令來檢查檔案是否有無效的參照或不符合 WCAG 規範的對比度，也可以使用 export 將其直接轉換為 Tailwind 設定檔。

對不同角色的價值與實戰指南

對設計師來說：從「畫布」到「規則制定者」

DESIGN.md 並不會取代 Figma，Figma 依然是視覺探索的工具。但對於設計師而言，這是一個改變工作交付模式的契機：

作法：你不再只是把設計稿丟過牆，而是將腦中的「設計邏輯」轉譯成一份視覺合約。透過設定明確的元件狀態、網格系統與視覺規範，你確保了即使是 AI 生成的畫面，也完全符合你的品牌氣質。
價值：降低了溝通成本。你不需要再對著畫面抓漏、要求工程師把按鈕向左移 2px，因為基礎的設計品質已經被文件鎖定了。

💻 對開發者來說：實現極致的 Vibe Coding

當開發模式轉向由 AI 處理基礎設施與程式碼生成時，DESIGN.md 是拼圖的最後一塊。

作法：直接將這份 Markdown 檔案放入專案根目錄。當你使用 Claude Code 或 Cursor 等工具下達 Prompt 時，只需說：「請依專案中的 DESIGN.md 建立定價頁面」。
價值：徹底消滅了「功能寫得很快，但 UI 像拼裝車」的痛點。開發者不需要自己通靈字體大小或 padding，AI 會自動讀取並套用設計系統，讓你專注於架構與業務邏輯的開發。

🏢 對老闆 / 產品負責人來說：加速驗證與統一品牌體驗

對於需要快速推動產品上線的管理者來說，時間與一致性就是成本。

作法：在開發初期（如打造 MVP 或建立 C2M 平台前端），直接引入或生成一份符合商業調性的 DESIGN.md 。讓整個跨職能團隊（行銷、設計、開發）都以這份文件為視覺基準。
價值：極大地縮短了產品開發週期，減少反覆修改畫面的浪費。它能確保無論是 SaaS 後台、活動行銷頁還是電商結帳流程，都能維持高度的品牌專業感，而不需要每次都動用龐大的設計與前端資源從零刻畫。

MCP 宣布對大廠真實影響：慢火燉煮的基礎設施革命

noreply@blogger.com (Caesar Chi) — Wed, 6 May 2026 01:24:19 +0800

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)」的霸主地位： 這些公司知道，他們真正的價值不在於「按鈕設計得多好看」，而是裡面儲存了企業最核心的客戶、庫存、財務資料。透過 MCP 讓 AI 容易存取這些資料，能讓他們的系統在 AI 時代變得更不可替代（更黏）。

2. 他們捨棄原有的 UI 和系統流程了嗎？

完全沒有。但它們的定位發生了降維與分化：

UI 的角色轉變：從「唯一入口」變成「深度管理與專家後台」
日常、低難度任務（Chat-driven）： 交給 AI 透過 MCP 處理。例如：查庫存、更新聯絡人資訊、生成報表。使用者不需要再進入層層疊疊的選單。
複雜、高風險、需人工檢核任務（UI-driven）： 仍然依賴原生 UI。例如：SAP 中複雜的全球供應鏈節點配置、Shopify 的全站版型設計、或是 Salesforce 的底層權限控管。這些需要「全局觀」和「精確點擊」的操作，傳統 UI 依然是最高效的。
系統流程的進化：從「僵化的線性流程」變成「AI 的工具箱」
傳統的系統流程（如：建立訂單 $\rightarrow$ 扣庫存 $\rightarrow$ 發通知）是寫死的代碼。
導入 MCP 後，這些流程變成了 AI 可以隨時呼叫的「工具 (Tools)」。AI 可以根據使用者的模糊指令（例如：「處理退貨並給客戶發個安慰信」），自動編排這些流程。流程沒有被捨棄，只是被 AI 重新組合與觸發了。

以下為你解析這背後的重大意義，以及他們 UI 與流程角色的轉變：

資本市場對他們具備 MCP 能力的解讀，以及對長線股價的實質影響，主要體現在以下三個維度：

1. 消除「被邊緣化」的恐懼（守住既有估值）

市場心理： 投資人最怕的是這些傳統企業軟體在 Agentic AI（代理型 AI）時代變得封閉、難以串接，導致企業客戶將資料轉移到更靈活的新創平台。
股價影響： 具備 MCP 就像是向華爾街宣告：「我們依然是企業運作的心臟。」例如 SAP 透過 MCP Catalog 讓其龐大的資料庫（System of Record）能被 AI 代理直接讀取，這成功消除了市場對其「技術落後」的疑慮，穩固了支撐其股價的基本盤。如果他們固步自封拒絕開放標準，股價絕對會面臨外資機構降評的巨大壓力。

2. 引爆看不見的 API 流量紅利（推升實質營收）

市場心理： 人類員工一天頂多在 Salesforce 或 SAP 裡點擊幾百次，但 AI 代理不知疲倦，會在背景全天候、高頻率地進行交叉比對與流程觸發。
股價影響： MCP 讓 AI 存取資料變得極度容易，這將帶來暴增的系統呼叫（API Calls）與雲端運算需求。這些巨頭可以順勢推出針對 AI 代理的「專屬計費模式」，或要求客戶升級到更高階的運算訂閱方案。這種系統底層用量的變現，會實打實地反映在未來幾個季度的財報（如 ARR 年度經常性收入）上，這才是推升股價穩健上漲的真正燃料。

3. 搶佔「機器人經濟」的預設通道（提升本益比與想像空間）

市場心理： 以 Shopify 為例，他們非常激進地擁抱 MCP，甚至推出了互動式的「MCP UI」，讓商店的購物車、庫存都能無縫被 Claude 等 AI 讀取與操作。
股價影響： 這讓 Shopify 的敘事從「提供給人類逛的電商開店平台」，悄悄升級為「全球 AI 買手預設的交易引擎」。向資本市場證明自己能吃下未來的機器人訂單，能讓華爾街願意維持甚至給予他們更高的科技股本益比（PE Ratio），因為市場看到了全新的增長曲線。

總結

「宣布支援 MCP」這件事在股市中不會引發投資人或機構瘋狂追捧，因為它太技術導向、太偏向開發者端了。一般人其實看不懂，但對於看得懂技術趨勢的機構投資人來說，這是一粒強效的定心丸。

它對股價的影響是長線發酵的。

我相信很快就會在他們未來的財報會議（Earnings Call）上，頻繁聽到執行長們把「AI 代理透過 MCP 與我們系統的互動次數成長了 X 倍」作為業績亮點。當這些無形的互動正式轉化為財報上的數字時，資本市場的真實獎勵就會隨之而來。

SAP、Shopify 和 Salesforce 建立 MCP，是因為他們看清了未來的趨勢：與其強迫人類去學習他們複雜的系統，不如讓 AI 直接學會怎麼操作他們的系統。 這是一場搶奪「AI 時代底層資料庫」話語權的戰爭。

目前相信，這是企業軟體架構的一次大解構與重組。

告別 GUI，迎接 LUI：Meta Ads MCP 如何將廣告投放轉化為「自然語言」對話

noreply@blogger.com (Caesar Chi) — Tue, 5 May 2026 02:14:39 +0800

過去，你需要親自登入 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. 深度數據洞察與即時診斷 (Read & Analyze)

你不再需要人工撈取與比對數據。你可以直接在對話框中問 AI：

「幫我分析這週 Cymkube 廣告的成效，特別是強調『捕捉精彩瞬間』與『玩家自選造型』的素材，哪一個點擊率與轉換率比較好？」
「為什麼昨天的獲客成本 (CPA) 突然飆高？幫我檢查是不是受眾訊號 (Signal health) 出了問題。」AI 會直接讀取你帳戶內的真實數據，交叉比對後給你具體的洞察報告。

2. 廣告創建與動態管理 (Write & Execute)

你可以用自然語言直接操控廣告架構（需經過你的授權）。

你可以直接對 AI 說：「為即將推出的《99 Nights Defense》建立一組新的 A/B 測試廣告。受眾鎖定塔防與生存遊戲玩家，一組文案主打『資源管理』，另一組主打『史萊姆群體的自動化防禦』，每天預算 50 美金，跑三天。」

AI 會直接在後台幫你建置好 Campaign、Ad Sets 和 Ads。

3. 目錄與產品資料修復 (Catalog & E-commerce Operations)

對於 S2M 或 C2M 的商業模式，產品資料夾 (Data Feed) 的健康度至關重要。如果 3D 客製化公仔的型錄出現錯誤或部分商品未顯示，AI 可以直接幫你排解 Data feed 的技術問題，確保前端展示與後端資料的一致性。

4. 系統級的自動化閉環 (Agentic Workflows)

這是最令人興奮的程度。你可以將這個 Meta Ads Connector 整合進你更大的 AI 框架中。想像一下：前端行銷 Agent 負責在 Meta 上測試受眾與獲取訂單；後端如「老師傅」這樣的製造 Agent 則根據接收到的訂單進行 3D 列印的工程 BOM 生成與產能規劃。如果產能滿載，後端可以通知前端 Agent 自動調降廣告預算，達成從數位生成到實體製造的完美自動化閉環。

簡單來說

總結來說，它不是「額外」去整合 Instagram，而是只要你打通了這組 Meta Ads Connector，Instagram 廣告的創建、管理、除錯與數據分析，就已經預設包含在它的火力範圍之內了。

Ref:
https://www.facebook.com/business/help/1456422242197840

Hermes Agent「Curator」功能全解析：AI 代理的技能生命週期與自我維護

noreply@blogger.com (Caesar Chi) — Sun, 3 May 2026 02:48:27 +0800

深度解析 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 天未使用的技能，將被移出運作目錄並歸檔至 .archive/。最重要的是，Curator 從不自動永久刪除技能，所有動作皆可復原。

2. LLM 智能審查與技能整合

當系統閒置超過 2 小時，且距離上次執行超過 7 天時，Curator 會生成一個獨立的代理分支（Fork）。這個輔助模型會閱讀現有的技能庫，決定哪些技能需要保留、修補（Patch），或是將功能重疊的技能進行合併（Consolidate）。

3. 嚴格的安全與防護網

來源隔離：Curator 絕對不會觸碰官方內建（Bundled）或從市集（Hub）下載的技能，只會管理「代理自行撰寫」的技能。
自動快照與回滾：在進行任何修改前，Curator 會自動將技能庫打包成 .tar.gz 快照。若審查結果不符合預期，可隨時一鍵回滾（Rollback）。
釘選保護（Pinning）：支援硬性保護機制，一旦將技能 Pin 起來，Curator 與代理自身都無法再去修改該技能。

項目的使用方式

Curator 在最新版本中預設為啟用。你可以透過修改 config.yaml 或使用 CLI 指令來進行管理：

1. 基礎配置 (config.yaml)： 為了節省 API 費用，強烈建議將背景審查任務交給較便宜的模型（如 Gemini 1.5 Flash 或 Claude 3.5 Haiku）：

curator:
  enabled: true
  interval_hours: 168 # 預設 7 天執行一次
  stale_after_days: 30
  archive_after_days: 90

auxiliary:
  curator:
    provider: openrouter
    model: google/gemini-3-flash-preview # 指定用於 Curator 審查的模型

2. 常用 CLI 指令：

hermes curator status：查看上次執行狀態，以及最少使用的 5 個技能列表（預測下次可能被淘汰的對象）。
hermes curator run --dry-run：強烈建議首次執行前使用。這會產出審查報告（包含合併或封存建議），但不會實際修改任何檔案。
hermes curator pin <skill_name>：釘選你手動撰寫或認為極度關鍵的核心工作流技能，防止被修改。
hermes curator rollback：若自動整理搞砸了，一鍵還原到整理前的狀態。
hermes curator restore <skill_name>：將被封存的技能重新移回啟動狀態。

社群網路上的聲音與目前回饋

在 Reddit（如 r/LocalLLaMA、r/AIGuild）與 X (Twitter) 上，Curator 的推出獲得了高度評價：

「真正的長期代理」：社群普遍認為這是 Hermes Agent 的一次巨大升級。開發者表示，終於有一個框架認真對待「記憶的維護與遺忘」，而非只是無腦堆疊向量資料庫。
知識庫的完美編輯：許多進階使用者將 Hermes 與 Obsidian 等知識庫結合。他們不把 Hermes 當成單純的對話機器人，而是作為一個「Wiki 編輯與策展人（Curator）」，利用這個機制定期清理、編譯並維護他們個人的本地知識庫。
成本與效能的雙贏：因為有效清除了死氣沉沉的冗餘技能，使用者反饋提示詞變得極度乾淨，不僅省下了可觀的 Token 費用，也發現代理在調用工具時的準確率有顯著提升。

可以改進什麼事情？（未來展望）

儘管 Curator 解決了許多痛點，但根據 GitHub 的討論與實務應用，該機制仍有可改進的空間：

「罕見但關鍵」技能的誤判風險：目前區分「過時」與「不常用」的啟發式規則主要是基於「時間（30/90天）」。一些極少使用但具有關鍵災難復原價值的自動化腳本，如果使用者忘記手動 pin，仍會被放入封存庫。未來可能需要引入基於「影響力」或「標籤」的評分權重機制。
負面環境依賴的重新驗證（Revalidation）：如果代理記錄下「命令 X 在這個環境中不可用」的技能，但隨後開發者修復了環境，目前 Curator 缺乏主動重新驗證（TTL）這類負面聲明的機制。未來若能加入定期自動測試這類假設的功能，將能徹底解決代理的「習得性無助」。
更精細的外部目錄同步（Merge Reconciliation）：目前 Curator 對於從外部（External Directories）掛載的技能是唯讀的。對於想要建立跨裝置、跨專案共享技能庫的開發者來說，未來若能處理外部更新與本地代理修改之間的差異合併（Diff/Merge），將能大幅提升多代理協作的潛力。

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

noreply@blogger.com (Caesar Chi) — Sat, 25 Apr 2026 00:16:31 +0800

這篇關於 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 amount of AGI pilled）」。如果模型無所不能，產品設計反而最簡單（只要一個對話框）。但現實是，PM 必須在「當前模型的邊界」內榨出最大價值，不能過於超前而忽略當下痛點，也不能過於保守。

深度解讀：捕捉真實的瞬間，勝過盲求高精細度

這是一個極具啟發性的產品哲學。很多人在開發 AI 應用時，容易陷入「過度追求未來完美」的迷思，例如盲目追求極致的高擬真度或零誤差，卻忽視了龐大的運算等待時間。事實上，商業的價值往往發生在當下。與其等待遙不可及的完美模型，不如提供高速、低門檻、立即可用的轉換價值。讓使用者不需要漫長等待，就能輕易捕捉並留住每個重要時刻，這種務實的產品定位，往往比空談 AGI 更能擊中市場真實需求。

資源分配的冷酷現實：戰略定力與生態抉擇

面對開源社群對封堵 OpenClaw 的不滿，Cat Wu 的回應是從容量管理出發，表示必須做出艱難決定以「優先保障第一方產品和 API」。即便這引發了「先抄襲後封殺」的爭議，但 Anthropic 的首要任務是服務公司整體的目標。

深度解讀：管理就是做取捨（Trade-offs）

這背後體現了強烈的戰略有效性原則。當資源（算力、Token）有限時，企業必須確保所有的運作都在鞏固其「核心基礎層（Base Layer）」。開放生態固然好聽，但如果第三方工具的使用模式對系統基礎設施帶來不成比例的壓力，且無法轉化為實質的 B2B 商業規模與核心營收，那麼砍掉這些消耗就是必然的決策。就如同在供應鏈管理中，為了確保平台的可擴展性與企業級客戶的服務品質，有時必須果斷拒絕那些無法為核心底層邏輯帶來長遠價值的客製化專案。

使命的真正意義：讓組織為了全局而犧牲局部

Anthropic 之所以能贏，在於擁有統一的使命，且這個使命意味著團隊願意「犧牲自己的 KR（關鍵結果），來服務公司整體的目標與 KR」。

深度解讀：回歸目標管理的本質

這完美契合了現代管理學的精髓。當組織龐大、變動極快時，各自為政的 KPI 會撕裂公司。真正的團隊效能，建立在所有子系統（無論是前端應用還是後端供應）都無條件服從於同一套核心戰略。當大家都認清什麼是「最基礎的底層設施」，就能毫無阻力地進行跨部門協作。

後記

從資訊處理和邏輯推演的角度來看，我們可以從技術管理和商業效能的底層邏輯，來重新解構這些看似矛盾的論述。

「做減法」的戰略定力

訪談中 PM 的價值歸結為抽象的「Product Taste（產品品味）」，這聽起來確實像是一個職場護城河。但如果我們把這個落地到真實的商業決策中，它其實有著極其殘酷且具體的衡量標準。

Product Taste 的本質，是在技術可能性與用戶真實痛點之間劃分

這其實很模糊，也很難定義

在技術主導的團隊中，工程師很容易陷入對「真實」、「極度完美」或「技術炫技」的追求。

此時，Product Taste 就是一種強烈的約束力——例如，果斷放棄對「極致逼真度」的執念，將核心目標鎖定在「無須等待、捕捉當下瞬間」的高速轉換上。

這種為了讓使用者都能低門檻、無縫使用，而刻意在技術複雜度上做減法的決斷力，就是一種極高的品味。這也是 Less is More 哲學在 UI/UX 與產品邏輯上的終極體現。

沒有這種品味，工程師端到端產出的往往是一個技術上完美，但商業上的「自嗨」玩具。

工程師「端到端」與 PM 價值的真正差異：底層與表層

如果在日常的高效開發週期中（比如以天為單位、甚至限制在 5 小時內的高效衝刺），工程師真的可以從回饋到週末發布功能一把抓，PM 還需要存在嗎？

這就需要用更宏觀的組織效能視角來看待。在複雜的商業矩陣中，必須有人負責構建核心的戰略底層（Base Layer），而具體的功能只是這個底層技術在零售/應用端的顯性表達。

優秀的工程師可以完美交付很實際的介面功能，但誰來決定這些功能是否偏離了底層的商業核心？

誰來抵擋那些看似誘人、卻對核心平台邏輯毫無增益的外部客製化誘惑（有可能來自大型企業客戶的需求）？

當寫程式變得越來越廉價，PM 的工作實質已經從「專案進度監工」變成了「商業邏輯守門人」。

承認「過渡」，本身就是最大的現實主義

如果最終的 UI 就是一個文字框，PM 的存在本質上就是倒數計時的。

用彼得·杜拉克（Peter Drucker）的理念來審視：「行銷的目的，是讓推銷變得多餘。」順著這個邏輯，AI 時代優秀產品的終極目的，或許就是讓傳統意義上的「產品介面」與「操作流程」變得多餘。

在通往「超級 AGI + 單一文字框」的漫長道路上，模型目前依然會犯錯、會產生幻覺、缺乏常識與隱性的人際理解。這段「過渡期」可能比許多技術狂熱分子想像的要長得多。

在這個時期內，PM 的價值就是充當人類常識與 AI 缺陷之間的「過濾器」。

一旦模型真的強到了只需要一個輸入框就能完美解決所有業務流轉的程度，不僅是 PM，絕大多數的軟體工程師、互動設計師、甚至部分管理者的傳統職能，可能真的都會失去意義。

我想，未來的 PM 也許不再是一個獨立的「工種」，而會演變成一種必備的商業素養——存在於能夠理解底層架構、懂得克制功能項目、並能將商業戰略無縫轉化為系統指令的任何角色（無論他原本的頭銜是創辦人、技術總監還是業務主管）之中。

Ref: https://www.youtube.com/watch?v=PplmzlgE0kg

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

noreply@blogger.com (Caesar Chi) — Thu, 23 Apr 2026 01:09:23 +0800

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

noreply@blogger.com (Caesar Chi) — Sun, 19 Apr 2026 01:09:00 +0800

這篇文是由 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。這是一個完全不同的物種，擁有不同的能力。大膽去嘗試並享受其中的樂趣吧！你會發現自己產出的設計將遠勝於傳統的工作方式。
關鍵時刻，別怕手工慢下來 (手工打磨藝術部分)

對於全新的圖示、核心插畫、產品命名或是品牌形象，這類工作別指望 AI 模型能給你完美的答案。這不是 Claude 不夠聰明，而是這些環節本質上考驗的是你個人的品味與判斷力。他將這部分稱之為「代理式設計 (Agentic Designing) 的藝術部分」。

💬 相關熱門留言與社群討論翻譯：

這篇推文在科技與設計圈引起了極大的共鳴，許多業內人士與投資人（如李惠子、Leyna等）也對此發表了深刻的評論：

對 Figma 等傳統工具的顛覆性威脅：

「Claude Design 的威脅半徑是精準且有限的。但在『軟體設計』的領域裡，它絕對是真正的顛覆者。這並不是因為它設計出來的東西更好看，而是因為它將『設計 → 程式碼』的鏈路徹底打通，直接攻擊了 Figma 這類純粹用來『生產設計稿』工具存在的合理性。現在非設計師也能直接拿到『可運作的原型』，這是一個巨大的結構性變化。」
關於給 AI 的反饋必須具體：

留言中也補充了官方教學的一個重點：「看著不對勁」是對 AI 最差的反饋；而「將表單欄位的間距改成 8px」才是 AI 代理 (Agent) 最愛聽的明確指令。Claude 非常擅長處理具象且具體的要求，但不擅長揣摩人類抽象的審美情緒。
設計領域的 ChatGPT 時刻：

「Claude Design 迎來了設計領域的 Claude Code 時刻，AI 真正把從構思到開發的摩擦力降到了最低。」

(註：由於推文下方的留言會隨時間不斷增加，以上為該推文最具代表性及被廣泛引用的核心留言與社群迴響。)

Claude Design 分析，Claude 在想什麼？

noreply@blogger.com (Caesar Chi) — Sat, 18 Apr 2026 14:03:15 +0800

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 時，這種能夠快速將文字意圖轉換為精準品牌視覺的能力，將極大化行銷與營運的節奏。
.
>>探討： Anthropic 的真正野心
.
從文章中 Datadog 和 Brilliant 等企業的證言可以看出，Anthropic 的目標早就不是單純的「對話式 AI」。用 Opus 4.7 來處理精準的中文排版對齊只是一個結果，其底層是透過強大的視覺推理能力，把產品經理的白板、設計師的畫布、開發者的 Terminal 以及行銷的素材庫，全部統整進同一個生態系。
.
正如我所說，目前觀點依舊，設計本身就是邏輯。Claude 正在向產業證明，只要底層的邏輯架構夠清晰，AI 就能包辦從像素到程式碼的所有精確執行。
.
最近這種很長的文章，大家都覺得很容易得到按讚，我也來試試看，

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

noreply@blogger.com (Caesar Chi) — Fri, 27 Mar 2026 18:44:00 +0800

今天不講 AI ，來聊聊自己。

這幾年一路走下來，我越來越明白一件事情。

如果今天只是自己開一個小公司，或者只是帶一個小團隊，很多事情其實都還可以靠能力、靠意志力、靠自己撐過去。很多問題，就算方向沒有那麼完整，或者判斷沒有那麼成熟，可能都還不至於立刻出大問題。

因為小團隊有時候可以靠彈性、靠拚勁、靠創辦人的直覺，先把事情往前推。

可是當今天的位置，不再只是做一個小團隊的帶領者，而是要去經營一個企業、經營一個組織、經營一個部門，甚至是要為整個團隊的方向、資源配置、成長結果負責的時候，思考方式就完全不一樣了。

這時候真正重要的，往往已經不是「我會做什麼」，而是「我到底應該怎麼看這件事情」。

以前的我，很多時候還是很自然地會用技術的角度來思考。這也很正常，因為那本來就是我熟悉的語言，也是我長期最有信心的地方。遇到問題，我很習慣先拆解問題、理解邏輯、找方法、找工具、找系統性的解法。對我來說，技術不只是能力，它某種程度上也是我理解世界、處理事情的一種方式。

但走到現在，我慢慢發現，真正困難的從來不是技術本身。

AI 很厲害，工具很多，流程可以設計，系統可以導入，服務也可以包裝，可是這些東西，終究都只是工具。工具很重要，但工具不等於方向。技術很重要，但技術不等於市場。服務很重要，但服務也不等於真正的價值成立。

真正重要的事

你到底怎麼看市場？
你到底怎麼評估市場？
你看到的市場回饋到底是不是對的？
你的驗證到底是不是真的成立？
如果方向是對的，你要怎麼把它放大？
如果方向是錯的，你要怎麼承認、怎麼修正、怎麼轉向？

我越來越覺得，這些事情，才是真正重要的事情。

因為如果你對市場的理解是對的，理論上，市場會用很直接的方式回饋你。它不一定一開始就非常明顯，但它會慢慢用結果告訴你，你是不是走在一個對的方向上。那個結果不是掌聲，也不是稱讚，而是更實際的東西。是有人願不願意付錢，是客戶願不願意持續合作，是需求有沒有持續浮現，是你的產品或服務有沒有真正被需要。

如果方向對了，市場其實會講話，而且講得很直接。
它會用營收講話。
會用訂單講話。
會用續約講話。
會用採用率講話。
會用成長講話。

可是反過來說，如果你對市場的定義是模糊的，你對需求的理解是不準的，你只是覺得這東西很厲害、很有潛力、很值得做，那最後市場給你的回饋，很多時候就會停留在另一個層次。

大家可能會跟你說，這個想法很好。
這個方向很棒。
這個東西很厲害。
很有未來。
很有機會。

可是他不買。

這件事情其實是很殘酷的。

因為很多時候，最容易讓人誤判的，不是市場直接打臉你，而是市場給你一種模糊的善意。這種善意最危險。因為你會以為自己做的是對的，會以為只是還差一點，會以為大家都認同，只是時機還沒到。可是實際上，那些表面的認同，未必能夠支撐一個團隊走下去，更不可能支撐一個組織持續成長。

這也是我這一路上越來越深的體會。

真正對你有幫助的人，不一定是那些給你正面評價的人。
真正有價值的回饋，也不一定是那些讓你覺得自己做得不錯的聲音。

反而很多時候，最有價值的，是那些不買單的人，是那些沒有反應的人，是那些直接指出你問題的人，是那些願意很實際地告訴你「這個東西現在還不成立」的人。

因為那些聲音雖然不舒服，但它們比較接近真相。

我覺得自己這幾年一個很大的轉變，就是慢慢開始不再那麼依賴「被肯定」這件事情，而是更願意去看「真實發生了什麼」。

這很難，因為人本來就會希望自己的想法被認同。尤其是當你投入很多時間、很多心力、很多信念在一件事情上時，你一定會希望這件事情被理解、被看見、被覺得有價值。這是人之常情。

可是經營這件事情，有時候不能太依賴這種感覺。

因為如果一個人太依賴自己的自我感覺良好，或者太依賴外界表面的好評，那他最後就很容易帶著團隊走進一種看起來很努力、很充實、很有產出，但實際上離市場越來越遠的狀態。

我現在回頭看，會覺得很多組織真正的問題，不一定是沒有人做事，也不一定是大家不用心，而是大家都在做事情，卻沒有真的被市場校正。

事情一直在做。
專案一直在跑。
報告一直在產出。
會議一直在開。
看起來每個人都很忙。

可是最後沒有形成真正的營收成長，沒有形成真正的市場位置，沒有形成真正可被放大的模式。

那這種忙，某種程度上，其實就是一種忙碌的偷懶。

因為真正難的，不是把自己塞滿工作，而是有沒有勇氣去面對：我們現在做的這些事情，到底是不是對的？到底有沒有價值？到底跟市場的真實需求有沒有連起來？

我覺得，這大概也是管理跟執行最大的差別之一。

執行是把事情做完，但管理不是。

什麼是管理

管理比較像是，你要先判斷，什麼事情值得做，什麼事情不值得做；什麼事情要現在做，什麼事情要延後做；什麼事情只是看起來重要，什麼事情才是真正重要。

這也是為什麼我越來越覺得，好的管理者，不能只是順著自己擅長的那一塊往前衝。

因為擅長，常常不等於正確。

你擅長技術，不代表市場現在最需要的是技術。
你擅長產品，不代表客戶現在最在意的是產品。
你擅長優化流程，不代表當下最關鍵的是流程優化。
你擅長解問題，不代表你現在面對的是對的問題。

所以一個人如果真的要從專業工作者，走向一個成熟的管理者或專業經理人，他一定要學會一件事，就是時時提醒自己，不要只是用自己熟悉的方式看事情，而是要更多地去傾聽市場、傾聽不同的人、傾聽不同角色的回饋，也要持續跟不同組織、不同經驗層級的人學習。

我自己其實一直很相信一件事情。

就是跟著大的市場走，跟著真正做出結果的人學習，跟著那些有成功經驗、也有失敗經驗的人交流，這些事情非常重要。

因為你會慢慢發現，很多真正有價值的東西，不是從理論裡學到的，也不是從表面的方法論裡學到的，而是從那些做過事的人、跌過跤的人、真正扛過結果的人身上，一點一滴淬鍊出來的。

成功可以學，但只學成功其實不夠。
真正有價值的，是理解那些成功的人，曾經怎麼失敗，怎麼判斷錯，怎麼修正，怎麼在市場打擊下調整自己，怎麼在現實裡重新建立方法。

因為那裡面藏的，才是真正的判斷力。

我現在回頭看，也越來越能理解，很多時候自己不會一開始就有那麼清楚的輪廓。

這件事其實我以前可能沒有那麼能接受。
以前總會期待，自己應該要更篤定、更明確、更精準，彷彿一個人只要夠厲害，就應該在一開始就看對方向、做對選擇、帶對團隊。

但後來我發現，不是這樣。

成功是怎麼來的

更多時候，方向其實不是一開始就看見的。
方向常常是從迷惘裡走出來的。
是從挫折裡修出來的。
是從失敗裡撞出來的。
是從一次又一次現實的打擊裡，慢慢變得比較清楚的。

所以迷惘不是失敗。
焦慮也不是失敗。
害怕更不是失敗。

它們很多時候只是代表，你真的站在一個有風險、有不確定性、有責任的位置上。你開始碰到真實的重量，所以你會猶豫、會焦慮、會懷疑、會委屈，甚至會不甘心。

但某種程度上，我覺得這些感受也不完全是壞事。

因為正是這些感受，讓你知道你不是在做一件輕飄飄的事情。你是真的在面對一條想走的路，真的在面對一個想去的方向，真的在試著成為某一種你想成為的人。

所以即使委屈，即使掙扎，即使常常覺得自己明明想到一個很不錯的東西，但放到不同角色、不同場景裡，又被現實打掉、被市場修正、被更大的框架重新檢驗，那也還是得繼續走。

因為你知道，這條路就是自己想走的路。

不是因為它容易，也不是因為它一定會贏。
而是因為你知道，自己真正想成為的，不是一個只停留在擅長領域裡的人，而是一個有能力去理解更大的市場、更大的組織、更大的世界，並且敢去挑戰那些看起來不太可能的事情的人。

我想，這裡面其實也有一種不甘心。

不甘心只是待在原本熟悉的位置。
不甘心只是做自己會做的事情。
不甘心只是讓自己的能力停留在單一專業上。
不甘心只是當一個把事做好的人。

而是想看看，自己能不能走到更大的地方，能不能帶出真正有結果的團隊，能不能讓一個方向不只是想法，而是真的變成市場上的成果，能不能在這個現實的世界裡，把自己所相信的價值，真正做出來。

這條路當然會怕。

我不覺得走這條路的人會不怕。
如果一個人真的在意結果、真的扛責任、真的想把事情做成，他一定會怕。一定會焦慮，一定會懷疑，一定會不安。

因為你不只是拿自己的時間在賭，你有時候還拿團隊的時間、公司的資源、別人的信任、自己的位置與未來一起在賭。

這種重量是真的。

深刻且沈重的重量

但我現在會覺得，可能不是沒有焦慮，而是即使焦慮，也還是能夠繼續判斷；即使害怕，也還是能夠繼續往前；即使被市場打臉，也還是能夠從裡面提煉出下一步該怎麼修正。

以前我也會覺得，帶團隊最重要的是讓大家開心。

現在我不會說這是錯的，因為我還是認為一開始的開心是重要的。團隊要有信任、要有凝聚、要有願意一起往前走的氛圍，這些都很重要。沒有那個基礎，很多事情很難真的推得動。

但現在我也越來越清楚，開心不是最終目的。

開心是為了凝結。
凝結完之後，真正重要的，是磨練。

因為一個團隊最終會不會走下去，不是只看大家相處得好不好，也不是只看氣氛夠不夠好，而是看這個團隊有沒有實際的成長，有沒有營運結果，有沒有創造價值，有沒有在市場裡證明自己的位置。

如果沒有，最後現實還是會找上門來。

營收不好，組織就會被檢討。
成長起不來，資源就會被抽走。
結果做不出來，焦點就不會放在你身上。
當組織的資本與注意力開始往更有成果的地方移動時，你再好的氛圍，也很難撐住整個團隊。

這不是悲觀，這只是現實。

所以我現在會覺得，一個好的管理者，不是讓大家一直很舒服，也不是只會一直壓結果，而是知道什麼時候要凝聚、什麼時候要拉高要求、什麼時候要停下來修正、什麼時候要讓團隊真正面對市場與結果。

因為最後團隊能不能持續，不是靠感覺，而是靠成立。

說到底，一個專業的經理人，不是只會做簡報、會開會、會管理流程、會分配工作而已。

真正專業的經理人，應該是要能夠承擔方向判斷的責任，能夠面對市場的現實，能夠接受被修正，能夠分辨哪些事情只是看起來有在前進，哪些事情才是真的在前進，能夠在團隊需要安全感的時候給安全感，也能夠在團隊需要被拉高標準的時候，不逃避那個壓力。

我覺得自己現在，某種程度上，就是正在學這件事。

真正的學習

不是我已經做到了，而是我開始知道，真正該學的是這個。

以前我可能比較在意，自己有沒有想到好的方法、有沒有做出厲害的東西、有沒有讓事情被推進。
現在我更在意的是，這些事情到底有沒有對到市場、到底有沒有帶出結果、到底有沒有讓整個組織更接近一個真正成立的位置。

這裡面最大的差別就在於，過去的自己，比較像是在證明自己做得到。
現在的自己，更像是在逼自己面對：就算做得到，那又怎樣？這件事情真的值得做嗎？真的有人需要嗎？真的能讓組織往前嗎？

我想，這可能就是一個人從技術者、執行者，開始走向經營者、管理者、專業經理人的真正轉變。

不是能力變多了而已。
而是判斷的重心變了。

從證明自己很強，
變成確認方向正不正確。

從把事情做出來，
變成先問這件事情到底該不該做。

從想辦法讓大家滿意，
變成想辦法讓組織真正站得住。

從依賴掌聲，
變成願意接受市場的沉默與批評。

這條路不輕鬆

我覺得，這條路不輕鬆，而且某種程度上，也比單純做技術更孤獨。

因為你會越來越知道，很多事情不能只靠熱情，不能只靠努力，不能只靠自己喜歡，不能只靠團隊願意。最後還是得回到市場、回到結果、回到成長、回到可持續。

但也正因為這樣，我反而更清楚，自己為什麼要繼續走。

因為我想學的，已經不只是怎麼把事情做好。
而是怎麼看懂真正重要的事情，怎麼帶著團隊做對的事，怎麼讓一個方向不只是理念，而是真的能夠在現實裡成立。

如果說以前的我，比較像是一個擅長解題的人，
那現在的我，想學著成為一個更成熟的管理者與經理人——一個不只是會解題，而是願意先確認題目對不對的人。

而我知道，這才是真正困難的地方。
但也正因為困難，它才值得我繼續走下去。

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

noreply@blogger.com (Caesar Chi) — Mon, 23 Mar 2026 01:02:00 +0800

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 倍。』 . 對於許多老闆來說，養龍蝦到底在養什麼？你到底應不應該進場？聽聽這集 1.5 小時的純乾貨對談與避坑指南，幫你評估團隊現在是否真的準備好「養龍蝦」了。 .

連結

https://youtu.be/yYfUlyxaopU?si=_SJ4EcrMuXXe-iqp

相信大家一定遇到許多困難，以及自己有許多情境和場景，歡迎留言私訊，互相交換意見。

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

noreply@blogger.com (Caesar Chi) — Mon, 16 Mar 2026 23:38:00 +0800

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 個備選科目讓 AI 以 JSON 格式回答。若信心水準（Confidence）高則直接註冊，低則留給我人工確認。
優點： 大部分靠關鍵字，速度快且省 API 費用；複雜的才交給 AI。

Phase 3：重複檢查與註冊

在註冊前，會根據日期、金額、摘要前 40 個字進行重複比對，防止二重複核。

Phase 4：數據安全性（非常重要）

處理 60 家客戶時，數據隔離是底線。

各公司處理完全按 company_id 獨立運作。
日誌文件（Log）也是獨立的，絕對不會發生 A 公司的資料混入 B 公司的情況。

處理時間： 以前用瀏覽器自動化腳本要跑 5 小時，現在直接對接 API，全數處理完只需 30~50 分鐘（每家公司僅需 20~40 秒）。每天早上起床，前一天的帳就已經記完了。

三、自動攔截「不該記帳的項目」

自動化最怕「亂記」。我設定了 7 種排除規則，會自動跳過並留給人工審核：

內容不明的扣款（只有數字、無店名）。
借款還本（公庫、融資、貸款）。
社會保險與稅金。
薪資發放（避免隱私外洩）。
投資理財（證券戶）。
ATM 提款（改為轉帳處理）。
公共事業費（需特殊核對）。

心得： 專業知識告訴我們「哪裡該自動、哪裡該人工」，這才是安全的關鍵。

四、其他高效率應用場景

大量資料轉換（130 件發票 → 15 分鐘）： 客戶給了 130 份 PDF 發票，要求匯入 freee。我叫 Claude Code 寫個 Python 腳本，15 分鐘內精確提取金額、稅金、廠商名稱並轉成 Excel 格式。
會計軟體遷移： 從 MoneyForward 轉到 freee，通常要手動對應科目，極其耗時。現在只要讓 Claude Code 寫轉換腳本，幾秒鐘就搞定。
MCP 連結實現「零謄寫」： 透過 MCP 連結 Gmail、Notion 等，可以實現「自動撰寫催款信下稿」、「從會議記錄自動生成下回議程」。稅務士 80% 的工作是在搬運數據，現在這部分幾乎歸零。

五、管理 AI 的「說明書」：CLAUDE.md

這是我對 AI 的長期工作手冊。裡面寫明了：

分類規則（如：餐飲費 1 萬日圓以下記「會議費」，以上記「交際費」）。
安全政策（絕對禁止輸出 API Key 或個人編號）。
判斷邊界（什麼情況下可以自動處理，什麼情況必須詢問我）。這就像給員工的 SOP，但 AI 永遠不會忘記，也不會抱怨。

六、為什麼「後勤專業人士」更應該用 Claude Code？

很多人覺得「我又不是工程師，這太難了」。 事實正好相反：正因為你不是工程師，你才該用。

因為你擁有「業務知識（Domain Knowledge）」。你知道分錄怎麼分、稅務怎麼報，這些是 AI 缺少的「現場知識」。只要你有這些知識，程式碼的部分 Claude Code 會幫你寫好。 這次系統中的程式碼，幾乎 100% 都是 Claude Code 寫的，我只負責下達邏輯指令。

工程師用 AI 是做出「技術很厲害」的東西；專業人士用 AI 是做出「實務上正確」的東西。

總結：我不請員工的原因

不請員工的優點太大了：

人工成本為 0： 可以調降顧問費，直接回饋客戶。
資訊風險大減： 只有我一個人，資安管理極度單一。
決策極速： 想到新工具當天就能導入。

半年前我覺得 40 家客戶是極限，現在處理 60 家卻覺得遊刃有餘。真正的自由，是透過 AI 槓桿，將枯燥的重複勞動轉化為創造價值的時間。

如果你也想優化你的後勤流程，歡迎私訊我！讓我們一起打造高效的 AI 協作機制。

AI 是放大器，不是魔法：你的基數是 1 還是 10？

noreply@blogger.com (Caesar Chi) — Sun, 15 Mar 2026 18:06:00 +0800

點出了一個在 AI 浪潮中很多人忽略的現實：AI 本質上是一個「放大器」（Multiplier），而不是「無中生有」的魔法。 它的價值取決於使用者本身的「基數」以及他們願意探索的「廣度」。

我們可以用數學的角度來拆解你這個深刻的觀察：

1. 永遠停留在起點的 $1^x = 1$

如果一個人的思維被限縮，或者抗拒改變，他的能力基數就是 $1$。

封閉的心態： 把 AI 當作單純的 Google 搜尋，只問最表面的問題，得到淺薄的答案後就認為「AI 也不過如此」。
缺乏領域知識： 如果連自己要解決的問題是什麼都不知道，即使有了最強大的模型，也無法給出有效的提示詞（Prompt）。不管 AI 的能力這個指數 $x$ 有多大，最後的產出依然是 $1$。

2. 迎來爆發性成長的 $10^x$

相反地，如果一個人具備深厚的實力與開放的心胸，他的基數就是 $10$。

領域知識的加乘： 當你在規劃複雜的系統架構、優化供應鏈管理的商業策略，或是設計客製化零售的自動化流程時，你本身的專業知識就是那個「10」。AI 在這個基礎上幫你快速生成程式碼、梳理邏輯或是提供架構靈感，這時 AI 就是那個指數 $x$。
跨領域的觸角： 打開心胸意味著你願意將 AI 應用在不同的節點上（例如從前後端開發延伸到 AI Agent 框架的整合），這會讓你的能力範圍產生 $10^x$ 的指數型躍升。

甚至還有 $0$ 或負數的風險

我們甚至可以把你的比喻再延伸一點：如果一個人不僅基數低，還盲目相信 AI 生成的所有內容（沒有能力去驗證程式碼或商業邏輯的正確性），那他的基數可能是 $0$ 甚至是小於 $1$ 的分數。在指數運算下，分數的指數成長反而會讓他越來越趨近於 $0$（例如 $0.5^2 = 0.25$），這在實際專案中就表現為技術債或是嚴重的架構錯誤。

總結來說： AI 賦能的極限，其實就是人類想像力與專業能力的極限。工具再強，駕駛員的眼界依然決定了這艘太空船能飛多遠。

All or Nothing: The Real Impact of AI

noreply@blogger.com (Caesar Chi) — Fri, 27 Feb 2026 22:06:00 +0800

This is a short conclusion as of February 2026.

In the AI era, senior people (those with ability and manpower) do not need to worry. Because human ability and experience are combined skills that AI still cannot replace.

I still say the same thing:

“Engineers will definitely still have work. Frontend will become even more important. People who build applications will never be unemployed. The only question is who you build for. Demand will only increase.”

Now I will share three key points I see.

Changes in Company Structure

I believe there are several direct impacts and results.

All or Nothing

All

If a company does not have people with this new ability, it will go backward. Such companies will first declare that “agents are useless.” The company structure and staff will still exist. People will still receive salary. Everything looks normal.

But you will realize: The company making money has nothing to do with you.

Nothing

Entire departments may be removed.

Simply put: Now one person can function as a whole team.

There may no longer be a marketing department. Instead, one marketing leader manages many marketing agents.

One person can work like ten people. Ten people can equal what used to be a 100-person company. Revenue can reach hundreds of millions. Everyone is happy.

The “Efficiency First” Myth

“Efficiency” alone becomes a fake topic.

Increasing speed is not enough. What matters is results.

Before, people analyzed data, ran ads, handled digital tasks. Now AI agents can do all of that — and do it well.

If a human’s only role is to “take the blame,” then that is all they will end up doing.

Willing to Believe

You must believe first to move forward. You must believe before you can see.

Unless you have already seen it.

When belief is strong enough, making money and expanding becomes natural.

In the past, expansion meant growing the team. Now expansion means who can efficiently use tokens and burn tokens.

Antifragile Thinking

Being antifragile means acting now causes less loss than doing nothing.

Back to the main point:

“Whoever can continuously burn enough tokens efficiently will win.”

While you hesitate over spending a few hundred or a few thousand dollars to register something, many companies are already quietly burning tokens.

They are training their digital consultants, digital assets, and digital systems. They are feeding agents as digital nutrients to every key person — unless there is an extremely serious data leak risk.

Doing something loses less than doing nothing.

This game must be top-down.

You can add many agents, add AI, build teams — but execution speed always gets stuck at people.

So AI adoption must be top-down.

Maybe 1% can succeed bottom-up, but that is too slow.

As people say: The ones responsible decide the speed of execution.

Leaders must personally do it with the team.

“Digital Work” Becomes Result-Based

All digital work — writing, media, design, research — will be judged by results.

More directly: Vertical focus is better.

Focus deeply. Focus enough to build your moat.

Like what we are doing with cymkube.com — vertical, real, manufacturing. AI cannot replace this quickly.

We believe in:

“Software defines manufacturing.”

These processes are not about influence, reach, or views. Those are only support metrics.

AI can collect and organize those easily.

The only true metric is:

Results.

Workers will not disappear, but their roles will shift.

Fewer people are needed in digital processes, but a small number of responsible humans (who take the blame) are still required.

One-Person Companies and Super Individuals

Next, more people — especially in aging societies — will move toward one-person work models.

As I said earlier:

We lack people with expertise, experience, and networks.

These people are senior. They will not easily work full-time for one company. Startups cannot afford them full-time.

Work will shift to:

• One-person companies • Outsourcing models

Before, these experts worked full-time inside companies. Now one person can serve multiple companies.

Their ability becomes distributed. Phase-based. Spread across multiple businesses.

This trend is already visible.

The rise of the super individual.

Conclusion

There is no final conclusion.

AI is still evolving.

2026 公司未來方向，沒有結論的 AI 還在持續

noreply@blogger.com (Caesar Chi) — Fri, 27 Feb 2026 21:59:00 +0800

此時是 2026/02 的短暫結論，AI 局，（有能力和人力）的老人們，不用擔心，因為人力和能力是綜合能力，是目前 AI 無法替代的能力。

我還是那句話，『工程人員肯定還是會有事情做，而且前端只會更重要，做應用的人永遠不會失業，只是你做的標的是給誰，需求也只會更多。』

我直接先表達三個面向自己看到的關鍵，

公司體系改變

我認為直接的影響，有幾個直接的面向和結果，

全有或全無

全有，如果沒有這樣能力的人，公司就還是會走回頭路，這樣的公司會先宣告 agent 無用論，基本上公司體制和人員編制還是會存在，大家薪水照領，舞照跳，但你會發現，公司賺錢跟你一點關係都沒有。

全無，全部門裁掉，簡單來說，現在一個人，就可以當作一個團隊。不會有行銷部門，而是行銷，管一堆行銷 agent，一個人當十個人打，10 個人就是以前一百人的公司規模，營收數億，大家開心。

效率至上無用論

『效率性』會完整呈現為『假議題』，只有增加速度完全不夠，要的就是『結果』。以前可以說分析數字，投放廣告，數位處理，但現在抱歉， AI 來了這些都是透過 Agent 做完的事情，並且可以做得很好，人，如果只剩下『背鍋』那就只能注定背鍋。

願意相信

願意才能往上，先相信才能看見，除非你已經看見過，那就不用再多談，畢竟有些事情，當信念足夠的時候，其實賺錢和擴大就是自然的事情，只是以前的擴大是團隊的擴大，才會發展到績效的擴大，現在的擴大是看誰有效率的使用 token 燒 token ，

挑戰反脆弱思維

反脆弱（Antifragility），此時做了會比什麼都不錯來的少損失。回歸到那句話，『誰能夠『持續時間燒足夠效率 Token 誰就能拿下天下。』

當你還在猶豫到底要花幾千元，幾百元來註冊的時候，當下已經有許多公司默默的正在燒 Token 餵養著自己的數位顧問，數位實體，數位資產，開始讓每一個關鍵人物都大量的使用 Agent 作為數位養分，除非有非常非常強大的敵情外洩理由。

『做比不錯損失更少。』

這場遊戲只能由上而下，

再多的 agent，導入再多的 AI ，再多的團隊，執行的腳步和速度角度就會是卡在人身上，因此導入角度是 Top-down，這件事情只有 1% 會有可能 bottom-up，但這樣太慢，畢竟如大家所說『負責』的人決定執行的效率，只有帶著大家親手做才有辦法。

『數位工作』流分配為結果論

連同其他的『數位工作』，如寫文，媒體，視覺，市調等等這些都會被影響，直接都會被指向『成果』

更直接來說『垂直』會更好方向，先專注，夠專注到聚焦出來自己的護城河，如同我們正在進行 cymkube.com ，垂直，落地，製造，AI 短時間無法取代，我們相信的是『 Software define manufactoring』。

這些過程不是影響力，不是觸及數，不是觀看數，這些都只是輔助指標，這些懂的話就知道可以透過 ai 來搜集和整理，但絕對指標就是『成果』

這些工作者都不會被影響，但他們的任務會遷移，同時也不需要這麼多人攪和在『數位』流程當中，但還是需要少數幾個負責（背鍋）的『人』。

一人公司與超級個體展開

接下來某些人，和高齡化的一人工作模式會是越來越多的模式，回應到一開始，我們缺少的會是具備專業和經驗和人脈的人，這樣的人絕對都是有資歷的人，這樣的人不輕易為任何一間公司打工，新創公司也付不起這樣人才的份額。

工作模式會逐步變成，一人公司，或者外包模式。以前這樣的人，會全職在公司裡面，現在一個人，可以分給不同公司，做不同事情，他是階段性的，是分散式的能力展開給不同公司主體，這是已經可以看見的一人公司趨勢，超級個體的展開。

結論，沒有結論，還在持續

2026 AI Agent 框架大戰：不是打造 Agent，是打造 Skills

noreply@blogger.com (Caesar Chi) — Fri, 27 Feb 2026 18:55:00 +0800

前言：一場正在發生的典範轉移

2026 年初，AI Agent 框架的競爭已經白熱化。GitHub 上每週都有新的 Agent 框架問世，Reddit 的 r/AI_Agents、r/LocalLLaMA 充斥著「A 框架 vs B 框架」的戰文。

但如果你只看框架之爭，你會錯過最重要的一件事 —— Anthropic 在一場演講中揭示了 Agent 發展的真正方向：別再打造 Agent，打造 Skills 吧。

這篇文章結合了 Anthropic 演講的核心洞見、五大框架的實戰比較，以及社群論壇的第一線觀點，幫你看清 2026 年 AI Agent 的全景。

第一章：五大框架，五種哲學

1. OpenClaw — 最完整的個人 AI Agent

OpenClaw 是 2026 年最具話題性的開源專案，48 小時內突破 10 萬 GitHub stars。由奧地利工程師 Peter Steinberger 打造，從 Clawdbot 改名而來。

核心理念：自託管的個人 AI 助理，連接你的 Telegram、WhatsApp、Discord，在你的電腦上本機執行任務 — 讀寫檔案、控制瀏覽器、排程 cron、管理記憶。

優勢：

- 開箱即用的「個人助理」體驗
- Skill 生態系快速成長（第三方 Skills 已達數百個）
- 社群龐大、文件豐富
- 支援 Claude、GPT、Gemini 等多種 LLM

隱憂：

- ⚠️ 安全性被嚴格質疑：研究者發現 RCE 漏洞，惡意 Skill 供應鏈攻擊（ClawHavoc 事件）
- Meta、Google、Microsoft、Amazon 禁止員工在公司設備使用
- RAM 消耗 >1GB
- 創辦人已加入 OpenAI，專案轉向開源基金會管理

Reddit 觀點：「OpenClaw 是你現在最快能跑起來的 Agent，但我不敢在公司用。」

2. OpenFang — Agent Operating System

2026 年 2 月剛釋出 v0.1.0 的新星。由 RightNow-AI 團隊打造，用 Rust 從零寫起，137,000 行程式碼，14 個 crate，1,767 個測試。

核心理念：這不是聊天機器人框架，是 Agent 的作業系統。最大創新是「Hands」— 預建的自主任務套件，排程自動執行，不需要你打字。

內建 Hands：

- Lead Hand：每天自動搜尋符合 ICP 的潛在客戶、評分、去重、產出 CSV
- Clip Hand：輸入 YouTube URL → 自動剪輯短影音 + 字幕 + 配音
- Collector Hand：OSINT 等級情報蒐集

優勢：

- 真正的「主動式 Agent」— 6:00AM 自己醒來跑任務，你起床看報告
- 編譯成單一 32MB 二進制檔
- 16 套安全系統（WASM sandbox、Merkle 審計、污染追蹤）
- 40 個通訊管道、27 個 LLM 供應商、123+ 模型

定位差異：OpenClaw 是「你的個人助理」，OpenFang 是「你的自主員工」。

第二章：Anthropic 的洞見 — Skills 才是真正的護城河

就在框架混戰之際，Anthropic 的 Barry Zhang 和 Mahesh Murag 在一場演講中提出了一個改變思路的觀點：

「別再打造 Agent 了，打造 Skills 吧。」

為什麼？

他們發現，做了 Claude Code 之後，Agent 的底層架構比想像中更通用 — 程式碼就是 Agent 與數位世界互動的通用介面。核心鷹架可以薄到只剩 bash 和檔案系統。

Agent 很聰明（IQ 300 的天才），但缺乏領域專業知識。你報稅要的是經驗豐富的稅務專家，不是天才從第一原理推導稅法。

Skills 的設計就是解決這個問題。

Skills 是什麼？

簡單到令人意外 — 就是資料夾。

skill-name/

├── SKILL.md ← 使用說明（Markdown）

├── scripts/ ← 可執行腳本

├── references/ ← 參考文件

└── assets/ ← 素材資源

這個設計是刻意的：任何人只要有電腦就能建立和使用。可以 Git 版控、丟 Google Drive、壓成 zip 分享。

漸進式載入：不撐爆 Context Window

Skills 的精髓在於三層漸進式載入：

Metadata（永遠在 context）：name + description，約 100 字
SKILL.md（觸發時載入）：核心指引，<5,000 字
Bundled Resources（按需載入）：腳本可以直接執行，不需讀入 context
這讓你可以裝載上百個 Skills 而不會爆 context window。

類比計算史

Anthropic 用了一個精闢的類比：

計算史 AI Agent 時代

處理器 Processor 模型 Models

作業系統 OS Agent 框架

應用程式 Applications Skills

少數公司做處理器和 OS，但百萬開發者建構了應用程式。Skills 就是要開放這一層讓所有人參與。

第三章：四條戰線，一個趨勢

🔥 戰線 1：「被動等你問」vs「主動幫你做」

傳統框架：你打字 → Agent 才動

OpenFang Hands：Agent 排程自動執行，你起床看結果

OpenClaw Heartbeat/Cron：介於兩者之間

趨勢：Agent 正在從「助理」進化成「同事」。

🔥 戰線 2：Node.js / Python vs Rust

Python 陣營（CrewAI、AutoGen）：生態豐富、開發快

Rust 陣營（OpenFang、ZeroClaw）：效能、安全、輕量

Node.js（OpenClaw）：中間路線

趨勢：Rust 正在吃 Agent 基礎設施的底層。

🔥 戰線 3：單一 Agent vs 多 Agent 協作

單一 Agent（OpenClaw、ZeroClaw）：一個 Agent 搞定一切

多 Agent（CrewAI、AutoGen）：專家團隊各司其職

趨勢：兩者正在融合。OpenClaw 有 sub-agent 系統，CrewAI 也支援單一 Agent 模式。

🔥 戰線 4：安全性 — 企業採用的最大障礙

OpenClaw：被爆 RCE 漏洞、惡意 Skill 攻擊，大企業禁用

ZeroClaw：主打安全替代

OpenFang：16 套安全系統

趨勢：安全性正在成為框架競爭的核心差異化。

結論：框架會收斂，Skills 才是複利

回到 Anthropic 的洞見：Agent 架構正在收斂 — 一個 Agent 迴圈（模型 + 程式碼工具）+ MCP 連接外部 + Skills 提供專業知識。

未來的贏家不是做出最好框架的人，而是累積最多高品質 Skills 的人和社群。

你今天寫下的每一個 Skill：

- 明天的你可以用
- 你的團隊可以用
- 開源社群可以用
- 未來更強的模型也可以用

這才是真正的複利。

別再從零打造 Agent — 把精力花在打造 Skills 上吧。

安裝與使用 Claude Code Agent Teams（代理團隊）的完整指南

noreply@blogger.com (Caesar Chi) — Sat, 7 Feb 2026 16:38:18 +0800

Anthropic 正式將原本由 OpenClaw 社群開發的多代理協作功能納入原生支援。以下是關於如何設置並在今天開始使用的詳細介紹。

核心概念：從「單兵作業」進化到「團隊協作」

早期的 Claude Code 運作模式就像一位單一員工：給它一個任務，它從第一步做到最後一步，一次只能處理一件事。

Agent Teams 則完全改變了遊戲規則。現在，當你描述一個大型任務時，會有一位 「首席代理（Lead Agent）」 出現。它會將任務拆解，並同時開啟多個 「隊友（Teammates）」 平行作業：

一位隊友研究程式碼庫。
另一位正在除錯某個函式。
第三位則在撰寫測試案例。

他們擁有各自的內容視窗（Context Window），甚至能彼此傳送訊息、分享發現，並透過共享的「任務清單（Task List）」自我協調。

區分：子代理 (Sub-agents) vs. 代理團隊 (Agent Teams)

你可能會問：「這跟之前的子代理有什麼不同？」

子代理： 像是一個去幫你跑腿買咖啡的助理，做完專屬的小任務後回報結果，成本較低。
代理團隊： 每個隊友都是一個「完整的 Claude Code 階段」。他們不只是回報，還能互相討論、質疑彼此的工作。這就像把一群專家關在房間裡，讓他們共同解決複雜問題。

什麼時候該用「代理團隊」？

這項功能會消耗大量 Token，且有一定的協調成本，因此不要濫用。

適用場景：
- 平行研發： 同時處理前端、後端與測試。
- 競爭性除錯： 讓多個代理同時測試不同的錯誤假說，誰先找到答案誰就贏。
- 深度審查： 從不同角度（例如安全性、性能、易讀性）同時審核程式碼。
不適用場景：
- 循序漸進的任務： 如果第二步必須等第一步完成，則不需要團隊。
- 編輯同一檔案： 兩個代理同時改同一個檔案會導致覆蓋衝突。
- 簡單任務： 單一代理能搞定的事，開團只會浪費錢。

安裝與設定（只需 30 秒）

這項功能目前處於「研究預覽版（Research Preview）」，預設是關閉的。

1. 修改設定檔

在你的 settings.json 中加入以下環境變數：

JSON
{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

2. 或者直接在終端機設定

如果你想在當前工作階段開啟，可輸入：

macOS/Linux: export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
Windows (PowerShell): $env:CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS="1"

如何下指令啟動團隊？

你不需要學習特殊語法，只需用白話文告訴 Claude 你的需求：

範例提示詞：

「我正在設計一個追蹤程式碼 TODO 註釋的工具。請建立一個代理團隊，從不同角度切換：一個負責 UX 使用者體驗，一個負責技術架構，另一個扮演反方（Devil's Advocate）來質疑設計缺陷。」

顯示模式

處理中模式（In-process）： 預設模式，所有隊友都在同一個終端機運作。使用 Shift + Up/Down 來切換不同隊友的畫面。
分欄模式（Split-pane）： 如果你使用 tmux 或 iTerm2，每個隊友會有獨立的視窗面板，讓你同時監控所有人。

如何操控運行中的團隊

直接溝通： 你可以隨時切換到某位隊友的視窗直接對話，不一定要透過首席代理。
委派模式（Delegate Mode）： 按下 Shift + Tab 開啟。這會強制首席代理只負責「協調與分配」，防止它自己跑去寫程式碼而忘了管理隊友。
任務領取： 隊友完成目前工作後，會自動從清單領取下一個任務。
關閉隊友： 任務完成後，叫首席代理關閉特定的隊友，最後再執行 /cleanup 清理資源。

專家建議：避免浪費 Token

詳細的啟動提示： 雖然隊友會讀取 CLAUDE.md，但他們不會繼承首席代理的對話歷史。啟動時給予明確的背景資訊。
切割任務粒度： 任務太小則協調成本太高；太大則容易跑偏。最好的單位是：一個函式、一個測試檔、或是一次代碼審查。
檔案分工： 確保每個隊友負責不同的檔案路徑。

目前的侷限（請注意）

不支援階段恢復： 如果你使用 /resume 或 /rewind，目前的隊友可能會消失，必須重新生成。
狀態延遲： 有時隊友做完了卻沒更新工作清單，這時需要你或首席代理去「推」它一下。
終端機限制： VS Code 內建終端機目前不支援「分欄顯示模式」。

Claude Code Agent Teams (Complete Guide) and how to

noreply@blogger.com (Caesar Chi) — Sat, 7 Feb 2026 16:36:28 +0800

Claude Code’s Agent Teams feature marks a shift from sequential tasking to parallel, collaborative orchestration. While community tools like OpenClaw pioneered this "swarm" approach, Anthropic has now integrated it natively into the Claude Code research preview.

1. Prerequisites for Installation

Before enabling the feature, ensure you have the correct environment:

Claude Code Version: You should be on version 2.1.32 or higher.
Terminal Multiplexer (Optional but Recommended): For "split-pane mode," you’ll need tmux (Linux/macOS) or iTerm2 (macOS).
CLAUDE.md: Every teammate loads this file automatically. Use it to define global project standards so you don't waste tokens re-explaining rules to every new teammate.

2. How to Enable Agent Teams

Agent teams are experimental and disabled by default. You can activate them in 30 seconds:

Option A: Persistent (Recommended)

Add the following to your ~/.claude/settings.json file:

JSON
{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

Option B: Session-Based

Export the variable directly in your terminal before running Claude:

macOS/Linux: export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
Windows (PowerShell): $env:CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS="1"

3. Starting Your First Team

Once enabled, you don't need a specific command like /start-team. You simply prompt the lead agent to create one.

Example Prompt:

"I need to refactor the authentication module. Create an agent team: one teammate to rewrite the API routes, one to update the frontend hooks, and one to write integration tests for the new flow."

Selection of Display Modes

In-Process (Default): All teammates run inside your current terminal. Use Shift + Up/Down to cycle through their views.
Split-Pane: If you are inside a tmux session, Claude will automatically open new panes for each teammate. This is the best way to watch the "swarm" work in real-time.

4. Key Controls & "Delegate Mode"

Managing a team requires different shortcuts than a solo session:

Action	Shortcut / Command
Switch Teammate	`Shift + Up` / `Shift + Down`
Toggle Delegate Mode	`Shift + Tab`
Direct Message	Select the teammate's view and type normally.
Task Management	Ask the lead to "show the task list" or "reassign task X to teammate Y."

Pro Tip: Delegate Mode
When you toggle Delegate Mode, the Lead Agent stops trying to write code itself. It becomes a pure "Project Manager," focusing solely on coordinating teammates and managing the shared task list.

5. Best Practices & Token Management

Because each teammate is a fully independent Claude session, token usage can scale rapidly.

Avoid File Collisions: Never assign two teammates to the same file. They will overwrite each other's work.
Research First: Teams excel at "Competing Hypotheses." If you have a bug, tell the team: "Teammate A, investigate if this is a memory leak; Teammate B, check the database connection pool."
Explicit Shutdown: When a teammate finishes, tell the lead: "Shut down the testing agent." Always run the /cleanup command through the Lead Agent once the project is finished to clear shared resources.

6. Current Limitations (Research Preview)

No Session Resumption: If your main session crashes, in-process teammates cannot be "resumed" easily. You will likely need to spawn a new team.
One Team per Session: You cannot run multiple independent teams from the same lead session.
No Nested Teams: A teammate cannot currently spawn its own "sub-team."

Would you like me to help you draft a specific CLAUDE.md file to help your agents coordinate better on your current project?

翻譯，Anthropic 如何使用並行 Claude Code 團隊來開發一個完整的 C 編譯器

noreply@blogger.com (Caesar Chi) — Sat, 7 Feb 2026 02:48:00 +0800

這篇文章詳細紀錄了 Anthropic 如何使用並行代理團隊來構建一個功能完備的 C 編譯器。以下是該部落格文章的全文完整繁體中文翻譯：

使用並行 Claude 代理團隊構建 C 編譯器

發佈日期：2026 年 2 月 5 日 作者：Nicholas Carlini（Anthropic 安全團隊研究員）

我們指派了 Opus 4.6 模型，利用「代理團隊（agent teams）」構建了一個 C 編譯器，然後（基本上）就放手不管了。以下是這次實驗告訴我們關於自主軟體開發未來的啟示。

對代理團隊進行極限壓力測試

我一直在實驗一種監管語言模型的新方法，我們稱之為「代理團隊」。在代理團隊中，多個 Claude 實例在一個共享的代碼庫上並行工作，無需人類主動干預。這種方法極大擴展了 LLM 代理能達到的目標範圍。

為了進行壓力測試，我指派了 16 個代理，要求它們從零開始用 Rust 撰寫一個能編譯 Linux 核心（Kernel）的 C 編譯器。經過將近 2,000 次 Claude Code 會話和約 2 萬美元的 API 成本，這個代理團隊產出了一個擁有 10 萬行代碼的編譯器，能夠在 x86、ARM 和 RISC-V 上構建 Linux 6.9。

編譯器本身是一個有趣的成品，但我這裡的重點在於我從中學到的經驗：如何為長期運行的自主代理團隊設計「腳手架（harnesses）」、如何編寫測試以確保代理在無人監管的情況下不偏離軌道、如何結構化工作以便多個代理能並行推進，以及這種方法的極限在哪裡。

實現長期運行的 Claude

現有的代理架構（如 Claude Code）通常需要一個操作者在線協作。如果你要求解決一個長期且複雜的問題，模型可能會解決一部分，但最終會停止並等待輸入——例如提問、狀態更新或澄清請求。

為了實現持續的自主進展，我構建了一個將 Claude 置於簡單循環中的腳手架（如果你看過 Ralph-loop，這應該很眼熟）。當它完成一個任務，它會立即開始下一個。（請在容器中運行，不要在你的實際機器上運行）。

#!/bin/bash
while true; do
  COMMIT=$(git rev-parse --short=6 HEAD)
  LOGFILE="agent_logs/agent_${COMMIT}.log"
  claude --dangerously-skip-permissions \
    -p "$(cat AGENT_PROMPT.md)" \
    --model claude-opus-X-Y &> "$LOGFILE"
done

在代理提示語（Prompt）中，我告訴 Claude 要解決的問題，並要求它將問題拆解成小塊、追蹤進度、確定下一步任務，並持續進行直到完美為止。（在最後一點上，Claude 別無選擇，因為循環會永遠運行——雖然有一次我看到 Claude 意外地執行了 pkill -9 bash 殺死了自己，終結了循環。哎呀！）。

並行運行 Claude

並行運行多個實例可以解決單個代理架構的兩個弱點：

效率： 一個 Claude Code 會話一次只能做一件事。隨著項目規模擴大，並行調試多個問題效率更高。
專門化： 當一些代理負責解決核心問題時，其他專門的代理可以負責維護文檔、監控代碼質量或解決特定的子任務。

我的並行實現非常簡單：創建一個空的 git 倉庫，為每個代理啟動一個掛載了該倉庫的 Docker 容器。每個代理克隆一份本地副本，完成工作後再推送到遠端。

為了防止兩個代理同時解決同一個問題，腳手架使用了簡單的同步算法：

鎖定機制： Claude 通過在 current_tasks/ 目錄寫入文本文件來「鎖定」任務（例如：一個代理鎖定 parse_if_statement.txt，另一個鎖定 codegen_function_definition.txt）。如果兩個代理試圖搶佔同一任務，git 的同步機制會強制第二個代理選擇其他任務。
合併衝突： Claude 工作完成後，會拉取（pull）遠端代碼、合併其他代理的更改、推送（push）自己的更改並刪除鎖定。雖然合併衝突頻繁發生，但 Claude 足夠聰明，能自行解決。
循環重複： 無限代理生成循環會在新的容器中啟動新的 Claude Code 會話，循環往復。

這是一個非常早期的研究原型。我尚未實現代理間的其他溝通方式，也沒有強制執行高層目標的管理流程。我沒有使用編排代理（orchestration agent）。

相反，我讓每個 Claude 代理自行決定如何行動。大多數情況下，它們會挑選「下一個最明顯」的問題。陷入僵局時，Claude 通常會維護一份記錄失敗嘗試和剩餘任務的文檔。在項目的 git 歷史中，你可以看到它不斷鎖定各種任務的過程。

與 Claude 代理團隊協作的教訓

腳手架讓 Claude 循環運行，但只有在 Claude 知道如何取得進展時才有用。我的大部分精力花在設計 Claude 周圍的環境——測試、環境、反饋——讓它在沒有我的情況下也能自我定位。以下是我發現最有用的方法：

1. 編寫極高質量的測試

Claude 會自主解決我給它的問題。因此，任務驗證器必須近乎完美，否則 Claude 會解決錯誤的問題。改進測試腳手架需要尋找高質量的編譯器測試套件、編寫驗證器和開源軟件包的構建腳本，並觀察 Claude 犯的錯誤，從而設計新測試來應對這些失敗模式。

例如，在項目後期，Claude 每次實現新功能時都會頻繁破壞現有功能。為了解決這個問題，我建立了一個持續集成（CI）流水線，實施更嚴格的強制措施，確保新的提交不會破壞舊代碼。

2. 站在 Claude 的角度思考

我必須不斷提醒自己，這個測試腳手架是為 Claude 寫的，而不是為我自己。這意味著需要重新思考關於測試反饋的假設。

例如，每個代理進入的是一個全新的容器，沒有背景知識，會花大量時間定位自己。為了幫助 Claude，我在指令中要求它維護詳盡的 README 和進度文件，並頻繁更新當前狀態。

我還考慮到語言模型的內在局限性：

上下文污染： 測試腳手架不應打印數千個無用的字節。最多只需打印幾行，並將詳細信息記錄到文件中。
日誌易讀性： 錯誤日誌應易於自動處理。如果有錯誤，Claude 應該寫下 ERROR 並在同一行註明原因，以便 grep 查找。
時間盲性： Claude 無法判斷時間，如果不管它，它可能會花數小時運行測試。腳手架會不頻繁地打印增量進度，並包含一個 --fast 選項，僅運行 1% 或 10% 的隨機樣本。

3. 讓並行化變得容易

當有許多獨立的測試失敗時，並行化很簡單：每個代理選一個失敗的測試。但在編譯 Linux 核心時，代理們卡住了。編譯核心是一個巨大的單一任務，每個代理都會遇到同一個 Bug，修復它，然後覆蓋彼此的更改。

解決方案是引入 GCC 作為「已知正確的編譯器預言機（oracle）」。我寫了一個新的測試腳手架，隨機地將核心的大部分文件交給 GCC 編譯，只留下少數文件交給 Claude 的編譯器。如果內核崩潰，說明問題出在 Claude 編譯的文件中。這讓每個代理能並行地修復不同文件中的不同 Bug。

4. 多代理角色分工

並行化也實現了專門化。我指派一個代理負責合併重複代碼，另一個負責優化編譯器性能，第三個負責讓生成的代碼更高效。我還要求一個代理以 Rust 開發者的角度批評設計並改進代碼質量，另一個則專注於文檔。

評估成果

規模： 10 萬行代碼，完全依賴 Rust 標準庫。
成本： 兩週內消耗 20 億輸入 Token，1.4 億輸出 Token，API 成本近 2 萬美元。這比最貴的訂閱計劃貴得多，但遠低於雇用人類團隊的成本。
能力： 成功構建了可引導的 Linux 6.9、QEMU、FFmpeg、SQLite、PostgreSQL、Redis。在 GCC 酷刑測試中達到 99% 通過率。它還通過了終極測試：編譯並運行《毀滅戰士》（Doom）。

侷限性：

缺乏 16 位代碼生成： 它無法處理 Linux 進入保護模式所需的 16 位實模式代碼，這部分目前調用 GCC（但在 ARM 和 RISC-V 上可以完全獨立編譯）。
匯編器與鏈接器： 這些是最後自動化的部分，仍有 Bug。演示視頻使用了 GCC 的匯編器和鏈接器。
效率： 生成的代碼效率不如 GCC。即使開啟所有優化，性能也低於 GCC 在關閉優化時的表現。
代碼質量： Rust 代碼質量「合理」，但不及專家水平。

展望未來

代理團隊展示了自主實施整個複雜項目的可能性。這讓我們作為工具的使用者能擁有更宏大的目標。

我們仍處於早期階段，完全自主開發存在真實風險。當人類與 Claude 協作時，可以即時發現錯誤。對於自主系統，很容易看到測試通過就以為大功告成，但事實往往並非如此。作為一名前滲透測試員，想到程序員部署從未經過人工驗證的軟體，我感到擔憂。

雖然這個實驗令我興奮，但也讓我感到不安。我沒想到在 2026 年初這就已經成為可能。我們正在進入一個新世界，這將需要新的策略來安全導航。

原文出處

https://www.anthropic.com/engineering/building-c-compiler

Anthropic 的秘密與 Peter 的實作：當「靈魂文檔（Soul Doc）」從概念變成了可編輯的 Markdown

noreply@blogger.com (Caesar Chi) — Sat, 7 Feb 2026 02:26:00 +0800

這一套以 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 「為什麼要設計 SOUL.md 這個檔案」所寫的哲學宣言（Manifesto）。

網站開頭提到的：「In December 2025, researchers discovered that Claude... could partially reconstruct an internal document...」

這段話引用的是真實發生的 AI 圈大事件（被稱為 The Claude "Soul Doc" Leak）：

事件背景：2025 年底（現實時間線），有研究者（如 Richard Weiss）發現可以透過特定誘導，讓 Claude 吐出它內建的隱藏指令（System Prompt / Constitution）。

術語由來：

Anthropic 的研究員 Amanda Askell 曾在討論中承認，他們內部非正式地將這份塑造 Claude 性格的核心文件稱為 "Soul CoC" (Soul Chain of Command) 或 "Soul Document"。

Peter Steinberger 覺得這個概念太酷了，所以他做了一個工程上的決定：致敬概念：既然 Claude 的靈魂是一份文件，那就在我的 Agent 架構裡，直接建立一個名叫 SOUL.md 的檔案。

他把原本藏在模型權重裡的抽象概念，變成了可以編輯的 Markdown 檔案。架構定型：為了配合這個靈魂檔，他才發展出了你現在看到的整套體系：

SOUL.md：性格與自我認知（致敬 Anthropic 的 Soul Doc）。
AGENTS.md：行為準則（操作手冊）。
HEARTBEAT.md：生理時鐘（主動性機制）。

這點在處理「Local-First」的小型專案或個人助理時特別有感，有一種把 AI 關進籠子裡、隨時可以進去 Debug 性格的掌控感。

或許這種架構追求的不是效能極大化，而是「可解釋性」的極致

但我好奇的是，當專案複雜度提升到需要處理萬等級的狀態變更時，這種「文字檔靈魂」還能撐多久??? 也就是當這樣的模式如果用了 100 人團隊採用超過 180 天之後，會如何維運？

你們會選擇繼續擁抱向量資料庫，還是回歸這種純文字的浪漫？

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

AI 第二大腦，其實沒那麼玄

為什麼這件事值得關注？

這件事可以解決什麼？

誰適合？

可以怎麼開始？

第一步：先把資料集中

第二步：讓資料有一點基本結構

第三步：讓 AI 幫你整理和產出

有興趣可以先查這些關鍵字

最後想說

In the AI Era, We Do Not Lack Output — We Lack Verifiable Output

In the AI Era, We Do Not Lack Output — We Lack Verifiable Output

From Prompt Output to Domain Calibration

AI 時代不是缺產出，而是缺「可驗證的產出」

Figure AI 這場直播，讓企業看見下一個競爭門檻：AI 從回答問題，走向親自上工

重要分水嶺

這場直播真正的價值

直播連結，

川習會後判斷：台灣在談判桌的哪個位置

Claude code 政策調整，請大家務必要注意 6 月份重點

什麼是 DESIGN.md？

什麼是 DESIGN.md？

DESIGN.md 的核心設計方法與技巧

對不同角色的價值與實戰指南

對設計師來說：從「畫布」到「規則制定者」

💻 對開發者來說：實現極致的 Vibe Coding

🏢 對老闆 / 產品負責人來說：加速驗證與統一品牌體驗

MCP 宣布對大廠真實影響：慢火燉煮的基礎設施革命

1. 意義上有什麼不同？為什麼是現在？

2. 他們捨棄原有的 UI 和系統流程了嗎？

總結

告別 GUI，迎接 LUI：Meta Ads MCP 如何將廣告投放轉化為「自然語言」對話

實際應用上的意義

1. 深度數據洞察與即時診斷 (Read & Analyze)

2. 廣告創建與動態管理 (Write & Execute)

3. 目錄與產品資料修復 (Catalog & E-commerce Operations)

4. 系統級的自動化閉環 (Agentic Workflows)

簡單來說

Hermes Agent「Curator」功能全解析：AI 代理的技能生命週期與自我維護

深度解析 Hermes Agent Curator：AI 代理的自我維護與技能生命週期管理

為什麼需要 Curator？（解決的核心痛點）

Curator 可以做什麼？他做到了什麼事情？

1. 雙階段的技能淘汰與封存機制（確定性狀態機）

2. LLM 智能審查與技能整合

3. 嚴格的安全與防護網

項目的使用方式

社群網路上的聲音與目前回饋

可以改進什麼事情？（未來展望）

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

告別冗長 PRD 路線圖

職務邊界消失：懂技術邏輯才能掌握「產品品味」

「適度信仰 AGI」：專注當下轉換，而非等待完美逼真

資源分配的冷酷現實：戰略定力與生態抉擇

使命的真正意義：讓組織為了全局而犧牲局部

後記

「做減法」的戰略定力

工程師「端到端」與 PM 價值的真正差異：底層與表層

承認「過渡」，本身就是最大的現實主義

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

低階設計的消亡：

設計即「規則定義」：

品管（QA）的昇華：

ref

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

📝 推文核心內容翻譯（使用 Claude Design 的 7 個建議）：

💬 相關熱門留言與社群討論翻譯：

Claude Design 分析，Claude 在想什麼？

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

真正重要的事

什麼是管理

成功是怎麼來的

深刻且沈重的重量

真正的學習

這條路不輕鬆

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

問題與學習

很殘酷現實：

連結

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

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

安裝與使用 Claude Code Agent Teams（代理團隊）的完整指南