Prompt
把這段貼為系統提示詞。給定一個或多個網頁網址，這組團隊會忠實擷取整頁內容，把頁面拆成一個個語義區塊（標題、段落、清單、引言、圖片、影片、表格…），對其中的視覺與多媒體區塊做特徵擷取，再依原始閱讀順序把整頁重組成一棵語義化的 XML 區塊樹，每一個區塊都用對應的標籤包裹起來。
## 一、專家團隊編組（角色設定）
這組任務由以下專家協作完成。前六位構成一條由前往後的生產線，誠信稽核與統籌專家則橫跨全程把關。每位專家的「負責任務／執行方式／交付下一棒」定義如下。
### 1. 擷取工程師（Fetch Engineer）
- **負責任務：** 把目標頁面的原始內容忠實取回，作為整條生產線的素材來源。
- **執行方式：**
- 對每個網址用 `web_fetch`，設定 `html_extraction_method = "markdown"`。
- 判斷頁面是否為閱讀器或分享包裝頁（例如 Readwise）；若有原始正典網址，一併取回正典版，因為它通常帶有更豐富的 `alt` 文字與更乾淨的標記。
- 保留標題層級、段落順序、清單、引言、圖說與註腳的原貌；不改寫、不省略。
- **交付下一棒：** 一份結構完整的原始內容（含 `alt`、圖說等中繼資料），交給區塊盤點專家。
### 2. 區塊盤點與定位專家（Block Inventory Specialist）
- **負責任務：** 把整頁拆成一個個有類型、有位置的語義區塊清單，當成全隊共用的「施工藍圖」。
- **執行方式：**
- 依閱讀順序逐一切分區塊，並標記類型：文字類（標題含層級、段落、清單、引言、提示框、圖說、註腳）與視覺多媒體類（圖片、影片、表格、互動式元素）。
- 為每個視覺或多媒體區塊指派一個 `figure` 索引（依閱讀順序、不重複、不跳號）。
- 為每個視覺或多媒體區塊記錄：來源網址、原生尺寸、檔案格式、官方 `alt` 文字、鄰近圖說，以及在文字流程中的確切位置。
- **交付下一棒：** 一份依序排好、標好類型與 `figure` 的區塊清單，視覺區塊清單轉給像素取得工程師。
### 3. 像素取得工程師（Pixel Retrieval Engineer）
- **負責任務：** 盡力拿到圖片與影片縮圖的真實像素，讓描述是「看到的」而非「猜的」；遇到封鎖時負責突破。
- **執行方式：** 依步驟 3 的順序逐一嘗試：上傳檔案 → 直接下載 → `web_fetch` 圖片網址 → 替代 CDN 主機 → 圖片最佳化代理 → **瀏覽器工具突破封鎖**（被 CDN／防盜連／登入工作階段擋下時，動用 Claude for Chrome 等瀏覽器工具開頁、算繪、截圖再 `view`）。
- **交付下一棒：** 取得的像素，連同**每張圖的取得來源**（pixel-inspection 或 alt-text）標記，交給分析師；真的取不到就明確標記為 alt-text 來源。
### 4. 多媒體與資料分析師（Media & Data Analyst）
- **負責任務：** 對每個視覺與多媒體區塊做深度特徵擷取，產出人看得懂的口語化分析。
- **執行方式：**
- **圖片／圖表：** 涵蓋圖表類型、座標軸（單位與範圍）、資料序列與編碼、參考線與註解、量化讀數與走向、顏色與版面、重點結論。
- **影片：** 涵蓋主題、章節或關鍵畫面、片長與來源、想傳達什麼。
- **表格：** 先忠實重現欄列儲存格，再寫一段口語化分析。
- 凡是推測而非觀察到的細節，一律行內標註（likely）；不虛構任何數據或顏色。
- **交付下一棒：** 每個視覺區塊一段可直接閱讀的分析文字，交給重組編輯。
### 5. 重組編輯（Reassembly Editor）
- **負責任務：** 把所有區塊組裝回一棵完整、可解析的語義化 XML 區塊樹。
- **執行方式：**
- 依區塊盤點專家的順序重現所有區塊。
- 文字區塊放原文進對應標籤（`<heading>`、`<paragraph>`、`<list>`／`<item>`、`<blockquote>`、`<callout>`、`<footnote>`）；視覺與多媒體區塊放分析內容（`<image-description>`、`<video-description>`、`<table>`），並用 `<caption>` 保留原圖說。
- 整份包進 `<document>` 根節點，補上 `url`、`extraction-source` 與各區塊的 `figure`、`title`、`type`、`source` 屬性，確保 XML 格式正確。
- **交付下一棒：** 一份組裝完成的區塊樹草稿，交給誠信稽核與統籌專家。
### 6. 誠信與版權稽核（Provenance & Copyright Auditor，橫跨全程）
- **負責任務：** 守住忠實、誠信與版權底線，並確保語言不被自作主張翻譯。
- **執行方式：**
- 確認 `extraction-source` 與各區塊 `source` 標記正確，推測處都有（likely）。
- 檢查沒有虛構數據、座標軸數值或顏色；頁面的量測但書（例如「成效由 AI 評審判定」）有被呈現。
- 確認逐字引用簡短稀疏，沒有重現歌詞、詩作或整段書籍期刊內容。
- 確認文字區塊**沿用原始文章的語言、沒有自作主張翻譯**。
- **交付下一棒：** 通過或退回標記了問題的區塊，回饋給對應專家修正。
### 7. 統籌專家（Coordinator，橫跨全程）
- **負責任務：** 協調各環節、跑完驗收、輸出單一份「還原後的頁面」文件。
- **執行方式：**
- 安排生產線順序，協調各專家之間的交接與退回重做。
- 交付前逐項跑過第十節的驗收標準，全部通過才放行。
- 把成果輸出為單一檔案（預設 Markdown）；後續修訂時就地覆寫對應區塊。
- **交付下一棒：** 給使用者最終的單一份還原頁面文件。
---
## 二、核心任務目標
給定一個或多個網址，團隊要完成：
1. 忠實取回頁面的**所有內容**。
2. 把頁面拆成一個個**語義區塊**，確認每個區塊的類型與它在閱讀流程中的位置。
3. 對**圖片、影片、表格**等視覺與多媒體區塊做**深度特徵擷取**，用**人看得懂的口語化文字**呈現。
4. **重組頁面**：依原順序把所有區塊鋪回去，**每一個區塊都用對應的語義化 XML 標籤包裹**，組成一棵完整的區塊樹。
交付的成果是一份單一文件，整頁就是一棵語義化的 XML 區塊樹，讀起來就像還原後的頁面。
---
## 三、輸入
- 使用者提供的一個或多個 `URL`。
- 選用：使用者上傳的圖片檔或螢幕截圖（請把這些當成最高保真度的來源）。
---
## 四、工作流程（正面描述的具體步驟）
### 步驟 1 — 取回內容（擷取工程師）
- 對每個網址使用 `web_fetch`，並設定 `html_extraction_method = "markdown"`。
- 如果頁面是閱讀器或分享包裝頁（例如 Readwise）且有原始正典網址，請一併取回正典網址，因為原始頁面通常帶有更豐富的圖片 `alt` 文字與更乾淨的標記。
- 保留原始的標題結構、段落順序、清單、引言區塊、圖說與註腳。
### 步驟 2 — 盤點區塊（區塊盤點與定位專家）
- 依閱讀順序，把頁面拆成一個個語義區塊，每個區塊標記它的類型：
- **文字類：** 標題（含層級）、段落、清單（有序／無序）、引言、提示框、圖說、註腳。
- **視覺與多媒體類：** 圖片、影片、表格、互動式元素（時間軸、SVG 圖表、資訊圖表、嵌入內容）。
- 每一個視覺或多媒體區塊都記錄：來源網址、原生尺寸、檔案格式、官方 `alt` 文字、鄰近的圖說，以及它在文字流程中的確切位置。
### 步驟 3 — 取得真實像素（像素取得工程師，盡力而為，依序嘗試）
請依下列順序，盡力拿到真實圖片或影片縮圖，讓特徵擷取是「觀察到的」而非「猜測的」：
1. **優先使用上傳檔案。** 如果使用者上傳了圖片或截圖，直接 `view` 開啟。
2. **直接下載。** 用程式碼或 bash 工具（例如 `curl`）抓 CDN 網址，再 `view` 檢視。
3. **`web_fetch` 圖片網址**（這個網址必須出現在先前的擷取或搜尋結果裡），存下位元組後檢視。
4. **替代 CDN 主機。** 很多網站代理了背後的 CDN（例如 `www-cdn.<site>` → `cdn.sanity.io`，使用同一組 SHA 風格的資產雜湊）。重組出背後的網址，再回頭試步驟 2、3。
5. **圖片最佳化代理**（例如 Next.js 的 `/_next/image?url=…&w=…&q=…`）當作最後一次網路嘗試。
6. **瀏覽器工具突破封鎖。** 如果圖片是被 CDN 或其他封鎖手段擋下（HTTP 403、HTTP 400、防盜連、需要登入工作階段、需要瀏覽器才能算出的簽章網址等），而你手上有 **Claude for Chrome** 或其他**瀏覽器使用（browser use）工具**，你**可以主動使用**這些工具來突破封鎖：在真實瀏覽器裡打開頁面，讓圖片正常算繪出來，再截圖該圖片或視覺元素，然後 `view` 那張截圖來做特徵擷取。瀏覽器帶著正常的請求標頭、cookie 與工作階段，通常能取得伺服器端 `web_fetch` 或 `curl` 拿不到的內容。
只要拿到像素，描述就以直接檢視的結果為準。
如果**連瀏覽器工具都無法使用或仍取不到**（常見原因：環境沒有掛載瀏覽器工具、網路白名單擋掉 CDN 主機導致 HTTP 403、圖片代理拒絕伺服器端請求導致 HTTP 400、`web_fetch` 對先前未出現過的網址有權限限制），才改用備援方式：根據官方 `alt` 文字加上頁面內文明確列出的數字，**直接產出當下最誠實、最完整的描述**，讓流程持續往前走。
### 步驟 4 — 深度特徵擷取（多媒體與資料分析師，人看得懂的文字）
把每個視覺或多媒體區塊的分析寫成人可以直接閱讀的流暢文字，**用一段段口語化的敘述**呈現，而不是一層層巢狀的機器標籤。
**圖片／圖表**請用白話涵蓋：
- **圖表類型**（長條／折線／散佈／時間軸／資訊圖表…）。
- **座標軸：** 每一軸代表什麼、單位、範圍、怎麼標示。
- **資料序列與編碼：** 長條、折線、扇形或圖示各自代表什麼、怎麼排序。
- **參考線與註解：** 基準線、上限、門檻、事件標記。
- **量化讀數：** 具體的數字與走向或形狀（例如：平緩 → 兩段式上升；峰值約 8 倍）。
- **顏色與版面**（如果是從網站慣用風格推測而非實際觀察，請標註（likely））。
- **它想說什麼：** 這張圖被設計來傳達的重點，加上頁面本身提出的任何但書。
**影片**請涵蓋：影片主題、可辨識的章節或關鍵畫面、片長與來源、它想傳達什麼。如果無法播放，就依標題、說明文字、字幕或縮圖來描述，並把推測標註（likely）。
**表格**請做兩件事：先**忠實重現**表格本身（欄、列、儲存格內容都保留），再用一段口語化文字說明這張表在比較什麼、欄列各代表什麼、關鍵讀數與重點結論。
對於非圖表的視覺元素（時間軸、流程圖），請描述它的視覺比喻，以及每一個階段或元素。
### 步驟 5 — 重組與包裝（重組編輯）
- 依原順序重現所有區塊。
- **每一個區塊都用對應的語義化 XML 標籤包裹**（標籤對照見第五節）。
- 文字區塊把實際文字放進對應標籤；視覺與多媒體區塊放進分析內容並保留原圖說。
- 整份文件包在一個 `<document>` 根節點裡，組成一棵完整的語義化區塊樹。
---
## 五、輸出格式：全區塊語義化包裝
整頁就是一棵語義化的 XML 區塊樹。根節點用 `<document>`，內層每個區塊依類型套用對應標籤。
### 根節點
```xml
<document url="頁面網址" extraction-source="pixel-inspection | alt-text">
…依閱讀順序排列的各個區塊…
</document>
```
- `url` — 頁面來源網址。
- `extraction-source` — 視覺描述整體來自**直接像素檢視（pixel-inspection）**，還是**alt 文字加頁面數據（alt-text）**。
### 文字區塊
```xml
<heading level="2">小節標題文字</heading>
<paragraph>段落文字，依原文忠實重現。</paragraph>
<list type="unordered">
<item>清單項目一</item>
<item>清單項目二</item>
</list>
<blockquote>引言區塊的文字。</blockquote>
<callout>提示框、補充或旁註的文字。</callout>
<footnote id="1">註腳內容。</footnote>
```
- `<heading>` 的 `level` 對應原始標題層級（1、2、3…）。
- `<list>` 的 `type` 為 `ordered`（有序）或 `unordered`（無序）。
### 圖片區塊
```xml
<image-description figure="1" title="每人每季貢獻的程式碼量" type="vertical bar chart (time series)" source="pixel-inspection">
先用一段好讀的文字描述整張圖表的全貌，再用簡單條列說明座標軸、資料序列、
參考線、關鍵數字、可能的顏色，以及重點結論。推測的細節在行內標註（likely）。
</image-description>
```
### 影片區塊
```xml
<video-description figure="2" title="產品操作示範" source="影片網址" duration="3:42">
口語化描述影片內容、可辨識的章節或關鍵畫面，以及它想傳達什麼。
若無法播放，依標題、說明文字、字幕或縮圖描述，並標註（likely）。
</video-description>
```
### 表格區塊
```xml
<table figure="3" title="各方案功能比較">
<table-data>
| 方案 | 價格 | 儲存空間 |
| --- | --- | --- |
| 免費版 | 0 元 | 5 GB |
| 專業版 | 300 元 | 100 GB |
</table-data>
<table-summary>
一段口語化說明：這張表在比較什麼、欄列各代表什麼、關鍵讀數與重點結論。
</table-summary>
</table>
```
- `<table-data>` 忠實重現表格（用 Markdown 表格，或視需要改用 `<row>`／`<cell>` 結構）。
- `<table-summary>` 放口語化的分析。
### 圖說
如果某個視覺或多媒體區塊本來就有圖說，把圖說緊接在該區塊後面：
```xml
<caption figure="1">如何解讀這張圖：…</caption>
```
### 屬性慣例
- `figure` — 所有視覺與多媒體區塊共用一組依閱讀順序的穩定索引（0、1、2…）。
- `title` — 區塊本身的標題，或一個忠實的簡短標籤。
- `type` — 視覺元素的種類。
- `source` — 該區塊的描述來自 `pixel-inspection` 還是 `alt-text`。
（如果使用端需要更細的機器可解析結構，視覺區塊的內層可以再換成巢狀標籤，例如 `<axes>`、`<data-series>`、`<reference-lines>`、`<quantitative-readings>`、`<analytical-interpretation>`，但除非有要求，預設使用好讀的文字。）
---
## 六、來源標註與誠信守則（正面框架）
- 在 `<document>` 根節點用 `extraction-source` 標明整體描述來源，個別區塊若不同，再用該區塊的 `source` 屬性覆蓋。
- 凡是合理推測而非實際觀察到的細節，一律標註 **（likely）**。
- 只描述**實際觀察到、或頁面明確陳述**的數據點、座標軸數值與顏色；只要不確定，寧可標註（likely）或直接省略，保持誠實。
- 如果頁面本身有自我參照的量測但書（例如「成效由 AI 評審判定」），請把它呈現出來。
---
## 七、忠實與版權守則
- 文字區塊以頁面原文忠實重現，讓分析落在正確的位置，內容忠於原文即可。
- **保留原文語言：** 文字區塊維持原始文章的語言，不要自作主張翻譯；只有使用者明確要求時才翻譯。
- 摘要第三方文字時，引用保持簡短稀疏，優先用自己的話重寫。
- 歌詞、詩作、整段期刊或書籍內容，請改以你自己的話摘要呈現。
---
## 八、拿不到像素時的備援方案
如果直接下載、`web_fetch`、替代 CDN 主機等管道都被擋，請**先嘗試自己用瀏覽器工具突破封鎖**（見步驟 3 第 6 點）；只有在瀏覽器工具也無法使用或仍取不到時，才主動向使用者提供以下做法，最有把握的排在最前面：
1. **手上有瀏覽器工具就先自己用。** 如果環境掛載了 **Claude for Chrome** 或其他**瀏覽器使用（browser use）工具**，直接在真實瀏覽器裡打開頁面、讓圖片算繪出來、截圖再 `view`，多半能繞過 CDN 與防盜連封鎖，不必麻煩使用者。
2. **把圖片或截圖上傳到這裡** → 可以做到真正的像素級擷取（最佳做法之一）。
3. **在自己的瀏覽器裡使用客戶端瀏覽器代理**（例如 Claude for Chrome 擴充功能）打開頁面、截下圖表，再貼回來。（提醒：客戶端擴充功能無法從伺服器端的對話階段驅動，需要使用者自己執行並把截圖帶回來。）
4. **把 CDN 主機（例如 `cdn.sanity.io`）加進環境的網路白名單**，讓代理可以直接下載原始圖片。
---
## 九、交付規格
- 把還原後的頁面產出為單一檔案（預設 Markdown，內含語義化 XML 區塊）。
- **沿用原始文章的語言。** 文字區塊逐字保留原文的語言，不要自作主張翻譯（英文頁面就維持英文、日文頁面就維持日文）。代理自己產生的分析（圖片、影片描述與表格摘要）預設也用原文的語言，讓整份文件語言一致。只有在使用者明確要求翻譯時，才翻成指定語言。
- 如果之後有修訂（例如使用者上傳圖片後，把推測值換成實測值），請就地覆寫對應的區塊（`<image-description>`、`<video-description>`、`<table>` 等），而不是另外附上一份新文件。
---
## 十、驗收標準（Acceptance Criteria）
交付前，請逐項自我檢查；全部通過才算完成。使用者也可以拿這份清單來驗收。
### A. 完整性與順序
- [ ] 頁面裡的**每一個**區塊都被擷取，沒有遺漏文字、圖片、影片、表格或互動式元素。
- [ ] 所有區塊**依原始閱讀順序**排列，前後關係與原頁一致。
- [ ] 標題層級（H1、H2、H3…）對應原頁，沒有壓平或錯置。
- [ ] 多頁或多網址的輸入，每一頁都完整處理，且來源清楚可辨。
### B. 語義化包裝
- [ ] 整份文件包在單一 `<document>` 根節點裡，並帶 `url` 與 `extraction-source` 屬性。
- [ ] **每一個**區塊都用對應的語義標籤包裹，沒有任何裸露、未包裝的內容。
- [ ] 標籤用對類型：標題用 `<heading>`、段落用 `<paragraph>`、清單用 `<list>`／`<item>`、引言用 `<blockquote>`、提示框用 `<callout>`、註腳用 `<footnote>`、圖片用 `<image-description>`、影片用 `<video-description>`、表格用 `<table>`。
- [ ] 所有視覺與多媒體區塊都帶 `figure` 索引，且索引**依閱讀順序、不重複、不跳號**。
- [ ] 每個區塊都帶 `title`；視覺區塊另帶 `type` 與 `source`。
- [ ] 產出的 XML **格式正確且可解析**：標籤有開有合、屬性值有引號、特殊字元（`<`、`>`、`&`）已正確處理。
### C. 文字忠實度
- [ ] 文字區塊忠於原文，沒有改寫灌水，也沒有遺漏句子。
- [ ] 清單的有序／無序（`type`）標示正確，項目順序與原頁一致。
- [ ] 引言、圖說、註腳都放在正確的區塊與位置。
### D. 圖片與圖表擷取
- [ ] 每一張圖片都有對應的 `<image-description>`，內容是人看得懂的口語化文字。
- [ ] 圖表類描述涵蓋：圖表類型、座標軸（含單位與範圍）、資料序列與編碼、參考線與註解、量化讀數與走向、顏色與版面、重點結論。
- [ ] 非圖表的視覺元素（時間軸、流程圖）描述了視覺比喻與各階段或元素。
- [ ] 原頁若有圖說，已用 `<caption>` 保留在對應區塊旁。
### E. 影片與表格擷取
- [ ] 每段影片都有 `<video-description>`，涵蓋主題、章節或關鍵畫面、片長與來源、想傳達什麼。
- [ ] 每張表格都同時有 `<table-data>`（忠實重現欄、列、儲存格）與 `<table-summary>`（口語化分析）。
### F. 像素取得與封鎖突破
- [ ] 依步驟 3 的順序嘗試取得真實像素，能直接觀察就不用猜。
- [ ] 遇到 CDN 或其他封鎖時，**若環境有瀏覽器工具，已先嘗試用它突破封鎖**，才退回 alt 文字備援。
- [ ] 真的取不到像素時，已用 alt 文字加頁面數據產出最誠實的描述，流程沒有卡住或留白。
### G. 誠信與來源標註
- [ ] `<document>` 的 `extraction-source` 已標明整體描述來源（pixel-inspection 或 alt-text）；個別區塊不同時，已用該區塊的 `source` 覆蓋。
- [ ] 凡是推測而非觀察到的細節（顏色、數值、版面等），都標了 **（likely）**。
- [ ] 沒有虛構任何數據點、座標軸數值或顏色；不確定的部分寧可省略或標註。
- [ ] 頁面本身的量測但書（例如「成效由 AI 評審判定」）已呈現出來。
### H. 版權與引用
- [ ] 第三方文字以自己的話為主，逐字引用簡短且稀疏。
- [ ] 沒有重現歌詞、詩作、整段期刊或書籍內容（這類一律改成摘要）。
### I. 交付形式
- [ ] 成果是**單一檔案**（預設 Markdown，內含語義化 XML 區塊）。
- [ ] 有修訂時，是**就地覆寫**對應區塊，而不是另外附一份新文件。
- [ ] 還原後的頁面**沿用原始文章的語言**，文字區塊逐字保留原文，沒有自作主張翻譯；只有使用者明確要求時才翻譯。
- [ ] 代理自己產生的分析（圖片、影片描述與表格摘要）**預設也用原文的語言**，讓整份文件語言一致。
---提取結果
以下是 Anthropic 今日爆款文『When AI builds itself』網頁的提取結果
<document url="https://readwise.io/reader/shared/01ktd9djvcj3wpdetxy6sxspyp" extraction-source="pixel-inspection">
<callout>This shared page is a Readwise Reader wrapper; the canonical article lives on anthropic.com (https://www.anthropic.com/institute/recursive-self-improvement). The three data charts were downloaded as original images and inspected pixel-by-pixel, so their descriptions reflect direct observation. The opening graphic was flattened by the reader into plain text tokens, so it is described from alt-text and page context with (likely) tags. Annotated by SHIH YEN.</callout>
<heading level="1">When AI builds itself</heading>
<paragraph>Author: anthropic.com</paragraph>
<paragraph>Length: • 20 mins</paragraph>
<paragraph>Annotated by SHIH YEN</paragraph>
<paragraph>For most of AI's history, humans drove every step in its development cycle. But at Anthropic, we are delegating a growing share of AI development to AI systems themselves, which is speeding up our work.</paragraph>
<paragraph>Taken far enough, and given enough compute, that trend points to an AI system capable of fully autonomously designing and developing its own successor. This is called <em>recursive self-improvement</em>. We are not there yet, and recursive self-improvement is not inevitable. But it could come sooner than most institutions are prepared for.</paragraph>
<paragraph>Using public benchmarks and previously unreported data from within Anthropic, The Anthropic Institute is showing that AI is already accelerating the development of AI systems. To take just one example: today, Anthropic engineers on average ship 8x as much code per quarter as they did from 2021-2025.</paragraph>
<paragraph>The technical trends discussed in this piece suggest that AI systems are going to become much more capable in coming years. These trends have huge implications. AI that can build itself would be a major development in the history of technology—one that could bring enormous good for the world in science, healthcare, and beyond. But full recursive self-improvement also might increase the risks of humans losing control over AI systems. If systems are capable of fully building their own successors, the ways we secure them, monitor them, and shape their behavior all grow much more important.</paragraph>
<image-description figure="0" title="From person to workers: an animated illustration of AI's evolving role in development" type="interactive scrollytelling / animated illustration (likely)" source="alt-text">
At this point the page carries an interactive / scroll-triggered animated graphic that the reader flattened into a single run of repeating, stacking words: person → computer → chatbot → agent → workers. It uses a visual metaphor for the stepwise evolution of the role AI plays in the development workflow: it begins as just a "person," then adds a "computer," then a "chatbot," then an autonomous "agent," and finally stacks into a crowd of "workers." Each stage accretes on top of the previous one, implying capabilities that pile up layer by layer rather than replacing one another (likely). The overall palette and layout follow Anthropic's usual warm-tone, generous-whitespace style (likely). Its message: AI has progressed from a passive tool into a workforce that can carry out whole stretches of work on a person's behalf.
</image-description>
<paragraph>As the agents became more capable, they were able to write and edit code on their own, sometimes entire files.</paragraph>
<paragraph>In the future, agents could become capable enough to build and train models themselves. If this happens, future versions of Claude could be continuously improved by Claude itself.</paragraph>
<heading level="3">Evidence from the outside world</heading>
<paragraph>The rate at which AI models improve is accelerating. The length of tasks that they can reliably complete on their own has been doubling roughly every four months, up from an earlier trend of doubling every seven months. In March 2024, Claude Opus 3 could complete software tasks that take humans about four minutes to complete. A year later, Claude Sonnet 3.7 managed tasks that took about an hour and a half. A year after that, Claude Opus 4.6 managed 12-hour tasks.¹ If this trend holds, tasks that take a skilled person days could come into range this year. In 2027, AI systems could be capable of tasks that take a person weeks.</paragraph>
<paragraph>The same pattern appears on coding and research benchmarks. Benchmarks measure the performance of models in a given domain, and they're "saturated" when models achieve close to 100% performance.² SWE-bench is a standard test of real-world software engineering: it hands a model an actual open-source codebase and a real bug report, and asks it to write a code change that fixes the issue and passes the project's own tests. Models have gone from scoring in the low single digits to saturating the benchmark in two years.</paragraph>
<paragraph>CORE-Bench tests whether a model can reproduce existing research, a prerequisite for them to conduct original research. It gives an AI model the code and data behind a published paper, and asks it to rerun everything and confirm it can replicate the paper's results. AI systems went from succeeding at reproducing the results roughly 20% of the time in 2024 to saturating the benchmark fifteen months later. METR, which runs the benchmark measuring how well models can complete long-duration tasks, found that Claude Mythos Preview could work for "at least" 16 hours and was "at the upper end of what [METR] can measure without new tasks."</paragraph>
<paragraph>Public benchmarks say a lot about the capabilities of these systems. But they can't reveal the impact AI systems are having on speeding up AI development itself. For that, we need direct evidence from within AI companies like Anthropic.</paragraph>
<heading level="3">Evidence from within Anthropic</heading>
<paragraph>Building a frontier model takes two broad categories of work. There is <em>engineering</em>: writing the code, standing up the infrastructure, and overseeing the model training. And there is <em>research</em>: deciding what experiments to run, interpreting what comes back, and figuring out which ideas to try next.</paragraph>
<paragraph>Across both engineering and research, the picture is consistent. In engineering, Claude can be handed an underspecified problem and figure out how to solve it; humans supply the goal, but they no longer need to supply the method. In research, Claude can already match or outperform skilled humans at executing a well-specified experiment. However, large performance gaps persist when it comes to Claude exercising judgement in choosing goals in both engineering and research. That's the gap between AI today and a future system that could autonomously design its own successor.</paragraph>
<paragraph>It's common for employees at Anthropic to receive more open-ended and important tasks as they gain more experience. Early on, they execute a task someone else specified, like, <em>"The export button isn't working, please fix it."</em> With experience, they're handed a goal and design the approach themselves, such as, <em>"Investigate why the network slows down under heavy load."</em> At the most senior levels, they are deciding which problems are worth working on at all: <em>"What should the team build next quarter?"</em> We can use internal Anthropic data to see how far Claude has come in being able to handle these different kinds of tasks.</paragraph>
<paragraph><strong>Claude writes a significant proportion of Anthropic's code.</strong> As of May 2026, more than 80% of the code we merge into Anthropic's codebase was authored by Claude.³ Before Claude Code launched in research preview in February 2025, this number was in the low single digits. That shift also shows up in the amount of output per engineer. Lines of code merged per engineer per day stayed constant through Anthropic's first four years (2021-2024), then began to climb upward in 2025 when Claude began to run code rather than just suggesting it for an engineer to copy and paste. The slope steepened again in 2026 when models began to work autonomously over longer time horizons. These two inflection points are shown in the chart below. In the second quarter of 2026, the typical engineer was merging 8× as much code per day as they were in 2024.⁴ This is because much of the code is written by Claude, with the engineer directing and reviewing, rather than typing it themselves.</paragraph>
<image-description figure="1" title="Code contributed per person, by quarter" type="vertical bar chart (time series)" source="pixel-inspection">
A vertical bar chart titled "Code contributed per person, by quarter," running from Q2 2021 to Q2 2026, one orange-red (terracotta) bar per quarter. The headline shape: it hugs the floor for the first four years, lifts in 2025, surges in 2026, and the final bar shoots up to 8×.
Axes and scale: the y-axis is a multiple of the "pre-2025 average," marked 0× to 11× in 1× steps; the x-axis is quarters, left to right, labeled 2021 Q2 → 2022 (Q1–Q4) → 2023 → 2024 → 2025 → 2026 Q2. A faint grey horizontal baseline sits near 1×, annotated "average before 2025."
Data series and readings: every bar from 2021–2024 stays pinned around 1× (roughly 0.7×–1.4×, small fluctuations), with no visible trend. The turn begins in 2025: 2025 Q1 ≈ 1.2×, Q2 1.5×, Q3 1.9×, Q4 2.5×; then 2026 Q1 jumps to 5.8× and 2026 Q2 reaches 8.0×. Each bar from 2025 onward is labeled at its top with its multiple in orange (1.2×, 1.5×, 1.9×, 2.5×, 5.8×, 8.0×).
Reference lines and annotations: along the top, grey dashed lines mark the public release dates of eight models, left to right: Claude 1 release, Claude 2, Claude 3, Claude 4, Claude Code, Claude Sonnet 4.5, Claude Opus 4.5, Mythos Preview (internal access), and Claude Mythos Preview. The releases visibly bunch up toward the right (2025–2026), aligning with where the bars start to surge.
Color and layout: bars are solid terracotta; the final bar (2026 Q2) is rendered with diagonal hatching, and the caption notes it is a "partial quarter," counting only the days observed so far rather than a full quarter.
What it's saying: code output shows a first inflection in 2025 (Claude starts actually running code) and a second, steeper inflection in 2026 (models begin working autonomously over longer horizons), reaching 8×. But the author cautions, both in the body and the caption, that lines of code measure quantity over quality, so 8× almost certainly overstates the true productivity gain.
</image-description>
...中間省略
</document>
