什麼是 AI 的「鋸齒邊緣」（Jagged Edge）？

「鋸齒邊緣」是指 AI 的能力分佈並非線性，而是呈鋸齒狀。AI 在某些任務上可以達到超人類水準，但在另一些任務上卻表現極差。這條能力邊界非常不直觀，無法用「簡單或複雜」來預測，必須透過大量實測才能掌握。這個概念由 Anthropic 第一位 Technical PM Dianne Penn 提出，對 AI 產品開發者來說是非常關鍵的認知框架。

AI 產品 PM 如何應對模型能力邊界模糊的問題？

Anthropic 的 Technical PM Dianne Penn 提出「eval-driven development loop」作為解法，也就是建立系統性的 evaluation framework，大量測試模型在不同任務類型、prompt 風格和 context 長度下的表現，而非憑直覺判斷。這能幫助 PM 追蹤每次模型更新對各項任務的實際影響，取代傳統軟體開發中明確的 SLA 與 QA 流程。

什麼是「Token Maxing」？對 AI 應用有什麼幫助？

Token Maxing 是指將所有可用的背景資訊——包括文件、歷史記錄、範例與相關脈絡——盡可能全部填入 AI 的 context window，而非只給精簡的 prompt。這個做法讓模型能在更完整的資訊下運作，通常能產出更準確、更符合需求的結果。此概念在 YC 社群與 Anthropic 的產品實踐中都受到關注。

Anthropic 第一位 Technical PM 說的「AI 鋸齒邊緣」是什麼？產品人必看

2026年7月27日 · Waiting7777 · 8 分鐘閱讀

Anthropic AI 職涯 Claude OpenNext Product Manager

📂 Anthropic 系列 📂 AI 系列 📂 職涯系列 📂 Claude 系列 📂 OpenNext 系列 📂 Product Manager 系列

在 AI 實驗室當第一個 Technical PM 是什麼感覺

> Meta Shift

2023 年，Anthropic 的整個 product team 是五個工程師。沒有 PM。

Dianne Penn 加入的時候，她是第一個。在那之前她在 Amazon 做 Alexa 的 AI，再之前在 JP Morgan Chase 交易高收益債券。這個背景組合放在今天看有點瘋狂——從 bond trader 到 voice AI 到 frontier model lab，但如果你看過這幾年 AI 的發展速度，大概就不會覺得意外了。

她在接受 Lenny Rachitsky 訪談的時候說了一個讓我印象很深的東西：jagged edge。

進去之前，Anthropic 是什麼狀況

Anthropic 是 2021 年從 OpenAI 出走的。核心創辦人 Dario Amodei 和 Daniela Amodei 帶著一批人出來，主打 safety-first 的路線，跟 OpenAI 在方向上有根本性的分歧。

Dianne 加入的時候是 2023 年，那時候 Claude 2 剛出來，Anthropic 在外界眼中還是一個「很 research 導向」的公司——聰明、有理念、但不確定能不能打。ChatGPT 已經爆了，GPT-4 也出來了，OpenAI 在市場上的品牌認知度領先非常多。

但那一年 Anthropic 開始做一件事：把賭注壓在 coding 上。

這不是偶然。他們觀察到 Claude 在 coding 任務上表現特別好，同時 developer 這個族群的 willingness to pay 極高，feedback loop 快，而且如果你的 model 能幫工程師省時間，那個 ROI 非常清楚。這是一個可以量化的市場，不像「讓 AI 更有用」這種模糊的方向。

結果也驗證了這個判斷。Anthropic 現在被描述為「史上成長最快的公司」之一，Claude Code 成為獨立產品，MCP（Model Context Protocol）成為 AI tool use 的重要基礎設施。Dianne 參與孵化了這些東西——Claude Code、MCP、computer use、tool use、reasoning，還有 Skills，幾乎每個 Claude 從 2 到 Fable 的 model 她都跟到了。

Jagged Edge：AI 的能力地圖其實是鋸齒形的

這是我覺得這次訪談最有價值的概念。

大部分人對 AI 的想像是線性的——它某個版本比較弱，下個版本比較強，能力是一條往右上走的線。但實際上不是這樣。

Jagged edge 說的是：AI 在某些任務上的能力是超人類水準，但在某些任務上又爛到你不敢相信。 而且這條邊界非常不直觀，不是「簡單的事它會、複雜的事它不會」，更不是「reasoning 型的它強、創意型的它弱」。它的能力分佈是鋸齒狀的，你需要真的用過、測過，才會知道邊界在哪裡。

這對 PM 來說是個很獨特的挑戰。

一般的軟體產品，你大概知道功能邊界在哪裡——這個按鈕按了會怎樣、這個 API 的 error rate 是多少、這個功能在什麼 edge case 會壞掉。你可以寫 spec、做 QA、定 SLA。但 LLM 的能力邊界是模糊的、會隨 prompt 改變的、甚至會隨 context window 裡的內容改變。

Dianne 的解法是她說的 eval-driven development loop：你要大量、系統性地去測模型的邊界，不是憑感覺說「感覺這個版本比較好」，而是建立一套 evaluation framework，讓你能追蹤每次 model change 對各種任務的影響。

這其實跟遊戲的 meta 分析很像。你不能只看一個 hero 的 win rate 就說它強，你要看在什麼 comp、什麼 map、對什麼 counter 的情境下它的表現。AI model 也一樣，你要知道它在什麼 task 類型、什麼 prompt style、什麼 context 長度下會超強或會崩掉。

Token Maxing：把 context window 用到極限

訪談裡還有一個概念是 token maxing，這個詞最近在 YC 社群裡也傳開了（Garry Tan 也提過）。

基本概念是：與其給 AI 少量、精心設計的 prompt，不如把你能給的 context 全部塞進去——文件、歷史記錄、背景資訊、範例，能給的都給。讓 model 在更完整的資訊下工作。

這背後的邏輯是，現代 LLM 的 context window 已經大到一個程度（Claude 的 context window 是 200K tokens，是業界最大之一），而 model 處理 long context 的能力也在進步。你不再需要像以前那樣省著用，反而應該考慮：我給的資訊夠不夠讓它做好這件事？

YC 有一篇報告提到，用 token maxing 策略的 builder 能讓 AI 做到 400 個工程師的工作量。這個數字聽起來很誇張，但如果你真的用過 Claude Code 或類似工具跑過完整的 codebase 分析，大概能理解這種感覺——它不是在幫你打字，它是真的在幫你思考架構、找 bug、寫測試、做 code review。

當然，前提是你要知道怎麼給它正確的 context。這又回到 jagged edge 的問題——你要先搞清楚它的能力邊界在哪裡，才能有效地「餵」它。