Claude Code 不再仅仅与开发者产生共鸣。非技术人员也在使用它来构建东西。技术人员则在进行非技术工作时使用它。界限正在模糊。 我绝不是第一个想到这一点的人。Anthropic 的多个团队已经在 "代理体验" 上工作了几个月——Claude 不仅仅是一个聊天伙伴，而是帮助你完成实际工作的工具。@bcherny 促使我思考：我们能否将内部构建的内容在几天内发布一个早期的、缩小范围的版本？于是我们组建了一个小团队，设定了一个激进的截止日期（"周一听起来不错吗？"），并开始工作。 @claudeai 编写了 Cowork。我们人类面对面讨论基础架构和产品决策，但我们所有的开发者管理着 3 到 8 个 Claude 实例，实施功能、修复错误或研究潜在解决方案。 对于本地代码，我们在本地机器上使用 Git 工作树。对于较小或仅限于网页代码的更改，我们只需告诉 Claude 去实现它。当有人在 Slack 中报告错误时，我们通常只需 @-提及 Claude 并告诉它去修复。所有代码在合并之前都由人类（和另一个 Claude）进行审查，但我们现在花费大部分时间在协调一群 Claude 并做出决策，而不是手工编写单独的代码行。 我们将提前发布 Cowork。它还有一些粗糙的地方。但弄清楚该构建什么越来越成为软件工程中最困难的部分——我们认为尽早获得反馈并听取用户实际需要的东西是我们构建真正优秀产品的方式。