Jkeeper 發佈的文章

你以為 AI 只是幫你寫報告、生圖片的小助手?Karen Hao 的《AI 帝國》會告訴你:醒醒,這早就不是技術問題了,這是一場權力重新分配的遊戲。

Karen Hao 是少數能把 AI 產業寫得像地緣政治分析的記者。她在《AI 帝國》裡做的事情很簡單——把那些矽谷巨頭包裝在「讓世界更美好」底下的東西,一層一層剝開。

剝開之後你會看到什麼?

資料的壟斷、算力的軍備競賽、還有一套「我來制定規則,你來遵守」的權力邏輯。

這跟歷史上的帝國擴張,本質上沒有區別。只不過以前搶的是土地和石油,現在搶的是數據和晶片。

- 閱讀剩餘部分 -

從昨天的數據來分析 $10/月 實際上大概能用的總金額,下圖是昨天到今天的使用量

┌────────────┬───────────────┬───────────┬───────────┬───────────────┬─────────────┬───────────────┬─────────────┐
│ Date       │ Models        │     Input │    Output │  Cache Create │  Cache Read │  Total Tokens │  Cost (USD) │
├────────────┼───────────────┼───────────┼───────────┼───────────────┼─────────────┼───────────────┼─────────────┤
│ Project: J │               │           │           │               │             │               │             │
├────────────┼───────────────┼───────────┼───────────┼───────────────┼─────────────┼───────────────┼─────────────┤
│ 2026-04-09 │ - haiku-4-5   │       406 │    42,986 │       477,088 │  12,547,364 │    13,067,844 │       $5.13 │
│            │ - sonnet-4-6  │           │           │               │             │               │             │
├────────────┼───────────────┼───────────┼───────────┼───────────────┼─────────────┼───────────────┼─────────────┤
│ 2026-04-10 │ - haiku-4-5   │     2,254 │    14,506 │       264,462 │   5,590,877 │     5,872,099 │       $2.62 │
│            │ - sonnet-4-6  │           │           │               │             │               │             │
├────────────┼───────────────┼───────────┼───────────┼───────────────┼─────────────┼───────────────┼─────────────┤
│ Project: J │               │           │           │               │             │               │             │
├────────────┼───────────────┼───────────┼───────────┼───────────────┼─────────────┼───────────────┼─────────────┤
│ 2026-04-09 │ - sonnet-4-6  │       169 │    93,469 │       229,481 │  12,690,029 │    13,013,148 │       $6.07 │
├────────────┼───────────────┼───────────┼───────────┼───────────────┼─────────────┼───────────────┼─────────────┤
│ 2026-04-10 │ - sonnet-4-6  │         7 │     2,009 │        87,456 │     365,925 │       455,397 │       $0.47 │
├────────────┼───────────────┼───────────┼───────────┼───────────────┼─────────────┼───────────────┼─────────────┤
│ Project: G │               │           │           │               │             │               │             │
├────────────┼───────────────┼───────────┼───────────┼───────────────┼─────────────┼───────────────┼─────────────┤
│ 2026-04-10 │ - sonnet-4-6  │        41 │    30,639 │        57,122 │   1,193,695 │     1,281,497 │       $1.03 │
├────────────┼───────────────┼───────────┼───────────┼───────────────┼─────────────┼───────────────┼─────────────┤
│ Total      │               │     2,877 │   183,609 │     1,115,609 │  32,387,890 │    33,689,985 │      $15.32 │
└────────────┴───────────────┴───────────┴───────────┴───────────────┴─────────────┴───────────────┴─────────────┘

然後目前周額度在 23%

- 閱讀剩餘部分 -

Claude Code 的「7層金字塔結構」是指它的記憶體優先級層次(Memory Hierarchy)。完整的 7 層結構如下,優先級由高到低:

優先級 來源 生命週期
1(最高) System instructions(內建系統指令) 永久內建
2 Global CLAUDE.md(~/.claude/CLAUDE.md 永久
3 Project CLAUDE.md(專案根目錄) 永久
4 CLAUDE.local.md(本地個人設定) 永久
5 Auto memory(MEMORY.md 自動記憶) 持久
6 Conversation history(當次對話歷史) 僅限本次 session
7(最低) Compacted summaries(壓縮摘要) 僅限本次 session

高優先級的層會覆蓋低優先級的層。例如,CLAUDE.md 裡寫「使用 tabs」會蓋過壓縮摘要裡的「使用 spaces」。 Skills Playground

各層說明

層 1–3(永久指令):CLAUDE.md 是最核心的記憶機制,你手動撰寫,每次 session 啟動時自動載入,包含架構規範、建置指令、開發慣例等。 Skills PlaygroundClaude

層 5(Auto Memory):Claude 在工作過程中自動學習並寫入的記憶,分為四種類型:user(角色偏好)、feedback(修正確認)、project(決策背景)、reference(外部資源位置)。不需要你手動撰寫,Claude 自行判斷什麼值得記住。 DEV Community

層 6–7(Session 層):對話歷史和壓縮摘要只存在於當次 session,新 session 開啟後即消失。 Skills Playground


補充:另一個「7層」的解讀

從 Claude Code 洩漏原始碼的逆向工程角度,還有另一種 7 層架構:指的是從毫秒級的 token 剪枝(token pruning)到數小時背景「dreaming」整合的記憶管理系統,每層成本遞增但功能更強大,設計上讓低成本層能阻止更昂貴層的觸發。 X.com

/context

70412-429nqtsk9bh.png

55040-o62qugc2lq.png

出現有趣的提示

File reads 佔 74.1k tokens (7%) → 可節省 ~22.2k 如果你在重複 read 同一個檔案,改用
offset/limit 或直接引用之前的結果就好

claude 建議是這兩點

  1. Grep 定位 → offset/limit 精準讀 → Edit
  2. 不重複讀已編輯過且記得內容的區段

總覺得這樣并不保險,討論後修改如下,就是比較麻煩,如果套用在項目必須所有成員都有共識,不然隨意修改可能會出現

## 檔案讀取規則
- 預設信任上次 Edit 的結果,不重新讀取驗證
- 除非用戶明確說以下情況:
  - 「我手動修改了 X 檔案」
  - 「我剛 git pull / git checkout」
  - 「這個檔案被外部程式修改了」
- 收到以上提示才重新 Read 指定檔案

## 出現以下情況主動告知用戶需要重新讀取
- Edit 失敗找不到目標字串
- 邏輯上感覺檔案狀態和記憶不符
- 距離上次讀取已經超過 10 次對話回合