Claude Code

价格

Commercial

平台

Terminal, macOS, Linux

官网

https://docs.anthropic.com/en/docs/claude-code

免费访问判断

Anthropic 曾为符合条件的开源维护者提供 Claude 访问计划。

注意

这不是通用免费额度，更像面向维护者的申请制计划。

2026 年结论

Claude Code 不应该被理解成“没有界面的 Cursor”。它更像一个住在命令行里的资深 coding worker：能读仓库、形成计划、修改文件、运行命令，最后交给你一组可以审查的 diff。

我的判断：Claude Code 的价值不是让不会写代码的人突然变强，而是放大一个已经有工程纪律的团队。如果你的仓库有清晰测试、稳定 lint、明确代码风格和小颗粒度任务，它会很快给出有用的一稿。如果这些护栏不存在，它也可能很快产出一堆看似合理但很难验证的改动。

它到底解决什么问题

Claude Code 的核心不是补全一行代码，而是处理一个开发任务。比如理解陌生模块、追踪 bug、补测试、做小范围重构、根据日志定位问题、把重复开发动作自动化。

这意味着它更适合习惯命令行、Git diff、测试输出、CI 日志和脚本的开发者。它不是“让编辑器更聪明”，而是“给仓库安排一个受约束的执行者”。

近期官方更新值得关注的地方

Anthropic 的 Claude Code changelog 更新很快，所以我会把这个页面当成持续评估，而不是一次性评测。2.1.142 到 2.1.145 这几轮更新，重点不只是“模型更会写代码”，而是当 agents、plugins、skills、hooks 和 background sessions 成为常态后，Claude Code 如何被观察、恢复和治理。2026 年 5 月 28 日 Claude Opus 4.8 发布把这个方向推了一步，2026 年 6 月 9 日 Claude Fable 5 发布后，Claude Code 的顶级模型栈又变了。

几个对团队有价值的变化：

• Claude Code 中的 Claude Fable 5，但要注意暂停状态：Anthropic 在 2026 年 6 月 9 日发布 Fable 5，把它描述为目前广泛发布模型里能力最强的模型，也是 Claude Code 中适合超过一次工作会话任务的最强模型。原本的使用路径是 Claude Code v2.1.170 或更新版本，先运行 claude update，再用 /model fable 选择。但当前采用判断必须补上一句：Anthropic 在 2026 年 6 月 12 日因为 classifier calibration issues 暂停了 Claude Fable 5 access。我的判断：可以准备评测用例，但在官方恢复访问前，不要把 Fable 5 当成可用默认模型。
• Fable 专属操作边界：等访问恢复后，Fable 5 也应该是有意升级使用的长任务模型，而不是每个小改动的默认选择。官方 Fable 页面还说明了实际边界：被标记的网络安全或生物学请求可能 fallback 到 Claude Opus 4.8；它不支持 zero data retention；使用 Fable 需要 30 天数据保留用于安全监控。
• 面向严肃仓库工作的 1M context：Claude Code 的模型配置文档说明 Fable 5 路径支持 1 million token context window，适合大代码库和长会话。这对 multi-package migrations 和长时间 debug 有意义，但不能替代 /context、/compact 和明确任务边界。
• Claude Code 2.1.145 的 agent 可观测性：claude agents --json 让脚本更容易读取 agent 状态，OTEL spans 增加 agent_id 和 parent_agent_id，status-line JSON 可以带 GitHub repo 和 PR 信息。对团队来说，这比终端里滚过去的一段日志更适合审计。
• Claude Opus 4.8 与 Dynamic Workflows：Anthropic 把 Opus 4.8 定位成更偏 coding 的 frontier model，并说明 Claude Code 现在可以为长任务并行启动数十到数百个专门 subagents，覆盖大规模迁移、依赖升级、安全修复、flaky test 清理和 issue triage。我的判断：这不是普通模型升级，而是 Claude Code 从“单 agent 加工具”转向“agent team orchestration”。
• Effort controls 变得更重要：Anthropic 说明 Opus 4.8 默认 high effort，Claude Code 里还可以使用 xhigh、extra、max 等更高 effort 设置。Fast mode 在很多工作负载下速度可以明显提升，但官方强调它是速度路径，不是最便宜模式。团队应该按任务风险选择 effort，而不是凭感觉。
• 安装前的插件可见性：/plugin 现在会在安装前展示 commands、agents、skills、hooks、MCP servers 和 LSP servers。插件安装不应该是随手点一下，而应该是依赖和权限决策。
• Background sessions 恢复能力：近期更新改善了 /resume、后台 subagent 时长、模型保持、worktree 处理和 session 配置。我的实际判断：后台 Claude Code 越好用，每个后台任务越需要命名 branch 或 worktree、验证命令和 review 负责人。
• 上下文成本与插件依赖可见：Claude Code 2.1.143 增加了 plugin dependencies 和 projected context cost 的可见性。重度使用时，问题往往不只是代码质量，而是隐藏的上下文膨胀、昂贵提示词和不透明 token 消耗。
• 企业 managed settings 与 web security：Anthropic 的 enterprise managed settings 和 Claude Code security preview 都指向组织级部署。正确理解不是“到处都能跑”，而是“给 agent 更多入口之前先定义策略”。

我的评价：2026 年 Claude Code 正在从“很快的终端 agent”变成“带模型路由、Fable 级长程任务能力、并行 subagents、治理钩子和可 review 产物的 agent runtime”。这是正确方向。一个工具一旦可以跑后台 session、安装插件、调用 MCP servers、暴露 skills、汇报 GitHub PR 状态，最重要的问题就变成：团队能否审查它到底做了什么。

2026 年 6 月下旬操作观察

Claude Code 最新信号不只是模型访问，而是运行层加固：remote control、agent teams、permissions、hooks、plugin inspection 和 background recovery。我的理解是，Anthropic 正在把 Claude Code 从短演示里的终端助手，推进到能承接长时间工程任务的 agent runtime。

现在采用时要明确三条规则。第一，subagents 要对应真实职责，比如 reviewer、test fixer、migration planner、dependency auditor 或 frontend verifier。第二，hooks 和 permission modes 不只是阻止危险命令，更要强制产出证据。第三，background work 开始前就应该有命名 worktree、proof commands 和 review owner。

这也让它和 Codex 的对比更清楚。Claude Code 更适合以本地 shell、Git state、MCP servers 和 permission prompts 为事实来源的任务。Codex 更适合 ChatGPT 原生入口、手机 steering、cloud tasks、project context 和跨设备连续性更重要的任务。认真采用时，两边应该复用同一份 task brief、acceptance criteria 和 proof commands。

实用指令与操作方式

Claude Code 最近变强了，但日常质量仍然取决于你怎么操作它。官方 commands、permissions、hooks、subagents、MCP 文档已经给出一个清晰模式：先设项目记忆，再选权限姿态，然后只在能减少歧义或增加证据时添加 subagents、hooks、MCP servers 和 plugins。

我会把下面这套当作默认操作顺序：

• 第一次进入仓库：先运行 /init 生成初始 CLAUDE.md，再用 /memory 补充架构说明、测试命令、代码风格、禁止修改区域和 review 预期。不要让第一个任务在没有 repo contract 的情况下开始。
• 先计划，再编辑：探索陌生仓库时，用 /permissions 或 claude --permission-mode plan 启动。plan mode 适合阅读、分析和只读命令，不应该直接改源文件。架构探索、迁移范围评估、高风险 bug 报告都适合先用这个模式。
• 明确 approval rules：用 /permissions 决定编辑、shell commands、MCP tools 或高风险动作是否需要审批。default 最适合敏感任务，acceptEdits 适合有人 review 的迭代，auto 能减少长任务中的确认疲劳，bypassPermissions 只应该放在隔离 container 或 VM 里。
• 有意地添加 subagents：只有当任务能拆出独立责任时才用 /agents，比如 reviewer、test fixer、dependency auditor、migration planner、frontend verifier。一个 subagent 应该有窄描述、受限 tools 和明确存在理由。
• 只在真实上下文缺口时加 MCP：当 Claude 需要 GitHub、文档、Issue、观测数据、数据库或内部 API 时再用 /mcp。不要因为某个 MCP server 可用就接入它，要因为任务需要那个上下文才接入。
• 信任自动化前先看 hooks：用 /hooks 检查 tool-event hooks。好的 hooks 会阻止危险写入、编辑后要求检查、验证最终声明；坏的 hooks 会悄悄增加副作用。
• 把 /plugin 当依赖审查：安装前先看插件会增加哪些 commands、agents、skills、hooks、MCP servers 和 LSP servers。插件安装应当像添加带权限的开发依赖一样审查。
• 恢复和审计后台工作：后台 session 用 /resume，需要脚本读取 agent 状态时用 claude agents --json。这应该和命名 worktree、明确 proof commands、指定 review owner 一起使用。
• 用 /context 和 /compact 管理漂移：长会话开始跑偏前，先看当前 context，再主动 compact。上下文膨胀是 agent 工作变贵、变散、变难 review 的常见原因。

我的工作规则：在任务、测试和文件边界没有搞清楚前，用 plan 或保守权限；任务足够窄、结果可 review 后，再切到 acceptEdits 或 auto；bypassPermissions 只给一次性隔离环境。优秀团队不是靠给 Claude Code 最大自由度获胜，而是靠让每次权限提升都可见、每个完成声明都有验证证据。

对 Fable 5 我会再加一条规则：等访问恢复后，只有当任务已经写成 outcome 和 acceptance criteria 时，才用 /model fable。不要微观管理每一步，而是给目标、约束、仓库边界和 proof commands，然后审查它的计划和最终 diff。如果只是一个单文件小修改，用 Opus 或 Sonnet 级别模型更合适。Fable 的优势会出现在本来需要数小时、多个会话或多个 subagents 的任务上。

Claude Code 与 Codex 如何关联使用

Claude Code 和 Codex 在 2026 年的重叠越来越多，但不应该把它们当成同一个工具。Claude Code 的强项是本地仓库、终端命令、Git 状态、hooks、permissions、MCP servers、subagents 和 proof commands。Codex 的强项是 ChatGPT 账号体系里的跨入口工作：Codex App、云端任务、connected hosts、手机 steering、Automations、active sessions、历史线程搜索，以及统一的 model 与 reasoning effort 设置。

一个实用分工是：

• 先用 Claude Code 做本地诊断：读仓库、复现失败、看日志、跑测试、理解 Git state，并把问题收敛成窄计划。
• 把并行或后台尝试交给 Codex：当任务需要 OpenAI 托管云端任务、ChatGPT mobile 跟进、多仓库访问、历史 Codex threads 搜索，或者 PR 级 review 面时，Codex 更适合。
• 两边使用同一组验收条件：比较 diff 大小、proof commands、review 时间、后续修复次数，以及工具是否解释了为什么这个改动安全。
• 治理要靠近执行入口：Claude Code 侧使用 /permissions、/hooks、/agents 和 MCP scopes；Codex 侧关注 active sessions、Codex Profiles、workspace settings、model/reasoning sync 和 Automation 边界。
• 用规范和 skills 做共同契约：OpenSpec 和 Skills 矩阵 可以降低任务歧义；9Router 或 OpenRouter 式路由属于成本与 fallback 层，不应该替代任务纪律。

我的建议：Claude Code 负责贴近 shell 的执行和本地证据；Codex 负责跨入口连续性、云端或 connected-host 委托、可 review 的后台工作。最强的工作流不是永远选一个 agent，而是让任务说明、权限、验证命令和 review 记录能在两个工具之间复用。

更大的变化：Agent Runtime 产品化

Claude Code 更深层的变化，不是“Anthropic 又换了一个更强模型”，而是 Anthropic 正在把 agent 周围的运行时产品化。这个方向可以在 ready-to-run agent templates、MCP 和 connector tooling、Claude Code Web、自定义 subagents、hooks、permissions、background tasks 这些线索里同时看到。

我的判断：Claude Code 正在变成严肃 agent 工作流的参考实现。一个真正有用的 coding agent 不能只有 prompt，还需要 runtime contract：它能使用哪些 skills，能连接哪些系统，能把任务委派给哪些 subagents，动作前后有哪些 hooks，permissions 如何拒绝危险工具，长会话如何汇报 progress，最终结果如何变成可 review 的 PR 或 diff。

几个 runtime 组件要分开看：

• Ready-to-run agent templates：Anthropic 在金融服务场景里把 agent template 拆成 skills、connectors 和 subagents，并通过 Claude Code plugins、Managed Agents cookbook 等形式交付。对 coding 工具的启发是：好用的 agent 会越来越像可安装的能力包，而不是一段临时 prompt。
• Agent connectivity 与 MCP tooling：Stainless 收购信息强调了一个现实判断：agent 的价值取决于它能安全连接什么系统。对工程团队来说，MCP servers 和 connectors 会成为 coding agent 连接 GitHub、Issue、文档、数据库、观测系统和内部 API 的集成层。
• Cloud / Web long-running sessions：Claude Code on the web 支持在浏览器里启动多个隔离 coding sessions、查看进度、主动 steering，并走向 PR 创建。这让 Claude Code 更像一个托管工作队列，而不只是本地终端助手。
• Subagents 与 Agent Teams：官方 subagents 文档强调独立上下文、受限 tool access、明确委派和模型选择。大任务最容易失败的地方是主 agent 丢失焦点，subagent 的价值就是先把责任拆开。
• Hooks、Permissions 与 agentic verification：hooks 和 Agent SDK permissions 形成动作前后的控制层。重点不是“多跑几个 shell hook”，而是有策略的验证：拒绝危险工具、要求审批、触发检查、让完成声明必须有证据。
• Background state management：subagents、hooks、background tasks、checkpoint 和 session recovery 让 Claude Code 更自主。但自主只有在状态可读时才有价值：当前 goal、progress、blocker、耗时、stale session、最终 wrap-up 都应该能被人看见。

如果要做企业内部 agent 平台，真正应该借鉴的不是某个 prompt 技巧，而是 runtime 边界。Skill、Tool、Channel、SubAgent、Hook、Permission、Ledger、Review 应该是一等概念。模型可以替换，运行时才决定 agent 工作能不能被治理。

适合谁

• 熟悉终端、Git 和代码审查的开发者。
• 已经有测试和 lint 的中大型项目。
• 能把需求写成验收条件、边界和约束的团队。
• 需要跨多个文件理解上下文、完成小任务的工程场景。
• 正在评估 Claude、Codex、opencode 这类 coding agent 的团队。
• 需要 managed settings、插件审查和可审计后台 agent 工作的团队。
• 正在设计内部 agent runtime 的平台团队，尤其是需要 skills、connectors、subagents、hooks、approval、progress ledger 和 PR handoff 的场景。

不适合谁

• 主要想要行内补全和可视化编辑体验的人。
• 没有测试、没有 lint、没有稳定验证方式的项目。
• 希望 AI 一次性完成大范围重构且不需要审查的团队。
• 对源码、密钥、配置权限没有清晰边界的敏感仓库。

它比 Cursor 强在哪里

Claude Code 更适合“任务型开发”。比如你说“修复这个测试失败，并说明原因”，它可以读取相关文件、修改代码、运行命令，再把结果交给你审查。Cursor 更像编辑器里的智能助手，Claude Code 更像可以执行一段开发流程的代理。

如果任务涉及多个文件、需要跑测试、需要读日志或理解项目结构，Claude Code 通常比纯编辑器交互更自然。

Cursor 仍然更好的地方

Cursor 的优势是即时、可视化、低摩擦。你正在读一段代码，选中几行，让它解释或改写，这种体验 Claude Code 不一定更好。

所以我不建议把两者看成非此即彼。更现实的组合是：Cursor 负责日常阅读、局部修改和快速交互；Claude Code 负责更完整的任务执行、修 bug、补测试和小范围重构。

Claude Code vs Codex vs opencode

Claude Code 和 Codex 都属于“把开发任务交给 agent”的方向。选择时不要只看品牌，要看三件事：它在你的代码库上表现如何、权限模型是否能被团队接受、生成的 diff 是否容易审查。

opencode 是更值得关注的开源对照组。如果你重视可检查性、模型选择和终端工作流控制，opencode 很有吸引力。Claude Code 更像成熟商业产品，opencode 更像能被团队自己改造的工作流底座。

插件、Skills 与 Superpowers

2026 年 Claude Code 最值得关注的扩展方向，不是“再多几个提示词”，而是“把开发流程管住”。模型已经足够会写代码，真正的问题是：它会不会先澄清需求、会不会写计划、会不会先写测试、遇到错误会不会定位根因、说完成前有没有跑验证、最后能不能留下可维护的上下文。

这就是 Superpowers 值得单独介绍的原因。CodeLove 这篇文章 讲到一个很真实的问题：很多人用 AI 写代码，仍然停留在“提需求、等结果、复制、报错、再改”的循环里。Superpowers 想改变的不是某一个功能，而是整个合作方式：设计、计划、测试、质量。我的判断是，它不是普通插件，更像是 Claude Code 的开发流程框架。

看一份“20 个 skills 推荐清单”时，我不建议照单全装。更好的问题是：你的 agent 工作流哪一层最弱？没有测试的个人项目，应该先补验证、调试和审查；已经有 CI 的团队，可能更需要 code review、worktree 隔离和领域型 skills。

Superpowers 里最核心的几个 Skills：

• find-skills 与 skill-installer：负责发现和安装 skills。随着生态变多，靠记忆管理会越来越不现实。
• brainstorming：在写代码前先停下来，把需求、约束、方案选择问清楚。
• writing-plans：把已经确认的设计拆成可执行计划，通常保存到 docs/superpowers/plans/。
• subagent-driven-development 或 executing-plans：按计划拆小步执行，避免一个长会话直接改完整个仓库。
• test-driven-development：要求先写失败测试，再写最小实现，再重构，而不是写完代码再想测试。
• systematic-debugging：遇到 bug 或测试失败时先定位根因，避免 AI 看到报错就猜着改。
• verification-before-completion：阻止“AI 说完成就算完成”，必须跑测试、lint、build 或对应验证命令。
• requesting-code-review 与 receiving-code-review：把代码审查变成明确流程，而不是最后随便看一眼。
• using-git-worktrees：把并行任务或高风险修改隔离到独立工作区，减少互相污染。
• finishing-a-development-branch：完成后明确选择合并、开 PR、保留分支或丢弃，而不是停在“代码写完了”。

我的评价：Superpowers 适合已经相信工程流程重要的团队。它会让一次任务看起来多几个步骤，但这些步骤是在减少返工、减少猜测、减少没人能解释的 AI diff。只做一两行小改时它可能显得重；做真实产品功能、重构、bug 修复时，它的价值会明显很多。好的 skill 会让 Claude Code 在正确的时刻慢下来：范围扩大前、bug 修复变成猜测前、AI 宣称完成前、大 diff 合并进主分支前。

更宽泛的 skill 生态也值得看，但我会按“证据价值”排序：

• 前端与浏览器 skills：浏览器自动化、截图验证、可访问性检查和视觉回归，适合那些必须在真实 viewport 里判断好坏的页面。
• 内容、SEO 与文档 skills：适合静态站、文档站、发布说明和工具对比页，可以减少薄内容和结构混乱。
• 数据库、云服务与基础设施 skills：只有在权限边界、dry-run 和回滚路径清楚时才值得用。这类 skill 很省时间，但影响面也更大。
• 审查、分支与协作 skills：团队价值最高，因为它们能把 agent 产出变成可追踪、可审查的工程交付物。

其他 Claude Code 插件和扩展，我会按层次来评估：

• 工作流插件：类似 Superpowers，定义 Claude Code 从想法到验证完成应该怎么走。
• 工具访问插件与 MCP servers：连接 GitHub、Issue 系统、文档、数据库、浏览器或内部系统。重点不是能连多少工具，而是权限边界和审计是否清楚。
• 质量与审查插件：围绕测试覆盖率、lint、安全检查、依赖扫描、代码审查做增强。
• 领域 Skills：面向 API 文档、数据库迁移、数据管道、UI 实现、发布说明、事故排查等具体任务。
• IDE 表层插件：把 Claude Code 带进 VS Code 或其他编辑器界面，让 diff 和交互更可见，但不能替代验证流程。

采用规则很简单：优先安装能减少歧义、增加证据、提高可审查性的插件。只让 Claude Code 更快地做更多事、但不提升 review 能力的插件，我会谨慎。

如果问题是成本和额度，我会把 9Router 单独拿出来评估。Superpowers 管的是 Claude Code 如何工作；9Router 管的是请求发到哪里、冗余工具输出怎么压缩、主力模型额度耗尽或报错时怎么 fallback。重度 Claude Code 用户往往需要这两层一起看。

来源说明

• Anthropic 的 Claude Code changelog 记录了 Claude Code 2.1.142 到 2.1.145 的更新，包括 claude agents --json、OTEL agent identifiers、GitHub repo 和 PR 状态上下文、plugin dependency visibility、MCP/LSP 安装前预览、background session 恢复、context-cost display 和 worktree 修复。
• Anthropic 的 Claude Code commands、CLI reference、permission modes、hooks、permissions、MCP 和 subagents 文档说明了 /init、/memory、/permissions、/agents、/mcp、/hooks、/plugin、/resume、/context、/compact、claude --permission-mode plan，以及 default、acceptEdits、plan、auto、dontAsk、bypassPermissions 的操作取舍。
• Anthropic 的 Claude Fable 5 与 Claude Mythos 5 公告、Fable 产品页 和 Claude Code 模型配置文档描述了 Fable 5 作为当前广泛发布的最强模型，在 Claude Code 里通过 /model fable 使用，适合长时间 coding 和知识工作，并说明了 1M context、fallback safeguards、版本要求、价格和数据保留限制。Anthropic 同时说明 Claude Fable 5 access 已在 2026 年 6 月 12 日因为 classifier calibration issues 暂停，所以本站把 Fable 当成待恢复后再评测的 watch item。
• OpenAI 的 ChatGPT 与 Codex release notes 说明了 2026 年 6 月中旬 Codex 更新，包括 rate limit resets bank、Codex 可用地区扩展、历史 Codex threads 搜索、CLI/IDE/cloud tasks 同步 model 与 reasoning effort、remote session 错误可见性提升，以及 multi-repository tasks。这些更新是本页关联 Claude Code 与 Codex 的依据。
• Anthropic 的 Claude Opus 4.8 公告 说明了 2026 年 5 月 28 日的模型发布、coding 定位、企业可用性和 Claude Code effort modes。
• Claude 的 Dynamic Workflows in Claude Code 介绍了并行 specialized subagents、长时间 coding workflows、大规模迁移、依赖升级、issue triage 和 PR 导向的工作方式。
• Anthropic 金融服务 agent 材料描述了由 skills、connectors 和 subagents 组成的 ready-to-run agent templates，并通过 Claude Code plugins 和 managed-agent 模式交付。
• Anthropic 收购 Stainless 的文章强调 agent connectivity、SDK、CLI、API 文档和 MCP server tooling 是有用 agent 系统的重要部分。
• Claude 的 Claude Code on the web 介绍了浏览器启动的隔离 coding sessions、进度可见、主动 steering 和 PR 导向的云端工作。
• Anthropic 的 Claude Code subagents 文档 说明了自定义 subagents 的独立上下文、受限工具、模型选择和任务委派。
• Anthropic 的 Claude Code hooks 与 Agent SDK permissions 文档说明了 hooks、allow/deny rules、permission modes 和 runtime callbacks 如何控制 agent 行为。
• Anthropic 的 enterprise managed settings 文档 说明了组织级 Claude Code 配置方式。
• Anthropic 的 Claude Code security preview 介绍了 web 执行、安全研究、prompt-injection 缓解、network allowlist 和 sandboxing 相关工作。

采用建议

• 给项目写清楚开发约定：架构、测试命令、代码风格、禁止修改的区域。
• 先让 Claude Code 做小任务，不要一上来交给它大重构。
• 每次都要求它先说明计划，再开始改文件。
• 把测试、lint、类型检查命令放到项目说明里。
• 所有 diff 都按正常代码审查处理，不要因为是 AI 写的就降低标准。

质量判断

Claude Code 好不好，不看它写了多少代码，而看它能不能持续产出小而清晰、能通过验证、符合项目风格的 diff。

最危险的信号是“速度很快但没人能解释”。如果团队开始合并自己都讲不清楚的 AI 改动，效率提升很快会变成技术债。