Claude Code 桌面端实战：从设计到 GitHub 自动合并的完整工作流

Claude Code 的桌面端正在把 AI 编程从命令行的「黑盒对话」拉回到可视化、可交互的开发体验。在一场来自 Anthropic 团队成员的现场演示中，我们看到了一条从 Claude Design 原型设计，到 Web 端接力、再到桌面端编码、最终完成 GitHub PR 自动合并的完整链路。本文梳理其中几个关键能力与使用技巧。

从设计稿到代码：一键 handoff 工作流

演示者坦言「设计一直是我最头疼的环节」，而 Claude Design 的出现改变了这一点。通过一次性（one-shot）生成的设计原型，可以直接 handoff 到 Claude Code，甚至立即发送到 Web 版的 Claude Code。

有意思的是，当一个只有设计、没有任何代码库连接的原型被打开时，Claude Code 会主动询问「要不要帮你搭建（scaffold）脚手架？」。这种从「我有一个想法」到「我有一个可运行原型」的过渡，极大降低了从创意到落地的门槛。演示者的原话是：「能够如此轻松地把它交接给 Claude Code，这是一个非常顺滑的工作流。」

这就是我们刚刚用过的那个预览

脚手架（Scaffold） 在前端开发中指的是自动生成项目初始结构的过程，包括目录布局、配置文件、依赖声明等基础骨架。传统流程中，开发者需要手动运行 create-react-app、vite 或 next 等 CLI 工具，并回答一系列配置问题才能得到可运行的项目。Claude Code 在这里的突破在于：它能读取设计原型的视觉结构，推断出合适的技术栈和组件层级，直接生成带有真实代码的可运行项目，而不只是空目录模板。这使得「有设计稿但还没写过一行代码」的状态，可以在几秒内跳转到「本地服务器已启动、组件已拆分」的状态。

桌面端：无需 IDE 和浏览器插件的可视化编辑

演示者的个人最爱仍然是 Claude Code 桌面端。与 CLI 相比，桌面端的核心优势在于可视化上下文。

当你有任何前端项目时，预览会直接集成在桌面应用内——不需要 Chrome 扩展，不需要额外配置。应用通过一个 launch.json 文件来启动开发服务器，前端画面直接在应用内渲染。

更关键的是元素选择能力。演示中，演示者直接选中界面上的一个按钮，说「把这个按钮变成蓝色」。桌面端会截取屏幕截图，并把对应的 React 组件、所有 props 和类型信息一起发给模型。模型因此能精确知道要改什么。

这解决了 CLI 的一大痛点：在命令行里说「把按钮变蓝」，模型往往会反问「哪个按钮？」，除非你自己手动截图，否则来回沟通成本很高。而桌面端把这一步自动化了。

可以快速查看 diff，无需打开 IDE

完成修改后，你可以直接在应用内查看 diff，无需打开任何 IDE，还能在 diff 上添加评论再发回给 Claude Code 继续调整。

PR 创建与 CI 自动修复：把 GitHub 流程托管给 AI

桌面端的「Create PR」按钮背后其实是一个 skill（技能）。点击按钮即触发创建 PR 的技能，Claude 作为 co-author 自动署名。

权限管理方面，演示者提到新增的 auto mode 很实用。此前的两种模式各有缺陷：bypass 模式会跳过所有权限询问（略显危险），而 accept edits 模式又会频繁询问（过于啰嗦）。auto mode 介于两者之间，提供了更平衡的体验。

CI 测试失败时可自动修复

真正强大的是 CI 联动。基于 GitHub App，当 PR 触发的 CI 失败时，你可以直接让 Claude「自动修复 CI 并处理评论」。Claude 会在后台迭代修复测试失败的问题，并响应同事在 PR 上留下的 review 评论。

如果再配合 GitHub 的 auto merge 设置，整个流程可以做到「开完 PR 就不用再管」——Claude 迭代修复直到 CI 全绿、评论全部处理完毕，GitHub 自动合并。这把人从繁琐的 CI 调试循环中解放出来。

GitHub App 是 GitHub 提供的一种集成机制，允许第三方服务以独立身份（而非借用某个用户账号）访问仓库事件和 API。与 OAuth App 不同，GitHub App 拥有细粒度的权限控制，可以精确声明它只读取 CI 状态、只写入 PR 评论，而不需要获取账号的全部权限。Claude Code 借助这一机制监听 PR 的 check_run 失败事件，并在检测到测试失败时自动触发修复流程。auto merge 则是 GitHub 原生提供的功能：当 PR 满足所有分支保护规则（如 CI 全绿、必要审查通过）时，GitHub 会自动执行合并，无需人工点击按钮。两者结合，使得 AI 的修复循环与 GitHub 的合并策略形成了完整的闭环。

上下文管理：compact、clear 与新会话的区别

面对「token 优化」的提问，演示者详细解释了几个容易混淆的概念。

compact（压缩）

当上下文接近用量上限（比如百万 token 里已用 60 万），而很多早期消息已不再相关时，可以使用 compact。它会再向模型发起一次调用，把所有对话消息合并压缩，只保留与当前会话相关的内容，从而释放大量被占用的上下文。

一个很多人不知道的技巧是：compact 可以带 hint（提示）。对于超大对话，如果不加提示直接压缩，Claude 可能会遗忘计划或你之前明确交代过的内容——因为它不知道该优先保留什么。此时可以提示它「确保保留我之前的所有评论和所有计划」，压缩效果会好很多。

compact 可以带提示一起使用

clear 与新会话

clear：在同一窗口切换到全新任务时使用，它不会保留任何历史。
compact：保留历史的摘要版本。
clear vs 新标签页：演示者认为两者本质相同——想留在同一窗口就用 clear，想开新终端/标签页则随意。

理解这几个命令的差异，需要先了解大语言模型的上下文窗口（Context Window） 概念。每次向模型发送请求时，所有历史对话消息都需要被打包进这个窗口，它有固定的 token 上限（Claude 目前支持约 200K token）。窗口填满后，模型要么拒绝处理，要么丢弃最早的消息。Compact 的本质是用一次「总结调用」把大量原始消息替换成一段高密度摘要，相当于把100页会议记录压缩成2页要点，代价是丢失部分细节，但保留了对后续任务最有用的脉络。这也解释了为什么 hint 如此关键——在压缩时明确告知模型「这些内容必须保留」，可以防止它按照通用摘要策略误删重要的技术决策或待办事项。

记忆文件：Claude 到底记住了什么

桌面端新增的 auto memory（自动记忆） 功能，会在检测到你多次重复某些指令时，自动写入一个 memory.md 文件。

需要注意的是，当前的记忆更偏向个人层面的纠正和偏好，而非特定项目的配置。演示者透露正在写一篇关于「Claude 到底记住了什么」的博客，因为目前哪些提示会被记住、哪些需要每次会话重新添加，确实还不够清晰。

小结

这套演示展现的核心价值在于：Claude Code 正从单纯的编码助手，演进为覆盖「设计 → 编码 → 预览 → PR → CI 修复 → 合并」全链路的开发平台。桌面端的可视化元素选择、CI 自动修复、auto memory 等能力，都在降低 AI 协作的摩擦成本。对于长期被设计环节困扰、或希望把重复 GitHub 流程托管出去的开发者而言，这是值得尝试的工作流。