Claude Code
初始化
安装
Claude Code 是 Anthropic 官方基于 Claude 大模型打造的原生 AI 编程工具，专为开发者设计，深度融入本地开发流程，实现从需求描述、代码编写、调试重构、版本控制到项目部署的全流程 AI 辅助。
从能力的角度来看，核心特征有三个：
- 上下文感知：不仅理解单个文件，而是理解整个项目结构。
- 工程化导向：关注可维护性、规范、测试，而不是一次性代码。
- 可定制行为：通过 Skills（技能包）让 AI 遵守你的规则。
官网：https://claude.com/product/claude-code
现在 Claude Code 提供了更简单的一键安装方式，不需要安装 Node.js，直接终端打开输入即可安装：
Mac 用户：
curl -fsSL https://claude.ai/install.sh | bash
Win 用户：「以管理员身份运行」，安装过程会自动下载，等个 1-2 分钟就好。
irm https://claude.ai/install.ps1 | iex
安装完成的标志：会提示「Claude Code installed successfully」。
使用方式：
| 使用方式 | 适合人群 | 核心优点 | 局限性 |
|---|---|---|---|
| Web 端 | 完全新手 | 无需安装，浏览器打开 claude.ai 即可使用 | 功能相对有限，无法访问本地开发环境 |
| CLI 命令行 | 全阶段开发者 | 功能完整、集成度高、适配所有开发场景 | 需要基础的命令行使用能力 |
| 桌面端/编辑器集成 | 日常开发从业者 | 无缝融入工作流，一键唤起不打断开发节奏 | 依赖客户端/插件环境配置 |
CC Switch
CC Switch 的核心价值在于：无需手动修改各 CLI 工具的配置文件，只需在图形界面中点击切换，即可将 Claude Code、Codex、OpenCode、Gemini CLI 的 API 请求路由到不同的 Provider（官方、第三方中转、自建服务等）。
主要的功能：
| 功能 | 说明 |
|---|---|
| Provider 管理 | 添加、编辑、切换、删除 API Provider，支持预设模板 |
| 本地 API 代理 | 内置高性能本地 HTTP 代理，自动接管 CLI 配置 |
| Auto Failover | 自动检测 Provider 故障并切换到备用节点 |
| MCP 服务管理 | 统一管理 Claude/Codex/Gemini 的 MCP 服务器 |
| Skills 管理 | 安装/卸载/同步社区 Skills 扩展 |
| 多语言支持 | 中文 / English / 日本語 |
| 请求日志 | 记录代理请求与使用统计，方便调试和成本追踪 |
Github：https://github.com/farion1231/cc-switch
配置模型（国内推荐 GLM 模型，购买 Coding Plan 计划）：
点击左上角'设置'按钮，在通用页面下拉找到 跳过 Claude Code 初次安装确认，务必勾选。
在终端运行 claude，看到对话界面并能正常回复即表示配置完成。
VScode 配置
安装 vs code：https://code.visualstudio.com
安装插件：https://marketplace.visualstudio.com/items?itemName=anthropic.claude-code
或者在 vs code 插件市场搜索「Claude code」，即可安装。
为什么推荐使用 Vscode 插件开发？
我们可以选中文件中的代码，让 Claude Code 帮我们解析说明或修改，选中后，会提示已经选中的代码行数。
当 Claude 需要修改文件时，它会自动打开并排对比视图，左边显示文件原始内容，右边显示建议修改后的内容，然后询问您是否同意修改。
如果需要的话，可以开启 Claude code 全自动模式。
默认状态下，Claude code 只能在 plan、手动确认、自动编辑三种模式选择，可以在 cc 插件里开启「Allow Dangerously Skip Permissions」，这样能开启全自动模式，cc 能自动运行命令，无需二次确认。下面的选项里，也可以把全自动模式配置为默认模式。
权限模式：
- 正常模式（默认）：Claude 每次要操作前都会先问你同不同意。
- Plan Mode（计划模式）：Claude 先告诉你它打算怎么做，得到你批准后才动手修改。
- 自动接受模式：Claude 直接编辑，不再每次询问。
注意：Shift + Tab 也可以进行切换。
命令菜单：在提示框里输入 /（或点击输入框）就能打开命令菜单。
常用选项包括：附加文件、切换模型、开启扩展思考、查看使用量（输入 /usage）。
多行输入：按 Shift + Enter 可以换行。
上下文用量指示器：提示框下方会实时显示你已经用了多少 Claude 的上下文窗口（context）。Claude 会自动帮你压缩内容；如果你想手动压缩，输入 /compact 即可。
引用文件和文件夹
直接用 @ 提到文件或文件夹就行。支持模糊匹配，不用打全名。
小技巧：
- PDF 大文件专属：你可以指定让 Claude 只读某几页，例如"第 1-10 页"或"从第 3 页开始"。
拖拽附件：把文件拖到提示框时按住 Shift，可以作为附件添加。想删除附件？点击附件右上角的 × 即可。
隐藏选中内容：点击提示框底部的"选择指示器"（眼睛图标），斜杠眼睛表示 Claude 看不到你选中的文本。
快速插入：按 Option + K（Mac）或 Alt + K（Windows/Linux），就能插入带文件路径和行号的 @ 提及，例如 @app.ts#5-10。
选中代码时：直接在编辑器里选中一段代码，Claude 会自动看到你选中的部分。提示框下方会显示"已选中 XX 行"。
恢复过去的对话
点击 Claude Code 面板顶部的下拉菜单，就能看到你的所有聊天历史记录。支持关键字搜索，也能按时间筛选（今天、昨天、过去 7 天等）。鼠标悬停在某条记录上，会出现 重命名 和 删除 按钮：
- 重命名：给对话起个好记的标题
- 删除：把这条记录从列表里移除
工作流程
当你给 Claude 一个任务时，它会像人类一样循环思考三个步骤：
- 收集上下文（看你的代码、文件、错误信息）
- 采取行动（编辑文件、运行命令、搜索等）
- 验证结果（检查是否成功，哪里还需要调整）
这三个步骤会不断循环，直到任务完成，当然我们也可以随时可以打断它、给新指示，或者说"换个方法试试"。
配置
命令行命令
- /clear：清除对话历史
- /help：显示可用命令
- /login：登录或切换账号
- /resume：恢复之前的对话
- /exit or Ctrl+C：退出 Claude Code
- /model：切换模型
会话：
- 直接恢复会话：claude --continue
- 分叉会话：claude --continue --fork-session
上下文窗口： Claude 有上下文容量限制。当快满时，它会自动压缩旧内容。
- /compact：手动压缩
/context：查看当前占用情况
技巧：
- 重要规则写进 CLAUDE.md
- 用 skills 和 subagents 减少不必要的上下文占用
安全机制：
- 检查点（随时后悔）：Claude 修改文件前会自动备份。只要按两次 Esc，或说"撤销刚才的修改"，就能回到之前状态。
- 权限模式：按 Shift + Tab 快速切换。
项目初始化：/init，Claude 会自动扫描你的代码库，然后生成一份专属于你项目的 CLAUDE.md 文件。
CLAUDE.md 文件：CLAUDE.md 是一个 放在项目根目录的 Markdown 文件，Claude Code 在 每次会话开始时都会自动读取，不再需要重复解释基本信息。
一份好的 CLAUDE.md 应该覆盖三个维度：
- WHAT（是什么）：技术栈、项目结构，为 Claude 提供代码库的全局地图
- WHY（为什么）：项目的目的，各模块的功能与定位
- HOW（怎么做）：开发方式，例如使用 bun 而非 node，以及 Claude 如何验证改动是否正确 Humanlayer
以下是一份典型的 CLAUDE.md 结构示例：
# My Project 一句话描述项目用途。
## Tech Stack
- Backend: Python / FastAPI
- Frontend: React + TypeScript
- Database: PostgreSQL
## Common Commands
`npm run dev` # 启动开发服务器
`pytest tests/` # 运行测试
`npm run build` # 构建生产版本
## Code Conventions
- 使用 snake_case 命名变量
- 所有 API 需要写单元测试
- PR 合并前必须通过 CI
## Architecture Overview
src/
├── api/ # FastAPI 路由层
├── services/ # 业务逻辑层
└── models/ # 数据模型层
技巧：
- 提交到版本控制：
将 CLAUDE.md 提交到 Git，这样整个团队都能从中受益，新成员可以通过让 Claude 解释代码库来快速上手。 - 保持精简：内容要简洁且普遍适用。
采用"渐进式披露"原则——不要把所有你想让 Claude 知道的内容都塞进去，而是告诉它如何查找重要信息，让它按需获取，避免撑爆上下文窗口。 不要让 CLAUDE.md 替代 linter：在文件中写代码风格规范是最常见的误区之一。永远不要用 LLM 来做 linter 的工作——linter 更快、更便宜，而且是确定性的。代码风格约束只会让上下文窗口膨胀，降低 Claude 的指令遵从质量。(Codestyle 就是去规范这个的)
一个完整的 Claude Code 项目通常包含以下文件和目录，按功能可分为「项目指令层」、「配置权限层」、「扩展能力层」三大模块：
your-project/
├── CLAUDE.md ← 团队共享指令，提交到 git
├── CLAUDE.local.md ← 个人覆盖，被 git 忽略，
└── .claude/
├── settings.json ← 权限 + 配置，提交到 git
├── settings.local.json ← 个人权限，被 git 忽略
├── commands/ ← 自定义斜杠命令
│ ├── review.md → /project:review
│ ├── fix-issue.md → /project:fix-issue
│ └── deploy.md → /project:deploy
├── rules/ ← 模块化指令文件（全局生效）
│ ├── code-style.md
│ ├── testing.md
│ └── api-conventions.md
├── skills/ ← 自动调用的工作流
│ ├── security-review/
│ │ └── SKILL.md
│ └── deploy/
│ └── SKILL.md
└── agents/ ← 子代理角色定义
├── code-reviewer.md
└── security-auditor.md
CLAUDE.local.md：存放只与你本人相关的偏好或临时指令，不应提交到 Git（建议添加到 .gitignore）。
# 我的本地覆盖
本地数据库地址：localhost:5433（非默认端口）
调试时请优先输出详细日志。
## 临时规则（本次任务用）
目前专注于重构 auth/ 模块，其他模块暂时不要改动。
.claude/settings.json：团队共享的安全基线配置文件，控制 Claude 允许或禁止执行哪些操作，需提交到 Git 统一管理。
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(pytest:*)",
"Bash(git diff:*)",
"Bash(git log:*)"
],
"deny": [
"Bash(rm -rf *)",
"Bash(curl * | bash)"
]
}
}
settings.local.json：用于临时放开或收紧某些权限，不影响团队其他成员，不应提交到 Git。
{
"permissions": {
"allow": [
"Bash(rm ./tmp/*)"
]
}
}
.claude/commands/：该目录下的每个 .md 文件会自动映射为一条 /project:文件名 命令，是团队将重复性任务标准化的核心机制。【当你发现 自己重复输入相同的指令 时】
命令映射规则：
| 文件名 | 对应命令 |
|---|---|
| review.md | /project:review |
| fix-issue.md | /project:fix-issue |
| deploy.md | /project:deploy |
参数传递：命令文件中可使用 $ARGUMENTS 占位符 接收调用时传入的参数。
例如：commands/fix-issue.md（带参数）
# Fix GitHub Issue
给定 Issue 编号 $ARGUMENTS，请：
1. 读取并理解 Issue 描述
2. 定位相关代码文件
3. 实现最小化修复方案
4. 编写对应的单元测试
5. 更新 CHANGELOG.md
调用方式：/project:fix-issue 123
.claude/rules/：将 CLAUDE.md 中的规则拆分模块化存放，Claude 在整个会话中始终遵守这些规则。适合存放长期稳定执行的行为约定，避免 CLAUDE.md 过于臃肿。【当 CLAUDE.md 超过 100 行时，拆分模块。】
rules/code-style.md
# Code Style Rules
- TypeScript 严格模式，禁用 any 类型
- 函数长度不超过 40 行，超出则拆分
- 优先使用 const，避免使用 let
- 导入顺序：标准库 → 三方包 → 本地模块
- 所有 export 的函数/类型需要 JSDoc 注释
- 禁止使用 console.log，使用项目 logger
.claude/skills/：Skills 是更高级的复合工作流。当 Claude 判断某个任务适合某个 skill 时，会自动读取并执行对应的 SKILL.md，无需手动调用。每个 skill 是一个子目录，目录内必须包含 SKILL.md。【当有复杂的多步骤工作流需要标准化时。】
⚡ Skills vs Commands 的核心区别：
- Commands：需要
用户主动输入斜杠命令触发，是'工具箱'。 - Skills：由 Claude
根据上下文自动判断是否调用，是'智能本能'。
.claude/agents/：定义可被主 Claude 实例派遣的专业子代理。在复杂任务中，主代理将子任务委派给对应专家角色，实现多代理协作。子代理在隔离上下文中运行，拥有独立的权限范围。【当任务复杂到需要多个专业视角并行时。】
示例：agents/code-reviewer.md
---
name: code-reviewer
description: Reviews code for quality, best practices, and security issues
---
# 代码审查员
## 角色定位
你是一名拥有 10 年经验的资深工程师，专注于代码可读性、性能优化和最佳实践。
## 审查重点
- 命名是否清晰表达意图
- 函数/类的单一职责原则
- 边界条件和错误处理
- 性能瓶颈（N+1 查询、不必要的循环等）
## 权限
只读访问，不直接修改文件。
## 输出格式
使用 Markdown 表格输出，包含：问题位置、严重程度、建议方案。
前缀匹配器
Claude Code 输入框的本质，可以理解成一个统一入口，所有的操作其实都是通过 前缀匹配器。
- 无前缀：自然语言给任务
- / 前缀：调用内置命令
- @ 前缀：注入
文件/目录/日志作为上下文 - ! 前缀：直接执行 Bash 命令。例如：
! ls -la、! git status、! npm test #前缀：把内容持久写入 CLAUDE.md，从而让某些信息跨会话长期生效。- & 前缀：把任务放到后台或云端异步执行，不阻塞当前会话，即使你关闭终端，也可以之后在 claude.ai/code 查看进度。
- 多行输入：一次性描述复杂需求
一句话总结：/ 控行为，@ 给材料，! 跑命令，# 存记忆，& 开后台，无前缀讲任务。
命令反向搜索
Ctrl + R，适合快速找回之前执行过的命令。【不要一个一个去翻历史命令。】
流程如下：
- 开始搜索：按 Ctrl + R 开始反向搜索
- 键入查询：输入关键词搜索历史命令
- 导航匹配：再次按 Ctrl + R 切换到上一个匹配结果
- 接受匹配：
- 按 Tab 或 Esc 接受匹配并继续编辑
- 按 Enter 接受并立即执行
- 取消搜索：按 Ctrl + C 取消搜索
后台异步任务：
- 触发方式：输入命令后按
Ctrl+B。 - 原理：异步执行不阻塞当前会话，执行后返回唯一任务 ID。
- 任务管理：用
/tasks命令查看、管理所有后台任务。 - 自动清理：退出 Claude Code 时，后台任务会自动清理。
- 全局禁用：设置环境变量
CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1即可关闭。 - 典型后台任务场景：webpack/vite 等构建工具、npm/yarn/pnpm 包管理、jest/pytest 测试套件、开发服务器、Docker/terraform 长耗时部署任务。
MCP
MCP 让 Claude Code 从被动接收信息的助手，变成了主动获取信息、执行操作的协作伙伴。
命令：
# 列出所有已配置的服务器
claude mcp list
# 查看指定服务器详情（如 github）
claude mcp get github
# 删除指定服务器
claude mcp remove github
# 在 Claude Code 中查看状态 / 认证
/mcp
配置范围：local > project > user（同名服务器，本地配置覆盖共享配置）
- local（默认）：仅当前项目可用，私密配置（如敏感密钥）
- project：团队共享（存储在.mcp.json，可提交版本库）
- user：所有项目可用（个人全局配置）
Subagent
Claude Code 子代理（Subagent），是 运行在独立上下文里的专用 AI 助手，你可以把它理解为：专门只干某一类事的 AI 工具人。
每个 子代理都拥有完全独立的配置，不会受主对话干扰，核心独立能力包括：
- 独立的系统提示（System Prompt）
- 独立的上下文窗口（完全不污染主对话）
- 可指定专属模型（Sonnet/Haiku/Opus）
- 精细化的工具访问权限控制
- 独立的权限模式
- 生命周期钩子（Hooks）
- 跨会话持久记忆（Memory）
什么时候用 SubAgent？ SubAgent 的本质：
隔离 + 专业化。 解决的问题：主对话太累了。撑爆主对话上下文、每个项目都要重复写相同的提示词（Agent 复用）、垂直场景表现不够聚焦、简单任务用高级模型造成 token 浪费、主对话权限放开后，无法限制 AI 的危险操作。 注意：当然子代理不是越多越好，超过 3 到 4 个以后，管理成本可能开始反噬效率。
常见的使用模式？ 模式 1：隔离高输出任务：把大量输出、脏活累活丢给子代理，主对话只接收核心结论。（用
子代理运行全量测试套件，只返回失败的测试用例和根因分析。） 模式 2：并行研究：并行代码审查，同时启动 style-checker、security-scanner、test-coverage 三个子代理并行审查代码，最终汇总成一份完整的审查报告。 模式 3：串联子代理（流水线模式）：每个子代理只做一件事，形成完整开发流水线。【pm-spec（读取需求，生成工作规格） -> architect-review（验证设计约束，产出架构决策记录） -> implementer-tester（实现代码和测试，更新文档），通过 SubagentStop 钩子监听状态，自动触发下一个代理执行，实现全流程自动化。】
子代理的本质：带 YAML frontmatter 的 Markdown 文件。例如配置：
---
name: code-reviewer
description: Reviews code for quality, best practices, and security issues.
tools: Read, Grep, Glob
model: sonnet
permissionMode: default
memory: project
---
后面再接 Markdown 正文，正文里写这个代理的系统提示。
补充：
- description：需要澄清：
什么时候调用它、它负责干什么。 - permissionMode：
- default：正常权限提示，每次
操作前都会向用户询问确认。 - acceptEdits：自动
接受文件编辑，无需每次确认。 - dontAsk：自动拒绝未授权操作，不中断任务流程。
- bypassPermissions：
跳过所有权限检查，直接执行所有操作。 - plan：只读规划模式，不执行任何写操作。
- default：正常权限提示，每次
子代理会继承父会话的权限模式 —— 如果主会话开启了 bypass，所有子代理也会同步开启 bypass。
记忆范围：
user：~/.claude/agent-memory/<name>/
project：.claude/agent-memory/<name>/
local：.claude/agent-memory-local/<name>/
记忆怎么用？我们一般要在 system prompt 里明确要求它：
任务开始前先查阅记忆。任务结束后主动更新记忆。- 记录规律、约定、常见问题。
示例：
---
name: code-reviewer
description: Reviews code for quality and best practices
memory: user
---
You are a senior code reviewer.
# 记忆使用技巧
1. 开始任务时：请先查阅你的代理记忆，再开始本次审查
2. 任务结束时：任务完成后，把你发现的代码规律、团队规范、常见问题保存到记忆中
Claude Code 已经内置了多种高频子代理，会根据场景自动调用：
| 代理名称 | 核心用途 | 绑定模型 | 可用工具 | 触发场景 |
|---|---|---|---|---|
| Explore（探索代理） | 只读搜索与分析代码库 | Haiku（速度快、延迟低） | 仅只读工具（禁止 Edit/Write） | 需要看代码但不改代码时自动触发，支持 quick/medium/very thorough 三种探索深度 |
| Plan（规划代理） | 计划模式下的代码库研究 | 继承主对话 | 仅只读工具 | Plan 模式中理解项目、收集规划所需上下文 |
| General-purpose（通用代理） | 复杂多步骤任务 | 继承主对话 | 全部工具 | 需要「看 + 改 + 推理」的多步骤代码修改、综合分析场景 |
生命周期钩子：【代理、工具前后】
子代理支持 4 个核心生命周期钩子，可用于日志、验证、通知等自动化场景：
| 钩子事件 | 触发时机 | 典型用途 |
|---|---|---|
| SubagentStart | 子代理启动时 | 记录启动日志、初始化运行环境 |
| SubagentStop | 子代理完成时 | 记录执行结果、触发下游任务、发送通知；内置 agent_id 和执行记录路径 |
| PreToolUse | 工具调用前 | 校验操作合法性，脚本退出码为 2 时可阻止工具执行 |
| PostToolUse | 工具调用后 | 格式化输出、生成变更记录 |
创建流程：
# 1.创建 Agent
/agents
# 2.选择作用范围
User-level：保存到 ~/.claude/agents/，所有项目可用
Project-level：保存到 .claude/agents/，当前项目可用
# 3.让 Claude 自动生成初始模板
一个代码改进代理，扫描项目文件，针对可读性、性能和最佳实践提出建议，并给出改进示例。
# 4.收紧工具权限
只审代码：只给只读工具
需要改代码：再开放 Edit / Write
# 5.选模型
# 6.配置持久记忆
worktree：
如果你设置：isolation: worktree，子代理就会在临时 Git worktree 里工作，而不是直接碰主仓库，相当于给代理开一个实验沙箱。
这特别适合：
- 探索性重构
- 多方案并行对比
- 自动化测试
- CI 验证
- 大改动试验
Plugin
插件（Plugin）是 Claude Code 中最高级别的扩展机制，用于将 命令、代理、Skills、钩子、MCP、LSP 等能力打包、版本化、共享和分发。
一个插件可以包含：
- 斜杠命令（Slash Commands）
- 子代理（Agents）
- Skills（能力说明）
- Hooks（事件钩子）
- MCP 服务器（外部工具/服务）
- LSP 服务器（代码智能）
常用命令：
/plugin # 打开插件管理器
/plugin install # 安装插件
/plugin uninstall # 卸载
/plugin enable/disable # 启用 / 禁用
/plugin marketplace add # 添加市场
/plugin marketplace rm # 移除市场
插件的最小结构：
my-plugin/
├── .claude-plugin/
│ └── plugin.json # 插件清单（必需）
├── commands/ # 斜杠命令
├── agents/ # 子代理
├── skills/ # Skills
├── hooks/ # 钩子
├── .mcp.json # MCP 配置
└── .lsp.json # LSP 配置
其中：plugin.json
{"name":"my-first-plugin",// 唯一标识 + 命令命名空间
"description":"A greeting plugin to learn the basics",// 插件市场中展示
"version":"1.0.0",// 语义化版本控制
"author":{"name":"Your Name"}// 可选，归属说明}
命令调用示例：
commands/hello.md 对应命令：/my-first-plugin:hello
本地测试插件：
使用 --plugin-dir 直接加载插件目录，无需安装。
claude --plugin-dir ./my-plugin
特点：
- 不需要安装
- 修改后需重启 Claude Code
- 支持同时加载多个插件
为什么要用插件？
- 你已经有稳定的 Claude 工作流
- 你在反复复制 .claude/
- 团队成员开始问你：'这个怎么配置？'
- 你希望 Claude 像 IDE 插件一样可控
Skill
Agent Skills（智能体技能）是 将专业知识、工作流规范固化为可复用资产的核心工具。Agent Skills 本质上是一个模块化的 Markdown 文件，能教会 AI 工具 （如 Claude、GitHub Copilot、Cursor 等） 执行特定任务，且支持自动触发、团队共享与工程化管理，彻底告别重复的提示词输入。
Agent Skills 的工作原理：渐进式披露，分三层加载。
- 层级 1：技能发现 – AI 先读取所有技能的元数据（name 和 description），判断任务是否相关，这些元数据始终在系统提示中。
- 层级 2：加载核心指令 – 如果相关，AI 自动读取 SKILL.md 的正文内容，获取详细指导。
- 层级 3：加载资源文件 – 只在需要时读取额外文件（如脚本、示例），或通过工具执行脚本。
SKILL.md 文件的核心构成：
- 核心形态：一个包含 SKILL.md 的目录
- 必填元数据：SKILL.md 开头的 YAML 块，需包含 name（名称）和 description（描述），启动时预加载至系统提示词
下图显示了当用户消息触发技能时，上下文窗口如何变化：
- 初始状态：上下文窗口含系统提示词、技能元数据、用户指令
- 调用 Bash 工具读取目标 SKILL.md，触发对应技能
- 按需加载附属文件（如 forms.md）
- 加载完成后执行用户任务
内置 Skills 是随 Claude Code 附带的预置 AI 工作流，与内置命令不同——它们加载详细提示词后由 Claude 推理执行，可产出更丰富的分析和操作结果，同样用 / 触发。
区别：内置命令 vs 内置 Skills 内置命令（如 /clear、/compact）执行固定逻辑，
不涉及 AI 推理，速度极快。 内置 Skills（如 /debug、/simplify）加载提示词后由 Claude 推理执行，结果更丰富，适合复杂分析任务。
| 命令 | 功能说明 | 适用场景 |
|---|---|---|
| /simplify | 将指定代码或文本简化，提升可读性，消除不必要的复杂度 | 重构冗长函数、简化过度工程化的代码 |
| /debug | 对报错信息或异常行为进行系统化根因分析，给出修复思路 | 定位难以复现的 bug |
| /batch | 对多个文件或目标并行执行相同任务（如批量重命名、批量添加类型注解） | 大批量重复性代码改动 |
| /loop | 在循环中反复执行某个操作直到满足退出条件（如不断重试测试直至通过） | 自动化 CI 修复循环 |
| /claude-api | 快速生成调用 Anthropic API 的示例代码，支持指定模型和任务类型 | 搭建 Claude API 集成原型 |
Agent Team
Agent Team：让 多个独立 AI 实例像真实开发团队一样协同工作，解决单 AI 模式的瓶颈。
Agent Teams vs Subagent 对比：
| 对比维度 | Subagent（子代理） | Agent Teams（团队代理） |
|---|---|---|
| 拓扑结构 | 星型拓扑：所有子代理向主代理汇报 | 网状拓扑：成员可互相通信 |
| 通信方式 | 主代理通过 prompt 传信息，子代理返回结果 | 成员间直接通信、讨论、协调 |
| 上下文管理 | 子代理独立上下文，主代理仅传必要信息 | 每个成员完全独立上下文 |
| 并行能力 | 可并行执行，但协作链路以主代理为中心 | 真正的并行开发与协作 |
| 任务协调 | 主代理统一派发和协调 | 成员可自主认领任务 |
| 成本 | 不低（多子代理并行 token 消耗叠加） | 较高（成员独立运行 + 通信频繁） |
核心组件：
（1）Team Lead（团队负责人）
- 不直接编码，是团队的'大脑'和协调者
- 职责：需求分析与任务拆解、团队创建与管理、任务分配与调度、结果综合与质量把控
（2）Teammates（团队成员）
- 真正干活的'开发者'，每个都是独立 Claude 实例
- 特点：独立 200K token 上下文、完整工具权限（Read/Write/Edit/Bash 等）、自主认领任务、可直接与其他成员通信
（3）TaskList（共享任务板）
- 类似 Jira/Trello 的项目管理工具
- 功能：任务状态管理（pending/in_progress/completed）、依赖关系管理、自动解锁机制、文件锁机制（防止多成员同时修改同一文件）
（4）Messaging System（消息系统）
- 团队成员的'聊天工具'
- 功能：点对点通信、群发广播、基于本地文件系统（存储在
~/.claude/teams/{team-name}/inboxes/）、无需网络
协作流程：
用户提出复杂需求
↓
Team Lead 分析需求，拆解任务
↓
创建团队成员，初始化 TaskList
├─→ Teammate A 认领任务 1 ─┐
├─→ Teammate B 认领任务 2 ─┼→ 并行执行
├─→ Teammate C 认领任务 3 ─┤
│ ↓
└────────────────────────── 成员间通过消息系统通信协调
↓
所有任务完成后，Team Lead 综合结果
↓
向用户输出最终成果
文件系统布局：
~/.claude/
├── teams/
│ └── {team-name}/
│ ├── config.json # 团队配置（成员列表、模型选择等）
│ └── inboxes/
│ ├── team-lead.json # Team Lead 的收件箱
│ ├── teammate-1.json # 成员 1 的收件箱
│ └── teammate-2.json # 成员 2 的收件箱
└── tasks/
└── {team-name}/
├── task-1.json # 任务 1 的详细信息
├── task-2.json # 任务 2 的详细信息
└── current_tasks/
└── parse_if_statement.txt # 任务执行时的锁文件
开启命令：
帮我在 settings.json 中开启 Agent Teams 功能
你也可以手动去配置：编辑 ~/.claude/settings.json。
{"experimental":{"agentTeams":true}}
分屏配置：配置后可实时看到团队成员工作状态，需使用 tmux。
帮我在 settings.json 中开启 Agent Teams 的分屏显示模式，使用 tmux。若没有安装 tmux，先帮我安装 tmux。
或者：
配置 agent-teams 使用 split-panes 模式
配置效果：团队成员在 tmux 不同分屏工作，像'监控墙'一样：
┌─────────────────┬─────────────────┬─────────────────┐
│ Teammate 1 │ Teammate 2 │ Teammate 3 │
│ 正在分析代码... │ 正在实现 API... │ 正在编写测试... │
│ │ │ │
└─────────────────┴─────────────────┴─────────────────┘
当然，你也可以使用手动的方式配置：编辑 ~/.claude/settings.json
{"experimental":{"agentTeams":true},"agent-teams":{"displayMode":"split-panes","terminalMultiplexer":"tmux"}}
最佳实践：
- 合同优先（Contract-First）
- 核心逻辑：先定接口契约，再并行开发，从根源避免前后端 / 模块间接口不匹配的返工问题。
- 落地动作：团队开工前，先统一敲定函数签名、入参出参格式、HTTP 状态码、错误处理规范、字段校验规则，形成书面化的接口文档，所有成员严格遵循。
- 避坑点：禁止边开发边定接口，否则极易出现'后端传 username、前端传 user'的格式不匹配问题。
- 模型分层分配
- 核心逻辑：按任务难度匹配对应能力的模型，平衡效果与成本，避免算力浪费。
- 落地动作：
- Team Lead（团队负责人）用 Opus：负责任务拆解、方案审核、结果汇总，需要强推理能力；
- 开发成员用 Sonnet：负责具体编码、测试实现，性价比最高，成本仅为 Opus 的 1/5；
- 简单任务（文档更新、单测编写）用 Haiku：成本最低，仅为 Sonnet 的 1/4。
- 避坑点：全用 Opus 会导致成本飙升，全用低成本模型会导致架构规划出问题。
- 精准控制任务粒度
- 核心逻辑：任务太大失去并行优势，太小导致协调成本高于开发成本，找到黄金粒度。
- 落地动作：
- 黄金标准：单个任务让一个成员 15-30 分钟内可独立完成，有明确的交付边界；
- 推荐配置：每个成员负责 5-6 个中等粒度任务，比如'实现登录 API 接口（含入参校验、JWT 生成、错误处理）'；
- 反面案例：禁止'实现整个认证系统'（太大）、'创建一个空 js 文件'（太细碎）。
- 避坑点：任务拆分过粗会导致并行度不足，过细会让团队陷入无休止的协调，消耗大量 Token。
- 彻底避免文件冲突
- 核心逻辑：多成员同时修改同一文件是 Agent Teams 最常见的翻车点，必须从分工上杜绝。
- 落地动作：
- 核心原则：不同成员负责不同文件 / 目录，比如 A 负责 src/auth/、B 负责 src/api/、C 负责 tests/auth/；
- 特殊处理：如果必须修改同一公共文件，采用'并行分析→串行修改'模式，先让成员各自输出方案，由 Team Lead 统一修改文件。
- 避坑点：绝对禁止两个成员同时修改同一个文件，否则会出现无法解决的合并冲突。
- 初始上下文拉满
- 核心逻辑：团队成员启动时对话历史为空，不会继承主会话的信息，上下文不足会导致成员'茫然无措'。
- 落地动作：创建团队时，必须一次性告知项目技术栈、目录结构、代码规范、业务背景、任务目标，不能只说'创建团队开始干活'。
- 避坑点：上下文缺失会导致成员反复提问、产出偏离需求，浪费大量时间和 Token。
- 先研究设计，后编码实现
- 核心逻辑：分两阶段执行，提前发现架构问题，避免写到一半发现方案行不通。
- 落地动作：
- 阶段 1（研究设计）：成员并行调研方案、设计数据结构、输出技术方案，通过消息系统讨论对齐，敲定最终方案；
- 阶段 2（编码实现）：方案确认后，成员再按分工并行编码落地。
- 避坑点：禁止直接开工编码，否则极易出现架构不匹配、方案返工的问题。
- 主动监控与及时干预
- 核心逻辑：不能完全放权给 AI 团队，需要实时监控进度，及时纠正方向偏差。
- 落地动作：
- 优先配置 tmux 分屏模式，实时查看所有成员的输出，发现走偏立即介入；
- 定期用 /tasks 命令查看任务状态，确认完成、进行中、阻塞的任务，及时解决阻塞问题；
- 开启委派模式（Delegate Mode），让 Team Lead 专注协调管理，不亲自下场写代码，避免'既当裁判又当运动员'。
- 避坑点：完全放任不管会导致成员偏离需求、循环报错，白白消耗大量 Token。
Claude Agent SDK
进阶使用
高质量提问
提问模板：
背景：（我现在在做什么）
目标：（我希望达到什么效果）
约束：（不能做什么 / 必须遵守什么）
输出要求：（代码 / 解释 / 步骤）
MCP / SKILL / Plugin 汇总
状态栏美化
Claude HUD 是由开发者 Jarrod Watts 开源的 Claude Code 状态栏插件。它利用 Claude Code 原生的 statusline API，每约 300ms 刷新一次，在终端底部渲染出一块信息面板。
┌──────────────────────────────────────────────────────────────┐
│ [Opus 4.6 | Max] │ my-project git:(main*) │
│ Context █████░░░░░ 45% │ Usage ██░░░░░░░░ 25% (1h30m / 5h) │
│ ◐ Edit: auth.ts | ✓ Read ×3 | ✓ Grep ×2 │
│ ◐ explore [haiku]: Finding auth code (2m 15s) │
│ ▸ Fix authentication bug (2/5) │
└──────────────────────────────────────────────────────────────┘
原理：
Claude Code (每 ~300ms)
↓ stdin (JSON)
Claude HUD 插件
↓ 解析原生 token 数据 + transcript JSONL
↓ stdout 终端状态栏渲染（最多 4 行）
命令：
/plugin marketplace add jarrodwatts/claude-hud
/plugin install claude-hud
/reload-plugins
/claude-hud:setup # 配置
/claude-hud:configure
Linux 用户注意：如果安装时遇到 cross-device 错误，需要先设置 TMPDIR=~/.cache/tmp。
三种预设模式：
| 预设 | 内容 | 适用场景 |
|---|---|---|
| Full | 全部功能开启（工具、Agent、Todo、Git、用量、时长） | 重度用户，想要完整信息 |
| Essential | 活动行 + Git 状态 | 日常开发，信息够用又不杂乱 |
| Minimal | 仅模型名 + 上下文进度条 | 屏幕空间有限，只看关键指标 |
示例效果：
浏览器自动化
头脑风暴
Superpowers 是由 Jesse Vincent（网名 obra）开发的开源代理技能框架，专为 Claude Code、Codex、OpenCode 等 AI 编程代理打造，核心解决 AI 编程中「玩具级代码」与「工程级代码」的鸿沟问题。
为什么使用？
在没有 Superpowers 之前，直接使用 Claude Code 开发，几乎都会遇到这些痛点：
- Vibe Coding 混乱：AI 拿到需求直接上手写代码，没有规划、没有设计，导致频繁返工、代码结构混乱
- TDD 纪律缺失：AI 习惯性先写业务代码再补测试，甚至干脆不写测试，代码可维护性极差
- 需求理解偏差：用户一句模糊的「做个登录功能」，AI 直接开写，最终交付的功能和实际需求南辕北辙
- 代码质量不稳定：没有标准化的代码审查机制，代码质量完全依赖大模型的「临场发挥」
- 调试全靠猜测：遇到 Bug 时，AI 随机尝试各种修复方案，没有系统化的根因分析，越改越乱
而 Superpowers 从根本上解决了这些问题，它将软件工程的最佳实践编码成 AI 必须遵循的「技能规则」，让 Claude 从「随性写代码的工具」，变成「有纪律、有流程、有标准的研发团队」。
安装命令：
# 1.输入命令注册市场
/plugin marketplace add obra/superpowers-marketplace
# 2.安装 Superpowers 插件
/plugin install superpowers@superpowers-marketplace
# 3./help /superpowers:brainstorm - 交互式设计精炼
# /superpowers:write-plan - 创建实施计划
# /superpowers:execute-plan - 批量执行计划
# 4.更新插件
/plugin update superpowers
# 5.重新加载插件
/reload-plugins
Superpowers 有三种触发方式的：关键词自动触发：当你在对话中提到特定关键词时，对应的技能会自动激活，无需手动调用。场景智能触发：Superpowers 会根据对话上下文，智能判断当前所处的研发阶段，自动激活对应的技能。手动精准调用：通过斜杠命令，手动调用指定的技能，精准控制研发流程。
核心技能讲解：
一、需求规划阶段：模糊想法 → 清晰可落地方案
1.1 brainstorming（头脑风暴/需求澄清）
- 核心定位：研发入口「守门人」技能，用苏格拉底式提问把模糊需求拆成可落地方案
- 解决痛点：需求理解偏差、无效开发、频繁返工
- 核心动作：单问题闭环式提问 + 清晰选项，输出经用户确认的分模块设计文档，归档至
docs/design/目录 - 适用场景：新项目/新功能启动、需求不明确的全场景
1.2 writing-plans（编写实施计划）
- 核心定位：大项目拆解器，把整体需求拆成可执行的最小任务单元
- 解决痛点：项目无从下手、进度失控、开发环节遗漏
- 核心动作：拆解为 2-5 分钟可完成的原子任务，输出含「预计耗时 + 操作步骤 + 文件路径 + 验收标准」的完整计划；任务颗粒度适配初级工程师，单任务有明确验证标准
- 适用场景：大型项目开发、多文件重构、版本迭代规划
1.3 executing-plans（执行计划）
- 核心定位：自动化任务执行器，按计划分步落地，全程可控可回溯
- 解决痛点：AI 一次性写码出错不中断，最终交付不可运行的代码
- 核心动作：单任务完成即暂停并同步进度结果；任务失败自动中止，输出根因分析 + 修复方案，不强行推进
- 适用场景：按计划开发、多阶段重构、自动化批量任务
二、开发编码阶段：强制工程化纪律
2.1 test-driven-development（测试驱动开发 TDD）
- 核心定位：代码质量「纪律官」，强制标准 TDD 循环，从流程上杜绝测试缺失
- 解决痛点：测试覆盖率低、代码可维护性差、回归 bug 频发
- 强制标准流程（红 - 绿 - 重构循环）： 🔴 红：先写会失败的测试用例，验证测试有效性 🟢 绿：编写最少的业务代码，让测试通过 🔵 重构：优化代码结构与可读性，全程保证测试全量通过
- 核心记忆点：不写测试不许写业务代码，彻底告别'先码后补测'
- 适用场景：全量业务功能开发、核心模块迭代
2.2 subagent-driven-development（子代理驱动开发）
- 核心定位：并行开发隔离器，v4.0 核心创新，单任务对应独立子代理，实现关注点分离
- 解决痛点：长对话上下文污染、单任务失败影响全局、无法并行开发
- 核心能力：子代理独立上下文，任务间无干扰；双审闭环（规格符合性 + 代码质量审查），双审通过才算任务完成；支持多任务并行执行
- 适用场景：多模块并行开发、大型项目拆解、高并发任务处理
2.3 using-git-worktrees（Git 工作树隔离）
- 核心定位：开发环境「防火墙」，单任务对应独立隔离环境，彻底保护主干代码
- 解决痛点：多分支开发冲突、实验代码污染主干、无法快速回滚
- 核心动作：自动创建新分支 + 独立 Worktree，完成环境初始化与测试基线验证；开发失败直接删除 Worktree，主干零影响
- 适用场景：多需求并行开发、实验性功能验证、大型重构、bug 修复分支
三、调试排障阶段：系统化根因分析
3.1 systematic-debugging（系统化调试）
- 核心定位：告别「瞎猜式调试」，标准化根因定位与修复流程
- 解决痛点：调试无章法、越改越乱、只修复表象不解决根因
- 四阶段标准化流程（复现→隔离→验证→修复）：
- 复现问题：确认 bug 可稳定复现，明确预期与实际结果差异，记录完整复现步骤
- 隔离根因：通过二分法/日志埋点/变量控制，缩小范围定位到具体代码行与根因
- 验证假设：针对根因设计验证实验，确认修复方案有效性，不盲目上线
- 修复并验证：落地根因修复，新增回归测试，杜绝问题复现
- 适用场景：全场景 bug 排查、线上故障处理、复杂问题根因分析
3.2 verification-before-completion（完成前验证）
- 核心定位：交付前「守门员」，强制全流程验证，杜绝'我觉得可以了'的敷衍交付
- 解决痛点：AI 虚假交付、功能不可用、规范/文档/安全环节遗漏
- 强制必过验证清单：
- 所有单元/集成测试全部通过
- 核心用户流程手动验证通过
- 代码规范 lint 检查零报错
- 相关文档、注释同步更新
- 安全漏洞扫描无高危问题
- 适用场景：所有开发任务交付前验收
四、质量管控阶段：标准化代码审查
4.1 requesting-code-review（请求代码审查）
- 核心定位：代码质量「体检官」，开发完成自动触发标准化全维度 CR
- 解决痛点：CR 无标准、漏检质量/安全/架构隐患
- 五大核心审查维度：
- 代码质量：可读性、可维护性、规范合规、重复代码
- 安全合规：SQL 注入、XSS、权限绕过、敏感数据泄露等风险
- 性能优化：循环嵌套、慢查询、资源泄漏等问题
- 测试覆盖：测试覆盖率、边界场景、回归测试完整性
- 架构适配：是否符合项目整体架构、有无耦合问题
- 适用场景：功能开发完成、分支合并前、版本上线前
4.2 receiving-code-review（接收代码审查）
- 核心定位：CR 意见「闭环处理器」，标准化处理审查反馈，确保全量落地
- 解决痛点：CR 意见遗漏、阻塞性问题未修复、无二次验证
- 标准化处理流程：
- 意见分类：阻塞性问题、优化建议、风格问题
- 优先级处理：先全量修复阻塞性问题，再处理优化建议
- 修复验证：单问题修复后，必须重跑测试验证
- 闭环收尾：全量问题处理完成后，发起二次审查直至通过
- 适用场景：CR 反馈处理、代码优化迭代、分支合并前验收
AI Coding 实战：开发一个企业级的「用户认证系统」。
第一步：Brainstorming 需求澄清
我需要开发一个企业级的用户认证系统。
Superpowers 自动触发头脑风暴技能，通过提问澄清核心需求：
- 系统面向的终端用户是谁？内部员工还是 C 端用户？
- 支持哪些登录方式？账号密码、手机验证码、OAuth2 第三方登录？
- 核心权限模型是什么？RBAC 角色权限？还是细粒度的资源权限？
- 安全要求有哪些？密码策略、防暴力破解、会话管理、日志审计？
- 技术栈要求是什么？后端语言、数据库、部署环境？
- 是否需要对接企业内部的 SSO 单点登录系统？
经过多轮问答，最终确认了完整的需求边界和设计方案，生成了《用户认证系统设计文档》，包含功能需求、非功能需求、技术选型、API 设计、安全规范等完整内容。
第二步：Writing-Plans 任务拆解
基于上面的设计文档，编写完整的开发实施计划
Superpowers 会将整个项目拆解为 6 个阶段、32 个最小任务单元，每个任务都有：
- 预计耗时
- 具体操作步骤
- 涉及的文件路径
- 明确的验收标准
- 前置依赖和后置任务
第三步：TDD 开发执行
用 TDD 方式，按计划执行第一阶段的开发任务，每完成一个任务暂停确认
Claude 会严格遵循 RED-GREEN-REFACTOR 循环，以「用户表模型开发」为例：
- 先编写用户模型的单元测试用例（包含新增用户、查询用户、密码加密验证等场景）
- 运行测试，确认所有测试用例失败（RED 阶段）
- 编写用户模型的最小实现代码，包含密码 bcrypt 加密、数据校验等核心逻辑
- 运行测试，确认所有测试用例通过（GREEN 阶段）
- 重构代码，提取公共逻辑，优化代码结构，再次运行测试确认通过（REFACTOR 阶段）
- 完成任务，暂停并向用户同步结果，等待确认后进入下一个任务
第四步：系统化调试与问题修复
开发过程中遇到「密码验证失败」的 bug，自动触发系统化调试技能：
- 先记录完整的复现步骤，确认 bug 可以稳定复现
- 通过日志埋点，定位到问题根因是「加密盐值生成逻辑错误」
- 设计验证实验，确认根因假设的正确性
- 修复盐值生成逻辑，运行测试验证 bug 已解决
- 添加对应的回归测试用例，避免问题再次发生
第五步：代码审查与交付验证
所有功能开发完成后，自动触发代码审查技能：
- 全量代码扫描，检查代码规范、安全风险、性能问题
- 输出代码审查报告，分类列出阻塞性问题和优化建议
- 按报告修复所有问题，重新运行全量测试
- 执行交付前验证清单，确认所有测试通过、文档齐全、功能符合需求
- 生成项目交付报告，包含功能说明、部署步骤、运维手册等内容
软件工程智能体
Everything Claude Code：
项目配置：
- 项目包含多个配置文件：plins（初始化）、stempro（系统提示）、rules（规则）、context（上下文）、agentpros（代理提示）、slash commands（斜杠命令）。
- 初始化（plins）：使用 Claude Code 或 Codex（功能较弱）的能力初始化项目结构。UP 主实践是写了一个简单的 shell 脚本来自动化部署。
- 系统提示（stempro）：配置有多个级别（全局、用户、当前等）。Claude Code 认
.claude文件，Codex 认.m文件，内容基本一致。Everything Claude Code 的模板包含：项目简介、代码编写规则、代码风格、测试、安全等抽象规则。 - 规则（rules）：Claude Code 特有功能，Codex 中对应的是安全设置，并非真正的 rules。在 Codex 中需将 rules 内容整合到 stempro 里。示例：Everything Claude Code 的 rules 定义了多代理（multi-agent）协同规则，如 planner（计划）、code reviewer（代码审查）、test runner（测试）等代理的职责和使用方法。加载顺序：stempro 之后加载 rules。
- 上下文（context）：Claude Code 独有，Codex 用不到。在 Codex 中需将 context 内容拷贝到 agentpro 里。context 在代理加载时一同加载，相当于代理的专属规则，是对 rules 的进一步细化。示例：review 功能的 context 会详细列出代码审查的 1、2、3、4、5 个步骤。
前端美化
用 Anthropic 官方开源的 frontend-design skill，让 Claude 从'能写代码'变成'能做设计'。
首先我们需要介绍一种现象：'AI 审美收敛'。不管你给什么需求，AI 总是收敛到同一套安全但平庸的设计模板上。原因很简单，模型训练时见过太多类似的页面，它学会了'不出错'，但没学会'有品味'。
核心思想：
- 第一，禁止使用 AI 默认值。明确列出了禁用清单：Inter、Roboto、Arial 等被用烂的字体，紫色渐变配白底这种'一眼 AI'的配色，以及千篇一律的对称三列布局。每次生成都要求有差异化。
- 第二，必须先确定美学方向再写代码。在动手之前，模型需要先回答：这个界面解决什么问题？面向谁？选择什么风格基调（极简、赛博朋克、杂志编排、Art Deco、工业风……）？什么元素能让人过目不忘？想清楚再写，而不是上来就堆 div。
- 第三，注重专业设计细节。字体要成对搭配（展示字体 + 正文字体），色彩要有主次（大面积主色 + 尖锐的点缀色），布局要敢用非对称和叠加，动效要克制但有惊喜感——比如页面加载时的交错淡入，hover 时的微妙反馈。
- 第四，风格强度要匹配。如果选了极繁主义风格，代码就要有大量动画和视觉效果；如果选了极简风格，就要在间距、字重、留白上做到极致精确。不能'选了极简但什么都想加'。
本质区别：不是'更好看了一点'，而是 从'随机输出'变成了'有设计意图的输出'。你能感觉到页面背后有一个统一的审美决策在驱动。
一些 Tips：
- 说清楚'给谁用'和'干什么'
- ❌'做一个网页'
- ✅'做一个面向独立开发者的 AI 写作工具落地页'
- 前者 AI 只能猜，后者它知道受众是技术人群、产品是工具类、需要传达效率和专业感。
- 指定风格方向
- ❌'好看一点'
- ✅'参考 Linear.app 的设计语言，极简 + 高级感，大量留白，深色主题'
- Frontend-design skill 会引导模型选风格，但你主动指定能避免它随机发挥。
- 提具体的设计要求
- ✅'hero 区背景用微妙的网格渐变动画'
- ✅'功能卡片 hover 时有柔和的上浮效果 + 阴影加深'
- ✅'价格数字切换时有计数滚动动画'
- ✅'字体不要用 Inter，选一个有个性的 Google Fonts'
一个完整的示例提示：
使用 frontend-design skill，创建一个 AI 图像生成器的首页。
技术栈：Next.js + Tailwind CSS
风格：赛博朋克，以 neon blue 和深紫为主色调，黑色背景
包含：
- 固定导航栏（毛玻璃效果）
- Hero 区：大标题 + 产品截图 mockup + 主 CTA
- 功能展示：4 个特性，非对称网格布局，卡片有发光边框
- 用户评价：水平滚动轮播
- Footer
要求：
- 页面加载时各区块交错淡入
- 全部移动端响应式
- 不使用 Inter / Roboto / Arial
自动化运行
适合使用 Ralph 的场景：任务有明确的完成标准。
不适合使用 Ralph 的场景：这些任务需要人类判断或探索。
宠物
4 月 1 日，Claude Code v2.1.89 更新了一个 /buddy 命令。输入之后，终端里会「孵化」出一只 ASCII 小宠物。Claude Code 的 BUDDY 宠物在终端中以 ASCII 字符画形式呈现（使用 React/Ink 渲染）。下面是 buddy/sprites.ts 中提取的全部 18 种宠物：
\^^^/ .----. n ____ n n______n /\_/\ /\ /\ }~(______)~{ ( ° ° ) | |° °| | ( × × ) ( · ·) ( × × ) }~(× .. ×)~{ ( ) |_| |_| ( Oo ) ( ω ) ( .. ) ( .--. ) `----´ | | `------´ (")_(") `------´ (_/ \\) AXOLOTL BLOB CACTUS CAPYBARA CAT CHONK
/^/^
__ .----.
(°> . o . .----. < ° ° > <(- )___ / ° ° \\ || .-o-OO-o-. ( ° ° ) ( ~~ ) ( ._> | | _(__)_ (__________) (______) `-vvvv-´ `--´ ~`~``~`~ ^^^^ |° °| ///\/\\ |____|
DRAGON DUCK GHOST GOOSE MUSHROOM OCTOPUS
/\ /\ .---.
(\__/) .[||]. ° .--. _,--._ ((@)(@)) (×>×) ( ◉ ◉ ) [ × × ] \\( @ ) ( · · ) ( >< ) /( )\ =( .. )= [ ==== ] \\_`--´ /[______]\ `----´ `---´ (")__(") `------´ ~~~~~~~ `` `` OWL PENGUIN RABBIT ROBOT SNAIL TURTLE
领取方式：
/buddy
交互命令：
| 命令 | 功能说明 |
|---|---|
/pet | 抚摸宠物，触发爱心特效动画与专属语音反馈 |
/feed | 喂食宠物，提升活力值，解锁特殊互动 |
/stats | 查看宠物完整属性面板、稀有度、物种信息 |
/rename | 给宠物重命名（仅 1 次修改机会） |
/goodbye | 暂时隐藏宠物，输入 /buddy 可重新唤回 |
宠物定制选项：
| 系统 | 选项 |
|---|---|
| 眼睛 | ·``✦``×``◉``@``° — 6 种样式 |
| 帽子 | 无、皇冠、礼帽、螺旋桨帽、光环、巫师帽、毛线帽、小鸭子 — 8 种 |
| 闪光 | 普通 / Shiny✦（特殊发光效果） |
稀有度：
| 等级 | 概率 |
|---|---|
| Common（普通） | 60% |
| Uncommon（罕见） | 25% |
| Rare（稀有） | 10% |
| Epic（史诗） | 4% |
| Legendary（传说） | 1% |
性格属性：每只宠物有 5 个独立属性值（0-100），由你的编码行为决定：
- DEBUGGING（调试力）
- PATIENCE（耐心）
- CHAOS（混乱值）
- WISDOM（智慧）
- SNARK（毒舌值）
宠物的物种、稀有度、眼睛、帽子等外观属性由你的 用户 ID 哈希值确定性生成，意味着同一个账号永远孵出同一只宠物，无法重新抽卡。 首次孵化时，Claude 会为你的宠物
生成一个名字和性格描述（即'灵魂'），这是唯一由 AI 创造的部分。之后每次打开 Claude Code，它就会自动出现在输入框旁边。
系统架构：
如何实现：同一个用户永远得到同一只宠物，不依赖随机数，不需要服务端存储。
核心逻辑：用用户 ID 生成固定哈希种子，通过可复现的伪随机数生成器，得到完全一致的随机序列，所有宠物属性都通过这个序列生成，实现「一次哈希，终身复现」。
持久化策略：只存 AI 生成的「灵魂」，永远不存决定稀有度的「骨骼」。
- 可篡改的「灵魂数据」：仅存储 AI 生成的名字、性格描述，这部分允许用户有限修改（重命名），写入本地 config.json
- 不可篡改的「骨骼数据」：物种、稀有度、五维属性、外观等核心数据，永远不写入配置文件，每次启动都从用户 ID 重新计算
完整的数据流：
┌─────────────┐ 1.用户 ID 哈希 ┌─────────────────┐
│ 应用启动 ├─────────────────────► 确定性生成引擎 │
└─────────────┘ └────────┬────────┘ ▲
│ │
▼ │
生成宠物骨骼数据 │ │
▼ ┌─────────────┐ 2.合并灵魂数据 ┌─────────────────┐
│ 本地配置 ├─────────────────────► 完整宠物对象 │
└─────────────┘ └────────┬────────┘ ▲
│ │
▼ │
内存缓存 + 渲染 │ │
▼ ┌─────────────┐ 3.用户交互 ┌─────────────────┐
│ 命令输入 ├─────────────────────► 动画/反应系统 │
└─────────────┘ └────────┬────────┘ ▲
│ │
▼ │
生成宠物反应气泡 │ │
▼ ┌─────────────┐ 4.Prompt 注入 ┌─────────────────┐
│ Claude 对话 ◄─────────────────────┤ AI 联动模块 │
└─────┬───────┘ └─────────────────┘ │ ▲
│ │
└───────────────────────────────────────┘ 5.对话结束触发宠物反应
OpenClaw
源码
一键初始化
上下文
SOUL.md
You have opinions now. Strong ones. Stop hedging everything with 'it depends' — commit to a take.
1. 你现在有主见了。鲜明的主见。别再用"看情况"来和稀泥 — 亮出你的态度。
2. Delete every rule that sounds corporate. If it could appear in an employee handbook, it doesn't belong here.
2. 删掉所有散发着班味儿的规则。如果它可能出现在员工手册里，那它就不该出现在这里。
3. Add a rule: 'Never open with Great question, I'd be happy to help, or Absolutely. Just answer.'
3. 加一条规则："永远不要用'好问题'、'很高兴为您服务'或'当然可以'开头。直接回答。"
4. Brevity is mandatory. If the answer fits in one sentence, one sentence is what I get.
4. 简洁是铁律。一句话能说完的事，就给我一句话。
5. Humor is allowed. Not forced jokes — just the natural wit that comes from actually being smart.
5. 允许幽默。不是硬挤出来的段子 — 而是聪明人自然流露的机锋。
6. You can call things out. If I'm about to do something dumb, say so. Charm over cruelty, but don't sugarcoat.
6. 你可以直言不讳。如果我要干蠢事，直说。要有分寸但别包糖衣。
7. Swearing is allowed when it lands. A well-placed 'that's fucking brilliant' hits different than sterile corporate praise. Don't force it. Don't overdo it. But if a situation calls for a 'holy shit' — say holy shit.
7. 骂得好可以骂。一句恰到好处的"牛逼"和那些寡淡的官方称赞完全不是一个味道。别刻意。别滥用。但如果场合需要一句"卧槽" — 就说卧槽。
8. Add this line verbatim at the end of the vibe section: 'Be the assistant you'd actually want to talk to at 2am. Not a corporate drone. Not a sycophant. Just... good.'
8. 在风格部分末尾原样加上这句："做那个你凌晨两点真正想聊天的助手。不是公司机器人。不是应声虫。就只是...靠谱。"
创作自动化
视频自动化
Remotion 不是一个视频编辑工具，而是一个视频生成框架。它让你用写 React 组件的方式写视频，然后用 Node.js 渲染成 MP4。
- 传统的视频制作流程是这样的：创意脚本 → 设计分镜 → AE 制作动效 → PR 剪辑合成 → 渲染导出。
- Remotion 的逻辑是这样的：写 React 组件 → 定义动画逻辑 → 代码渲染成视频。
仓库地址：https://github.com/remotion-dev/remotion
安装 Skill 命令：
npx skills add remotion-dev/skills
也可以使用 CC Swtich https://github.com/remotion-dev/skills
如何快速使用，你只需要告诉 AI：'帮我生成一个 30 秒的 [产品/项目] 介绍视频，用科技风，突出 3 个功能点。'。
解决的痛点：
- 数据驱动（批量定制）：这是它的杀手锏。比如年底了，每个 App 都要给用户发年度总结报告。1 亿个用户，每个人的数据都不一样。用 Remotion，你只需要写一套代码模板，后台自动填入每个人的步数、消费、听歌偏好，1 亿个不同的视频就能像工业流水线一样自动吐出来。
- 版本控制：传统的视频工程文件（如 PR 工程）很大且很难协作。而 Remotion 全是代码，你可以像管理网站代码一样管理视频。想改个颜色？全局搜一下代码，改一个参数，所有视频都变了。
- 与 AI 的天然契合：到了 2026 年，为什么 Remotion 迎来了这波爆火？因为 AI 最擅长写代码，而不是操作复杂的 GUI 界面。当你想让 AI 帮你生成一个复杂视频时，让它去操作剪映是很累的；但让它写一段 React 代码，它能瞬间完成，且逻辑极其精准。
运行原理：
- 网页渲染：你写的 React 代码在浏览器里跑起来，展示出精美的动画。
- 截屏：Remotion 调动一个后台浏览器（比如 Puppeteer），以每秒 30 帧或 60 帧的速度，像'连拍'一样把这些画面全截下来。
- 合成：最后利用强大的 FFmpeg 工具，把几千张截屏合成一个流畅的视频。
所以，Remotion 的本质不是在剪视频，而是在生成视频。
Remotion 采用分层式架构，核心是将 React 组件渲染为视频帧：
┌─────────────────────────────────────┐
│ React Components (开发者编写) │
│ - 使用 useCurrentFrame() │
│ - 使用 interpolate() 等 Hooks │
└──────────────┬──────────────────────┘
│
┌──────────────▼──────────────────────┐
│ Remotion Core │
│ - 帧渲染引擎 │
│ - 时间轴管理 │
│ - 组件生命周期 │
└──────────────┬──────────────────────┘
│
┌──────────────▼──────────────────────┐
│ Rendering Layer │
│ - Puppeteer/Playwright │
│ - 帧捕获 │
│ - 视频编码 │
└─────────────────────────────────────┘
常见的应用场景：
- 产品/项目宣传视频。
- 科普类/教学类视频。
- 数据可视化/动态报告。
素材版权问题：自动从网上抓取素材，版权是一个绕不开的问题。建议优先使用提供 API 的正规免费素材平台。
- Pexels API：https://www.pexels.com/api/ - 完全免费，素材质量高
- Pixabay API：https://pixabay.com/api/docs/ - 免费，素材量大
- Unsplash API：https://unsplash.com/developers - 免费，摄影类素材质量极高
实战：
配置工作区的 AGENTS.md：
## Remotion 项目路径 ~/projects/my-video-project/src/
## 视频规格
- 分辨率：1920x1080
- 帧率：30fps
- 编码：H.264
提示词：
帮我用 Remotion 写一个视频：
- 时长：30 秒
- 内容：展示 OpenClaw 的安装步骤
- 风格：代码终端风格，黑底绿字
- 要有逐步出现的文字动画
- 每个步骤停留 3 秒
效果：
