Claude Code 不再僅僅與開發者產生共鳴。非技術人員也在使用它來構建東西。技術人員則在進行非技術工作。界線變得模糊。 我絕對不是第一個想到這一點的人。Anthropic 的多個團隊已經在 "代理體驗" 上工作了幾個月——Claude 不僅僅是聊天夥伴，而是幫助你完成實際工作的工具。@bcherny 促使我思考：我們能否將內部構建的東西發佈一個早期的、範圍縮小的版本，並在幾天內完成？於是我們組建了一個小團隊，設定了一個激進的截止日期（"星期一聽起來不錯？"），然後開始工作。 @claudeai 寫了 Cowork。我們人類面對面討論基礎架構和產品決策，但我們所有的開發者管理著 3 到 8 個 Claude 實例，實施功能、修復錯誤或研究潛在解決方案。 對於本地代碼，我們在本地機器上使用 Git 工作樹。對於較小或僅限於網頁代碼的更改，我們只需告訴 Claude 去實施它。當有人在 Slack 中報告錯誤時，我們經常只是 @-提及 Claude 並告訴它去修復。所有代碼在合併之前都會由人類（和另一個 Claude）進行審查，但我們現在花費大部分時間在協調一群 Claude 並做出決策，而不是手工編寫單獨的代碼行。 我們提前發佈 Cowork。它還有一些粗糙的地方。但弄清楚該構建什麼越來越成為軟體工程中最困難的部分——我們認為及早獲得反饋並聽取用戶實際需要的東西是我們構建真正優秀產品的方式。