Anthropic设计负责人分享Claude Code已验证工作流 · AI HOT
meng shao @shao__meng 72
2026-06-05 08:58 ·28天前
AI 摘要 Anthropic设计负责人Meaghan在NYC Dive Club Live展示团队已验证的Claude Code工作流。现场演示用/prototype Skill为Excalidraw生成5个方案，让AI选择并解释，然后实现、验证、开PR（含录屏）。她强调三大原则：LLM做设计还很糟，人必须留审美环；自动化不应限于写代码；人人都能ship不等于什么都该ship。并行工作流包括云端批量UI修复、自动Code Review与PR合并、定时巡检无设计师参与的改动并生成草案。验收单位从聊天文字变为带视觉证据的Pull Request。建议使用claude-worktree、Opus加百万上下文、Auto模式。
meng shao @shao__meng · X 2026-06-05 08:58 · 28天前
在 X 看原推 · x.com AI 摘要 Anthropic设计负责人Meaghan在NYC Dive Club Live展示团队已验证的Claude Code工作流。现场演示用/prototype Skill为Excalidraw生成5个方案，让AI选择并解释，然后实现、验证、开PR（含录屏）。她强调三大原则：LLM做设计还很糟，人必须留审美环；自动化不应限于写代码；人人都能ship不等于什么都该ship。并行工作流包括云端批量UI修复、自动Code Review与PR合并、定时巡检无设计师参与的改动并生成草案。验收单位从聊天文字变为带视觉证据的Pull Request。建议使用claude-worktree、Opus加百万上下文、Auto模式。
这三条把演讲从「技巧清单」抬到了 组织与产品治理 层面。
三条「并行工作流」（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/文档/定时任务一体化；为「设计治理自动化」留接口，即使当前模型还不够好
Ridd 🤿 ~12 min of Claude Code tips for designers (straight from the design lead @meaghaneschoi) here's her demo from Dive Club Live in NYC (it's about as practical as ...
她实际用的 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/文档/定时任务一体化；为「设计治理自动化」留接口，即使当前模型还不够好
Ridd 🤿 ~12 min of Claude Code tips for designers (straight from the design lead @meaghaneschoi) here's her demo from Dive Club Live in NYC (it's about as practical as ...
meng shao@shao__meng · X