Anthropic 内部设计师如何用 Claude Code 做产品、写代码、推 PR
TL;DR · AI 摘要
Anthropic设计负责人验证了以“带视觉证据的PR”为验收单位的AI工作流，通过自定义Skill、Auto模式及定时巡检任务，将设计师从代码执行者转变为审美决策者与质量治理者。
核心要点
- 使用/prototype Skill让AI生成5个方案并自选最优解，人仅做最终审美确认。
- 启用Auto模式配合claude-worktree实现多会话并行，消除权限摩擦与分支冲突。
- 建立定时巡检任务扫描未经设计评审的代码变更，预留脚本待模型升级后自动修复。
结构提纲
按章节快速跳转。
产品交付周期被压缩，Claude Code应作为全流程协作者而非单纯的代码补全工具。
通过自定义Skill生成多方案、AI自主决策、联网调研及loop until done指令完成功能开发。
利用云端批量处理UI微调、自动化PR合并审查及定时巡检无设计评审变更来提升效率。
坚持人在审美决策环中，将非编码工作自动化，并建立防止功能泛滥的质量治理机制。
设计师侧重原型探索与细节交付，工程师关注并行开发与E2E自验，管理者投资一体化基建。
思维导图
用一张图看清主题之间的关系。
查看大纲文本（无障碍 / 无 JS 友好）
- Anthropic设计师AI工作流
- 实操Demo流程
- /prototype Skill生成5方案
- AI自选方案并解释理由
- Loop until done完整执行
- 并行Side Workflows
- 云端批量处理UI微调
- PR合并与Code Review自动化
- 定时巡检无设计评审变更
- 核心治理原则
- 人保留审美与最终决策权
- 非编码工作全面自动化
金句 / Highlights
值得收藏与分享的关键句。
验收单位已经改变：不再是聊天窗口里的文字，而是带视觉证据（GIF/录屏）的Pull Request。
若只用Claude Code写代码等于没用满这套工具，要把大量非编码工作也交给AI，将其视为全流程协作者。
人人都能ship不等于什么都该ship，代码门槛下降后需要可扩展的质量与治理机制，否则产品会失控。
使用claude-worktree多开Claude时避免改同一分支互相覆盖，比复制多份repo更好管理。
-- 来自 Claude Code & Cowork 设计负责人 @meaghaneschoi
核心命题：时间被压缩，但工作方式还没跟上 Meaghan 开场就点出一个行业现状： · 产品节奏越来越快，交付周期被大幅压缩； · Anthropic https://t.co/8I3ivHXj8Y" / X
Anthropic 内部设计师如何用 Claude Code 做产品、写代码、推 PR -- 来自 Claude Code & Cowork 设计负责人
核心命题：时间被压缩，但工作方式还没跟上 Meaghan 开场就点出一个行业现状： · 产品节奏越来越快，交付周期被大幅压缩； · Anthropic 内部因为能随时用最新模型、整天在试新用法，总在找「下一套更高效的工作方式」。 她这次分享的目标很明确：把团队内部已经验证过的 Claude Code 工作流，做成可复制的实操 demo，而不是讲概念。 同时她也先打了预防针：自己是 CLI 重度用户（她本人就参与设计 Claude Code 的 CLI），但 桌面版同样能做演示里的一切，不必为了学她而硬上终端。 现场 Demo：在 Excalidraw 上「一句话加功能」 演示选在开源项目 Excalidraw（issue 多、社区开放，适合练手）。任务极简： 给 Excalidraw 加一个 autocomplete 功能。没有设计稿，没有详细 spec。 她实际用的 Prompt 结构（值得学） 1. 调用自定义 /prototype Skill · 让 Claude 默认生成 5 个不同实现方案（HTML 预览 + 迭代）； · 她强调：没人再手写 Skill，都是让 Claude 生成。 2. 让 AI 先选方案，再解释理由 · 以前：原型出来 → 人选； · 现在：「你选一个并说明为什么」——把决策权部分交给模型，人只做最终确认。 3. 允许联网 / 查内部资料 · 开源项目：在线调研即可； · 自家产品：会要求查 Slack、Google Docs、BigQuery 等。 4. 实现 → 验证 → 样式对齐 → 开 PR 并附截图 她几乎 不再看终端对话，而是直接看 Claude 提交的 PR（含功能录屏/GIF）。 5. 使用 loop until done 让任务跑到真正完成，而不是中途停在一半。 6. 全员开 Auto 模式 用分类器判断风险操作，减少反复点「确认」，加快并行任务。 现场观众选了方案 2，她一句话确认后，Claude 继续往下做。 三条「操作层」建议（演示前） · claude-worktree：多开 Claude 时避免改同一分支互相覆盖；比复制多份 repo（repo1、repo2…）更好管 · Opus + 1M 上下文 + Fast 模式：少纠结模型选择，加快 demo（她承认并非所有人都有权限） · Auto 模式：降低权限摩擦，适合长时间并行跑任务 她还提到：平时会 同时开很多 Claude 会话；今晚为了展示流程，才只跑一个并边等边讲别的。 她坚持的三大原则（整场最重要的「观念层」） 1. LLM 目前还做不好设计 → 人必须留在审美与决策环里 · 「Claude 做设计还很糟」是她的原话； · 工作流围绕：AI 出方案，人定最终产品形态； · 这不代表永远如此，而是 当前阶段的现实约束。 2. 自动化不应只限于「写代码」 · 编码可以交给 AI，但她把大量 非编码工作 也交给 Claude； · 若只用 Claude Code 写代码，等于没用满这套工具； · 要把 AI 当成 全流程协作者，而不只是 Copilot。 3. 「人人都能 ship」≠「什么都该 ship」 · 代码门槛下降后，功能会泛滥； · 需要 可扩展的质量与治理机制，否则产品会失控。 这三条把演讲从「技巧清单」抬到了 组织与产品治理 层面。 三条「并行工作流」（Claude 在跑主任务时她在做什么） 这是视频最有价值的部分：Anthropic 设计负责人真实在用的 side workflows。 工作流 A：云端 Claude 批量处理「小抛光」 · 用 Claude in the web / cloud 提交大量零碎 UI 修复（CSS 微调等）； · 不值得为每个小问题开新会话； · 工程师有时会抱怨 PR 太多，她就让 Claude 合并成一个 PR； · 极小改动常 自动通过，无需人工 review。 启示：把「工艺感」维护成 后台持续流水线，而不是等项目排期。 工作流 B：PR 合并与 Code Review 自动化 她坦言：idea 定下来之后，她几乎不再碰 CI——不手动改 review 意见、不盯着 merge 流程。 依赖两类能力（多为内部 Skill，但逻辑可复刻）： · simplify / code review：大改前做代码卫生检查； · commit push PR：跑内部检查清单； · 审查所有 open PR 并推到可合并（原命令已封装成 Skill）； · 与 Slack 打通：自动 DM reviewer 或 stamp 频道、@ on-call。 配合 Claude in Chrome：前端改动由浏览器里自动点测、自验证；演示里 Claude 正在 Chrome 里测 autocomplete。 启示：人的精力应放在 决策与验收（PR + 录屏），而不是 diff 往返。 工作流 C：定时任务 —「无设计师参与的改动」巡检（最激进） 她用 Claude Cowork 的 scheduled task 跑一条 routine： 1. 扫描所有 repo 的前端变更； 2. 查 Slack、Google Meet 转录、Google Docs 等，判断 是否有设计师参与； 3. 若无 → 标记「未经设计评审就 ship」； 4. 生成 对抗性设计改进 并起草 PR，原本还会 DM 工程师（后因 AI 设计太差而关掉 DM）； 5. 她本人消费这份报告，并 为下一代模型预留脚本——模型变强后可直接再启用。 6. 她自嘲第一次试时「真的很烂」，但团队当时愿意包容；现在改为 自己消化报告，等模型升级再放开。 启示：自动化要想到 第 N 步（发现 → 评估 → 起草 → 通知 → 协作），而不是停在「生成代码」。 演示收尾：验收方式已经变了 主任务结束时，Claude： 1. 用 Chrome 扩展自测功能； 2. 用 GIF 录屏记录行为； 3. 自动开 PR。 她的验收单位是：带视觉证据的 Pull Request，而不是聊天窗口里的文字。 对不同角色的实用 takeaway · 设计师：/prototype 多方案探索；人定审美；小 polish 用云端批量提交；争取直接 ship 前端细节 · 产品经理：让 AI 查 Slack/Docs 再实现；用 loop 跑完；建立「能 ship 不等于该 ship」的规范 · 工程师：worktree 并行；对接 simplify/CR/merge 类 Skill；Claude in Chrome 做 E2E 自验 · 团队负责人：投资 Slack/CI/文档/定时任务一体化；为「设计治理自动化」留接口，即使当前模型还不够好