---
title: "AI 的天花板，是你的野心：速度、高度、深度、廣度四個維度"
description: "Anthropic 工程主管 Felix Rieseberg 把「對 AI 更有野心」拆成速度、高度、深度、廣度四個維度。本文整理他的做法與實例，再加上我的實踐筆記：用目標導向的指令，調度 Multi-AI Agents 專家團隊做多視角交叉審查，提升任務品質。"
url: https://stephen.taipei/articles/ai-ambition-four-dimensions-felix-rieseberg
author: "Stephen Chuang"
date: 2026-10-21T09:30:29+08:00
tags: [ai-agents, learning]
lang: zh-TW
---

# AI 的天花板，是你的野心：速度、高度、深度、廣度四個維度

Anthropic 工程主管 Felix Rieseberg 在〈[How to be more ambitious: A tutorial for humans with models](https://felixrieseberg.com/how-to-be-more-ambitious-a-tutorial-for-humans-with-models/)〉裡提到：看到別人用 AI 做出驚人成果時，他和身邊的人常有同一個反應：「我們還不夠有野心。」

我的解讀是：**人類用 AI 的上限，往往卡在自己的野心與想像力，而不是模型。**

他把「野心」拆成四個維度：

- **速度（Speed）**：同樣的工作，用更短的時間完成。
- **高度（Altitude）**：拉高抽象層級，看最終成果，而不是單一任務。
- **深度（Depth）**：用領域頂尖專家的標準、工具和方法來做。
- **廣度（Range）**：跳出單一領域，跨領域找解法。

結論先講：**精準下達目標導向的指令，調度 Multi-AI Agents 專家團隊做多視角協作與交叉審查，任務品質才會整體往上拉。**

## 一、速度：最基本，也最少人卡關

同樣的工作用更短的時間完成。Felix 認為這一點大家已經很熟悉，文章直接跳過。

我的看法：速度是 AI 最直觀的價值，但只追求速度，協作方式不會有太大改變。真正拉開差距的是後面三個維度。

## 二、高度：問「目標背後的目標」

核心提問：**下一步真正想要的結果是什麼？目標背後的目標是什麼？**

Felix 的例子：

- **從修一個 Crash，到讓 App 不再 Crash。** 他原本請 Claude 修單一 Crash，後來改成要求 App 保持零 Crash。為了讓這件事能持續自動跑，他得先改自己的流程：讓 Crash 報告容易取得、把 App 版本對應到 Git Commit、讓 Claude 能使用 Windows、macOS、Linux 機器重現並驗證修正。
- **季度業務檢討（QBR）的三段升級：**
  1. 盡量用原始資料，說明這一季變了什麼、為什麼、接下來該怎麼做。
  2. 找出 3 個最急迫的決策，各自寫出正反論點。
  3. 設計一套比季度簡報更早發現問題的替代機制，用歷史資料測試，再跟現行流程並行跑一季。

他也提醒邊界：在 2026 年，像「Claude，去幫我賺錢」這種模糊目標還行不通，但他預期模型能處理的抽象層級會越來越高。

## 三、深度：比照領域頂尖專家的規格

Felix 的做法：

- **用這個產業真正在用的工具。** 模型常常只換了用詞、沒換方法，丟一張 Markdown 表格就交差。要堅持用資料庫、統計模型這類真正的分析工具。
- **設定看似不合理的目標，並告訴模型這是可解的。** 他的例子：網站載入從 10 秒壓到 5 秒之後，再要求 200 毫秒。模型退縮時，堅持這個目標可以達成。
- **挑戰你自己相信的假設。** 給模型原始資料，用對抗的角度檢驗。例如：「我們認為流失是新手引導的問題，試著從原始資料重現這個結論。」
- **產生新知識。** 從 Logs 建模擬，找出你還不知道的最早流失訊號，再用沒看過的資料驗證。
- **找外部裁判（Outside Judge）。** 不讓模型自己批改自己。最好掛一個模型能直接執行、立即回饋的工具來驗證。

他的 Prompt 心法是：**要的是「更深的版本」，不是「更大的版本」。** 請模型說出頂尖專業人士會多做什麼、最原始的資料在哪、要用哪些方法和工具，以及除了模型或你的判斷之外，有什麼能證明結果是對的。

## 四、廣度：動詞取代名詞，組一支專家團隊

- **動詞取代名詞。** 這個概念 Felix 引自《The Art of Innovation》。QBR 與其說是「一份簡報」，不如說是「在 30 分鐘內，讓忙碌的人理解因果、在不確定中做決定」。用動詞定義目標，就看得出需要哪些領域的能力。
- **組一支團隊。** 要做出好的簡報，找分析師、記者、編輯；要上台報告，再加動態與音效設計師。要做對抗審查，就找放空機構的研究員和鑑識會計師。
- **不要做沒意義的角色扮演。** 不是叫模型「用放空機構的口吻寫」，而是叫它真的執行放空機構研究一個部位的方法。只換口吻，結果不會更好。

前提是：模型要有一台能安裝軟體的電腦，並能透過 MCP 連接器等方式取得相關資料。

## 五、我的實踐筆記：從「資料傳遞」到「意圖達成」

以下是我結合軟體架構與工程實務的延伸，不是原文內容。

### 1. Jobs to be Done 與意圖導向（Intent-Based）

- **別問「做什麼」，問「達成什麼」。** 設計不該停在 `generate_deck_pdf()` 這種被動的資料傳遞管線，而要提升到 `resolve_leadership_uncertainty_and_commit_budget()` 這種狀態轉換的意圖。
- **定義真實的損失函數。** 只要求產物，模型會生出看似完美的廢話；要求解決決策的不確定性，模型和 Sub-agent 才會主動補上邏輯漏洞和風險邊界。

### 2. 探索時發散，驗收時收斂

- **探索時**先發散找可能，再收斂。
- **驗收時**不要再發散。避免問「這件事還可以怎麼做？」這種沒有邊界的問題，只會換來泛泛之談。
- **明確寫出目標範圍、限制條件和客觀驗證工具**（特定的測試腳本、業務指標門檻），讓 Multi-Agent 團隊在聚焦的框架裡做壓力測試，交出高品質的成果。

## 心得總結

- **目標導向：** 用動詞取代名詞。交付解決問題的成果，而不是只為了交差的產出物。
- **探索與收斂：** 探索時發散找可能，驗收時嚴格收斂、驗證邊界。
- **抽象聚焦：** 從核心提問出發，重構整套任務流程。
- **專家深度：** 不只模仿專家的口吻，而是逼模型用頂尖專家的工具和方法解決問題。

原文：[How to be more ambitious: A tutorial for humans with models](https://felixrieseberg.com/how-to-be-more-ambitious-a-tutorial-for-humans-with-models/)（Felix Rieseberg，2026-10-13）