… 当我们开始使用Claude Code时，只是我们几个人在使用它。现在，许多工程师每天都依赖Claude Code来完成他们的工作。我们不能再只为自身设计，我们严重依赖社区反馈来共同设计正确的体验。没有这些反馈，我们无法构建正确的东西。Yoshi正确指出了这一点，通常这种迭代是在公开的情况下进行的。在这种情况下，我们特别有意地进行，并在内部进行了一个多月的自举测试，以在发布前让用户体验变得完美；这导致了大多数用户更喜欢的体验。但我们对一部分用户来说还是没达到预期。为了改进它，我反复在问题中了解人们在新设计中遇到的问题，并推出了多轮更改，最终达到了一个良好的用户体验。我们之前也以这种方式公开构建过，例如在迭代spinner用户体验、todos工具用户体验以及许多其他领域时。我们总是希望听到用户的声音，以便让产品变得更好。Yoshi提到的特定剩余问题是有道理的。…
源讨论Claude Code 正在被简化原帖 701 条评论 · 导入时统计把你的经验，加入这段讨论。
在哪些终端中渲染速度很慢？我认为终端的GPU加速（如Ghostty中看到的）很荒谬。它只是一个终端。 编辑：显然因为该死的（dang）我今天不能再发帖了。如果你发帖说某个终端不好，至少告诉我们渲染问题的情况。
完整原文这是一个极其出色的回应。历史背景，我们犯的错误，我们正在采取的修复措施。继续努力！
完整原文有太多配置选项。大多数我仍然需要真正深入理解。 但这个不是吗？我会称自己为专业人士。我在各种项目和不同类型的工作中使用它，处理大量文件。 对我来说，文件路径是理解工作上下文和CC获得的上下文的重要方面。 现在？感觉就像在雾中奔跑的街道，永远不知道拐角处会有什么，可能会撞到篱笆或房子。 为什么不多加一个切换开关呢？我很乐意将它添加到我的别名中。 编辑：我忘了。我不需要更好的子代理输出。或者甚至在查看思考轨迹时减少输出。我很满意完全的详细程度。有些情况下，这是重要的方面。
完整原文我无法计算有多少次我从看到Claude正在读取的文件中受益，以了解我如何可以打断并给它更多的上下文……节省了数千个标记并节省了上下文窗口。我可能是少数喜欢看到实际文件的用户。我爱Claude代码，但最近的一些更新似乎让我不那么容易看到发生了什么。我同意作者的观点，即详细模式不是答案。在我看来，这应该是可配置的
完整原文> 这导致了大多数用户更喜欢的体验 我只是觉得这很难相信。真的有人现在对输出做些什么吗？还是他们只是抱着侥幸心理，希望一切顺利？
完整原文我是一个使用屏幕阅读器的人，也是无障碍公司的首席技术官。这个更改并没有为我减少噪音。它移除了功能。 视力正常的人失去了便利。我失去了对工具的信任。使用屏幕阅读器时，不存在“快速浏览”终端输出的情况。也不存在“逐步揭示”。文本要么被告诉我，要么就不存在。 当你将文件路径折叠成“读取了3个文件”，我就无法知道代理在对我的代码库做什么，除非切换到详细模式，这会将子代理的对话、思考轨迹和完整的文件内容全部发送到我的音频流中。视力正常的人可以视觉上跳过这些内容。而我则必须按顺序听取每一行。 你们创造了一个情况，我的选择只有“没有信息”或“全部信息”。之前存在的中间地带，即内联文件路径和搜索模式，才是无障碍的。 这不是一个高级用户的问题…
完整原文> 我们不能再为自己设计了，我们严重依赖社区反馈来共同设计正确的体验。没有这些反馈，我们无法构建正确的东西。 这怎么可能成立呢，当你故意且反复地告诉开发者（你声称要倾听的社区）你比他们更了解情况？他们告诉你他们想要什么，而你却说“不”。这不是在倾听。你明白这一点，对吧？
完整原文我不是程序员，而且讨厌终端环境，当我设计复杂性时，我需要简单的界面，Claude 现在根据我最初的設計規格指導所有開發者，它能創建出漂亮的筆記本，可以直接上傳到 Colab 或 GitHub，沒有任何 UX，也沒有可用性問題，這是我們昨天製造的最新產品 starborn.github.io/copp-notebook 感謝 Claude 工程團隊為我做了一件飛得非常高且帶我一起飛的東西，starborn.github.io/copp-notebook
完整原文尊重不同观点，分享具体经验。
登录后即可发帖、评论、转发和引用。