工具 on 你怂你mua

Codex vs Claude Code：AI 编程助手实践对比

Sun, 10 May 2026 00:00:00 +0800

引言

AI 编程助手已经从“代码补全”走到了“能读项目、改文件、跑命令、提 PR”的 Agent 阶段。

目前开发者讨论最多的两个工具，一个是 OpenAI 的 Codex，一个是 Anthropic 的 Claude Code。

它们都能帮你写代码，但气质并不一样：

1
2

Codex 更像一个和 ChatGPT 深度绑定的工程代理。
Claude Code 更像一个强终端原生的代码协作助手。

这篇文章不做简单的“谁更强”排名，而是从实际开发角度拆开看：

产品定位
使用入口
代码上下文
工具和权限
MCP 与扩展生态
自动化能力
适用场景
选型建议

先说结论：如果你已经重度使用 ChatGPT 和 OpenAI 生态，Codex 的统一体验更顺；如果你重度依赖终端、MCP、本地工作流和长时间代码协作，Claude Code 仍然非常有竞争力。

两者分别是什么

Codex

Codex 是 OpenAI 面向软件开发的 coding agent。

它可以在本地 CLI、IDE、Web 或 ChatGPT 环境中帮助开发者：

阅读代码
修改文件
运行命令
修复 bug
编写测试
解释项目
进行代码审查
处理 GitHub 任务

Codex 的核心优势在于它和 OpenAI/ChatGPT 生态结合很深。你可以把它理解成：

`1`	`ChatGPT 生态里的工程执行层。`

Claude Code

Claude Code 是 Anthropic 推出的 agentic coding tool，主要围绕终端和开发环境展开。

它能在项目目录里理解代码、编辑文件、运行命令、使用 MCP Server、处理 Git 工作流，并支持可脚本化的自动化任务。

你可以把它理解成：

`1`	`一个住在终端里的 Claude 工程搭档。`

Claude Code 的特点是终端体验强、MCP 生态成熟、项目内协作方式自然。

快速对比

维度	Codex	Claude Code
产品归属	OpenAI	Anthropic
核心形态	本地 CLI + IDE + Web/云端任务	终端 + IDE + Desktop/Web
生态绑定	ChatGPT / OpenAI 生态	Claude / Anthropic 生态
项目指令	AGENTS.md	CLAUDE.md
工具扩展	本地命令、GitHub、MCP 等	本地命令、MCP、Hooks、Skills 等
远程任务	支持云端并行任务和 PR 工作流	支持自动化、远程/后台任务能力
强项	统一账号体验、云端任务、ChatGPT 联动	终端原生、MCP 成熟、长流程协作
典型用户	ChatGPT 深度用户、希望统一在 OpenAI 生态完成开发	终端重度用户、喜欢可控本地工作流的开发者

这个表只能给第一印象。真正影响体验的，是下面这些细节。

使用入口

Codex 的入口

Codex 的入口比较多：

ChatGPT
Codex CLI
IDE 扩展
Web / cloud tasks
GitHub 集成

这意味着你可以在 ChatGPT 里讨论需求，然后把任务交给 Codex；也可以在本地终端里直接让它读写代码。

Codex 的优势是“入口统一”。如果你的日常知识问答、产品设计、代码解释都在 ChatGPT 里，Codex 会自然成为同一工作流的一部分。

Claude Code 的入口

Claude Code 最典型的入口是终端：

claude

它也支持 IDE、桌面和 Web 侧能力，但开发者最熟悉的仍然是项目目录里的交互式终端体验。

Claude Code 的优势是“贴近本地开发”。你在项目根目录启动它，它就围绕当前仓库展开工作。

上下文文件：AGENTS.md vs CLAUDE.md

AI 编程工具最重要的能力之一，是理解项目约定。

Codex 和 Claude Code 都支持项目级说明文件。

AGENTS.md

Codex 使用 AGENTS.md 作为项目指令文件。

它通常用来描述：

项目结构
构建命令
测试命令
代码风格
提交流程
注意事项
Agent 工作边界

如果一个仓库里有 AGENTS.md，Codex 会把它当成项目内协作规则。

CLAUDE.md

Claude Code 使用 CLAUDE.md。

它的作用类似：

告诉 Claude 项目技术栈
说明常用命令
记录目录约定
提醒哪些文件不能动
指定测试和发布流程
补充团队偏好

本质区别

二者本质上都是“给 Agent 的 README”。

区别不在概念，而在生态：

1
2

Codex 生态默认读 AGENTS.md
Claude Code 生态默认读 CLAUDE.md

如果团队同时使用两者，最好维护两份内容一致的项目指令，或者把其中一份作为主文档，另一份引用它。

工具和权限

AI 编程助手真正危险的地方不是“写错代码”，而是它能执行动作。

例如：

修改文件
删除文件
运行命令
安装依赖
访问网络
提交代码
创建 PR

所以工具权限设计非常关键。

Codex 的权限模型

Codex 在本地工作时会围绕 sandbox、approval、workspace 权限做控制。

典型场景：

读文件：通常允许
写工作区：按 sandbox 配置允许
访问网络：可能需要授权
高风险命令：需要确认

这种设计适合让 Agent 在可控环境里做事：它能主动推进任务，但遇到越权动作时需要用户批准。

Claude Code 的权限模型

Claude Code 也有自己的权限控制方式，包括命令确认、工具授权、配置文件和 MCP Server 权限。

它的强项在于终端工作流里比较自然：

1
2
3

Claude 想运行命令 → 用户确认
Claude 想改文件 → 展示修改
Claude 使用 MCP → 按配置暴露能力

Claude Code 还有一些偏工程化的能力，比如 hooks、settings、权限配置等，适合团队把约束固化下来。

共同原则

无论使用哪一个工具，都应该遵守：

只给当前任务需要的权限
高风险动作必须确认
提交前必须看 diff
运行测试再信结果
不要让 Agent 直接接触生产密钥

工具越强，越需要边界。

MCP 与扩展生态

MCP 是 AI 工具连接外部系统的重要协议。

Claude Code 很早就围绕 MCP 建立了强生态：文件系统、GitHub、浏览器、数据库、Figma 等都可以通过 MCP Server 接进来。

Codex 也支持围绕工具和 MCP 扩展能力，但它的体验更多和 OpenAI 自身平台、ChatGPT、Codex CLI、云端任务结合。

Claude Code 的 MCP 体验

Claude Code 使用 MCP 的场景非常典型：

接 GitHub MCP → 查 Issue、PR、Actions
接 Filesystem MCP → 读写指定目录
接 Figma MCP → 读取设计稿
接 Browser MCP → 操作浏览器

对于喜欢自己拼装工具链的人，Claude Code 很舒服。

Codex 的扩展体验

Codex 的扩展更偏“Agent 平台化”：

本地 CLI 工具
GitHub 任务
ChatGPT 上下文
IDE 集成
云端并行任务
OpenAI 工具生态

如果你希望少折腾配置，在 OpenAI 生态里完成从讨论到执行的闭环，Codex 的路径更统一。

本地协作体验

Claude Code：终端感更强

Claude Code 的终端交互非常直接。

常见工作方式：

打开项目
运行 claude
让它阅读代码
让它计划
让它修改
看 diff
跑测试
提交

它适合你和 Agent 在同一个仓库里“边聊边改”。

尤其是长时间任务，比如：

大范围重构
系统性排查 bug
阅读陌生代码库
梳理架构
持续迭代一组文章或文档

Claude Code 的节奏比较像结对编程。

Codex：任务代理感更强

Codex 的本地 CLI 也能做类似事情，但它的整体产品方向更强调 agent 执行任务。

你可以把任务描述清楚，让 Codex 自己探索、编辑、验证，然后给出结果。

当结合 Web/云端任务时，这种感觉更明显：

1
2
3

把任务派出去
让 agent 在隔离环境里跑
最后回来审查结果

这适合同时处理多个相对独立的开发任务。

云端与并行任务

这是两者体验差异比较大的地方。

Codex 的云端任务优势

Codex 的一个明显方向是：把 coding agent 放到云端执行。

这意味着你可以：

同时派发多个任务
让任务在远程环境里跑
由 Agent 修改代码并生成 PR
在 ChatGPT 或 Web 里查看进展

这种模式适合：

修多个小 bug
批量处理 issue
并行探索多个实现方案
让 Agent 做初稿，人工做 review

它更像“给 Agent 派工”。

Claude Code 的本地长流程优势

Claude Code 更擅长你和它在一个具体工作区里持续协作。

例如：

先读代码
再写计划
再分阶段改
中途不断修正
最后跑测试和提交

这种模式适合复杂、模糊、需要频繁交流的任务。

自动化与脚本化

Codex

Codex CLI 适合命令行自动化，也可以和 GitHub、CI、云端任务结合。

适合做：

自动修复简单 issue
批量代码迁移
生成测试
代码审查辅助
文档补全

Claude Code

Claude Code 支持非交互式命令、配置、hooks、MCP、计划模式、工作树等能力。

适合做：

固定开发流程自动化
项目内长期工作流
与 MCP 工具链组合
让 Agent 按团队规范执行

如果你喜欢把 AI 工作流沉淀成一套工程规约，Claude Code 的可配置性很有吸引力。

代码质量体验

代码质量不仅取决于模型能力，也取决于工作流。

一个好的 AI 编程工具应该做到：

先读代码
理解约定
小步修改
运行测试
解释改动
不乱动无关文件
失败后能根据错误修复

Codex 和 Claude Code 都能做到这些，但体验侧重点不同。

Codex 更适合任务闭环

当任务定义清晰时，Codex 很适合直接推进：

修复这个测试失败
给这个模块补单测
把 API 从 v1 迁到 v2
根据 issue 实现功能

它的优势在于可以和 OpenAI 的 agent 生态、云端环境、PR 流程结合。

Claude Code 更适合边探索边修正

当任务还不清楚时，Claude Code 的交互感更好：

帮我先读一下这个模块
这个设计有没有问题
我们先列方案
只改这一层，别动外部 API
刚才方向不对，换一个思路

它更适合和开发者来回协作。

成本与账号体系

两者的成本模型会随着产品更新变化，具体价格要看官方最新页面。

但从使用方式上看：

1
2

Codex 更绑定 ChatGPT / OpenAI 账号体系
Claude Code 更绑定 Claude / Anthropic 账号体系

如果团队已经统一购买某一侧生态，选型成本会明显降低。

除了钱，还要考虑：

是否允许代码进入对应云端环境
是否能满足公司合规要求
是否支持所需地区和账号
是否方便管理团队权限
是否能接入现有 GitHub / CI 流程

安全与隐私

AI 编程助手会接触源代码、日志、配置、测试输出，甚至可能接触密钥。

选型时要问：

代码会不会上传云端？
是否支持本地执行？
是否能限制工作目录？
是否能禁用网络？
是否有审计日志？
是否能控制工具权限？
是否能接入企业权限系统？

对于个人项目，两者都可以很方便。
对于公司项目，合规和权限往往比模型能力更重要。

适用场景

更适合 Codex 的场景

场景	原因
ChatGPT 深度用户	需求讨论、代码执行、任务派发在同一生态
多任务并行	云端任务和 PR 流程更自然
清晰 issue 修复	适合派发给 agent 自主完成
OpenAI 技术栈项目	与 OpenAI API、Agents SDK、Responses API 等生态一致
希望少配置	入口统一，心智负担低

更适合 Claude Code 的场景

场景	原因
终端重度用户	本地项目交互体验强
复杂代码探索	适合边读边问边改
MCP 工具链丰富	接外部工具非常成熟
团队有固定工程规范	CLAUDE.md、settings、hooks 等便于固化
长流程协作	像结对编程一样持续推进

两者都适合的场景

写测试
改 bug
解释代码
生成文档
代码审查
小型重构
根据错误日志修复问题

这些基础场景里，真正拉开差距的往往不是工具名，而是你怎么给任务、怎么限制范围、怎么验证结果。

我的选型建议

个人开发

如果你已经每天用 ChatGPT，建议先试 Codex。它和 ChatGPT 的连接更自然，适合把“问问题”和“改代码”放在一个工作流里。

如果你每天离不开终端，喜欢在项目目录里和 AI 一起读代码、改代码、跑命令，Claude Code 会更顺手。

团队项目

团队项目优先看四件事：

权限能不能控
代码能不能审
测试能不能跑
流程能不能沉淀

如果团队要批量处理 issue、自动开 PR、并行跑多个任务，Codex 更值得重点看。

如果团队要把 AI 嵌入已有终端工作流、MCP 工具链和工程规范，Claude Code 更容易沉淀实践。

最佳实践：不要二选一

实际上 Codex 和 Claude Code 并不一定互斥。

可以这样分工：

1
2

Codex：处理清晰、可派发、可并行的任务
Claude Code：处理复杂、需要持续对话的本地协作任务

例如：

用 Codex 批量补测试、修小 issue、开 PR
用 Claude Code 做架构梳理、大重构、复杂排障

工具不必有信仰，能稳定交付才是重点。

使用建议

不管选哪一个，想让 AI 编程助手真正好用，都要做好这些事：

写好项目指令

Codex 写 AGENTS.md，Claude Code 写 CLAUDE.md。

里面至少包含：

项目结构
构建命令
测试命令
代码风格
禁止修改的文件
提交规范
常见坑

小步提交

不要让 Agent 一次改太多。

好的任务：

`1`	`只为 cache 模块增加 TTL 单测，不改实现。`

坏的任务：

`1`	`帮我优化整个项目。`

任务越小，结果越可靠。

每次都看 diff

AI 写的代码必须 review。

重点看：

有没有改无关文件
有没有删逻辑
有没有引入隐藏依赖
有没有测试覆盖
有没有硬编码
有没有安全问题

让工具跑验证

不要只听 Agent 说“应该可以”。

要求它运行：

go test ./...
npm test
cargo test
hugo

能运行验证，才算闭环。

小结

Codex 和 Claude Code 都是强 AI 编程工具，但侧重点不同。

1
2

Codex：更像 OpenAI / ChatGPT 生态里的工程代理。
Claude Code：更像终端里的长期代码协作搭档。

选型时不要只问“哪个模型更强”，而要问：

我的任务是派发型还是协作型？
我更依赖云端还是本地？
我的工具链更靠 OpenAI 还是 MCP？
团队权限和审计怎么做？
结果如何验证？

如果任务清晰、可以并行、适合交给 Agent 自主跑，Codex 很合适。
如果任务复杂、上下文多、需要反复沟通和本地工具链配合，Claude Code 很顺手。

真正高效的做法，是把它们都当成工程工具：明确边界、控制权限、跑验证、看 diff。这样无论用哪一个，都会比“盲目相信 AI”可靠得多。

参考资料

Claude Code 安装与 Superpowers 实战：从想法到发布的工程化工作流

Tue, 28 Apr 2026 00:00:00 +0000

为什么需要 Superpowers

Claude Code 原生已经很强——读代码、写文件、跑命令，日常够用。但面对复杂任务时，它容易"一步到位直接写"，然后反复修 bug。你不是在写代码，是在和 AI 打乒乓球。

Superpowers 解决的问题就是这个。它是一套工程化工作流，把软件开发的标准流程——澄清需求、写设计文档、拆分任务、TDD、调试、审查、验证——固化为 18 个 Skill。Claude 拿到的不再是一句"帮我做 X"，而是一整套经过验证的做事方法。

下面用一个完整的 Go 项目——从零写一个并发安全的缓存库——把 18 个 Skill 串一遍。

安装

Claude Code

Windows 下需要 Node.js 20+，推荐 npm 全局安装：

`1`	`npm install -g @anthropic-ai/claude-code`

macOS/Linux 同理。装完后终端输入 claude 启动，首次会引导登录 Anthropic 账号并绑定 API Key。

Superpowers 插件

`1`	`npx skills add anthropics/skills@superpowers -g -y`

安装后重启 Claude Code，npx skills list 确认看到 18 个 superpowers: 前缀的 Skill。无需额外配置，对话中自动触发。

实战：Go 并发安全缓存库

我们的目标是写一个带 TTL 过期、LRU 淘汰、并发安全的 Go 缓存库。下面按 Superpowers 的完整流程走一遍。

1. 想法 → brainstorming

在项目目录下打开 Claude Code，输入：

我想写一个 Go 的并发安全缓存库，支持 TTL 过期和 LRU 淘汰策略

这时 Superpowers 的 brainstorming Skill 自动介入——Claude 不会直接写代码，而是开始追问：

几个问题帮我理清需求：

缓存容量是固定的还是可配置的？有默认值吗？

TTL 是在 Set 时指定每个 key 独立的过期时间，还是全局统一？

API 风格偏好——Get(key) (value, bool) 这种标准模式，还是需要额外返回 error？

淘汰策略是纯 LRU，还是需要支持 LFU / ARC 等扩展接口？

追问结束后，Claude 提出两种方案：

方案 A — sync.Map + 惰性删除：利用 sync.Map 的无锁读，过期 key 在 Get 时惰性清理，简单但 LRU 维护麻烦
方案 B — 分片 + mutex + 双向链表（推荐）：标准做法，每个分片独立锁，链表维护访问顺序，TTL 用 time.AfterFunc 或惰性检查

确认方案 B 后，Claude 把设计文档写入 docs/superpowers/specs/。

2. 设计 → writing-plans

brainstorming 结束后，Claude 自动调用 writing-plans，将设计文档转化为可执行的任务列表：

1. 定义 Cache 接口（Set/Get/Del/Len）
2. 实现 item 结构体（value + expiration + list.Element）
3. 实现 LRU 双向链表（promote + evict）
4. 实现分片锁管理器（hash key → shard）
5. 实现 TTL 过期检查（惰性删除 + 可选后台清理）
6. 编写并发安全测试（-race 检测）
7. 编写基准测试（benchmark）

每个任务有明确的输入、输出和验收标准，不再是一个模糊的"帮我写个缓存库"。

3. 隔离 → using-git-worktrees

正式编码前，Claude 建议创建隔离的工作树：

这个改动不小，建议先在 worktree 里做，不会弄乱 main 分支。

接受后，Claude 调用 EnterWorktree，在 .claude/worktrees/ 下创建独立分支和目录。所有的文件变更都隔离在这个环境里，随时可以丢弃重来，不影响主分支。

4. 编码 → TDD + 并行 Agent

test-driven-development Skill 介入——Claude 先写测试：

func TestCache_SetAndGet(t *testing.T) {
    c := cache.New(cache.WithMaxItems(100))
    c.Set("key1", "value1", 5*time.Second)
    val, ok := c.Get("key1")
    assert.True(t, ok)
    assert.Equal(t, "value1", val)
}

func TestCache_Expiry(t *testing.T) {
    c := cache.New(cache.WithMaxItems(100))
    c.Set("key1", "value1", 50*time.Millisecond)
    time.Sleep(100 * time.Millisecond)
    _, ok := c.Get("key1")
    assert.False(t, ok)
}

测试写完后才进入实现。此时 dispatching-parallel-agents 发挥作用——LRU 链表实现和 TTL 过期逻辑是两个独立任务，Claude 同时启动两个 subagent 并行处理：

1
2

[subagent-1] 实现 LRU 双向链表 + promote + evict
[subagent-2] 实现 TTL 惰性过期检查 + 后台清理 goroutine

两个 agent 完成后，主 Agent 把它们的结果合并到分片锁管理器中。并行的好处是等待时间减半——LRU 链表和 TTL 互不依赖，完全可以同时写。

5. 排查 → systematic-debugging

编码完成后运行测试：

`1`	`go test -race ./...`

咦，race detector 报了一个 data race。Claude 没有猜原因，而是触发 systematic-debugging：

观察到的现象：TestCache_ConcurrentSet 在 -race 下报 data race，指向 item.lastAccess 字段的并发写入。

假设一：promote 操作没有在锁内修改链表节点假设二：TTL 检查的 goroutine 和 Set 之间没有同步

先验证假设一：在 promote 调用处加 trace 日志，确认是否在 shard.mu.Lock() 之外执行。

逐步排除后定位到根因：Get 中的 promote 操作读取了 item.lastAccess 但未加写锁。修复后 -race 干净通过。

整个过程不是 Claude 盲目改代码，而是形成假设 → 逐个验证 → 定位根因，和人类 debug 的思维方式一致。

6. 审查 → requesting-code-review + receiving-code-review

测试通过后，Claude 调用 requesting-code-review，由独立的 code-reviewer agent 审查代码。审查结果返回：

缺少 Keys() 方法，调用方无法遍历所有有效 key

TTL 后台清理 goroutine 没有优雅退出机制，调用 New() 多次会泄漏 goroutine

WithMaxItems(0) 应该视为无限制，当前实现会 panic

receiving-code-review Skill 此时介入——它提醒 Claude 不要"全盘接受所有建议"：

评估每条审查意见：第一条确实需要，第二条必须修，第三条是防御性编程可以加。不要为了"让 reviewer 满意"而过度工程。

修复这三条后重新运行测试，确认没有引入回归。

7. 验证 → verification-before-completion

代码改完了，Claude 没有直接说"搞定了"，而是执行 verification-before-completion：

1
2
3

go test -race -count=3 ./...      # 重复三次确认无 flaky
go test -bench=. -benchmem ./...   # 基准测试通过
go vet ./...                       # 静态分析无警告

三项全部通过后，Claude 才报告完成。先验证再宣称——这是 Superpowers 的核心纪律。

8. 收尾 → finishing-a-development-branch

功能验证通过，finishing-a-development-branch 给出三个选项：

合并到 main（本地直接 merge）

创建 PR（推到远程并 gh pr create）

保留当前分支，稍后处理

选择 2 后，Claude 分析 diff，生成 PR 标题和描述，推送到远程并创建 Pull Request。Worktree 清理后回到原工作目录，main 分支干干净净。

Superpowers Skill 速查表

阶段	Skill	用途
构思	`brainstorming`	需求澄清、方案探索、设计文档
设计	`writing-plans`	设计文档 → 可执行任务清单
设计	`executing-plans`	在独立会话中按计划逐步执行
编码	`using-git-worktrees`	创建隔离工作树，避免污染主分支
编码	`test-driven-development`	先写测试再写实现
编码	`dispatching-parallel-agents`	并行调度 subagent 处理独立任务
编码	`subagent-driven-development`	在独立 subagent 中执行任务
调试	`systematic-debugging`	假设驱动、逐步验证的调试方法
审查	`requesting-code-review`	请求独立 code-reviewer 审查代码
审查	`receiving-code-review`	评估审查反馈，有选择地采纳
验证	`verification-before-completion`	运行验证命令后才宣称完成
发布	`finishing-a-development-branch`	合并/PR/保留的结构化收尾
发布	`gh-cli`	GitHub CLI 操作辅助
发布	`git-commit`	自动生成规范 commit 信息
工具	`using-superpowers`	Superpowers 总入口，引导正确使用
工具	`find-skills`	搜索和发现第三方 Skill
工具	`writing-skills`	创建和编辑自定义 Skill
工具	`update-config`	配置 settings.json（权限、环境变量等）

小结

Superpowers 的价值不是"让 Claude 更强"，而是让 Claude 做事更有章法。从想到做、从做到上线，每个阶段有对应的 Skill 把流程框住——需求先澄清、方案先设计、代码先测试、完成先验证。这恰好是优秀工程师的工作习惯，现在通过 Skill 机制固化到了 AI 编程流程里。

Claude Code Skills 使用教程

Thu, 02 Apr 2026 00:00:00 +0000

什么是 Skills

Skills（技能）是 Claude Code 的扩展机制，类似于 IDE 的插件系统。每个 Skill 封装了特定领域的知识、工作流程和工具集成，安装后 Claude Code 便自动获得该领域的能力。

打个比方：MCP 是给 Claude 接上外部工具（手），Skills 是教会 Claude 特定的工作方法（脑）。

Skills 生态基于 npx skills CLI 管理，社区贡献的 Skills 托管在 skills.sh，可以自由查找和安装。

Skills vs MCP

很多同学会把两者搞混，先区分一下：

维度	Skills	MCP
本质	提示词 + 工作流模板	工具/数据源连接协议
作用	教 Claude"怎么做"	让 Claude"能访问什么"
配置	`npx skills add` 安装	`.claude/claude.json` 配置
示例	自动生成 commit、代码审查	文件系统、GitHub API

两者互补，经常配合使用。比如安装了 gh-cli Skill，还需要 GitHub MCP 提供 API 访问能力。

查找 Skills

方式一：命令行搜索

`1`	`npx skills find <关键词>`

例如：

1
2
3

npx skills find github     # 搜索 GitHub 相关 Skill
npx skills find react      # 搜索 React 相关 Skill
npx skills find testing    # 搜索测试相关 Skill

搜索结果会显示 Skill 名称、安装量和详情链接。

方式二：浏览在线市场

访问 skills.sh 查看排行榜，按安装量排序。热门 Skill 通常更可靠。

目前最受欢迎的 Skill 系列：

系列	来源	热门 Skill
`vercel-labs/agent-skills`	Vercel 官方	react-best-practices, next-js, web-design
`github/awesome-copilot`	GitHub	git-commit, gh-cli, prd
`anthropics/skills`	Anthropic 官方	frontend-design, document-processing

挑选 Skill 的三条原则

安装量优先 — 选 1K+ 安装量的，避开 < 100 的
来源可靠 — 官方来源（vercel-labs、anthropics、github）优先
安全审计通过 — 安装时注意看 Gen、Socket、Snyk 的审计结果

安装 Skills

基本命令

`1`	`npx skills add <owner/repo@skill-name> -g -y`

参数说明：

-g：全局安装（用户级，所有项目可用）
-y：跳过确认提示

安装示例

安装 git-commit Skill，用于自动生成规范的 commit 信息：

`1`	`npx skills add github/awesome-copilot@git-commit -g -y`

安装 gh-cli Skill，辅助 GitHub CLI 操作：

`1`	`npx skills add github/awesome-copilot@gh-cli -g -y`

安装成功后，Skill 文件存放于 ~/.agents/skills/ 目录。

安装输出解读

安装过程会显示：

◇  Source: https://github.com/github/awesome-copilot.git@git-commit
◇  Repository cloned
◇  Found 308 skills
●  Selected 1 skill: git-commit
◇  45 agents
●  Installing to: Claude Code, OpenClaw, Codex, Trae CN

◇  Installation Summary
  ~\.agents\skills\git-commit
    universal: Codex, Amp, Antigravity, Cline, Cursor +7 more
    symlink → Claude Code, OpenClaw, Trae CN

◇  Security Risk Assessments
  git-commit  Safe  0 alerts  Low Risk

◇  Installed 1 skill
✓ ~\.agents\skills\git-commit

关键信息：

agents：支持 45 种 AI 编程工具
Security Risk：Gen 评为 Safe、Socket 0 alerts 即安全
symlink：Claude Code 通过符号链接加载

使用 Skills

安装后无需额外配置，Skill 会自动生效。有两种触发方式：

自动触发

当对话内容命中 Skill 的适用场景时，Claude Code 会自动调用。例如安装了 git-commit 后，说"帮我提交代码"，Claude 就会用该 Skill 生成规范 commit。

手动调用

使用 / 斜杠命令显式调用：

`1`	`/git-commit`

/skills 命令可以查看当前已安装的所有 Skill。

管理 Skills

查看已安装

`1`	`npx skills list`

检查更新

`1`	`npx skills check`

更新所有 Skill

`1`	`npx skills update`

锁定版本

安装 Skill 后会自动生成 skills-lock.json（类似 package-lock.json），锁定版本到当前 tag 对应的 commit。将该文件提交到 Git 仓库，团队成员拉取后可用 npx skills install 安装完全相同的版本。

1
2

git add skills-lock.json
git commit -m "chore: lock skill versions"

常用 Skill 推荐

开发效率

Skill	用途	安装量
`github/awesome-copilot@git-commit`	自动生成规范 commit	26.7K
`github/awesome-copilot@gh-cli`	GitHub CLI 辅助	19.3K
`github/awesome-copilot@prd`	自动生成 PR 描述	15.8K

安装：

1
2

npx skills add github/awesome-copilot@git-commit -g -y
npx skills add github/awesome-copilot@gh-cli -g -y

代码质量

Skill	用途	安装量
`simplify` (内置)	审查代码质量和效率	内置
`security-review` (内置)	安全审查	内置
`review` (内置)	PR Review	内置

注：simplify、security-review、review 是 Claude Code 自带的基础 Skill，无需额外安装。

前端开发

`1`	`npx skills add vercel-labs/agent-skills@react-best-practices -g -y`

Skill 与 CLAUDE.md 配合

CLAUDE.md 是项目级的指令文件，告诉 Claude 项目的上下文信息。Skills + CLAUDE.md 的组合效果最佳：

项目根目录/
├── CLAUDE.md          # 项目说明（技术栈、目录结构、约定）
├── skills-lock.json   # Skill 版本锁定
└── .claude/
    └── claude.json    # MCP 配置

三者分工明确：CLAUDE.md 描述项目，Skills 赋予领域能力，MCP 连接外部工具。

常见问题

安装时 clone 很慢

GitHub 仓库克隆失败或速度慢时，可以设置代理：

`1`	`git config --global http.proxy http://127.0.0.1:7890`

Skill 不生效

确认 Skill 已安装成功：npx skills list
重启 Claude Code
确认项目根目录下没有冲突的 .agents/ 目录

多个 Agent 工具的 Skill 隔离

~/.agents/skills/ 是通用 Skill 目录，Claude Code 通过 symlink 引用。如果你同时使用 Codex、Cursor 等工具，同一个 Skill 会被共享，这是预期行为。

小结

查找：npx skills find <关键词>
安装：npx skills add <owner/repo@skill> -g -y
使用：自动触发或 /skill名 手动调用
管理：npx skills list / check / update

Skills 让 Claude Code 从通用助手变成领域专家，是提升效率的核心手段。

Claude Code 安装配置 MCP 教程

Wed, 01 Apr 2026 00:00:00 +0000

什么是 MCP

MCP（Model Context Protocol，模型上下文协议）是 Anthropic 推出的一种开放协议，用于标准化 AI 模型与外部工具、数据源之间的通信。通过 MCP，Claude Code 可以连接各种外部服务，比如文件系统、GitHub、数据库、浏览器等，从而大幅扩展其能力边界。

简单理解：MCP 就像是 AI 的"USB 接口"，让 Claude 可以即插即用地连接各种外部工具。

环境准备

Claude Code 已安装（本文以 Windows 为例）
Node.js 20+（大部分 MCP Server 需要）
对应 MCP Server 所需的服务账号或 Token（如 GitHub Token）

npx 命令需要 Node.js 环境，确保已安装：

1
2

node -v   # 确认版本 >= 20
npm -v

MCP 配置结构

Claude Code 启动时会自动注册已配置的 MCP Server，所以 只需配置一次，每次使用自动就绪。

配置文件分为三个层级：

文件	作用域	路径
`claude.json`	项目级	项目根目录 `.claude/`
`claude.json`	全局用户级	`~/.claude/`
`settings.json`	项目/用户级	同上（可合并配置）

项目级配置仅对当前项目生效，用户级配置对所有项目生效。项目级会覆盖用户级的同名 MCP Server。

配置 MCP Server

以下使用项目级配置为例，在 .claude/claude.json 中添加 mcpServers 字段：

{
  "mcpServers": {
    "server-name": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@org/mcp-package"],
      "env": {
        "API_KEY": "your-api-key"
      }
    }
  }
}

每个 MCP Server 的关键字段：

server-name：自定义名称，用于日志区分
type：通信方式，目前几乎都是 "stdio"
command：启动命令，通常是 npx 或 node
args：命令参数
env：环境变量（存放 Token 等敏感信息）

配置示例一：Filesystem MCP（文件系统）

让 Claude 读取和写入指定目录：

{
  "mcpServers": {
    "filesystem": {
      "type": "stdio",
      "command": "npx",
      "args": [
        "-y",
        "@anthropic/mcp-filesystem",
        "D:\\projects"
      ]
    }
  }
}

配置示例二：GitHub MCP

连接 GitHub，自动创建 Issue、PR 等：

{
  "mcpServers": {
    "github": {
      "type": "stdio",
      "command": "npx",
      "args": ["-y", "@anthropic/mcp-github"],
      "env": {
        "GITHUB_TOKEN": "ghp_xxxxxxxxxxxx"
      }
    }
  }
}

GitHub Token 可在 GitHub Settings > Developer settings > Personal access tokens 创建。

配置示例三：Figma MCP

让 Claude 直接读取 Figma 设计稿并生成代码。在 settings.json 中配置：

{
  "enableAllProjectMcpServers": true,
  "enabledMcpjsonServers": ["figma"]
}

Figma MCP 通常在 .mcp.json 中配置（由 Figma 桌面客户端自动生成），无需手动编写。

常用 MCP Server 推荐

MCP Server	用途	安装量
`@anthropic/mcp-filesystem`	文件系统读写	官方出品
`@anthropic/mcp-github`	GitHub API 集成	官方出品
Figma MCP	设计稿转代码	需要 Figma 桌面端
Playwright MCP	浏览器自动化	用于网页截图、测试

可以通过 npx skills find mcp 搜索更多第三方 MCP。

验证 MCP 是否生效

配置完成后，有两种验证方式：

方式一：启动后检查日志

claude

启动后查看控制台输出，成功注册的 MCP Server 会显示类似：

`1`	`[MCPServerRegistry] Registered MCP server: filesystem`

方式二：直接对话测试

在 Claude Code 中输入：

帮我列一下 D:\projects 目录下的文件

如果 Filesystem MCP 配置正确，Claude 会直接列出文件。

常见问题

npx 命令找不到

确保 Node.js 已安装且 npm 目录在 PATH 中：

`1`	`where npx`

MCP Server 启动失败

检查 .claude/claude.json 的 JSON 格式是否正确（不能有多余逗号）。也可以用 npx 直接在终端测试 MCP Server 包是否能正常下载：

`1`	`npx -y @anthropic/mcp-filesystem D:\test`

Token 权限不足

GitHub MCP Server 报 403 通常是 Token 权限不够。创建 Token 时确保勾选 repo、workflow 等必要权限。

多个配置文件优先级

项目级 .claude/claude.json > 用户级 ~/.claude/claude.json。同名 MCP Server 项目级会覆盖用户级。

小结

MCP 是 Claude Code 的核心扩展机制，配置简单但能力强大：

在 .claude/claude.json 中添加 mcpServers 字段
填写 command、args、env 等参数
重启 Claude Code 即可生效

建议从官方 @anthropic 系列的 MCP Server 开始，稳定性和安全性都有保障。

Claude Code 常用命令速查手册

Thu, 19 Mar 2026 00:00:00 +0000

引言

Claude Code 是 Anthropic 推出的命令行 AI 编程助手。日常使用中，掌握常用命令和快捷键能显著提升效率。本文整理了高频使用的命令、参数和操作技巧，适合随时查阅。

启动与基础命令

启动 Claude Code

# 在项目目录下启动
claude

# 直接带问题启动
claude "帮我分析这个项目的结构"

# 指定模型
claude --model opus

# 跳过权限检查（一次性）
claude --dangerously-skip-permissions

查看帮助

# 查看所有命令
/help

# 查看指定命令的帮助
/help compact
/help memory

退出

1
2

/exit
# 或 Ctrl+C / Ctrl+D

会话管理

对话上下文中断与恢复

多次连续对话后 token 积累较多时，可以主动压缩上下文：

`1`	`/compact`

Claude 会自动压缩历史对话、保留关键信息并更新 token 用量。建议对话超过几十轮后手动压缩，避免达到上下文限制。

开始新对话

/clear

保留当前会话的工作目录和权限设置，只清空对话历史。

查看对话统计

`1`	`/context`

显示当前会话的 token 使用量、剩余空间等关键信息。

文件与代码编辑

Claude Code 在对话中直接编辑文件，理解意图后修改代码。以下是主动触发文件操作的方式：

格式化代码

# 格式化指定文件
/format-file src/index.ts

# 格式化当前打开的全部文件
/format-file

查看差异

当 Claude 修改代码后，通常不会默认展示 diff。可以在对话中直接说"显示差异"或：

/diff

回退修改

对修改不满意时：

/undo

创建与管理

初始化项目文档

/init

Claude 会自动扫描项目结构、技术栈、构建系统，生成项目级 CLAUDE.md 文件。这是让 Claude 快速理解项目的最佳方式。

创建 PR

对当前分支有提交但未合并的情况：

/pr

Claude 会自动分析变更生成标题和描述，创建 Pull Request。

查看已安装的 Skills

/skills

列出当前项目可用和已安装的所有 Skill。

计划模式与工作树

计划模式

复杂任务先规划再执行：

# 进入计划模式
/plan

# 或者直接描述任务，Claude 会自动询问是否需要先规划
"帮我重构用户认证模块"

在计划模式下 Claude 只会探索代码库并设计方案，不修改代码，直到你确认方案。

工作树隔离

开发新功能时，可以先创建隔离的工作树，不影响主工作区：

`1`	`/worktree`

Claude 会在 .claude/worktrees/ 下创建独立的 git 工作树，在其中完成开发，避免污染主分支。

记忆系统

Claude Code 支持文件持久化的记忆系统，跨会话保留关键信息。

记住信息

# 记住用户偏好
/remember "这个项目使用 Go 1.22，模块路径是 github.com/user/repo"

# 记住项目约定
/remember "测试文件放在 __tests__ 目录，使用 vitest"

管理记忆

记忆文件存放在项目和用户目录的 .claude/projects/ 下。可直接在对话中说"显示记忆"或"删除记忆 X"进行管理。

权限管理

配置权限

每个 Bash 命令、文件操作都可能需要用户确认。可以精细化控制：

`1`	`/permissions`

或在 settings.json 中配置白名单：

{
  "permissions": {
    "allow": [
      "Bash(git:*)",
      "Bash(npm:* test*)",
      "Bash(hugo:*)"
    ]
  }
}

免打扰模式

1
2

# 减少确认提示
claude --output-format stream-json

配置与自定义

全局设置

/config

进入交互式配置菜单，修改主题、模型、权限等。

配置文件位置

级别	路径	作用
用户级	`~/.claude/settings.json`	全局生效
项目级	`.claude/settings.json`	当前项目生效
本地覆盖	`.claude/settings.local.json`	本地覆盖，不入库

设置环境变量

1
2

# 添加环境变量
/env

也可以在 settings.json 中通过 env 字段设置。

常用快捷键

在交互式 TUI 中使用以下快捷键提升效率：

快捷键	作用
`Ctrl+C`	中断当前生成或操作
`Ctrl+D`	退出 Claude Code
`Ctrl+R`	搜索对话历史
`Ctrl+O`	查看压缩后的对话摘要
`Ctrl+G`	切换对话模式（需要权限时）
`↑/↓`	浏览历史命令
`Shift+Tab`	切换焦点区域
`Esc`	返回 / 取消当前操作

自定义快捷键

编辑 ~/.claude/keybindings.json 自定义快捷键：

1
2

/claude keybindings
# 或在对话中说"帮我自定义快捷键"

命令组合

日常使用中常见的命令组合流程：

流程一：代码审查

# 1. 检查当前状态
"帮我看看未提交的改动"

# 2. 安全审查
/security-review

# 3. 格式化
/format-file

流程二：功能开发

# 1. 确认要修改
"在 Go 后端 blog 项目中添加文章标签过滤接口"

# 2. 复杂任务先规划
/plan

# 3. 确认方案后开始实现

# 4. 审查代码
/review

流程三：提交与发布

# 1. 检查状态
"git status 看看有什么变更"

# 2. 让 Claude 生成提交信息
/commit

# 3. 推送
"push 一下"

# 4. 创建 PR
/pr

常用 CLI 参数

# 指定模型
claude --model haiku           # 轻量快速
claude --model sonnet          # 平衡
claude --model opus            # 最强推理

# 调试模式
claude --debug

# 输出格式
claude --output-format json    # JSON 输出
claude --output-format stream-json  # 流式 JSON

# 只生成不交互
claude -p "解释 Go 的接口"     # 直接输出后退出

# 指定工作目录
claude --cwd /path/to/project

小结

会话管理：/compact 压缩上下文，/clear 清空对话
文件操作：/diff、/format-file、/undo
项目管理：/init 初始化、/pr 创建 PR
开发流程：/plan 先规划、/review 后审查
安全与权限：/permissions 配置、/security-review 审查

掌握这些命令，日常使用 Claude Code 的效率会有质的提升。不需要记所有命令——用 /help 随时查，需要什么看什么。