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/文档/定时任务一体化；为「设计治理自动化」留接口，即使当前模型还不够好