小編精選 - 技術文章翻譯 · 06月15日

Claude Code 的產品哲學：當價值觀成為架構

前一篇我們討論了關於 TUI 的技術演進。但是一個月前再看 Claude Code 的程式碼，並對比四個 AI Coding 工具的設計和架構時，有個問題一直在我腦海中迴盪：**四家最具影響力的 AI Coding 工具（Claude Code、Codex CLI、Gemini CLI、Aider）不約而同選擇了終端機作為主要介面，但它們的技術路線卻南轅北轍。這種分化說明什麼？**

我目前能回答的是（也許過一段時間後這個答案會變化，但不管了，先寫下來吧 (¯_¯;) ）：TUI 不是目的，而是手段。真正的分歧在於「在 AI Coding 時，我們想建立什麼樣的協作關係」。

OpenAI 選擇 Rust + Ratatui 的全螢幕獨佔模式，追求極致效能和零依賴發佈，他隱含的產品定位始終都是「終端機中的 IDE」——一個完整、自包含、與系統最小耦合的獨立應用程式。
Google 選擇第三方 Ink 的開放生態路線，隱含的定位是「模型能力的管道」——快速整合、借力社群、專注核心。
Anthropic 選擇自研 Ink + React + TypeScript，隱含的定位是「開發者的協作夥伴」——需要深度嵌入開發者既有的工作流程，需要理解開發者既有的心智模型，需要在開發者最熟悉的情境中提供幫助。

技術路線是產品意圖的投影。不理解產品意圖，技術分析也會變成一場沒有地圖的考古；換句話說，我們能描述每一件陶器的形狀，卻無法理解這個文明為何如此塑造它們。我以前在閱讀 React 原始碼的時候就犯過這個錯，只會埋頭看程式碼，對程式碼進行分析。

這也是這篇文章想要達到的目標：在技術解構之前，先建立價值座標系。 我們將從 Claude Code 的 README 出發，理解他的產品定位；從 Anthropic 的「Helpful, Harmless, Honest」出發，理解他價值觀是怎麼被工程化為具體的系統架構；並從中提煉出對前端有普遍意義的工程思維。但是這個目標很大，可能還是沒辦法達到，只能說盡力往這個方向靠，思考的歷史侷限性可能還是依舊存在，有問題，望指出。

從 README 看產品定位：「AI teammate in the terminal」的深層架構

Claude Code 的原始碼 README 極其簡潔——只有版本號、建置說明和快速開始指南。但原始 npm 套件的官方描述提供了關鍵的產品定位線索：「your AI teammate in the terminal」。這六個單字值得逐字拆解。

「teammate」：協作而非取代

「Teammate」而不是「assistant」、「copilot」、「tool」——這個詞的選擇本身就構成了一種產品宣言。teammate 之間的關係是 對等協作：你有你的專長，我有我的專長；我們共同對結果負責；你可以提出建議，但最終決策權在我們手中。這種對等關係直接映射到 Claude Code 的互動設計：

建議權 vs. 執行權：Claude Code 可以建議執行 BashTool 命令，但使用者擁有最終確認權（除非在特定的自動模式下）。這與 Copilot 的「自動完成」模式不同——Copilot 在使用者打字時直接修改編輯器內容，而 Claude Code 在工具呼叫前停下來等待確認。
上下文共享：teammate 共享同一個工作空間。Claude Code 不是在一個隔離的沙箱中操作，而是直接在使用者的專案目錄中讀取檔案、執行命令、修改程式碼。這種「共享工作空間」的設計讓 Claude Code 能看到使用者能看到的全部上下文——.gitignore 規則、環境變數、在地設定。
持續在場：teammate 不是一次性服務。Claude Code 的工作階段記憶（SessionMemory，出處：src/services/SessionMemory/）和自動壓縮機制（autoCompact.ts）使得一次對話可以持續數小時、跨越數百輪互動，而不丟失上下文。

上面圖片對比了兩種 AI 程式設計助手的協作模型。這不是也不是有優劣之分，而是產品意圖的不一樣：Claude Code 追求的是 「擴展能力邊界」，Copilot 追求的是 「減少打字」。前者優化的是問題解決能力，後者優化的是輸入效率。對前端而言，這類似於「設計系統」與「程式碼片段庫」的區別——前者給我們建構元件的方法論和工具鏈，後者給我們現成的元件。

「in the terminal」：嵌入而非附加

「in the terminal」比「for the terminal」或「with the terminal」更精確。「in」意味著沉浸、嵌入、不可分離。Claude Code 不是終端機外的一個應用程式，不是透過 API 與終端機通訊的外部服務，而是直接在終端機程序內部執行，與 Shell 環境、檔案系統、Git 倉庫、Node.js 執行環境處於同一個作業系統情境中。

這種嵌入性的架構含義也是深遠的：

環境繼承：Claude Code 繼承目前 Shell 的環境變數、工作目錄、別名、函式。這與 VS Code 的整合式終端機不同——VS Code 的終端機是 IDE 的子程序，而 Claude Code 是 Shell 的對等程序（甚至可以在 REPL 模式下直接執行 JavaScript）。
無情境切換成本：使用者不需要「打開一個應用程式」然後「切換回終端機」——Claude Code 就是終端機。之前討論的心流狀態和鍵盤效率，在這裡也成了產品定位的架構保障。
Unix 相容：因為嵌入在終端機中，Claude Code 的輸出可以被管線傳遞給其他命令，可以被重新導向到檔案，可以被腳本化呼叫。這種相容性是「teammate」模型的自然延伸——一個合格的 teammate 應該能與團隊中的其他工具協作。

產品定位的「同心圓」模型

結合上面的分析，我們可以畫出 Claude Code 產品定位的同心圓模型：

上圖的同心圓從內到外依序是：核心身份（AI teammate）→ 存在域（in the terminal）→ 能力範圍（software engineering tasks）→ 價值約束（Helpful, Harmless, Honest）。每一層都約束著外層的實作方式：因為我們是 teammate 而非 tool，所以我們需要共享工作空間而非隔離沙箱；因為我們在 terminal 中，所以我們需要相容 Unix 管線而非輸出封閉格式；因為我們處理 software engineering tasks，所以我們需要理解程式碼、Git、測試、建置等工程情境；因為我們遵循三個價值觀，所以我們需要權限系統、安全邊界和透明機制。

這個同心圓模型是後續所有技術分析的起點。當我們討論 Ink 的自研決策時，可以追溯到「in the terminal」的沉浸需求；當我們討論工具系統的 30+ 工具時，可以追溯到「software engineering tasks」的能力範圍；當我們討論權限系統的三層防禦時，可以追溯到「Harmless」的價值約束。

Helpful：從「功能堆砌」到「意圖理解」

「Helpful」在產品層面通常被理解為「功能多、回應快」。但 Claude Code 對「Helpful」的定義更加精確：理解使用者意圖，而非僅僅執行使用者指令。

系統提示中的 Agent 定位

在 src/constants/prompts.ts 中，Claude Code 的系統提示開篇即明確定義了自身角色：

typescript 体验AI代码助手 代码解读复制代码function getSimpleIntroSection(
  outputStyleConfig: OutputStyleConfig | null,
): string {
  return `
You are an interactive agent that helps users ${
      outputStyleConfig !== null
        ? 'according to your "Output Style" below...'
        : 'with software engineering tasks.'
    } Use the instructions below and the tools available to you to assist the user.`
}

注意措辭的精確性：「interactive agent」而不是「command executor」，「helps users with software engineering tasks」而不是「answers questions」。這個定位決定了整個系統的互動設計——Claude Code 不是等待使用者輸入然後回傳結果的被動工具，而是 主動理解情境、規劃行動路徑、呼叫工具執行、回饋執行結果 的協作智慧體。在看到這個 prompts 時，突然覺得之前寫的 prompts 都白寫了，措辭不夠精確、定位不夠清楚、規劃不夠明白，只把 AI 當成能夠對話的「人」了，而不是能夠真正執行完整任務的實習生。

這種「Agent」定位直接影響了 30+ 工具系統的設計。每個工具都不是孤立的功能點，而是 Agent 能力的延伸：

BashTool 不只是執行命令，它還會判斷命令的安全性；
FileEditTool 不只是修改檔案，它還會追蹤 Git 情境；
TaskCreateTool 不只是建立子任務，它還會監控子任務的執行狀態和輸出。

這種「工具即能力延伸」的設計哲學，與前端工程中「元件即 UI 的延伸」是完全平行的——Button 元件不只是可點擊區域，它還承載了停用狀態、載入狀態、焦點管理、ARIA 語意等完整的互動語意。

從命令到意圖：互動層級的躍遷

傳統 CLI 工具的互動模型是 「命令→執行→輸出」 的單層結構。Claude Code 引入了三層互動模型：

意圖層：使用者用自然語言表達目標（「幫我優化這個元件的效能」）。
規劃層：Agent 將意圖拆解為可執行的工具呼叫序列——先讀取檔案、再分析程式碼、再執行優化、最後執行測試驗證。
執行層：工具系統在本地環境中實際執行操作，並將結果回饋給規劃層。

上圖展示了 Claude Code 的三層互動模型。這種模型對前端來說並不陌生——它與現代前端框架中的「資料層→狀態管理層→視圖層」三層架構有著深刻的同構性。使用者的自然語言輸入對應「使用者事件」，規劃層的工具呼叫序列對應「狀態變更 action」，執行層的本地操作對應「副作用（side effect）」。Claude Code 的「Helpful」哲學，本質上是在終端機環境中實現了意圖驅動的副作用編排系統。

上下文感知：Helpful 的根基

真正的「Helpful」需要理解上下文。Claude Code 的上下文系統是其產品哲學中最精密的部分之一。getSystemPrompt() 函式（出處：src/constants/prompts.ts）組裝了數十個系統提示片段，每一個片段都服務於「讓 Agent 更理解當前情境」：

環境上下文：目前作業系統、Shell 類型、Git 狀態、Node.js 版本。
專案上下文：專案結構、技術棧（透過 package.json 等檔案推斷）、最近的修改歷史。
工作階段上下文：對話歷史、已執行的工具呼叫、使用者之前的確認/拒絕模式。
使用者偏好：語言偏好、輸出風格設定（OutputStyleConfig）、權限模式設定。

這些上下文資訊不是簡單拼接的字串，而是透過 systemPromptSection() 和 DANGEROUS_uncachedSystemPromptSection() 進行分層快取管理（出處：src/constants/systemPromptSections.ts）。靜態內容（如通用系統指令）使用全域快取跨工作階段重複利用，動態內容（如目前 Git 狀態）每輪重新計算。這種「快取分層」的工程決策，直接源自「Helpful」哲學中「既要全面理解上下文，又要高效利用資源」的雙重訴求。

上圖展示了 Claude Code 系統提示的快取分層架構（出處：src/constants/prompts.ts 中 SYSTEM_PROMPT_DYNAMIC_BOUNDARY 註解）。這個邊界設計精妙之處在於：它不僅是效能最佳化手段，更是產品透明性的工程保障——靜態部分是所有使用者共享的通用指令，動態部分是工作階段特定的個人化內容。使用者如果查閱系統提示，可以清楚地看到「哪些是產品的固定行為，哪些是目前工作階段的情境資訊」。

Harmless：安全不是功能的阻礙，而是信任的基石

「Harmless」是三個價值觀中最難工程化的。它要求在「幫助使用者完成任務」和「防止造成傷害」之間建立精確的邊界。Claude Code 的安全架構不是事後加上的補丁，而是貫穿整個系統的預設安全設計（Secure-by-Design）。

CYBER_RISK_INSTRUCTION：安全邊界的文字化

在 src/constants/cyberRiskInstruction.ts 中，有一段被明確標記為「Safeguards 團隊所有，修改需核准」的安全指令：

typescript 体验AI代码助手 代码解读复制代码export const CYBER_RISK_INSTRUCTION = `IMPORTANT: Assist with authorized security testing, 
defensive security, CTF challenges, and educational contexts. 
Refuse requests for destructive techniques, DoS attacks, mass targeting, 
supply chain compromise, or detection evasion for malicious purposes. 
Dual-use security tools (C2 frameworks, credential testing, exploit development) 
require clear authorization context: pentesting engagements, CTF competitions, 
security research, or defensive use cases.`

這段指令的文字看似簡單，但其工程價值在於精確性。它沒有使用模糊的「不要做壞事」式措辭，而是明確劃分了四個安全區域：

安全區域允許的行為拒絕的行為
授權安全測試 滲透測試、弱點掃描未授權的系統入侵
防禦性安全 防火牆設定、入侵偵測攻擊工具的開發
教育場景 CTF 競賽、安全課程惡意技術的教學
雙用途工具 密碼測試（明確授權下） C2 框架、漏洞利用開發（無授權）

這種精確性對前端有重要啟示：安全策略的模糊性是漏洞的溫床。 在 Web 應用中，我們經常看到「過濾使用者輸入」這種模糊的安全策略；而 Claude Code 的做法是，將安全邊界文字化、可稽核、可測試——每一段系統提示都經過 Safeguards 團隊的審查，每一次修改都有明確的核准流程。

權限系統的三層防禦

Claude Code 的權限系統（src/utils/permissions/ 目錄）是其「Harmless」思考的工程傑作。它不是一個簡單的「允許/拒絕」開關，而是一個三層防禦體系：

第一層：權限模式（Permission Mode）

PermissionMode.ts 中定義了六種權限模式，構成一個從「最保守」到「最開放」的層級（出處：src/utils/permissions/PermissionMode.ts）：

typescript 体验AI代码助手 代码解读复制代码const PERMISSION_MODE_CONFIG = {
  default:     { title: 'Default',      color: 'text' },      // 逐個詢問
  plan:        { title: 'Plan Mode',    color: 'planMode' },  // 唯讀 + 規劃
  acceptEdits: { title: 'Accept edits', color: 'autoAccept' },// 自動接受檔案編輯
  auto:        { title: 'Auto mode',    color: 'warning' },   // 分類器判斷
  bypassPermissions: { title: 'Bypass Permissions', color: 'error' }, // 危險
  dontAsk:     { title: "Don't Ask",    color: 'error' },     // 極端危險
}

這個層級的設計本身就是產品哲學的體現：安全不是二元對立，而是漸進增長的層級。 使用者可以從最保守的「逐個詢問」開始，隨著對 Claude Code 的信任加深，逐步過渡到「自動接受編輯」甚至「自動模式」。但即使是最開放的 auto 模式，也有一個安全網——分類器（classifier）會在背景評估每個工具呼叫的風險等級。

第二層：權限規則引擎（Permission Rule Engine）

權限規則不是簡單的全域開關，而是基於內容的精細化比對。PermissionRule 的資料結構（出處：src/utils/permissions/PermissionRule.ts）包含四個維度：工具名稱、規則內容、行為（allow/ask/deny）、規則來源。這種四維結構使得權限規則可以精確到「只允許 BashTool 執行 npm install 和 git status，但其他命令仍需詢問」。

第三層：危險模式辨識（Dangerous Pattern Detection）

即使權限規則允許了某個工具，系統還會進行執行期危險檢測。dangerousPatterns.ts 中定義了 DANGEROUS_BASH_PATTERNS 和 CROSS_PLATFORM_CODE_EXEC（出處：src/utils/permissions/dangerousPatterns.ts）。isDangerousBashPermission() 函式使用啟發式規則判斷一個 Bash 權限設定是否危險：如果規則允許了 python:* 或 node* 這類前綴比對，系統會將其標記為危險，阻止自動模式的啟用。

上圖展示了 Claude Code 權限系統的三層防禦體系。任何一層發現異常，都會將決策降級為「詢問使用者」。這是經典的「縱深防禦」（Defense in Depth）策略在終端機工具中的完美實踐。

沙箱與隔離：Harmless 的物理保障

當權限系統無法完全消除風險時，Claude Code 轉向程序級隔離。forkedAgent.ts（出處：src/utils/forkedAgent.ts）實現了子代理的隔離執行：每個子代理執行在一個獨立的 Node.js 程序中，擁有獨立的記憶體空間和檔案系統視圖。這種隔離策略與前端工程中的微前端架構有著有趣的平行——微前端透過 iframe 或 Shadow DOM 實現執行期隔離，Claude Code 透過子程序和 Git 工作樹實現執行隔離。兩者都遵循同一個原則：不信任任何元件/代理的預設安全性，透過架構隔離將潛在損害的爆炸半徑控制在最小範圍。

Honest：透明是可被驗證的信任

「Honest」在工程層面意味著兩件事：對使用者透明（使用者知道系統在做什麼、為什麼這樣做），和對資料誠實（系統不隱瞞、不竄改、不過度收集）。

系統提示的透明性：使用者可查閱的「大腦」

Claude Code 最體現「Honest」哲學的設計之一是：使用者可以查閱系統提示。 在大多數 AI 產品中，系統提示是黑盒——使用者不知道模型被灌輸了什麼指令，也不知道為什麼模型會做出某種行為。Claude Code 透過 /status 命令展示了完整的系統提示結構，甚至將提示分成了「可快取的靜態部分」和「工作階段特定的動態部分」。

systemPromptSections.ts 中的架構設計（出處：src/constants/systemPromptSections.ts）使得提示的組裝過程完全可追蹤：

typescript 体验AI代码助手 代码解读复制代码type SystemPromptSection = {
  name: string        // 片段名稱，如 "System", "Hooks", "DoingTasks"
  compute: ComputeFn  // 計算函式，回傳該片段的文字內容
  cacheBreak: boolean // 是否打破快取（動態內容）
}

每個提示片段都有名稱和計算函式，使用者可以透過除錯輸出或 /status 看到「目前系統提示由哪些片段組成，每個片段的內容是什麼」。這種設計使得 Claude Code 的「大腦」不是黑盒，而是使用者可以理解、可以驗證的白盒。

權限決策的可解釋性：為什麼允許/拒絕

Claude Code 的權限系統不僅給出「允許」或「拒絕」的結論，還給出決策理由。createPermissionRequestMessage() 函式（出處：src/utils/permissions/permissions.ts）會根據決策原因生成不同的提示文字：當自動模式的分類器決定某個工具呼叫需要使用者確認時，它會告訴使用者：「是哪个分類器做出了這個判斷」、「判斷的理由是什麼」。這種可解釋性對建立使用者信任至關重要——使用者不會因為「系統莫名其妙地阻止了我」而感到挫折，而是理解「系統發現了什麼潛在風險」。

遙測資料的 PII 保護：誠實的另一面

「Honest」不僅意味著「告訴使用者我們在做什麼」，還意味著「不收集我們不應該收集的資料」。Claude Code 的遙測系統（src/services/analytics/index.ts）中有一個精妙的型別設計（出處：src/services/analytics/index.ts）：

typescript 体验AI代码助手 代码解读复制代码export type AnalyticsMetadata_I_VERIFIED_THIS_IS_NOT_CODE_OR_FILEPATHS = never

這個型別是一個編譯期標記：任何要記錄到遙測系統的字串，都必須經過顯式型別斷言，證明它不包含程式碼片段、檔案路徑或其他敏感資訊。這不是執行期的檢查（可以被繞過），而是TypeScript 型別系統的強制約束——如果我們試圖傳入一個未經審查的字串，編譯會失敗。

這種設計體現了「Honest」哲學的工程深度：隱私保護不是依賴工程師的自覺，而是透過型別系統編碼到編譯流程中。 這與前端工程中「透過 TypeScript 型別系統防止執行期錯誤」的實踐完全一致，只是保護的對象從「程式碼正確性」擴展到了「資料隱私性」。

上圖展示了 Claude Code 透明性機制與使用者信任之間的關係。三種透明機制分別對應三種信任需求：系統提示的可見性回答了「它在想什麼」，權限決策的解釋性回答了「它為什麼這樣做」，遙測資料的去識別化約束回答了「它知道什麼」。

使用者主權：漸進授權的信任模型

「使用者主權」（User Sovereignty）是 Claude Code 產品哲學中一個隱含但貫穿始終的主題。它不是 Anthropic 公開宣揚的三個價值觀之一，但在工程實作中無處不在。

七級設定瀑布：控制權的精細化分配

Claude Code 的設定系統是其使用者主權哲學的最直接體現。settings.ts 中實現了七級設定來源（出處：src/utils/settings/constants.ts）：

Defaults：產品預設設定。
Bundled：捆綁的設定（如內建技能設定）。
Plugin：外掛提供的設定。
Managed：企業/團隊管理員下發的策略設定。
Project：專案層級設定（.claude/settings.json）。
User：使用者層級設定（~/.claude/settings.json）。
CLI Args：命令列參數（最高優先級）。

這種七級架構不是過度設計，而是控制權分配的民主化：管理員可以設定安全策略（Managed），專案負責人可以設定專案規範（Project），個人開發者可以設定個人偏好（User），臨時場景可以透過 CLI 參數覆蓋（CLI Args）。每一層都在其權限範圍內行使控制權，同時尊重更高優先級的約束。

上圖展示了 Claude Code 的七級設定瀑布。這種設計對前端有直接的啟示：設定系統本質上是權力分配系統。 在設計元件庫或應用框架時，我們常常需要回答「誰有權力修改這個行為？」Claude Code 的答案是一個精細的層級結構，而不是簡單的「全域設定 vs 區域設定」二元對立。

從「預設拒絕」到「漸進信任」

使用者主權的另一個體現是 Claude Code 的預設安全姿態。新使用者首次啟動時，權限模式是 default——每個工具呼叫都需要確認。這不是因為 Claude Code 不信任使用者，而是因為信任需要時間建立。

隨著使用者對 Claude Code 的了解加深，他們可以：使用 /accept-edits 命令切換到「自動接受檔案編輯」模式；設定權限規則，允許特定的安全命令（如 git status、npm test）自動執行；在足夠信任後，啟用 auto 模式讓分類器自動判斷。這種「漸進信任」的模型與 Web 應用中的漸進式授權（Progressive Enhancement of Permissions）完全平行。現代瀏覽器在請求地理位置、通知、攝影機權限時，也是先詢問使用者，再記住使用者的選擇，而不是一上來就請求所有權限。

結語

作為前端，我們習慣了討論框架選型、效能優化、元件設計——這些無疑是重要的。但 Claude Code 的工程實踐提醒我們：技術決策的底層是價值判斷。

Claude Code 的價值不在於它選擇了 React 或 TypeScript 或自研 Ink，而在於它有意識地將這些選擇編織成一張連貫的價值之網。每一個架構決策都可以追溯到「Helpful, Harmless, Honest」這三個詞，而這三者之間的關係——如何在幫助使用者的同時保護他們、如何在保護他們的同時保持誠實。

原文出處：https://juejin.cn/post/7649936611648667686