Anthropic 设计师用 Claude Code 做产品、写代码、推 PR 的实操工作流

Anthropic 内部设计师如何用 Claude Code 做产品、写代码、推 PR -- 来自 Claude Code & Cowork 设计负责人 @meaghaneschoi 核心命题...

精选理由

Anthropic 内部设计负责人的真实工作流,把 Claude Code 从代码工具升级为全流程协作者,做产品、写代码、推 PR 一条龙。设计师、产品经理、工程师都能直接复制她的 prompt 结构和并行工作流,看完就能用。

AI 摘要

Anthropic 内部设计负责人 Meaghan 分享了团队已验证的 Claude Code 工作流,核心是让 AI 成为全流程协作者,而非仅代码工具。她演示了在 Excalidraw 上通过一句话 prompt 加功能,包括多方案生成、AI 自主选方案、自动开 PR 并附录屏。她强调 LLM 目前做不好设计,人必须留在审美与决策环中,同时将自动化扩展到非编码任务,如批量 UI 修复、代码审查和定时巡检。她还提出了三条组织级原则:自动化不限于写代码、人人都能 ship 不等于什么都该 ship、需要可扩展的质量治理。

原文 · shao__meng

Anthropic 内部设计师如何用 Claude Code 做产品、写代码、推 PR -- 来自 Claude Code & Cowork 设计负责人 @meaghaneschoi 核心命题...

Anthropic 内部设计师如何用 Claude Code 做产品、写代码、推 PR -- 来自 Claude Code & Cowork 设计负责人 @meaghaneschoi 核心命题:时间被压缩,但工作方式还没跟上 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/文档/定时任务一体化;为「设计治理自动化」留接口,即使当前模型还不够好 Ridd 🤿 @ridd_design ~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 it gets)👇 Your browser does not support the video tag. 🔗 View on Twitter 🔗 View Quoted Tweet 💬 0 🔄 0 ❤️ 1 👀 61 ⚡