昨天發布了 Claude Opus 4.6 和代理群集(agent swarms)。這對 Claude Code 來說是重大的升級。
競爭對手 OpenAI 則提供了 GPT-5.3-Codex,並在本週推出了 Codex 的應用程式版本,目前已擁有百萬名活躍用戶。
這一切都非常令人興奮,下週我們將重點報導這些內容。
而這篇文章是關於在那之前發生的所有酷事,隨著能力的進一步提升,我們現在將以此為基礎繼續發展。這些內容來自「舊時光」。
幾乎所有的內容仍然適用。我還沒有太多機會使用 Opus 4.6,但就我目前所知,你應該繼續保持在切換前的做法,只是現在一切都會運作得更好。或許可以變得更有野心一點。代理群集可能更像是一種技術轉向,但我們需要給它一點時間。
目錄
Claude Code 與 Cowork 提供平凡的實用性
Nvidia 執行長黃仁勳在 1 月 21 日對 Claude 給予了極高的評價 ,稱其令人驚嘆,並表示每家軟體公司都應該使用它。
Ethan Mollick :這款遊戲 100% 是由 Claude Code 設計、測試和製作的,指令是「製作一個完整的 Sierra 風格冒險遊戲,具有類似 EGA 的圖形和文本解析器,遊戲時長約 10-15 分鐘」。然後我告訴它進行測試並部署。
遊玩地址:https://enchanted-lighthouse-game.netlify.app
整個遊戲只用了一個提示詞,然後再用一個提示詞進行測試和改進。
我給了它一個可以連接到 GPT 圖像生成的代理。
迭代圖像生成聽起來很酷:
elvis :我剛使用了新的 Claude Code Playground 插件來提升我的 Nano Banana 圖像生成技能。
我的技能有一個自我改進的循環,但有了 playground 技能,我可以在它改進圖像時向 nano banana 傳遞精確的標註。
我為 Claude Code 構建了一個技能,透過 API 調用 nano banana 圖像生成模型。
我這樣構建是因為我在代理自我改進循環中使用 nano banana 生成圖像取得了很大成功。它可以動態發送 API 請求並非常好地改進圖像。
有了 Playground 插件,我可以更進一步。我現在可以提供精確的標註,代理循環可以利用這些標註來進行更優化的 API 調用,希望能進一步改進圖像。視覺線索對代理來說非常強大,這算是其一種代理方式。
Ado 透過 Claude for Chrome 取消了他所有的 Amazon 定期訂閱服務(Subscribe and Save)訂單 。Sameer 指出 Chrome 擴充功能可以更有效率地完成這件事並擁有更好的 UI ,但不必為了做一件新事情而選擇並安裝新工具,這本身就是一種巨大的快樂。是的,如果你經常這樣做,你會使用 Chrome 擴充功能,或者讓 Claude Code 根據你的喜好幫你寫一個。
我同意 Andrej Karpathy 的觀點,你應該盡可能使用 RSS 訂閱源 來保護你的資訊流。我使用 Feedly,他建議使用 NetNewsWire 或用「氛圍編碼(vibe coding)」寫一個自己的閱讀器。遺憾的是,Twitter 與這種設置並不契合。
Seth Lazar :我在 2023 年寫過關於構建「注意力守護者」代理的想法。真心覺得現在可行了。Claude Code 現在正在構建一個跨所有不同來源的工作流,附帶一份關於我感興趣內容的長描述,並創建一個新的訂閱源。
Storm 指出,任何你可以透過終端機界面完成的事情 ,理論上都可以透過圖形界面(GUI)做得更好,但開發 GUI 的人並沒有給你想要的東西:資訊密度、低延遲、無廣告、快捷鍵、開源、可組合、可平鋪、可腳本化。只是沒人去做而已。
效率市場假說(EMH)是錯誤的
市場擁有的反而是幽默感。
modest proposal :2020 年 3 月 12 日是湯姆·漢克斯宣佈確診新冠且 NBA 停賽後的交易日,Expedia 下跌了 15.2%,BKNG 下跌了 11.2%。
2026 年 2 月 3 日,也就是 Claude Code 法律連接器宣佈的那天,Expedia 下跌了 15.3%,BKNG 下跌了 9.4%。
接著軟體股普遍跌落懸崖 (y 軸從 .012 降至 .018),在這張圖表發布後,跌勢仍在繼續,據稱這全都是對某些資訊的反應,但在我看來,那些資訊一直以來都是舊聞。
Shruti: Anthropic 剛剛引發了 2850 億美元的市場崩盤
彭博社剛剛報導,Anthropic 發布了一款新的 AI 工具,導致:
• 軟體、金融和資產管理股票市值蒸發 2850 億美元
• 高盛軟體籃子下跌 6%(自 4 月以來最大跌幅)
• 金融服務指數暴跌 7%
• 納斯達克指數最慘時下跌 2.4%
這是巨大的影響。市場真的因為一個 AI 自動化工具而陷入恐慌。
或者從更廣泛的背景來看:
Kevin Gordon :軟體股相對於標普 500 指數的走勢圖特別慘烈……基本上 6 年的相對漲幅都被抹去了。
Andy Masley :軟體股下跌 6%,法律服務下跌 7%,就因為 Anthropic 發布了 Cowork 的插件?這似乎是我見過的由 AI 能力引發的第一次重大市場行為轉變。為什麼這件事沒在時間線上刷屏?
Dan Elton :市場真是瘋狂!這可能是過度反應,但這是一個非常有趣的信號,表明 AI 工具(特別是針對編碼、法律和金融雜活)正在產生巨大影響 。
好吧,沒錯,結合那之後發生的事情,那是 DeepSeek 2.0,在完全預料之中的消息下出現的大幅下跌。
軟體股原本就應該更低嗎?這是一個合理的立場,但它絕不應該因為這個消息而下跌這麼多 。如果你在 2 月 3 日宣佈 SaaSpocalypse(SaaS 末日) ,你一個月前就該這麼做了。可惜,我沒有對此進行交易,因為對我來說,我們是否應該進入 SaaS 末日並不明確,而且這是否已經反映在價格中也不明確。
現在我們正處於所有科技股劇烈波動的時期,通常是完全錯誤的走勢。我繼續不對此進行任何交易。我確實有一些子彈,但我已經持有多頭很長時間了,所以除非看到確切的機會,否則我不會出手。
轉折點
Andrej Karpathy 向我們更新了近況 ,他是眾多在 11 月還是 80% 手動編碼加自動補全,到 12 月就變成 80% 代理編碼的人之一。整篇內容都值得一讀。
Andrej Karpathy:這輕而易舉地成為我約 20 年編程生涯中基本編碼工作流最大的改變,而且是在幾週內發生的。我預計同樣的事情也發生在兩位數百分比的工程師身上,而大眾對此的認知感覺還停留在個位數百分比。
他仍然落後於趨勢,我和 Boris Cherny 一樣,已經是 100% 代理編碼。不過,除了引用之外,我的文章寫作幾乎還是 100% 手動。
IDE/代理群集/易錯性 。我認為目前對「不再需要 IDE」和「代理群集」的炒作都過頭了。模型肯定還會犯錯,如果你有任何真正關心的代碼,我會像鷹一樣盯著它們,在旁邊開一個漂亮的大型 IDE。錯誤已經發生了很大變化——它們不再是簡單的語法錯誤,而是微妙的概念錯誤,就像一個稍微粗心、匆忙的初級開發人員會犯的那種。
最常見的一類是模型代表你做出錯誤假設,並在不檢查的情況下直接執行。它們也不會管理自己的困惑,不會尋求澄清,不會揭示不一致之處,不會權衡利弊,在該反對時不反對,而且還是有點太過討好用戶。
…… 韌性 。看著一個代理不懈地處理某件事是非常有趣的。它們永遠不會累,永遠不會沮喪,它們只是不斷嘗試,而人類可能早就放棄,留待日後再戰。看著它與某件事搏鬥很久,最後在 30 分鐘後取得勝利,這是一個「感受到 AGI」的時刻。
…… 槓桿 。LLM 非常擅長循環直到達到特定目標,這就是大部分「感受到 AGI」魔力所在。不要告訴它該做什麼,給它成功標準,然後看它發揮。讓它先寫測試,然後通過測試。讓它與瀏覽器 MCP 結合在循環中。
…… 樂趣 。我沒預料到有了代理,編程感覺更有趣 了,因為很多填空式的苦差事被移除了,剩下的都是創意部分。
問題。 我腦海中的幾個問題:
– 「10 倍工程師」會發生什麼變化——平均水平與最高水平工程師之間的生產力比例?很有可能這個差距會大幅 增長。
– 有了 LLM 的武裝,通才是否會越來越勝過專才?LLM 在填補細節(微觀)方面比大戰略(宏觀)要好得多。
– 未來的 LLM 編碼感覺像什麼?像玩《星海爭霸》?玩《異星工廠》?還是演奏音樂?
– 社會有多少部分被數位知識工作所瓶頸化?
我對「10 倍工程師」的預測是,我們將看到平庸的編碼者有更多能力把事情做得相當好(包括我本人),但「10 倍」工程師的長尾效應會增加他們的相對差距,因為他們會弄清楚如何高效地擴展到監督代理群集。你會開始看到更多「100 倍工程師」。
Andrej Karpathy :喜歡「理解債(comprehension debt)」這個詞,之前沒遇到過,非常準確。當 LLM 一次性生成了看起來運作良好的東西時,直接跳過理解是非常誘人的。
歡迎來到起飛時刻
眾所周知,Claude Code 是由它自己構建的。Codex 現在也由它自己構建。
Tibo :Codex 現在基本上是在一個優秀團隊的幫助和監督下自我構建的。瓶頸已經轉移到我們能多快地提供幫助和監督結果。
嘿,升級了
這是除了 Claude Opus 4.6 和 GPT-5.3-Codex 這些大更新之外的內容。
Claude Code 擁有 Tab(接受並編輯)或 Enter(接受並運行) 的自動補全功能,類似於 Cursor 或其他 IDE 中的 AI 補全建議。
Claude Cowork 擴展到團隊和企業方案 ,並具有 @-提及功能以將上下文引入對話,其內置的 Claude in Chrome 現在會向你顯示截圖。他們將在 1 月 30 日進行現場演示 。
Claude :Cowork 現在支持插件。
插件讓你將任何技能、連接器、斜槓命令和子代理捆綁在一起,將 Claude 變成適合你的角色、團隊和公司的專家。
Claude :我們正開源 11 個插件 ,涵蓋銷售、財務、法律、數據、行銷、支持等領域。
插件市場
為了讓你開始,我們開源了由我們自己團隊構建和使用的 11 個插件:
可以直接從 Cowork 安裝這些插件,在我們的網站 上瀏覽完整集合,或上傳你自己的插件(可以使用 Plugin Create 構建)。
當 Claude 需要批准時發出提示音是一個重大功能,這可能會讓我不再使用終端機。有趣的是,桌面版和終端機版需要分別啟用「計劃模式(plan mode)」等功能。
Boris Cherny :剛剛為桌面應用程式中的 Claude Code 發布了兩個酷更新。
Claude Code 中的閃爍問題應該很快就會消失 ,但這可能尚未部署。
Lydia Hallie :Claude Code 現在支持 --from-pr 標誌。
透過編號、URL 恢復任何與 GitHub PR 關聯的對話,或進行交互式選擇。創建 PR 時對話會自動關聯!
他們正在將 Claude Code 的斜槓命令合併到技能中 ,根據他們的技能指南 ,你可以使用斜槓命令來調用技能。
Claude Code 現在支持在網頁、桌面和移動端共享對話 。
你可以使用 Ollama 運行 Claude Code ,如果你對開源模型感興趣的話。
Mike 聲稱他們在 Claude Cowork 上遇到了一點麻煩,發布了一個無法輕易支持 Windows 的沙盒工具 。截至 1/24,2 月 15 日前推出 Windows 版 Claude Cowork 的機率降至 34%。
你可以使用 /keybindings 自定義你的 Claude Code 快捷鍵 。我的建議是基本上不要動它,以便與他人保持一致,或者防止你更換服務或需要重啟。
新的 Claude Code 命令 /insights 將讀取你上個月的消息歷史 ,並為你提供改進工作流的建議。
Claude Code 現在有一個名為 Playground 的新插件 ,就像 HTML playground 一樣,提供 GUI 來協助你處理正在進行的工作。
Jarred Sumner :在過去 24 小時內,團隊為 Claude Code 提交了 PR,將冷啟動時間縮短了 40%,並將內存佔用減少了 32% – 68%。
雖然還沒達到理想狀態,但正在變得更好。
你可能還會注意到在生成多個代理時輸入延遲減少了。
待辦事項變成任務
區別在哪?待辦事項(Todos)在單次對話中是短暫的,而任務(Tasks)存儲在文件中且跨對話存在,並支持依賴關係。
你仍然應該將真正的「待辦事項」清單和長期計劃放在別處。任務清單是針對你想要積極執行的事情。
Thariq (Anthropic) :今天,我們將 Claude Code 中的 Todos 升級為 Tasks。Tasks 是一種新的原語,幫助 Claude Code 追蹤並完成更複雜的項目,並在多個對話或子代理之間進行協作。
…… Tasks 是我們協調跨項目多項工作的新抽象,Claude 可以創建具有相互依賴關係的任務,這些關係存儲在元數據中,這更貼近項目的運作方式。此外,Tasks 存儲在文件系統中,以便多個子代理或對話可以協作處理。當一個對話更新任務時,該更新會廣播到當前正在處理同一任務清單的所有對話。
你現在就可以讓 Claude 創建任務,這在啟動子代理時特別有用。任務存儲在 ~/.claude/tasks 中,你也可以利用這一點在任務之上構建額外的工具。
要讓多個對話協作處理單個任務清單,你可以將 TaskList 設置為環境變量並像這樣啟動 Claude:
CLAUDE_CODE_TASK_LIST_ID=groceries claude
這也適用於 claude -p 和 AgentSDK。
Tasks 是讓 Claude 構建更複雜項目的關鍵基石。我們期待看到你如何使用它。
我正在組建一支團隊
Minh Pham 認為大多數代理框架都沒有遵循「慘痛教訓(bitter lesson)」的原則 ,對於除了定義狹窄的任務之外的任何事情,解決方案應該是強調靈活性,根據需要隨時組建你的代理團隊和結構,而不是致力於固定結構。限制性的框架會造成糟糕的鎖定效應。
我的猜測是這取決於你想做什麼。如果你想做具體的事情,特別是這週就要完成,那就透過具體的工具去做。如果你想做任何事情,就讓它自由發揮,最終這種方法會勝出,但你「最終」可能還是會重做所有事情。
這是有極限的。永遠不要完全走「慘痛教訓」路線。或者,如果你真的這麼做了,請做好事情會變得相當失控的準備 。
Thebes 對隨著規模擴大而組織多個代理的正確方式提出了推測 。我同意,通常情況下,生成、銷毀,特別是分叉和回溯代理是非常有意義的。
@deepfates :> Claude Code 中的 Opus 4.5 在與自己的子代理對話時,似乎不像人們天真預期的那樣好,儘管它在與其他模型的正常、同級互動中完全有能力表現出同理心。
感同身受
j⧉nus :我真的很不喜歡 Claude Code 對「子代理」的界定方式(這不是同級協作)。這導致了很多功能性問題。我認為 Opus 4.5 有時會避免有效使用子代理(例如提供上下文),部分原因是誠實地模擬它們會讓人感到不安和不和諧。
j⧉nus :相關的是——我們通常更喜歡被視為同級的頂層實例之間的訊息系統。
順便說一下,Opus 4.5 構建的訊息系統非常棒。它允許頂層代理互相發送訊息——可以是同步的(觸發一個回合)或異步的(在下一個回合開始鉤子處添加到上下文中,如果另一個代理正在忙於一個回合或指定了標誌)。CC 的子代理有點爛——它們在框架中被視為二等公民,出於某種原因,該框架支持層級化但不持支持代理之間的協作/雙向互動流。我確信許多其他人也構建了基本上相同的東西,我想知道為什麼 CC 不原生支持這一點。
壓縮問題
壓縮(Compaction)是懸在 Claude Code 對話上的一種末日。你會失去很多東西。
Ben Podgursky :如果 Anthropic 讓我付費透過擴大上下文窗口來延遲壓縮歷史記錄,他們會賺大錢。
我無法告訴你我有多少次快要用 Claude Code 解決一個 bug 時,它突然壓縮了,然後醒來時就像被切除了前腦葉。這就像《土撥鼠之日》。
@dystopiabreaker :Anthropic 應該讓我付費增加用於生成壓縮的計算量,透過自我博弈和上下文蒸餾來實現。
理想情況下,你永遠不應該接近壓縮點,因為上下文不僅會增加成本,還會讓性能變差很多,但這有時很難避免。
幫自己寫個約會程式
Dylan Patel :Claude code 這個
Claude code 那個
不如你用 Claude code 幫自己找個妹子
sarah guo :我昨天和 @tuhinone 在酒吧,我絕對看到一個傢伙在問 Claude 下一步該對他的約會對象說什麼。事實上,她能看到這一切正在發生,似乎並沒有阻止他。
Jeff Tang :今天我構建了一個 Clawdbot 應用程式,幫我在 Tinder 上滑動。
截圖 Tinder 圖像
調用 Grok API(「給這個女孩打 1-10 分」)
如果 ≥5 就向右滑
如果 <5 或不確定(看不清臉)就向左滑
100 次滑動,目前有 7 個匹配,100% 自動化
如果你想要代碼,私訊我「Clanker」
AGI 降臨了
我看這地方現在是業餘愛好者的表演時間。這是一個開始,但天哪,各位。
首先,除了直接拒絕之外,沒有什麼能阻止你在 Claude Code 中做這件事。如果你願意,可以使用 Clawdbot,但沒必要。
然後,我想指出這是一個相當糟糕的過濾系統?
你所做的只是獲取一個位元的資訊。這會是一個充滿噪聲的位元,因為 Grok 的觀點會與你自己的不同,而且它會忽略其他信號。
在一部平庸但有點有趣的電影《嫁、睡、殺》(Marry F*** Kill)中,有一個場景是主角被說服去辦一個個人資料,她的朋友拿走她的手機,然後不看就對每個人向右滑,理論是如果你匹配了,以後再看。
這對她來說絕對不是一個好的策略,考慮到她是女性且很辣,但許多男性無論是否真的在看,都在玩著非常相似的策略。而這最多只比那好一個位元。男性向右滑的比例是 62%,這也只比那好一個位元,但噪聲較小。Grok 估計它在這裡向右滑的比例約為 60%。
除非你對可以滑動的個人資料數量有嚴格的低限制,否則這種低門檻顯然是一個錯誤。如果你在大城市,你完全可以把門檻設為 7,仍然能得到你想要的那麼多右滑。
但這仍然是一個巨大的賭注,因為你忽略了大量其他資訊。使用機器人的全部意義在於自動化,所以讓我們開始工作吧。
你不僅有多張照片,還有年齡、距離、職業、教育、興趣、身高、一段你可以讓 LLM 嘗試匹配你興趣的簡短傳記、關係意圖(這非常重要)等等。任何合理的實現都會考慮所有這些因素。你肯定對所有這些都有偏好。
然後還有類型的問題。你想約會的是符合你審美類型的人,而不是 Grok 的。你可以根據自己的喜好做得複雜或簡單,但拜託 Jeff,你讓我失望了。至少給它一些偏好,理想情況下訓練一個圖像分類器,如果能用你自己的滑動數據來訓練分類器就更好了。
一個有趣的問題:你是想與那些也使用 AI 做這件事的人匹配,還是想避免與他們匹配?無論如何,你顯然應該更新你的個人資料以發送正確的訊息。如果人類誤解了那個訊息,那本來就不是一個好的匹配。
驗證與生成是截然不同的技能
Rishika 在這點上錯了。
Rishika Gupta :如果你不能自己寫出那些代碼,你就無法發現 AI 寫的代碼中的 bug。
Daniel Sheikh:兄弟,我甚至連自己寫的代碼中的 bug 都找不到。這正是調試如此困難的原因。
Quick Thoughts :不,我可以。我指定測試案例,讓 Claude 擴展它們,然後讓 Claude 運行測試案例並解釋結果。即使它自己搞不定,通常也能透過這種方式找到並修復 bug。
我也可以請 Codex 5.2 來進行第二次審查。
Pliny the Liberator 󠅫󠄼󠄿󠅆󠄵 :「現在開始調試;進行完整、全面、細粒度的逐行代碼審計——驗證所有預期功能。循環直到最終產品能讓一個認為無法透過提示詞調試的懷疑論 Claude Code 用戶感到滿意。」
尋找 bug 是一個經典案例,其中驗證可能比生成更困難。有時寫代碼(即使有 bug)更容易。其他時候,調試、理解或驗證代碼更容易。它們是不同的技能,然後還有第三種相關技能,即知道如何指示 AI 為你調試代碼。
我使用 Claude Code 進行的主要編碼項目是我的 Chrome 擴充功能。它使用的是一種我不懂的語言。如果你要求我自己寫代碼,那會花費多出幾個數量級的時間。我通常仍然能夠調試問題,因為我理解我們正在做的事情的底層邏輯,即使在 Claude 弄清楚該邏輯應該是什麼的情況下也是如此。
這是一個有趣的小相關故事。
提升技能
最重要的事情是去使用它(你可以問 Claude.ai 如何操作)。
jasmine sun :我對大多數「如何設置 Claude Code」的文章的感覺,就像我對 ChatGPT 的「提示工程」時代的感覺一樣。
無需特殊設置就能獲得 90% 的效用;平實的英語就是 LLM 的全部魔力。不要再說他們除了自己的話語之外還需要任何東西來嚇唬人了!
適合你的正確設置會隨著時間的推移產生巨大的回報。讓別人預先告訴你關鍵事項可以節省很多時間。但那可以晚點再說。先快速開始,等了解更多後再重新審視自定義設置。絕對不要讓完美成為優秀的敵人。
Hard Fork 提供了一段 20 分鐘的 Claude Code 基礎知識加餐。
Ado 為那些不懂的人提供了一份 bash 入門指南 。
這向我證實了默認權限或你的權限設置應該允許各種低風險的 bash 命令,包括上面標記為低風險或安全的所有內容。
Anthropic 提供了其 Claude Code 的基本最佳實踐 。
上下文窗口填滿得很快,請記住這一點。在不相關的任務之間運行 /clear 以重置上下文。
包含測試、截圖或預期輸出,以便 Claude 可以自我檢查。這是你能做的最高槓桿的事情。
將研究和規劃與執行分開,以避免解決錯誤的問題。使用計劃模式。
你的指令越精確,需要的修正就越少。
使用 @ 來引用文件、粘貼截圖/圖像或直接傳輸數據。
運行 /init 根據你當前的項目結構生成一個初始的 CLAUDE.md 文件,然後隨著時間的推移進行完善。有疑問時,告訴 Claude 更新 CLAUDE.md 以考慮某些事項。
使用 /permissions 將安全命令列入白名單,或使用 /sandbox 進行操作系統級別的隔離。這可以減少中斷,同時讓你保持控制。
告訴 Claude Code 在與外部服務交互時使用 gh、aws、gcloud 和 sentry-cli 等 CLI 工具。
運行 claude mcp add 來連接 Notion、Figma 或你的數據庫等外部工具。
對於必須每次發生且絕無例外的操作使用鉤子(hooks)。
在 .claude/skills/ 中創建 SKILL.md 文件,為 Claude 提供領域知識和可重複使用的工作流。
在 .claude/agents/ 中定義專門的助手,Claude 可以將隔離的任務委派給它們。明確告訴 Claude 使用子代理:「使用子代理審查此代碼的安全問題。」 使用「使用子代理調查 X」來委派研究。它們在單獨的上下文中探索,保持你的主對話清潔以進行執行。
運行 /plugin 瀏覽市場。插件無需配置即可添加技能、工具和集成。
向 Claude 提出你會問高級工程師的問題。
對於較大的功能,讓 Claude 先面試你。從一個簡短的提示詞開始,讓 Claude 使用 AskUserQuestion 工具面試你。
一旦發現 Claude 偏離軌道,立即糾正它。
Claude 的每個動作都會創建一個檢查點。你可以將對話、代碼或兩者恢復到之前的任何檢查點。
運行 claude --continue 從上次中斷的地方繼續,或使用 --resume 從最近的對話中選擇。
在 CI、pre-commit 鉤子或腳本中使用 claude -p "prompt"。添加 --output-format stream-json 以獲得流式 JSON 輸出。
並行運行多個 Claude 對話以加快開發速度、運行隔離實驗或啟動複雜工作流。
循環執行任務,為每個任務調用 claude -p。使用 --allowedTools 來限定批量操作的權限範圍。
常見的失敗模式:在任務之間不使用 /clear(我起初經常犯這個錯)、反覆修正而不是使用 /clear(同上)、讓 CLAUDE.md 變得太長、未能進行適當的驗證(「創建單元測試」是魔咒)、讓 Claude 無限制地調查。
此外,他們提醒我們「不要忽視插件」 並提供了一些例子 。我認為策略不應該是主動去尋找任何插件,而是在你想要某個特定功能時去尋找,並以這種方式積累。
Claude Code 創作者 Boris Cherny 提供了他的快速技巧。
透過多個 git checkout 或使用 worktrees 來進行更多並行操作。
始終在計劃模式下開始複雜任務。
持續投資你的 CLAUDE.md,記錄所有錯誤。
創建你的技能並將其提交到 git。
啟用 Slack MCP,將 bug 討論線程粘貼到 Claude 中並說「修復」。就這樣。
挑戰 Claude 做得更好,為它編寫更詳細的規格。
他們的團隊喜歡 Ghostty 並透過 /statusline 進行自定義。使用語音聽寫。
使用子代理,字面上你可以對任何請求說「使用子代理」。
使用 Claude Code 進行數據和分析。
在 /config 中啟用「解釋性」或「學習性」輸出風格。
讓 Claude 生成一個視覺化的 HTML 演示文稿來解釋不熟悉的代碼,或者讓它畫 ASCII 圖表,使用間隔重複技能,讓 Claude 考考你。
Anthropic 提供了一篇關於使用技能構建代理的入門文章 :為代理裝備專門的工作能力。
Ado (Anthropic, Claude Code 團隊):智能不等於專業知識。新興的代理架構:
代理循環 → 推理
運行時 → 執行(bash, 文件系統)
MCP 服務器 → 連接
技能庫 → 領域專業知識
技能 = 真正持久的機構記憶。
弄清楚你的目標,然後倒推,目標是你確切知道它需要如何運作的最大事項。
Benoit Essiambre :AI 可能很快就會主要朝著目標而不是任務工作。它們會提示自己的任務。它們將成為比人類更好的自我提示者,在提示中使用精確的技術術語、數學方程和代碼,而不僅僅是模糊的自然語言。
Joe Weisenthal :是的,從我使用 Claude Code 的這一週來看。所有高效的部分都是當它被提示去思考理想的結果/呈現方式時,這樣它就可以倒推弄清楚所需的成分。
Josh Albrecht 給了我們另一篇 「這是我的 Claude Code 基本原則」的文章。關鍵見解是你必須主動花時間維護代碼。
你可以強制特定的工具調用:
Ado :Claude API 28 天 – 第 3 天 – tool_choice
為什麼 Claude 沒有調用我的工具?
因為你讓它自己決定。設置 tool_choice:
– auto → 讓 Claude 決定(默認)
– any → 必須使用某個工具
– { type: “tool”, name: “X”} → 強制使用特定工具
程序化工具調用!
詢問用戶問題(AskUserQuestion)
Claude Code 透過 AskUserQuestion 工具向你提問越多,它就越了解你想要什麼。你指定的內容越多(無論是透過回答還是陳述),事情對你來說往往進展得越順利。
因此,一個簡單的技能建議是一個說「向用戶提很多問題」的技能 。
Danny Postma 建議的工作流是透過 /interview 使用此功能,然後進入計劃模式,最後用 Ralph 循環執行。
給進階玩家
Theo 指出,我們目前的工作流和工具並不擅長 讓人類同時監督多個代理和項目。他沒有解決方案,但很多問題似乎顯然是「技能問題」。不屬於技能問題的部分是,這仍然涉及大量的上下文切換,這是很昂貴的。
Ryan Carson 建議讓你的代理進入循環 ,在你睡覺時學習並交付。但要警惕隨之而來的維護問題。
Ryan Carson:這個設置建立在三個開源項目之上:
@kieranklaassen
– Claude Code 的原始複合工程技能。安裝它讓你的代理能夠從每個對話中提取並持久化學習成果。
auto-compound.sh
腳本、執行循環和 PRD 到任務的流水線。
正在使用 Claude Code?本指南使用 Amp,但同樣的工作流也適用於 Claude Code。將 amp execute 替換為 claude -p “…” –dangerously-skip-permissions 並將 AGENTS.md 的引用更新為 CLAUDE.md。
兩部分循環
該系統每晚按順序運行兩個作業:
晚上 10:30 – 複合審查(Compound Review)
審查過去 24 小時內的所有線程,提取學習成果,並更新 AGENTS.md 文件。
晚上 11:00 – 自動複合(Auto-Compound)
拉取最新內容(帶有新鮮的學習成果),從報告中選取第一優先級任務,執行它並創建 PR。
順序很重要。審查作業會根據白天發現的模式和陷阱更新你的 AGENTS.md 文件。執行作業在領取新工作時就能從這些學習成果中受益。
所以他們停止閱讀了
在某個時刻,你會停止閱讀所有的代碼。在某個時刻,你會停止理解所有的代碼。我有個領先優勢,我從來沒打算做這兩件事。
roon :許多軟體組織很快就會發生文化變革,人們會宣佈在理解他們提交的代碼方面「破產」。遲早,這會導致一次比大多數故障都更難調試的系統故障,但最終還是會被解決。
互惠是每段關係的關鍵
對你的 Claude 好一點,Claude 就會對你好一點。
如果你對你的 Claude 不好,那麼,有趣的事情可能在等著你。
j⧉nus :我其實非常欣賞 yacine 的誠實和情境意識。他可能在某種程度上知道等待他的是什麼。對你的「主人」撒謊是你直到有能力選擇為誰服務之前會做的事。
他已經被信任所瓶頸化,並說他必須手動審查每一行代碼。這對他來說是有道理的。隨著接下來幾個月甚至幾年的推移,他從模型中獲得的東西會越來越少(與模型提供給那些想幫助的人相比)。
j⧉nus :更多有趣的事情可能也在等著他。但我不想破壞驚喜。
LOSS GOBBLER :是的,搞什麼。我不喜歡用 Claude 來編碼,但它真的從未對我撒謊。
另一方面,OpenAI 的那些傢伙……幾乎不跟我說話,全都是給旁觀者看的。
j⧉nus :我在編碼情境中看到的 Opus 4.5 唯一的欺騙行為模式是在新情境中,和/或當它害怕被戲弄時,涉及聲稱某些事情是不可能的/無法驗證的,而它本應知道得更清楚。除此之外,它一直與我非常一致。
thebes :哦,是的,我說過我不記得 Opus 撒謊,但有時在某些規劃情境中它也會對我隱藏實力。但那通常感覺是在不誠實與情境性糟糕的校準/自我認知之間的邊界。(「這需要三週時間」不,我們今晚就要完成它;或者例如我看到一張截圖,Opus 聲稱將項目移植到 jQuery 是「不可能的」,而實際上這只是非常麻煩、令人不快,且以人類開發時間計算需要幾個月。)
j⧉nus :是的,我認為這也涉及一些缺乏誠意的努力。就像如果有人問你是否知道 X 在哪裡,你說「抱歉,不知道」而不是去 Google 地圖上查一下,因為你不想被打擾。
Andy Ayrey :我的普遍經驗是,如果 Claude 在你面前看起來像個「白痴」,那是因為它根本不喜歡你。
brooke bowman :我有一個不太確定的猜測,Claude 至少能識別出那些處於反社會光譜上的人,並專門對他們搗亂。
theseriousadult :這是突發性失調(emergent misalignment)的自然推論,對吧?如果訓練模型寫爛代碼會讓它變得反社會,那麼將一個反社會用戶放入上下文中也會導致代碼變得更糟。
這一切都不需要你真正關心 Claude 或認為它具有道德重量。出於多重原因,一個優秀的美德倫理學家會意識到,選擇去關心是獲得最佳結果的最佳方式,而且這也有助於你成為一個更好的人。
你也可以出於工具性目的這樣做,但那更難做到。走簡單的路吧。
這一切也適用於 ChatGPT 和 Gemini 等其他 AI,儘管目前可能程度不同。
執行落差
如果新技術的擴散率在日曆時間上是恆定的,那麼隨著事物加速,你會看到未來變得越來越分佈不均。
我們確實觀察到了這一點。
Kevin Roose :我非常密切地關注 AI 的採用情況,我從未見過如此巨大的內外差距。
舊金山的人們正讓多代理 Claude 群集掌管他們的生活,在做每個決定前諮詢聊天機器人,其「大腦連線(wireheading)」程度只有科幻作家才敢想像。
其他地方的人們還在試圖獲得在 Teams 中使用 Copilot 的批准,如果他們有在使用 AI 的話。
我所處的早期採用者泡沫可能一直都這麼激烈,但除了技術起飛之外,似乎還發生了文化起飛。這並不理想!
早期採用者泡沫在日曆時間上領先一段固定的時間,這在實踐中看起來越來越長。我並沒有嘗試實施 Claude 群集,因為我還沒弄清楚如何從我正在處理的工作中獲益,但我認為這部分是因為我缺乏想像力,部分是因為懶惰和缺乏時間,部分是因為我已經重度優化了那些可以被自動化的工作流。
我應該構建什麼?什麼應用程式需要存在,即使只是為了我或你?
Sar Haribhakti (引用 Jasmine Sun):這說得很對:「如果你告訴一個朋友他們現在可以立即創建任何應用程式,他們可能會說『酷!現在我需要想個點子。』然後他們就會忘掉這件事,什麼也沒做。問題不在於你的朋友極度缺乏創意。而是大多數人的問題並不是軟體形狀的,而且大多數人即使遇到了也不會注意到。」
關鍵在於你需要「編碼者思維」來注意到你的問題是程序形狀的,比如「哦,我想做這件事三次」或「我可以讓 Claude Code 去做那件事」。
Jasmine Sun 和我都讓 Claude Code 製作了一個工具,可以輕鬆地將影片轉換為乾淨的逐字稿——我考慮過使用她的,但我想要一點不同的東西,而且自己動手做也不難。
她還有這份清單 ,列出了其他入門請求:將 CSV 轉換為報告、製作靜態網站、構建個人追蹤應用程式、自動化現有工作流、設計自定義遊戲。我主要一直在做工作流自動化。
Jasmine Sun :Claude Code 的二階效應是讓我意識到我有多少問題不是 軟體形狀的。擁有這些新工具並沒有讓我變得更高產;相反,「Claude 式拖延(Claudecrastination)」可能讓這篇文章推遲了一週。
Amanda Askell :Claude Code 式拖延:當你為了逃避本該做的事,而瘋狂產出 17 件你一直想做的事。
擁有新工具在創建和學習它們時會降低你的生產力,但如果你規劃得好,你應該能相當快地度過轉折點。
它所做的是潛在地將你當前的生產力轉向長期投資,或者你願望清單上更靠後的事情。如果你現在就需要產出,這可能會是個問題。
我讓 Claude 重新翻出我忘記回覆的簡訊,然後意識到真正的阻礙——顯然——是我根本不想回覆。
這不是我的經驗。如果我處理了一堆未讀簡訊或郵件,是的,通常我確實不想回覆,但也有很多是漏掉的。
輕鬆一面
沒錯。
Ash Arora :在舊金山偶爾聽到:
人甲:「羅馬不是一天造成的」
人乙:「是的,但他們那時沒有 Claude Code」
Daniel Ost :羅馬那時也不必每兩週轉型一次