返回
查看原链接原链接
Bilibili44分45秒 · —

Cloud Code 实战入门与进阶落地指南

Cloud Code 实战入门与进阶落地指南

Cloud Code 是一个不绑定特定模型的通用编程 Agent,其核心价值在于通过三种交互模式(默认、自动、规划)、终端控制、MCP 接入、上下文管理、CLAUDE.md、Hook、Agent Skill、Sub Agent 与 Plugin 等机制,将 AI 编程从“能跑通 Demo”真正落地为“高效可控的生产力工具”。

核心要点

本节梳理 Cloud Code 的总体定位、适用场景与同类产品关系,帮助读者在动手前建立全局认知。

  • 定位:Cloud Code 是一款交互式编程 Agent,支持在终端中通过自然语言完成代码编写、文件修改、终端命令执行、架构重构等完整开发流程。
  • 模型无关性:Cloud Code 本身不绑定 Anthropic 的 Claude 模型,可以通过设置环境变量接入国产模型(如 GLM、MiniMax 等),使其成为通用编程底座。
  • 同类产品:市场上类似的 Agent 还有 Codex、Open Code 等。作者认为它们在功能与使用方式上与 Cloud Code 没有本质区别,掌握 Cloud Code 后可“一通百通”,快速上手同类工具。
  • 完整落地路径:视频教程覆盖了从环境搭建、基础交互、复杂任务处理、终端控制、回滚、设计稿还原(含 MCP)、上下文管理,到 CLAUDE.md、Hook、Agent Skill、Sub Agent、Plugin 等高级扩展的完整实战流程。
  • 核心工具链:除 Cloud Code 本体之外,还需要用到 VS Code(作为外部编辑器)、Node.js/npm(运行前端项目)、Homebrew 或类似包管理器(安装 MCP Server)、以及 Figma(作为设计稿来源)。

环境搭建与基础交互

安装与登录

  • 安装方式:访问 Cloud Code 官方网站,复制安装命令,在终端中粘贴并执行即可完成安装。
  • 启动命令:在项目目录下执行 cloud 命令打开 Cloud Code 交互界面。
  • 登录方式:进入后若未自动提示登录,可执行 /login 命令主动触发登录流程。官方提供两种标准接入方式:
  • 订阅制:面向已购买 Claude Pro 或 Max 会员的用户,直接选择此项授权登录即可。
  • API Key 按量计费:使用官方 API Key,按照 token 用量付费,用多少花多少。
  • 登录流程细节:选择订阅制后会弹出网页授权页面,点击同意后回到终端按回车,登录即完成。

三种交互模式(shift+tab 循环切换)

Cloud Code 提供三种核心交互模式,通过 shift+tab 在它们之间循环切换。理解这三种模式是高效使用 Cloud Code 的分水岭。

模式名称显示特征核心行为适用场景注意事项
默认模式底部灰色提示 ? for shortcuts每次创建或修改文件前必询问用户,用户需逐次确认需要精细控制每一步文件变更的稳妥操作该提示是快捷键提示,并非“快捷键模式”
自动模式底部显示 accept edits on本次对话期间内,文件创建与修改自动通过,不再询问已明确需求方向、希望减少打断的批量开发只对“文件操作”生效,终端命令仍需确认
规划模式(plan mode)底部显示 plan mode只讨论方案、不执行任何文件修改复杂架构重构前的方案探讨与细节确认该模式适合梳理思路,不直接产出代码变更
  • 在自动模式下输入框下方会出现 accept edits on 作为当前模式的指示文字。
  • 在规划模式下,用户可以与 Cloud Code 充分探讨方案、补充需求细节,Cloud Code 会产出详细实施计划供审阅。

文件确认选项的含义

当 Cloud Code 请求创建或修改文件时,通常会给出三个选项:

  1. Yes(单次授权) :仅同意当前这一次文件操作;后续若还需其他文件操作,会再次询问。
  2. Yes, allow all edits during this session:选中后,本次会话期间后续所有文件操作自动通过,不再重复打扰。
  3. 不同意(No) :拒绝当前操作,用户可继续输入自己的想法,Cloud Code 会根据新输入生成代码并再次确认。

终端内打开文件

  • 方式一:在文件管理器中找到文件,双击打开。
  • 方式二(推荐) :在 Cloud Code 输入框中先输入 ! 进入 Bash 模式,即可执行任意终端命令。例如输入 open index.html 可打开 HTML 文件查看效果。

复杂任务处理与终端控制

处理示例:从零构建待办应用

需求提出与文件创建
  • 用户使用 mkdir my-todo 创建目录并进入,然后执行 cloud 打开 Cloud Code。
  • 输入需求“给我做一个待办软件,使用 HTML 实现”,Cloud Code 将创建 index.html 文件。
  • 为演示方便,选择了“自动同意”模式,后续文件写入不再打扰。
切换到现代架构的规划过程
  • 动机:最初生成的代码将全部逻辑写入 index.html,对于小项目可接受,但随着项目变大维护困难,因此决定迁移到 React + TypeScript + Vite 的现代架构。
  • 规划模式的使用:由于改架构是重大变更,应先确定细节再动手。按 shift+tab 进入 Plan Mode,输入重构请求。
  • 多行输入:在 Cloud Code 中,按回车会直接提交问题;若要换行,需按 shift+回车。如果 shift+回车 无效,大概率是 Cloud Code 版本过旧,需要升级。
  • VS Code 集成的替代输入方式:若觉得终端输入框不够顺手,可按 ctrl+g 打开一个 VS Code 标签页,在其中自由编辑内容(回车不会误提交);保存并关闭标签页后,内容自动回填到输入框中,此时按回车即可提交。此方式需要预先安装 VS Code。
计划生成与三种后续选项

Cloud Code 生成重构计划后,会提供三个选项:

  1. 执行计划并进入自动同意模式:后续修改文件前不再询问。
  2. 执行计划但使用默认模式:后续每次写入文件前仍需询问确认。
  3. 继续修改计划:对当前计划不满意时,可继续输入意见,Cloud Code 据此修改并产出新计划。
规划迭代的案例
  • 初次计划已覆盖项目目标、目录结构等内容。
  • 用户提出修改意见:“给每个待办事项增加一个优先级,比如高、中、低,并且用不同颜色标记出来。”
  • Cloud Code 修改计划后,在测试部分明确体现了优先级需求。
  • 用户选择第一项(执行并进入自动同意模式),Cloud Code 开始执行计划。

终端命令的权限机制与危险参数

终端命令仍需授权的设计逻辑
  • 现象:在自动同意模式下,Cloud Code 使用 mkdir 创建目录时仍然暂停并向用户确认。
  • 原因:Cloud Code 将终端命令视为比文件操作更危险的操作,必须征得用户同意才继续。
  • 选项细节:即便在终端命令确认弹窗中选择了第二项(例如“以后可以自由访问 src 目录”),也只是对该路径的访问授权,执行其他终端命令仍然要确认。
--dangerously-skip-permissions 参数
  • 作用:启动 Cloud Code 时附加 --dangerously-skip-permissions 参数,可跳过所有权限检测,Cloud Code 会进入 bypass permissions on 模式,此后执行任何终端命令(安装依赖、删除文件、创建目录等)都不会再征求用户意见。
  • 官方态度:参数本身带有 dangerously(危险)字样,官方已明确提示风险。
  • 双刃剑效应
  • 好处:极大提升开发效率,实现全自动开发,无需用户一直盯着点击同意。
  • 风险:Cloud Code 在理论上拥有与用户相同的终端权限,虽然它在“极度发疯”时破坏电脑的概率微乎其微,但仍存在理论上的安全风险。
  • 作者建议:是否为了效率承担该理论风险,决定权在用户手中;视频演示中默认仍不使用此参数,选择“允许自由访问 src 目录”来推进。

任务运行的阻塞、后台执行与任务管理

阻塞问题
  • 现象:当 Cloud Code 启动开发服务器(如 npm run dev)后,服务器运行会阻塞 Cloud Code 的输入处理。此时输入新请求(如“hi”),Cloud Code 不会做出回应,因为服务仍在运行,无法同时处理新请求。
将任务放入后台:ctrl+b
  • 在服务阻塞期间,按 ctrl+b 即可将当前运行的服务放置到后台,Cloud Code 便恢复对用户请求的处理能力,同时后台任务继续运行,后续对代码的修改可以实时在浏览器中看到效果。
查看与管理后台任务:/tasks
  • 输入 /tasks 可查看当前所有后台任务列表。
  • 在任务列表中按 k 键可关掉对应的后台服务。
  • 按 ESC 可退出任务列表界面并返回正常的输入界面。

回滚操作:/rewind、双击 ESC、/resume、/init

基本回滚操作
  • 触发方式:在输入框中输入 /rewind 或直接按两次 ESC,即可进入回滚(Rollback)页面。
  • 回滚点机制:Cloud Code 在用户每次输入请求时都会自动创建一个回滚点。
  • 回滚选项:Cloud Code 提供四个选项:
  1. 代码与对话都回滚:恢复到所选回滚点时的代码与对话状态。
  2. 只回滚对话:仅将对话内容恢复到当时状态,代码不变。
  3. 只回滚代码:仅将代码恢复到当时状态,对话内容保留。
  4. 放弃回滚:取消本次回滚操作。
  • 使用案例:以为待办应用添加中英文切换功能后决定放弃新功能为例,在回滚页面选择对应回滚点,选择“代码与对话都回滚”,之后刷新页面确认切换语言选项已经消失。
回滚功能的限制与 Git 比较
  • 仅能回滚 Cloud Code 自己写入的文件:由终端命令生成的文件(如 mkdir 创建的目录、npm install 安装的依赖等)不会被回滚。
  • 局限:若想精准回滚整个项目到某个状态,作者明确建议使用 Git 而非 Cloud Code 的内置回滚功能。
  • 手动清理示例:回滚到最初只有 index.html 的版本后,目录中仍残留许多由终端命令生成的文件,需要用文件管理器手动删除多余文件,只保留 index.html
会话恢复
  • `/resume` 命令:重新进入 Cloud Code 后,可用 /resume 命令选择并回到之前的会话。
  • `cloud -c` 命令-c 是 continue 的缩写,启动 Cloud Code 时加上该参数即可自动恢复上一次的对话,无需手动选择。

案例与操作复盘:一次典型的架构重构 + 回滚流程

为帮助理解上述内容在真实开发中的串联使用,这里将视频演示中的一个完整案例按时间顺序进行梳理:

  1. 初始:在 my-todo 目录中通过 Cloud Code 生成了一个基于 index.html 的待办应用。
  2. 重构请求:进入 Plan Mode(shift+tab),提出“将当前待办应用重构为 React + TypeScript + Vite 项目,保留所有现有功能,UI 风格保持一致”。
  3. 计划迭代:审阅 Cloud Code 生成的第一版重构计划后,选择“继续修改计划”,补充要求“为每个待办事项增加优先级,并标记颜色”。在第二版计划中确认该需求已被纳入。
  4. 自动执行:选择“执行计划并进入自动同意模式”,Cloud Code 开始重构。
  5. 自建目录授权:在需要创建项目目录结构时,Cloud Code 弹出终端命令确认框。选择第二项,授权其自由访问 src 目录后继续执行。
  6. 启动服务的授权:当 Cloud Code 尝试运行 npm install 时,选择“以后都同意”。
  7. 手动启动的部分:Cloud Code 想用 npm run dev 启动服务器时,选择取消(No),并告知 Cloud Code“这个命令等会自己执行,你确保其他部分都完成了即可”。Cloud Code 据此完成任务确认。
  8. 手动验证:用户自己运行 npm run dev,浏览器打开链接验证重写后的应用功能与 UI 正常。
  9. 再次开发:利用后台运行能力,新增页面右上角“切换语言”的功能(中/英文,默认中文),并验证其切换有效。
  10. 回滚决策:反思后认为“切换语言”功能并非用户所需(用户都看得懂中文),决定回滚。先关闭后台开发服务器(/tasks 后按 k),再按两下 ESC,选择重构前的回滚点,执行“代码与对话都回滚”操作。
  11. 清理:回滚完成后,虽然 index.html 已回到旧版,但仍残留重构时通过终端命令生成的依赖与配置文件。手动在文件管理器中删除除 index.html 之外的所有文件与目录,确认为干净的单文件状态。
  12. 结果:用 open index.html 验证回滚后的应用可正常打开运行,至此整个流程结束。

设计稿还原:图片直传与 MCP 接入

方法一:直接拖放图片

  • 适用场景:快速验证设计稿为截图或静态图片时的还原效果。
  • 具体操作
  1. 在 Figma 中选中所需 Frame,点击右下角的 Export Frame 将设计稿导出为 PNG 图片。
  2. 将 PNG 图片直接拖拽至 Cloud Code 对话框中,或使用 ctrl+v 进行粘贴(注意:在 macOS 上同样要按 control+v 而不是 command+v,后者不起作用)。
  3. 图片成功放入后,输入请求“根据图片修改代码”,Cloud Code 便会依据图片内容来调整页面。
  • 局限:大模型很难从静态图片上精确判断字体、间距等细节,还原度不够精确。

方法二:使用 MCP 服务(推荐)

MCP 概念简介
  • MCP(Model Context Protocol)是大模型与外界沟通的渠道。作者在之前的视频中系统性讲解过 MCP 的使用方法与原理。
  • Figma 官方提供了一个高质量的 MCP Server,可以接入 Cloud Code 以获取精确的组件间距、字体样式等信息。
Figma MCP 接入步骤
  1. 安装 MCP Server:按两下 ctrl+c 退出 Cloud Code,在终端执行 Figma 官方指定的安装命令,安装完成后重新打开 Cloud Code。原对话可用 /resume 恢复,或直接使用 cloud -c 自动恢复上一次对话。
  2. 验证工具:执行 /mcp 命令查看当前已安装的 MCP 工具,确认 Figma MCP 出现在列表中。
  3. 鉴权与授权:选择对应的 MCP 工具,选择 authenticate,Cloud Code 会自动弹出网页授权页面,点击同意后即完成鉴权。
  4. 查看工具状态:回到 Cloud Code 执行 /mcp,再次选择 Figma,此时状态已变为可用。选择 view tools 可查看该 MCP Server 内含的所有工具,如截图(screenshot)、创建设计规则等。
  5. 使用 MCP 完成还原:用户不需要关心该调用哪个具体工具,可将判断权交给 Cloud Code。具体流程为:
  • 在 Figma 中点击 copy link to selection 复制设计稿链接;
  • 回到 Cloud Code 输入需求“修改当前页面,使它与 Figma 稿件保持一致”,粘贴链接并回车;
  • Cloud Code 发现 Figma MCP 后,依次调用 get design context(获取设计上下文)与截图(screenshot)工具,获取设计稿的全部信息(包括截图、组件间距、字体样式等);
  • Cloud Code 基于这些结构化信息修改现有 HTML 代码。
  1. 效果评估:视频展示的对比中,还原效果相当不错,虽仍有 undefinedNaN 等小细节待打磨,但整体视觉还原度很高。

上下文管理

长会话中的上下文膨胀问题

在长时间、多轮次的开发过程中,Cloud Code 的上下文会积累大量信息(代码、工具调用结果等),其中有用的与无用的混杂。需要根据实际需求对上下文进行压缩或清理,以保证性能与 token 消耗的可控性。

上下文压缩:/compact

  • 命令用法/compact 命令可以对上下文进行压缩整理。
  • 可附加策略:可在命令后附上具体的压缩策略,例如“重点保留用户提出的需求”等。
  • 压缩效果:压缩完成后按 ctrl+o 即可查看压缩后的上下文内容。演示中,原先包含大量代码与 MCP 调用结果的上下文,在压缩后仅剩很短的精炼总结。
  • 价值:压缩不仅保障了 Cloud Code 的响应性能,也能显著减少后续执行任务时的 token 消耗。
  • 注意(缺陷) :压缩结果的可控性不强,Cloud Code 不提供手动编辑压缩后结果的选项。

上下文清空:/clear

  • 命令作用/clear/compact 更极端,会直接将所有上下文内容全部清空。
  • 适用场景:后续任务与之前的对话没有关联时,可使用此命令开启一个干净的会话。

上下文与项目的绑定局限

无论压缩与否,上下文都与某个特定会话绑定。当退出 Cloud Code 后再次进入时,它默认并不知道之前发生了什么,需要先恢复到对应会话,Cloud Code 才能读取相关历史上下文。

项目记忆与规范化:CLAUDE.md

CLAUDE.md 的核心作用

CLAUDE.md 是解决“项目知识沉淀”问题的关键机制:它可让 Cloud Code 在每次进入交互时自动读取用户提前写入的项目说明、需求背景、注意事项、编码规范等信息,从而更好地理解项目并按其提示执行任务。

自动生成:/init

  • 在 Cloud Code 中输入 /init,它会自动扫描当前项目并生成一份 CLAUDE.md 文件。
  • 该文件位于项目根目录中,内容会概括项目基本情况,默认生成语言为英文,可要求 Cloud Code 翻译为中文。
  • CLAUDE.md 的内容可以随时自由修改。例如可在末尾添加一条指令:“每次回答的最后必须追加一句 happy coding”。修改后重启 Cloud Code 即可重新加载最新版本。
  • 验证:在重启后随口说一句“hi”,Cloud Code 回复末尾确实出现了 happy coding,证明配置文件生效。

快速定位:/memory

  • 在输入框中输入 /memory 可以看到 CLAUDE.md 的两种类型:
  • 项目级别:文件放在当前目录中,只对当前项目生效。
  • 用户级别:文件放在用户目录中,对当前用户所有项目生效。
  • 选择对应项后,CLAUDE.md 文件会被直接打开(如使用 VS Code),这是快速定位编辑入口的方法。

自动化定制:Hook 功能

Hook 的定义与功能

Cloud Code 的 Hook 功能允许用户在“工具运行前后”等特定时机执行一段自定义逻辑,这本质上是一种自动化钩子机制。典型应用包括代码自动格式化,即在 Cloud Code 完成写文件后,无缝接入用户自己定义的格式化流程。

配置流程(通过 /hooks 命令)

  1. 进入配置页面:输入 /hooks 打开 Hook 配置页面。
  2. 选择执行时机:可选时机包括工具使用前、工具使用后、工具使用失败、发送通知等。演示中以“工具使用后”为例,选择 PostToolUse
  3. 添加触发器:选择 Add New Matcher,指定希望触发 Hook 的工具。填写 WriteEdit,表示在 Cloud Code 创建或编辑文件后触发该 Hook。
  4. 填入具体的 Hook 命令:选择 Add New Hook 并填写具体命令。

命令示例解析(自动格式化命令)

演示中使用的格式化命令较长,其核心逻辑为:

... | jq -r '.file_path' | xargs -I {} prettier --write {}
  • Cloud Code 在运行 Hook 时会向命令传入一份 JSON 数据,其中 file_path 字段指向刚刚编辑好的文件路径。
  • jq 是一个用于解析 JSON 的命令行工具,命令中 jq -r '.file_path' 的功能是从 JSON 中提取出文件路径字段的值并交给下一个环节。
  • xargs 将得到的文件路径传递给 prettier 命令,最终由 prettier 对目标文件完成代码格式化。

三种保存级别与选择

保存 Hook 时需选择其生效范围,实际对应不同的配置文件,影响分发范围:

  1. 本地项目级:只在当前机器的当前项目中生效。配置保存于项目的 settings.local.json,并自动写入 .gitignore,因此不会随 Git 分发共享给他人。
  2. 项目级:对所有使用该项目的用户生效。配置保存于 settings.json,该文件会随 Git 分发到所有协作者。
  3. 用户级:对当前用户的所有项目生效。配置存放在用户主目录下,每个用户各自一份,不会互相影响。

演示验证:配置完 Hook 后,请求 Cloud Code 创建一个仅含一行 HTML 的 test.html 文件。当 Cloud Code 实际写入多行内容后,Hook 生效并自动将文件格式化为美观的多行结构。视频证实,查看最终文件时已被格式化为漂亮的 HTML 代码,证明该自动化自定义机制按预期运转。

Hook 与命令执行时的风险考虑

Hook 会按设定自动执行,给工作流带来极大便利。本次演示只是格式化文件,并不涉及高危操作。若有需要,请务必像配置 --dangerously-skip-permissions 参数那样谨慎评估其权限范围与潜在副作用,确保自动化逻辑来自可信来源且确实无害。

Agent Skill

核心概念

Agent Skill 可理解为“给大模型看的说明书/动态加载的 Prompt”,可协助 Cloud Code 处理那些需要一定固定模板与格式的重复任务。它由大模型自动发现并调用,也可以由用户主动触发。

创建方法:以“每日开发报告”为例

  1. 创建目录:在用户目录下的 .claude/skills 文件夹中新建一个子目录,如 daily-report
  2. 创建 Skill 文件:在该目录下创建 SKILL.md,填入以下两部分内容:
  • 元数据(name 与 description) :定义 Skill 名称与用途描述。Cloud Code 根据这段描述智能判断用户请求是否与该 Skill 相关。
  • 具体描述:详细介绍 Skill 需要完成的任务。例如在本案例中规定了一份完整日报的格式规范,包括日期、开发摘要、开发详情等必备字段。
  1. 安装目录的注意点:Agent Skill 是放在用户全局目录还是项目目录中,决定了当前用户的所有项目或仅当前项目可见。

使用方式

  • 情景触发:当用户输入“写一份每日总结”等语义相符的请求时,Cloud Code 会自动识别出该请求与 daily-report Skill 的相关性,请求调用该 Skill。用户同意后,Cloud Code 便严格按照 Skill 中定义的格式完成总结输出。
  • 手动触发:也可主动以 /daily-report,后接具体请求的方式调用该 Skill,跳过模型意图识别的过程。结果是限制性更强、更可控。

Sub Agent

定义与核心特征

Sub Agent 是一个拥有独立上下文独立工具集独立 Skill 的独立 Agent。它接受主任务后独自运行,完成后再将最终成果汇报给主 Agent。主对话不包含它的中间过程。

创建过程(以代码审查 Sub Agent 为例)

  1. 输入 /agent 并选择 create new agent
  2. 选择一级类型:项目级(所有使用该项目的人可用)或 用户级。演示选择项目级。
  3. 选择二类创建方法:一种是由 Cloud Code 初始化生成,另一种是完全手动创建。官方推荐第一项,演示也选择 Cloud Code 自动初始化。
  4. 填写对该 Sub Agent 用途的描述:“这是一个用于代码审核的 Sub Agent,在用户要求代码审核的时候调用它”。
  5. 选择可用工具集:演示选择 read-only tools,即只读工具,移除其余工具权限。
  6. 选择模型:如默认的 Sonnet。
  7. 指定颜色:Cloud Code 运行时用该颜色展示该 Sub Agent 的对话,例如绿色。
  8. 修改生成内容:Cloud Code 生成的 Sub Agent 默认描述为英文,且通常与期望存在差异。按 e 键可编辑其描述文件,替换为自定义内容,例如:
  • 说明审查准则(含 JS 审查项与 CSS 审查项);
  • 描述输出格式要求。
  1. 重启 Cloud Code 使配置生效。

使用效果

请求“给我做一下代码审核”时,Cloud Code 会调用刚创建的 Sub Agent 并将任务描述传给它。可以从终端中看到该 Sub Agent 以自定义的绿色显示,其最终给出的代码审核报告与之前预设的两条准则及输出格式保持一致。

Agent Skill 与 Sub Agent 的对比(从上下文视角)

  • Agent Skill:由直接运行,运行时会完全继承和共享主对话的上下文。其每一行日志与思考过程都会写入主上下文。当将任务交由 Skill 处理几万行代码的项目时很容易把上下文撑满,造成 token 消耗飙升与 agent 变慢变傻。因此 Agent Skill 最适合处理与主上下文关联大、但对上下文本身影响小的任务,如按今日的开发过程写一份每日总结。
  • Sub Agent:拥有完全独立的上下文。每次启动时都会开辟新的对话窗口,所有代码阅读与中间分析都在该窗口完成,不会回传主对话。主对话仅收到其最终执行结果。上述过程可避免让无关紧要的中间信息占用主上下文。因此 Sub Agent 适合处理与主上下文关联较小、但输出结果又对上下文影响较大的任务,例如对大型项目做代码审核。

Plugin 插件系统

定义与构成

Plugin 可类比为“全家桶安装包”——在 macOS 上相当于 DMG 安装包,在 Windows 上相当于 EXE 程序。它将多个 Skill、Sub Agent、Hook、MCP 等能力打包在一起,用户只需一次安装即可获得整套配置。使用插件可以避免逐一配置的繁琐过程。

安装流程(以“前端设计风格”插件为例)

  1. 输入 /plugin 进入插件管理器,可看到 Discover(发现)、Installed(已安装)、Marketplaces(插件市场)等选项。
  2. 在 Discover 列表中搜索并选中目标插件,如 frontend-design 后按回车。
  3. 选择安装范围:默认选项是“对当前用户生效”、“对当前项目生效”、“对当前用户的当前项目生效”等;绝大多数情况下保持默认即可。
  4. 等待安装完成即可。
  5. 重启 Cloud Code 后进入 /plugin 再选择 installed,可查看到该插件的详细信息。例如所选插件主要由一个 frontend-design 的 Agent Skill 组成。
  6. 在输入框中执行 /skills 可以确认该 Plugin 所带来的技能已被加载。
  7. 根据视频演示,启用该插件后可让前端界面避免大模型“默认深紫色主题”的雷同感。演示效果说明,按照该插件规范生成的页面更具高级排版、协调色彩与符合现代审美的交互设计。
  8. 注意:部分 Plugin 可能内部包含多个元素(MCP、Hook、Skill 等),可按需组合选用。
  9. 也可参考官方文档将自己沉淀的 Skill、Sub Agent、MCP 等配置打包成 Plugin 分享给团队或社区。

限制与待确认问题

  • 回滚能力边界:Cloud Code 的回滚只针对它自己直接写入的文件,对 npm installmkdir 等终端命令产生的文件无法回滚。教程中建议依靠 Git 作为最终与最安全的回滚方案。
  • 设计稿还原精度:通过“图片直传”方式还原 Figma 设计稿时,大模型对字体、间距等静态图信息的还原往往做不到足够精确;MCP 方式能显著提高精确度,但对细节仍存在潜在偏差。
  • Agent Skill 与上下文限制:Agent Skill 没有独立上下文,运行期间会与大上下文共享,长任务时可能出现 token 消耗过高与模型“变慢变傻”的风险。
  • 插件生态待发展:目前 Cloud Code 的插件市场仍在高速增长期,除 UI 设计类之外,还出现针对特定语言的 LSP 插件;但对于非常见或小众的工程能力,可能仍没有成熟插件覆盖。
  • MCP 与第三方模型接入方法细节:该教程序章中明确提到国产模型可以通过设置几个环境变量来驱动 Cloud Code,但并未逐步详解其具体配置过程(如环境变量名称等);如有需要,请另行查阅官方文档或相关中文教程。
  • --dangerously-skip-permissions 参数的风险:启用后 Cloud Code 拥有与用户同等终端权限,理论上可执行破坏性命令。虽然概率极低,但需要在效率与安全之间自行权衡;具体实际风险案例未在视频中出现。

行动清单

以下为从零开始上手落地 Cloud Code 的简明操作列表:

  1. 安装、登录并完成基本验证:在终端执行官方提供的安装命令,进入 cloud 交互页,使用 /login 完成订阅或 API Key 认证。
  2. 掌握三种工作模式的含义与切换:使用 shift+tab 让模式在默认、accept edits(自动同意)与 plan mode(规划)之间循环切换,并熟悉各自的限制——文件授权粒度与终端命令仍需单独确认。
  3. 建立真实小项目跑通“需求-修改-运行”闭环:例如创建 my-todo 目录并请求一个最简单实现,涵盖“用 ! 快速执行终端命令(mkdir 与 open)”、“用 ctrl+b 把阻塞任务放入后台”与“/tasks 查看后台任务”等操作。
  4. 规范化项目记忆:在项目根目录运行 /init 创建 CLAUDE.md,将其内容翻译成中文并按需补充说明事项;验证应体现“每次进入项目都自动加载”。
  5. 为重复性高频操作建立三种自动化资产
  • 在用户级或项目级 .claude/skills/ 中新建 SKILL.md 定期完成的重复生成任务;
  • /hooks 配置代码自动格式化规则;
  • /agent 创建可承担大任务的独立 Sub Agent,并为它指定只读工具、模型与专属颜色;
  1. 需要时真正接入前端设计稿:直接粘贴 PNG 或接入 Figma MCP Server 后用真实设计稿执行一次还原任务。
  2. 养成上下文管理习惯
  • 面对长会话,使用 /compact 做压缩并查看结果;
  • 需要彻底切换任务且不再需要旧上下文时,执行 /clear
  • 记得用 cloud -c/resume 恢复会话。
  1. 对外输出与团队分享:当积累出比较满意的配置组合,按官方文档将其打包成 Plugin 并考虑通过插件市场分发给团队或社区。

总结

Cloud Code 的真正价值不在于“多敲几条命令”,而在于掌握了环境搭建、三种工作流模式、上下文管理、CLAUDE.md、Hook、Agent Skill、Sub Agent、Plugin 等一系列从个人配置到团队协作的进阶机制之后,能把它纳入规范化工程流程、生成真正符合需求的高质量产物。同时,模型本身并不绑定任何厂家,亦可按需接入其它模型 API,拓宽工具的适用范围——从第一句需求到架构重构、精确还原设计稿、再到将代码风格与工作流固化为可分享插件,整个过程体现的正是“AI 编程落地生产环境”的现实路径,而非停留在概念或 Demo 层面。其他同类 Agent(如 Codex、Open Code)在原理与功能上大同小异,理解并掌握本教程中的通用概念后几乎可以无痛迁移。后续使用中要注意把 Git 作为最终回滚守门员,对“跳过权限”类能力保持必要的谨慎边界。