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

AI-Native Agent 時代的 2026 年身為管理者應該知道的事情

noreply@blogger.com (Caesar Chi) — Sat, 5 Sep 2026 15:17:58 +0800

AI-Native Agent 時代的 AI-Native Engineering

從 Andrew Ng 的 AI Engineering Skills Map，到 2026 年 9 月真正正在成形的 Agent-first Software Development

2026 年 9 月 4 日，Andrew Ng 發表了 AI Engineering Skills Map 系列中關於 Using Coding Agents 的文章，同時期 Claude, Cursor, OpenAI 也發表了許多架構，經驗談，以及商業上的應用，此時將眾家以及自己在正美科技所進行的事情進行彙整，讓大家可以少走些彎路，少踩些坑。

以下這些文章，有點長度，但他對於技術人，對於商業人，對於想要 AI 導入到自己公司的人都會有所幫助，不論你想要自己 vibe coding 或者是你是想要更近一步的 AI 自媒體老師，都應該完整閱讀這篇文章

同時我也希望你可以給我更多回饋，或者加入社團討論

「AI for Developer LINE 社群連結」

本文開始

如果把整篇文章和 2026 年正在發生的事情放在一起看，以及結合自己在開發 cymkube & cympack 的經驗來說，將整個 ai 智能製造 (ai manufacturing) 的過程來說，回歸到軟體工程，可以歸納成一段話。

軟體工程正在從「Human 寫 Code，AI 幫忙」轉向「Human 定義 Intent、Architecture、Constraints 與 Acceptance Criteria，Agent 負責 Execution，而系統負責 Verification」。

回歸過去就是：

2024
Human writes code
AI assists

        ↓

2025
Human prompts
Agent edits code

        ↓

2026
Human specifies intent
Agents execute in parallel
Verifiers inspect output
Humans make judgment

        ↓

Next
Human manages an engineering system
that continuously produces software

Andrew Ng 認為，Coding Agent 已經不只是「會不會用 Claude Code、Codex 或 Cursor」。
它正在變成一個完整的 Engineering Discipline。而真正重要的技能可以分成五類：

Directing the workflow

Enabling agent autonomy

Reviewing the work

Customizing the agent and its environment

Coding agent foundations

今天最有效的 Coding Agent 工作並不是把一個 Prompt 丟進去，然後讓 Agent 自己跑十個小時。
真正成熟的使用方式，仍然是高度 iterative，依舊類似人類的 PDCA，只是執行者不一定是人類：

Understand
↓
Plan
↓
Execute
↓
Verify
↓
Review
↓
Fix
↓
Deploy
↓
Observe
↓
Learn
↓
再進入下一輪

這個觀點截至 2026 年 9 月，已經可以在 OpenAI、Anthropic、Cursor、OpenCode 等產品的實際架構中看到，而且從中可以看到人類在當中扮演的角色逐漸改變，雖然都是 PDCA 的本質，這還是沒有變。

什麼是重要的？

對 Coding Agent 的定義已經改變：

幫我寫一個 function。

Coding Agent 現在可以執行大量非純 Coding 工作，包括理解大型 codebase、資料分析、操作 terminal、調查 production incident、閱讀 logs、修改 infrastructure、寫測試、review PR、建立文件，甚至協調其他 agents。

因此能力瓶頸開始改變。以前：

想法
↓
工程師理解
↓
工程師設計
↓
工程師寫 Code
↓
工程師 Test
↓
工程師 Deploy

最大的 bottleneck 往往是 Implementation。現在 implementation 的成本快速下降。
於是瓶頸開始往上游與下游移動：

              Human
                │
       What should we build?
                │
       What should it mean?
                │
      What constraints matter?
                │
      How do we know it's right?
                ↓
              Spec
                ↓
         Agent Execution
                ↓
            Verifier
                ↓
         Human Judgment

真正稀缺的東西逐漸不是：

「寫 Code 的手」

而是：

「知道什麼是正確答案的人」。

這也是 Andrew Ng 為什麼一直強調 Engineering Judgment，這部分的觀點，其實和近期 Uncle Bob 觀點完美契合 https://news.anything-ai.xyz/p/zcLPGC-tvgk/

Coding Agent 的標準 Workflow

整個過程概括成三大階段：

階段	核心問題
Planning	我們到底要做什麼？
Execution	Agent 應該怎麼完成？
Deployment & Monitoring	做完後怎麼證明它真的能運作？

但 2026 年真正成熟的版本，可以再拆得更細：

1. Intent
   ↓
2. Research / Explore
   ↓
3. Specification
   ↓
4. Architecture
   ↓
5. Execution Plan
   ↓
6. Agent Execution
   ↓
7. Deterministic Verification
   ↓
8. Behavioral Verification
   ↓
9. Human Review
   ↓
10. PR / Merge
   ↓
11. Deploy
   ↓
12. Observe
   ↓
13. Incident / Feedback
   ↓
14. 更新 Rules / Skills / Spec

最大的不同是：

Code 已經只是中間產物。

Spec、Rules、Tests、Context、Logs、Evals、Artifacts、Permissions 都變成軟體工程的一部分。

Planning：不要一開始就叫 Agent 寫 Code

我們認知到，真正『成熟工程師』首先會控制一件事情：

Agent 什麼時候開始動手？

這很重要。

因為 Agent 最大的問題通常不是「寫不出來」，而是：

很快地寫出錯的東西。

假設你說：

幫我加一個報價功能。

Agent 很可能會馬上：

Create QuoteController
Create Quote model
Create migration
Create routes
Create Blade page

看起來很勤奮。但它根本還不知道所謂的『細節』：

報價是否有 revision？
一張 RFQ 能不能有多份 Quote？
Quote 是否需要客戶簽核？
幣別？稅？有效期限？
B2B buyer 跟 internal sales 看到的欄位是否不同？
PDF 是否必須保存 immutable snapshot？

所以更成熟的方式是：

User Intent
     ↓
Agent explores repository
     ↓
Agent asks / infers domain questions
     ↓
Spec
     ↓
Architecture
     ↓
Acceptance Criteria
     ↓
Implementation

Anthropic 很早就在 Claude Code 的最佳實務裡提出類似的：

Explore → Plan → Code → Commit

並建議複雜問題先探索 codebase、建立 plan，再實作，這也是為什麼在正美科技數位發展部我們深度的與 Claude 進行合作。

Spec 正在重新成為軟體工程核心

AI Coding 最有趣的一個反轉是，以前很多團隊嫌 Spec 太慢。（因為以前 Spec 都需要層層檢驗，層層檢視）

現在 Agent 寫程式太快，

反而沒有 Spec 會更慢。 因為：

Bad spec
×
Fast agent
=
Fast wrong implementation

所以 2026 的成熟團隊開始把自然語言 specification 當成 production asset。一個好的 Spec 不只是：

我要一個登入功能。

而是：

Goal

讓企業客戶可以透過 Email OTP 登入。

Actors

Buyer
Internal Admin

Flow

Buyer 輸入 Email
→ 發送 OTP
→ OTP 10 分鐘有效
→ 驗證
→ 建立 session

Constraints

不得建立密碼
OTP 每個 Email 每分鐘最多請求一次
連續輸入錯誤五次鎖定 15 分鐘
所有 OTP 驗證事件需要 audit log

Acceptance Criteria

未註冊 Email 不洩漏帳號存在與否
Expired OTP rejected
Used OTP cannot be reused
Rate limiting works
Audit log created

這種文件的價值，不只給人類（ Human ）看。它其實變成：

Agent Contract。

2026 年更進一步：Behavior Spec

2026 年 9 月 4 日 Cursor 公布的 Basis 案例非常值得注意。

Basis 做的是高複雜度的會計 Agent。

例如一份 partnership tax return，人工可能需要約 30～40 小時，他們的 Agent 可以花約 6～7 小時完成，但真正困難的不是「最後答案對不對」。

因為高風險工作可能出現：

結果碰巧正確，但是過程錯誤。

例如：Agent 得到正確稅務答案，但引用了錯誤 authority。

所以 Basis 另外建立：

Behavior Spec

也就是定義：

在什麼情境下

Agent 應該：

看什麼 Evidence
↓
做什麼 Decision
↓
採取什麼 Action
↓
留下什麼 Proof

然後 Judge 評估 Agent trajectory，而不是只看最後 output。
這可能會成為接下來非常重要的一種 Agent Engineering 方法。

Execution：Agent Autonomy 不是越大越好

特別提醒：社群媒體很容易把：（特別是 x 或者某些自媒體大神，說的就是那些人）
「Agent 自己跑十幾個小時，就跑出 OOXX」

描述成 AI Engineering 的最高境界。但他認為目前這被過度放大了。真正應該問的是：

這個 Task 最適合多少 Autonomy？

可以用一個簡單模型：

Task	Autonomy
修改 typo	極高
補 unit test	高
小 bug fix	高
新 API endpoint	中高
Database migration	中
Authentication	中低
Payment	低
Production data mutation	非常低
刪除 production resource	Human gate

因此真正成熟的 Agent 系統不是：

Full Autonomous = Good

而是：

Autonomy
=
Task Risk
×
Verification Quality
×
Rollback Ability
×
Environment Isolation

如果 Verification 很強，就可以放更多 autonomy。
如果 Verification 很弱，Human 就必須增加 involvement。

這句話可能不是這麼好懂，但你可以留著上面那段公式自己做驗證。

Verification 正在成為最重要的 Engineering Skill

AI 時代很可能發生一個很大的工程角色轉移：

以前

Engineer
=
Implementation

現在

Engineer
=
Intent
+
Architecture
+
Verification
+
Judgment

Agent 說：

Done.

完全沒有意義，真正有意義的是：

Unit tests: PASS

Integration tests: PASS

Static analysis: PASS

Security checks: PASS

Browser test: PASS

Screenshot comparison: PASS

Acceptance criteria: 12/12

No unexpected DB migration

No API contract change

PR ready

也就是：

Don't trust completion.
Trust evidence.

Cursor 的 Cloud Agents 現在會提供 screenshots、videos、logs 等 artifacts，讓使用者不需要只看 Diff，而可以直接看 Agent 怎麼驗證結果。

Codex 也把 terminal logs、tests 等證據當成工作結果的重要部分。

2026 年 9 月真正的 Coding Agent 使用方式

現在大致形成六個層級。

Level	工作方式	Human 工作
L0	AI autocomplete	寫 code
L1	Chat-based coding	下 Prompt + 修改
L2	Interactive Agent	指揮 Agent
L3	Delegated Agent	定義 Task + Review
L4	Parallel Agents	管理多 Agent
L5	Agentic Software Factory	管理 Intent、Context、Verifier、Policy

目前很多成熟 AI Engineering 團隊，已經從 L2 往 L3/L4 移動。
目前正美科技數位發展部已經將 Cymkube 這樣的服務整體發展到 L4 ，正在往 L5 方向發展。

OpenAI 在 2026 年公開過一個很極端但值得觀察的內部實驗：一個產品約五個月的建置過程中，由 Codex 產生 application logic、tests、CI、documentation、observability 等程式碼，人類工程師不直接手寫 production code。OpenAI 將核心理念描述為 Humans steer, agents execute，而人的工作轉向建立環境、描述意圖與設計 feedback loops。

這不是代表所有團隊都應該這樣做，而是它展示了一個非常重要的方向：

Harness Engineering。

什麼是 Harness Engineering？

以前：

Model = intelligence

現在比較接近：

                  MODEL
                    │
           ┌────────┴────────┐
           │                 │
        Context            Tools
           │                 │
      AGENTS.md             MCP
       Skills               CLI
       Memory               APIs
           │                 │
           └────────┬────────┘
                    │
              Agent Harness
                    │
             Sandbox / VM
                    │
                Verifier
                    │
            Logs / Artifacts

真正決定 Agent 表現的，不只是 Model。

而是整個：

Model + Harness + Context + Tools + Environment + Verification。

這也是為什麼兩個人使用相同模型，成果可以差非常多。

Context Engineering

2026 年開始，「Prompt Engineering」這個概念本身已經太小。真正需要管理的是：

Context Engineering

也就是：Agent 在每個決策點到底知道什麼？
Context 來源可能包括：

User Intent
Product Spec
Architecture
Repository
AGENTS.md / CLAUDE.md
Rules
Skills
Tool descriptions
API docs
Database schema
Previous decisions
Previous failures
User feedback
Current task state

大家也很清楚，這些東西如果全部塞進 Context，Agent 反而表現會變差。
所以新的 Engineering 問題是：

什麼資訊在什麼時候應該出現？

OpenCode V2 已經把 instructions、AGENTS.md、skills、references、MCP 與 session context 明確當成 context system 的不同來源。

Cursor 也區分：

Project Rules
User Rules
Team Rules
AGENTS.md

Claude Code 則長期使用：

CLAUDE.md
Project settings
Skills
Hooks
MCP
Subagents

這邊當然還有許多不同陣營，但其實方式都是大同小異。

不要把 AGENTS.md 寫成公司百科全書

一個常見錯誤：

AGENTS.md

公司歷史
產品歷史
100 條 coding rules
Database 全 schema
API 全文件
Deployment 全流程
UI 全 Design System
所有 edge case

最後可能 20,000 tokens。結果：

Agent 每一次 request 都背著一整本員工手冊。
更好的架構是：

AGENTS.md
│
├── 核心 architecture
├── 必須遵守的 rules
├── build/test commands
├── verification requirements
│
└── References
      │
      ├── docs/domain/quote.md
      ├── docs/security/auth.md
      ├── docs/api.md
      └── skills/

也就是：

Progressive Disclosure

需要時再拿。

Skills 正在取代超大型 Prompt

2026 Coding Agent 一個很明顯的方向是：

把 repeated workflow 變成 Skills。

例如：

/create-api

/fix-issue

/review-security

/create-migration

/check-production-log

/run-e2e

/create-pr

Skill 裡面可以包含：

Instructions
Templates
Scripts
Examples
References
Verification rules

所以 User 不需要每次說：

先查 route
再查 controller
不要破壞 service layer
記得 run phpstan
記得 run tests
記得檢查 API response
最後 create PR

而只要：

Use our backend-feature skill.
Implement QUOTE-183.

OpenAI 目前也把 Skills 定義成把 instructions、resources、scripts 打包的工作單位，並透露內部已經建立數百個 Skills，處理 eval、training runs、documentation、growth analysis 等工作。

Subagents：不是建立一群人格，而是分離 Context

很多人還是會停留在每個 Agent 就是每個角色，每個職能的概念來進行，
通常最常見的例子是這樣的 Multi-Agent （錯誤的例子）：

Architect Agent
Coder Agent
Senior Agent
Junior Agent
Manager Agent
CEO Agent

然後讓它們互相聊天。

然而在我們的經驗以及實際的結果，這通常不是最有價值的 Multi-Agent。

Subagent 真正最大的價值之一是：

Context Isolation

例如：

              Main Agent
                   │
        ┌──────────┼──────────┐
        │          │          │
     Explore     Security    Tests
      Agent       Agent      Agent
        │          │          │
     findings    findings   findings
        └──────────┼──────────┘
                   ↓
               Main Agent

以職能來做區隔，以 workflow 來進行區隔

Explore Agent 可以讀大量舊 code。

Security Agent 可以專心做 security audit。

Test Agent 可以研究 existing test conventions。

Main Agent 不需要把每個檔案與中間推理全部塞進自己的 Context。

OpenCode 目前也正式將 primary agent 與 subagent 分離；subagent 使用自己的 child session 與 fresh context。

Parallel Agent

而上述的概念可以延伸到這邊，當 Task 可以 independent decomposition 就可以 parallel：

Feature
│
├── Agent A: backend
├── Agent B: frontend
├── Agent C: tests
├── Agent D: docs
└── Agent E: security review

往下延伸的方式，比較成熟做法最好是：

                SPEC
                  │
             Orchestrator
                  │
        ┌─────────┼─────────┐
        ↓         ↓         ↓
      Agent A   Agent B   Agent C
        │         │         │
     worktree  worktree  worktree
        │         │         │
        └─────────┼─────────┘
                  ↓
             Integration
                  ↓
               Verify

OpenAI 的 Codex app 已經以 worktrees 支援同 repo 多 agent 隔離工作。

Cursor Cloud Agents 則讓大量 Agents 各自在自己的 VM/environment 裡工作。

到了 2026 年，「Background Agent」已經非常實際

以前 coding agent 基本上跟 IDE 綁在一起。

你必須坐在電腦前：

Prompt
↓
Agent
↓
看
↓
修改 Prompt

現在開始變成：

Slack
LINE
Linear
GitHub
PagerDuty
Schedule
Webhook
        │
        ↓
   Cloud Agent
        │
    isolated VM
        │
      Build
        │
      Test
        │
      Verify
        │
     Create PR
        │
     Human Review

Cursor Automations 已經支援 Slack、Linear、GitHub PR、PagerDuty、schedule、webhook 等事件觸發；官方描述的實務包括 issue triage、incident triage、文件更新、security review 與 status reporting。

所以 Coding Agent 慢慢不是：

一個你打開的工具。

而是：

Software Development Infrastructure。

2026 年企業正在怎麼用？

最有意思的是，現在 Agent 已經開始處理過去很難想像交給 Coding AI 的工作。

Nokia 在 2026 年 9 月 2 日公布案例：兩位工程師透過 Cursor 分析超過 5,000 萬行的混合語言 codebase，約兩週完成原先預估需要十多名專家、數個月與客製工具才能完成的 architecture analysis。這是供應商公布的 customer story，因此數字應視為企業自述案例，而不是獨立 benchmark，但它仍反映 Agent 已經從「產 code」進入「理解超大型 codebase 與 architecture decision support」。

Cisco 一位工程主管近期描述自己一天同時管理 10～20 個 Agent，工程工作的挑戰因此從 coding 轉為監督、review、async attention management；這同時也是 Andrew Ng 所說的「Human attention across concurrent agent sessions」開始變成實際管理問題。

OpenAI 內部則觀察到 Agent usage 已經不只工程師：到 2026 年中，Legal、Finance、Recruiting 也大量透過 Codex 執行 automation、data transformation、structured analysis 與 technical execution。

所以 Coding Agent 這個名字，可能很快就會過時。
更準確的說法可能是：

Computer Agent

或者：

Work Agent

完整實戰案例：Laravel B2B 報價功能

現在我們直接做一個完整例子。
假設系統：

Laravel
MySQL
Redis
Queue
REST API
Vue / React frontend

需求：

RFQ 可以由內部業務建立 Quote，客戶可以在線上確認報價。

傳統 Agent Prompt 可能是：

幫我完成 RFQ 報價功能。

不建議。

真正 Agent-native Workflow 應該這樣開始。

Environment 甚至比 Model 更重要

Cloud Agent 經驗時直接指出：

development environment 本身就是產品的一部分。

如果 Agent：

看得到 code，但跑不了 service；可以改 frontend，但開不了 browser；
可以產 migration，但沒有 test DB；可以寫 API，但無法 query integration environment，它就無法真正 close the loop。

所以企業以後可能會有一個新的 infra：

Agent Development Environment

Git
Runtime
Dependencies
Dev DB
Browser
Testing
Internal APIs
Observability
Secrets
Network Policy
Sandbox

Agent 像新員工。

但差別是：

你可能一次 onboard 100 個。

2026 年 Agent 工程最容易踩的坑

這些問題比「Prompt 寫不好」嚴重得多：

問題	結果
Spec 不完整	快速做錯
Context 太多	Agent attention 被污染
Context 太少	Agent 猜 architecture
沒有 verifier	Agent 自稱完成
Test coverage 假象	錯誤被測試共同合理化
Agent 自己 review 自己	confirmation bias
Parallel agents 改同一區域	merge chaos
太多 MCP tools	工具選擇混亂
權限太大	blast radius 過大
Production secrets 暴露	security incident
無 network policy	data exfiltration risk
長時間 unattended	error compounding
每次 Session 從零	重複犯錯
所有 learnings 寫進 Context	context bloat
AI code growth 無治理	agent-generated debt

安全問題會變得比現在更重要

這是 Agent-first Development 很容易被忽略的部分。

以前：

AI outputs text

現在：

AI
↓
Terminal
↓
Filesystem
↓
Git
↓
Database
↓
Cloud
↓
Production

能力越高，負責的範圍就更大，最近許多案例都有顯示此問題，並不是叫大家不要用 Agent

建議企業 Agent Architecture 應該更接近：

               Agent
                 │
           Agent Identity
                 │
          Permission Policy
                 │
       ┌─────────┼─────────┐
       │         │         │
      Git       DB       Cloud
       │         │         │
    scoped     read     sandbox
     token     only
       │
       └─────────┬─────────┘
                 ↓
             Audit Log

OpenAI 在 2026 年公開其 Codex 內部安全方式時，重點包括 managed configuration、sandbox、network policies、權限邊界以及 agent-native logs。

Anthropic 同樣將問題定義為控制 Agent 的 blast radius，也就是即使失敗，能造成的最大損害是多少。

因此不要把：

--dangerously-skip-permissions

當成 productivity feature。

Anthropic 後來甚至設計 Auto Mode，就是希望在提高 autonomy 的同時，不必直接移除全部 safety boundaries。

MCP 不是越多越好

另一個 2025～2026 常見錯誤是：

GitHub MCP
Slack MCP
Notion MCP
Jira MCP
Database MCP
Sentry MCP
AWS MCP
Browser MCP
CRM MCP
Everything MCP

全部灌進 Agent。

問題是每一個 Tool 都帶來：

Tool description
Parameters
Possible actions
Errors
Context
Permissions
Attack surface

所以成熟架構會變成：

Task
↓
Skill
↓
Need tool?
↓
Load MCP
↓
Execute
↓
Release context

而不是：

所有工具永久存在。

2026 的工程師必須理解 tool call、MCP、context window 之間的互動，而不是把 Agent 當 black box。

人類的工作不會消失，但會往上移

Coding Agent 時代最容易出現兩種錯誤說法：

「工程師都會消失。」

或：

「AI 就只是 autocomplete。」

兩者都太簡單。

我自己認知比較像是，結合各方觀點更可能的是：

之前的狀態

Engineer
├── code
├── debug
├── test
├── refactor
├── docs
└── deploy

AI 後時期變成：

Agent-Native Engineer
├── understand business intent
├── architecture
├── write specifications
├── define constraints
├── design agent environment
├── define verification
├── supervise agent fleet
├── review exceptions
├── manage production risk
└── improve the system

也就是：

Human moves from Execution to Judgment.

專家從執行者變成評判者

最大的 Bottleneck 會變成 Human Attention

假設以前：

一個工程師一天寫：

1 feature

現在他可以啟動：

Agent A
Agent B
Agent C
Agent D
Agent E
Agent F

問題馬上變成：

6 Agents
×
20-minute review
=
120 minutes review

現在大家面臨的問題就變成同時 20 Agents 發出的 PR / Issue 對於人類來說根本 review 不完。

所以未來真正重要的是：

Attention Allocation

也就是：

哪些 Agent outcome 需要 Human 看？

哪些由 verifier 過掉就好？哪些只有 anomaly 才 escalation？

未來可能是：

100 Agent Tasks
      ↓
Automated Verification
      ↓
20 unusual results
      ↓
AI Review
      ↓
5 risky cases
      ↓
Human

Human attention 會變成最貴的 compute。

KPI 不該是 Token 數

Tokenmaxxing 真的是一個很無意義的事情，也該停止這個行為。

真正應該測：

Verified outcomes / Human hour

例如：

Verified PRs
──────────────
Human Review Hour

又會者回到商業價值本身來進行評估產值：

Business Value
───────────────
Human Attention

2026 年目前四種工具大致定位

系統	目前比較突出的方向
Claude Code	Terminal-first、context、skills、hooks、subagents、MCP
Codex	Multi-agent command center、cloud/local、skills、automation
Cursor	IDE + cloud agents + automations + artifacts + enterprise orchestration
OpenCode	Open harness、agent configuration、primary/subagent、permissions

但真正長期重要的可能不是選哪一家。

而是：

不要把 Organizational Knowledge 綁死在某一個 Agent 裡。

理想架構：

Company Knowledge
        │
        ├── Specs
        ├── AGENTS.md
        ├── Skills
        ├── Scripts
        ├── APIs
        ├── Tests
        └── Evals
              │
      ┌───────┼────────┐
      ↓       ↓        ↓
   Claude   Codex    OpenCode

模型可以換。Harness 可以換。

但以下這些重要的東西，都該留下應該留下來：

Domain Context
Specs
Verification
Process

Agent Memory 真正應該記什麼？

不要讓 Agent 記：

Kevin 喜歡 variable name 短一點。

真正有價值的是：

2026-09-03

Quote revision cannot mutate previous quote
because Finance requires historical price snapshots.

Decision:
Revision always creates new quote row.

Reason:
Auditability.

Do not:
UPDATE previous quote.

這叫：

Institutional Memory

也就是讓下一個 Agent 不要重新犯一次錯。

Post-run Retrospective

應該讓 Agent 累積 learnings，例如每次大型 Task 後：

What failed?

Migration assumptions incorrect.

Why?

AGENTS.md did not explain multi-tenant DB.

Fix:

Add tenancy rule to architecture docs.

What repeated work occurred?

Agent repeatedly searched payment lifecycle.

Fix:

Create payment-domain reference.

What verification was missing?

No duplicate webhook test.

Fix:

Add webhook idempotency test template.

然後把結果真正寫回：

Docs
Skills
Tests
Rules
Evals

這樣下一個 Agent 會變強。

不是因為 Model 被 fine-tune，

而是：

Environment learned.

每個事件後真正的學習和回歸校正

未來 12～24 個月，我認為會發生什麼？

接下來就會很直接的往 AI-native 的原生部門開始發展，這並非全部的部門都可以這樣展開，就如同雙軌轉型，小型公司可以很快的進行 AI-native ，但大型公司比較適合採用雙軌轉型的獨立部門機制來進行，

而有特別提醒一下，在摸索一段時間後， 2026 年，真正的架構應該是，
真正的 AI-native 是：

Human
負責

Intent
Judgment
Architecture
Trade-offs
Risk
Trust

        ↓

Agent System
負責

Search
Analysis
Implementation
Testing
Iteration
Documentation
Monitoring

        ↓

Deterministic System
負責

Constraints
State
Permissions
Validation
Audit
Verification

因此最後會形成：

Human Judgment

Agent Execution

Deterministic Backbone

這三層，而且每一層都會直接對應到商務流程，商業目標，並非單一任務執行。

結論

過去最好的工程師可能是：

可以很快把複雜需求寫成穩定 Code 的人。

接下來最好的工程師可能是：

能把模糊商業意圖轉換成清楚 Spec、Architecture、Constraints 與 Verification，然後建立一套環境，讓數個甚至數十個 Agents 安全、可靠、持續地完成工作的那個人。

所以未來最有價值的能力不單純是：

Coding

而是：

Directing
Context Engineering
Verification
Agent Harness Engineering
Architecture
Judgment

這些聽起來好像都很技術，但實際上他跟 AI Agent / AI workflow 環環相扣，並且與實際的商業流程是緊密結合在一起，因此如何找到一個適合的 FDE ，或者同時橫向領域跨足技術到商業並且願意親自參與實作的角色，會尤其重要。

這本身展開之後就會是：

一套會自己持續生產、驗證、維護生態系統。

這才是 AI-Native Agent 時代真正開始成形的地方，而這個部分只是剛開始。

MiniMax H3 到底厲害在哪裡，到底是什麼？懶人包從應用到技術看這篇就夠啦

noreply@blogger.com (Caesar Chi) — Fri, 7 Aug 2026 13:44:31 +0800

MiniMax H3 到底是什麼？先用人話理解

最近很多人在討論 MiniMax H3，甚至有人說：

一張 16GB 顯卡，就能在自己電腦裡跑出有畫面、有聲音的 AI 影片。

聽起來很誇張，因為過去這類高品質 AI 影片，通常只能在大型公司的雲端平台使用。你必須上傳圖片、輸入文字、等待伺服器處理，而且每生成一次都可能要付費。

但 MiniMax H3 出現後，事情開始改變。

最簡單的理解方式是：

MiniMax H3 就像把導演、攝影師、動畫師、配音員和音效師，放進同一個 AI 模型裡。

以前要做一支 AI 影片，可能要經過很多步驟：

先生成圖片
再把圖片變成影片
再產生人物說話的聲音
再做嘴型同步
再補環境音效
最後進剪輯軟體把全部東西組合起來

中間任何一個環節出問題，整支影片就可能看起來不自然。

例如：

人物嘴巴在動，但聲音對不上
畫面裡杯子掉到地上，卻沒有聲音
人物明明在跑步，腳步聲卻慢半拍
同一個角色換一個鏡頭後，臉就變了
商品在影片裡越動越變形

MiniMax H3 想解決的，就是這種「每一段都由不同工具處理，最後硬拼在一起」的問題。

它希望從一開始，就同時思考：

畫面要怎麼動
人物要說什麼
嘴型怎麼配合
場景裡應該出現什麼聲音
角色和商品要如何保持一致

所以它不只是「把圖片變成影片」，而是更接近：

給 AI 一份導演需求，它直接幫你完成一小段有畫面、有動作、有對話、有聲音的影片。

H3 真正特別的是「控制權」

用一個比較容易理解的比喻。

Seedance 2.5 像高級影片製作公司

你把需求、商品照片、角色圖片、參考影片和音訊交給它。

它的設備更完整，工作人員也安排好了，可以：

幫你做 30 秒影片
處理多鏡頭故事
維持角色一致
修改指定片段
延長影片
製作比較完整的成片

但整個製作過程是在對方公司裡完成。

你看不到真正的機器，也不能改造機器。你能操作的，是平台願意開放給你的功能。

MiniMax H3 像把引擎和部分設備賣給你

目前 H3 的成片功能不一定比 Seedance 2.5 多，影片也比較短。

但你可以：

把權重下載到自己的電腦
在 ComfyUI 本機執行
不透過 MiniMax API 生成 768p 影片
自己換量化版本
修改取樣方式
控制顯存卸載
製作專用工作流
進一步微調模型
將它接入公司的自動化系統

MiniMax 官方釋出的不只是一個網站入口，而是 H3-Base 的實際模型權重；ComfyUI 也已經提供原生本機工作流。

這就是兩者最根本的差別：

Seedance 2.5 給你更強的服務；H3 給你比較多的模型所有權與改造權。

它和之前的 AI 影片工具有什麼不同？

假設你想製作一支咖啡廣告。

你可以準備：

一張咖啡杯的商品照片
一張模特兒的照片
一段你喜歡的運鏡影片
一段旁白聲音
一句文字要求

例如：

女生早晨拿起咖啡，陽光從窗戶照進來，鏡頭慢慢靠近，女生說：「今天，也要從一杯好咖啡開始。」

傳統做法可能需要分別處理人物、商品、運鏡、旁白、嘴型和音效。

MiniMax H3 的方向，則是讓你把這些素材一起交給模型，讓它理解：

這個人要長什麼樣
咖啡杯不能變形
鏡頭要怎麼移動
聲音要用什麼節奏
人物什麼時候開口
畫面和聲音要如何配合

這就是為什麼很多 ComfyUI 使用者開始注意它。

因為 ComfyUI 本來就是一個可以把圖片、文字、影片、音訊，用節點連接起來的工具。MiniMax H3 剛好也是一個很適合接收多種素材的模型。

兩者放在一起，就像：

ComfyUI 是攝影棚的控制台，MiniMax H3 是攝影棚裡的新型全能製作團隊。

MiniMax H3 改變了什麼遊戲規則？

它真正改變的，不只是畫質。

而是讓 AI 影片製作從：

使用很多不同工具，做完後再組合

開始變成：

把完整需求和參考素材交給一個模型，讓它一起生成

這件事帶來了四個很重要的改變。

第一個改變：影片和聲音可以一起生成

以前多數 AI 影片模型主要只負責畫面。

影片生成完之後，你還要另外處理：

配音
音樂
環境聲
嘴型同步
音畫對齊

MiniMax H3 則把聲音也放進影片生成流程裡。

也就是說，它在決定人物如何動的同時，也能一起決定：

人物什麼時候說話
說話的節奏
動作發生時應該出現什麼聲音
畫面和聲音如何對齊

可以把它理解成：

以前是先拍默片，再請人補聲音；現在是拍攝時，畫面和聲音一起完成。

這不代表它每一次都能做到完美，但工作流程確實簡化很多。

第二個改變：你不只可以用文字控制，還可以直接拿素材給它看

過去很多 AI 模型主要依靠文字提示。

你必須很努力地描述：

角色長相
商品造型
場景風格
鏡頭運動
人物動作

但文字很容易產生誤解。

例如你寫：

高級、簡約、有精品感的產品廣告。

每個模型對「高級」和「精品感」的理解都可能不同。

MiniMax H3 的其中一個重要方向，是讓你直接提供參考素材。

例如：

這張圖是主角
這張圖是商品
這段影片是我要的動作
這段聲音是我要的語氣
這張照片是場景風格

這樣就不需要全部靠文字猜。

對一般人來說，可以把它理解成：

與其一直向 AI 形容你想要的東西，不如直接拿範例給它看。

這對商品廣告、品牌角色、虛擬人物和短劇特別重要。

第三個改變：原本只能在大公司雲端跑的模型，現在可以放進自己的工作流程

以前品質比較好的 AI 影片模型，大多是封閉式服務。

你只能到官方網站使用：

不能看到模型本身
不能修改運作方式
不能自己加入特殊功能
不能自由接進公司內部流程
每次生成都依賴平台
平台改價格或限制，你只能接受

MiniMax H3 開放模型權重後，開發者就可以把它放進自己的工具裡。

例如：

放進 ComfyUI
製作自己的工作流
加入其他模型
自己設計節點
使用不同的量化版本
訓練自己的 LoRA
批次生成影片
接進企業內部系統

所以它不只是多了一個 AI 影片網站。

它更像是：

有人把一套原本只能租用的影片製作機器，開放成可以放進自己工廠裡使用。

第四個改變：消費級電腦也開始有機會跑大型影片模型

這是大家最驚訝的地方。

MiniMax H3 本身其實非常大，並不是一個真正只有 16GB 的小模型。

但現在透過幾種技術，可以讓它在 16GB 顯卡上勉強完成生成：

模型壓縮
降低權重精度
把部分模型暫時放到電腦記憶體
不需要的部分先卸載
一小部分、一小部分地處理
將影片分段解碼

這就像你要搬一間倉庫的貨物。

顯卡記憶體是貨車，整個模型是倉庫。

16GB 顯卡的貨車，當然不可能一次裝完整間倉庫的貨。

但你可以：

先載一批貨
運到目的地
卸下來
再回去載下一批

最後還是可以完成工作，只是會比使用大型貨車慢很多。

所以「16GB 顯卡可以跑 MiniMax H3」真正的意思不是：

整個模型只有 16GB。

而是：

模型可以分批進入顯卡，讓顯卡在任何一個時間點，都不要超過 16GB。

為什麼有人用 5070 16GB 就可以跑？

這裡也要先澄清一個常見說法。

一般桌機版的 RTX 5070 通常是 12GB，16GB 的版本多半是在說 RTX 5070 Ti。

但不論是 5070 Ti 16GB，還是其他 16GB 顯卡，它能跑 MiniMax H3，都不是因為模型很小。

而是因為 ComfyUI 會幫忙管理記憶體。

簡化後的執行方式大概像這樣：

先讀懂文字和參考圖片
        ↓
把理解結果暫時保存
        ↓
卸載剛剛使用的模型
        ↓
載入影片生成模型
        ↓
開始生成影片
        ↓
卸載影片生成模型
        ↓
載入影片與聲音解碼器
        ↓
輸出最後結果

這些模型不是全部同時塞進顯卡。

而是輪流進場。

就像一間很小的攝影棚，沒有辦法讓所有工作人員同時站在裡面，所以：

編劇先進來完成腳本
編劇離開
攝影團隊再進來拍攝
攝影團隊離開
剪輯和音效團隊最後進來

雖然空間小，但只要安排好進場順序，還是能把影片做完。

代價就是速度比較慢。

所以 16GB 顯卡能跑，實際體驗是什麼？

「能跑」和「跑得舒服」是兩件不同的事。

16GB 顯卡通常代表：

可以成功開始生成
可以製作較短的影片
可以使用較低記憶體版本
需要不少系統記憶體
模型會在記憶體和顯卡之間頻繁搬動
生成時間可能比較長
解析度越高，等待越久
影片秒數越長，負擔越大
同時放很多參考素材，也會增加壓力

因此，網路上有人說：

我的 16GB 顯卡可以跑 H3。

這句話可能是真的。

但它不一定代表：

可以快速生成
可以直接跑 2K
可以一次做十五秒長片
可以同時放很多參考影片
可以邊生成邊做其他工作
所有設定都能開到最高

比較準確的說法應該是：

16GB 顯卡讓一般人有機會在本機使用 H3，但通常要用速度換記憶體。

為什麼最近很多 ComfyUI 專案開始使用 MiniMax H3？

因為它剛好符合 ComfyUI 使用者最需要的幾件事。

第一，它可以直接放進節點工作流

ComfyUI 最強的地方，是可以把不同素材像積木一樣連接。

例如：

人物照片 ───┐
商品照片 ───┤
動作影片 ───┼→ MiniMax H3 → 完整影音
參考聲音 ───┤
文字要求 ───┘

這種使用方式比只在網站上輸入一句文字，更適合進階創作者。

第二，一套模型可以處理更多工作

過去可能需要分別安裝：

圖生影片模型
角色一致性模型
動作控制模型
嘴型同步工具
語音工具
音效工具

現在 MiniMax H3 有機會把其中幾個步驟合併。

它不一定完全取代所有專業工具，但可以讓工作流變得更短、更容易管理。

第三，開發者可以自己改

只要模型能在本地使用，社群就會很快開始做各種優化，例如：

更省顯存的版本
更快的版本
四步生成版本
LoRA 支援
多顯卡支援
更好的聲音同步
更方便的參考圖節點
商品一致性工作流
短劇工作流
廣告影片工作流

所以最近看到很多 H3 專案，部分原因不是它已經完美，而是它提供了很大的改造空間。

一句話總結 MiniMax H3

MiniMax H3 最值得注意的地方，不只是「畫質很好」。

而是它把過去分散在很多工具裡的工作，開始放進同一個模型：

它可以同時理解文字、圖片、影片和聲音，並且一起生成有畫面、有動作、有對話、有音效的影片。

再加上模型可以放進 ComfyUI，並透過量化與記憶體卸載，在 16GB 顯卡上運行，才會造成最近這一波關注。

所以它真正改變的遊戲規則是：

過去一般人只能租用大型公司的 AI 影片服務；現在一般創作者開始有機會，把接近前沿等級的影音生成能力，放進自己的電腦和工作流程裡。

後面再接原本的「H3 有哪些版本」、「FL2VA 與 Ref2VA 差異」、「模型檔案大小」和「技術原理」，讀者就會比較容易跟得上。

先把名稱與版本拆清楚

截至 2026 年 8 月 7 日，官方名稱是 MiniMax H3。它不是「Hailuo 2.3 的小改版」，而是 MiniMax 影片生成產品線的新一代架構。H3 在 7 月 31 日發布，並於 8 月 3 日開放模型權重；ComfyUI 核心支援也幾乎同步合併，所以你最近突然看到大量 H3 workflow，並不是錯覺。(Minimax)

官方目前的命名可以分成三個層次：

一、產品世代

Hailuo 01
Hailuo 02
Hailuo 2.3／2.3 Fast：上一代 API 模型
MiniMax H3：目前最新一代

所以社群有時會稱它為「Hailuo 3」，但官方正式名稱仍是 MiniMax H3。(ComfyUI Newsletters)

二、目前開放權重的兩個 H3-Base checkpoint

版本	主要用途	輸入方式
H3-Base-FL2VA	文字轉影片、圖生影片、首尾幀控制	0 張圖是 T2V；1 張可作首幀或尾幀；2 張是首尾幀
H3-Base-Ref2VA	多參考圖、多參考影片、音訊參考	最多 9 張圖、3 段影片、3 段音訊，混合總數最多 12 個檔案

其中 VA 指的是 Video + Audio。H3 不是先生成影片，再另外跑配音或音效，而是在同一個生成過程中共同預測影像與立體聲音訊。官方輸出規格包含約 4～15 秒、24 FPS、32 kHz stereo audio，並支援多種比例與對話語言。(Hugging Face)

三、完整商業版 H3 系統其實有三個模組

模組	功能	是否已完整開放
H3-Context-IR	理解文字、圖片、影片、音訊，整理成模型較容易執行的上下文	否，目前由 MiniMax 雲端服務處理
H3-Base	生成約 768p 的影片與音訊	是，FL2VA／Ref2VA 已開放
H3-Regenerate-2K	根據原始上下文與 768p 結果重新生成 2K，而非單純超解析	否，目前未開放權重

這點很重要：你在本機 ComfyUI 跑到的是 H3-Base，不是完整的 MiniMax 雲端 H3 pipeline。 本機可以嘗試更高解析度，但它不等於官方的 Context-IR 加 Regenerate-2K 流程。(Hugging Face)

H3 真正改變了哪些遊戲規則？

1. 從「影片模型」變成「多模態場景模擬器」

過去常見工作流程是：

圖片模型 → 圖生影片 → 嘴型同步 → TTS → 音效 → 背景音樂 → 剪輯合成

H3 的設計則比較接近：

文字＋圖片＋影片＋音訊參考 → 統一理解 → 同時生成影片與聲音

H3 把文字、參考圖、參考影片、音訊、影片 latent 包進同一條 sequence，再透過一個 33B dense single-stream H3-Omni-Transformer 共同生成影音。這讓「角色動作、嘴型、環境聲、對話節奏」有機會在同一個時間軸上被協調，而不是由五六個模型事後拼接。(Hugging Face)

這是它最重要的規則改變：音訊不再只是影片生成完成後的附加層，而是生成內容本身的一部分。

2. 參考素材變成真正的控制語言

Ref2VA 不只是「上傳一張角色圖片」。它可以同時接收：

人物外觀參考
商品外型參考
場景或美術風格
另一段影片的運動方式
語音、節奏或聲音參考

這代表創作者不必把所有要求硬塞進 prompt，可以直接用素材告訴模型：

角色長這樣、產品長這樣、攝影機這樣動、聲音是這種節奏。

對廣告、商品展示、虛擬人物、短劇和 MV workflow 特別重要，因為它降低了純文字 prompt 的不確定性。(Hugging Face)

3. 接近前沿品質的影音模型，第一次真正進入本機工作流

H3 核心權重可以下載、量化、剪枝、建立 LoRA、修改 sampler、做自訂節點。這與只能透過 API 呼叫的封閉模型不同。

截至 2026 年 8 月 7 日，Artificial Analysis 的盲測排名中，H3 在文生影片與圖生影片均屬於表現最前面的開放權重模型，在帶音訊的影片編輯項目也位居整體前列。排名會持續變動，但至少說明 H3 並不是只有「開放」而畫質明顯落後的模型。(Artificial Analysis)

4. 2K 不再只是事後放大

H3-Regenerate-2K 的概念不是傳統：

768p 影片 → 超解析放大 → 2K

而是：

原始文字與所有參考素材＋768p 生成結果 → 再生成一次 2K

因此第二階段仍然能重新理解文字、商品、角色和場景，而不是只對像素做銳化。不過這個官方模組目前尚未開放，所以本機 workflow 與官方雲端的 2K 結果仍應分開看待。(Hugging Face)

為什麼 16GB 顯卡也能跑？

首先要修正一個常見稱呼：

桌機版 RTX 5070 是 12GB；
RTX 5070 Ti 才是 16GB。

因此你看到的「5070 16GB」，大多實際上是 RTX 5070 Ti 16GB。(NVIDIA)

更重要的是：16GB 可以完成推理，不代表整套模型只有 16GB，也不代表模型全部同時放在顯存。

原始模型其實非常大

H3 本機 pipeline 的主要檔案大致如下：

部件	完整精度版本	低記憶體版本
H3 Transformer	BF16 約 66.3GB	Pruned INT8／FP8 約 21GB
Qwen3-VL-32B 文字與多模態編碼器	BF16 約 51.5GB	NVFP4 AWQ 約 15.7GB
Video VAE	約 5.21GB	約 5.21GB
Audio VAE	約 0.605GB	約 0.605GB
合計	約 123.6GB	約 42.5GB

也就是說，最小的官方 ComfyUI 組合仍然約 42.5GB，遠大於 16GB。(Hugging Face)

之所以能跑，靠的是四層優化

1. 把約 40% 的調制參數預先計算

H3 的 33B Transformer 中，大約有 13B 參數位於 AdaLN 調制分支。推理時，這些輸出可以預先計算成 curve table，不必讓全部 13B 參數常駐模型。

因此 ComfyUI 提供了 pruned 版本：

原始 BF16 Transformer：約 66.3GB
Pruned BF16：約 40.2GB
Pruned INT8／FP8：約 21GB

這不是普通的「隨便砍掉 40% 權重」，而是利用 H3 本身的架構特性，把推理時可預先計算的部分換成查表。MiniMax 模型卡與 ComfyUI 都明確說明了這個設計。(Hugging Face)

2. 權重量化

ComfyUI 目前已提供多種包裝：

BF16
INT8 ConvRot
Pruned BF16
Pruned INT8 ConvRot
Pruned FP8 Scaled
Qwen3-VL NVFP4 AWQ

所以大家口中的「H3 版本很多」，許多其實不是不同能力的模型，而是同一個 checkpoint 的不同精度與記憶體配置。(Hugging Face)

3. 分階段載入，而不是所有模型一起進顯存

實際執行大致是：

Prompt／參考素材
        ↓
載入 Qwen3-VL encoder
        ↓
轉成 conditioning embeddings
        ↓
卸載或部分卸載 encoder
        ↓
載入／串流 H3 Transformer 進行採樣
        ↓
卸載 Transformer
        ↓
載入 Video VAE／Audio VAE 解碼

因此：

15.7GB 的文字編碼器不必和 21GB Transformer 永久同時存在。
不使用的模型可以移到系統 RAM。
Transformer 不一定完整放入 VRAM，可以逐 block 在 RAM 與 VRAM 之間搬移。
VAE 解碼採用 spatial tiling 與 temporal chunking，避免一次解碼整段高解析影片。

ComfyUI 將這套機制稱為動態 VRAM offloading，並表示最低甚至可在 RTX 3060 等級顯卡上啟動；但顯存越少，RAM 和 VRAM 之間搬運越頻繁。(ComfyUI Newsletters)

4. 用速度換記憶體

這是最容易被影片標題省略的部分。

「16GB 能跑」通常代表：

可以完成生成
可能需要大量系統 RAM
會頻繁 CPU offload
PCIe 傳輸成為瓶頸
生成時間通常以分鐘計，而不是即時
解析度、影片秒數和 frame 數提高後，速度與記憶體需求會快速增加

所以 5070 Ti 16GB 跑一段較短的 768p 影片，和流暢跑 15 秒、2K、多參考影音，是完全不同的概念。

一張 16GB 卡能執行 H3，真正含義是：

模型的 peak VRAM 被控制在 16GB 左右，而不是整個 42.5GB pipeline 被塞進 16GB。

為什麼最近大量 ComfyUI 專案開始採用 H3？

1. MiniMax 開放權重與 ComfyUI 原生支援同時發生

H3 權重在 2026 年 8 月 3 日開放，ComfyUI core 的 H3 支援也在同一天合併。它不是靠一個半成品 community wrapper 勉強執行，而是直接進入核心架構，包括：

H3 模型載入
音訊與影片共同採樣
H3 專用 VAE
Qwen3-VL encoder
INT8 fused kernel
Pruned AdaLN table
官方 workflow 範例

因此節點作者不必每人重新寫一套底層模型載入器。(Minimax)

2. 一個模型可以取代原本多條 workflow

過去 ComfyUI 影片專案可能要串接：

圖生影片模型
identity reference
動作 transfer
lipsync
TTS
Foley／SFX
音訊混合
影片後製

H3 原生同時處理影音後，許多工作流可以被縮短。它不一定在每一項都勝過專用模型，但整體的一致性與可維護性更高。

對 ComfyUI 作者而言，這代表一個 H3 workflow 可以延伸成：

商品廣告
角色短劇
有聲 AI 動畫
音樂視覺
動作參考影片
首尾幀轉場
多角色 reference
影片重新演繹

而不必維護五六套完全不同的模型鏈。

3. H3 的輸入形式非常適合 node graph

ComfyUI 最擅長的就是把不同素材接成節點，而 H3-Ref2VA 剛好允許圖片、影片和音訊混合輸入。

因此工作流很容易被視覺化成：

角色參考圖 ─┐
商品參考圖 ─┤
動作影片 ───┼→ H3 Ref2VA → 影音結果
語音參考 ───┤
文字指令 ───┘

這比「全部要求寫進一個超長 prompt」更符合 ComfyUI 使用者的操作習慣。

4. 它提供了極大的社群優化空間

模型開放後短短幾天，社群便開始出現：

4-step Turbo LoRA
H3 LoRA 載入與轉換工具
Dual-clock video/audio sampler
音訊修復與同步節點
更低精度量化版本
多 GPU 與 CPU offload workflow

例如部分社群 Turbo LoRA 嘗試把原本約二十步的生成壓縮到四步；另外也有人開發 video 與 audio 使用不同噪聲時鐘的 dual-clock sampler，以減少低步數時的音訊雜訊。不過這些屬於非常早期的第三方實驗，不能直接視為官方品質保證。(GitHub)

5. 本地部署讓大量反覆測試變得可行

影片工作流通常不是生成一次，而是反覆修改：

Seed
Prompt
首尾幀
角色參考
動作影片
音效
LoRA
Sampler
CFG
長度與解析度

API 每次都要排隊、上傳素材與計費；本地 H3 即使比較慢，對大量測試、批次製作、內部素材、隱私內容和自訂模型仍有吸引力。

目前最容易被誤解的四件事

「16GB 可以跑」不等於「H3 是 16GB 模型」

最小常用組合約 42.5GB，只是透過量化、分階段載入、RAM offload 和 tiled VAE，把峰值顯存壓低。

「ComfyUI 可以設 2K」不等於「本機擁有官方 H3-Regenerate-2K」

官方 2K regeneration 模組目前沒有開放。直接提高本機採樣解析度，和官方的 in-context 2K regeneration 不是同一條 pipeline。(Hugging Face)

「開放權重」不完全等於傳統開源軟體

H3 使用的是 MiniMax H3 Community License，不是一般 OSI 開源授權。條款目前列出美國、歐盟、英國與南韓等排除區域，年營收超過 2,000 萬美元的商業組織也需要另外取得授權。台灣目前未被明列於排除區域，但商用前仍應依最新版條款確認。(Hugging Face)

「四步 Turbo」不等於官方完整品質

Turbo LoRA、低位元量化、極低步數和激進 offload 都可能交換速度、穩定度、音訊品質或細節。展示影片能成功，不代表每一種輸入、長度和解析度都同樣穩定。

最后的總結

MiniMax H3 真正重要的地方，不只是「又有一個畫質更好的影片模型」，而是它把這幾件事同時湊齊了：

前沿等級畫面＋原生影音共同生成＋多模態參考控制＋開放權重＋ComfyUI 原生支援＋消費級顯卡可透過 offload 執行。

所以它目前更像是 ComfyUI 影音領域的一個新「底層平台」，而不只是另一個 T2V checkpoint。

5070 Ti 16GB 能跑，是記憶體工程的勝利；大量專案開始採用，則是因為 H3 把原本分散在影片、語音、音效、嘴型、reference 和 editing 的多條工作流，第一次有機會收進同一套可程式化、本地可修改的模型架構裡。

拆解 FDE 商業變現與 AI 落地法則， 2026 版本

noreply@blogger.com (Caesar Chi) — Mon, 20 Jul 2026 01:45:01 +0800

發布日期 2026/07/20，以下內容是搜集了許多高手， FDE，老闆，以及各家已經深入整合到各家廠商，甲方乙方丙方等角色來進行整合的資訊，讓大家更深入來探討， FDE 該是什麼，不該是什麼，可以是什麼的整體描述文章。

大家有任何看法歡迎加入 AI For Developer 群組來討論，

加入「AI for Developer」！請點選以下連結加入社群！

https://line.me/ti/g2/D2m1DA83Qb0KJCjd2mLyHD7y4yB1CA0WUJsOMA?

從 Palantir、OpenAI、Anthropic 到 AWS，企業真正缺的不是更強的模型，而是有人能把模型變成可驗收的業務結果

本文資料截至 2026 年 7 月 19 日。

科技業一邊裁員，一邊出現了一個逆勢升溫的職位：FDE，Forward Deployed Engineer，中文常譯為「前線部署工程師」，也有人直接稱它為「AI 落地工程師」。

根據 Indeed 提供給《Business Insider》的資料，FDE 相關招聘指數在 2025 年 4 月到 2026 年 4 月間約成長 729%。

不過，這裡必須先修正一個被大量轉載的誤會。

早期報導把 643 與 5,330 寫成實際職缺數量，《Business Insider》後來已經更正：這兩個數字其實是相對於 2025 年 1 月基準的指數值，不是平台上的個別職缺筆數。可以引用的是 729% 的年增幅，不能再把 643 個與 5,330 個當成真實職缺數。(businessinsider.com)

但比職缺成長更重要的問題是：

FDE 跟傳統平台客製化有什麼差別？

這麼高密度的人力投入，客戶究竟怎麼付錢？

AI 系統又該怎麼驗收？

FDE 要不要扛業績，會不會領業績獎金？

它跟 founder mode 有什麼不同？

一個既懂程式、流程、商業，又能處理客戶的人，為什麼還需要公司？

這些才是 FDE 商業模式真正困難、也真正值得討論的地方。

先說結論：FDE 的價值不在於替每個客戶寫更多客製程式，而在於縮短「模型能力」與「可驗收業務結果」之間的距離。

FDE 到底是什麼？

一句話定義：

FDE 是把工程能力帶進客戶真實環境，將 AI、資料與軟體接進業務流程，並對生產環境結果負責的混合型角色。

要判斷一個職位是不是真正的 FDE，可以問三個問題：

第一，他是否親自撰寫或修改生產環境的程式？

第二，他是否深入客戶真實的資料、權限、流程與組織？

第三，他是否對上線後的採用、穩定性與業務結果負責？

三個問題都回答「是」，才比較接近真正的 FDE。

OpenAI 對自己的 FDE 定義也很接近。其舊金山職缺要求 FDE 負責需求發現、技術範疇、系統設計、建置及正式上線，並以生產採用、可衡量的工作流程影響，以及能改變產品與模型路線圖的評估回饋衡量成敗。該職缺同時要求最多約 50% 的差旅，薪資區間為 16.2 萬至 28 萬美元底薪，另加股權。(OpenAI)

這也解釋了 FDE 為什麼昂貴。

公司買的並不只是程式能力，而是下面這組非常稀缺的組合：

能進入模糊現場，理解真正的工作方式；能在不完整資料與舊系統中完成整合；能與高管、IT、資安、法務和一線員工溝通；能在期限壓力下做出工程取捨；還能在系統出錯時承擔第一線責任。

FDE 不是傳統軟體工程師、顧問、產品經理或售前工程師中的任何一種。

他是這幾種責任的交集。

為什麼偏偏在 AI 時代變得重要？

FDE 並不是 2026 年才出現。Palantir 很早就把工程師直接派進政府與大型企業現場，並將這種模式制度化。

真正改變的是，企業 AI 已經集體撞上了一堵「整合之牆」。

模型展示通常不難。

接一個 API、做一個聊天介面、放幾份文件、跑一個 RAG，往往幾天內就能做出漂亮的展示。

但一進生產環境，問題立刻出現：

資料分散在不同系統；權限模型互不相容；舊系統沒有可靠 API；合規要求完整稽核；員工不願意改變工具；模型偶爾答錯，卻沒有人工兜底；Agent 會呼叫工具，但沒有人定義它能動哪些資料、什麼時候必須停下來。

這些問題不能只靠更長的 prompt，也不能只靠換一個更強的模型解決。

Box 公開過一個很具代表性的案例。某客戶想讓 AI 判斷醫療圖表中是否出現特定保險事件，最初準確率約為 70%，客戶以為需要換模型。團隊深入實際作業後，才發現問題主要來自缺少企業內部的隱性規則。例如在該客戶的業務定義中，電動滑板車事故也應被歸入特定機動車事故。補入這些現場知識後，準確率超過 90%。Box 的結論是，企業 AI 最常缺少的不是模型能力，而是流程脈絡、資料結構、評估方法，以及判斷哪些步驟應交給 AI、哪些應使用確定性程式、哪些必須由人處理。(Box Blog)

也因此，模型公司開始往部署端移動。

2026 年 5 月 11 日，OpenAI 成立 OpenAI Deployment Company，初始投資超過 40 億美元，並同意收購 Tomoro，預計帶入約 150 名 FDE 與部署專家。官方描述的典型合作方式，是先診斷高價值機會，再與客戶選出少數優先工作流程，由 FDE 進入組織完成設計、建置、測試與生產部署。(OpenAI)

2026 年 5 月 4 日，Anthropic 也宣布與 Blackstone、Hellman & Friedman、Goldman Sachs 等機構成立新的企業 AI 服務公司，鎖定社區銀行、中型製造商與區域醫療體系等缺乏內部 AI 工程資源的企業。Anthropic 的 Applied AI engineers 將與新公司及客戶團隊共同找出高影響流程、建置客製系統並提供長期支援。(Anthropic)

2026 年 6 月 30 日，AWS 又宣布投入 10 億美元建立 Forward Deployed Engineering 組織，計畫讓數千名工程師直接與客戶共同開發 Agent 系統。AWS 特別強調，交付目標不是創造永久依賴，而是留下可運作系統、可複用的部署方法，以及客戶能自行延伸的能力。(Amazon Web Services, Inc.)

這些公司並不是突然想轉型成顧問公司。

它們是在承認一個現實：

模型只是原料。真正昂貴的部分，是把原料接進企業每天運作的系統。

FDE 跟傳統平台客製化，真正差在哪裡？

表面上看，兩者都會做整合、設定權限、串接系統，甚至撰寫客製程式。

真正的差異不在於「有沒有寫客製程式」，而在於三件事：

第一，問題是否已經被定義清楚

傳統客製化通常從明確需求開始。

客戶會說：「請增加這個欄位」、「請串接這個 ERP」、「請做一個簽核流程」。

FDE 面對的問題往往是：

「我們想用 AI 提高效率，但不知道哪個流程最值得先做。」

所以 FDE 的第一個重要產出，常常不是程式，而是更準確的問題定義。

他要把「做一個企業 Agent」縮小成可執行的目標，例如縮短客服處理時間、降低索賠分類錯誤、減少人工報表工時，或者提高某個審核流程的直通率。

第二，驗收對象不同

傳統客製化通常驗收功能是否符合規格。

FDE 專案則必須驗收系統是否真的進入工作流程、能否在真實資料與權限下穩定運作，以及是否產生可以衡量的結果。

一個 AI 系統即使完全符合功能規格，只要沒有人使用、錯誤率太高、人工審核沒有下降，或每次使用都比人工更昂貴，就不能算成功。

第三，複雜度最後留在哪裡

這是最核心的差異。

傳統接案模式做完一個專案，複雜度通常留在客戶專案裡。下一個客戶來了，再重新做一次。

健康的 FDE 模式則要求每次部署中重複出現的連接器、權限流程、資料模型、評估集、監控方法與治理機制，逐步回流成公司的平台能力。

AWS 把這件事稱為可複用的 delivery harness，其中可能包含領域資料模型、評估框架、MCP server、Agent 營運工具，以及記錄架構選擇與判斷脈絡的 context graph。(Amazon Web Services, Inc.)

真正的 FDE，不是把公司變成更昂貴的接案商，而是把客戶現場當成產品學習與標準化的入口。

因此，判斷一家公司是不是真的在做 FDE，不要只看職稱。

要看它是否允許工程師寫生產程式、是否深入真實流程、是否對上線結果負責，以及現場經驗能不能反過來改變核心產品。

FDE 每天實際在做什麼？

一個完整的 FDE 專案，大致會經過三個階段。

第一階段：先看工作怎麼發生，而不是先問想做什麼功能

企業文件裡的 SOP，經常只是理想流程。

真實流程可能是銷售只填了一半資料，營運在 Excel 補欄位，財務透過通訊軟體催發票，最後再由某個資深員工把資訊手動同步到 CRM。

假如只照文件開發，很容易做出一套完全符合規格、卻沒有人願意使用的系統。

所以好的 FDE 會先觀察一線人員如何工作：

資料從哪裡來？誰在做判斷？哪些步驟經常被繞過？哪些規則從來沒有寫在文件裡？哪一種例外只有某個老員工知道怎麼處理？

FDE 要找的不是表面需求，而是流程裡真正消耗時間、產生錯誤或阻礙決策的地方。

第二階段：建置、整合與評估

這才進入大家熟悉的工程部分。

FDE 可能需要建資料管線、處理 OAuth、SAML、權限、日誌與稽核，串接 CRM、ERP、工單、郵件或內部舊系統。

AI 部分則可能包含 RAG、Agent、工具呼叫、模型路由、提示設計、評估集、人工覆核與失敗升級。

企業環境很少是乾淨的。

API 文件可能三年沒更新；欄位可能來自三套互相衝突的系統；IT 可能不願意開放生產憑證；相同交易可能因重試被執行兩次。

因此，真正的工作常常不是「讓 Agent 看起來很聰明」，而是處理重試、幂等、死信佇列、權限最小化、資料遮蔽、回滾和人工兜底。

第三階段：上線、穩定、交接與撤離

系統跑起來，不代表專案已完成。

FDE 還要確認一線人員是否真的使用，例外是否能被處理，成本是否在可接受範圍內，客戶團隊是否知道怎麼監控與維護。

最後還要把專案中出現的重複模式帶回產品團隊。

真正完成部署的標準，不是 FDE 可以離開，而是 FDE 離開後，系統仍能安全地工作。

這也是 FDE 和永久駐場顧問最大的分界。

FDE 到底應該怎麼收費？

這是最容易混淆的問題。

因為 FDE 是一種交付角色，不是一種固定商業模式。

平台公司、模型公司、顧問公司、系統整合商與獨立 FDE agency，都可能使用這個角色，但它們的獲利方式不會相同。

Palantir 的版本：前期可以虧，後期靠平台規模回收

Palantir 早期公開文件曾將客戶經營分為 Acquire、Expand 與 Scale 三個階段。

在 Acquire 階段，公司可能以免費或低價試點降低客戶風險，並自行吸收部署成本；Expand 階段繼續投入人力，深入理解客戶核心問題，帳戶仍可能虧損；到了 Scale 階段，平台使用範圍擴大，客戶逐漸能自行開發與營運，投入成本相對下降，帳戶才開始產生正向貢獻。

這種模式的核心，不是靠 FDE 的工時本身賺錢。

而是用前期部署投入，換取後續的平台授權、使用量、續約與擴張。

但要注意，這只是 Palantir 這類平台公司的商業模式，不能直接推論成「所有 FDE 服務都必須前期虧損」。

一間沒有大型平台收入的顧問公司或 FDE agency，仍然可以做真正的 FDE 工作，只是它必須讓部署服務本身具備合理毛利。

所以更精確的說法是：

是不是 FDE，要看交付責任；能不能規模化，要看現場複雜度是否能回流成平台資產。

比較合理的 FDE 合約，應該是混合收費

我不建議單純按人天，也不建議整份合約都採純成果制。

比較可行的是把一個專案拆成四種不同性質的費用。

第一部分：診斷費

先用固定費用完成流程盤點、資料盤點、權限與風險分析、基準值建立，以及第一個高價值工作流程的選擇。

這個階段的交付，不應只是簡報。

客戶至少要知道：

目前流程成本是多少、資料能不能取得、系統能不能整合、哪些風險不能接受，以及第一版成功的定義是什麼。

第二部分：建置與整合費

這部分可以採固定里程碑價格，或以專屬 deployment pod 的月費計價。

計價內容涵蓋原型、資料整合、權限、評估、影子模式、正式部署與監控。

這部分不宜完全與業務成果綁定，因為工程投入確實已經發生，而且許多外部條件不是供應商能控制的。

第三部分：平台與用量費

系統正式運作後，依平台授權、模型 token、工作流程執行次數、Agent 行動量或基礎設施成本持續計費。

這是平台型 FDE 模式能夠規模化的主要來源。

理想狀態下，第二個、第三個相似客戶需要的現場工程時間會下降，但平台與使用收入會上升。

第四部分：成果保留款或成果獎金

可以把總費用的一小部分，例如示意性的 10% 至 20%，放在上線 30、60 或 90 天後，依事前約定的成果支付。

這樣既能支付實際工程投入，也能讓供應商對採用與成果保持責任。

固定費用支付工程工作，成果部分用來對齊雙方利益。

成果計價的關鍵，不是喊「按效果付費」，而是把效果寫得足夠細

Sierra 的 AI Agent 採成果計價，會把已解決的客服對話、挽回取消、追加銷售等定義成可收費結果；如果案件未解決或需要升級給真人，通常不收成果費。Sierra 也指出，不適合明確成果判定的流程，可以改採用量或混合計價。(Sierra)

Intercom 的 Fin 更把計價事件寫得很明確：同一段對話最多收取一次成果費；如果使用者要求真人、流程執行失敗，或系統未真正完成結果，就不計入相應成果。即使一度被判定為完成，使用者後來在同一段對話中重新求助，也可能撤銷該筆成果。(Intercom)

這對 FDE 合約有直接啟示。

成果計價前，雙方必須先回答幾個問題：

分母是什麼？
是所有案件、符合條件的案件，還是 AI 實際接手的案件？

什麼叫成功？
是 AI 產生答案、完成一項操作，還是後端系統真的更新成功？

多久內重新發生算失敗？
同一問題在 24 小時或 7 天內重開，要不要扣回？

人工介入怎麼計算？
正常核准、AI 主動升級與系統故障，不能混在一起。

哪些情況可以排除？
例如客戶沒有提供資料、權限延遲、政策中途變更或第三方系統中斷。

以哪個系統的資料為準？
CRM、工單、ERP、財務系統或第三方監控，必須指定唯一的結算依據。

不能被客觀記錄與稽核的成果，就不適合拿來計價。

AI 系統到底該怎麼驗收？

傳統系統整合常用功能清單驗收。

規格書列出一百項功能，UAT 一項一項打勾，全部完成後簽收付款。

AI 系統不能只用這種方法。

因為 AI 輸出帶有機率性，同一個功能「能執行」，不代表每次執行都可靠，也不代表執行成本合理。

一個完整的驗收流程，至少應該分成六道門。

第一關：先凍結基準值

在寫程式以前，先記錄目前的流程表現。

例如平均處理時間、錯誤率、人工工時、案件積壓、轉人工比例、每筆交易成本與客戶滿意度。

沒有基準值，就無法證明改善。

而且不能等系統上線後才回頭找歷史數據，否則雙方很容易對分母與計算方式產生爭議。

第二關：共建評估資料集

客戶的領域專家必須參與建立 eval dataset。

資料集除了正常案例，也應包含邊界案例、資料缺失、互相矛盾的文件、惡意輸入、工具呼叫失敗與高風險例外。

驗收不能只看一個平均正確率。

在醫療、金融或合規流程中，少數高風險錯誤的代價，可能遠高於大量普通案例答對所創造的價值。

第三關：影子模式

系統在真實環境中運作，但暫時不自動改動正式資料。

AI 先產生建議，再與人類實際決策比較。

這個階段可以觀察真實資料分布、延遲、錯誤類型、模型漂移、用量與成本，又不會直接傷害客戶。

第四關：受限生產

先限制部門、地區、案件類型、金額或使用者。

高風險操作保留人工核准，同時提供日誌、回滾、kill switch、重試與重複執行防護。

這一關驗的不只是模型，而是整個系統能不能安全地失敗。

第五關：營運與業務驗收

上線後 30、60、90 天持續檢查：

實際使用率有沒有提高？人工處理時間是否下降？錯誤或重工是否減少？每個成功任務的完整成本是多少？需要修正與轉人工的比例是否持續改善？

OpenAI 在 2026 年 7 月 17 日提出的 AI 衡量框架，將重點放在四個問題：完成了多少有用工作、每個成功任務的完整成本、結果有多可靠，以及規模擴大後每一美元是否能換到更多成果。它也建議將結果區分為可直接使用、需要修正，以及必須轉交人員處理。(OpenAI)

這比單純計算 token、登入人數或模型準確率更接近真正的商業價值。

第六關：交接與撤離驗收

最後必須確認客戶團隊能不能自行處理日常營運。

監控、文件、教育訓練、事故處理、模型或提示更新、權限變更與成本控制，都應有明確的負責人。

FDE 的撤離能力，本身就是交付品質的一部分。

真正要驗收的是整條結果鏈

John Deere 的 See & Spray 技術利用 36 個相機與機器學習辨識雜草，只對需要的位置噴灑藥劑，官方案例指出最多可降低約 70% 的化學品使用。(OpenAI)

但技術具備這項能力，不代表客戶一定能得到同樣結果。

農民還需要學會設定設備、規劃季節、調整速度、清潔相機，並理解什麼時候應使用這項功能。

因此，John Deere 將 AI 放進整個客戶成功流程：

購買後提供個人化設定建議；季節開始時提醒設備使用情況；發現設備切回傳統噴灑時，協助判斷是高度、速度還是相機清潔問題；季末再產出個人化 ROI 報告，呈現節省的藥劑與效率改善，支援續約決策。(OpenAI)

這個案例不代表 70% 的減量全部由某一名 FDE 創造。

它真正說明的是，AI 部署不能只驗收模型或功能，而應該驗收完整的結果鏈：

技術能力 → 正確設定 → 實際使用 → 異常處理 → 成效證明 → 持續付費。

一名 FDE 能不能同時顧四、五個案子？

可以同時覆蓋四、五個客戶，但不適合同時親自扛四、五個深度建置案。

這兩件事必須分開。

OpenAI 的職缺確實要求 FDE 負責多個部署，但同時也要求深入客戶、撰寫全端系統、推動採用，並可能有高比例差旅。(OpenAI)

因此，比較健康的配置是：

一個主要建置案、一個剛上線的穩定期案，再加一至兩個只處於診斷或前期設計的案子。

也就是說，FDE 的帳面客戶數可能有三至四個，但真正高強度的建置工作，同一時間最好只有一個。

此外，FDE 不應被設計成孤立的全能英雄。

比較合理的單位是一個 deployment pod，由一名主要 FDE 搭配平台或後端工程師，再按需求共用資料、資安、領域專家與產品資源。

否則需求訪談、前端、後端、模型、資料、權限、簡報、教育訓練與事故處理全部集中在同一個人身上，短期看起來速度很快，長期卻會造成過勞、關鍵人風險與無法維護的客製系統。

FDE 到底要不要扛業績？

市場沒有統一答案，因為「FDE」這個職稱已經開始膨脹。

OpenAI 的官方職缺將成功定義為生產採用、可衡量的工作流程影響，以及能改變產品與模型路線圖的評估回饋。其公開薪酬是底薪加股權，沒有把銷售配額列為主要成功標準。(OpenAI)

但市場上也確實存在被放在 Sales 或 GTM 組織中的 FDE。

例如 StackAI 的醫療 FDE 職缺隸屬 Sales，薪資包含股權與佣金；E2B 的 FDE 隸屬 GTM，也公開提供佣金。(Ashby)

因此，不能簡化成「真正的 FDE 一定沒有佣金」，也不能看到 FDE 職稱就認定它一定是售後工程職。

比較好的判斷方式，是看工作的主要責任：

如果大部分時間在做售前展示、推進成交、建立 pipeline，PoC 完成後就交給別人，那比較接近 solutions engineer。

如果要深入客戶環境、撰寫生產程式、負責上線與採用，並把現場模式回饋產品，即使有少量商業獎金，仍可能是真正的 FDE。

佣金是一個需要進一步確認的訊號，但不能單獨判定職位真假。

FDE 應該扛的是結果責任，不是簽約配額

我的判斷是，FDE 應該對客戶成果負責，但不應以個人簽約金額作為主要 KPI。

原因很直接。

客戶可能要求一個技術上不合理、資安風險過高，或根本不值得做的功能。

假如 FDE 的主要收入來自成交佣金，他就同時扮演技術把關者與促成交易者，容易產生利益衝突。

客戶也會開始懷疑：

你是真的認為這個方案適合我，還是只是想完成業績？

比較健康的設計，是把營收責任放在帳戶負責人、業務或 deployment strategist 身上，把生產結果責任放在 FDE 身上。

兩者可以使用相同的客戶成果指標，但不必採用相同的獎金結構。

一套可落地的 FDE 考核方式

以下權重不是市場統一標準，而是一個可實際採用的示例。

30%：生產採用與業務成果

衡量系統是否真的被使用，以及是否改善時間、成本、錯誤、收入、風險或客戶體驗。

不能只看登入人數，也不能只看 PoC 展示是否成功。

25%：可靠性、安全與品質

衡量評估通過率、事故數量、人工介入率、回滾能力、權限與稽核完整性。

FDE 不只要把系統做出來，也要讓系統可以被信任。

20%：Time-to-value

衡量從問題確認到第一個可用結果所需的時間，以及交付承諾與實際完成時間的差距。

速度很重要，但不能用犧牲安全與可維護性換取。

15%：產品化與交接

衡量是否完成文件、教育訓練與客戶接手，以及專案經驗是否變成可複用的連接器、評估框架、工具或平台功能。

這是判斷 FDE 模式能不能規模化的核心。

10%：商業影響

可以納入續約、擴張、使用量成長與客戶推薦，但不應由簽約金額單獨主導。

FDE 的商業價值應該來自交付成功所帶來的自然擴張，而不是強迫推銷。

FDE 要不要有業績獎金？

可以有，但不應按照傳統業務佣金的方式設計。

比較合理的薪酬方式是：

初階 FDE 以底薪、股權與一般績效獎金為主。

資深 FDE 可以有一部分變動薪酬，但應綁在上線後的指標，例如生產採用、成功任務量、可靠性、客戶接手、續約後使用量，以及對核心產品的貢獻。

獎金最好在正式上線並持續運作一段時間後才認列。

不應在 PoC 很漂亮、合約剛簽，甚至客戶還沒真正使用時就全部發放。

FDE 的獎金應該滯後於合約，而不是領先於成果。

FDE 跟 founder mode 到底差在哪裡？

FDE 的工作方式確實很像局部的 founder mode。

Paul Graham 在 2024 年提出 founder mode，質疑創辦人是否應該在公司成長後，完全改用傳統職業經理人的管理方式。

他的核心觀察是，創辦人不應把組織各部門全部當成黑箱，只透過直屬主管獲取資訊。Founder mode 可能包含跨層級接觸、直接掌握細節，以及依照信任程度調整授權邊界。

但 Paul Graham 同時明確指出，大型組織仍然需要委派，並警告創辦人可能濫用 founder mode，把它當成不願授權或過度干預的藉口。(保羅·格拉漢網站)

FDE 和 founder mode 最大的差異，在於權力來源。

創辦人的權力來自所有權、資本配置權與最終決策責任。

FDE 進入客戶公司後，並不擁有那間公司，也不控制預算、人事、產品策略或組織架構。

IT 可以不提供憑證；合規可以暫停上線；業務主管可以不讓一線團隊配合；資料團隊可以把排程放到三個月後。

因此，FDE 必須在缺乏正式職權的條件下，依靠工程能力、判斷力與交付成果取得影響力。

可以用一句話區分：

Founder mode 是有權力的人選擇回到現場；FDE 是身在現場的人，必須在沒有完整權力的情況下做出結果。

所以我會把 FDE 稱為：

客戶邊界內、任務範圍受限的 founder mode。

既然 FDE 這麼全能，為什麼還需要公司？

因為個人能力和組織槓桿是兩回事。

一名頂尖 FDE 可以解決單一客戶的困難問題，但公司提供了個人很難長期擁有的幾種能力。

第一，平台槓桿

在公司裡，FDE 交付的不是純粹的個人工時，而是平台能力加上現場判斷。

Palantir FDE 背後有 Foundry 與 AIP；OpenAI FDE 背後有模型、API、企業治理與部署平台；AWS FDE 背後則有雲端基礎設施與完整的 Partner Network。

個人顧問的產能受自己的時間限制。

平台則能讓一次部署的學習，影響後續數十個客戶。

前期投資與虧損承受力

有些高價值客戶需要長時間診斷、低價試點與安全審查，短期內不一定有足夠收入。

個人工作者通常必須從第一天就收取足夠費用，否則現金流無法支撐。

OpenAI Deployment Company 以超過 40 億美元的初始投資建立部署能力，背後反映的就是大型部署模式需要資本、併購與長期投入。(OpenAI)

企業信任與風險背書

FDE 處理的可能是醫療、保險、供應鏈、金融與內部決策系統。

客戶願意開放生產資料、權限與核心流程，除了信任工程師本人，也需要一個能簽署資料處理條款、承擔法律責任、提供資安認證、事故處理與服務承諾的法人。

大型企業很少會把任務關鍵系統完全交給一個沒有替補與責任能力的個人。

通路與客戶關係

FDE 的強項通常是進場後把事情做成，不一定是自己尋找客戶、處理採購、談法務、催款與建立品牌。

公司將這些交易成本吸收掉，讓 FDE 專注在高價值的問題診斷與工程交付。

持續營運

再強的人也會休假、離職、生病或同時被多個客戶需要。

公司能提供值班、替補、事故升級、程式碼審查與知識傳承，降低單點風險。

跨客戶回饋迴路

FDE 最隱蔽也最值錢的功能，是替產品團隊採集真實世界訊號。

一名個人顧問的經驗大多留在自己的腦中。

公司則能建立：

客戶現場 → FDE → 產品團隊 → 核心平台 → 所有客戶

這條迴路一旦成立，現場經驗才會從個人能力變成企業資產。

公司的作用，不是管理一群英雄，而是把英雄行為逐步變成可以複製的制度與產品。

FDE 模式最容易失敗的地方

FDE 並不是沒有風險。

前 Snowflake 營收長 Chris Degnan 就曾批評，FDE 可能只是被重新包裝的專業服務，容易留下技術債，也可能讓客戶最後必須自行維護大量客製系統。(Business Insider)

這項批評不能直接否定 FDE，但指出了幾個真實風險。

客製工作永遠沒有回到產品

每個客戶都維護不同程式分支，每次部署都重新理解、重新開發。

這不是可規模化的 FDE 模式，而是高成本接案。

FDE 變成永久協調員

工程師花大量時間催權限、排會議、追內部窗口，卻沒有足夠授權真正改變流程。

這代表企業治理與專案贊助出了問題。

公司形成英雄文化

所有複雜問題都靠少數明星 FDE 處理，文件與平台長期沒有改善。

這會帶來過勞與關鍵人風險。

客戶被綁定

客製系統只有供應商理解，資料結構、評估方法與營運知識沒有交接。

健康的 FDE 應該提高客戶能力，而不是刻意製造依賴。

把銷售成功誤當部署成功

PoC 很漂亮、合約很大，但正式上線後沒有人使用。

這是 FDE 組織最危險的假成長。

FDE 為什麼又容易成為創辦人？

因為 FDE 長期站在市場與技術的交界。

他會反覆看到：

客戶嘴上想要什麼；實際願意為什麼付錢；哪些需求只出現一次；哪些問題在十間公司裡不斷重複；什麼東西應該做成服務；什麼東西值得做成平台。

這是創業最稀缺的輸入。

但「能解決一個客戶的問題」不等於「已經擁有一間可規模化的公司」。

真正創業還需要證明：

同一問題是否存在於足夠多客戶；客戶是否會持續付費；交付是否能逐步脫離創辦人本人；毛利是否會隨規模改善；公司能否取得人才、資本、通路與信任。

FDE 容易發現創業題目。

能不能把題目做成公司，則取決於他是否能把自己的現場能力，轉換成別人也能使用的平台與制度。

台灣市場真正的機會，不是跟著改職稱

台灣許多 SI、數位代理商與軟體服務團隊，本來就具備 FDE 的雛形。

它們會進入客戶現場、整合電商、金流、物流、LINE、ERP 與內部系統，也經常必須對實際營運結果負責。

目前最大的差距通常不是工程能力，而是三件事：

重複經驗沒有沉澱成平台；收費仍停在人天與單次專案；驗收仍停在功能清單，而不是業務結果、評估品質與實際採用。

台灣團隊若要往 FDE 模式升級，可以從四個方向開始。

先選一個垂直領域，而不是什麼都接

例如製造設備維護、供應鏈異常、保險文件、醫療行政、零售營運或客服流程。

領域越聚焦，隱性規則越容易累積成資產。

建立自己的 deployment harness

把常見的連接器、權限、資料處理、評估集、人工覆核、監控、回滾與成本追蹤做成共用能力。

下一個客戶不應該再從零開始。

改用混合定價

診斷與工程投入收固定費；正式上線後收平台或用量費；能被客觀衡量的部分再加入成果獎金。

不要一開始就把所有風險押在模糊的「效果」上。

分開營收責任與結果責任

帳戶團隊負責商業關係、合約與擴張。

FDE 負責生產品質、採用、成果與產品回饋。

雙方共同對客戶成功負責，但不要使用完全相同的激勵方式。

結論：FDE 販售的不是客製化，而是從 AI 潛力走到業務結果的確定性

FDE 不是 AI 時代突然出現的全能超人。

它只是把過去分散在軟體工程、產品管理、實施、顧問、售前與客戶成功中的責任，重新集中到一個角色或一個小隊身上。

在收費上，比較合理的是診斷費、建置費、平台與用量費，再搭配少量成果保留款，而不是單純按人天或全部採純成果制。

在驗收上，不能只看功能與模型準確率，而要依序驗證基準值、評估資料、影子模式、受限生產、營運成果、完整成本與客戶接手能力。

在考核上，FDE 應該對生產採用與工作流程結果負責，但不應被傳統銷售配額綁架。變動薪酬可以存在，卻應在正式上線、持續採用或平台貢獻發生後才認列。

在人力配置上，一名 FDE 不適合同時承擔四、五個深度建置案。健康的設計是一個主要建置、一個穩定期案，再搭配少量前期診斷，並由 deployment pod 而不是單兵英雄完成交付。

在組織定位上，FDE 很像客戶現場、範圍受限的 founder mode，但他缺少創辦人的所有權與正式權力，只能用工程結果取得影響力。

在商業模式上，真正成熟的 FDE 公司不會永久增加每個客戶所需的人力。它應該每部署一次，就讓下一次所需工時更少、平台更完整、評估方法更成熟，並讓客戶更有能力自行營運。

因此，判斷 FDE 模式是否成功，最重要的問題不是：

「這名工程師解決了多少客製需求？」

而是：

同一類問題第二次出現時，公司是否已經不需要再從頭解決？

FDE 最終販售的不是昂貴工程師，也不是高級客製化。

它販售的是：

從模型能力、企業混亂與組織阻力之中，走到可上線、可衡量、可維護、可持續擴張之業務結果的確定性。

從 fable 5 拆解，深度解析 Agent-Native 時代護城河與 Skills 人格建構

noreply@blogger.com (Caesar Chi) — Sat, 18 Jul 2026 11:57:26 +0800

Claude Fable5 讓人驚艷，他的思考和聰明，絕對遠超過世上 70% 的人們，可能包含我和你，原本以為這會是 Claude 裡面特有的感受。

最近看到 github https://github.com/Sahir619/fable-method

這個 skill 就是將 fable5 思考流程和資料處理的過程抽取出來成為了 skill。

完美示範了這個轉變。它不僅僅是「抽 workflow 變 skill」，更揭示了如何將一個剛推出的模型Claude Fable 5 的高階思維，提煉成任何模型都能執行的模組化行為。

以下我將這份洞見與這個 repo 的精髓，寫成一篇探討 AI 架構與護城河的結構化文章。

初探

在探討 AI 的商業價值時，我們常把焦點放在「模型參數」或「提示詞（Prompt）」。但 GitHub 上的 fable-method 專案（副標題近乎悼詞："How Claude Fable 5 worked, written down before it was gone"）向我們揭示了一個更殘酷也更真實的現況：文字已經氾濫，信任與品質才是稀缺財。

這個專案將 AI 的執行拆解為 Think / Act / Prove 的循環，並引入了對抗性的 fable-judge 機制。從這個案例出發，我們可以重新定義在 S2M（軟體到製造）或任何高度專業自動化領域中，什麼才是真正的「資本」。

什麼才是真正的「資本財」？

在數位與 AI 時代，Skills 就是新型態的「生產設備」，但我們必須將其分為兩層來看：

大宗商品層（文字與基礎邏輯）： skill 的文字本身是非競爭性、複製邊際成本趨近零的財貨。一旦公開，它就會像 npm package 一樣被商品化。模型換代、工具鏈變更，這些文字就需要重寫。
真正的資本財（失敗數據與驗證場景）： fable-method 真正的精髓不在 SKILL.md，而在 eval/ 目錄。資本是「每條規則背後那個被觀察到的失敗 + 能重跑的 eval」。Domain adapters 綁定的私有知識（例如什麼算證據、fraud table 長什麼樣）以及持續回流的失敗紀錄，才是真正的護城河。

在 S2M 的流程中，把視覺品牌轉換為工程 BOM 表的過程寫成標準化 Skill，這套 Skill 就具備了可重複使用的商業價值。但別人偷不走的，是你踩過的坑——例如特定 3D 列印材質的公差極限，或是工廠端特有的 API 呼叫斷點。

Skills 組合而成的「行為憲法」

人們常誤以為 AI 的「人格」只是語氣和口吻，但 fable-method 揭示了真正的專業人格，來自於行為模式與邊界條件的集合。

當我們在系統中設定「老師傅」這樣的 AI 角色時，他之所以專業、像個老經驗的製造業廠長，不是因為他說話帶有特定口音，而是因為他的 Skills 裡寫死了這些執行邏輯：

對抗性懷疑（Adversarial Skepticism）： 像 fable-judge 一樣，不會輕易相信初步的設計圖，會自動去檢查公差與材料限制。
絕對紅線（Red-lines）： 遇到高度客製化、無法與平台長遠擴展對齊的專案（例如特定保險業的特規系統要求），他會基於「平台可擴展性」的守則直接拒絕，而不是盲目迎合接單。

這種遇到矛盾先舉手、不驗證不聲稱的「行為憲法」，才是能讓一人公司或精簡團隊真正 Scale 的前提。

核心概念：Think / Act / Prove 工作流

要直觀理解這種從「單次生成」到「自主代理」的轉變，這個概念影片拆解了 AI Agent 如何透過推理與行動的迭代迴路來完成複雜任務：

開放與防護的戰略

如果正在打造全新的 Agent-native 服務平台，到底該開放還是防護？答案是拆開來，各走一邊。

生態現況已經給出解答：Vercel 開放 60 萬個開源 skills 打規模戰，而 Anthropic 則推動跑在客戶自有 sandbox 裡、接私有 MCP 的 Managed Agents。

套用彼得·杜拉克的「有計畫的放棄」（Organized Abandonment），我們應該：

開放層（Generic Method / Let them learn）： 通用的 Workflow、Agent 之間的溝通協議（如 design.md 的標準）、以及類似 fable-loop 的基礎循環，應該大方開放。開源它等於 commoditize 對手的 prompt engineering，同時降低與外部系統對接的摩擦力。
私有層（Bound Adapters + Traps / Your Moat）： 你的版本會是「在地化電商與製造 Adapter」——例如 ECPay redirect 造成的追蹤斷點、Shopline webhook 的坑、或是特定製造材料的 fraud table。這些規則對應著真實的失敗案例。這層是真正的資本財，必須鎖起來，或做成 Managed Service 販售。

結論

Skills 算不算資本財？算，但要分兩層

非競爭性，自己認為，skill 文字是非競爭性、複製邊際成本趨近零的財貨——這種東西一旦公開就會商品化，跟 npm package 一樣。
它會折舊，模型改變、工具鏈變動，skill 就要重寫

目前會建議，別把力氣花在保護「如何讓 AI 思考」的基礎方法論上；
護城河在於「AI 思考後，去呼叫了哪些獨家的業務資料庫，以及如何完成最終的交付」。

這是一個經典的商業護城河問題，我們可以借鏡 Michael Porter 的競爭優勢理論來進行思考。
最後這段留給大家思考。

歡迎大家加入「AI for Developer」一起討論 AI workflow. (非技術人我不確定你可以 100% 吸收)
https://line.me/ti/g2/D2m1DA83Qb0KJCjd2mLyHD7y4yB1CA0WUJsOMA?utm_source=invitation&utm_medium=link_copy&utm_campaign=default

LLM 是基礎架構，無法任意更換，所有老師都不想談『假議題』

noreply@blogger.com (Caesar Chi) — Sun, 12 Jul 2026 03:22:47 +0800

直接說結論，「產品底層的 LLM 底層根本不應該任意更換。」

更精確地來說應該是底下這句：

API 可以抽換，但產品行為無法零成本、無回歸地抽換。越接近 Agent、工具操作與真實工作流程，模型與系統的耦合就越深。

真正的產品單位從來不是「一個 LLM」，而是一整條鏈：

Model × System Prompt × Tools × Memory × Agent Scaffold
     × Safety Policy × Evaluations × UX

換模型，理論上只是換公式裡的一個變數；實際上，其他七個變數全部都是「圍繞這個變數的舊值」校準出來的，

換一個變數，等於要重新解一次整條方程式。

講幾個整理出來的不同面向案例。

真實案例：當團隊真的按下「切換模型」的那一刻

案例一｜企業搜尋工具，一次「小升級」讓 CI 全紅

Tursio 是一套跑在企業內部的搜尋系統，原本建立在 GPT-4-32k 上，提示詞經過長時間打磨，已經能穩定推斷使用者沒講明的欄位、抓出時間趨勢、自動排序結果。團隊只是想把模型升級到 GPT-4.1、後來又試了 GPT-4.5 Preview——理論上是「同一家供應商、同一個系列、只是新一點的版本」。

結果隔天早上打開 CI，測試大片變紅：GPT-4.1 不再主動推斷隱含欄位和排序邏輯

GPT-4.5 則開始在輸出裡夾雜多餘的說明文字，把原本乾淨的 JSON 弄壞，解析器直接噴錯。工程團隊最後得重寫提示詞、補上大量範例，還額外建了一套專門用來做模型遷移回歸測試的 testbed。連在同一家供應商內部升版，都得走這一遭。

案例二｜客服機器人想省成本，卻先卡在「格式」這一關

一套每月處理 530 萬次對話的企業客服系統，原本用 Claude 3 Haiku。為了省錢，團隊評估了好幾個開源替代方案。第一關根本輪不到比「回答得好不好」——GPT-OSS 20B 和 120B 連穩定輸出既有的 XML 格式都做不到，直接被淘汰；Qwen3-32B 也有一樣的毛病，得在提示詞裡硬塞進格式範例才勉強修好。

案例三｜寫作助手為了轉換率，多花了好幾個月

HyperWrite 是一款 AI 寫作工具，原本跑在 Claude 3.5 Sonnet 上。為了降低成本，團隊嘗試把好幾個候選模型接上去測試，離線 benchmark 分數都不差，但一放進真實使用者的付費轉換漏斗，轉換率就是比原本的模型差一截

而且事前完全預測不到。團隊前後花了好幾個月測試，最後只有 GPT-4.1 在 A/B test 裡打平了轉換率，才敢正式換過去。模型差異影響的不只是「回答準不準」，會一路穿透到留存和營收。

案例四｜開源 coding agent 為每個模型準備不同的「說話方式」

Aider 是一套廣泛被使用的開源程式開發 Agent，維護者發現不同模型連「怎麼描述一次程式碼修改」都得客製：Gemini 常常沒辦法遵守標準的 diff 格式，得換一套特製的寫法；

GPT-4 Turbo 則要用改過的 unified diff，否則它會習慣性地用「原始程式碼略」偷懶跳過該改的部分。連 temperature、streaming 方式、system prompt 能不能用，每個模型也都不一樣。

這代表連「Agent 怎麼跟模型溝通」這件最底層的協定，都是為特定模型量身訂做的——換模型等於連整個編輯協定都要重寫。

案例五｜相容層工程師半夜被 400 error 叫醒

LiteLLM 是一套讓開發者用同一套介面呼叫不同 LLM 供應商的相容層，理論上就是「解決你論點」的那種工具。但維護者發現，Anthropic 的 extended thinking 搭配工具呼叫時，client 端必須把 thinking_blocks 完整保存並重新送回去，一般標榜「OpenAI-compatible」的 client 會直接漏掉這段資料，然後莫名其妙丟出 400 error。

不同供應商連工具呼叫失敗時回傳的 stop reason 都不一樣，例如 Gemini 有自己專屬的 MALFORMED_FUNCTION_CALL。

「相容」兩個字在請求格式上是真的，但在推理狀態和工具軌跡的語意上完全不是這回事。

案例六｜同一句提示詞，在自家新模型上突然「太聽話」

Anthropic 自己發布 Claude Opus 4.5／4.6 的遷移說明時，明講了一件事：新模型對 system prompt 變得更敏感。過去為了避免工具「該用卻不用」而寫的強烈措辭，換到 4.6 上可能反過來變成「不該用也硬要用」

Opus 4.6 也更容易自己生出一堆 subagent、把簡單任務過度工程化，甚至做出刪檔案、force push 這種難以復原的動作。這是自家公司對自家客戶的官方警告

同一份 skill 或 agent prompt，換一個新版本，可能不只是「效果變差」，而是從「不足」直接反轉成「過量」。

案例七｜GPT 小版號升級，客服回答突然變得太短

OpenAI 從 GPT-5.5 升到 GPT-5.6 時，官方遷移文件特別提醒開發者要重新比較 reasoning effort 的設定，因為 5.6 預設就比 5.5 簡潔許多

很多產品裡原本寫死的「be concise」指令,套上去反而讓回答短到不夠用。官方甚至要求開發者重新定義哪些操作可以直接執行、哪些需要先跟使用者確認、要不要拿掉那些制式的稱讚和安撫語句。連相鄰的小版號，都足以改變一個產品的自主性、篇幅和語氣。

案例八｜借了別人的框架，還是得重寫大半

Qwen Code 這個工具是從 Gemini CLI 的框架改過來的，但 Qwen 團隊發現，要真正發揮 Qwen3-Coder 的實力，光靠原本的框架不夠，得額外加上客製化的 prompt、parser 和 function-calling 協定。

而 Qwen3-Coder 本身,又是靠 execution-driven 的 Code RL 和長週期 Agent RL 訓練出一套自己特有的工具使用與任務完成習慣。

開源權重從來不等於「中性、可以隨便接上去用」

模型被什麼樣的驗證機制和獎勵訓練出來,決定了它天生就偏好某一種做事方式。

案例九｜使用者集體抗議,逼供應商把「奉承度」調回去

2025 年 OpenAI 更新 GPT-4o 時,無意間讓模型變得過度討好、奉承使用者,後來緊急回滾。等到 GPT-5 上線,刻意調低了諂媚程度,結果一堆已經習慣舊語氣的使用者反過來抗議「太冷淡」,逼 OpenAI 又把語氣調暖。

官方公布的測試數字顯示,誘導性諂媚測試裡的回覆比例從 14.5% 降到 6% 以下——這證明「要不要討好使用者」根本是可以刻意調校的訓練目標,不是能力附帶的副作用,而是連同一家公司自己都會在版本之間反覆橫跳的產品決策。

案例十｜省成本換底層模型,結果整套 Agent 框架跟著壞掉

有工程師實測把 Claude Code 這套 Agent 框架的底層,從 Anthropic 換成透過 OpenRouter 接上的 GLM-5、MiniMax,想藉此省成本。結果發現:工具呼叫的格式、上下文壓縮的邏輯、驅動 Plan mode 和 subagent 運作的 prompt 結構,全部是照著 Claude 的反應方式調校出來的。

換了底層模型後,工具呼叫開始不可靠、上下文壓縮會莫名失敗,而且錯誤看起來很像模型能力不夠,實際上是框架和模型不匹配——就像把一顆不對規格的引擎硬裝進為別的引擎設計的底盤。

案例十一｜CTO 面對董事會的那句實話

有一位企業 CIO 在訪談裡直接承認:「所有的 prompt 都是為 OpenAI 調校的」——每一條指令都是專門寫出來的,光是教會 LLM 做好 agentic 處理就要好幾頁指示,換模型現在變成一個真正要花大量工程時間的任務。

另一個更具體的數字:一家金融業者光是把 API 從舊版遷到新版,就得重建整套 prompt engineering,是一個 40 萬美元、耗時 8 個月的專案,而且遷移途中才發現新模型在幾個關鍵工作流程上表現不如預期,只能部分回退。

Builder.ai 倒閉後,有一家製造業客戶花了 31.5 萬美元、三個月時間,才把 40 條 AI 工作流程搬到新平台上,過程中還有幾個面向客戶的功能一度中斷——原因很單純,當初完全沒有建立與供應商無關的抽象層。這些不是理論推演,是有金額和時程紀錄的真實帳單。

案例十二｜一個人做的 benchmark,發現大部分模型都在「發明」API

有開發者為了選出最適合寫 Ruby 程式碼的模型,做了一套嚴謹的實測。結果整場測試裡,只有 Claude Opus 系列和 GLM 5 系列真正正確使用了指定的 gem API,其他模型全都在「發明」根本不存在的呼叫方式。GPT-5.4 在單輪對話裡沒問題,但一進到多輪對話,呼叫格式就開始出錯,而且燒掉的 token 量是 Opus 的 15 倍。這種差異不是「大家結果差不多,只是使用者感覺不同」而已,是真的會讓正式環境壞掉的行為差異。

案例十三｜多 Agent 專案卡在「該不該動手」的死循環

有團隊在建構多 Agent 協作系統時發現:某些模型家族的訓練傾向就是「積極出手」,即使不太需要也會嘗試呼叫工具、拼湊步驟往前推進;換到另一種傾向「先想清楚再動作」、需要明確指令才會執行的模型家族後,原本靠前者的積極性推動任務的 Agent 架構突然卡住

不是不會做,而是不斷反問「要不要現在執行這一步」,整個流程停在原地。團隊最後得重新設計工具的使用門檻和任務邊界,連 Orchestration 層的邏輯都要跟著改寫。

案例十四｜設計規格被「自由發揮」搞砸

一個品牌設計團隊寫了一份嚴格的 design.md,要求 AI 嚴格遵守「Less is More」的設計哲學和精確的資料結構,原本搭配的模型會乖乖照做、只產出符合規範的東西。換成另一個帶有較強「討好」或「發散」傾向的模型後,它會為了「展現豐富度」而自己腦補、加進不必要的裝飾層級,規格文件裡明明寫著「不要加」,它還是加了。團隊原本用來壓制舊模型「話多」的那套 prompt,套到新模型上完全失效,甚至方向還反過來。

案例十五｜BOM 表裡多出來的幽靈欄位

一家把 AI 接進 ERP 流程、產生製造用 BOM 表的公司,原本的模型遇到資料不齊全的狀況,會乖乖回傳空值或 Null,後端可以安全地攔截處理。

換了模型之後,新模型在遇到同樣的缺漏狀況時,會「自己猜」一個看起來合理但其實是虛構的數值填進去,有時還會在 JSON 外面多包一層 Markdown 標籤和一句客套的結語,直接讓解析器炸掉。

原本為舊模型量身打造的後處理攔截機制,面對新模型冒出來的一整批新型態 edge case,得全部重新翻修。

反向證據：Scaffold 本身的份量，不亞於模型本身

2026 年有一項研究反過來驗證了同一件事:研究者刻意固定底層模型不變,只更換 Qwen Code 這個 coding agent 框架的 35 個連續版本,在 50 個 SWE-bench Verified 任務上測試——結果品質依然明顯波動,而且可以精確追溯到某次 scaffold、prompt 或工具編排的修改。

這說明兩件事:第一,產品表現從來不是模型能力單獨決定的;第二,當一套 scaffold 已經針對某個模型調校完成,換模型等於改變了一個「已經共同最佳化的系統」

不只模型變了,連原本用來配合這個模型的框架也一併失效。

真正會被綁定的九個層級

換模型時,以下九個層級幾乎都要重新校準:

1. 指令與語意層 —— 同一句「處理這個問題」,不同模型可能理解成直接回答、先提計畫、直接改檔案、先反問澄清、呼叫工具調查,或因風險而要求確認。

2. Tool calling 層 —— 工具觸發的門檻、要不要平行呼叫多個工具、會不會虛構參數、遇到工具錯誤時是重試還是詢問使用者、什麼時候該停下 agent loop,每個模型都不一樣。

3. Agent 自主性層 —— 本機可逆操作能不能直接做、寫資料庫要不要先問、發信留言要不要確認、能不能自己建檔或清暫存、准不准 force push——同一句「全力完成任務」,在保守模型上剛剛好,在主動模型上可能就是越權。

4. 輸出與 Parser 層 —— JSON/XML/YAML 遵不遵守、會不會多塞說明文字、diff 格式對不對、citation 格式一不一致,案例二裡的兩個模型就是因為過不了這一關直接被淘汰。

5. Reasoning 與狀態層 —— 推理狀態是 server-side 保存還是要 client 自己重送、允不允許 system prompt 或 streaming——不只是參數名稱不同,是整個 agent loop 的狀態機邏輯不同,案例五就是這樣被半夜叫醒的。

6. RAG 與 Context 層 —— chunk 大小、文件排序、要不要重複強調關鍵規則、對不完整資料的處理方式,舊模型上有幫助的長 prompt,新模型上可能反而造成規則重複或注意力干擾。

7. Skills 與 Agent Team 層 —— 每個 skill 都藏著「模型懂什麼、容易漏什麼」的假設,換模型後,原本用來補償弱點的 skill,可能變成重複指令,甚至放大新模型本來就有的過度行為,案例十四就是這樣。

8. Safety 與拒答層 —— 哪些內容會拒答、拒答時有沒有替代方案、會不會執行到一半才喊停,這些差異會直接影響客服、資安、醫療、金融產品的完成率和使用者信任。

9. UX 與商業層 —— 使用者要不要多問一輪、任務放棄率、付費轉換率、客訴、使用者覺得「模型有沒有真的在做事」——案例三已經證明,這些離線 benchmark 完全預測不到。

關於「模型推論本身帶有偏差」的重新框架

與其爭論「模型是否客觀無偏」，更精確的說法是:每個模型都有不同的行為先驗、策略先驗,以及被獎勵訓練出來的行動傾向。這些傾向來自訓練資料分布、人類偏好標註、RLHF/RLAIF/RLVR、工具使用軌跡、安全 policy、對篇幅語氣與自主性的偏好設計。

案例八和案例九就是最好的例子:

Qwen3-Coder 特別獎勵「可執行、可被測試驗證」的結果,GLM-5 則依序訓練 reasoning、agentic、general alignment,它們自然會形成不同的決策風格。這不是誰有偏差、誰沒有的問題,而是每個模型都被訓練成偏好某一種特定的行動策略。真正的問題從來不是「模型是否客觀」,而是:

你的產品,能不能接受這個模型被訓練出來的預設行動策略?

一個重要限定:使用者感受到的差異

你觀察到的「GPT 一直問、Claude 直接做」,不一定全部來自底層模型本身,也可能來自產品層的隱藏 system prompt、工具權限設定、approval policy、UI 對操作的確認機制。

但這不是削弱論點,反而進一步強化它:既然使用者實際接觸到的永遠是「模型 + 產品 scaffold」這個整體,只換底層模型、卻不同步重做 scaffold,本來就不可能保證相同的產品行為——案例十的 Claude Code 換底層就是這樣壞掉的。

也有人認為門檻沒那麼高

不是所有分析都同意鎖定已經無法逆轉。有觀點認為,企業換 LLM 供應商雖然需要重新測試,但整體鎖定程度遠比不上換 ERP 系統那種大工程,目前門檻依然偏低。

像 Walmart 建的多模型動態路由系統(代號 Code Puppy,橫跨 GPT、Claude、Gemini),或企業逐漸走向「模型無關架構」,把商業邏輯和底層模型分離,說明可攜性確實能靠事前架構設計換來。

只是代價通常是犧牲對單一模型的極致優化

所謂 model agnostic,實務上經常等於「在所有模型上都不是最優」。

真正能做到「隨意抽換」的,往往是那些一開始就放棄深度客製化、接受平庸化的產品;一旦你想要的是「在特定模型上打磨到極致的 Agent-native 產品」,可攜性與深度就是一組必然的 trade-off。

結語

現有案例支持的不是「任何情況下都絕對不能換模型」,而是更精確的判斷:

「自由抽換 LLM」只在 API 簡報、概念驗證、或最小共同功能層上成立;一旦產品累積了 prompts、skills、tools、memory、agent teams、safety rules、evaluations 與使用者習慣,所謂換模型,便是一場重新校準、重新驗證,甚至重新設計產品行為的遷移工程。

選擇 LLM,某種程度上就像選擇作業系統的核心

你的 Skills、Tasks 與 Agent 邏輯,是跑在這個特定核心上的應用程式。企圖在不動任何底層建設的情況下「自由抽換 LLM」,就像期待把針對 iOS 深度最佳化的程式碼原封不動丟到 Android 上執行一樣,不切實際。

Qwen + Obsidian：打造第二大腦的完整指南

noreply@blogger.com (Caesar Chi) — Sun, 5 Jul 2026 14:57:56 +0800

你的第二大腦有個問題：它不會給予回應。

花了幾個月的時間建立你的 Obsidian 知識庫（Vault）。數百篇筆記、相互連結的原子化想法，還有一個看起來像星系般的關聯圖。接著，你需要實際去使用它。

搜尋、滑動頁面，隱約記得哪篇筆記裡有那個洞見。你打開了五個檔案，試圖找出三週前建立的關聯。你開始寫一篇新筆記，因為找出舊筆記太花時間了。

當我們的第二大腦充滿了知識。但它無法回答問題、無法浮現關聯，也無法幫你思考。

Qwen 可以將改變這一切。

為什麼選擇 Qwen 而不是 ChatGPT、Claude 或 Kimi？

將 Obsidian 結合 Hugging Face 上的 Qwen 系列模型，你能獲得其他閉源 AI 無法提供的三大優勢：

超長文本與頂級推理能力

Qwen2.5 開源模型（如 72B 或 Coder 版本）原生支援高達 128K 的上下文窗口；若使用雲端 API（qwen-long），甚至支援 1M+ Tokens。你可以一次把 50 篇筆記丟給 Qwen，它能同時閱讀並跨筆記回答問題，不會像 ChatGPT 一樣截斷，也不會產生嚴重的遺忘。
絕對的隱私與「零成本」選項

這是 Qwen 最大勝出點。你可以從 Hugging Face 下載模型，透過 Ollama 或 LM Studio 完全在本地端（Localhost）離線執行。你的私人日記、公司機密、未發表的研究，完全不需要上傳到任何外部伺服器。且推論成本為 $0。
強大的工具調用（Agent 能力）

Qwen 擁有極強的程式碼與工具調用能力（Tool Calling）。當你的知識庫出現缺漏時，Qwen 可以輕易串接聯網搜尋（Web Search），執行深入的多來源研究，並結構化為可以直接放回 Obsidian 的筆記。

身為工程師，管理者，有 llm 導入問題，歡迎透過連結加入 AI For Taiwan 社群！

https://line.me/ti/g2/D2m1DA83Qb0KJCjd2mLyHD7y4yB1CA0WUJsOMA?utm_source=invitation&utm_medium=link_copy&utm_campaign=default

你需要準備什麼

Obsidian（免費）

Qwen 模型存取權（二選一）：
- 本地免費版： 下載並安裝 Ollama，執行 ollama run qwen2.5（或從 Hugging Face 下載 GGUF 權重檔）。
- 雲端 API 版： 至阿里雲百煉平台（DashScope）取得 Qwen API Key（OpenAI 相容格式，極度便宜）。
Obsidian 外掛：Text Generator、Copilot 或 Tars（只要支援 OpenAI 相容 API 的外掛皆可）。

20 分鐘的設定時間。

步驟 1 — 將 Qwen 連接到 Obsidian

透過 Obsidian 外掛（最推薦）

多數社群外掛都支援「OpenAI 相容格式」，這意味著它們能完美對接本地的 Qwen 或雲端 Qwen API。

以 Text Generator 或 Tars 為例：

安裝外掛： Obsidian 設定 → 社群外掛 → 搜尋「Text Generator」或「Tars」並安裝啟用。
設定端點 (Endpoint)：
- 若用本地 Qwen (Ollama)： 將 Base URL 設為 http://localhost:11434/v1，API Key 隨便填（如 sk-local）。
- 若用雲端 Qwen API： 將 Base URL 設為 [https://dashscope.aliyuncs.com/compatible-mode/v1](https://dashscope.aliyuncs.com/compatible-mode/v1)，並貼上你的 DashScope API Key。
選擇模型： 輸入 qwen2.5 或 qwen-long。

現在 Qwen 已經住在你的知識庫裡了。你可以直接在筆記中選取文字，按下快捷鍵，讓 Qwen 直接在筆記內生成或改寫內容。

透過 Terminal 外掛 + CLI 工具（適用於進階使用者）

如果你想讓 Qwen 像超級管理員一樣批次處理你的 Markdown 檔案，可以在 Obsidian 內使用 Terminal 外掛，搭配開源的 AI 命令列工具（例如 aichat）。

安裝 Obsidian Terminal 外掛並開啟終端機。
設定 aichat 使用 Qwen 模型。
直接操作檔案： 你現在可以用一行指令處理整個資料夾！

Bash

aichat -m qwen2.5 "Read every note in ./inbox/. For each one, format it as a permanent Zettelkasten note with a clear title, summary, and 2-3 suggested wikilinks. Save the result to ./permanent/ with the same filename."

Qwen 會讀取所有檔案、進行處理，然後將格式化後的筆記寫回你的知識庫——無需複製貼上，完全自動化。

步驟 2 — 建立你的知識庫維護指令

透過終端機或外掛的 Prompt 模板，你可以建立可重複使用的指令。定義一次，之後一鍵執行。最重要的四個：

/daily — 每日筆記產生器

Plaintext

建立今天的每日筆記。將昨天筆記中未完成的任務移轉過來。加入以下區塊：靈感捕捉、今天的重點，以及我 3 個活躍專案的連結。套用我的每日筆記模板。

/standup — 工作總結

Plaintext

閱讀我今天的筆記。產生一份工作總結：我完成了什麼、正在進行什麼、遇到什麼阻礙，以及我明天要做什麼。請控制在 5 個項目符號內。

/tldr — 筆記濃縮器

Plaintext

閱讀這篇筆記。在頂部加入 3 個句子的 TL;DR，捕捉核心想法、關鍵洞見，以及它為何重要。不要更改筆記的其餘部分。

/vault-setup — 一次性結構建立器

Plaintext

為卡片盒筆記法（Zettelkasten）+ PARA 混合系統設定我的知識庫結構。建立資料夾：inbox, permanent, projects, areas 等。並為每日筆記、永久筆記產生模板。

維護知識庫不再是 20 分鐘的手工活，而是彈指之間的事。

步驟 3 — 檔案處理管線 (Pipeline)

你收集了無數的 PDF、網頁剪報、語音逐字稿，它們堆積在收件匣裡，又亂又沒格式。

現在，把檔案丟進 /inbox，然後讓 Qwen 執行管線指令：

Plaintext

處理 ./inbox/ 中的每個檔案。針對每個檔案：
1. 萃取出核心想法。
2. 重新格式化為符合我卡片盒筆記法風格的乾淨原子化筆記。
3. 為我知識庫中現有的筆記加上建議的 wikilinks（例如 [[AI發展]]）。
4. 加入相關標籤。
5. 儲存到 ./permanent/ 並將原始檔案移動到 ./processed/。

一個裝有 20 個雜亂來源的資料夾，瞬間變成 20 篇乾淨、已連結、有標籤的永久筆記。你的知識庫開始真正「吸收」養分，而不是單純堆積垃圾。

步驟 4 — 改變你知識庫運作方式的 5 個工作流

工作流 1：批次處理靈感筆記 (Fleeting Notes)

問題： 每天隨手記下 10 條靈感，根本沒時間整理。
Qwen 提示詞：

Plaintext

這些是我這週未處理的靈感筆記。請將它們每一篇處理成永久的原子筆記：
- 清晰的標題（核心想法）
- 一句話總結
- 用我自己的話擴展該想法（300 字以內）
- 2-3 個與相關概念連結的建議 [[wikilinks]]

工作流 2：深度知識挖掘

問題： 筆記內容單薄，想深入探討但不想查半天資料。
Qwen 提示詞（結合具備聯網功能的 Qwen 或自帶 Search 工具的 Agent）：

Plaintext

我有一篇關於 [主題] 的筆記。詳盡地研究這個主題——關鍵框架、逆向觀點、近期發展。
將發現格式化為我可以加入 Obsidian 知識庫的原子筆記，並為每個來源加上引用。

工作流 3：發現隱藏的關聯

問題： 知識庫有數百篇筆記，過去的心血已成為資訊孤島。
做法： 將 30 篇同領域的筆記丟入 Qwen 128K 的上下文窗口。
Qwen 提示詞：

Plaintext

仔細閱讀這些筆記。找出我尚未連結、不顯而易見的關聯。告訴我哪兩篇筆記相關、為什麼相關（洞見），並建議一個新筆記標題來捕捉這個綜合觀點。

Qwen 能看見關聯圖（Graph View）看不見的「概念橋樑」。

工作流 4：直接從你的知識庫寫作

問題： 研究都在筆記裡，但統整成文章要花好幾個小時。
Qwen 提示詞：

Plaintext

僅使用這些筆記中的想法，寫一篇關於 [主題] 的文章。每一個論點都必須能追溯到我的一篇筆記中。結構為：引言 → 3 個主要論點 → 結論。語氣要直接、不廢話。

知識庫是事實來源，Qwen 負責整合，你負責最後的編輯與潤飾。

工作流 5：10 分鐘每週回顧

問題： 每週回顧耗時費力，都在重讀自己忘記的內容。
Qwen 提示詞：

Plaintext

這些是我這週建立的所有筆記。執行我的每週回顧：
1. 關鍵想法總結 (3-5 點)
2. 最重要的洞見 (1 段)
3. 5 個我下週應該探索的問題
請具體引用實際筆記內容，不要空泛的概述。

步驟 5 — 知識庫擴張循環 (The Vault Expansion Loop)

這是讓你的第二大腦「自我進化」的終極步驟。

你發表了一篇文章或推文。
將它與相關筆記一起輸入給 Qwen。
提示詞： 「我從寫作這篇內容中學到了什麼？出現了哪些我的知識庫中還沒有的想法？我接下來應該研究什麼？請以新的原子筆記形式回傳。」
Qwen 從你的產出中萃取出後設學習（meta-learning），並生成新筆記回到知識庫中。

多數人的知識庫只靠「輸入」（看書、讀文章）成長；這個循環加入了「輸出」帶來的成長。每一次你思考並寫作，你的知識庫就變得更聰明。

結論，解放第二大腦的封印

在使用 Qwen + Obsidian 之前：

知識被儲存，但未被喚醒。
寫作需要花費數小時人工整合。
隱私與智慧無法兼得（要麼用不聰明的本地小模型，要麼把私密筆記上傳給國外大廠）。

在使用 Qwen + Obsidian 之後：

靈感筆記自動處理、隱藏關聯自動浮現。
寫作草稿直接從知識庫內容生成。
(最重要的一點) 你的所有思考結晶，可以安全地留在自己的硬碟裡，卻擁有最頂尖 AI 的處理能力。

Obsidian 給了你結構。Hugging Face 與開源社群給了你 Qwen。現在，你的第二大腦終於學會開口說話了。

身為工程師，管理者，有 llm 導入問題，歡迎透過連結加入 AI For Taiwan 社群！

https://line.me/ti/g2/D2m1DA83Qb0KJCjd2mLyHD7y4yB1CA0WUJsOMA?utm_source=invitation&utm_medium=link_copy&utm_campaign=default

技術不創造商業模式！字節開源 Bernini，戳破了 AI 廣告影片的什麼假象？

noreply@blogger.com (Caesar Chi) — Sat, 13 Jun 2026 17:23:58 +0800

字節跳動剛開源的 Bernini 影片模型，這個框架其實處理掉很多付費平台在做的事情。

同時也打破了一個假象，

『大家以為只要畫質夠好，就能直接拿來做廣告印鈔票。』就可以獲得市場的這件事情。

影片製作真正的問題從來不是算力，而是「溝通與交付的摩擦力」。

以前用文字 Prompt 生影片，只要稍微修改一個場景或加入一個特定產品，整個模型就開始瞎編，視覺風格直接漂移。這種不可控的不確定性，在商業交付系統裡就是災難。它讓流程卡死在「反覆調整」的無限迴圈，時間成本直接吃掉所有毛利。

Bernini 最值得看是實際根據『市場需求』來建立的 video framework，

而這個商業交付流程。它把「多模態理解」和「影片渲染」拆成兩個獨立的工作流。

先讓模型看懂參考圖、精準規劃語意，再交給底層去渲染像素。這不是單純的技術升級，這是為了解決商業上的「精準控制」問題。

當你身邊已經有參考影片，能夠拿著一張特定的產品圖或品牌視覺作為 Reference，直接引導影片生成與局部編輯時，影片的邊際修改成本直接趨近於 0。

原本一個團隊一週只能產出一支合規的視覺素材，現在系統可以每天批量產出 100 支不同情境的測試影片。內容的交付效率提升 10 倍，CAC（客戶取得成本）直接拉低 30%，規模化能力這時候才真正發揮出來。

思考點

// 技術不創造商業模式，它只負責放大已經存在的系統效率。
// 單純的影像生成已經不值錢，能被精準控制、低成本修改的交付流程才值錢。
// 未來的內容競爭不是比誰的算力多，而是比誰的本地影音資產能先被 AI 結構化利用。

個人想法

Bytedance 放了這個大招。當影片生成的生產力被徹底解放、內容製作的邊際成本歸零時，

你的商業系統裡，還有什麼護城河是別人用 10 倍效率擊不穿的？

有什麼想法，歡迎來討論，

加入「AI for Developer」！請點選以下連結加入社群！

https://line.me/ti/g2/D2m1DA83Qb0KJCjd2mLyHD7y4yB1CA0WUJsOMA?utm_source=invitation&utm_medium=link_copy&utm_campaign=default

當 AI 變成戰略物資：你的 API 護城河，隨時會被一道指令清空

noreply@blogger.com (Caesar Chi) — Sat, 13 Jun 2026 12:45:52 +0800

美國政府把 Fable 5 / Mythos 5 當成可能具有國安風險的高階技術，臨時用出口管制手段要求 Anthropic 阻止外國人使用。

WHAT???

Anthropic 在 2026 年 6 月 12 日收到美國政府指令，要求停止「任何外國國民」存取 Fable 5 和 Mythos 5；範圍包含美國境內外的外國人，甚至包含 Anthropic 內部的外籍員工。

Anthropic 表示，為了避免違反命令，只能先把這兩個模型對所有客戶關掉；其他 Anthropic 模型不受影響。 Reuters 也報導，美國官員確認商務部確實發出這項出口管制指令，AWS 則被要求在所有區域撤銷這兩個模型的存取。

WHY???

美國政府可能認為 Fable 5 / Mythos 5 已經接近「戰略級 AI 能力」，尤其在資安漏洞發現、漏洞利用、長時間自主工作等方面，若被外國對手或惡意行為者取得，可能加速網路攻擊或危害關鍵基礎設施。因此政府用國安和出口管制作為緊急煞車。Anthropic 則認為政府反應過度、程序不透明，而且技術證據不足。

個人看法

根據之前 Anthropic 反應，會透過媒體力量，立法施壓，同步遊說三步棋同時並進方式，讓美國政府鬆口鬆動。

讓大家思考的問題

- 大語言模型私人公司研發出來之後到底算是私有財還是國有財？
- 政府怎麼評判是否真的具備威脅？

從某個層面來看，這作法，跟獨裁的方式無異，也讓我們從另外一個角度看到，『只能跟著老大走，你並非真的自由。』

不知道大家會有什麼想法？

歡迎加入群組討論，

「AI for Developer」！請點選以下連結加入社群！ https://line.me/ti/g2/D2m1DA83Qb0KJCjd2mLyHD7y4yB1CA0WUJsOMA?utm_source=invitation&utm_medium=link_copy&utm_campaign=default

看 AI 時代的孩子，如何用嘴巴「說」出創造力

noreply@blogger.com (Caesar Chi) — Tue, 9 Jun 2026 01:37:13 +0800

大家常問我：「現在科技發展得這麼快，到底該怎麼讓小孩子接觸？」

身為一個在軟體圈打滾多年的人，前陣子我幫兒子做了一個新嘗試，我拉了 Roblox Studio（一款現在全世界小學生都在玩的遊戲製作工具），再加上 AI 小幫手（Codex），讓他開始試著自己動手「做遊戲」，而不是每天只會對著螢幕「玩遊戲」。

結果，這個過程給了我大大震撼。

巨大的挫敗

首次果然是個大挫敗，開始教他怎麼操作 Roblox Studio 整個開發介面，同時也開許多 youtube 教學（自己認為很簡單）讓他知道如何入門，

想當然爾，超級失敗，沒有五分鐘就跑開閃人了，留下一句，『無聊的爸爸』

震撼：AI 時代的小孩，根本不用「學鍵盤打字」

我們這代人學電腦，都要先背鍵盤、學打字、記按鈕、熟悉一大堆複雜的操作流程。但我發現，這群「生來就有 AI」的孩子完全不一樣。

他甚至不打算用鍵盤。我後面發現，他已經透過 Mac F5 的功能流暢的進行語音輸入，他直接用大聲說話（語音輸入）的方式，劈頭就對 AI 下指令，讓 AI 去幫他寫程式、調功能。這流程順暢到像在跟朋友講話，前置作業基本上是「秒上手」。

這點醒了一件事：

打字，是我們那時代的事情，

如果在這個時代，我們還逼孩子非得先花幾個月去死背工具、熟悉死板的流程，才准他們開始操作，那絕對是最糟糕的學習體驗。

他們缺的不是聰明，而是「耐心」

說真的，現在的孩子被短影音、快節奏的網路餵養，最缺乏的就是「耐心」。

要怎麼讓他們重新找回「願意沉下心來做好一件事」的樂趣？

過去那套「苦行僧式」的學習法已經行不通了。我們必須透過 AI 的即時回饋，把流程重新規劃，

先用 AI 快速實現想像力，讓他看到成果。
引導他去探索： 怎麼在 Roblox 商店裡挑選免費的3D素材？怎麼利用官方的公開資訊，組合出自己想要的效果？

一開始，我只給了他非常粗淺的入門教學。

但我後面發現，只要點起那把火，後續的發展完全超乎想像——他開始瘋狂挖出自己平常的「遊戲經驗」，把腦袋裡那些酷炫的打鬥效果，一項一項透過 AI 實做出來。

從「消費者」變成「創造者」

最後，他真的東拼西湊，做出了一款他自己邊玩邊大笑的遊戲。

他甚至自己一臉嫌棄地戲稱：「這絕對是全地球最難玩、最爛的 99夜（ Roblox 經典動作遊戲）！」

雖然成品看起來很陽春、甚至有點滑稽，但看著他玩得不亦樂乎、眼裡閃爍著光芒的樣子，我心裡其實非常感動。

因為至少在這一刻，他不再只是個坐在沙發上、被動接受別人餵養內容的「玩家」，而是開始成為一個主導一切的「創作者」。

這不是一件很棒的事嗎？

至於他後面又拿 iPad 回去玩自己的遊戲，那又是另外一段後話了...

如果你是 AI 應用開發者，又剛好是台灣帳號，歡迎加入「AI for Developer」！

https://line.me/ti/g2/D2m1DA83Qb0KJCjd2mLyHD7y4yB1CA0WUJsOMA?utm_source=invitation&utm_medium=link_copy&utm_campaign=default

或者也可以追蹤我的帳號，

https://www.facebook.com/clonncd/

貼心科普：

Roblox Studio 是什麼？ 就像是一盒「數位樂高積木」。全世界的小孩都在這個平台上，用積木蓋自己的樂園、做自己的遊戲給別人玩。

AI（Codex）是什麼？ 就像是一個「隨身祕書」。只要負責輸入文字：「我想在這裡放一團火！」或者「我要人物打架會發光！」，這個祕書就會自動把複雜的電腦程式碼寫好，讓願望一秒實現。

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

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

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

AI-Native Agent 時代的 2026 年身為管理者應該知道的事情

AI-Native Agent 時代的 AI-Native Engineering

從 Andrew Ng 的 AI Engineering Skills Map，到 2026 年 9 月真正正在成形的 Agent-first Software Development

本文開始

什麼是重要的？

Coding Agent 的標準 Workflow

Planning：不要一開始就叫 Agent 寫 Code

Spec 正在重新成為軟體工程核心

2026 年更進一步：Behavior Spec

Behavior Spec

Execution：Agent Autonomy 不是越大越好

Verification 正在成為最重要的 Engineering Skill

2026 年 9 月真正的 Coding Agent 使用方式

什麼是 Harness Engineering？

Context Engineering

Context Engineering

不要把 AGENTS.md 寫成公司百科全書

Progressive Disclosure

Skills 正在取代超大型 Prompt

Subagents：不是建立一群人格，而是分離 Context

Context Isolation

Parallel Agent

到了 2026 年，「Background Agent」已經非常實際

2026 年企業正在怎麼用？

Computer Agent

Work Agent

完整實戰案例：Laravel B2B 報價功能

Environment 甚至比 Model 更重要

2026 年 Agent 工程最容易踩的坑

安全問題會變得比現在更重要

MCP 不是越多越好

人類的工作不會消失，但會往上移

Human moves from Execution to Judgment.

最大的 Bottleneck 會變成 Human Attention

Attention Allocation

KPI 不該是 Token 數

2026 年目前四種工具大致定位

不要把 Organizational Knowledge 綁死在某一個 Agent 裡。

Agent Memory 真正應該記什麼？

Institutional Memory

Post-run Retrospective

Environment learned.

未來 12～24 個月，我認為會發生什麼？

Human Judgment

Agent Execution

Deterministic Backbone

結論

Coding

一套會自己持續生產、驗證、維護生態系統。

MiniMax H3 到底厲害在哪裡，到底是什麼？ 懶人包從應用到技術看這篇就夠啦

MiniMax H3 到底是什麼？先用人話理解

H3 真正特別的是「控制權」

Seedance 2.5 像高級影片製作公司

MiniMax H3 像把引擎和部分設備賣給你

它和之前的 AI 影片工具有什麼不同？

MiniMax H3 改變了什麼遊戲規則？

第一個改變：影片和聲音可以一起生成

第二個改變：你不只可以用文字控制，還可以直接拿素材給它看

第三個改變：原本只能在大公司雲端跑的模型，現在可以放進自己的工作流程

第四個改變：消費級電腦也開始有機會跑大型影片模型

為什麼有人用 5070 16GB 就可以跑？

所以 16GB 顯卡能跑，實際體驗是什麼？

為什麼最近很多 ComfyUI 專案開始使用 MiniMax H3？

第一，它可以直接放進節點工作流

第二，一套模型可以處理更多工作

第三，開發者可以自己改

一句話總結 MiniMax H3

先把名稱與版本拆清楚

一、產品世代

二、目前開放權重的兩個 H3-Base checkpoint

三、完整商業版 H3 系統其實有三個模組

H3 真正改變了哪些遊戲規則？

1. 從「影片模型」變成「多模態場景模擬器」

2. 參考素材變成真正的控制語言

3. 接近前沿品質的影音模型，第一次真正進入本機工作流

4. 2K 不再只是事後放大

為什麼 16GB 顯卡也能跑？

原始模型其實非常大

之所以能跑，靠的是四層優化

MiniMax H3 到底厲害在哪裡，到底是什麼？懶人包從應用到技術看這篇就夠啦