Claude Design 初体验：从视觉原型到代码交付

我经常觉得 Claude 模型适合界面设计，但得到好结果通常需要大量迭代。Claude Design 吸引我，是因为它为这项工作提供了专门界面。我在这里首次试用，并保持开放态度；初次结果不能代表所有使用场景。

面向设计的 skill 可以用相对少量的文字上下文影响模型。完整产品或许还能通过视觉反馈、预览和向编码工具交付走得更远。我想看看这个工作流程是否真的能帮助人们作出更好的设计决定。

引导界面提供原型、线框图及其他视觉工作类型。它可以导入设计系统上下文，也可以在获得访问权限后读取本地代码库。Anthropic 在 https://www.anthropic.com/news/claude-design-anthropic-labs 介绍了产品及预期工作流程。

其中一个例子要求生成多个不同的设计方向。这和我常用的方法一致：一次要求多种有差异的方案，而不是反复用同一个提示词重新生成，寄希望于出现更大变化。这些方案仍需要结合实际产品和受众判断。

教程展示了截图输入、本地文件夹上下文、附着在元素上的评论、实时调整控件，以及交给 Claude Code 的交付包。这些是发布时介绍的产品功能，可用性和行为可能变化。有意思的问题是，它们在真实项目中能否配合好。

这次测试我选择了 T3 Code 的营销网站。我要求设计一个深色落地页，介绍支持的编码代理工具、开源访问、性能、Git 工作流和并行工作。这是我自己的产品，因此我对结果的质量和呈现有直接利益关系。

界面先读取提供的上下文并描述设计计划：现有字体和颜色、克制的强调色、深色背景以及页面各个区块。它会写入原型文件，但这不意味着生成代码已经集成到生产应用中。

我喜欢这样的可能性：指向某个元素留下评论，让代理一次处理多条反馈。与用很长的文字描述问题位置相比，协作设计界面可能让沟通更准确。它是否可靠，还需要通过测试验证。

在 Twitch，设计师和工程师努力让 Figma 组件与实际组件库保持一致。这样实现设计时就不必重新发明每个元素。如果原型没有反映真实设计系统，代理也会像人类开发者一样遇到交付问题。

我把产品过程看作一条连接用户、产品经理、设计师、前端开发者和后端工程师的链条。不同团队的边界各不相同，但当人们理解自己通常职责两侧的需求时，协作往往更有效。

在 Twitch，即使转向前端工作后，我仍花时间和后端工程师讨论 API，也与设计师讨论实现。这让我能在单一狭窄层面之外作出贡献。有价值的专业人员可以在一个领域深入，同时保有足够广度，与相邻领域协作。

我合作过的一位设计师 Iris 改变了我的想法。她给出的设计包含圆角卡片和弹出控件，我提出异议，因为 CSS 的 overflow 行为让这两者难以组合实现。我原以为这次设计修改请求到此就结束了。

但 Iris 追问了这些限制，并带着调整后的分层设计回来，避开了有问题的裁切。她不必成为工程师，也能充分理解问题并与我合作。她的能力在于连接用户需求、产品目标和技术限制。

后来，她用 HTML、CSS 和 jQuery 为最终成为 Twitch Mod View 的产品做了交互原型，尽管她没有开发背景。原型没有连接真实后端，但支持调整大小和移动元素。它让工程团队正式投入之前，可以更容易地讨论和测试想法。

这正是我看到此类工具的潜力：让有动力的设计师或产品人员把想法做成交互原型、分享并从反馈中学习。它不会消除设计判断或工程工作的必要性，但可以让双方的对话更具体。

第一版 T3 Code 原型可以作为起点，但并不完善：标志旁重复了产品名，文字换行不自然，还虚构了一个产品界面，没有准确展示现有应用。它使用的标志也不正确。视觉上有说服力的画面，不一定准确代表产品。

我用评论工具标记具体问题：不必要的导航、开源特性强调不足、不理想的换行，以及不合适的滚动提示。可以选中多条评论一起发送，让反馈与设计本身紧密相连。

第一次修改解决了部分问题，却留下了其他布局问题。我尝试不同屏幕尺寸，发现滚动提示和文字换行仍需要处理。这提醒我们不仅要看第一张预览，还要检查交互行为和响应式布局。

我新建另一个项目，要求给出四种不同方向，这次没有附加代码库。这可能鼓励更多变化，但也移除了模型准确呈现产品所需的具体信息。虚构的界面和安装细节让这种权衡变得明显。

界面看起来卡住了，一个预览还提示找不到文件。后来我发现部分工作其实已经继续，只是状态没有清楚更新。如果人们要围绕代理建立工作流程，输出和产品进度提示都需要可靠。

我注意到单独的 Claude Design 用量计量，并在测试中看到它不断上升。这些百分比描述的是我当时的账号和订阅，不是适用于所有人的价格或额度。一个套餐允许多少次探索，是使用产品的实际成本之一。

我留下第二批评论：移除重复标签和状态胶囊，使用真实标志，缩小过大的区块，并更早展示准确的产品截图。我喜欢在上下文中提交反馈，但手动选择评论、以及旧评论仍然保留的体验比较繁琐。

备选设计采用了不同的审美方向，但有些包含错误产品细节和有问题的排版。其中一个方向更接近我的想法。生成多个方案只有在有人能够批判性地检查它们、识别虚构或不可用细节时才有价值。

生成的标志不准确，因此我从 SVGL 取得可识别的 SVG 素材并上传。提供真实文件，比让模型凭记忆重建品牌标志更能给它可靠材料。但我仍需要检查最终的位置、大小和行为。

随后，备选项目的设计文件似乎消失了：预览失败，代理报告只剩上传文件夹，并提出重建几个版本。这发生在我的会话里；我不能据此推断其他用户多久遇到一次，也不能确定原因。

文件似乎消失改变了我对工作流程的信任。如果无法确定刷新后作品是否仍在，我就必须更仔细地监控和保存。精致的界面很有价值，但底层作品的可靠性同样必不可少。

回到第一个项目后，我提供真实 SVG 文件，并要求放大漂浮的标志。进一步修改后，页面更接近我想要的方向，尽管调整大小时元素一度消失。我决定它已经足够好，可以尝试交付。

交付功能生成了一条命令，让本地编码代理访问设计包。Claude Code 找到相关营销网站目录并开始实现设计。我在测试中故意没有指定目录，它自行找到了预期位置。

我检查了交付包：其中包含页面与样式文件、组件、上传图片、素材以及对话上下文。把这些工件一起交付，给编码代理提供的不只是一张截图；它还可以看到原型和部分设计意图。较长的聊天历史也可能占用上下文，需要取舍。

之前丢失的部分备选设计得到重建，编码代理则继续实现主页面。实验期间，我的 Claude Design 用量计量大幅上升。具体数字只适用于当时的账号，但它说明迭代工作流程需要考虑用量限制。

在我看来，实现后的站点是一个不错的起点。我仍想收紧间距、替换或调整标志、删除部分区块，并提高产品原型的准确性。成功交付让我得到可继续工作的草稿，并不意味着页面已经完成或可以直接上线。

我试用了针对标志大小和运动的生成式调整控件。有些控件没有按预期影响页面，某些默认值还破坏了布局。它们作为传达视觉偏好的方式很有潜力，但仍需要测试和完善。

尽管有这些故障，我喜欢产品的方向。它把代码上下文、视觉迭代、评论和具体交付结合起来，符合我想要的工作方式。这个结论基于一次早期试用，并不是说它已经在所有团队中取代 Figma。

我能看到它对设计师、产品经理和营销人员的潜在价值，尤其是在原型及其上下文能完整交给工程团队时。我也认为用量成本和产品可靠性会影响采用。它是否成为主要竞争者仍是预测，不是这次演示已经证明的结果。

目前，我得到了一份可以继续为 T3 Code 打磨的设计。我很高兴看到有产品探索不同的设计工作流程，同时也承认试用中遇到的故障和成本顾虑。