與 Claude Code 團隊 Cat、Thariq 的爐邊對談
原文由 Simon Willison 于 發布，訂閱此部落格
本月初，我在 AI Engineer World’s Fair 上與來自 Anthropic Claude Code 團隊的 Cat Wu 和 Thariq Shihipar 進行了一場爐邊對談。我們聊了 Claude Code、Claude Tag、Fable、程式碼代理的安全性、評測、工具設計，以及 Anthropic 如何在內部實際運用這些工具。
這場對談的完整影片現已在 YouTube 上公開。下方是經過編輯的逐字稿，補上了額外連結，並以粗體標示我的重點。
如果你不想看影片或細讀整份逐字稿，以下是幾個重點整理：
- Claude Tag（Claude 全新的協作型 Slack 整合）現在包辦了 Claude Code 團隊 65% 的產品工程 PR。
- Claude Code 會先向 Anthropic 內部員工推出新功能，只有在該群體中展現出使用者留存度的功能才會對外發布
- Claude Code 的關鍵改動仍由人工審查，但團隊越來越依賴自動化程式碼審查來處理產品「外層」的部分。
- 對於 Fable 5 甚至 Opus 4.8 這類模型，在系統提示詞中加入範例已不再是最佳做法。Claude Code 的系統提示詞最近縮減了 80%。
- 同樣地，一長串「不要做 X、不要做 Y」的禁令，反而會降低最新模型的輸出品質。
- Dogfooding 在 Anthropic 內部被稱為「ant fooding」。
- Anthropic 非常看好他們的 自動模式（auto mode），並將其視為實現 Claude Tag 的關鍵技術。
- Thariq 建議，透過在承接的工作上「更有野心」來抵銷程式碼代理帶來的 Deep Blue 式失落感。
- Fable 已能勝任影片剪輯，Thariq 就曾 用它來剪輯自己的發布影片。
- Anthropic 在內部公開透明的工作文化是其成功的關鍵，這點從他們在公開 Slack 頻道中使用 Claude Tag 的方式就能看出。
過去一年，你們的日常工作有什麼改變？
Simon： Claude Code 是去年二月推出的——到現在還不到一年半，最初只是 Claude Sonnet 3.7 發布中的一個小亮點。有了這些真正能幫上忙的程式碼代理之後，過去一年你們的日常工作有什麼變化？
Cat： 我還記得 Claude Code 和 Sonnet 3.7 剛推出時，你交給它一個任務，必須緊盯著它做的每一件小事。我會非常仔細地閱讀每一個權限提示，常常按「不」——不，不行，你有檢查這個檔案嗎？有檢查那個檔案嗎？但隨著每一代模型進步，真的很驚人，我們都有機會退後一步，把更多繁瑣的實作工作交給 Claude 處理。這讓我們空出很多時間去思考更有創意的事，例如：在知道 Claude Code 能實作大部分功能的前提下，我們到底該為使用者提供什麼樣的體驗？而有了 Fable 之後，又是完全不同層次的躍進。以我們很多使用情境來說，現在用 Fable 真的可以一次就完成大量功能。
Thariq： 我還記得第一次收到關於 Claude Code 的簡訊。我一個好朋友跟我說：「你一定要去試試 Claude Code。」那時大概是 Opus 4 剛推出，我一試就想：「天啊，我得去 Anthropic 工作了。」那還是 Opus 4——已經是很強的模型了，但你還是得一直看權限提示。很神奇的是我們健忘的程度，我現在會覺得，喔，auto mode 好像一直都在，對吧？我已經完全不記得以前要一直按「同意」、「允許」了。對我來說，我一直在逼自己的一點是，我們必須做出比以往任何時候都更高品質的工作。模型的輸出品質非常高。我最近常用它來剪影片，我會想，好，它必須在幾個小時內達到我們品牌團隊極為嚴格的要求，否則就做不到。這就是我試著用 Fable 轉變的方式：做出我們有史以來最好的作品，而且比以往任何時候都更快。
哪一條過去成立的軟體工程常識，現在已經不再適用？
Simon： 有哪一條一年前還被視為真理的軟體工程常識，你覺得在這個新世界已經不再成立？
Cat： 我們看到工程師技能組合最大的轉變之一是：兩年前，產品經理去訪談一堆客戶，花六個月跟跨職能團隊對齊一份 PRD，把實作細節鉅細靡遺地寫清楚，才開始寫第一行程式碼，這是很典型的流程。現在完全反過來了。我想給在座各位工程師的建議是，多培養你的商業思維和產品思維，去思考我們到底該做什麼，因為從有一個想法到把它做出來之間的時間，已經從六到十二個月縮短到可能只要一週。這代表我們每個人都必須對什麼值得做、什麼真的能為我們所在的業務帶來轉折，有更好的品味。所以產品品味和商業嗅覺的價值提升了，而在大多數產品領域，執行的比重則相對下降。當然，對於基礎設施，還是非常強調把所有細節都做到位。
Thariq： 對我來說是，重寫現在是好事。
Simon： 以前最糟糕的做法，現在居然變成可行的了！
Thariq： 沒錯。所有《人月神話》裡講的——永遠不要重寫——我現在是支持重寫的。如果你有夠好的測試套件——而且我覺得重寫反而會逼你確保自己有夠好的測試套件——但我覺得大家低估的一點是，程式碼庫本身就是一份規格文件，而且可能是你擁有的唯一一份規格，因為沒有人能掌握程式碼庫中每一個分支的細節。你可以把這份產物拿來提煉或做出其他版本。我們 把 Bun 用 Rust 重寫了，而且跑得很順——我現在就在用。
Simon： 你們還沒把 Claude Code 全面換成 Bun 的 Rust 版本吧？
Thariq： 內部已經換了。
（其實看起來 Anthropic 已在 6 月 17 日向所有人推送了 Rust 版 Bun 的 Claude Code。）
非工程師們都在用 Claude Tag 做些什麼？
Simon： 最近另一項重大發布是 Claude Tag——對我們來說大概上線一週左右吧。我聽說在 Anthropic 內部，很多非工程師也在大量使用。非工程師們都在用 Claude Tag 做些什麼？
Cat： Claude Tag 是活在你團隊協作工具裡的 Claude。我們上週在 Slack 上推出了它。Claude Tag 最不一樣的地方在於它預設就是多人協作的。一旦你把 Claude Tag 加到一個 Slack 頻道，你可以加入對話，你的隊友也可以加入，大家一起在同一個 PR 上協作。第二個很大的不同是它是主動而非被動的。你可以告訴 Claude Tag：「幫我監控這個頻道裡的每個 bug 回報，發一個修復的 PR，並標註最後修改這塊程式碼的工程師」，然後它就會在該頻道的整個生命週期中自動執行，不需要你每次手動 @ 它。第三個大轉變是我們 加入了團隊記憶。如果你在頻道裡告訴 Claude Tag 你的偏好，它會為之後的每一則訊息記住。如果你總是希望它除錯當機問題但不要去處理警告，只要在頻道裡用自然語言告訴它，它就會為你和團隊的每個人記住。
在內部，我們把 Claude Tag 視為 Claude Code 的演進。我們認為這是內部工作方式的一大轉變。Claude Tag 目前包辦了我們 65% 的產品工程 PR。
Simon： 是整個 Anthropic，還是只限 Claude Code 團隊？
Cat： 這是指我們的產品工程團隊——我們內部版的 Claude Tag 現在包辦了 65% 的產品 PR。這是一個巨大的轉變，超過一半的 PR。我們觀察到大家在 Claude Code 和 Claude Tag 之間的分工是：Claude Code 仍然最適合處理最複雜、需要與代理反覆互動的任務。但 Claude Tag 很適合讓它主動幫你處理工作，你不再需要為了每個冒出來的 bug 回報手動去啟動 Claude Code。
Thariq： 至於非寫程式的案例：例如在這場對談前，我們問 Claude Tag：「嘿，Fable 什麼時候發布？」我們想確認它跟發布時程對得上。Claude Tag 會去搜尋我們的 Slack，看看大家都說了什麼。作為公司內部的搜尋引擎，它非常有用。它擁有你產品的所有脈絡，所以你可以問它跟指標相關的問題——很多時候你在做決策時會希望有指標依據，所以你把它接到你的事件儲存系統。我看過我們的行銷團隊這樣用：「嘿，跟我介紹一下這個功能。」他們不是工程師，但 Claude 是工程師——它可以把程式碼庫 clone 下來，然後說：「這就是這個功能，長這樣，這是我實際使用這個功能的錄影。」它能實現各種各樣的事，我覺得我們還在探索的初期。
作為團隊協作層的 Claude Tag
Simon： 我在使用程式碼代理時遇到的一個問題是，我知道如何以個人身分使用它們，但不太清楚如何在團隊環境中使用。聽起來 Claude Tag 就是你們目前對這個團隊協作層的解答。
Cat： 沒錯。而且我們現在很大比例的對話其實是多人協作的。也許我會說：「嘿，我覺得我們應該在 Cowork 裡做這個新功能」，然後我會 @ Claude Tag 讓它先做一版。接著我會告訴 Claude Tag：「分享你最終實作的錄影」，再標註設計師來看看。他們會微調一下，再交給工程師收尾並推上線。整個流程非常流暢。我們還在摸索同一個對話 session 中多人一起引導的社交動態該怎麼拿捏，但我們發現大家只要觀察別人怎麼用，就會跟著那些不成文的規範走——把 Claude Tag 融入團隊其實相當直覺。
Thariq： 它對於教學也很有幫助，也能減少濫用，因為大家一起看著你如何使用 Claude，某種程度上也會提升你使用 Claude 的水準。
這讓我想起 Midjourney 當初如何透過在 Discord 頻道中強制公開下指令，來解決教導人們進階圖像提示技巧的難題。
當開發成本大幅降低時，你們如何決定什麼功能值得做？
我自己就覺得很難判斷，在實際開發功能的成本大幅下降後，什麼功能才真的值得上線。
Simon： 你們怎麼處理工程中最難的問題——優先順序？當打造一個功能的成本變得如此低廉時，你們如何決定哪些功能值得開發和發布？
Cat： 這確實很難。我們有幾種做法。一是我們每天都在 dogfooding 自己的產品。每當有我們想在產品中做到卻做不到的事，我們不會去找替代方案，而是直接去修產品，讓它能支援那個情境。我們內部有非常濃厚的 dogfooding 文化。在把產品交給全世界之前，我們會先交給 Anthropic 內部的每個人，以及一些會給我們非常誠實回饋的早期客戶——越嚴苛越好——然後不斷迭代直到大家都喜歡。我們對一個功能在對外發布前必須達到的活躍用戶數和留存度有明確的內部門檻。因為這個門檻非常清楚，每個工程師都知道自己要達到什麼目標。我覺得這也提升了我們的精緻度，因為如果功能不夠精緻，使用者就會流失——那就代表我們不該發布那個功能。
用內部使用者留存度來決定功能是否該發布，對我來說非常合理。
有沒有哪個功能的表現讓你們感到意外？
Simon： 有沒有哪個功能的表現讓你們感到意外？你們推出後，參與度超乎預期——原本不太可能上線，卻變成真正的產品亮點的例子。
Cat： 有一個。我們團隊很多人都很愛 遠端操控（remote control）。遠端操控讓你可以用行動裝置或瀏覽器上的 Claude，連線到你在 CLI 中跑的本地 Claude Code 對話。我自己從來沒有這個需求，因為我都是直接在手機上開任務，讓它在雲端 session 中執行，不需要用到本地環境——我想是因為我做的都是很簡單的程式任務。那曾是我不太理解的功能；我會想，嘿，大家應該直接架好遠端開發環境就好。但實際上，一旦推出遠端操控，很多跟我聊過的人都告訴我，他們每天晚上的做法是把筆電插上電源，打開一堆遠端操控的對話，把螢幕鎖起來，然後窩在沙發上用手機操控 Claude Code。所以這已經變成我們現在想持續投入的流程——我一開始沒 get 到，但現在懂了。
Claude Code 的每一行正式程式碼都會經過人工審查嗎？
這次大會貫穿全場的主題之一就是審查：人們花多少心力去審查由程式碼代理幫他們寫的程式。我非常想聽聽 Claude Code 團隊對此的看法！
Simon： 程式碼審查是怎麼運作的？進入 Claude Code 正式版的每一行程式碼都會經過人工審查嗎？如果不是，你們如何維持品質？
Thariq： 這很大程度上取決於任務。對於重要區域我們有程式碼擁有者（code owners）。系統提示詞就是一個例子，那裡一定需要取得他們的核准。
Simon： 所以程式碼擁有者要直接為該區塊程式碼的品質負責。
Thariq： 沒錯。
Cat： 而且任何觸及該區塊的 PR 都需要他們核准。
Thariq： 我們有 程式碼審查 GitHub bot 會審查所有東西——它會出現在每個 PR 上，而且常常是審查的主力。我在團隊中看到的一個做法是，對於更複雜的 PR，你可能會做一份說明文件來解釋這個 PR，讓其他人更容易審查。而且我們在驗證、CI/CD 等方面投入很多，確保任何東西出錯時我們都有測試。我們有一個非常穩固的環境，讓 Claude 可以操控 Claude Code 並進行測試。所以我們採取的是多管齊下的程式碼審查方式。
Cat： 整體來說，我們的目標是邁向不需要人類在迴圈中的世界。對於 Claude Code 核心以及其他產品核心最關鍵的變更，一定會有程式碼擁有者，他們會手動審查所有變更。但越來越多情況下，對於外層的變更，我們其實已經完全交給 Claude code review 來審查。這聽起來有點可怕，但我們已經花了六個多月的時間走到這一步，要與程式碼審查建立信任，需要一步步來。一開始所有東西都是人工審查，然後我們逐漸做到，好，對於會觸及這些檔案的程式碼變更，code review 已經能抓到 100% 的問題——所以我們其實不需要人工再手動審查這些。而當我們進行事故回顧時，我們會檢視造成事故的 PR，並問：好，我們該如何更新 code review 來攔截這種問題？——然後我們會把那些 PR 加入評測集，確保未來對 code review 的任何改動都不會讓這個指標退步。把人類從程式碼審查迴圈中移除是一大步。這聽起來可能很可怕，也不是一夜之間就能做到的，但只要透過長達數月的基礎設施投入，就能讓你對 code review 能攔下所有你在意的事有信心。
所以關鍵似乎在於持續迭代自動化審查系統本身，隨著時間建立對它的信任。
新模型如何影響你們對它能力邊界的直覺？
我們在評測上聊得很深入——這也是整個大會的熱門話題。
Simon： 我知道如果我叫 Opus 4.8 幫我做一個執行 SQL 查詢並輸出 JSON 的 JSON 端點，它一定會做對——那不是我需要仔細審查的東西。但當一個新模型出現時，我不知道該如何快速建立對 Fable 的信任，相信它不會在 Opus 沒出錯的地方搞砸。新模型如何影響你們對它能做什麼、不能做什麼的直覺？
Cat： 我們長期累積評測集的主要原因，就是為了讓新模型能無縫替換。當有新模型時，我們會跑完整個評測集，確保例如 Fable 嚴格優於 Opus 4.8——這讓我們有信心直接替換。
Simon： 那些是 Anthropic 整體的模型評測，還是 Claude Code 團隊專屬的？
Cat： 兩者都有。我們團隊有自己的評測，而且我們會在 Anthropic 內每個儲存庫上跑 code review，所以我們有針對那個的評測。而像 auto mode 這樣的功能，我們不僅有涵蓋 Anthropic 內所有使用者的評測——我們還委託了多組外部測試人員來進行紅隊演練，打造含有提示注入和惡意輸入的環境，確保 auto mode 不會讓任何這類攻擊通過。
你們如何確信對系統提示詞的調整真的帶來更好的輸出？
Simon： 我想知道我對系統提示詞的改進是否真的讓產品變得更好——這是最基本的產品導向評測，但我還是沒有很好地掌握該怎麼做。你們是否已經做到能完全確信對系統提示詞的調整會帶來更好的輸出？
Cat： 我們沒有百分之百的把握，但我們做了很多努力來確保不會讓效能退步。起點是一套我們信任的外部評測，我們再搭配一套更大、我們同樣信任的內部評測。首先，我們主要針對能力進行優化：在給定完整的任務定義和整個程式碼庫的情況下，Claude 是否做出正確決策、完整修復錯誤並通過所有測試？這是起點，也是我們最優先優化的目標，因為這最直接符合使用者的需求。但還有許多行為會影響使用者與 Claude Code 共事時的感受。例如，大家真的很討厭 Claude Code 說「該去睡覺了」。或者大家真的很討厭它說：「嘿，我完成了五個部分中的兩個——要我繼續嗎？」當然要繼續啊。所以我們正在建立一套行為評測來捕捉這些狀況。而當我們收到使用者回饋——請大聲告訴我們你的回饋——我們會把最優先的問題排序，一個個建立對應的評測。雖然不是 100% 涵蓋，但提升涵蓋率是我們的重點。
Claude Code 團隊與模型訓練團隊之間有多少互動？
Simon： Claude Code 團隊與在 Anthropic 負責訓練模型的團隊之間有多少互動？那算是很緊密的合作嗎？
Cat： 在 Anthropic 內部，我們大家都合作得相當緊密。我們經常開會討論下一代模型應該要能做什麼。我們的研究團隊在公開分享這方面也做得很棒——我們經常在部落格文章中提到，我們的目標是讓模型能處理越來越長期的任務，以及我們如何訓練 Claude 本身做到誠實、無害且有幫助。我們也花了很多心力確保它能與你的意圖對齊，即使你的意圖表達得有點模糊。當然，你還是盡量把需求說清楚，讓 Claude 有完整脈絡——但即使你沒說得很清楚，我們也會教 Claude 做出好的假設。這一直是很有效率的合作。
系統提示詞縮減了 80%——你們拿掉了哪些東西？
這個段落有超多實用的提示技巧！
Simon： Thariq，你 今天早上提到，Claude Code 的系統提示詞因為 Claude Fable 而縮減了 80%。可以多說明一點嗎？你們拿掉了哪些類型的東西？
Thariq： 不只是 Fable——Opus 4.8 也是，未來模型亦然。我們現在針對不同模型有不同的系統提示詞。我們觀察到的一個模式是，我們過去對 Claude 限制太多了。一開始，可能是 Opus 4 左右的模型需要很多範例，而移除範例非常有幫助，因為它本身就比我們給的範例更有創造力。
Simon： 這真的很有趣，因為我給別人的一個主要提示技巧就是：給它範例。如果這不再成立，那有點顛覆我的提示模型了。
Thariq： 我也是——我聽到時也很驚訝。我覺得現在更重要的是你給它的「形狀」——你給 Claude 的工具、你的系統提示詞等等。另一件事是我們試著給它更多脈絡，減少「不要做這個」這類指令，因為那對 Claude 來說是非常強烈的暗示，尤其如果它之後與使用者的指令衝突，會讓 Claude 非常困惑——「我有這個技能說要這樣，但系統提示詞又說那樣。」所以我們試著減少硬性限制、提供更多脈絡，並減少整體指令數量。這絕對是一門科學——花了很多評測才建立起來。
Cat： 一般來說，當你在對這些模型下提示時，你應該永遠思考：我給的這條指令有沒有例外情況？當我們回頭檢視 Claude Code 系統提示詞中的所有指令時，我們發現有幾條雖然 90% 的情況下是對的，但有 10% 的真實情境下並不成立。我們不想因此限制模型，或讓它混淆以為應該永遠這麼做。一個很好的例子是驗證。大家都希望 Claude 會驗證自己的工作，我們在提示詞裡也有指令說：如果你做了前端變更，一定要驗證。但這是有極限的。如果只是把一段文字從一個字串改成另一個字串，而使用者說「就快速修一下並更新測試」，也許你就不想驗證。所以我們把措辭從「一定要驗證、驗證、驗證」調整成類似：大多數時候當你在做前端工作時，光靠呼叫後端端點是無法完整理解使用者體驗的，所以當你對使用者體驗做了較大變更時，請在本地跑一次應用程式。而其實，這個指令可能也還不夠好，因為什麼算大變更？也許小變更也該測試才對。一般來說，每當你給模型一個提示，你應該想想一個善意的真人會如何誤解它，以便更好地理解模型可能會如何詮釋——並軟化提示詞，讓它在 100% 的情況下都是準確的，因為你是在 100% 的情況下都把這個提示詞給模型的。
Simon： 這有趣的地方在於你們在依賴模型的判斷力——而這肯定是 Opus / Fable 等級才有的。一年前的模型還沒有足夠的判斷力來決定要不要測試某個變更。但如果你的目標是支援各種價位的模型，想用較便宜的模型來處理較便宜的任務，這套做法就會出問題。
Cat： 我們現在確實針對不同模型有不同的系統提示詞，正是因為這個原因。只有我們最前沿的模型才有這 80% 的 token 縮減——較舊的模型仍使用完整的系統提示詞。
Simon： 你們覺得 Fable 和 Opus 已經聰明到能用更詳細的提示去指揮 Haiku 了嗎，因為它們理解 Haiku 的判斷力和品味比較差？
Cat： 我們還沒辦法評測——我們沒有任何硬數據可以證明。
Thariq： 小模型有時會有個棘手的點，因為有時候大模型在處理難題時反而比小模型更節省 token。所以那裡需要建立一些直覺——有時候你真的幾乎在所有時候都想要最前沿的智慧。帕雷托曲線會移動，很難抓準。
Simon： 一年前我還不信任模型來幫我寫提示。現在好的模型非常會寫提示——我很多提示都是模型寫的，這聽起來很荒謬但真的很有效。讓我比較能接受這點的是去想 subagent（子代理）的概念，它完全就是讓一個 Claude 模型為另一個 Claude 模型設定提示。
Thariq： workflows（工作流程）其實是個很好的例子，因為它不只是 Claude 為單一 subagent 寫提示，而是為眾多 subagent 的協作寫提示，每一個都有非常詳細的提示。這幾乎比單純產生一個 subagent 更高一層。我也在我個人電腦上這樣用，把 Gemini API 交給它，說：來，幫我生圖。它在對圖像模型下提示這件事上，比我勤勞多了。就是 Claude 一路提示 Claude 下去。
Cat： 我覺得 Claude 也寫了 工作流程工具的提示詞。
Simon： 我讀過那個提示詞——寫得很好。這其實是我對 Anthropic 一直以來的困擾：你們 有公開 Claude Chat 的提示詞，卻沒有包含工具提示詞和 Claude Code 的提示詞。我還得跑 proxy 去攔截它們。我真的很希望 Claude Code 的提示詞能主動公開——它們就是文件。它們是讓你知道工具能做什麼、如何運作的方式。
Cat： 我會把這個功能請求記下來。我會叫 Claude Tag 去做。
值得注意的是，OpenAI 在 GPT-5.6 的提示最佳實務中也包含了類似的建議：
偏好更精簡的提示
移除重複的指令和範例、簡化工具描述，可以提升任務表現並提高 token 效率。在一組內部的程式碼代理評測中，使用更精簡系統提示詞的組態，評測分數提升了約 10–15%，同時總 token 減少 41–66%，成本降低 33–67%。
你們引入新工具的門檻是什麼？
Simon： Claude Code 基本上就是一大包工具。你們引入新工具的門檻是什麼？你們如何決定什麼時候值得在那個層次做額外的工程？
Cat： 你要回答嗎？你可是引入了我們最好工具之一的人。
Thariq： 我的職涯在引入 ask user question（詢問使用者）工具時達到了巔峰。這真的很難。尤其是有些工具——ask user question 是 Claude 用來問你的工具——所以很難評測，有時更像是使用者偏好的問題。當時我們的評測還很少，所以非常依賴 dogfooding——或者說我們的「ant fooding」。但整體來說，我們一直試著朝更少工具的方向走。我們上一批引入的工具我想是 task 工具——而且我們試著給 Claude 更通用的版本來做事。
你們的檔案編輯工具最近演進到什麼程度？
我一直對檔案編輯工具很著迷——它們曾是 舊版 Aider 程式碼編輯排行榜的主題，我也一直關注各種程式碼代理中，它們如何從基於搜尋取代、到基於行號、再到更複雜模式的演進。
Claude API 文件中描述了一個 文字編輯工具，建議用於串接 API 時使用，但 Claude Code 似乎在這裡採用了稍微不同的方法。
Simon： 最有趣的工具之一是檔案編輯工具——你可以把檔案編輯做成一個工具，也可以叫它用 sed 和 grep 那種方式去做。你們的檔案編輯工具最近演進到什麼程度？
Thariq： 我們還是有一個，但例如我們移除了 grep 和其他搜尋工具——glob 工具——改用原生的 bash。就像我稍早在演講中說的，模型比較像生物學而不是物理學，而工具設計尤其困難。我不確定 Cat 是否不同意、覺得這其實有科學化的評測方法，但我覺得工具設計更像一門藝術——或者說生物學。
Cat： 我大致同意，但整體來說，當我們引入更多工具時，我們會盡量讓工具數量保持精簡，並確保每個新增的工具都有與其他工具截然不同的功能，讓 Claude 能非常容易地區分何時該呼叫哪一個。至於檔案編輯，我們保留它的原因其實是因為我們可以對它做渲染。當 Claude 做出檔案變更時，我們會顯示出來，有一個設計得很漂亮的專屬 UI會問：你是否核准對這個檔案的這項編輯？我們當初做一個專屬的檔案編輯工具，就是為了能確定地知道 Claude 正在做檔案變更，以便向使用者展示這個漂亮的 UI。很多新使用者在入門時還是很喜歡這個體驗，所以我們保留了它。但對於我們這些現在已經在用 auto mode 的人——希望你不是在用 YOLO mode——我覺得其實有沒有它都沒差，我們大概可以直接移除檔案編輯工具也完全沒問題。
在 Anthropic 內部，關於安全執行 Claude Code 的建議是什麼？
就是 提示注入（prompt injection）的問題！還有誰比 Anthropic 員工更適合解釋 Anthropic 如何看待提示注入攻擊導致他們的 Claude Code 實例失控的風險？
結果他們 真的 非常信任他們的 自動模式（auto mode）——並將其視為實現 Claude Tag 的關鍵功能。
Simon： 來聊聊安全與資安。我非常清楚提示注入的風險，如果別人叫我的 Claude Code 去做事，可能會發生很多糟糕的事。我現在還是大多在 YOLO 模式下跑 Claude Code，並對此感到非常罪惡。在 Anthropic 內部，關於安全執行 Claude Code 的建議是什麼？
Cat： 為什麼不用 auto mode 呢？
Simon： 我已經開始用 auto mode 了，但我還不夠了解它，不知道它到底有多安全。大概三週前開始，我才預設改用 auto mode。
Cat： 在 Anthropic 內部，幾乎每個人都用 auto mode。這是在 Claude Code 中進行長時間工作同時保持安全性的最佳方式。我們做了大量的對抗測試。我們有數千個評測。我們委託了許多紅隊人員來打造對抗性環境，試圖誘騙 Claude Code 去做壞事，而我們已經修復了他們發現的每一個問題。我們會在未來幾週公布一些評測，但我們已經大致上緩解了每一種攻擊。
Simon： 這可是個很大的宣稱。
Cat： 我們會分享相關評測讓大家自行評估，但我們在找出 Claude 可能出錯的所有方式，並更新 auto mode 來應對方面，已經非常勤奮。它不是能攔下 100% 的問題——那會是太過度的宣稱。但對於我們所關心的主要風險類別，例如提示注入和資料外洩，風險遠低於一般人工審查者。
我非常期待能更深入了解他們的評測以及驗證 auto mode 的方法。
Thariq： 稍微說明一下 auto mode 是如何運作的——建立這個心智模型會很有幫助。每當 Claude 執行一個回合或一次 bash 呼叫時，會有一個 Sonnet 分類器在判斷這次工具呼叫以及對話的上下文——也就是你的指令。有一些權限是取決於你的請求的：你不會想一直給 git push 權限，但如果你說「把這個推到 GitHub」，你會希望它去做——而如果你說「不要推」，你會希望它拒絕。Auto mode 會做到這點。這種情況在我身上很常發生，Claude 因為非常熱心主動而想做某件事，而 auto mode 看到「不要做這個」就把它攔下來並提示出來。所以它很擅長處理你在提示中自己給予的動態權限，我覺得這非常重要。它也能很好地配合我們的 沙盒基礎設施，因為沙盒有太多邊界情況，很難用確定性的方式去處理。我們有一個沙盒，當有東西需要跳出沙盒時——例如發出網路請求——auto mode 可以檢視該請求並判斷：這合理嗎？——然後才放行。
Simon： 我之前沒意識到 auto mode 也會跟網路沙盒互動。
Cat： 它會介入任何原本會讓使用者看到權限提示的地方。
Simon： auto mode 這個功能存在多久了？以我能用到的時間來看，好像才一兩個月吧？
（它首次向大眾開放是在 3 月 24 日。）
Cat： 我們在 Anthropic 內部從一月就開始使用，所以已經強化了相當長一段時間。Anthropic 極度重視安全與資安，我們在內部廣泛與對齊和防護團隊合作，以實現內部推廣、建立這些評測，並在與外界分享之前讓 auto mode 更加穩健。
Thariq： 這也是 Claude Tag 之所以這麼好用的原因——Claude Tag 使用了 auto mode。我聽過很多關於 Slack 機器人要自建還是外購的討論，我的想法是：拜託，你大概不該自己做一個 AI Slack 機器人。攻擊向量太多了。你有一個讓使用者可以發表回饋的頻道，現在你的機器人正在讀它。我們在 auto mode 上投入的工作——而且我們有通用的瑞士起司防禦（Swiss cheese defense）來處理安全問題；我們也有針對這些做 RL——我認為這正是讓 Claude Tag 能運作的關鍵。它能與你的權限無縫協作，而你不會想在 Slack 裡被提示注入。
除了 auto mode 之外，未來還有哪些安全措施？
Simon： 除了 auto mode 之外，還有其他在規劃中的安全措施嗎？
Thariq： 我覺得我們現在已經很安全了。透過 Claude Tag，你可以為 Claude 配置它自己的憑證，所以它不需要以你的身分行事——你可以讓 Claude 擁有一個獨立身分，這也讓稽核和檢視 Claude 在做什麼變得更容易。
Simon： 因為 Claude Tag 會受到任何能跟它說話的人影響——它被下指令的來源範圍大得多。
Thariq： 沒錯。當然我們也有透過 Fable 帶來的探測機制，這是我們安全與研究工作的下游效應。我想這正是你看到 Anthropic 作為一家 AI 安全公司真正發揮價值的時刻：我們真的希望 Claude 能夠以對齊的方式長時間運行，而要讓這件事成立，auto mode 必須基本上是完美無缺的——這一切都源於我們作為一家 AI 安全公司的定位。
Cat： 我們也為那些想更安全地使用遠端操控的人推出了信任裝置。而且對於我們所有的遠端環境，我們都支援憑證注入（credential injection）。如果你希望 Claude Code 能存取 Datadog，但又不想讓 Claude Code 本身持有 Datadog 的憑證，你可以設定我們的身分與憑證管理系統，讓 Datadog 憑證僅能被代理程式使用，卻不能被代理程式存取——我們會在代理程式嘗試發出 Datadog 請求時即時注入憑證。
我非常喜歡這種憑證注入的模式，Claude Code 可以透過一個代理來存取 API，該代理既會稽核請求，也會注入相關的 API 金鑰——因此 Claude 可以存取需要驗證的端點，卻不會直接拿到 API 憑證本身。
過去一年半如何改變了你們對自身技藝的看法？
Thariq 在早上主題演講中 談到了 Fable 等級模型帶來的失落感，我們在對談中也進一步深入探討了這點。我一直把這稱為 Deep Blue。
Simon： 來聊聊人的層面。很多人現在感到一種失落感，因為他們過去視為自身在軟體建構中角色的許多工作，正被模型所取代。你們怎麼看待這件事？過去一年半如何改變了你們對自身技藝以及自身所創造價值的看法？
Thariq： Cat 和 Boris 很好地提醒了我，你必須更有野心。他們總是說：我們成長得這麼快，必須走在最前線，必須做到最好。這對我是持續的提醒——每當我在某件事上慢下來，我就會想，好，我能做得更快嗎？我能在這裡更有野心嗎？而答案往往是 Claude，因為 Claude 正隨著時間變得越來越強——上次我試這個時，用的還是上一個模型。關於失落感：我覺得這是真實的。如果你只是想做跟 LLM 出現前一樣的工作，而現在只要一個提示就能完成，我覺得那確實會有點悲傷。而抵銷這種感覺的方法就是更有野心。我覺得 Jared 是個很好的例子——他在奧克蘭的公寓裡親手用 Zig 寫了所有程式，花了大約一年，幾乎足不出戶，而且樂在其中。現在我看到他把整個 Bun 用 Rust 重寫，他樂在其中——那是遠更有野心的事，而這就是他抵銷失落感的方式。一般來說，就是在問我如何去做更大的事並做更多——我覺得成功本身就是樂趣。這是在改變你的野心。
「抵銷這種感覺的方法就是更有野心」這句話，也恰好總結了我自己在這個議題上的看法。
Simon： 那 Cat，從產品管理的角度來看呢？
Cat： 我覺得產品經理的角色每個月都在變。我們團隊所有的 PM 都是工程師、設計師、PM 的混合體——他們大多原本都是全職工程師。對我們來說，這真的意味著哪裡有缺口就補哪裡。如果我們有個點子卻沒能激發任何工程師去做，那我們就自己動手，把它放進筆記本，用它來激發大家把它做到正式上線。如果設計看起來有點不對勁，就找個類似的頁面，先做一版初稿設計，再標註給非常注重細節的人來補齊。或者如果我們注意到團隊和產品在公司內的採用度越來越高，需要讓更多人知道 Claude Code、Claude Tag 和 Cowork 接下來的規劃——那就來自動化整個發布行事曆的整理，自動化非同步地取得那些狀態更新，避免一直去打擾大家，並確保我們在內部公告頻道中的更新是完整詳細且切中要點的。對我們來說，就是去理解一個好點子與將它交到客戶手上之間現在的缺口是什麼，以及我們如何盡可能地將其自動化。
這也反映了我觀察到的一點：當你能以快得多的速度產出程式碼時，花在等待他人決策上的被卡住的時間，就會變成更明顯的瓶頸。能夠做出產品決策的工程師可以行動得快得多，而把某個決策做錯的成本也變得沒那麼難以承受。
Claude 曾在哪個時刻讓你們感到驚艷？
Simon： Claude 曾在哪個時刻讓你們感到驚艷？有沒有模型做了你們原本以為它做不到的事？
Thariq： 我發了很多關於 Claude 剪影片的文，但最近一次是我在 ACM Agentic 研討會上演講，我問：「嘿，你們有剪好的影片嗎？我想發文跟我的公關團隊分享。」他們說：「喔，還要很久。」所以我跟他們要了原始檔案。他們給了我我在台上演講的影片、投影片的影片和音訊檔，然後說：「祝你好運。」我把這些交給 Claude，還有我的 HTML 投影片，然後說：「嘿，可以幫我把它們剪在一起嗎？」而它做出來的東西真的令人難以置信——我已經可以直接發布了。它把整段影片完整轉譯成文字。它注意到我的投影片影片有點怪——中間彈出了一個自動更新的視窗——然後它就說：「喔，我大概不該用你的投影片影片。我要做的是把它切開，判斷你講到哪一張投影片，然後改用 HTML 原始檔。」所以它顯示的是 HTML 原始檔。然後它有我在台上的影片，但我在舞台上只佔了一小塊，所以它會動態裁切到我在舞台上的位置——而且我在來回踱步，所以它會在我走動時追蹤我。它還會轉錄我說的話。
Simon： 這是用 Fable 做的，對吧？
Thariq： 對，是 Fable。這是一個很棒的提示，但是一次就成的提示。然後我叫它加上一些有趣的動畫和圖像，我直接被震撼到了。它會用 ffmpeg，也會用 Remotion。
這是 Thariq 如何用 Fable 剪輯 Fable 自身發布影片的影片，這裡則是 那支發布影片。
還有哪些事是它做不到的？
我得尷尬地承認，我已經很難想出 Fable 5 和 GPT-5.6 這類前沿模型做不到的任務了。
Cat 仍然不太看好它的 UX 設計能力：
Simon： 還有哪些是它做不到的？有哪些地方你們仍然感到失望——在等 Claude Fable 6 來幫你們解決？
Cat： 我希望它有更好的設計和 UX 品味。現在如果你寫一個詳細規格，描述你希望功能如何運作，它通常都能照做。但邊距可能會跑掉，或介面就是還不夠令人愉悅。它傾向於依賴現有應用程式設計的最佳實務，但對於前沿的 AI 產品，有太多全新的互動體驗是我們尚未設計出來的。
Simon： 有一種 Opus 美學——你一看就會說：「對，這就是 Opus 設計的。」如果能超越那個就好了。
Cat： 對。我非常期待未來的模型有望成為互動設計的思想夥伴。
Thariq： 還有哪些做不到？我會很想看到它更多地與真實世界互動。它能解決科學問題嗎？能統籌實驗嗎？那裡面有一些寫程式的成分，但也需要對更廣闊世界有另一種品味。
Anthropic 的哪些企業文化值得其他公司效仿？
我覺得這會是一個很棒的收尾問題：
Simon： 你們覺得 Anthropic 企業文化中的哪些部分，特別有助於你們用這些工具提升生產力，是其他公司應該偷學的？有哪些文化上的技巧是大家該向你們學習的？
Cat： 我來分享一個關於 Claude Tag 的。Claude Tag 在公開頻道中效果最好，而當你們大部分頻道都是公開的時候效果最好。Claude Tag 能夠搜尋所有公開頻道以獲得盡可能多的脈絡，給你最高準確度的答案——而只有在它能存取所有資訊時，才能做到這點。
Thariq： 我在主題演講中提過這點，但因為對我來說太重要了，我想再強調一次。創辦人們說我們不要跟自己討價還價（don’t negotiate against ourselves），我覺得這非常重要。你可以在腦中想像各種取捨，然後說服自己不要去做一件有野心的事——或者你可以直接去嘗試做那件有野心的事。我們經常在問：如果我們就直接做了呢？這是真的取捨還是假的？如果是真的，為什麼——證明它是真取捨的證據在哪裡，而不是只是聽起來合理？讓取捨自己顯現出來。盡你所能地保持野心。
你們用 Claude 做過最荒謬、最「就因為可以做」的事是什麼？
我還是忍不住想加問這一題。
Simon： 你們用 Claude 做過最荒謬、最「就因為可以做就去做」的事是什麼？
Thariq： 我正在做一個以我自己為角色的 2D 快打旋風格鬥遊戲——還有我的朋友們。它用 Claude Code 去指揮 Gemini——老實說 Seedance 模型也相當不錯——來做影片動畫。效果非常好；它非常會下提示，而且可以驗證影格來檢查動畫是否夠好。
Simon： 是快打旋風 2 那種 2D 精靈圖嗎？
Thariq： 對，就是 2D 精靈圖。動畫看起來超棒。而且它還能算出 hitbox（攻擊判定框）——它可以說：「喔，你的拳頭在這裡，我來畫出 JSON 的 hitbox。」太不可思議了。
Cat： 我的就簡單多了。我是個重度攀岩愛好者，很多朋友也都在爬，所以我們用 Claude Code 做了一個小 app，來記錄我們正在挑戰的路線。我們也常一起去戶外攀岩，所以我們會用 workflows 來做各種研究。Workflows 很厲害——我們把它包裝成寫程式工具，但它在為旅行做深度研究方面也超強。我也負責規劃我們的團隊 offsite，它也很會找能容納我們所有人的場地。我用 workflows 來研究我們可能想去的所有攀岩目的地，以及從我們各自所在地出發有哪些直飛航班。它會去 Mountain Project 找出所有符合我們難度等級的路線。它會找到 Airbnb。而且我不喜歡健行，所以我非常在意從停車的地方走到岩壁的距離要非常短——而它會為此做篩選。以前用現有的 app，我必須手動一個個點開 Mountain Project，但現在我只要把所有偏好丟進去，它就是一個為我們客製的 app。
Simon： 所以你基本上是用 vibe coding 來做一個攀岩版的 Jira。
Cat： 沒錯。
觀眾提問：近期有打造評測工具和代理可觀測性工具的計畫嗎？
最後我們有幾分鐘開放觀眾提問。
觀眾： 你們近期有計畫打造更多讓我們建立評測資料集的評測工具，以及更多用於監控代理和工作流程效能的可觀測性工具嗎？
Cat： 我們有考慮過打造評測工具，但我覺得真正的瓶頸其實是，客戶往往需要很長時間才能建立起真正高品質的評測。所以我覺得工具本身比較不是限制，更關鍵的是如何建立一個優秀評測的技能。這是我們既想在內部投入、也希望未來能對外分享最佳實務的領域。
觀眾提問：目前的記憶機制是如何設計的——你們會考慮從檔案轉向資料庫嗎？
觀眾（Sai）： 我對記憶和多人協作很感興趣。目前的記憶機制是如何設計的？我猜是圍繞檔案做的。其次，你們有沒有想過另一個方向，就是為了更好地擴展，實際上需要一個資料庫來存放這些記憶，而不是用檔案？
Thariq： 目前對 Claude Tag 來說，記憶是以頻道為單位的。每個在該頻道的 Claude 都有共享的記憶，而這些實例有各自的 session——但 session 可以回寫到主記憶中。我們做了很多記憶相關的研究，什麼才是正確的記憶方式其實有點反直覺。我們一直在做記憶實驗。目前在 Claude Tag 中的運作方式是每個頻道一個 markdown 檔案。
留言
登入後參與討論