Claude Code 作者：別再沉迷功能堆砌了！最好的 AI 工具，是把控制權還給你

編譯自 ai.engineer

責編 | 王啟隆

出品 | CSDN（ID：CSDNnews）

原文 | youtube.com/watch?v=Lue8K2jqfKk

投稿或尋求報道 | zhanghy@csdn.net

前幾天編譯的一篇 AI Engineer World's Fair 的演講反響很好，這次我們再來一篇，演講者來自 OpenAI 的死對頭——Anthropic 公司。

現在 Claude Code 作為廣大程序員的新工具風頭無兩，如果說 ——從“代碼”到“規約”的價值轉移；那么，Claude Code 的創造者Boris Cherny，則為我們帶來了另一場截然不同的分享。

這他的核心觀點可以概括為一種“極簡主義哲學”：在模型能力日新月異、最佳實踐尚未定型的當下，最好的AI工具，或許不是一個功能繁復的“大教堂”，而應該是一個簡單、通用、無偏見（unopinionated）的“樂高積木”。

它不試圖替你決定工作流，而是給你最底層的、最原始的力量，讓你自己去創造、去組合、去定義最適合你的工作方式。最強大的工具，往往是那些將最終控制權交還給創造者本身的工具。

以下為演講全文：

我叫 Boris，是 Anthropic 的技術團隊成員，也是 Claude Code 的創造者。

我之前一直在糾結，對于一個已經了解 Claude Code、了解 AI 和各種代碼工具的聽眾，我到底該講些什么。所以，我決定先從一個宏觀的視角切入，然后再具體深入：

1. 模型正在飛速進化。

2. 產品幾乎也在以同樣的速度進化。

3. 用 Claude Code，選擇你自己的路。

第一部分：編程的拐點

編程正在改變，而且變得越來越快。

如果你回顧編程的起點，在上世紀三四十年代，我們用的是交換機面板，那是純物理的東西，根本沒有軟件的概念。

然后到了 1950 年代，打孔卡出現了。我外公在蘇聯就是第一批程序員之一。我媽媽會給我講故事，說她在 70 年代長大的時候，我外公會把這些大疊的打孔卡從單位帶回家，然后她就在上面用蠟筆畫畫。

那就是那時候的編程。

但到了 50 年代末，更高級別的語言開始出現。首先是匯編語言，編程從硬件和打孔卡這種物理實體，轉向了軟件。

然后，抽象的層級不斷提升。我們有了 COBOL，然后是類型語言，C++。到了 90 年代初，出現了一次語言家族的大爆發，有 Haskell 家族，有 JavaScript 和 Java，C 語言家族的演進，還有 Python。

到了今天，如果你瞇著眼看，會發現所有語言都開始變得有點像。我寫 TypeScript 的時候感覺像在寫 Rust，寫 Rust 感覺像在寫 Swift，寫 Swift 又感覺像在寫 Go。各種抽象已經開始趨同。

第二部分：開發體驗的進化

如果我們思考編程語言的用戶體驗（UX），它也同樣在進化。

回到 1950 年代，你用的是類似打字機的東西在打孔卡上打洞，那就是編程。

然后，在文本編輯器出現之前，編程是這樣的：

這是IBM O29，1964 年的產品。這在當時算是頂配了，是編程打孔卡的“MacBook”。幾乎人手一臺。

然后有了Ed，這是世界上第一個文本編輯器，由貝爾實驗室的 Ken Thompson 發明。

它看起來還挺熟悉的，如果你打開你的 MacBook，還能在終端里輸入“ed”，這個 50 多年前發明的工具現在還在。這很瘋狂，因為它沒有光標，不能回滾，沒有代碼補全，幾乎什么都沒有。它就是為那種只能在紙上打印輸出的電傳打字機設計的。

Smalltalk-80在 1980 年是一個巨大的飛躍。它是第一個為軟件編程提供圖形界面的工具之一。對于那些折騰過 React 或 Redux 熱重載的人來說，這個東西在 1980 年就已經有了“實時重載”（Live Reload）功能，而且能用。

之后，Visual Basic在 1991 年首次將圖形化范式帶入主流。在這之前，人們主要使用基于文本的編輯器，比如 Vim 和 Emacs。而 VB 是很多人（包括我）的啟蒙。

Eclipse在 2001 年將“代碼補全”（typeahead）帶入主流。這不是 AI 驅動的，而是基于靜態分析。它索引你的符號，然后進行排序和展示。這可能也是第一個擁有龐大第三方插件生態系統的 IDE。

Copilot是一次巨大的飛躍，帶來了單行和多行的代碼補全。

而我認為，Devin可能是第一個真正突破，將“用自然語言編程”這個概念帶入主流的產品。人們已經探索了幾十年，但 Devin 是第一個讓這個想法真正落地的產品。

所以，IDE 的開發體驗（devx）進化得很快，而且未來會變得更快。

第三部分：找到適合任務的工作流

傳統的編碼工具，非常專注于“編寫代碼”這個環節。但我認為，新一代的編碼工具能做的遠不止于此。這也是很多剛接觸這類工具的人感到困惑的地方。

所以，這里有幾個我個人發現的、使用 Claude Code 的有效工作流：

1. 讓 Claude 探索、規劃，再由你確認，然后它才編碼、提交。

> figure out the root cause for issue #983, then propose a few fixes. Let me choose an approach before you code. ultrathink > 找出 #983 問題的根本原因，然后提出幾個修復方案。在我選定一個方案之后你再開始寫代碼。#ultrathink

你可以讓它先用工具進行探索，制定一個計劃，然后把計劃給你看，等你確認之后再執行。

2. 使用測試驅動開發（TDD）

> write tests for @utils/markdown.ts to make sure links render properly (note the tests won’t pass yet, since links aren’t yet implemented). then commit. then update the code to make the tests pass. > 為 @utils/markdown.ts 編寫測試，確保鏈接能正確渲染（注意測試暫時不會通過，因為鏈接功能還沒實現）。然后提交。之后再更新代碼讓測試通過。

我知道，我個人也試過 TDD，在實踐中確實挺難堅持的。但現在有了編碼工具，它真的變得可行了。也許原因不是我在做，而是模型在做。

3. 對照目標進行迭代

> implement [mock.png]. Then screenshot it with puppeteer and iterate till it looks like the mock. > 實現這個 [mock.png] 設計圖。然后用 puppeteer 截圖，并不斷迭代，直到它看起來和設計圖一樣。

總的來說，如果 Claude 有一個可以迭代的目標，它的表現會好得多。所以，只要有辦法驗證輸出——無論是單元測試、集成測試，還是在 iOS 模擬器里截圖——它的效果就會更好。第一次的產出可能還行，但第二次、第三次迭代后的結果會非常出色。

最后的思考：保持無偏見，成為一個簡單的通用工具

今天，我們在 Claude Code 中發布了“計劃模式”（Plan Mode）。任何時候，你按下 Shift+Tab ，Claude 就會切換到計劃模式。你可以讓它做一件事，但它不會馬上做，而是先制定一個計劃，等待你的批準。

我想分享的最后一點是，給 Claude 更多上下文。方法有很多，最簡單的是 CLAUDE.md 文件。你可以在項目根目錄或者子目錄里創建這個文件，它會被自動引用。你也可以在你的 home 目錄里創建，它也會被全局引用。

我們還支持自定義“斜杠命令”（slash commands）。

你可以在 .claude/commands/ 目錄下創建 Markdown 文件，它們就會出現在斜杠菜單里。這對于復用工作流非常有用。

你還可以用 # 號讓 Claude 記住一些事情，它會提示你保存到哪個記憶文件中。這也是我們在探索如何更好地使用“記憶”這個新概念，我們希望聽到你們的反饋。

歸根結底，Claude Code 的思路是保持無偏見（unopinionated），成為一個簡單、通用的工具。

• 通用目的

• 能與你所有的工具協同工作

• 能融入你所有現有的工作流

AI 產品爆發，但你的痛點解決了嗎？

2025 全球產品經理大會

8 月 15–16 日

北京·威斯汀酒店

互聯網大廠、AI 創業公司、ToB/ToC 實戰一線的產品人

12 大專題分享，洞察趨勢、拆解路徑、對話未來。

立即掃碼領取大會PPT

搶占 AI 產品下一波紅利