Claude Code on KnightLi的博客

Claude Opus 4.8 发布：Anthropic 继续强化编程与代理任务

Fri, 29 May 2026 15:22:47 +0800

Anthropic 在 2026 年 5 月 28 日发布 Claude Opus 4.8。这是 Opus 系列的新版本，官方定位很明确：不是一次换代式命名，而是在 Opus 4.7 基础上继续增强编程、代理任务、推理和专业知识工作能力。

这次更新对普通聊天用户当然有意义，但更值得关注的是 Claude Code 和长任务 agent 场景。Anthropic 把 Opus 4.8 描述成更可靠的协作者：在复杂任务里更能判断何时提问、何时推进、何时保守处理。

这次更新的重点

Claude Opus 4.8 已经上线，价格保持不变。官方同时强调了几项配套变化：

Opus 4.8 在代码、代理能力、推理和知识工作评测上相比前代继续提升。
claude.ai 用户可以控制 Claude 在任务上投入的 effort。
Claude Code 新增 dynamic workflows，用来处理更大规模的问题。
Opus 4.8 的 fast mode 可以以约 2.5 倍速度工作，并且比此前模型的 fast mode 便宜三倍。

这些变化放在一起看，Anthropic 不是只在模型分数上做小幅升级，而是在围绕“长时间执行复杂任务”改产品形态。模型更强只是其中一部分，任务控制、工作流拆解和成本结构同样重要。

为什么 Claude Code 用户更应该关注

Claude Code 这类编程 agent 最怕的不是单个函数不会写，而是在真实仓库里迷路。它需要读文件、理解依赖、跑测试、看错误、修改方案，再把修改控制在合理范围内。

Opus 4.8 的卖点正好贴近这些问题：

更适合 agentic tasks，也就是需要模型持续计划、调用工具、观察结果并调整策略的任务。
更强调 judgement，能在不确定时停下来确认，而不是一路自信地写错。
dynamic workflows 让 Claude Code 更适合处理大规模、多步骤的问题。

如果这些能力在真实项目里稳定，Claude Code 的使用方式会更接近“把一个明确目标交给它推进”，而不是只让它补一段代码。

effort 控制意味着什么

Anthropic 这次给 claude.ai 加入 effort 控制，含义很直接：用户可以调节模型在任务上花多少力气。

这对日常使用很实用。简单问题不需要深推理，复杂任务则值得让模型多想一会儿。过去很多用户只能靠提示词表达“认真一点”或“快速回答”，现在这种控制开始进入产品层。

对开发者来说，这也是一个信号：未来 agent 产品不会只暴露“选哪个模型”，还会暴露更多执行策略，比如速度、成本、推理深度、工具调用积极程度和风险偏好。

fast mode 的成本变化很关键

官方提到，Opus 4.8 的 fast mode 可以达到约 2.5 倍速度，同时成本比此前模型的 fast mode 低很多。

这件事容易被模型能力新闻盖过去，但它对实际工作流很重要。很多 agent 任务不是只跑一次，而是会反复执行：

生成初稿
跑测试
修复失败
再跑测试
根据 review 继续改

如果 fast mode 足够便宜，团队就更愿意把它放进高频流程里，而不是只在关键任务上偶尔使用顶级模型。速度和成本一旦下降，agent 才更容易从“演示效果”进入“日常工具”。

和 Opus 4.7 的关系

Opus 4.8 更像是一次面向可用性的增强版。它继承 Opus 4.7 的定位，但把重点继续推向编程、代理任务和专业工作。

从 Anthropic 的表述看，Opus 4.8 不只是回答更好，而是更会协作。它在任务中应该更清楚什么时候需要信息、什么时候方案不稳、什么时候应该先建立信心再做大改动。

这类能力很难只靠单一 benchmark 判断。真正的验证要看它在大型仓库、复杂业务规则、长上下文任务和多轮修复里的表现。

对 AI 编程竞争的影响

2026 年的模型竞争已经明显从“聊天能力”转向“能不能做事”。OpenAI、Anthropic、Google、xAI 都在把模型和工具链绑得更紧：模型负责推理，工具负责执行，产品层负责把任务保持在可控范围内。

Claude Opus 4.8 的发布延续了这个趋势。它的重点不是炫耀一个单点能力，而是强化三个环节：

模型本身更适合代码和代理任务。
Claude Code 能拆更大的工作流。
产品层开始提供 effort 和 fast mode 这类执行控制。

这对开发者的实际意义是，选择模型时不能只看“哪个最聪明”。还要看它是否适合所在工具、能否稳定调用工具、长任务成本是否可接受、失败时是否容易被纠正。

我的判断

Claude Opus 4.8 是一次偏务实的更新。它没有把叙事放在一个夸张的新参数上，而是继续补 agent 工作流最需要的东西：判断力、稳定性、速度、成本和任务控制。

如果你已经在使用 Claude Code，这次更新值得尽快试。尤其适合拿真实仓库里的长任务做对比，比如跨模块重构、测试修复、文档同步、复杂 bug 定位。

如果你只是普通聊天用户，Opus 4.8 的变化可能不会像新一代模型发布那样立刻震撼。但从产品方向看，它说明 Anthropic 仍在把 Claude 往“可靠执行复杂工作”的方向推。

原文链接：Introducing Claude Opus 4.8

CLIProxyAPI：把 Codex、Claude Code、Gemini CLI 统一封装成 API

Sun, 24 May 2026 10:03:33 +0800

CLIProxyAPI 是一个很有“民间工程味”的项目：它不是再造一个大模型，也不是单纯做 API 转发，而是把一堆原本偏交互式、偏 CLI、偏 OAuth 登录的 AI 工具，重新包成统一 API 服务。

它支持的对象包括 Gemini CLI、OpenAI Codex、Claude Code、Amp CLI、AI Studio Build，以及上游 OpenAI 兼容服务。换句话说，它想解决的问题是：

我手上有 CLI 工具、有订阅账号、有 OAuth 登录态，能不能像调用普通 API 一样，把这些能力接到自己的客户端、脚本、IDE 或内部服务里？

CLIProxyAPI 给出的答案是：可以，中间加一层代理，把不同来源的 CLI 能力转换成 OpenAI、Gemini、Claude、Codex 兼容接口。

它真正解决的痛点

很多 AI 编程工具的能力本来很强，但默认使用方式并不适合自动化。

比如：

Gemini CLI 能登录账号使用，但你的程序更习惯调用 HTTP API。
Claude Code 很适合交互式编码，但接入其他客户端时会遇到协议不一致。
Codex CLI 支持 OAuth 登录和 Responses 风格能力，但不是所有上层工具都知道怎么和它说话。
一个团队可能有多个账号，需要轮询、负载均衡、异常账号剔除和配额观察。
你想让某些工具只认 OpenAI 格式，但后端实际可能是 Gemini、Claude 或 Codex。

CLIProxyAPI 的定位，就是做这些工具和客户端之间的“协议适配层”。

它把复杂的一侧藏在后面：OAuth、CLI 登录、多账号、不同协议、不同 provider。前面则暴露相对熟悉的接口，比如 OpenAI Chat Completions、OpenAI Responses、Gemini、Claude Messages、Codex 相关端点。

能力概览

从官方 README 和文档看，CLIProxyAPI 目前的核心能力包括：

为 CLI 模型提供 OpenAI、Gemini、Claude、Codex 兼容 API 端点。
通过 OAuth 登录接入 OpenAI Codex 和 Claude Code。
支持流式、非流式响应，以及部分场景下的 WebSocket。
支持函数调用、工具调用和多模态输入。
支持 Gemini、OpenAI、Claude 多账号轮询与负载均衡。
支持 Gemini AI Studio API Key。
支持 AI Studio Build、Gemini CLI、Claude Code、OpenAI Codex 的多账号池。
可以通过配置接入 OpenAI 兼容上游，比如 OpenRouter。
提供 Go SDK，方便把代理能力嵌入到自己的服务里。

这类项目最有价值的地方，不是“多支持几个模型名”，而是把账号登录、协议转换和请求路由这些琐碎工作打包起来。

它适合谁用

CLIProxyAPI 更适合下面几类人：

第一类是重度 AI 编程用户。你已经在用 Codex、Claude Code、Gemini CLI，但想把它们接到 Cursor、Cline、RooCode、Amp、内部脚本或自建工作流里。

第二类是有多账号池的人。比如你有多个 Gemini、OpenAI、Claude 登录态，不想手工切换，希望自动轮询、均衡使用、遇到异常账号时能快速排查。

第三类是做团队内部网关的人。团队不希望每个客户端都分别适配 Gemini、Claude、Codex，而是想通过一个中间层统一暴露 API。

第四类是喜欢折腾协议的人。你可能关心 Responses、Chat Completions、Claude Messages、Gemini v1beta 这些接口如何互相转换，也可能希望在同一套客户端里切换不同后端。

如果只是个人偶尔问几句 AI，或者只用官方 App 聊天，那 CLIProxyAPI 的部署和维护成本就显得重了。

和普通 API 中转有什么不同

普通 API 中转服务一般是：

`1`	`客户端 -> 中转 API -> 上游模型 API`

CLIProxyAPI 的链路更像：

`1`	`客户端 -> CLIProxyAPI -> CLI / OAuth 登录态 / 多账号池 -> 模型服务`

区别在于，它处理的不只是 API Key 转发，还包括 CLI 工具、OAuth 账号、协议表面和模型别名。

比如 Codex 和 Claude Code 这类工具，本身就不是传统意义上“拿一个 API Key 就能稳定调用”的模式。CLIProxyAPI 把这些登录态和调用逻辑包装起来，让外部客户端像调用 API 一样访问它们。

这也是它吸引人的地方，同时也是它复杂的地方。

使用时最容易误解的地方

第一，不要以为统一 /v1/... 就能解决所有协议差异。

CLIProxyAPI 文档里专门提醒过：当你需要某一类后端的请求和响应形态时，优先使用 provider-specific 路径。例如 messages 风格用 /api/provider/{provider}/v1/messages，Gemini 模型路径用 /api/provider/{provider}/v1beta/models/...，chat-completions 风格用 /api/provider/{provider}/v1/chat/completions。

统一入口方便，但不同协议的语义并不会凭空消失。工具调用、流式返回、多模态输入、系统消息处理，都可能因为后端不同而有细节差异。

第二，模型名不等于唯一后端。

如果多个后端暴露了相同的客户端可见模型名，仅靠路径不一定能锁定真正执行推理的那个后端。要严格固定后端，最好使用唯一 alias、前缀，或者避免让多个后端暴露同名模型。

第三，多账号轮询不是无限额度。

轮询只能更均匀地使用账号池，不能绕过上游服务的真实限制。账号异常、配额耗尽、风控、OAuth 失效，都需要单独监控。

第四，它不是免维护魔法盒。

一旦你把它放进日常工作流，就要关心配置、日志、上游账号状态、版本升级、客户端兼容性和安全边界。

管理和监控怎么办

官方 README 提到，从 v6.10.0 开始，CLIProxyAPI 和 CPAMC 不再预置数据统计功能。如果需要使用量统计，可以配合独立项目：

CPA Usage Keeper：同步 CLIProxyAPI 数据，存到 SQLite，并提供聚合 API 和仪表盘。
CLIProxyAPI Usage Dashboard：本地优先的用量与配额看板，可展示账号、模型、时间窗口和 Codex 配额余量。
CPA-Manager：更完整的管理中心，面向请求监控、费用估算、账号池巡检、异常账号定位和清理建议。

这说明 CLIProxyAPI 的核心更偏“代理和协议层”，而不是一站式商业管理后台。如果是团队使用，最好一开始就把日志、监控和账号池管理考虑进去。

一个比较合理的使用姿势

如果要试用，可以按这个顺序来：

先用官方文档的 Quick Start 跑起来。
只接一个 provider，比如 Gemini CLI 或 Codex，确认基本请求能通。
再测试流式响应、工具调用、多模态输入这些高风险能力。
确认客户端实际使用的是哪个 endpoint，不要混用协议路径。
最后再加入多账号轮询、管理面板和用量统计。

不要一上来就把 Gemini、Codex、Claude、OpenRouter、多账号和所有客户端全接进去。这样出错时很难判断是认证问题、协议问题、模型名问题，还是上游账号问题。

安全边界也要想清楚

CLIProxyAPI 会接触到账号登录态、API Key、OAuth 相关凭据和请求内容。它如果只跑在自己机器上，风险相对可控；如果暴露到公网或团队内网，就必须认真处理认证、访问控制、日志脱敏和网络隔离。

尤其是管理端点，最好只允许本机或可信内网访问。不要为了省事直接把管理接口裸露出去。

总结

CLIProxyAPI 的价值在于，它把原本散落在多个 CLI、多个账号、多个协议里的 AI 能力，收拢成一个可编程的 API 层。

它适合重度 AI 编程用户、多账号用户和团队内部网关场景；不太适合只想“开箱即用、完全无维护”的轻量用户。

如果你正在折腾 Codex、Claude Code、Gemini CLI 这些工具，并且希望把它们接进自己的客户端或自动化工作流里，CLIProxyAPI 值得认真看一眼。但要把它当基础设施来用，而不是当一次性小工具来用。

参考资料：

CodeGraph 是什么？给 Claude Code、Codex 和 Cursor 加一个本地代码地图

Sat, 23 May 2026 21:09:46 +0800

CodeGraph 是一个给 AI 编程工具使用的本地代码知识图谱。它会提前给项目建立索引，把符号关系、调用图、代码结构、路由关系等信息整理成可查询的图，让 Claude Code、Codex CLI、Cursor、OpenCode、Hermes Agent 这类工具不用每次都靠 grep、glob、Read 和子代理到处翻文件。

它解决的是一个很实际的问题：AI Agent 看大型代码库时，很多成本不是花在真正修改代码上，而是花在“找代码在哪里”。如果每次都重新搜索、读取、筛选，token、时间和工具调用都会被消耗掉。CodeGraph 的思路是先把代码库变成一张本地地图，让 Agent 先问地图，再决定要不要读具体文件。

它主要解决什么痛点

AI 编程工具在小项目里通常还好，文件少，搜索快，读一遍也不贵。但项目一大，常见问题就会出现：

Agent 为了理解一个模块，反复调用 grep、find、ls、Read。
探索子代理读了很多无关文件，主任务上下文却没有变清楚。
问一个架构问题时，token 大量花在定位文件上。
改一个函数前，不知道谁在调用它、它又调用了谁。
Web 项目里，URL 路由和实际处理函数之间的关系不够直观。

CodeGraph 试图把这些“先找路”的工作前置。项目索引建好后，Agent 可以直接查询相关符号、调用方、被调用方、影响范围和代码片段。

安装方式

项目提供跨平台安装脚本，不要求用户自己准备 Node.js：

`1`	`curl -fsSL https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.sh \| sh`

Windows PowerShell 可以使用：

`1`	`irm https://raw.githubusercontent.com/colbymchenry/codegraph/main/install.ps1 \| iex`

如果已经有 Node 环境，也可以直接用 npm：

`1`	`npx @colbymchenry/codegraph`

或者全局安装：

`1`	`npm i -g @colbymchenry/codegraph`

安装器会自动检测并配置已安装的 Agent，例如 Claude Code、Cursor、Codex CLI、opencode 和 Hermes Agent。它会写入对应的 MCP server 配置和指令文件，让这些工具知道什么时候调用 CodeGraph。

初始化项目

安装完成后，需要在目标项目里建立索引：

1
2

cd your-project
codegraph init -i

这个命令会生成项目级知识图谱索引。README 中提到，只要项目里存在 .codegraph/ 目录，Agent 就可以自动使用 CodeGraph 工具。

如果不想继续使用，也可以卸载全局配置：

`1`	`codegraph uninstall`

它会移除安装器写入的 MCP server 配置、指令和权限。项目中的 .codegraph/ 索引不会被自动删除，如果要移除项目索引，需要使用 codegraph uninit。

为什么它对 Agent 有用

Claude Code、Codex CLI、Cursor 这类工具在理解代码库时，常常会先做探索：找文件、读入口、查引用、再追调用链。这个过程对人来说像“翻项目”，对模型来说就是一串工具调用和上下文消耗。

CodeGraph 把这一步变成索引查询。Agent 可以先用 codegraph_context 找到相关入口、符号和片段，再用 codegraph_explore 或其他工具读取必要内容。这样做的好处是：

少读无关文件。
少调用搜索工具。
更快找到真正相关的代码。
改动前更容易看清影响范围。
大型仓库里的架构问题更容易回答。

项目 README 给出的基准测试显示，在 7 个真实开源代码库上，对比启用 CodeGraph 和不启用 CodeGraph，平均结果是成本更低、token 更少、速度更快、工具调用更少。具体数字会受项目规模、语言、问题类型和 Agent 使用方式影响，但方向很清楚：越大的仓库，预索引的价值越明显。

核心能力

1. 智能上下文构建

一个工具调用可以返回入口点、相关符号和代码片段，减少 Agent 先派一堆探索任务再慢慢筛选的情况。对架构理解、模块定位、功能入口分析很有用。

2. 全文搜索

CodeGraph 使用 FTS5 做全文搜索，可以在整个代码库里快速按名称和文本查找代码。这不是替代所有 grep 场景，而是让 Agent 有一个更结构化的第一站。

3. 影响分析

在改函数、类、方法或路由前，可以查询 callers、callees 和影响半径。对重构、修 bug、删除旧代码尤其有用，因为最怕的就是只改了当前文件，却漏掉上游或下游调用。

4. 自动保持新鲜

README 中提到，CodeGraph 使用原生文件系统事件，例如 FSEvents、inotify、ReadDirectoryChangesW，并带有 debounce auto-sync。意思是索引会随着本地代码变化自动更新，不需要每改一个文件都手动重建。

5. 多语言支持

项目列出的支持范围超过 19 种语言，包括 TypeScript、JavaScript、Python、Go、Rust、Java、C#、PHP、Ruby、C、C++、Swift、Kotlin、Dart、Lua、Luau、Svelte、Liquid、Pascal / Delphi 等。

这让它更适合多语言仓库和全栈项目，而不是只服务某一种语言。

6. Web 路由感知

CodeGraph 还会识别多种 Web 框架里的路由文件和路由声明，把 URL pattern 和处理函数连接起来。README 中提到的框架包括 Django、Flask、FastAPI、Express、NestJS、Laravel、Rails、Spring、Gin、Axum、ASP.NET、Vapor、React Router、SvelteKit 等。

这点很实用。很多 Web 项目的真实入口不是某个明显的 main 函数，而是路由、controller、handler、view 或 resolver。Agent 如果能先知道 URL 到处理函数的关系，理解业务流程会快很多。

本地优先的设计

CodeGraph 强调 100% local。它不需要 API key，不依赖外部服务，索引数据保存在本地 SQLite 数据库里。

对企业项目、私有仓库或敏感代码来说，这个设计很重要。AI 工具接入代码库时，大家最担心的往往不是“能不能查到代码”，而是“代码结构和索引会不会被发出去”。CodeGraph 的定位是本地构建、本地查询、本地服务 Agent。

当然，本地也意味着要考虑磁盘空间、索引时间、文件监听和项目规模。如果仓库特别大，第一次初始化和后续同步仍然需要资源。

适合哪些场景

CodeGraph 更适合这些场景：

大型代码库，经常需要问架构和调用链问题。
使用 Claude Code、Codex CLI、Cursor 等 Agent 做代码理解和修改。
希望减少 Agent 到处读文件、乱搜、反复探索。
需要在改动前分析影响范围。
Web 项目路由复杂，需要快速从 URL 找到处理函数。
团队希望给 AI Agent 一个更稳定的本地项目索引。

如果只是几十个文件的小项目，普通搜索已经够快，CodeGraph 的优势可能不明显。它最有价值的地方，是中大型代码库和经常让 Agent 做探索的场景。

使用时要注意什么

第一，CodeGraph 不是替代代码审查和测试的工具。它能帮助 Agent 更快找到相关代码，但不能保证 Agent 的修改一定正确。

第二，索引质量会影响使用效果。项目结构复杂、生成代码很多、语言混杂或 build 产物没有排除时，索引可能会变得臃肿。使用前最好确认 .gitignore、项目目录和索引范围是否合理。

第三，MCP 配置和 Agent 指令很关键。README 里也提醒，CodeGraph 只有在被正确查询时才有帮助。如果 Agent 仍然绕开它去大量读文件，预索引就会变成额外开销。

第四，虽然它是本地工具，也要注意权限。安装器会写入 Agent 配置和权限列表，团队环境中最好统一审查这些配置。

小结

CodeGraph 的价值可以简单理解为：给 AI Agent 一张本地代码地图。它不是让模型更聪明，而是让模型少迷路。

当 Claude Code、Codex CLI、Cursor 这类工具面对大型仓库时，最耗费上下文的往往是探索过程。CodeGraph 用预索引的符号关系、调用图、路由图和全文搜索，把“找代码”这一步提前做好，让 Agent 把更多预算花在理解和修改上。

如果你已经在真实项目里使用 AI 编程工具，并且经常遇到“它读了一堆文件还是没找到重点”的情况，CodeGraph 值得试一下。它代表了 AI 编程工具的一个重要方向：不只是换更强的模型，也要给模型更好的本地代码上下文。

参考资料：

GitHub 项目：https://github.com/colbymchenry/codegraph

Claude Code 也有插件市场了：能装什么、怎么装、要注意什么

Sat, 23 May 2026 19:03:30 +0800

anthropics/claude-plugins-official 是 Anthropic 管理的 Claude Code 官方插件目录。它不是一个普通代码库，而是一个可被 Claude Code 插件系统直接使用的 marketplace，集中放置经过 Anthropic 维护或筛选的 Claude Code 插件。

这个仓库值得关注，是因为 Claude Code 正在从“一个 AI 编程命令行工具”变成“可扩展的开发环境”。插件可以把 Skills、Agents、Hooks、MCP servers、LSP servers、后台监控和默认设置打包起来，让团队或社区用统一方式分发。

这个仓库是什么

仓库 README 对它的定位很直接：这是一个高质量 Claude Code 插件的 curated directory。

目录主要分成两块：

/plugins：Anthropic 内部开发和维护的插件。
/external_plugins：来自合作伙伴和社区的第三方插件。

也就是说，它既包含官方能力，也包含经过收录的外部生态入口。对普通用户来说，最直接的意义是可以通过 Claude Code 的 /plugin 系统发现和安装插件；对开发者来说，它提供了观察 Claude Code 插件格式和生态方向的窗口。

如何安装插件

README 给出的安装方式很简单。可以直接通过 Claude Code 的插件系统安装：

`1`	`/plugin install {plugin-name}@claude-plugins-official`

也可以在 Claude Code 里打开插件发现入口：

`1`	`/plugin > Discover`

这里的关键点是 @claude-plugins-official。它代表官方插件目录这个 marketplace。根据 Claude Code 文档，claude-plugins-official 是 Anthropic 维护的官方 marketplace，并且会在 Claude Code 安装中默认可用。

插件长什么样

仓库 README 给出了标准插件结构：

plugin-name/
├── .claude-plugin/
│   └── plugin.json
├── .mcp.json
├── commands/
├── agents/
├── skills/
└── README.md

其中 .claude-plugin/plugin.json 是插件元数据文件，通常用来声明插件名、描述、版本、作者等信息。其他目录则按需存在：

skills/：放 Claude 可自动调用的技能说明。
commands/：放 slash commands。
agents/：放自定义 agent 定义。
hooks/：放事件触发逻辑。
.mcp.json：配置 MCP server。
.lsp.json：配置语言服务器。
monitors/：配置后台监控。
settings.json：给插件附带默认设置。

这说明 Claude Code 插件不是单一类型扩展，而是一种打包格式。它可以只是一个小命令，也可以是一整套面向某个技术栈的工作流。

官方目录里已经有哪些方向

从 /plugins 目录看，官方维护插件覆盖了不少开发场景，包括：

LSP 类插件：typescript-lsp、pyright-lsp、rust-analyzer-lsp、gopls-lsp、clangd-lsp、csharp-lsp、jdtls-lsp、kotlin-lsp、lua-lsp、php-lsp、ruby-lsp、swift-lsp。
编程工作流：code-review、feature-dev、code-modernization、code-simplifier、commit-commands、pr-review-toolkit。
Claude Code 配置和插件开发：claude-code-setup、claude-md-management、plugin-dev、skill-creator、mcp-server-dev。
输出风格和专项能力：explanatory-output-style、learning-output-style、security-guidance、session-report、math-olympiad。

/external_plugins 里则能看到更多第三方工具和服务方向，例如 github、gitlab、linear、asana、firebase、playwright、terraform、context7、serena、telegram、discord 等。

这组插件透露出一个趋势：Claude Code 不只是想帮你改文件，还想接入代码智能、项目管理、云服务、测试、基础设施和团队协作工具。

为什么插件系统重要

过去很多 Claude Code 自定义能力都可能散落在项目里的 .claude/ 目录中，比如 commands、agents、skills 或 hooks。这种方式适合个人或单个项目，但不方便跨项目复用，也不方便团队统一分发和更新。

插件解决的是可复用和可分发问题：

同一套配置可以跨多个项目安装。
命令和技能有命名空间，减少冲突。
插件可以通过 marketplace 发布和更新。
团队可以把内部最佳实践打包成标准插件。
社区可以围绕某个框架、语言或服务维护专门扩展。

这和 VS Code 插件、JetBrains 插件、浏览器扩展的思路类似：当一个工具开始有稳定插件生态，它就不再只是单一产品，而是在形成平台。

对开发者有什么用

如果你只是 Claude Code 用户，这个仓库最实用的地方是找插件。比如需要 TypeScript、Python、Rust 或 Go 的 LSP 能力，可以先看官方目录里是否已有对应插件；需要 PR review、commit、代码现代化等工作流，也可以从官方插件开始试。

如果你是插件开发者，这个仓库更像样板库。你可以参考它的目录组织、plugin.json 写法、README 说明方式，以及 Anthropic 如何把 skills、agents、MCP、LSP 和 hooks 组合起来。

Claude Code 文档也明确建议：如果只是单项目自定义，可以先用 .claude/；如果需要分享给团队、跨项目复用、版本化发布，或者进入 marketplace，就应该做成插件。

安全边界不能忽略

仓库 README 在开头就提醒：安装、更新或使用插件前必须信任该插件。原因很简单，插件可能包含 MCP server、文件、脚本或其他软件。Anthropic 维护目录，不等于能保证每个插件在你的本地环境中都按你预期运行。

实际使用时建议至少做几件事：

安装前看插件主页和 README。
检查是否包含 .mcp.json、hooks、可执行脚本或后台监控。
对需要访问账号、代码仓库、聊天工具、云服务的插件格外谨慎。
在重要项目中启用插件前，先在测试仓库验证。
团队环境最好统一审核插件来源和版本。

AI 编程插件的权限往往比普通编辑器主题高得多。它可能能读项目文件、调用外部服务、启动本地命令，甚至影响提交和部署流程，所以信任边界要比“装一个小工具”更严格。

和社区 marketplace 的关系

Claude Code 文档提到，Anthropic 维护两个公开插件 marketplace：

claude-plugins-official：Anthropic 维护的 curated 插件集合。
claude-community：第三方提交后进入审查流程的社区插件目录。

这两者的定位不同。社区插件可以通过提交表单进入 review；官方目录则由 Anthropic 自行决定是否收录，没有普通申请流程。换句话说，claude-plugins-official 更像官方精选目录，claude-community 更像开放社区目录。

小结

anthropics/claude-plugins-official 的意义不只是“多了一个 GitHub 仓库”。它说明 Claude Code 的扩展机制正在平台化：Skills、Agents、Hooks、MCP、LSP、后台监控和默认设置都可以被打包、安装、更新和分发。

对个人开发者来说，官方插件目录能降低配置 Claude Code 的门槛。对团队来说，它提供了把内部流程标准化的路径。对插件开发者来说，它给出了 Anthropic 认可的插件结构和生态方向。

接下来值得关注的不是某一个插件本身，而是 Claude Code 插件生态会不会形成稳定分层：官方精选、社区插件、团队私有 marketplace，以及围绕主流语言、框架和 SaaS 服务的专门扩展。如果这条路线走通，Claude Code 会越来越像一个可编排的 AI 开发平台，而不只是一个命令行助手。

参考资料：

GitHub 项目：https://github.com/anthropics/claude-plugins-official
Claude Code 插件文档：https://code.claude.com/docs/en/plugins

Graphify 解决 Claude Code 最大局限：把代码库变成 AI 可查询知识图谱

Thu, 21 May 2026 08:02:32 +0800

safishamsi/graphify 是一个面向 AI 编程助手的知识图谱工具。它的目标很直接：把一个项目目录里的代码、文档、SQL schema、脚本、论文、图片、视频和音频，整理成可查询的知识图谱，让 AI 助手不再只靠 grep、全文阅读或临时搜索来理解项目。

项目地址：safishamsi/graphify

截至本文整理时，GitHub 页面显示项目约有 50.2k stars、5.4k forks，许可证为 MIT。README 对它的描述是：在 AI 编程助手里输入 /graphify，它就会把整个项目映射成一个可以查询的知识图谱。

它解决的核心问题

AI 编程助手越来越强，但在真实代码库里仍然经常遇到几个问题：

不知道关键模块之间怎么连接。
读了很多文件，但没形成整体架构地图。
搜索命中了文本，却不知道上下游依赖。
代码、数据库 schema、文档和基础设施配置分散在不同地方。
多人协作时，每个人对项目结构的理解不一致。

Graphify 想做的是给项目生成一层“记忆层”。它把代码实体、文档概念、数据库表、配置、设计说明和跨文件关系连接起来，让 AI 助手可以按图谱查询，而不是每次从零开始扫文件。

最小使用方式

Graphify 的最小用法非常简单。安装后，在 AI 编程助手里输入：

`1`	`/graphify .`

在 PowerShell 里要注意，前导 / 会被当成路径分隔符，所以 Windows PowerShell 下应使用：

`1`	`graphify .`

运行后会生成 graphify-out/ 目录，核心文件包括：

graphify-out/
├── graph.html
├── GRAPH_REPORT.md
└── graph.json

这三个文件分工不同：

graph.html：浏览器里打开的交互式图谱，可以点击节点、过滤和搜索。
GRAPH_REPORT.md：项目亮点、关键概念、意外连接和推荐问题。
graph.json：完整图谱，后续可以直接查询，不必重新读所有文件。

如果想生成更可读的架构页面和 Mermaid 调用流图，可以运行：

`1`	`graphify export callflow-html`

安装和平台支持

Graphify 的 PyPI 包名是 graphifyy，注意是双 y。README 特别提醒，PyPI 上其他 graphify* 包并不属于该项目，但 CLI 命令仍然叫 graphify。

推荐安装方式是：

`1`	`uv tool install graphifyy`

也可以使用：

1
2

pipx install graphifyy
pip install graphifyy

安装后注册到 AI 助手：

`1`	`graphify install`

项目支持的平台很多，包括 Claude Code、Codex、OpenCode、GitHub Copilot CLI、VS Code Copilot Chat、Aider、Cursor、Gemini CLI、Kimi Code、Kiro、Google Antigravity 等。不同平台可以用不同安装命令，例如：

graphify install --platform codex
graphify install --platform gemini
graphify cursor install
graphify antigravity install

Codex 用户还需要在 ~/.codex/config.toml 的 [features] 下加入：

`1`	`multi_agent = true`

README 也说明，Codex 使用 $graphify，不是 /graphify。

它能处理哪些文件

Graphify 覆盖的输入类型很广。

代码方面，它支持 31 种语言，包括 Python、TypeScript、JavaScript、Go、Rust、Java、C/C++、Ruby、C#、Kotlin、Scala、PHP、Swift、Lua、Zig、PowerShell、SQL、Shell、JSON 等。

文档方面，它支持：

.md
.mdx
.qmd
.html
.txt
.rst
.yaml
.yml

还可以通过可选依赖扩展更多类型：

pip install "graphifyy[pdf]"
pip install "graphifyy[office]"
pip install "graphifyy[video]"
pip install "graphifyy[mcp]"
pip install "graphifyy[neo4j]"
pip install "graphifyy[sql]"
pip install "graphifyy[all]"

其中，pdf 用于 PDF 提取，office 用于 .docx 和 .xlsx，video 用于视频和音频转写，mcp 用于 MCP stdio server，neo4j 用于推送到 Neo4j，sql 用于 SQL schema 提取。

生成的报告有什么价值

GRAPH_REPORT.md 不是普通摘要，它会把项目里更值得 AI 助手关注的关系挑出来。

README 里提到的报告内容包括：

God nodes：项目里连接最多的核心概念。
Surprising connections：跨文件、跨模块的意外连接。
The why：从注释、docstring、设计文档里提取出的设计理由。
Suggested questions：图谱特别适合回答的问题。
Confidence tags：关系会标记为 EXTRACTED、INFERRED 或 AMBIGUOUS。

这点很关键。普通搜索只能告诉你“哪里出现了这个词”，而图谱可以回答“这个概念和哪些模块、配置、表、文档有关”。对大型代码库来说，这比单纯全文检索更接近架构理解。

常用命令

Graphify 的常见命令包括：

/graphify .
/graphify ./docs --update
/graphify . --cluster-only
/graphify . --no-viz
/graphify . --wiki
graphify export callflow-html
/graphify query "what connects auth to the database?"
/graphify path "UserService" "DatabasePool"
/graphify explain "RateLimiter"

也可以把论文或视频加入图谱：

1
2

/graphify add https://arxiv.org/abs/1706.03762
/graphify add <youtube-url>

如果要做 PR 辅助分析，还可以使用：

graphify prs
graphify prs 42
graphify prs --triage
graphify prs --conflicts

这类命令适合代码评审场景：看 PR 影响了哪些图谱社区、是否和其他 PR 有冲突风险、哪些 review queue 更值得优先处理。

和 MCP、Neo4j、CI 的关系

Graphify 不只是生成 HTML 图。它也可以把图谱暴露给 AI 助手反复调用。

例如可以启动 MCP server：

`1`	`python -m graphify.serve graphify-out/graph.json`

MCP server 提供的能力包括 query_graph、get_node、get_neighbors、shortest_path、list_prs、get_pr_impact、triage_prs 等。

它也支持 Neo4j 导出或推送：

1
2

/graphify ./raw --neo4j
/graphify ./raw --neo4j-push bolt://localhost:7687

团队协作上，README 建议可以提交 graphify-out/，让团队每个人拉取后都能共享同一份项目地图。还可以运行：

`1`	`graphify hook install`

这样每次 git commit 后自动重建图谱，并设置 merge driver，避免 graph.json 在多人并行提交时留下冲突标记。

隐私和成本要怎么看

Graphify 的 README 对隐私边界写得比较清楚。

代码文件会通过 tree-sitter 在本地解析，不会发出 API 调用。视频和音频可以通过 faster-whisper 本地转写。文档、PDF、图片这类语义提取内容，则会通过你的 AI 助手模型 API 处理。

如果用 headless graphify extract，可能需要设置这些环境变量：

ANTHROPIC_API_KEY
GEMINI_API_KEY
GOOGLE_API_KEY
OPENAI_API_KEY
DEEPSEEK_API_KEY
MOONSHOT_API_KEY
OLLAMA_BASE_URL

本地 Ollama、AWS Bedrock、Claude Code CLI 等也可以作为 backend。README 还写明项目没有 telemetry、usage tracking 和 analytics。

实际使用时要注意：代码本地解析不等于所有内容都不出网。涉及文档、PDF、图片或云端模型时，仍然要看 backend、API key、企业合规和数据边界。

适合哪些场景

Graphify 适合几类用户：

想让 Claude Code、Codex、Cursor、Gemini CLI 更懂项目结构的开发者。
需要快速理解大型陌生代码库的人。
需要把代码、SQL schema、文档、配置放在一起分析的团队。
做架构审查、PR review、重构影响分析的人。
希望把项目知识暴露成 MCP 工具给 Agent 使用的人。
想为团队保留“项目地图”的技术负责人。

它不一定适合所有项目。小型脚本、一次性 demo、结构非常简单的仓库，用普通搜索和 README 可能已经够用。Graphify 的价值更容易出现在模块多、文档多、团队协作多、AI 助手频繁参与开发的大项目里。

小结

Graphify 的意义在于，它把 AI 编程助手的上下文从“临时读取文件”推进到“长期可查询的项目知识图谱”。

对开发者来说，它不是替代 IDE、搜索或 LSP，而是给 AI 助手补一层结构化记忆：哪些模块重要、哪些概念连接紧密、哪些文档解释了设计理由、某个 PR 会影响哪些社区。随着 Codex、Claude Code、Gemini CLI、Antigravity 这类 Agent 工具继续普及，这类“项目图谱层”会越来越有用。

参考来源：

GitHub：safishamsi/graphify

Open Design 项目解析：把 Claude Code、Codex 变成 AI 设计工具

Mon, 18 May 2026 18:57:16 +0800

Open Design 是 nexu-io 推出的开源 AI 设计项目，定位是 local-first、open-source 的 Claude Design / Figma 替代方案。

它想解决的问题很明确：Claude Design 证明了大模型可以直接生成设计制品，但这类能力如果只存在于闭源、云端、单一模型的产品里，用户就很难自托管、接入自己的 Agent、替换模型、沉淀私有设计系统，或者把产物放进本地工作流。

Open Design 的思路不是重新造一个大模型，而是把你电脑上已有的 coding-agent CLI 接进一个设计工作台。Claude Code、Codex、Cursor Agent、Gemini CLI、OpenCode、Qwen、Copilot CLI、Kimi、DeepSeek TUI 等工具，都可以成为它的“设计引擎”。

Open Design 是什么

Open Design 可以理解为三个部分的组合：

一个 Web UI，用来对话、预览、管理项目和导出产物。
一个本地 daemon，负责调度 Agent、管理文件、保存项目和提供 API。
一组 Skills、Design Systems 和模板，用来约束 Agent 生成更像设计作品，而不是随手拼出来的 AI 页面。

用户输入需求后，Open Design 不只是把一句话丢给模型。它会先让用户补充设计简报，选择场景和方向，再把项目元数据、当前设计系统、Skill 文件、模板、检查清单等上下文注入给 Agent。Agent 在真实文件夹里读写文件，最后生成可在沙盒 iframe 中预览的 artifact。

这让它更接近“AI 设计工作流”，而不是单次网页生成器。

为什么它和普通 AI 生成网页不一样

很多 AI 工具都能生成一个 HTML 页面，但 Open Design 的重点不是“让模型写页面”，而是“让模型按设计流程交付可预览、可导出、可迭代的制品”。

它强调几个设计：

先问问题，再生成。新设计 brief 会先出现交互式 question form，用来锁定受众、语气、品牌上下文、约束和视觉方向。
Skills 是文件，不是黑盒插件。每个 Skill 由 SKILL.md、assets/、references/ 组成，可以被阅读、替换和扩展。
Design Systems 是 Markdown，不是固定主题 JSON。颜色、字体、间距、组件、动效、品牌语气和反模式都可以写进 DESIGN.md。
Agent 在真实项目目录里工作。它能读模板、写文件、生成图片、输出 .pptx、.pdf、.zip 等文件。
产物在沙盒 iframe 中预览，减少直接执行不受控代码的风险。

这套结构的目标，是让 AI 更像一个有规范、有素材、有检查清单的设计协作者。

它支持哪些 Agent

Open Design 的一个亮点是“把 Agent 当运行时”，而不是绑定某一家模型。

README 中列出的支持对象包括 Claude Code、Codex CLI、Devin for Terminal、Cursor Agent、Gemini CLI、OpenCode、Qwen Code、Qoder CLI、GitHub Copilot CLI、Hermes、Kimi、Pi、Kiro、Kilo、Mistral Vibe、DeepSeek TUI 等。它会从 PATH 中自动检测这些 CLI，并允许用户切换。

如果本地没有合适的 CLI，也可以走 OpenAI-compatible 的 BYOK proxy，把自己的 baseUrl、apiKey 和模型填进去，让 daemon 把流式输出规范化成同一套聊天流。

这种设计的好处是：

不锁定单一模型。
可以复用用户已经安装和配置好的 Agent。
本地文件读写由 daemon 管理，权限边界更清晰。
对企业或重度用户来说，更容易接入自己的模型和 API 供应商。

Skills 和 Design Systems 是它的核心资产

Open Design 内置了大量 Skills 和 Design Systems。README 中提到，项目内置的 Skills 覆盖网页原型、SaaS landing page、dashboard、mobile app、gamified app、社交轮播图、杂志海报、PPT、周报、财务报告、HR onboarding、invoice、kanban、OKR 等场景。

Design Systems 则用于给 Agent 提供品牌级视觉约束。仓库介绍中列出了 Linear、Stripe、Vercel、Airbnb、Tesla、Notion、Apple、Anthropic、Cursor、Supabase、Figma、小红书等设计系统来源。

这两者的关系可以这样理解：

Skill 决定“这次要交付什么类型的作品”。
Design System 决定“作品应该长成什么品牌风格”。

如果没有这两层约束，AI 很容易生成那种看起来熟悉但缺少判断的通用页面。有了 Skill 和 Design System，模型至少有了清晰的任务边界、视觉参考和检查规则。

它能生成什么

Open Design 不是只做网页原型。

按 README 的描述，它覆盖 web、desktop、mobile prototypes、slides、images、videos、HyperFrames 等方向，并支持 HTML、PDF、PPTX、ZIP、Markdown 等导出形式。媒体生成方面，它把图片、视频、音频也放在同一个设计循环里，例如海报、头像、信息图、地图插画、短视频和 HTML 转 MP4 动效。

这意味着它的使用场景可以很宽：

创业团队快速做 pitch deck。
产品团队生成 landing page 或功能原型。
运营团队做活动页、社媒图、周报。
设计师用它做 moodboard、视觉方向和第一版 layout。
开发者把需求转成可运行的前端 artifact。

它的价值不只是“生成一个页面”，而是把多个内容形态放进同一套 Agent 工作流。

本地优先是什么意思

Open Design 强调 local-first。它不是把所有东西都交给一个远端 SaaS 后端，而是在本地跑 daemon 和项目工作区。

仓库 README 里描述的架构大致是：

前端是 Next.js / React / TypeScript。
本地 daemon 使用 Node、Express、SQLite 和 SSE。
项目、会话、消息、tab、模板等数据保存在本地 SQLite 和 .od/projects/<id>/ 目录。
Agent 通过 child_process.spawn 启动，并在项目 artifact 文件夹中读写。
预览通过沙盒 iframe 渲染。
导出包括 HTML、PDF、PPTX、ZIP、Markdown。

这种结构更适合希望把设计产物留在本机、接入本地 Agent、控制 API key、维护私有工作区的用户。

不过 local-first 不等于完全离线。实际生成仍然取决于你使用的 Agent 和模型。如果你用的是云端模型 API，内容仍然会发往对应供应商。Open Design 更准确的定位，是把工作区、调度、文件和预览放回本地，把模型层交给用户自己选择。

和 Claude Design / Figma 的关系

Open Design 在 README 中明确把自己称为 Claude Design / Figma 的开源替代方向，但它并不是传统意义上的 Figma 复刻。

Figma 是设计师手动编辑、协作和交付设计稿的专业工具；Open Design 更偏 Agent-native：用户通过自然语言、表单、Skills 和设计系统驱动 Agent 产出可运行 artifact。

它更像是把几个东西合在一起：

Claude Design 的 artifact-first 体验。
Figma 的设计系统意识。
Claude Code / Codex 这类 Agent 的文件读写和执行能力。
本地 daemon 的项目管理和沙盒预览。

所以它未必会替代专业设计师的全流程工具，但很适合做“从想法到可预览原型”的快速通道。

适合谁使用

Open Design 更适合这些人：

已经在使用 Claude Code、Codex、Cursor、Gemini CLI 等 Agent 的开发者。
想把 AI 设计产物放到本地项目目录里管理的人。
需要快速生成网页原型、PPT、海报、运营素材的创业团队。
希望自定义 Skills、Design Systems、提示词栈的高级用户。
不想被单一模型或单一云端产品锁住的团队。

不太适合这些人：

只想打开网页、输入一句话、立刻下载图片的轻量用户。
完全不想碰 Node、pnpm、daemon、CLI 和本地配置的人。
需要成熟多人协作、设计评审和矢量编辑能力的专业 Figma 流程。

换句话说，Open Design 更像给 Agent 用户和技术型设计团队准备的工具，而不是面向所有人的轻量设计 SaaS。

需要注意的地方

Open Design 的 README 标注了 0.8.0-preview，并说明项目仍在快速迭代。这类项目的活力很强，但也意味着 API、数据目录、桌面版迁移、Skills 结构和导出流程可能还会变化。

使用前最好注意几点：

不要把它当成稳定企业级设计平台。
先用测试项目体验工作流，再导入重要资料。
如果要迁移 .od/ 数据，先备份，确保 daemon 和桌面应用都已停止。
BYOK 时注意 API key、代理地址和本地私有网络访问风险。
生成的设计仍需要人工审查，尤其是品牌、版权、文案和视觉一致性。

开源项目最大的好处是可检查、可改、可贡献；代价是你需要接受一定的工程摩擦。

小结

Open Design 的看点，不只是“开源版 Claude Design”。它真正有意思的地方，是把 Agent CLI、Skills、Design Systems、本地 daemon 和沙盒预览组织成一个设计工作流。

它把设计生成从单次 prompt 推向了更结构化的流程：先问问题，选方向，加载设计系统，读取 Skill，写入真实文件，预览 artifact，再导出结果。

如果你已经习惯用 Claude Code、Codex 或 Cursor 处理代码，那么 Open Design 值得关注。它代表了一种新的产品形态：不是 AI 帮你画一张图，而是 AI 在本地项目空间里，按设计系统和任务技能，生成一组可以继续迭代的设计制品。

参考资料

nexu-io/open-design GitHub 仓库

Claude Code 省 Token 指南：模型、MCP、CLAUDE.md 和 Skills 怎么影响缓存

Mon, 18 May 2026 18:30:24 +0800

Claude Code 长任务里，Prompt Cache 命中率会直接影响成本和速度。很多人只知道“缓存能省 Token”，但不清楚哪些操作会让缓存突然失效。

理解它并不难：每次请求都可以看成一条从左到右的上下文链条：

`1`	`tools -> system -> CLAUDE.md / skills -> messages`

越靠左的内容越稳定，缓存收益越大；越靠左的内容一变，后面的缓存也更容易跟着失效。反过来，越靠右的内容变化，影响范围越小。

所以优化 Claude Code 的 Prompt Cache，不是靠玄学，而是靠一个原则：任务开始前把模型、MCP、Skills、CLAUDE.md 等基础上下文准备好，任务中途尽量不要改。

Prompt Cache 缓存的不是文字本身

Prompt Cache 不是简单地把提示词字符串存起来。对 Transformer 模型来说，更关键的是前缀上下文经过注意力层计算后的 Key/Value 状态，也就是常说的 KV cache。

这意味着两个事实：

同一段上下文，只要前缀保持稳定，就可以在后续请求中复用一部分计算结果。
如果模型、工具定义、系统提示词或前缀消息发生变化，之前的缓存就可能无法复用。

Anthropic 官方文档也把失效层级概括为 tools -> system -> messages。工具定义变化会影响整段缓存，系统层变化会影响 system 和 messages，messages 层变化则主要影响消息缓存。

Claude Code 里还会额外涉及 CLAUDE.md、Skills、MCP、插件和子代理等上下文，所以实际使用时更容易踩到缓存失效点。

缓存杀手一：中途切换模型

切模型是影响最大的操作。

Prompt Cache 是按模型隔离的。Opus、Sonnet、Haiku 这类模型的结构和权重不同，同一段文本算出来的 KV cache 也不同。你在 Opus 里跑了很长上下文，再切到 Sonnet，并不能让 Sonnet 复用 Opus 的缓存。

这会带来一个反直觉结果：中途为了省钱切模型，可能反而让前面已经积累的缓存全部失效。原本可以按 cache read 价格读取的上下文，需要重新写入和计算。

更稳妥的做法是：

主对话尽量固定一个模型。
需要便宜模型处理支线任务时，用 subagent 隔离出去。
让支线代理完成搜索、探索、整理，再把结果摘要交回主对话。

这样主对话的长上下文尽量不动，缓存命中率更稳定。

缓存杀手二：中途新增 MCP 或重载插件

MCP 会向 Claude Code 提供工具。新增 MCP 服务器后，工具列表会变化，而工具定义处在上下文链条最左侧。

从 Prompt Cache 的角度看，工具列表一变，后面的 system 和 messages 都可能需要重新计算。尤其是 MCP 很多时，工具定义本身就可能占用大量 Token，缓存失效的代价会很明显。

不过有一个细节：Claude Code 通常在会话启动时读取 MCP 配置。你中途改了配置，当前 session 不一定立刻受影响。真正需要小心的是触发重新加载的动作，例如重启、恢复会话、重新加载插件或让工具列表重新组装。

建议是：

开始长任务前，一次性装好需要的 MCP。
不要做一半才发现缺工具，再安装并重载。
对大型 MCP 工具集，优先考虑按需加载或减少默认启用数量。
不常用的 MCP 不要长期挂在默认配置里。

如果工具定义稳定，Prompt Cache 才有长期命中的基础。

缓存杀手三：中途修改 CLAUDE.md

CLAUDE.md 是 Claude Code 的项目记忆文件，适合放构建命令、测试命令、架构约定、代码风格和项目注意事项。

它对 Claude Code 很有用，但也会进入上下文。官方帮助文档说明，CLAUDE.md 会在 session 开始时读取，并作为用户消息提供给 Claude；它也会使用 Anthropic 的 Prompt Cache。首次请求会按完整输入计费，后续请求如果在缓存有效期内命中，就按更低的 cache read 成本处理。

问题在于：CLAUDE.md 是内容寻址的。你一改文件内容，旧缓存就对不上了。

所以不要在长任务中途频繁改 CLAUDE.md。更好的方式是：

任务开始前先检查 CLAUDE.md 是否够用。
把稳定规则写进去，把临时指令放在当前对话里。
如果只是一次性任务，不要为了临时需求修改长期记忆文件。
如果必须改，最好在一个阶段结束后再开始新 session。

CLAUDE.md 应该是稳定的项目说明，而不是每轮任务都改的便签。

缓存杀手四：中途安装或更新 Skills

Skills 也是上下文的一部分。安装新 Skill、更新 Skill，或者让 Skill 列表发生变化，都会让注入到会话里的上下文不同。

这类变化通常不会在当前 session 里立刻完整生效，而是在重新加载、恢复会话或新开会话时体现出来。问题是，一旦重新组装 messages，旧缓存就可能命中不了。

建议和 MCP 类似：

开始任务前先确认需要哪些 Skills。
同一类任务尽量固定 Skill 集合。
不要在一个长任务中途边做边装 Skill。
如果安装了新 Skill，最好把它当成新阶段的开始。

对经常做内容生产、代码审查、部署、翻译的工作流，可以把常用 Skills 固定下来，让上下文结构尽量稳定。

缓存杀手五：空闲时间超过 TTL

Prompt Cache 不是永久保存。常见默认有效期是几分钟级别，Anthropic 文档和 Claude Code 相关说明里都提到过 5 分钟左右的缓存窗口。超过 TTL 后，即使你发送完全一样的请求，服务端也可能已经清掉缓存。

这也是很多长任务用户的体感来源：刚才还很省，去喝杯咖啡回来，再发下一步，Token 又突然涨上去了。

长任务尤其容易遇到这个问题。你可能要看 Claude Code 的输出、检查文件、跑测试、思考下一步，这些操作一不小心就超过 5 分钟。

如果你的使用环境支持，可以在长任务前启用 1 小时 Prompt Cache TTL：

`1`	`export ENABLE_PROMPT_CACHING_1H=1`

在 Windows PowerShell 里可以写成：

`1`	`$env:ENABLE_PROMPT_CACHING_1H="1"`

需要注意的是，1 小时缓存写入成本通常会高于 5 分钟缓存写入成本。它不适合所有短任务，但对大型代码库、长对话、复杂多步骤开发任务，往往比频繁缓存过期更划算。

怎么安排一次更省 Token 的 Claude Code 长任务

比较稳的流程可以这样做：

任务开始前选定模型，不要中途频繁切换。
提前启用需要的 MCP，不用的 MCP 先关掉。
检查 CLAUDE.md，只保留稳定、关键、长期有效的规则。
提前准备好本次任务需要的 Skills。
如果是复杂任务，考虑启用 1 小时 TTL。
把大任务拆成几个阶段，但每个阶段内部尽量保持上下文结构稳定。
需要探索支线问题时，用 subagent 或单独 session，不要污染主对话。

这套做法的目标不是绝对不让缓存失效，而是避免那些代价最高、最容易被忽略的失效。

一个简单判断标准

你可以用一句话判断某个操作是否危险：

这个操作会不会改变模型、工具定义、系统上下文或会话开头的固定消息？

如果答案是会，那它大概率会影响 Prompt Cache。越靠近上下文链条左侧，影响越大。

常见操作可以这样理解：

切模型：高风险，模型缓存隔离。
新增 MCP 或重载插件：高风险，工具列表变化。
修改 CLAUDE.md：中高风险，项目记忆变化。
安装 Skills：中高风险，注入上下文变化。
普通对话继续追问：低风险，主要追加 messages。
空闲超过 TTL：高风险，服务端缓存过期。

小结

Claude Code 的 Prompt Cache 优化，关键不是背参数，而是让会话前缀稳定。

模型不要随便切，MCP 和 Skills 不要边做边装，CLAUDE.md 不要当临时草稿频繁改，复杂任务尽量延长 TTL。只要这些基础动作稳定下来，Claude Code 在长任务里的 Token 成本和响应速度都会更可控。

最实用的一句话是：开始前配好，开始后少动。

参考资料

Anthropic Founder’s Playbook 解读：Claude 如何帮助创业团队提速

Mon, 18 May 2026 18:02:58 +0800

Anthropic 在 Claude 官方博客发布了面向创业者的 The Founder’s Playbook，核心问题很直接：一家 AI-native startup 如何更快从洞察走到产品、发布和规模化？

这份 playbook 并不是单纯介绍 Claude 的功能清单，而是把创业过程拆成四个阶段：Idea、MVP、Launch 和 Scale。它强调的不是“让 AI 代替创始人做判断”，而是把市场调研、文案初稿、代码脚手架、运营流程、销售材料等重复性工作先交给 Claude，让创始人把更多时间留给判断、品味、取舍和信任建设。

这份 playbook 在讲什么

AI 创业公司面临的压力越来越像一场压缩比赛：产品周期更短，竞争者更多，用户对速度和质量的要求同时提高。过去需要多人团队分工完成的事情，现在可以用 AI 先做出第一版，再由创始团队审阅、修正和推进。

Anthropic 给出的框架很清晰：不要一开始就试图把公司完全“AI 化”，而是先找一个耗时、重复、低创造密度的流程，让 Claude 生成初稿、脚本、调研结果或执行清单。创始人负责定义目标、校准方向、判断质量，并把可行结果接入真实业务。

第一阶段：Idea

Idea 阶段的重点不是“想一个酷点子”，而是验证这个点子是否值得继续投入。

Claude 适合在这个阶段帮助创始人做几件事：整理市场地图、归纳用户痛点、比较竞品定位、提出潜在楔入点，并把模糊想法压缩成更具体的价值主张。

但这一步最重要的仍然是人的判断。AI 可以帮助你更快看到一批可能性，却不能替你承担“这个市场是否真的存在强需求”的责任。创始人仍然需要和真实用户交流，观察他们愿不愿意改变现有工作流，甚至愿不愿意付费。

第二阶段：MVP

MVP 阶段是 Claude Code 最容易发挥作用的地方。

对小团队来说，最稀缺的往往不是想法，而是把想法变成可试用产品的速度。Claude Code 可以参与生成脚手架、写脚本、补组件、检查边界条件、产出技术方案说明，帮助团队更快做出可验证的版本。

这里的关键不是让 AI 一次性写出完美产品，而是把“从 0 到第一版”的摩擦降下来。创始人和工程师仍然需要审查架构、安全性、数据处理和用户体验，但他们不必把时间浪费在大量机械性的初稿工作上。

第三阶段：Launch

Launch 阶段考验的是叙事、分发和反馈速度。

很多创业团队会低估发布的复杂度：官网文案、产品演示、邮件、社交媒体内容、用户访谈、销售话术、投资人更新，每一项都需要清楚表达“为什么现在需要这个产品”。

Claude 在这里可以充当一个高频协作对象：帮团队生成不同版本的定位表达，改写面向不同用户群体的介绍，模拟用户疑问，整理发布节奏，并把早期反馈转成下一轮产品和市场动作。

第四阶段：Scale

Scale 阶段的主题从“做出来”转向“可重复地增长”。

当公司开始有稳定用户和收入，创始团队会被运营、销售、客服、数据分析和内部协作拉扯。Claude Cowork 这类 agent 化能力适合处理更完整的任务：例如做市场研究、设计活动方案、整理募资策略、汇总增长指标，或者把一套运营流程拆成可以反复执行的步骤。

这也是 AI-native 公司和传统软件公司的差异开始显现的地方。真正的变化不只是“员工使用 AI 工具”，而是公司流程从一开始就围绕 AI 协作来设计：哪些任务由人定义标准，哪些任务由 AI 先跑一遍，哪些结果必须进入审查，哪些流程可以沉淀成可复用模板。

Claude Code、Claude Cowork 和 Chat 各自适合做什么

从这篇官方博客的描述看，Anthropic 想让创业者把 Claude 分成三类使用场景。

Claude Code 更偏工程协作，适合写代码、生成脚本、分析边界情况、产出组件规格和技术文档。它解决的是“把想法推进成可运行东西”的问题。

Claude Cowork 更像可委派的工作代理，适合市场研究、活动设计、募资策略、运营分析这类需要连续执行的任务。它解决的是“把一件较完整的业务工作先推进一轮”的问题。

Claude Chat 则更适合创始人的判断时刻：推敲 go-to-market 策略、压力测试产品定位、比较路线图优先级、打磨关键叙事。它不是执行机器，而是一个可以快速反复讨论的思考搭档。

对创业团队真正有用的地方

这份 playbook 的价值，不在于告诉创业者“AI 很重要”。这一点已经不新鲜了。

它更有用的地方，是把 AI 使用方式从零散工具调用，推进到公司建设方法论：每个阶段都有不同的瓶颈，每个瓶颈都可以拆出适合 AI 参与的部分。

Idea 阶段，AI 帮你扩大搜索空间。MVP 阶段，AI 帮你压缩实现周期。Launch 阶段，AI 帮你加快表达和分发实验。Scale 阶段，AI 帮你沉淀可重复流程。

这套逻辑对小团队尤其重要。因为小团队没有足够的人手覆盖所有职能，但可以用 AI 先补上“第一版能力”，再把有限的人力投入到最需要判断和关系建设的部分。

需要警惕的误区

第一个误区是把 AI 生成的内容直接当结论。市场调研、竞品分析、用户画像、增长策略都必须回到真实数据和用户反馈里验证。

第二个误区是低估审查成本。AI 能显著降低初稿成本，但代码质量、法律风险、品牌表达、商业承诺和安全问题仍然需要人负责。

第三个误区是过早自动化。对还没有跑通的流程，不应该急着交给 agent 自动执行。更稳妥的方式是先让 AI 参与其中一小段流程，观察输出质量，再逐步扩大范围。

小结

Anthropic 这篇 The Founder’s Playbook 传递的信号很明确：AI-native startup 的优势，不只是“会用 AI 写代码”，而是从公司第一天开始，就把 AI 作为产品、工程、市场、销售和运营里的协作层。

对创业者来说，最现实的起点不是搭建宏大的 AI 工作流，而是选出一个最耗时、最重复、最拖慢推进速度的任务，让 Claude 先做第一版。真正的竞争力，来自人类创始人对方向、质量和信任的把关，以及团队能否把这种协作方式稳定地嵌入日常工作。

参考资料

The founder’s playbook for the age of AI

easy-vibe：给 Vibe Coding 初学者的一张学习地图

Sat, 16 May 2026 22:44:43 +0800

easy-vibe 是 Datawhale 开源的 Vibe Coding 学习项目。它面向的不是已经熟练使用 AI 编程工具的开发者，而是刚开始接触 Vibe Coding 的学生、产品经理、设计师、运营、独立开发者和普通技术爱好者。

这个项目的价值不在于又列出一批 AI 工具，而是把“怎么开始用 AI 做项目”拆成了更容易理解的学习路径。对很多新手来说，真正困难的不是不知道有 Claude Code、Cursor、MCP 或 Agent，而是不知道应该先学什么、怎么练、什么时候进入进阶工具。

Vibe Coding 新手最缺的是路径

Vibe Coding 这几年很火，但它对新手并不友好。

表面上看，只要会描述需求，就可以让 AI 写代码。实际上，只要任务稍微复杂一点，问题就会出现：需求说不清，模型改错文件，项目结构看不懂，报错不会处理，依赖装不上，提示词越写越乱，最后只能回到“复制代码到聊天框”的状态。

所以 Vibe Coding 入门不能只教“怎么写提示词”。它至少要解决几件事：

如何把想法拆成可执行任务；
如何让 AI 理解项目结构；
如何看懂模型生成的代码；
如何处理报错和迭代；
如何使用终端和本地开发环境；
如何从网页聊天过渡到真正的 AI 编程工具。

easy-vibe 的意义就在这里：它试图把这些内容整理成一条学习路线，而不是让新手自己在工具、教程和术语里迷路。

它不是单点教程，而是路线图

从项目介绍看，easy-vibe 覆盖了基础教程、交互式练习、可视化内容、RAG、终端工具、AI 编程工具，以及更进阶的 Claude Code、MCP、Skills、Agent Teams 等主题。

这类组织方式比较适合初学者。因为 AI 编程不是一个单独技能，而是一组能力的组合：

会描述需求；
会拆任务；
会读项目；
会让模型改代码；
会运行和验证；
会根据错误继续迭代；
会把常用流程沉淀成工具或技能。

如果只学某一个工具，很容易被工具界面限制住。换一个模型、换一个编辑器、换一个 CLI，就又不知道怎么做。路线图的好处是先建立工作方式，再把工具放到合适的位置。

对非程序员尤其有用

Vibe Coding 最大的吸引力，是让非专业程序员也能做出原型。

产品经理可以把产品想法变成可交互 demo，设计师可以验证交互逻辑，运营可以写内部工具，学生可以快速做课程项目，创业者可以在早期验证需求。这些人不一定要成为传统意义上的全职工程师，但需要掌握一套“让 AI 帮我把想法落地”的方法。

这也是 easy-vibe 适合中文社区的原因。很多中文用户已经知道 AI 能写代码，但还缺少系统入门材料：从开发环境、提示词、项目结构、调试方法到 Agent 工具使用，最好能用中文解释清楚，并配合练习逐步推进。

对这类用户来说，最重要的不是一上来学复杂框架，而是先跑通完整闭环：提出需求、生成项目、运行起来、发现问题、继续修改、最终得到一个可用版本。

进阶部分开始靠近真实 AI 开发工作流

easy-vibe 里提到的 Claude Code、MCP、Skills、Agent Teams，已经不只是入门概念。

Claude Code 代表的是终端编程 Agent：模型可以进入本地项目，读取文件、修改代码、运行命令。MCP 解决的是工具和数据源接入，让模型不只停留在聊天框里。Skills 则把可复用流程沉淀下来，例如固定的项目生成、文档整理、测试检查或内容生产流程。Agent Teams 进一步把任务拆给多个智能体协作。

这些内容对新手来说可能有点远，但它们值得提前了解。因为 Vibe Coding 的发展方向已经很清楚：从“让 AI 写一段代码”，走向“让 AI 参与一个完整项目流程”。

如果学习路线只停留在提示词层面，很快就会跟不上工具演进。反过来，如果一开始就把所有高级概念塞给新手，又会让人无从下手。easy-vibe 的合理价值，是把这些内容放在一条逐步升级的路径里。

学习时要避免两个误区

第一个误区，是以为 Vibe Coding 等于不会代码也能完全不管代码。

AI 可以生成很多内容，但用户仍然需要判断结果是否正确。至少要能看懂项目结构、知道怎么运行、知道错误大概发生在哪里。即使不写复杂代码，也要具备基本的工程常识。

第二个误区，是以为工具越高级越好。

新手不一定一开始就需要 Claude Code、MCP 或多 Agent。更好的顺序是先用简单项目建立反馈循环，再逐步引入终端、版本管理、测试、工具调用和自动化流程。工具要跟任务复杂度匹配，否则很容易变成“看起来很强，但不知道用来做什么”。

适合怎么用

如果你刚接触 Vibe Coding，可以把 easy-vibe 当作学习清单来用。

先从基础概念和简单练习开始，不急着追所有工具。做一个小项目，例如个人主页、数据看板、表单工具、自动化脚本或知识库 demo。过程中重点观察 AI 在哪些地方帮得上忙，哪些地方需要你自己确认。

等你能稳定完成小项目，再开始学习更复杂的内容：

用终端工具处理本地项目；
用 Git 管理每次修改；
用 RAG 接入自己的资料；
用 MCP 连接外部工具；
用 Skills 固化重复流程；
用 Agent Teams 拆分复杂任务。

这样学出来的 Vibe Coding 才不只是会问 AI，而是能把 AI 放进自己的工作流程里。

总结

easy-vibe 适合被看作 Vibe Coding 的中文入门地图。它把零散的 AI 编程概念、工具和练习组织成一条路径，让新手更容易从“听说 AI 能写代码”走到“我能用 AI 做出一个项目”。

Vibe Coding 真正有价值的地方，不是让人跳过所有学习，而是降低从想法到原型的门槛。你仍然需要理解需求、组织任务、验证结果和控制风险，但很多重复、枯燥、容易卡住的步骤，可以交给 AI 协助完成。

如果你想系统入门 AI 编程，又不想一开始就陷入工具名词和复杂工程配置，easy-vibe 是一个值得收藏的起点。

Claude Code + Ollama 本地部署教程：用 CC Switch 打造免费 AI 编程助手

Fri, 15 May 2026 23:27:50 +0800

最近 Claude Code 在 AI 开发工具圈很火，原因不难理解：它不像普通聊天机器人那样只回答问题，而是可以读取项目、修改代码、执行终端命令、安装依赖，并尝试自动修复报错。

真正的问题在成本。Claude 官方 API 在长上下文、大型项目、多轮 Agent 调用和自动修 Bug 场景下，Token 消耗会很快变大。于是出现了一种新的玩法：继续使用 Claude Code 的 Agent 外壳，但把模型请求转发给本地 Ollama。

这条链路的关键工具是 CC Switch。

这套方案解决什么问题

可以把它理解为：

1
2
3

Claude Code 桌面版
+ CC Switch API 转发层
+ Ollama 本地模型

Claude Code 继续负责项目操作、终端执行、文件修改和 Agent 流程；真正负责推理的大模型，则换成本地运行的 Qwen、DeepSeek、Gemma、GLM 等模型。

这样做的吸引力很直接：

不依赖 Claude 官方 API。
没有持续 Token 计费压力。
模型和数据可以留在本机。
小项目、脚本、网页、运维任务可以低成本反复试。

但它不是“免费获得 Claude Sonnet 能力”。本地模型的工程理解、长上下文稳定性和复杂任务规划，仍然会受模型能力、显存、量化版本和上下文长度限制。

基本准备

前置环境主要包括：

安装 Git。
安装 Claude Code 官方桌面版。
安装最新版 Ollama 客户端。
下载 CC Switch 开源工具。
在 Ollama 中准备合适的本地模型。

模型选择可以按显存来定。常见选择包括：

Qwen 3.6 / Qwen 3.5
Gemma4
DeepSeek R1
GLM

如果显存不大，优先选择较小参数或较低量化版本。不要一开始就用超大模型，否则很容易出现加载慢、上下文短、响应卡顿或直接显存不足。

CC Switch 关键配置

这套方案里最关键的配置项是下面几项。

请求地址：

`1`	`http://127.0.0.1:11434/v1`

API 格式：

`1`	`OpenAI Chat Completions`

认证字段选择：

`1`	`ANTHROPIC_API_KEY`

Claude Code 桌面版的自定义配置文件末尾，还需要加入注册表修改命令：

`1`	`"inferenceModels"="[\"haiku\",\"sonnet\",\"opus\"]"`

这一步的作用，是让 CC Switch 把模型名称注入到 Claude Code 里显示。Claude Code 以为自己在调用 Claude 模型，实际请求已经被 CC Switch 转发到了本地 Ollama。

Claude Code 强在哪里

很多人第一次接触 Claude Code，会把它当成高级聊天工具。但它和普通 AI 聊天客户端不太一样。

普通聊天式 AI 通常是：

1
2

你问一句
它答一句

Claude Code 更接近：

`1`	`AI + IDE + Terminal`

它可以读取项目结构，例如：

src/
components/
package.json
docker-compose.yml

然后尝试完成一串操作：

分析代码。
修改文件。
安装依赖。
执行命令。
查看报错。
再次修改。
重新运行项目。

这也是为什么很多开发者把它叫做 AI 开发 Agent。它的价值不只是“写一段代码”，而是能围绕项目状态连续行动。

Ollama 在这里扮演什么角色

Ollama 负责在本机运行模型。

这套组合的核心逻辑是：

Claude Code 负责 Agent 能力和项目操作。
CC Switch 负责把 Claude Code 的请求转成兼容本地模型的 API。
Ollama 负责实际推理。
本地模型返回结果后，再交给 Claude Code 继续执行。

所以，这不是把 Ollama 变成一个普通聊天窗口，而是把它接进 Claude Code 的工作流。

对于小型任务，这种组合会很有吸引力。比如：

生成一个 HTML 页面。
修改小型前端项目。
写自动化脚本。
处理 Docker 配置。
做 VPS 运维辅助。
生成简单工具或测试代码。

类似“帮我生成一个赛博朋克风格的个人主页网站”这类任务，本地模型可以完成项目创建、网页生成、动画和特效配置，并尝试自动运行。

体验边界在哪里

这套玩法很有意思，但边界也要说清楚。

目前本地模型仍然很难完全替代 Claude Sonnet，尤其在这些场景里：

长上下文理解。
大型工程结构分析。
多步骤推理。
复杂项目架构调整。
长时间连续修 Bug。

项目一复杂，本地模型更容易出现：

逻辑混乱。
修改错误文件。
反复修同一个 Bug。
忘记前文上下文。
对项目结构判断不稳定。

所以更合理的定位是：它适合低成本试验、小项目、脚本任务和局部代码修改；不适合一开始就把大型生产项目完全交给它自动改。

多模态兼容性还不稳定

这套链路还有一个明显问题：Vision 多模态兼容性。

虽然 Ollama 已经支持一些 Vision 模型，但 Claude Code + CC Switch + Ollama 这条链路对图片支持并不完整。常见情况是：用户上传了图片，但 AI 仍提示没有看到图片。

这并不一定是模型不支持 Vision，而是整条链路里：

Claude Code 更偏代码 Agent。
CC Switch 主要处理 API 转发。
Ollama 模型能力和请求格式还要匹配。
图片输入在不同客户端和模型之间并不总是无缝传递。

所以目前更适合的场景还是：

编程。
终端操作。
项目文件修改。
自动化脚本。

而不是：

图片理解。
OCR。
多模态聊天。
复杂视觉任务。

适合谁尝试

这套方案适合几类人：

想体验 Claude Code Agent 工作流，但不想持续消耗 Claude API 的用户。
已经在本机跑 Ollama 的本地大模型玩家。
做小项目、脚本、网页、运维工具的开发者。
想测试本地模型真实编程能力的人。
对数据本地化更敏感的用户。

不太适合：

完全不想折腾配置的人。
希望获得 Claude Sonnet 同等能力的人。
需要稳定处理大型生产代码库的人。
强依赖图片输入和多模态能力的人。

使用建议

如果要尝试，建议按低风险方式开始：

先用测试项目，不要直接接生产仓库。
选择中小模型，确认 Ollama 本身运行稳定。
先做 HTML、脚本、配置文件这类简单任务。
每次修改后自己检查 git diff。
不要让它在不确认的情况下批量删除或重构文件。
多模态任务暂时不要依赖这条链路。

如果项目比较复杂，最好把任务拆小：让它只改一个模块、一个函数、一个页面或一个配置文件。这样比“一句话让它重构整个项目”可靠得多。

小结

Claude Code + Ollama + CC Switch 的意义，不是让本地模型立刻变成 Claude Sonnet，而是把本地模型接进一个真正能操作项目的 Agent 外壳里。

这让本地 AI 开发助手第一次变得更接近真实生产力工具：它可以看项目、改文件、跑命令、修错误，而不是只在聊天框里给建议。

但它的能力上限仍然取决于本地模型本身。小项目和自动化任务会很有价值；大型工程、长上下文和复杂推理仍然需要更强模型。

如果你的目标是“零 API 成本、无 Token 焦虑、在本机反复试 AI 编程 Agent”，这套方案值得折腾。只是要记住：它是本地开发助手，不是万能自动程序员。

Superpowers：把 Coding Agent 拉回工程流程的技能框架

Fri, 15 May 2026 08:53:17 +0800

obra/superpowers 是一个给 coding agent 使用的技能框架，也是一套软件开发方法论。它的目标不是再写一个“让 AI 更听话”的万能 prompt，而是把 agent 的工作流程固定下来：先澄清目标，再产出设计，再拆计划，再按测试驱动开发推进，最后做 review 和收尾。

项目地址：https://github.com/obra/superpowers

截至写作时，GitHub API 显示这个仓库已有超过 19 万 star，许可证为 MIT，最近仍在更新。README 对它的描述很直接：An agentic skills framework & software development methodology that works.

它想解决什么问题

现在很多 AI 编程工具的问题，不是“不够会写代码”，而是太容易直接写代码。

用户刚说一个模糊需求，agent 就开始改文件；改完以后看似完成，其实边界没对齐、测试没补、架构没想清楚。短任务可能没事，复杂项目里就会变成返工、回滚和技术债。

Superpowers 的思路是：让 agent 在动手前先进入流程。

README 里描述的核心路径大致是：

发现用户要做东西时，不立刻写代码，而是先追问目标。
从对话中整理出规格说明，并分段给用户确认。
设计通过后，生成足够清楚的实施计划。
用户说 “go” 之后，再进入实现流程。
实现时强调 TDD、YAGNI、DRY，并通过 review 检查结果。

这套流程听起来不新，但放到 coding agent 里很关键。AI 的执行速度越快，前置澄清和中途验证越重要。

支持哪些工具

Superpowers 不是只面向一个 agent。README 里列出的安装入口包括：

Claude Code
Codex CLI
Codex App
Factory Droid
Gemini CLI
OpenCode
Cursor
GitHub Copilot CLI

其中 Codex CLI 和 Codex App 都可以通过官方 Codex plugin marketplace 安装。Claude Code 也可以通过官方插件市场或 Superpowers 自己的 marketplace 安装。

这说明它的定位更像“跨 harness 的工作流层”，而不是绑定某一家模型或某一个命令行工具。

基础工作流

Superpowers 的基础工作流分成几个阶段。

第一步是 brainstorming。它会在写代码前触发，通过问题把粗糙想法整理成可执行设计。它不是让 agent 自嗨式补全需求，而是把设计分段拿给用户确认。

第二步是 using-git-worktrees。设计确认后，它会创建隔离的工作区和新分支，先确认项目能正常安装、测试基线是干净的。这一步能减少多个任务互相污染工作区的问题。

第三步是 writing-plans。它会把设计拆成短小任务，每个任务要求有明确文件路径、代码范围和验证步骤。README 里甚至把计划写给“没有上下文、品味可疑、不爱测试的热情初级工程师”也能执行，当作清晰度标准。

第四步是实现。它可以用 subagent-driven-development 派发子任务，也可以用 executing-plans 分批执行。重点不是并发本身，而是每个任务都要能检查、能 review、能继续推进。

第五步是 test-driven-development。Superpowers 强调真正的 RED-GREEN-REFACTOR：先写失败测试，确认失败，再写最小实现，确认通过，然后重构。它甚至要求删除测试前写出来的实现代码，避免“先实现后补测试”的假 TDD。

第六步是 requesting-code-review。任务之间做 review，按严重程度报告问题。Critical 问题会阻塞继续推进。

最后是 finishing-a-development-branch。任务结束后，验证测试，给出合并、发 PR、保留或丢弃 worktree 的选择。

Skills Library 里有什么

Superpowers 的技能库可以分成几类。

测试类主要是 test-driven-development，围绕红绿重构循环，并包含测试反模式参考。

调试类包括 systematic-debugging 和 verification-before-completion。前者要求按复现、最小化、假设、验证、修复的过程找根因；后者强调不要在没有验证前宣布完成。

协作类更丰富，包括：

brainstorming
writing-plans
executing-plans
dispatching-parallel-agents
requesting-code-review
receiving-code-review
using-git-worktrees
finishing-a-development-branch
subagent-driven-development

元技能包括 writing-skills 和 using-superpowers。前者用于创建新技能，后者用于理解技能系统本身。

这些技能组合起来，像是给 agent 装了一套工程习惯：什么时候该问，什么时候该计划，什么时候该测试，什么时候该停下来 review。

和普通 prompt 最大的区别

普通 prompt 往往把规则堆在一段 system prompt 里：不要乱改、先思考、要测试、要解释、要简洁。问题是规则越堆越多，模型越容易在复杂任务里选择性遗忘。

Superpowers 更像把规则拆成可触发的流程模块。不同任务阶段使用不同技能，每个技能只负责一段工作。这样做有几个好处：

规则更短，目标更集中。
agent 更容易知道当前阶段该做什么。
复杂流程可以被拆成可检查的步骤。
技能可以跨工具复用。
团队可以把自己的工程习惯沉淀成技能。

这也是它最值得参考的地方：不要只追求“更聪明的模型”，还要给模型一套可重复的工作方式。

适合谁用

Superpowers 更适合已经在认真使用 coding agent 的开发者，尤其是这些场景：

任务不只是单文件改动。
希望 agent 先设计再实现。
项目需要 TDD 或至少需要验证步骤。
经常并行做多个功能分支。
希望用 subagent 分摊实现、检查和 review。
想把团队流程写成可复用技能。

如果只是让 AI 改一行配置、生成一个脚本，它可能显得偏重。但一旦任务涉及多文件、多阶段、多轮确认，它的流程约束就会变得有价值。

使用时要注意什么

第一，不要把它理解成自动驾驶。Superpowers 能让 agent 更有流程感，但设计取舍、需求边界和最终验收仍然需要人负责。

第二，TDD 和 review 会增加前期成本。小任务可能会变慢，但复杂任务通常能减少返工。

第三，子代理并发不是越多越好。并发适合边界清楚、写入范围不重叠的任务；如果需求还没想清楚，先并发只会把混乱放大。

第四，团队要维护自己的技能质量。技能不是写完就万事大吉，过时的流程、模糊的指令和互相冲突的规则，也会拖累 agent。

小结

Superpowers 的价值，不在于某个单独技能多神奇，而在于它把 coding agent 从“接到需求就写代码”拉回了软件工程流程。

它提醒我们：AI 编程真正缺的往往不是生成速度，而是澄清、计划、验证、review 和收尾。模型越强，这些流程越不能省。否则 AI 只是更快地制造未验证的代码。

如果你已经在用 Codex、Claude Code、Cursor 或 Gemini CLI 做真实项目，Superpowers 值得看一眼。即使不直接安装，它的技能拆分方式也很适合拿来改造自己的 agent 工作流。

拒绝 Vibe Coding：Matt Pocock 的 skills 仓库给 AI 编程补上工程约束

Fri, 15 May 2026 08:46:23 +0800

AI 写代码越快，项目失控也可能越快。真正的问题不是模型会不会生成函数，而是它是否理解需求、是否遵守团队语言、是否能在已有架构里小步推进。如果把 AI 当成“随便说一句就自动完工”的代码喷射器，最后很容易得到一堆跑不通、难维护、没人敢改的代码。

Matt Pocock 开源的 mattpocock/skills 仓库，正好给了一个相反方向的示例：不要让 AI 接管整个开发流程，而是把 AI 放进成熟的软件工程约束里。

项目地址：https://github.com/mattpocock/skills

这套方法的重点不是某个神奇 prompt，而是一组可以组合的 agent skills。它们把需求澄清、领域建模、测试驱动、问题诊断、架构审查这些老派工程实践，重新包装成适合 AI 编程工具调用的工作流。

先解决对齐失败

AI 编程最常见的失败，是你以为它懂了，其实它只是顺着你的模糊描述开始猜。

grill-me 的思路就是反过来：在写代码之前，先让 AI 变成一个会追问的审稿人。它不会立刻开始实现，而是持续追问计划里的分支、边界和未决问题。

比如你说“做一个登录页”，它应该先问：

忘记密码怎么处理？
是否支持第三方登录？
登录失败时要显示什么错误？
账号锁定、验证码、风控是否在本期范围内？
成功后跳转到哪里？

这一步看起来慢，但它减少的是后面返工的时间。AI 生成代码的成本越低，需求没想清楚带来的浪费就越大。

把领域语言写进上下文

第二个问题是 AI 的“通用词汇病”。它不了解团队内部的业务叫法，只能用常见词来猜，于是变量名、函数名、文档描述都开始漂移。

grill-with-docs 解决的是这个问题。它不只是追问需求，还会结合项目里的 CONTEXT.md、ADR 或领域文档，检查用户表达是否和既有术语冲突。确认后的术语、边界和决策，可以继续沉淀回上下文文档。

这和领域驱动设计里的“统一语言”很接近。假设团队把 user 称为 customer，把 order 称为 transaction，那么 AI 在写代码时也应该继承这些叫法，而不是自己再发明一套。

上下文文档的价值不在于堆资料，而在于让 AI 少猜一点。

用 TDD 限制生成速度

AI 的危险之处在于它太快了。过去写出一大段坏代码需要时间，现在几秒钟就能生成几百行。速度本身不是问题，缺少反馈循环才是问题。

tdd skill 把经典的红绿重构流程放回 AI 编程里：

先为一个行为写失败测试。
再实现刚好让测试通过的代码。
然后重构。
按垂直切片继续推进。

重点是“一次一个行为”，而不是让 AI 一口气写完所有测试和所有实现。这样做可以把任务切小，也能让每一步都有可验证结果。AI 负责执行，人类负责确认方向和边界。

用诊断循环处理复杂问题

遇到 bug 时，很多 AI 会直接猜答案，然后连续改几轮，把问题越修越乱。

diagnose 的价值在于要求 AI 先建立反馈循环：

复现问题
最小化场景
提出假设
增加观测或日志
修复
补回归测试

这套流程不新，但在 AI 编程里尤其重要。因为 AI 很擅长快速尝试，却不一定擅长判断哪次尝试真正接近根因。诊断流程相当于给它加了一条轨道。

定期审查架构，而不是只看单个任务

单次任务跑通，不代表代码库变好了。AI 反复提交小改动后，最容易出现的问题是模块边界变模糊、接口越来越复杂、测试越来越难写。

improve-codebase-architecture 这类 skill 的意义，是让 AI 定期跳出当前任务，从更高层看代码库：

哪些模块职责开始混在一起？
哪些接口太复杂？
哪些路径难以测试？
哪些命名和领域语言不一致？
哪些重复逻辑应该收敛？

这不是让 AI 自动大重构，而是让它先给出结构化观察和改进方向。真正要不要改、改到什么程度，仍然需要开发者判断。

真正该限制的是自由度

这套方法论的核心可以压缩成一句话：AI 编程不是放任模型自由发挥，而是给它清晰的目标、上下文、测试和停止条件。

人类更适合负责问题定义、架构边界、业务取舍和验收标准；AI 更适合负责代码生成、测试补全、重复修改和局部重构。两者配合得好，AI 是放大器；配合得不好，它会把混乱也一起放大。

所以，软件工程基础没有因为 AI 变强而过时。恰恰相反，需求澄清、领域语言、TDD、诊断、架构审查这些能力，在 AI 时代变得更关键。

会写代码的人会越来越多。真正拉开差距的，是谁能把 AI 放进可维护、可验证、可长期演进的工程体系里。

cc-haha 是什么？一个把 Claude Code 做成桌面工作台的项目

Thu, 14 May 2026 22:36:43 +0800

cc-haha 是一个围绕 Claude Code 工作流改造出来的项目。它的完整仓库名是 NanmiCoder/cc-haha，项目页面写得很直接：它基于 2026-03-31 从 Anthropic npm registry 泄露的 Claude Code 源码修复而来，现在主要形态是一个桌面端 Claude Code 工作台。

项目地址：https://github.com/NanmiCoder/cc-haha

这句话里有两个重点。

第一，它不是 Anthropic 官方 Claude Code。项目 README 也明确写了原始源码版权归 Anthropic 所有，仅供学习和研究用途。

第二，它现在的重点已经不只是“本地跑一个 Claude Code CLI”。从 README 和最新 release 看，cc-haha 更像一个把 Claude Code 的会话、项目、权限、Diff、Computer Use、远程访问和模型提供商配置集中起来的桌面应用。

它想解决什么问题

Claude Code 原本是偏终端的工具。会话、命令执行、权限确认、文件修改、上下文切换都在终端里完成。对熟悉 CLI 的人来说没问题，但长期使用时会遇到几个不方便的地方：

多个项目和多个会话不好同时管理。
AI 改了哪些文件，需要自己切到 Git 或编辑器里看。
权限审批、命令执行、文件 Diff 分散在不同界面。
想在手机或其他设备上远程看当前会话，需要额外方案。
想接入非 Anthropic 模型，需要自己处理协议兼容。

cc-haha 的方向就是把这些东西做成一个图形化工作台。它并不是只给 Claude Code 换皮，而是把“会话管理”和“本地开发流程控制”放到了桌面端里。

桌面端工作台：从终端变成控制台

根据 README，cc-haha 桌面端把这些能力集中到 macOS / Windows App 里：

多会话工作台：用标签页、项目切换、终端入口和历史记录管理不同任务。
分支 / Worktree 启动：新会话可以选择仓库分支，也可以选择使用当前工作树或隔离 Worktree。
右侧代码改动面板：聊天时直接查看修改过的文件、增删行和工作区状态。
代码修改可视化：查看 AI 对文件的编辑、Diff 和执行过程。
权限与确认流：把危险命令、工具调用和 AI 反问集中到桌面端审批。
多模型提供商：支持 Anthropic 兼容 API、第三方模型、WebSearch fallback 和本地配置。
H5 远程访问：用一次性 token 在手机或其他设备上接入当前桌面会话。
IM 接入：通过 Telegram、飞书、微信、钉钉远程对话、切换项目和审批权限。
定时任务与 token 用量统计：在桌面端创建计划任务，并查看本机 token 使用趋势。

这类功能说明它更接近“AI 编程工作台”，而不是单纯的命令行替代品。它想把 AI 写代码时最常见的几个界面放到同一个地方：聊天、文件改动、权限、项目、远程入口、模型配置。

安装和启动方式

普通用户更适合从 Releases 下载桌面端安装包。

项目 README 给出的桌面端安装流程是：

前往 GitHub Releases 下载 macOS 或 Windows 安装包。
首次启动后，在桌面端设置里配置模型提供商、API Key 和默认模型。
如果 macOS 提示应用无法打开，按安装指南处理 Gatekeeper 权限。

最新 release 页面显示，v0.2.6 发布于 2026-05-13。这个版本主要围绕 H5 手机访问安全恢复、桌面会话管理、文件提及搜索和桌面体验细节。

如果想从源码启动 CLI，README 给出的命令是：

1
2
3

bun install
cp .env.example .env
./bin/claude-haha

这个路径更适合想调试底层 CLI、服务端或自行开发的人。普通使用还是桌面端更直接。

v0.2.6 更新了什么

v0.2.6 的重点是把 H5/LAN 访问从临时放行收回到显式开启和 token 配对模型。

几个值得注意的变化：

H5/LAN 访问需要本地显式开启。
QR 链接会携带一次性显示的 token。
远程 API、proxy 和 WebSocket 不再裸露。
Settings 新增独立 H5 Access 页面。
桌面侧边栏增加批量管理模式，支持多选和删除会话。
桌面文件提及搜索改为 git-first，遵守 ignore 规则，减少 node_modules 和构建产物噪声。
新增纯白主题，修复长 URL 撑破聊天布局、多 tab 草稿串台等问题。

这说明项目已经不只是“能跑”，而是在补桌面产品需要的安全边界和日常体验。

尤其是 H5 访问这一块，作者在 release 里明确提醒：H5 是给个人或可信团队使用的浏览器访问入口，不是公开多租户登录系统。实际使用时，不应该把它当成公网开放的 SaaS 登录后台。

Computer Use：让 Agent 操作桌面

cc-haha 另一个重要卖点是 Computer Use。

项目文档说明，这个功能基于 Claude Code 泄露源码中的 Computer Use 内部实现改造而来。官方实现依赖 Anthropic 内部私有原生模块，例如 @ant/computer-use-swift 和 @ant/computer-use-input，无法公开获取。cc-haha 用 Python bridge 替换底层操作层，通过 pyautogui、mss、pyobjc 等公开库实现系统交互。

Computer Use 支持的操作包括：

截屏：screenshot、zoom
鼠标：点击、拖拽、移动、滚动、读取光标位置
键盘：输入文字、按键、按住按键
应用：打开应用、切换显示器
权限：请求应用授权、列出已授权应用
剪贴板：读取和写入剪贴板
其他：等待、批量操作

它的工作方式是一个“截图 - 分析 - 操作”的闭环：

模型收到用户请求。
调用 screenshot 获取屏幕画面。
模型根据视觉能力识别按钮、输入框和坐标。
调用点击、输入或应用操作工具。
再次截图确认结果，再继续下一步。

从文档看，完整支持的平台主要是 macOS，包括 Apple Silicon 和 Intel。Windows / Linux 在理论上可行，但涉及 pyobjc 的应用管理部分需要替换为对应平台方案，当前并不是完整适配状态。

运行要求包括：

Bun >= 1.1.0
Python >= 3.8
macOS Accessibility 辅助功能权限
macOS Screen Recording 屏幕录制权限

这类功能很强，但也意味着权限风险更高。让 AI 操作桌面应用时，最好只授权明确需要的应用，不要在无关窗口里打开敏感内容。

多模型接入：通过 Anthropic 协议兼容层

cc-haha 的通信基础仍然是 Anthropic Messages API 协议。项目文档给出的推荐方案是用 LiteLLM 做协议转换代理。

基本结构是：

`1`	`claude-code-haha ──Anthropic协议──▶ LiteLLM Proxy ──OpenAI协议──▶ 目标模型 API`

也就是说，cc-haha 发出 Anthropic Messages API 请求，LiteLLM 把它转换成 OpenAI Chat Completions 等格式，再转发给 OpenAI、DeepSeek、Ollama 或其他模型服务。

文档给出的 LiteLLM 安装方式是：

`1`	`pip install 'litellm[proxy]'`

然后可以在 litellm_config.yaml 里配置 OpenAI、DeepSeek、Ollama 等模型。启动代理后，在 .env 或 ~/.claude/settings.json 里设置：

ANTHROPIC_AUTH_TOKEN=sk-anything
ANTHROPIC_BASE_URL=http://localhost:4000
ANTHROPIC_MODEL=gpt-4o
ANTHROPIC_DEFAULT_SONNET_MODEL=gpt-4o
ANTHROPIC_DEFAULT_HAIKU_MODEL=gpt-4o
ANTHROPIC_DEFAULT_OPUS_MODEL=gpt-4o
API_TIMEOUT_MS=3000000
DISABLE_TELEMETRY=1
CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1

这里有几个实际注意点：

drop_params: true 很重要，因为 Anthropic 的 thinking、cache_control 等参数在 OpenAI API 中不存在。
Extended Thinking 属于 Anthropic 专有能力，使用第三方模型时不可用。
Prompt Caching 也不会按 Anthropic 原生方式生效。
工具调用会经过 Anthropic tool_use 到 OpenAI function calling 的转换，复杂工具调用可能存在兼容性问题。
本地 Ollama 小模型未必能稳定处理这套工具调用流程。

所以多模型接入能跑，不等于所有模型体验一样。cc-haha 对模型的工具调用、代码理解和长上下文能力要求仍然不低。

适合什么人

cc-haha 更适合这几类用户：

已经熟悉 Claude Code，但想要桌面端会话管理的人。
经常同时处理多个仓库、分支和 AI 会话的人。
希望在右侧直接看 AI 文件改动、Diff 和工作区状态的人。
想尝试 Computer Use，让 Agent 操作桌面应用的人。
想用 Anthropic 协议接入 OpenAI、DeepSeek、Ollama 或其他模型的人。
需要手机或 IM 远程查看会话、审批权限的人。

不太适合：

只想稳定使用官方 Claude Code 的用户。
不能接受泄露源码背景和版权不确定性的人。
不愿意给本地工具较高系统权限的人。
需要企业合规、审计和官方支持的人。
不熟悉 API key、代理、模型兼容和本地服务配置的人。

风险和边界

这篇文章不能只讲功能，也必须讲风险。

cc-haha 的来源决定了它不是一个普通的社区重写项目。README 明确写到它基于泄露的 Claude Code 源码，且原始源码版权归 Anthropic 所有。这会带来版权、合规和长期维护上的不确定性。

另外，Computer Use、H5 远程访问、IM 接入和本地权限审批都属于高权限能力。它们越方便，越需要清楚边界：

不要在不可信网络下开放 H5 访问。
不要把 token 当作长期公开登录凭证。
不要给 Agent 操作不相关的敏感应用。
不要在生产环境或公司合规环境里随意接入。
不要把第三方模型代理和 API key 配置暴露到公共仓库。

如果只是学习 AI 编程工具架构、桌面端工作流和 Computer Use 实现，它很有参考价值。如果要放进长期生产工作流，就要先评估法律、权限、安全和维护风险。

总结

cc-haha 最值得关注的地方，不是“它能不能复刻 Claude Code”，而是它把 Claude Code 类型的 AI 编程工具推向了桌面工作台形态。

会话、项目、Worktree、Diff、权限、远程访问、Computer Use、多模型提供商、定时任务和 token 用量统计都被放进同一个桌面体验里。这说明 AI 编程工具的下一步，不只是模型更强，也包括工作流界面更完整。

不过它的边界也很清楚：这不是 Anthropic 官方产品，来源存在敏感背景，高权限能力需要谨慎使用。更合适的态度是把它当成一个观察 AI 编程工具演化方向的项目，而不是无脑替代官方 Claude Code。

参考资料

GitHub 仓库：https://github.com/NanmiCoder/cc-haha
最新 Release：https://github.com/NanmiCoder/cc-haha/releases/tag/v0.2.6
Computer Use 文档：https://github.com/NanmiCoder/cc-haha/blob/main/docs/computer-use.md
第三方模型文档：https://github.com/NanmiCoder/cc-haha/blob/main/docs/guide/third-party-models.md

Codex /goal vs Claude Code /goal：长任务自动跑到完成

Thu, 14 May 2026 22:22:42 +0800

/goal 正在变成 AI 编程工具里的一个重要命令。

它解决的不是“让模型多写几行代码”，而是另一个更实际的问题：当任务有明确完成条件时，能不能让 Agent 持续推进，直到条件满足，而不是每完成一轮就停下来等用户继续催。

Codex CLI 已经在官方文档里加入了实验性的 /goal。Claude Code 也上线了自己的 /goal 文档，而且把它描述成一种可以跨多轮持续工作的自动化能力。两者名字一样，但产品取向并不完全一样。

`/goal` 到底解决什么问题

普通 AI 编程对话通常是“一问一答”：

用户提出任务。
Agent 分析、改代码、跑测试。
Agent 汇报结果。
用户再决定下一步。

这个流程适合短任务，但遇到迁移、重构、测试修复、issue backlog 清理时，就会变得很碎。Agent 可能每次只推进一小段，然后停下来等你输入“继续”。

/goal 的思路是把任务从“下一步做什么”改成“最终什么状态算完成”。例如：

`1`	`/goal 完成登录模块迁移，所有 auth 测试通过，lint 无报错`

这类目标天然适合长任务，因为它有清楚的终点：测试通过、构建成功、文件拆分完成、队列清空、验收条件满足。

Codex 的 `/goal`：实验功能，绑定当前线程

OpenAI 的 Codex CLI 文档把 /goal 标为实验功能。它不是默认稳定能力，需要先开启 features.goals。

开启方式有两种：

`1`	`/experimental`

或者在 config.toml 里加入：

1
2

[features]
goals = true

启用后，可以这样使用：

`1`	`/goal Finish the migration and keep tests green`

常用命令包括：

/goal
/goal pause
/goal resume
/goal clear

按照 OpenAI 文档的说法，Codex 会把 goal 附着在当前 active thread 上，在更大的任务运行过程中持续跟踪这个目标。

这里要注意一个细节：官方文档对 Codex /goal 的措辞比较克制。它强调“给长任务设置实验性目标”“把目标附着到当前线程”，但没有像 Claude Code 文档那样展开说明每一轮结束后由独立 evaluator 自动判断并继续下一轮。所以现在使用 Codex /goal 时，最好仍把它看作实验中的长任务目标机制，而不是完全稳定的无人值守执行模式。

Claude Code 的 `/goal`：完成条件驱动的多轮执行

Claude Code 的 /goal 文档写得更明确：用户设置 completion condition 后，Claude 会跨 turn 持续工作，直到条件满足。

示例：

`1`	`/goal all tests in test/auth pass and the lint step is clean`

Claude Code 的机制大致是：

当前 turn 完成后，不直接把控制权还给用户。
一个小型快速模型会检查目标条件是否已经满足。
如果没有满足，Claude 自动开始下一轮。
如果满足，goal 自动清除，并在 transcript 里记录完成状态。

这意味着 Claude Code 的 /goal 更像“按完成条件自动续跑”。它不只是把目标挂在会话里，而是把“是否继续下一轮”交给一个独立评估步骤。

Claude Code 还支持直接查看状态：

/goal

状态里会显示目标条件、运行时间、已评估 turn 数、token 消耗，以及 evaluator 最近一次给出的原因。

如果要提前停止，可以使用：

`1`	`/goal clear`

stop、off、reset、none、cancel 也可以作为清除别名。开启目标后，如果会话中断，之后通过 --resume 或 --continue 恢复时，仍然 active 的 goal 可以被带回来；但计时、turn 数和 token 基线会重新计算。

两者最大的差异

Codex 和 Claude Code 都在把 AI 编程从“单轮回答”推向“长任务执行”，但 /goal 的定位有差异。

对比项	Codex CLI `/goal`	Claude Code `/goal`
状态	experimental	官方文档单独成页说明
启用方式	需要开启 `features.goals`	可直接在受信任 workspace 使用
目标作用域	当前 active thread	当前 session
常用操作	set / view / pause / resume / clear	set / view / clear
自动判断	文档强调目标附着与跟踪	明确说明每轮后由 evaluator 判断
自动续跑	文档表述较克制	条件未满足时自动下一轮
适合场景	想在 Codex 长任务里保持目标上下文	想按完成条件让 Claude Code 持续推进

简单说，Codex 的 /goal 更像“给当前线程挂一个实验性的长期目标”；Claude Code 的 /goal 更像“给当前会话设置一个可验证的停止条件，让它自动干到满足为止”。

写好 `/goal` 的关键

不管使用哪一个工具，/goal 都不适合写成模糊愿望。

不太好的写法：

`1`	`/goal 把项目优化一下`

更好的写法：

`1`	`/goal 将 payment 模块迁移到新 API，npm test -- payment 退出码为 0，git diff 只包含 payment 相关文件`

一个好目标通常包含三点：

明确的完成状态。
可执行的验证方式。
必须遵守的边界。

如果目标太大，还应该加上停止条件：

`1`	`/goal 修复 eslint 报错，npm run lint 退出码为 0；如果超过 20 轮仍未完成，停止并总结剩余问题`

这很重要。/goal 越强，越需要边界。否则 Agent 可能会为了追求“完成”而改动过多文件、跑太久、消耗太多 token，甚至把原本该停下来询问的问题继续往前推。

什么时候适合用 `/goal`

适合：

测试修复：直到指定测试通过。
代码迁移：直到所有调用点改完并编译成功。
批量清理：直到某类 lint 或类型错误清零。
文档补齐：直到所有指定模块都有说明。
issue 队列处理：直到某个标签下的问题都被处理或明确分类。

不适合：

需求本身还没想清楚。
需要频繁产品判断。
涉及高风险删除、数据迁移或权限变更。
验收条件只能靠主观判断。
任务会跨越大量无关模块。

一个实用原则是：如果你能写出“跑哪个命令、看到什么结果、哪些文件不能碰”，就适合用 /goal。如果只能写“帮我做得更好”，那还是先用普通对话、计划模式或人工评审更稳。

对 AI 编程工具的影响

/goal 代表一个很明显的方向：AI 编程工具正在从“交互式助手”变成“可持续执行的工作单元”。

过去我们让 Agent 做任务，经常要在旁边守着。它卡住了要提示，测完了要继续，报错了要再下命令。/goal 把这部分交互压缩成一个完成条件，让 Agent 自己决定下一轮该做什么。

但这也带来新的要求。以后写 prompt 不只是描述任务，还要写验收条件、验证命令、修改边界和停止规则。换句话说，用户的工作从“催它继续”变成“定义什么叫完成”。

Codex 和 Claude Code 走到 /goal 这一步，说明长任务 Agent 已经不再只是后台任务或云端队列的专利。终端里的本地编程工具，也开始需要更强的自主推进能力。

总结

Codex CLI 和 Claude Code 都有了 /goal，但现阶段不要把它们简单看成同一个功能。

Codex 的 /goal 仍是实验能力，需要开启 features.goals，更适合在 Codex 当前线程里维持长期目标。Claude Code 的 /goal 则更明确地把“完成条件”和“自动续跑”连在一起，通过独立 evaluator 判断是否继续。

对日常开发来说，这类命令最适合处理有明确验收标准的工程任务。它不会替代需求判断，也不会消除代码审查，但能减少长任务里大量重复的“继续”“再跑一次”“修到测试通过”。

真正要学会的不是某个命令本身，而是如何把任务写成清楚、可验证、可停止的目标。

参考资料

OpenAI Codex CLI Slash Commands：https://developers.openai.com/codex/cli/slash-commands
Claude Code Goal 文档：https://code.claude.com/docs/en/goal

AI 编程工具这一轮，DeepSeek 为何成了省钱关键？

Mon, 11 May 2026 04:59:00 +0800

这一轮 AI 编程工具的竞争，表面上是在比模型能力、插件生态和 agent 自动化程度，真正用起来以后，最先撞上的问题却是成本。

Claude Code、Codex、OpenClaw、Superpowers 这类工具都很好用，但它们有一个共同特点：一旦进入复杂任务，就会非常吃 token。它们要读项目、建计划、调用工具、总结上下文、反复检查结果，还可能拉起多个子任务。模型越聪明，工作流越自动化，账单也越容易悄悄变大。

所以 DeepSeek 在这一轮里变得很关键，不只是因为它能写代码，而是因为它在长上下文和缓存成本上，刚好打中了 AI 编程工具最烧钱的地方。

Agent 工具为什么特别费 token

传统聊天式编程助手，通常是一问一答。你问一个函数怎么写，它回答一段代码。这个模式消耗不小，但还算可控。

Agent 工具不一样。它不是只回答问题，而是要像一个临时工程师一样进入项目：

先扫描目录和关键文件；
再理解需求和现有架构；
然后制定计划；
修改文件；
运行命令或测试；
根据报错继续修；
最后总结改了什么。

这个过程里，模型反复读取同一批上下文。项目说明、代码片段、工具结果、历史对话、计划和错误日志都会被塞回上下文。任务稍微复杂一点，几十万 token 很快就出去了。

如果再装一些更激进的插件，成本会更明显。比如有些 OpenCode 或 Claude Code 增强工具，会默认组织一整套 agent 团队。你只是想改一个小功能，它也可能启动规划、审查、执行、复盘等多个环节。任务当然显得更“智能”，但 token 也会一路往上跑。

Superpowers 的好处是按需触发

Superpowers 这类工具的一个优点，是它不会在所有任务里都强行拉起完整 agent 流程。

平时你还是可以让 Claude Code、OpenCode 或 Codex 按原来的方式工作。只有当你明确调用某个 skill，比如头脑风暴、写计划、执行计划、做复盘时，它才进入更重的自动化流程。

这对成本很重要。

AI 编程不应该所有任务都用重武器。改一行配置、查一个报错、写一个小脚本，用普通对话就够了；只有复杂重构、跨文件修改、长文档处理、多轮验证，才值得上完整 agent 流程。

工具越强，越要学会控制触发条件。否则自动化越多，浪费越多。

DeepSeek 的关键优势是缓存便宜

DeepSeek 适合接这类 agent 工具，一个很重要的原因是缓存命中成本低。

AI 编程任务里有大量重复前缀。比如项目背景、系统提示词、工具说明、文件内容、前几轮对话，经常会在后续请求里反复出现。如果模型服务支持 prompt cache，这些重复内容命中缓存后，成本会明显下降。

很多模型的缓存命中价只是比未命中便宜一些，比如便宜到三分之一左右。DeepSeek 的优势在于，命中缓存后的价格差距可以大很多。对长上下文、多轮调用、重复读取项目的 agent 工作流来说，这个差距会直接反映到账单上。

也就是说，DeepSeek 不是每一次回答都一定最强，而是在“长任务、多轮任务、反复读上下文”的场景里，成本结构特别适合 AI 编程。

长上下文让 Claude Code 更好用

把 Claude Code 或类似工具接到 DeepSeek V4 时，另一个明显优势是长上下文。

AI 编程工具最怕上下文不够。上下文一不够，就要频繁压缩；压缩一多，前面读过的细节就可能丢失。模型开始忘记项目结构、忘记约束、忘记某个文件为什么这么改，后续质量就会下降。

DeepSeek V4 系列的长上下文能力，让它更适合处理代码仓库、文档批处理、字幕翻译、站点文章整理这类任务。特别是接入 Claude Code、OpenClaw 这类工具时，如果配置得当，可以让它尽量晚一点进入上下文压缩，让模型保留更多项目细节。

这也是为什么有些任务用 DeepSeek 会显得“很经使”：它不一定每一步都惊艳，但能承受长时间、低成本、反复调用。

V4 Pro 和 V4 Flash 怎么分工

DeepSeek V4 Pro 和 V4 Flash 不应该混着用。

简单任务用 DeepSeek V4 Flash 更合适。它速度快、成本低，用在下面这些场景通常足够：

翻译字幕；
整理文档；
生成普通脚本；
修改小范围代码；
跑 OpenClaw 里的轻量任务；
做简单的站点内容处理。

复杂任务再考虑 DeepSeek V4 Pro：

大规模重构；
多模块代码理解；
复杂推理；
长链路 agent 任务；
高风险代码修改；
需要更强规划能力的工程任务。

很多人一上来就想挂最强模型，这反而不划算。AI 编程工具最现实的玩法，是把任务分层：便宜模型吃掉大量常规工作，贵模型只处理关键节点。

MiniMax、豆包和 DeepSeek 的位置不同

国产模型和套餐里，MiniMax、豆包、Kimi、DeepSeek 各有位置。

MiniMax 的优势是量大、便宜、功能全。它未必是最聪明的编程模型，但拿来做翻译、轻量整理、批处理，很划算。比如批量处理字幕、改格式、做简单校对，MiniMax 这类套餐很耐用。

豆包的优势是生态工具比较全，图片、视频、搜索、TTS、可能的 STT 和 embedding 都能接在一起。它更像综合型工具箱。

DeepSeek 的位置更明确：文本、代码、长上下文、低成本缓存。它没有完整的图像生成、语音、视频生态，短板很明显；但在 AI 编程和长文本 agent 工作流里，它的长板足够长。

所以不是谁替代谁，而是任务拆开以后各用各的。

省钱的关键不是只找便宜模型

AI 编程想省钱，不是简单把所有请求都换成便宜模型。

真正有效的省钱方式有几条：

简单任务不要启动重 agent。
能用 Flash 的任务不要上 Pro。
长任务尽量利用缓存。
重复上下文要稳定，避免无意义改动导致缓存失效。
大任务先让便宜模型做草稿和批处理，再让强模型做关键审查。
明确告诉 agent 不要重复描述事实，不要反复总结同一件事。

尤其是最后一点很重要。AI 工具很容易啰嗦，啰嗦不只是阅读体验问题，也是成本问题。提示词里明确要求“事实只描述一次，观点只表达一次”，能同时改善文章质量和 token 消耗。

DeepSeek 适合哪类 AI 编程工作流

DeepSeek 最适合这些任务：

长代码仓库阅读；
多文件轻量修改；
批量文档整理；
批量字幕翻译；
Hugo 文章整理；
agent 计划执行；
大量重复上下文的低成本自动化。

它不一定适合所有任务。如果要做特别强的前端审美、复杂产品判断、跨模态创作，可能还要搭配 Claude、GPT、Gemini、豆包或其他工具。

但只要任务是“长文本、长上下文、反复调用、成本敏感”，DeepSeek 就很容易变成首选。

小结

AI 编程工具这一轮，DeepSeek 的价值不只是“国产模型能写代码”，而是它解决了 agent 工具最现实的痛点：长任务太烧钱。

Claude Code、OpenClaw、Superpowers 这类工具会让开发流程越来越自动化，但自动化的背后是大量上下文读写和多轮调用。谁能把这部分成本压下来，谁就能让 AI 编程从“偶尔爽一下”变成“天天用得起”。

DeepSeek 的长上下文、低缓存成本和 V4 Flash / V4 Pro 分层使用，正好让它站在这个位置上。

这一轮真正省钱的关键，不是不用好模型，而是把好模型、便宜模型、缓存和 agent 流程搭配好。能把这套账算明白，AI 编程工具才真的会变成生产力，而不是一个漂亮但昂贵的玩具。

AI Coding 套餐怎么选：轻度看顺手，重度看灵活性

Sun, 10 May 2026 08:20:58 +0800

AI Coding 套餐这半年变化很快。很多工具从“按次”转向“按量”，免费或低价套餐的额度被收紧，部分海外服务还增加了身份验证、地区限制和更严格的用量规则。

对开发者来说，问题已经不只是“哪个模型最强”，而是：每个月要花多少钱、额度是否够用、工具是否顺手，以及当某个套餐突然涨价或改规则时，能不能平滑切换。

一个比较实用的结论是：轻度用户买顺手的工具，中度用户买性价比，重度用户买灵活性。使用越重，越不要把模型和工具绑死在同一个套餐里。

选套餐先看四件事

过去选 AI Coding 套餐，通常看三点：

模型能力是否足够强。
响应速度是否稳定。
套餐额度是否够用。

现在还要加上第四点：模型和工具能不能分开。

模型负责推理能力，工具负责上下文管理、文件编辑、Agent 编排和工作流体验。两者都重要，但最好不要完全绑定。比如喜欢 Claude 模型，可以买官方套餐，也可以通过 API 接到其他工具里；喜欢某个编辑器或 Agent 工具，也最好确认它能接入不同模型，而不是只能使用自家套餐。

这样做的好处不是折腾，而是降低风险。AI Coding 是变化最快的赛道之一，今天额度宽松的套餐，过两个月可能就改计费；今天好用的工具，下一版也可能因为模型接口变化而体验下降。把模型和工具分开，等于给自己留了迁移空间。

海外套餐正在收紧

GitHub Copilot、Cursor、Windsurf、Claude Code 这类工具仍然是很多人的主力选择，但整体趋势已经很明确：低价高额度越来越难维持，按量计费越来越常见。

GitHub Copilot 这类服务开始更强调使用量计费后，套餐本身的“套利空间”会明显减少。对轻度用户来说，它仍然方便；但对高频使用 Agent、长上下文和复杂代码任务的人来说，实际消耗会更接近真实 API 成本。

Cursor 和 Windsurf 本质上是把模型能力包进 IDE 体验里。它们的优势是开箱即用、编辑器体验成熟，缺点是工具绑定较深。一旦你依赖其中的专属 Agent、索引和自动化流程，后续迁移成本会越来越高。

Claude Code 的体验和生态热度很高，但海外订阅、身份验证、地区限制、中转服务安全性，都会成为国内用户需要额外评估的风险。尤其是第三方中转服务，可能存在模型掺杂、稳定性不足、数据安全和跑路风险，不适合作为重要项目的长期基础设施。

国产套餐的优点和短板

国产 AI Coding 套餐的一个优点，是很多服务以 API 形式提供，天然不太锁定工具。你可以把模型接入 OpenCode、Cline、Continue、自己的脚本或内部 Agent。

短板也很明显：如果同时要求模型强、速度快、额度足，很少有一个套餐能全部满足。

GLM 系列在国产模型里能力较强，但高峰期吞吐可能不稳定，重度任务容易被速度卡住。Kimi 的能力不错，但价格和额度规则需要持续关注，尤其要看后台额度是否透明。MiniMax 这类模型速度和额度较友好，适合日常轻任务、批处理和不太复杂的代码辅助，但在复杂工程推理上可能略低一档。DeepSeek 新模型如果处在活动价或优惠期，性价比会很高；活动结束后，就要重新按官方价格和套餐规则评估。

所以国产方案更适合作为“模型池”使用：不同任务用不同模型，而不是押注一个模型包打天下。

轻度用户：选顺手的，不必折腾 API

如果一周只是让 AI 改脚本、补文档、解释报错、写一点小工具，不需要复杂配置。

这类用户优先选顺手的产品。Cursor、Windsurf、Trae、CodeBuddy、通义灵码、GitHub Copilot 之类都可以尝试。重点不是追求最低单价，而是减少使用门槛：能在你常用编辑器里稳定工作、补全质量不错、出错时容易回退，就足够了。

轻度用户不建议为了省一点钱去折腾多层 API、中转站和复杂代理。时间成本、账户风险和排错成本往往高于节省下来的订阅费。

中度用户：看性价比，也看可迁移性

如果每天都会用 AI 写代码、改项目、生成测试、整理文档，就要开始关注额度和实际消耗。

这类用户可以把主力工具和备用模型分开安排。比如一个顺手的 IDE 套餐负责日常编辑，再配一个可接入多工具的 API 或聚合套餐，处理更长上下文、更复杂的 Agent 任务。

选择时可以重点看三点：

是否支持接入第三方工具。
是否能清楚看到 token 或额度消耗。
超额后是限速、降级、停止服务，还是按量付费。

如果一个套餐看起来便宜，但只允许在自家工具里使用，就要把迁移成本算进去。如果一个套餐贵一点，但能接入多种工具，反而可能更适合作为长期主力。

重度用户：不要把模型和工具绑死

重度用户的核心诉求是灵活性。

当一个人或团队每天大量使用 AI Agent，消耗会非常快。复杂代码库检索、长上下文修改、多轮调试、自动化测试修复，都会让 token 消耗成倍增长。此时再依赖单一套餐，很容易遇到三个问题：

额度突然不够。
计费规则突然改变。
某个工具或模型临时不可用。

更稳妥的做法是准备多层组合：一个主力 Agent 工具，一个或多个可替换模型接口，一个低成本模型处理简单任务，一个高能力模型处理复杂任务。日常小任务不要都交给最贵模型，关键任务也不要只依赖最便宜模型。

对重度用户来说，“工具能接任意模型，模型能接入任意工具”比单月便宜几十美元更重要。因为真正贵的不是订阅费，而是工作流被某个生态锁死后，迁移和重建习惯的成本。

一个更稳的组合思路

比较稳妥的组合可以这样安排：

轻任务用低成本模型：解释代码、写小脚本、改格式、生成简单文档。
中等任务用性价比模型：常规功能开发、测试补全、重构建议。
难任务用强模型：复杂架构调整、跨文件修复、疑难 bug、长上下文推理。
工具层保持开放：尽量选择能接 API、能导出配置、能切换模型的工具。
保留备用方案：主力套餐改规则时，可以快速切到另一个模型或工具。

这样不一定最省钱，但更抗波动。AI Coding 套餐的价格和额度还会继续变化，真正值得长期投入的是可迁移的工作流，而不是某个短期看起来特别划算的套餐。

小结

AI Coding 套餐不适合只看单月价格。轻度用户应该少折腾，选一个顺手的工具；中度用户要开始看额度、消耗和可迁移性；重度用户则要把模型和工具解耦，避免被单一生态绑定。

现在最值得记住的一点是：套餐会变，模型会变，工具也会变。把选择权留在自己手里，才是长期使用 AI Coding 工具时最重要的成本控制。

Claude Code 限额翻倍：Anthropic 借 SpaceX 算力扩容缓解使用限制

Sat, 09 May 2026 10:59:48 +0800

Anthropic 在 2026 年 5 月 6 日宣布，将提高 Claude Code 和 Claude API 的使用限额，并与 SpaceX 达成新的算力合作。对普通用户来说，最直接的变化是 Claude Code 可用额度变多；对开发者和企业来说，重点是 Claude 的推理容量正在继续扩张。

这次公告可以拆成两部分看：

Claude Code 与 Claude API 的限额提升。
Anthropic 通过 SpaceX 数据中心获得新的算力容量。

Claude Code 限额有哪些变化

Anthropic 表示，下面三项变化从公告当天开始生效：

Claude Code 的五小时 rate limit 对 Pro、Max、Team 和 seat-based Enterprise 计划翻倍。
Pro 和 Max 账号的 Claude Code 高峰时段限额降低被取消。
Claude Opus 模型的 API rate limits 明显提高。

也就是说，如果你经常用 Claude Code 做长时间代码任务、仓库分析、重构、调试或 Agent 工作流，这次变化可能会直接减少“还没做完就到限额”的情况。

不过需要注意，限额提高不等于无限使用。Claude Code 仍然会受订阅计划、使用方式、模型、任务长度、上下文大小和平台策略影响。只是相比之前，Anthropic 明确给出了更大的使用空间。

为什么算力会影响 Claude Code 体验

Claude Code 这类工具比普通聊天更吃资源。一次代码任务可能会包含：

读取大量文件。
长上下文分析。
多轮工具调用。
生成、修改和检查代码。
反复运行测试或解释错误。
使用 Opus 模型处理复杂推理。

这些操作背后消耗的不只是 token，还有模型推理容量、并发能力和调度资源。用户看到的是“限额”“排队”“高峰时段变慢”，平台看到的是算力供给和需求之间的压力。

所以这次 Anthropic 把限额提升和算力合作放在同一篇公告里，本质上是在说明：Claude Code 体验的改善不是单纯改一个套餐规则，而是依赖后端推理容量扩张。

SpaceX 合作带来什么

Anthropic 表示，已经与 SpaceX 签署协议，将使用 SpaceX Colossus 1 数据中心的全部算力容量。官方提到，这部分容量超过 300 兆瓦，对应 22 万块以上 NVIDIA GPU，并将在一个月内提供给 Anthropic 使用。

这部分新增容量会直接改善 Claude Pro 和 Claude Max 订阅用户的可用容量。

公告中还提到，Anthropic 对未来与 SpaceX 合作开发轨道 AI 算力表示兴趣。不过这更像长期方向，和当前用户马上能感受到的 Claude Code 限额提升不是同一层面的事情。

Anthropic 的算力布局正在变大

SpaceX 只是 Anthropic 近期算力扩张的一部分。官方同时列出了其他合作：

与 Amazon 的最高 5GW 合作，其中接近 1GW 新容量计划在 2026 年底前上线。
与 Google 和 Broadcom 的 5GW 合作，预计从 2027 年开始上线。
与 Microsoft 和 NVIDIA 的战略合作，包含 300 亿美元 Azure 容量。
与 Fluidstack 的 500 亿美元美国 AI 基础设施投资。

Anthropic 还强调，Claude 的训练和运行会使用多种 AI 硬件，包括 AWS Trainium、Google TPU 和 NVIDIA GPU。

这说明一个趋势：头部模型公司的竞争不只在模型参数、榜单成绩和产品形态，也在电力、数据中心、GPU、TPU、网络和全球部署能力。

对 Claude Code 用户的实际影响

对开发者来说，这次最值得关注的是 Claude Code 的五小时限额翻倍。它会影响这些场景：

大型仓库代码阅读。
多文件重构。
Bug 排查和测试修复。
代码迁移与依赖升级。
长时间 Agent 编程任务。
Team 或 Enterprise 中多人同时使用 Claude Code。

过去使用 Claude Code 时，一个常见问题是任务还在推进，但额度已经到顶。限额提升后，开发者更容易让 Agent 把一个完整任务走完，而不是中途停下。

如果你是 Pro 或 Max 用户，取消高峰时段限额降低也很关键。它意味着晚高峰或使用高峰期的体验可能更稳定，不会因为平台临时收紧额度而明显影响 Claude Code 工作流。

对 API 用户的意义

公告中还提到，Claude Opus 模型的 API rate limits 得到明显提升。对于使用 Opus 做复杂任务的团队，这通常意味着：

更高并发。
更少 429 限流。
更容易支撑批量任务。
更适合长上下文、复杂推理和 Agent 工作流。

不过具体限额会因账户、组织、模型和计划不同而变化。实际部署前，仍然需要看自己的 Anthropic Console、rate limits 文档和错误日志。

企业和区域部署也在变重要

Anthropic 在公告里还提到，金融、医疗、政府等受监管行业越来越需要区域内基础设施，以满足合规和数据驻留要求。因此，部分容量扩张会放在美国以外地区，尤其是亚洲和欧洲的推理能力。

这对企业客户很重要。大模型应用进入核心业务后，问题不只是“模型好不好用”，还包括：

数据是否留在指定区域。
是否满足行业合规要求。
高峰期是否有稳定容量。
是否能支撑团队级和组织级并发。
是否有审计、权限和安全控制。

从这个角度看，算力扩容不只是性能新闻，也会影响企业采购和部署决策。

总结

Anthropic 这次公告的核心信息很直接：Claude Code 和 Claude API 的使用限制正在放宽，背后原因是新的算力容量正在上线。

对普通 Claude Code 用户来说，最重要的是五小时限额翻倍，以及 Pro、Max 高峰期限额降低取消。对 API 和企业用户来说，更值得关注的是 Opus rate limits 提升，以及 Anthropic 在 SpaceX、Amazon、Google、Microsoft、NVIDIA、Fluidstack 等合作中的长期算力布局。

AI 工具越来越像基础设施服务。模型能力是一部分，稳定容量、区域合规、限额策略和成本控制，同样会决定用户体验。

参考链接：

Anthropic：Higher usage limits for Claude and a compute deal with SpaceX

Claude 账号被封怎么办？Claude Code 受限原因与申诉指南

Sat, 09 May 2026 10:32:12 +0800

Claude 或 Claude Code 账号突然被限制、刚充值后被封、Pro 权限异常、用量突然变少，这类问题近来被很多用户反复讨论。真正需要注意的是：不要把它简单理解成“换个节点”“换个账号”就能解决的技术问题。账号风控通常和地区、支付、设备、登录行为、使用内容、自动化调用、共享方式等多种信号有关。

更稳妥的处理方式，是先判断自己遇到的是哪类问题：是普通用量限制、支付订阅异常、Claude Code 授权问题，还是 Anthropic 认为账号违反了使用政策或服务条款。

先区分三类情况

第一类是正常限额。Claude Pro、Max、Team、API 和 Claude Code 的额度机制不同，高峰期、长上下文、代码任务、Agent 任务都会更快消耗额度。看到“limit reached”不一定是封号，可能只是当前周期的使用量耗尽。

第二类是订阅或授权异常。比如刚充值但权限没刷新、移动端订阅和网页账号不同步、Claude Code 没有正确登录、环境变量里还残留旧的 ANTHROPIC_API_KEY。这类问题通常应该从账单、登录状态和客户端配置排查。

第三类才是账号暂停或封禁。常见表现是收到 suspension、disabled、terminated 一类邮件，或者登录时直接提示账号不可用。这时就不要继续反复换设备、换网络、换账号尝试登录，因为这可能让风控信号更复杂。

常见触发因素

Anthropic 官方帮助文档和隐私说明里提到过几类常见风险信号：违反 Usage Policy、从不支持地区创建或使用账号、违反服务条款、重复违规、异常访问或滥用行为。

实际使用中，容易触发风险的场景包括：

账号注册、登录和支付地区不一致。
长期使用数据中心代理、共享代理或频繁切换 IP。
多人共用一个个人账号。
短时间内在多台设备、多地区频繁登录。
使用自动化脚本高频访问 Claude.ai。
把 Claude Code 当作共享服务或转售入口。
请求明显违反 Anthropic 使用政策的内容。
支付方式、账单地址、账号地区互相冲突。

这里的关键不是“某一个信号必封”，而是多个异常信号叠加后，系统更容易把账号判断为高风险。

不建议用“规避风控”的思路解决

网上经常会出现所谓“稳定使用方案”，例如指纹浏览器、设备指纹重置、清空本地目录、换环境、固定时区语言、换邮箱继续注册等。这类说法里有些只是普通环境排查，有些则明显是在规避平台风控。

不建议把“绕过风控”当成解决方案。原因很简单：

它可能违反服务条款。
它可能让账号风险信号进一步增加。
它不能解决支付、地区、政策违规等根本问题。
一旦涉及团队或商业使用，后续申诉会更难解释。

如果你的目标是长期稳定使用 Claude，正确方向不是伪装，而是让账号、地区、支付、设备和用途都尽量真实、一致、可解释。

Claude Code 受限怎么排查

Claude Code 用户遇到问题时，可以先按下面顺序检查：

1
2

claude --version
claude auth status

如果使用 API key，也要确认环境变量是否指向了正确账号：

`1`	`echo $ANTHROPIC_API_KEY`

在 Windows PowerShell 中可检查：

`1`	`echo $env:ANTHROPIC_API_KEY`

如果你同时用过网页登录、OAuth、API key、第三方客户端或不同终端，建议先统一认证方式，避免一个工具还在使用旧凭据。

还要区分两种情况：

Claude Code 用量到达上限：通常是额度或订阅限制。
账号或组织被 disabled：通常是账号、组织、支付或政策层面的风险。

前者可以等额度刷新或调整订阅；后者应保留提示截图和邮件，走官方支持或申诉流程。

稳定使用的合规建议

想降低账号异常概率，建议从这些基础做起：

使用受支持国家或地区的正常账号。
尽量保持登录地区、支付方式和账单信息一致。
避免多人共享个人账号。
不要把个人 Pro/Max 当作团队 API 池。
不要频繁切换 IP、设备和浏览器环境。
不要使用来源不明的第三方 Claude 客户端。
避免高频自动化访问 Claude.ai 网页端。
商业或团队场景优先使用 Team、Enterprise 或 API。
熟悉 Anthropic Usage Policy，不把账号用于受限用途。

如果你确实需要在多设备上使用，保持正常登录即可，不要频繁清环境、换指纹、换代理。过度“折腾环境”本身就可能看起来像异常行为。

被封后该怎么做

如果账号已经被暂停，建议按这个顺序处理：

查收 Anthropic 或 Claude 发来的邮件，确认封禁原因或提示类型。
停止继续创建新账号、换网络、换设备反复尝试。
整理账号邮箱、订阅订单、支付凭证、近期使用场景。
如果认为是误判，按官方入口提交 appeal 或联系支持。
说明真实使用场景，避免编造地区、身份或用途。
如果涉及订阅扣费，单独询问退款或订阅处理。

申诉时越具体越好，例如说明是否使用 Claude Code、是否切换过设备、是否使用过 VPN、是否有团队共用、是否接入过第三方工具。平台需要判断风险来源，模糊说“我什么都没做”通常帮助有限。

哪些说法要谨慎看待

有些文章或视频会声称“只要固定指纹就不会封”“某浏览器能彻底防封”“清理某目录就能重置设备身份”“IP 对齐时区就能解决所有问题”。这些说法不宜照单全收。

原因是平台风控通常是多维模型，不只看浏览器指纹或 IP。账号历史、支付信息、地区政策、使用内容、访问频率、自动化特征、客户端版本、API 调用方式，都可能参与判断。单点伪装不等于长期稳定，反而可能制造更多不一致信号。

更重要的是，很多所谓“防封方案”本质上是卖工具或卖服务。用户真正需要的是判断风险来源、合规使用和保留申诉证据，而不是把账号安全寄托在第三方环境包装上。

总结

Claude 账号被封或 Claude Code 受限，不一定是单一原因造成的。它可能是额度问题、订阅问题、授权问题，也可能是地区、支付、设备、共享、自动化或内容政策触发的综合风控。

长期稳定使用 Claude 的关键不是绕过风控，而是让使用方式合规、账号信息一致、访问环境稳定、团队使用走正式方案。遇到封禁时，先停止折腾环境，保存证据，走官方申诉和支持流程，才是最稳妥的处理方式。

参考链接：

从 PPT 到原型设计：归藏 PPT Skill 与 Huashu Design 使用场景解析

Sat, 09 May 2026 08:34:23 +0800

最近两个中文开发者做的设计类 Agent Skill 很值得放在一起看：一个是歸藏的 guizang-ppt-skill，另一个是花叔的 huashu-design。

它们都不是传统意义上的“设计工具”，而是把一套设计流程、审美偏好、检查清单和工程模板写成 Agent 可以执行的 Skill。你不是打开一个 UI 慢慢拖元素，而是把需求交给 Claude Code、Codex、Cursor 这类 Agent，让它按固定流程生成 HTML、PPT、动画或原型。

这类项目的价值，不在于让 AI 随机发挥，而在于把“怎么做才不难看”这件事流程化。

guizang-ppt-skill：专注杂志风网页 PPT

歸藏的 guizang-ppt-skill 定位很清楚：生成单文件 HTML 横向翻页 PPT，视觉基调是“电子杂志 × 电子墨水”。它更像一套为演讲准备的版式系统，而不是通用设计框架。

仓库 README 里列出的核心能力包括：

单文件 HTML 输出，不需要构建和服务器，浏览器直接打开。
横向左右翻页，支持键盘、滚轮、触屏滑动、底部圆点和 ESC 索引。
5 套主题色预设，包括墨水经典、靛蓝瓷、森林墨、牛皮纸和沙丘。
10 种页面布局，包括开场封面、章节幕封、数据大字报、左文右图、图片网格、Pipeline、悬念问题、大引用、Before/After 对比和图文混排。
内置模板、组件说明、布局骨架、主题配置和质量检查清单。

它适合做线下分享、行业内部讲话、私享会、AI 产品发布、demo day，以及带有强烈个人风格的演讲稿。不太适合大段表格数据、培训课件和多人协作编辑。

这个项目有一个很好的取舍：它没有试图覆盖所有设计场景，而是把“杂志风 PPT”这个场景做窄。主题色只能从预设里选，布局也有明确骨架，这反而降低了 Agent 跑偏的概率。

如果你经常要把观点、行业观察、产品发布内容做成演讲 deck，它的实用性会很高。

安装命令也很直接：

`1`	`npx skills add https://github.com/op7418/guizang-ppt-skill --skill guizang-ppt-skill`

huashu-design：更完整的 HTML 原生设计工作流

花叔的 huashu-design 覆盖面更大。它的目标不是只做 PPT，而是把 HTML 当成原生设计画布，用 Agent 生成可交付的设计资产。

仓库 README 里列出的能力包括：

可点击 App 或 Web 原型。
HTML 幻灯片，以及可编辑 PPTX 导出。
产品发布动画、MP4、GIF 和配乐版本。
多方向设计方案并排对比。
信息图、数据可视化、PDF、PNG、SVG 导出。
5 维专家评审，包括哲学一致性、视觉层级、执行工艺、功能性和创新性。

它的核心思路是：让 Agent 先理解品牌和素材，再产出高保真设计。项目里强调了 Core Asset Protocol，也就是遇到具体品牌时，要先确认 logo、产品图、UI 截图、配色、字体和品牌指南，而不是凭记忆猜。

这点很重要。很多 AI 生成设计看起来“像设计”，但不像某个真实产品或品牌。huashu-design 试图把这个问题前置解决：先找真实资产，再做设计。

安装命令是：

`1`	`npx skills add alchaincyf/huashu-design`

它更适合那些希望在终端里完成较完整设计交付的人：产品原型、发布动画、演示文稿、信息图、设计评审都可以放在一个 Agent 工作流里处理。

两者最大的区别

简单说，guizang-ppt-skill 是一个更窄、更稳的演讲 deck 生成器；huashu-design 是一个更宽、更完整的 HTML 原生设计系统。

如果只看 PPT：

guizang-ppt-skill 更强调杂志感、节奏、版式和单文件浏览器演示。
huashu-design 更强调通用设计能力、可编辑 PPTX、品牌素材、导出链路和评审流程。

如果看整体设计能力：

guizang-ppt-skill 的边界更清晰，适合快速做一份有风格的横向演讲。
huashu-design 的能力更综合，适合把一个产品或品牌设计任务拆成原型、动画、幻灯片和信息图。

这两个项目也代表了两种不同的 Skill 写法。前者像一套高度收敛的模板和审美约束，后者像一个小型设计团队的工作流说明书。

为什么这类 Skill 重要

Agent 的一个常见问题是“会做，但不稳定”。同样一句需求，有时输出很好，有时就会滑向紫色渐变、圆角卡片、假图标和一堆看似高级的空话。

Skill 的意义就是把稳定性补上。它把下面这些东西固化下来：

可复用的模板。
可执行的检查清单。
明确的审美偏好。
常见错误的规避规则。
输出格式和验证流程。
什么时候该问问题，什么时候该直接开始做。

这比单纯写一句“请做得高级一点”可靠得多。

尤其是设计任务，审美并不是一句 prompt 就能稳定复现的。真正有用的是流程：先确认素材，再定方向，再搭结构，再做视觉，再检查输出。把这个流程写成 Skill，Agent 才更像一个可协作的执行者，而不是一次性图片生成器。

使用建议

如果你只是想把一个主题做成线下演讲或分享 deck，可以优先试 guizang-ppt-skill。它的输出边界窄，单文件 HTML 也方便分发和预览。

如果你想让 Agent 承担更完整的设计任务，比如 App 原型、发布动画、品牌化幻灯片、可导出 PPTX 或信息图，可以优先看 huashu-design。它的链路更长，适合需要多轮迭代和交付物导出的任务。

如果你已经在写自己的 Codex 或 Claude Code Skill，这两个项目也都值得参考：

想学“如何把一个窄场景做稳”，看 guizang-ppt-skill。
想学“如何把复杂工作流拆成可执行协议”，看 huashu-design。

总结

歸藏和花叔这两个项目的共同点，是都把“设计能力”从一次 prompt 变成了可重复执行的流程。

guizang-ppt-skill 的重点是杂志风 HTML PPT，适合高风格化演讲；huashu-design 的重点是 HTML 原生设计系统，覆盖原型、动画、幻灯片、信息图和评审。它们解决的不是“AI 能不能生成设计”，而是“AI 能不能按一套稳定方法生成可交付的设计”。

这可能会成为 Agent 工具生态里很重要的一类开源项目：不只是代码模板，而是把人的经验、审美和工作方法打包成 Skill。

参考链接：

Codex vs Claude Code：两套 Subagent 机制怎么选

Fri, 08 May 2026 14:01:38 +0800

现在的 AI 编程工具越来越重视 Subagent。原因不是功能跟风，而是单个 Agent 处理真实工程任务时，很快会撞到边界。

一个 Agent 如果同时负责读代码、查日志、改实现、跑测试、分析报错、总结结果，主上下文会很快变脏。搜索结果、命令输出、测试日志和中间推理混在一起，后续判断就会被噪声干扰。任务也很难并行：探索、实现、验证和审查都塞在一条主线上，系统越做越重。

Subagent 的本质，是给 Agent 减压。主会话不再把所有事情从头做到尾，而是更像协调者：判断目标、安排任务、接收结果，再把结果合成最终答案。子 Agent 处理某一段局部工作，例如探索、实现、验证或审查，并只把压缩后的结论带回来。

所以 Subagent 不是“再开一个同款自己”，而是把原来糊成一团的工程工作拆成几个边界更清楚的角色。

成熟 Subagent 系统的底层共识

无论具体产品怎么设计，成熟的 Subagent 系统通常都绕不开四件事：

上下文隔离。
角色专用化。
项目和用户级配置。
工具与权限边界。

上下文隔离是前提。真实仓库里的中间结果很多：搜索结果可能几十条，测试日志可能几百行，命令输出里还混着大量无关信息。这些内容如果直接塞进主会话，主线很快会变乱。Subagent 的价值之一，就是让局部过程先在局部被消化，主会话只看到真正有决策价值的结论。

角色专用化也很关键。多 Agent 不是多开几个一样的模型一起干活。探索型任务要擅长搜索、阅读、总结；实现型任务要专注改代码和处理局部细节；验证型任务要跑检查、识别风险，并把结果清楚汇报。它们的任务边界、工具权限和输出形式都应该不同。

工具和权限边界决定了系统能不能安全落地。子 Agent 不应该默认拥有主会话的全部能力。探索型角色未必需要写文件，验证型角色未必需要改实现，后台任务也不该随意越过工作区边界。权限越清楚，协作越可控。

在这些共识之上，Codex 和 Claude Code 走出了两种不同路线。

Codex：显式派工，主会话始终在场

Codex 的 Subagent 设计气质更克制。

它更像是在说：我给你一套受控、轻量、围绕当前主会话展开的分工机制。什么时候派活、派给谁、什么时候收结果，都由主会话明确决定。控制流始终握在当前任务里。

这种设计的特点是“显式”：

需要子任务时，主会话明确发起委托。
子任务角色数量保持克制。
主会话知道哪个 Agent 在做什么。
结果回到主线后再统一判断。
协作边界比较透明。

公开可见的角色思路也偏简洁：通用角色、探索角色、工作角色这类基础分工已经能覆盖很多工程场景。自定义 Agent 更像配置层上的补充，而不是一套非常重的运行时对象系统。

Codex 这套方式的好处是可预期。它适合需要手动编排、强调确定性、希望主会话始终掌控节奏的团队。比如你正在做一个代码修改任务，可以先派一个探索角色查清调用链，再派一个工作角色做改动，最后由主会话整合并决定是否继续测试。

它的缺点也很清楚：如果任务越来越复杂，所有编排压力仍然落在主会话身上。主会话要判断何时拆分、如何拆分、派给谁、怎么合并结果。对轻量协作来说这很舒服，对长期复杂工程流来说，可能不如平台化系统省心。

Claude Code：把 Agent 做成正式工位

Claude Code 的取向更平台化。

它不是只提供几个临时帮手，而是把 Agent 做成可描述、可选择、可配置、可记忆、可隔离、可后台运行的正式对象。子 Agent 不只是会话里的一个工具，而更像工程系统里的一个工位。

这套思路会把 Agent 列表、适用场景、描述信息、工具边界等内容放进选择逻辑里，让模型判断本轮应该调用哪个角色。这类“模型驱动的委托”会带来更强的自动化：用户不一定每次都显式指定角色，系统可以根据任务类型自己选择。

从机制上看，Claude Code 更强调几类能力。

第一是角色体系。探索、规划、通用处理、验证等角色不是随手加几个名字，而是可以带着用途说明、工具限制、默认模型和运行条件存在。探索型角色可以被限制为只读，规划型角色负责设计方案，验证型角色可以专注检查和汇报。

第二是继承和覆盖。子 Agent 并不是完全自由的，它默认继承主会话的大边界；但在规则允许范围内，也可以通过局部配置调整权限、模式或行为。正确理解不是“全部继承”或“全部覆盖”，而是主会话定义大边界，Agent 在边界内做局部装配。

第三是记忆。记忆不只是“记住一点内容”，而是可以有作用域。用户级记忆更像长期偏好，项目级记忆更像仓库背景知识，本地级记忆更像只留在当前环境里的私人状态。这样某些 Agent 不必每次从零理解项目。

第四是后台和工作区隔离。某些验证任务可以在后台持续跑，主线不用停在原地等待。需要强隔离时，Agent 可以进入独立 worktree，像在主工位旁边分出一张独立桌子：仍然在同一个项目里，但操作空间被明确隔开。

第五是插件生态。只有当 Agent 被视为正式对象时，才会认真考虑它如何被分发、安装、覆盖、排序和接入生态。插件 Agent 可以进入系统，但高风险字段仍应被收口，例如权限模式、hooks、MCP server 等不应该由插件随意声明。

这让 Claude Code 更像一套 Agent 运行时，而不是单次会话里的协作工具。

两种路线的差异

可以把两者理解成两种产品哲学。

Codex 更像受控分工工具：

主会话显式派工。
角色集保持轻量。
控制流清晰。
子任务围绕当前会话展开。
适合强调确定性和人工编排的工作方式。

Claude Code 更像工程工位系统：

Agent 被正式建模。
角色更体系化。
支持记忆、后台、隔离和插件生态。
模型可以参与选择角色。
适合长期项目、复杂工作流和平台化扩展。

这不是谁功能更多谁就更好。真正的差别在于：你希望 Subagent 是“我显式叫来的助手”，还是“系统里长期存在的工位”。

怎么选择

如果你更看重显式控制、轻量分工、当前会话内的安全并行，Codex 的思路更顺手。它让你清楚知道任务什么时候被拆出去，谁在处理，结果什么时候回来。对代码审查、小型改动、明确的实现任务和需要人工节奏控制的场景，这种方式很稳。

如果你更看重体系化角色、长期记忆、后台执行、worktree 隔离、插件扩展和更完整的 Agent 运行时，Claude Code 的路线更合适。它适合把 Agent 当成长期参与项目的成员，而不是临时搬一把的助手。

可以用两个问题判断：

你能不能接受模型自己选择该派谁干活？
你是否需要一套更完整的 Agent 运行时？

如果第一个问题让你不舒服，说明你更适合显式派工。
如果第二个问题答案是肯定的，说明你可能需要平台化的 Agent 工位系统。

使用建议

无论选哪种，都不要把 Subagent 当作“多开几个模型就更强”。

更有效的做法是：

给每个角色明确任务边界。
控制每个角色能用的工具。
让子 Agent 输出结论，而不是搬回全部原始日志。
主会话保留最终决策权。
对后台任务和工作区隔离保持可见性。
对插件 Agent 设置明确安全边界。

工程任务里，Subagent 的价值不在数量，而在分工质量。角色越清楚，上下文越干净，主线判断越稳定。

小结

Codex 和 Claude Code 都在解决同一个问题：单个 Agent 很难独自承载真实工程任务。它们都承认上下文隔离、角色专用、权限边界和局部汇总的重要性。

差异在于实现取向。Codex 更克制，强调显式派工和主会话控制；Claude Code 更体系化，把 Agent 做成可配置、可记忆、可隔离、可后台运行、可进入插件生态的正式工位。

选择哪一个，不是看哪个品牌赢，而是看你的工作方式需要什么：是受控协作工具，还是完整 Agent 运行时。

9Router：把 Claude Code、Codex、Cursor 接到同一个 AI 路由器

Fri, 08 May 2026 13:32:38 +0800

9Router 是一个面向 AI 编程工具的本地路由器。它把 Claude Code、Codex、Cursor、Cline、Copilot、OpenCode、OpenClaw 等工具统一接到一个 OpenAI-compatible endpoint，再由 9Router 负责转发到不同模型和服务商。

它的目标不是再做一个聊天客户端，而是放在 AI 编程工具和模型服务之间，解决几个实际问题：

不同工具的 API 格式不一致。
订阅额度、免费额度和便宜 API 需要手动切换。
git diff、grep、ls、tree 等工具输出会快速消耗 token。
某个模型限流或额度耗尽时，编码流程容易中断。
多账号、多 provider、多模型组合管理成本高。

根据项目说明，9Router 支持 40+ provider 和 100+ 模型，并提供 RTK Token Saver、自动 fallback、额度追踪、多账号轮询、格式转换和请求日志等功能。项目使用 JavaScript 编写，技术栈包括 Node.js、Next.js、React、Tailwind CSS 和 LowDB，许可证为 MIT。

它适合解决什么问题

9Router 最适合的场景，是你同时使用多个 AI 编程工具和多个模型来源。

比如：

Claude Code 用订阅账号。
Codex 或 Cursor 需要接自定义 OpenAI endpoint。
Cline、Continue、RooCode 需要 OpenAI-compatible API。
免费 provider 作为日常尝试。
GLM、MiniMax、Kimi 等便宜 API 作为备用。
某些高质量模型只在复杂任务时使用。

没有 9Router 时，这些配置往往分散在不同工具里。每个工具都要单独写 endpoint、API key、模型名和 fallback 策略。9Router 的思路是让工具都访问同一个本地地址，再在路由器里配置 provider、combo 和优先级。

默认本地地址是：

`1`	`http://localhost:20128/v1`

Dashboard 地址通常是：

`1`	`http://localhost:20128/dashboard`

快速安装

如果只是本机使用，可以直接通过 npm 安装：

1
2

npm install -g 9router
9router

启动后，Dashboard 会在本地打开。项目文档中的默认端口是 20128。

如果想从源码运行：

git clone https://github.com/decolua/9router.git
cd 9router
cp .env.example .env
npm install
PORT=20128 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run dev

生产模式可以先构建再启动：

1
2

npm run build
PORT=20128 HOSTNAME=0.0.0.0 NEXT_PUBLIC_BASE_URL=http://localhost:20128 npm run start

npm 包当前要求 Node.js >=18.0.0。如果是部署到 VPS 或 Docker，建议按项目 README 配置 JWT_SECRET、INITIAL_PASSWORD、DATA_DIR、API_KEY_SECRET 等环境变量，不要直接暴露默认配置。

接入 AI 编程工具

9Router 对外提供 OpenAI-compatible API，因此大多数支持自定义 OpenAI endpoint 的工具都能接。

常见配置大致如下：

1
2
3

Base URL: http://localhost:20128/v1
API Key: 从 9Router Dashboard 复制
Model: 在 9Router 中配置的模型名或 combo 名

以 Codex CLI 为例，可以使用环境变量：

export OPENAI_BASE_URL="http://localhost:20128"
export OPENAI_API_KEY="your-9router-api-key"

codex "your prompt"

以 Cline、Continue、RooCode 这类工具为例，通常选择 OpenAI Compatible provider，然后填入：

1
2
3

Base URL: http://localhost:20128/v1
API Key: your-9router-api-key
Model: cc/claude-opus-4-7

模型名取决于你在 9Router 中连接了哪些 provider。README 中示例包括 cc/、cx/、gh/、glm/、minimax/、kr/、vertex/ 等前缀。

RTK Token Saver 的意义

AI 编程工具消耗 token 最快的地方，往往不是普通对话，而是工具输出。

例如：

git diff
git status
grep
find
ls
tree
日志片段
大段文件列表

9Router 内置 RTK Token Saver，会在请求发给模型前压缩这类工具输出。项目说明称，它可以在很多请求中节省 20%-40% input tokens。

这个功能的价值在于：它不要求你更换模型，也不改变上层工具使用习惯，而是在路由层减少无效上下文。对经常让 AI 读 diff、搜代码、看目录结构的人来说，这比单纯换一个更便宜的模型更直接。

不过它不是万能压缩。涉及关键上下文、完整日志或长文件内容时，仍然要留意是否需要保留原始信息。更稳妥的做法是先在本地开发环境里试用，确认回答质量没有明显下降，再把它放到长期工作流里。

自动 fallback 怎么用

9Router 的另一个重点是三层 fallback。你可以把模型按优先级组合起来：

1
2
3

1. 订阅模型
2. 便宜 API
3. 免费 provider

当第一层额度用完、限流或出错时，9Router 自动切到下一层。这样做的好处是减少手动切换模型的次数，也能避免写代码写到一半突然停住。

一个常见组合可以是：

1
2
3

1. cc/claude-opus-4-7
2. glm/glm-5.1
3. kr/claude-sonnet-4.5

如果你追求稳定，可以把付费或订阅模型放前面，把便宜模型作为备用；如果你追求低成本，可以把免费 provider 放前面，把便宜 API 放在后面兜底。

这里要注意：fallback 会影响输出一致性。不同模型的代码风格、推理强度和上下文处理能力不同。对需要严格一致性的任务，比如大型重构、协议实现、数据库迁移，最好固定主模型，只有失败时再手动切换。

免费 provider 要谨慎理解

项目 README 强调 Kiro、OpenCode Free、Vertex 等免费路径，并且提到部分历史免费层已经变化或不再推荐。

这类信息变化很快，使用时要按当时 provider 的官方政策确认：

是否真的免费。
是否有区域、账号或使用场景限制。
是否允许接入第三方工具。
是否可能触发封号或限流。
免费额度是否有到期时间。

9Router 可以帮你管理路由和 fallback，但不能改变上游 provider 的服务条款。尤其是把个人订阅、OAuth token 或免费额度接给自动化工具时，最好只在自己可控的本机环境里使用，并定期检查账号安全。

本地运行和部署建议

本机使用时，最简单的方式是只监听 localhost。这样 Claude Code、Codex、Cursor、Cline 等本地工具可以访问 9Router，但外部网络不能直接连进来。

如果要部署到 VPS 或局域网服务器，建议至少做到：

修改默认登录密码。
设置强 JWT_SECRET。
设置 API_KEY_SECRET。
开启访问控制或反向代理认证。
避免把 Dashboard 裸露到公网。
对 /v1/* 接口启用 Bearer API key。
定期备份 DATA_DIR 下的配置和用量数据。

Docker 运行时可以参考项目文档，把数据目录挂载出来：

docker run -d \
  --name 9router \
  -p 20128:20128 \
  --env-file ./.env \
  -v 9router-data:/app/data \
  -v 9router-usage:/root/.9router \
  9router

如果只是个人开发机使用，没有必要一上来就公网部署。先在本地跑通 provider、combo、工具接入和日志，再决定是否迁移到服务器。

适合谁用

9Router 更适合这些用户：

同时使用多个 AI 编程工具。
同时有订阅、免费额度和付费 API。
经常被 provider 限流或额度耗尽打断。
想把模型 fallback 做成统一配置。
想减少工具输出带来的 token 浪费。
愿意自己维护本地代理和 provider 凭据。

如果你只用一个工具、一个模型，而且额度足够，9Router 可能会增加一层不必要的复杂度。它真正有价值的地方，是把“多工具、多模型、多账号、多价格层”的混乱收进一个本地路由层里。

小结

9Router 可以理解为 AI 编程工具的本地网关。它把 Claude Code、Codex、Cursor、Cline 等工具统一接到 http://localhost:20128/v1，再由路由器处理模型选择、格式转换、token 压缩、额度追踪和 fallback。

它适合重度 AI 编程用户，尤其适合已经在多个 provider 之间来回切换的人。最稳妥的使用方式是先本地安装，接入一个常用工具和一个 provider，确认请求、日志、模型名和 fallback 都正常后，再逐步增加账号和模型组合。

如果你只是想省心，单一官方客户端仍然更简单。
如果你想把 AI 编程工具变成一套可配置、可切换、可兜底的工作流，9Router 值得试试。

参考资料

Claude Code 24 个使用技巧：计划模式、回滚、CLAUDE.md、Skills、Agents 和插件

Fri, 08 May 2026 08:54:14 +0800

Claude Code 不只是一个聊天框。它更像一个能进入项目目录、读写文件、执行命令、维护上下文的编程 Agent。

如果只是把需求丢进去让它生成代码，很快会遇到几个问题：计划不够清楚、权限反复确认、上下文越来越长、生成结果不满意、不知道怎么回滚，也不知道怎么把项目规则长期保存下来。

下面整理一组常用操作，适合刚开始使用 Claude Code 的开发者快速建立工作流。

先在项目目录启动

Claude Code 最好在项目目录里启动，而不是随便打开一个终端就开始用。

可以先创建一个文件夹作为项目目录，进入目录后打开命令行，再启动 Claude Code：

claude

首次进入项目时，如果 Claude Code 询问是否信任当前文件夹，确认后再继续。这样它才能围绕当前项目读取文件、创建文件和执行后续操作。

一个简单的练习方式是让它创建一个摄影师个人网站。这个任务足够直观：能看到页面效果，也能练习文件生成、命令执行、回滚和后续重构。

计划模式先把方向想清楚

Claude Code 在面对较复杂任务时会进入计划模式。计划模式的作用是先讨论需求、拆解步骤，再让用户决定是否批准执行。

当它给出计划后，通常会出现几类选择：

批准计划，并允许后续自动使用编辑工具。
批准计划，但后续编辑仍然需要手动确认。
暂停执行，继续和 Claude Code 讨论计划。

如果任务比较明确，可以批准计划并继续。如果任务还不清楚，建议先让它继续补充方案，比如页面风格、技术栈、目录结构、交互效果和验收标准。

计划模式的好处是减少返工。直接让 Agent 动手，可能很快生成一堆文件；但如果方向错了，后面越改越乱。

用 Shift + Tab 切换模式

在 Claude Code 中，可以用 Shift + Tab 在不同工作模式之间切换。常见用途是进入计划模式，或者切换到自动同意编辑工具的模式。

建议的习惯是：

新项目、新功能、大改动：先进入计划模式。
小改动、明确修复：可以直接执行。
涉及删除、批量替换、安装依赖：保持人工确认。

计划模式下，Claude Code 可能会主动询问项目细节。可以用方向键选择选项，用回车确认。提交反馈后，它会根据你的选择更新计划。

权限确认不要一律放开

Claude Code 执行命令、编辑文件或启动程序时，可能会申请权限。

常见选择包括：

只同意本次使用。
在当前会话中以后都同意同类命令。
拒绝或暂停。

如果只是启动本地页面、运行开发服务器、查看文件，可以根据需要允许。但不要为了省事长期使用“自动同意所有权限”的启动方式。

全自动权限适合非常确定、风险很低、项目已经有 Git 备份的场景。日常使用中，涉及删除文件、覆盖目录、安装依赖、联网、提交代码、执行脚本时，最好保留人工确认。

用终端模式执行本地命令

Claude Code 里可以进入终端命令模式，直接执行一些本地命令。

例如页面生成后，可以用系统命令打开 HTML 文件：

`1`	`start index.html`

这里的 start 是 Windows 下打开文件的命令，后面接文件名。这样可以快速查看生成页面，而不用手动去资源管理器里找文件。

终端模式适合执行这些轻量操作：

打开生成的页面。
查看目录内容。
启动本地开发服务器。
运行测试或构建命令。

但高风险命令仍然要谨慎，比如递归删除、移动目录、批量覆盖和修改系统环境。

回滚：结果不满意时及时退回

如果 Claude Code 做出的页面或代码不是你想要的，而且越改越乱，就应该及时回滚。

回滚功能可以把对话或代码退回到某个节点。常见选项包括：

同时回滚代码和对话。
只回滚对话。
只回滚代码。
把某个节点之前的内容压缩成摘要。
取消操作。

更推荐在明显走偏时选择“同时回滚代码和对话”。这样可以让上下文和文件状态一起回到较干净的位置。

需要注意：Claude Code 的回滚通常只能覆盖它通过内置工具创建或修改的文件。如果文件是通过外部命令生成的，未必能完整回滚。因此重要项目仍然要配合 Git 使用。

长提示词用编辑器写

复杂需求不要全挤在一行输入框里。

如果系统支持在文本编辑器中编辑长提示词，可以打开编辑器，把需求写完整后保存，再发送给 Claude Code。

长提示词里建议写清楚：

目标是什么。
使用什么技术栈。
不要做什么。
需要保留哪些文件。
完成后如何验证。
页面或功能的验收标准。

例如让 Claude Code 把一个普通 HTML 页面重构成更现代的技术栈时，不要只写“重构一下”。可以说明希望使用组件化结构、保留视觉内容、增加响应式布局，并要求它运行构建检查。

退出后用历史恢复会话

如果中途需要退出 Claude Code，可以正常退出。之后回到同一个项目目录，再次启动：

claude

如果发现前面的记录没有直接显示，可以使用历史相关命令查看最近会话，并加载之前的会话。

这个功能适合中断后继续工作。不过不要把会话历史当成唯一记忆。项目规则、技术栈、常用命令和注意事项，最好写进项目文件里。

用 CLAUDE.md 保存项目规则

CLAUDE.md 是 Claude Code 很重要的记忆文件。它通常放在项目根目录，用来告诉 Claude Code 项目规则、技术栈、目录结构和协作约束。

可以让 Claude Code 初始化这个文件：

/init

CLAUDE.md 适合记录：

项目目标。
技术栈。
常用启动、测试、构建命令。
目录说明。
代码风格。
不允许执行的操作。
提交和部署规则。

每次对话时，Claude Code 会把这类规则作为上下文的一部分使用。你可以把它理解成“项目说明书”。

一个简单验证方式是：在 CLAUDE.md 里加入一条明显规则，然后再向 Claude Code 提问。如果回答遵循了这条规则，就说明它确实读到了项目记忆。

用 @ 引用文件

在输入框中使用 @，可以选择文件或 Agent，把指定内容加入当前对话上下文。

这适合几类场景：

让 Claude Code 阅读某个配置文件。
让它修改某个指定页面。
让它根据 CLAUDE.md 或其他文档继续工作。
明确告诉它“只看这个文件，不要猜项目结构”。

相比把文件内容复制到输入框里，@ 引用更清晰，也更不容易漏内容。

查看和压缩上下文

长时间对话后，上下文会越来越大。上下文太长时，模型可能变慢，也可能开始忽略早期细节。

可以使用上下文查看命令了解当前占用情况：

`1`	`/context`

如果上下文已经很长，可以压缩历史：

`1`	`/compact`

如果压缩后效果仍然不好，可以考虑清空当前上下文：

/clear

清空上下文后，Claude Code 仍然可以通过项目文件、CLAUDE.md 和当前目录重新理解一部分项目情况，但不会保留完整对话历史。

实用建议是：一个任务完成后就开新会话；项目级规则写进 CLAUDE.md；临时讨论不要无限堆在一个聊天里。

Skills：把固定流程做成说明书

Skills 可以理解为 Claude Code 的工作说明书。它不是一次性提示词，而是一套可复用的任务流程。

例如你经常要生成周报，就可以创建一个周报 Skill，里面写清楚：

输入需要哪些信息。
输出格式是什么。
语气和结构怎么控制。
哪些内容必须保留。
哪些内容不能编造。

Skills 通常由 name、description 和具体指令组成。安装到全局 Skills 目录后，Claude Code 在遇到相关任务时可以识别并加载。

这适合处理重复工作：

周报。
代码审查模板。
文档整理。
图片批处理。
固定格式文章。
项目初始化流程。

如果你发现自己反复复制同一段提示词，就可以考虑把它做成 Skill。

Agents：把子任务交给独立助手

Agents 和 Skills 不一样。

Skill 更像说明书，告诉 Claude Code 怎么做某类任务；Agent 更像一个独立助手，可以在当前主会话之外执行任务，完成后把结果返回。

Agents 的价值在于隔离上下文。比如做代码巡检时，可以创建一个只读 Agent，让它只读取项目并输出报告，不直接修改文件。这样不会污染主会话，也能降低误操作风险。

创建 Agent 时通常要考虑：

是项目级 Agent，还是用户级 Agent。
是否需要 Claude Code 帮你生成配置。
允许哪些工具权限。
使用哪个模型。
是否保存记忆。
Agent 的提示词是否足够明确。

对于代码巡检类 Agent，建议只给读取权限，不给写入权限。先让它输出报告，再由主会话决定是否修改代码。

插件：打包 Skills、Agents、MCP 和 Hooks

插件可以理解为更完整的能力包。它可能同时包含：

Skills
Agents
MCP
Hooks

相比单独安装一个 Skill，插件更适合成套能力。例如前端设计插件可能会把页面审美、布局规则、组件习惯和相关 Agent 一起打包。

安装插件时通常会有几个位置选项：

如果是个人常用能力，可以放在用户目录；如果是团队项目约定，可以放进项目目录；如果只是临时测试，放本地项目目录更稳。

插件能明显改善特定任务效果

在前端页面生成这类任务里，插件往往比裸提示词更稳定。

例如同样是“制作一个摄影师个人网页”，只用普通提示词可能生成一个能看的页面；如果明确使用前端设计插件，页面结构、视觉层次、间距、配色和整体完成度通常会更好。

这并不意味着插件能替代人工审美。更合理的用法是：先让插件生成一个更好的初稿，再由人做细节微调。

一套更稳的 Claude Code 工作流

把上面这些技巧组合起来，可以形成一套比较稳的流程：

在项目目录启动 claude。
先用计划模式讨论需求。
批准计划前确认技术栈和验收标准。
涉及高风险操作时保留手动确认。
用终端模式执行本地预览和测试。
结果走偏时及时回滚。
把项目规则写进 CLAUDE.md。
长对话定期查看和压缩上下文。
重复流程沉淀成 Skills。
巡检、研究、分析类任务交给只读 Agents。
特定领域任务优先用插件。
重要项目始终配合 Git 提交点。

这样使用 Claude Code，会比单纯“发一句需求等它生成”稳定得多。

小结

Claude Code 的效率不只来自模型能力，也来自工作流控制。

计划模式决定方向，权限确认控制风险，回滚减少返工，CLAUDE.md 保存项目规则，/context、/compact 和 /clear 管理上下文，Skills 复用固定流程，Agents 隔离复杂子任务，插件则把成套能力打包进项目。

真正好用的 Claude Code 工作方式，是让它在清楚边界内持续推进任务，而不是把整个项目一次性交给它自由发挥。

opencode、Claude Code、Codex 有什么区别？开源 AI 编程工具使用指南

Fri, 08 May 2026 08:33:37 +0800

opencode 是 anomalyco 开源的 AI Coding Agent。它的定位很直接：让开发者在终端里使用一个可编程、可扩展、可接入多家模型的代码助手。

如果把它和 Claude Code、Codex 放在一起看，三者解决的是同一类问题：让 AI 进入真实代码库，理解上下文，修改文件，运行命令和测试。但它们的产品取向不一样。

opencode 更强调开源、多模型和终端 TUI；Claude Code 更强调 Anthropic 模型生态和本地工程协作；Codex 则是 OpenAI 的 AI coding agent，可以在终端、IDE、Codex app 和云端任务里使用。

opencode 适合谁

opencode 更适合这几类开发者：

想在终端里完成代码修改、项目分析和工程任务的人。
希望 AI Coding Agent 不绑定单一模型提供商的人。
偏好开源工具，想自己审计、扩展或二次开发的人。
已经习惯 Neovim、TUI、命令行工作流的人。
希望以后用桌面端、移动端或其他客户端远程驱动同一个编码代理的人。

它的重点不是做一个聊天窗口，而是把 AI 编程能力放进开发者原本使用的终端和项目目录里。

安装方式

官方 README 提供了多种安装方式。

# 直接安装
curl -fsSL https://opencode.ai/install | bash

# npm
npm i -g opencode-ai@latest

# Windows
scoop install opencode
choco install opencode

# macOS 和 Linux
brew install anomalyco/tap/opencode
brew install opencode

# Arch Linux
sudo pacman -S opencode
paru -S opencode-bin

# 其他方式
mise use -g opencode
nix run nixpkgs#opencode

官方也提醒，安装前最好先移除 0.1.x 之前的旧版本，避免旧版本残留造成问题。

安装脚本会按优先级选择安装目录：

$OPENCODE_INSTALL_DIR
$XDG_BIN_DIR
$HOME/bin
$HOME/.opencode/bin

如果需要指定路径，可以这样写：

1
2

OPENCODE_INSTALL_DIR=/usr/local/bin curl -fsSL https://opencode.ai/install | bash
XDG_BIN_DIR=$HOME/.local/bin curl -fsSL https://opencode.ai/install | bash

桌面应用还在 Beta

除了命令行工具，opencode 也提供桌面应用，目前仍处于 Beta。可以从 GitHub Releases 或 opencode.ai/download 下载。

桌面端覆盖这些平台：

平台	文件
macOS Apple Silicon	`opencode-desktop-mac-arm64.dmg`
macOS Intel	`opencode-desktop-mac-x64.dmg`
Windows	`opencode-desktop-windows-x64.exe`
Linux	`.deb`、`.rpm` 或 `.AppImage`

macOS 和 Windows 也可以通过包管理器安装桌面端。

# macOS
brew install --cask opencode-desktop

# Windows
scoop bucket add extras
scoop install extras/opencode-desktop

两种内置 Agent 模式

opencode 内置两种 Agent，可以通过 Tab 键切换。

build 是默认模式，拥有完整开发权限，适合直接修改代码、运行命令和推进工程任务。

plan 是只读模式，更适合分析陌生代码库、理解项目结构、制定修改方案。它默认拒绝文件编辑，并且在运行 bash 命令前会询问。

另外，opencode 还带有一个 general 子 Agent，用于复杂搜索和多步骤任务。用户可以在消息中输入 @general 调用。

这个设计比较实用：真正动手前先用 plan 看清楚项目，需要改代码时再切到 build。对于大型仓库，读写权限分开能减少误操作。

Codex 是什么

Codex 是 OpenAI 的 AI coding agent，用来帮助开发者写代码、审查代码、修复 bug 和交付工程任务。

和单纯的代码补全工具不同，Codex 更接近一个可以操作代码库的 Agent。它可以在本地工具里和你结对，也可以把任务委托到云端执行。OpenAI 官方资料里提到，Codex 可以通过 CLI、IDE、Codex app、ChatGPT/Codex 云端等不同入口使用。

对开发者来说，Codex 的重点有几处：

可以读取代码库、编辑文件、运行命令和测试。
支持终端、IDE、应用和云端等多种使用界面。
适合修 bug、写功能、重构、迁移、代码审查和测试补齐。
更偏 OpenAI 账户、模型和 Codex 产品体系。
云端任务适合并行处理多个相对清晰的工程任务。

如果 opencode 更像一个开放的终端代理框架，Codex 更像 OpenAI 提供的一整套 AI 编程工作台：本地可以结对，云端可以委托，团队可以把它接入更长的工程流程。

三者核心区别

opencode、Claude Code、Codex 都是 AI 编程工具，但选择时可以先看这几个维度。

工具	核心定位	主要优势	更适合
`opencode`	开源 AI Coding Agent	开源、多模型、TUI、客户端/服务器架构	想要开放工具链、可替换模型、偏终端工作流的开发者
`Claude Code`	Anthropic 的命令行编程工具	Claude 模型体验、代码理解、长上下文、工程任务协作	已经使用 Claude/Anthropic 生态，希望本地推进代码任务的开发者
`Codex`	OpenAI 的 AI coding agent	CLI、IDE、Codex app、云端任务、多 Agent 工作流	已经使用 ChatGPT/OpenAI，希望本地结对和云端委托并用的团队

简单说，opencode 的关键词是“开源和可替换”，Claude Code 的关键词是“Claude 生态和本地工程代理”，Codex 的关键词是“OpenAI 生态和多入口协作”。

和 Claude Code 的区别

opencode 的官方 FAQ 直接把 Claude Code 拿来对比。两者能力上很接近，但差异主要在这几处。

第一，opencode 是 100% 开源项目，代码托管在 GitHub，并使用 MIT license。

第二，opencode 不绑定单一模型提供商。它推荐 OpenCode Zen 提供的模型，但也可以搭配 Claude、OpenAI、Google 或本地模型。对开发者来说，这意味着模型成本、能力和可用性变化时，不必被某一个平台锁住。

第三，opencode 内置可选的 LSP 支持。对代码补全、跳转、诊断和项目理解来说，LSP 是非常关键的基础能力。

第四，opencode 更强调 TUI。它由 Neovim 用户和 terminal.shop 的创建者打造，产品重心明显放在终端体验上。

第五，opencode 采用客户端/服务器架构。也就是说，opencode 可以在你的电脑上运行，未来由 TUI、桌面端、移动端或其他客户端来控制。TUI 只是其中一种前端形态。

什么时候选 opencode、Claude Code 或 Codex

如果你已经在使用 Claude Code 或 Codex，opencode 不一定是立刻替换它们的工具。更合理的看法是：它提供了一个开源、可替换模型、偏终端的选择。

可以优先考虑 opencode 的场景包括：

你希望 AI 编程工具尽量开源。
你不想把工作流绑定在某个模型供应商上。
你希望用同一个工具测试 Claude、OpenAI、Google 或本地模型。
你喜欢 TUI，不希望主要工作流被桌面应用或网页应用打断。
你关注客户端/服务器架构带来的远程控制能力。

可以优先考虑 Claude Code 的场景包括：

你主要使用 Claude 模型。
你重视长上下文、代码理解和复杂工程任务协作。
你希望在本地仓库中持续推进修改、测试和重构。
你更信任 Anthropic 对 Claude Code 的默认产品体验。

可以优先考虑 Codex 的场景包括：

你已经在使用 ChatGPT 或 OpenAI 账户体系。
你希望同一个 coding agent 覆盖终端、IDE、桌面应用和云端任务。
你想把较清晰的 bug 修复、功能开发、迁移、测试补齐交给云端并行处理。
你需要代码审查、后台任务、团队协作和多 Agent 工作流。

如果你更看重官方闭环体验、模型默认配置、企业管理和现成集成，Claude Code 或 Codex 可能更省心；如果你更看重可控性、开放性和 provider-agnostic，opencode 更值得关注。

需要注意的地方

opencode、Claude Code 和 Codex 都发展很快，GitHub release、安装命令、桌面端文件名、模型可用性和套餐权限都可能变化。实际安装和选型前，最好直接查看各自官方 README、文档和发布页面。

另外，它的桌面应用仍然标注为 Beta，不适合默认当作稳定生产工具。对于日常工程任务，终端版仍然是更主要的入口。

从工具趋势看，opencode 代表的是 AI Coding Agent 的开放工具链方向：模型可以替换，客户端可以替换，核心代理能力尽量开放。Codex 和 Claude Code 则更像模型公司把 coding agent 做成完整产品入口。对开发者来说，这两条路线会长期并存。

参考链接

opencode GitHub：https://github.com/anomalyco/opencode
opencode 官网：https://opencode.ai
opencode 文档：https://opencode.ai/docs
opencode Releases：https://github.com/anomalyco/opencode/releases
OpenAI Codex：https://openai.com/codex/
Using Codex with your ChatGPT plan：https://help.openai.com/en/articles/11369540-codex-in-chatgpt
OpenAI Codex CLI Getting Started：https://help.openai.com/en/articles/11096431-openai-codex-ci-getting-started

Claude Opus 4.7、Sonnet 4.6、Haiku 4.5 有什么区别？Claude 模型选择指南

Fri, 08 May 2026 08:19:03 +0800

Anthropic 的核心大模型主要通过 Claude 系列迭代。到 2026 年 5 月，Claude 的主流产品线已经进入 4.x 阶段，整体仍然延续三档定位：Opus 负责最高能力，Sonnet 负责性能与成本平衡，Haiku 负责速度和性价比。

如果只想快速选型，可以先记住一句话：

最复杂、最重的推理和 agentic coding：优先看 Claude Opus 4.7。
大多数开发、写作、分析和企业 API 场景：从 Claude Sonnet 4.6 开始最稳。
高并发、低延迟、成本敏感任务：考虑 Claude Haiku 4.5。

当前主流模型

根据 Anthropic 官方模型文档，当前 Claude 主流模型可以这样理解。

模型	定位	适合场景
`Claude Opus 4.7`	当前最强的通用可用模型，面向复杂推理和 agentic coding	大型代码库重构、多步骤任务、复杂策略分析、要求更高一致性的工作
`Claude Sonnet 4.6`	速度、能力和成本的平衡点，支持 100 万 token 上下文窗口	代码生成、长文档分析、企业知识工作、Agent 开发、日常高质量生产任务
`Claude Haiku 4.5`	速度最快、成本更低的小模型，但仍有接近前沿模型的能力	实时对话、客服、批量分类、简单代码协作、高并发 API 调用

这里需要注意两个命名细节。

第一，官方名称是 Claude Haiku 4.5，不是 Claude 4.5 Haiku。第二，Claude Mythos Preview 不是普通用户或开发者的主流可用模型，它是 Project Glasswing 相关的受控研究预览，主要面向防御性网络安全工作流，不应和常规 Claude 模型混在一起选型。

Opus：处理最难的问题

Opus 是 Anthropic 给最强模型使用的档位。Claude Opus 4.7 的重点不是便宜，也不是最快，而是更适合处理复杂、多步骤、需要反复校验的任务。

它更适合这些情况：

跨很多文件的大型代码修改。
复杂系统重构和架构推理。
长链路 Agent 任务。
需要更强视觉理解、文档理解和多轮规划的工作。
对错误成本比较敏感的企业分析任务。

如果一个任务失败一次的代价很高，或者你希望模型在开始动手前花更多时间理解上下文，Opus 通常更值得尝试。

Sonnet：多数人的默认起点

Claude Sonnet 4.6 是更适合作为默认入口的模型。它的定位不是“低配 Opus”，而是把足够强的推理、编程、视觉理解、长上下文和 agent planning 放在更可控的成本与速度里。

对开发者来说，Sonnet 4.6 的价值主要在三点：

能处理很长的上下文，适合放入代码库、合同、报告或多篇资料。
在 Claude Code、API 和企业场景中更容易作为常用模型。
成本低于 Opus，更适合高频使用。

如果你不知道该从哪个 Claude 模型开始，通常可以从 Claude Sonnet 4.6 开始。只有在任务明显需要更强能力时，再切到 Opus。

Haiku：快和便宜更重要时

Claude Haiku 4.5 是小模型档位，但不能简单理解成“弱模型”。Anthropic 对它的定位是快速、低成本，同时保留接近前沿模型的能力。

它适合这些场景：

实时聊天和客服机器人。
大量短文本分类。
低延迟 API 调用。
简单代码修改和快速原型。
多 Agent 工作流中的子任务执行。

如果任务本身很清楚、上下文不复杂、需要吞吐量，Haiku 往往比盲目使用更大的模型更合理。

Claude 的工具能力

Claude 系列不只是聊天模型。Anthropic 现在把模型能力放进了多种产品和开发工具里。

Claude Code 是面向开发者的命令行编程工具，可以读取代码库、编辑文件、运行命令和测试，适合持续推进工程任务。它的体验很依赖模型本身的代码理解、上下文管理和工具调用稳定性。

Computer Use 是让模型通过截图、鼠标和键盘操作桌面环境的能力。它仍然需要谨慎使用，官方文档也强调要放在隔离环境中运行，避免误操作或安全风险。

Artifacts 更偏向 Claude 应用侧体验，可以把代码、页面原型、图表或文档结果放在界面中预览和迭代。它不是一个单独模型，而是 Claude 产品形态的一部分。

至于“Managed Agents”或“自我进化 Agent”这类说法，写文章时要谨慎。Anthropic 确实在强化 Agent SDK、Claude Code、长上下文、工具调用和企业工作流，但不要把它描述成已经具备不受控自我进化能力。

访问方式

普通用户可以通过 Claude.ai 网页端或移动端使用 Claude，不同套餐会影响可用模型、额度和功能。

开发者通常有几种接入方式：

Anthropic Console 和 Claude API。
Amazon Bedrock。
Google Cloud Vertex AI。
Microsoft Foundry。

具体可用模型、上下文窗口、价格和地区支持会变化，开发前最好以 Anthropic 官方模型文档和对应云平台页面为准。

怎么选

实际使用时，不需要一开始就追求最强模型。更好的方式是按任务成本分层。

如果是日常写作、代码生成、长文档分析、知识整理和大多数 Agent 原型，先用 Claude Sonnet 4.6。它通常是性价比和通用能力的最佳起点。

如果任务需要更强的复杂推理、跨文件工程修改、长链路规划或更高可靠性，再切到 Claude Opus 4.7。

如果任务简单、数量大、对延迟敏感，例如分类、摘要、客服、批量处理，就把 Claude Haiku 4.5 放进候选。

Claude 的模型线不是单纯的“新版本替代旧版本”，而是一套按任务难度、速度和成本分层的工具箱。选对模型，比盲目使用最贵模型更重要。

参考链接

Anthropic Models Overview：https://platform.claude.com/docs/en/about-claude/models/overview
Introducing Claude Opus 4.7：https://www.anthropic.com/news/claude-opus-4-7
Introducing Claude Sonnet 4.6：https://www.anthropic.com/news/claude-sonnet-4-6
Introducing Claude Haiku 4.5：https://www.anthropic.com/news/claude-haiku-4-5
Anthropic Computer Use Tool：https://docs.anthropic.com/en/docs/build-with-claude/computer-use

ChatGPT、Claude Code 和 Gemini 的记忆机制有什么不同？

Thu, 07 May 2026 14:47:17 +0800

AI 产品里的“记忆”正在变得越来越重要。它标志着 AI 从“单次对话工具”走向“长期协作伙伴”：不用每次重新介绍背景，不用反复解释偏好，也不用让模型一次次重新理解项目。

但不同产品里的记忆并不是一回事。ChatGPT、Claude Code 和 Gemini 都在解决“AI 如何记得更久”的问题，但它们的设计目标、存储位置、透明度和适用场景差异很大。

截至 2026 年 5 月 7 日，可以把它们粗略理解成三类：

ChatGPT 更像“个人助理记忆”。
Claude Code 更像“工程项目记忆”。
Gemini 更像“Google 生态上下文”。

ChatGPT：围绕人的长期偏好

ChatGPT 的记忆机制主要面向个人协作。它关心的是“你是谁”“你偏好什么”“你长期在做什么”。

OpenAI 目前把 ChatGPT 的记忆分成两类：saved memories 和 chat history。

saved memories 是 ChatGPT 保存下来的重要信息，比如你的名字、偏好、目标、常用技术栈、写作习惯等。你可以直接要求它记住某件事，它也可能在对话中自动保存它认为未来有用的信息。

chat history 则是让 ChatGPT 在回答时参考过去聊天。它不等于把每一段聊天都完整变成记忆，而是在需要时从过往对话里找相关上下文。

所以 ChatGPT 的核心逻辑是：跨会话理解同一个用户。

典型例子包括：

“以后给我代码示例时尽量简洁。”
“我主要使用 Python 和 TypeScript。”
“我正在写一个关于 AI 工具的 Hugo 博客。”
“我喜欢先看结论，再看细节。”

这些记忆不是绑定某个单独项目，而是跟随账号和个人使用习惯。

Memory Sources：让个性化来源更可见

OpenAI 在 2026 年 5 月的更新中强调了 Memory sources。

它的作用不是新增另一种记忆，而是让用户看到 ChatGPT 在个性化回答时参考了哪些来源。根据 OpenAI 帮助文档，Memory Sources 可能显示：

过去聊天。
保存记忆。
自定义指令。
文件库中的文件。
已连接 Gmail 中的邮件。

其中，文件和 Gmail 的可见范围会受到计划、地区和连接状态限制。OpenAI 也明确说明，Memory sources 不一定展示影响回答的所有因素，而是帮助用户理解和管理个性化。

这一步很重要。因为 AI 越会“记住你”，用户越需要知道它到底根据什么在回答。否则个性化很容易变成黑箱：你感觉它好像知道你，但不知道它为什么知道。

ChatGPT 的优势是跨会话、跨主题持续理解个人偏好；风险是记忆容易过期，或者用户忘了某条旧记忆还在影响回答。因此，适合定期清理 saved memories 和旧聊天。

Claude Code：围绕代码库和工程规则

Claude Code 的记忆机制更偏工程协作。它关心的不是“用户平时爱喝什么咖啡”，而是“这个代码库应该怎么改”。

Claude Code 有两类容易混在一起的记忆：

显式项目记忆：CLAUDE.md。
自动项目记忆：Auto Memory。

CLAUDE.md 是最基础、最稳定的项目记忆文件。它可以放在项目根目录，也可以在子目录中存在。Claude Code 会读取这些文件，把它们作为项目说明和操作规则。

适合写进 CLAUDE.md 的内容包括：

常用构建、测试、lint 命令。
代码风格和命名规则。
项目架构说明。
模块边界和危险区域。
团队约定和提交流程。

如果 CLAUDE.md 放在代码库里，它可以提交到 Git，成为团队共享的 agent 说明书。这一点和 ChatGPT 的云端个人记忆完全不同。

Claude Code Auto Memory：自动积累项目经验

Claude Code 现在也有 Auto Memory。它的目标是让 Claude 在多个会话之间自动积累项目经验，而不要求用户每次手写说明。

根据 Claude Code 文档，Auto Memory 会让 Claude 在工作过程中为自己保存笔记，例如构建命令、调试发现、架构说明、代码风格偏好和工作流习惯。它不会每个会话都保存，而是判断哪些信息未来可能有用。

这里有一个容易误解的点：Auto Memory 默认不是把内容写到项目根目录的 .claude/memory.md。官方文档说明，每个项目会在用户目录下拥有自己的 memory 目录，路径类似：

`1`	`~/.claude/projects/<project>/memory/`

其中 MEMORY.md 会在每次对话开始时加载前 200 行或前 25KB，详细内容则可能被拆到其他主题文件里。Auto Memory 文件是本机本地的 Markdown 文件，用户可以通过 /memory 查看、编辑或删除。

这让 Claude Code 的记忆更像“本机上的项目经验库”。它比 ChatGPT 的个人记忆更贴近代码库，也比单纯的 CLAUDE.md 更动态。

但要注意，Auto Memory 是机器本地的，不会天然跟随代码库同步到其他机器或云环境。如果要团队共享稳定规则，仍然应该优先写进项目中的 CLAUDE.md。

Gemini：围绕 Google 生态上下文

Gemini 的记忆逻辑又不同。

Gemini 也有保存信息和参考过去聊天的能力。Google 帮助文档提到，用户可以保存关于生活、工作或偏好的信息，也可以让 Gemini 在回答前参考过去聊天。Gemini 使用这些信息时，可能会在回答底部的来源区域显示 Your saved info 或 Previous chats。

但 Gemini 的差异化不只在“保存几条偏好”，而在 Google 生态集成。

在用户授权和功能可用的前提下，Gemini 可以通过连接的 Google 应用获取上下文，例如 Gmail、Google Drive、Docs、Sheets 等。它的优势不是让用户一条条教它记住什么，而是把已有的 Google 账号资料变成可检索的工作上下文。

典型区别是：

ChatGPT 记得：“我最近在做 LTO 磁带机修复。”
Gemini 可能可以从 Gmail 找到购买确认邮件，或从 Drive 里读取相关维修笔记。

当然，这不代表 Gemini 可以无条件读取你所有 Google 数据。它取决于账号类型、地区、权限、连接应用、Keep Activity 设置和具体产品可用性。对企业或学校账号，还可能受 Google Workspace 管理员控制。

所以更准确地说，Gemini 的记忆不是一个单纯的“备忘录”，而是“保存信息 + 过去聊天 + Google 生态连接”的组合。

三者核心差异

维度	ChatGPT	Claude Code	Gemini
核心对象	人和偏好	项目和代码库	Google 账号与生态资料
典型记忆	偏好、背景、长期目标	架构、命令、规范、调试经验	saved info、过去聊天、Gmail/Drive/Docs 上下文
存储形态	OpenAI 账户内的记忆和聊天上下文	`CLAUDE.md`、`MEMORY.md`、本地 Markdown 文件	Google 账号活动、保存信息、连接应用数据
透明度	Memory sources 可见一部分来源	Markdown 文件可直接查看和编辑	通过来源提示、Gemini Apps Activity 和 Google 设置管理
跨项目能力	强，跟随用户账号	弱，主要跟随项目或本机项目 memory	强，取决于 Google 生态资料和权限
团队共享	不适合直接共享	`CLAUDE.md` 可随 Git 共享	主要依赖 Workspace 和权限体系
最适合	个人偏好和长期助理	长期代码项目和 agent 协作	Google Workspace 资料检索和跨工具工作

该怎么选择和使用

如果你想让 AI 记住“我是谁、我喜欢什么风格、我长期怎么工作”，ChatGPT 的记忆更合适。

它适合保存个人偏好，例如写作风格、常用技术栈、回答格式、职业背景、长期项目方向。它的重点是减少自我介绍成本，让每次新对话更快进入状态。

如果你想让 AI 记住“这个代码库怎么改、哪些命令能跑、哪些坑不能踩”，Claude Code 更合适。

稳定规则写进 CLAUDE.md，团队共享；动态经验交给 Auto Memory 辅助积累；关键决策最好仍然整理进文档或 CLAUDE.md，避免只停留在本机自动记忆里。

如果你的资料大量存在 Gmail、Drive、Docs、Sheets 里，Gemini 的生态上下文更有优势。

它适合查找过去邮件、整理 Google Drive 文档、联动日历和办公资料。使用 Gemini 的关键，不是反复在聊天里提醒它，而是确保相关应用连接、权限和活动设置正确。

一个实用分工

可以把三者这样分工：

ChatGPT 记住“我的通用偏好”。
Claude Code 记住“这个仓库的工程知识”。
Gemini 检索“我在 Google 生态里的资料”。

也就是说，ChatGPT 更像私人秘书，Claude Code 更像项目里的资深工程同事，Gemini 更像 Google 账号里的资料索引员。

这三种记忆没有绝对高低，只是目标不同。

最需要警惕的是把它们混为一谈。个人偏好不一定适合写进项目记忆；项目架构不一定适合存在云端个人记忆；Google 生态检索也不等于模型真正“长期理解”了你。

简短判断

AI 记忆的下一阶段，不是简单地“记得越多越好”，而是记忆要分层、可见、可控。

ChatGPT 的重点是跨会话个人化，Claude Code 的重点是代码项目连续性，Gemini 的重点是 Google 生态上下文。真正好用的长期 AI 协作，不是把所有信息塞进一个黑箱，而是让不同类型的记忆待在合适的位置。

个人偏好放在个人记忆里，工程规则放在代码库里，历史资料放在原本的文档和邮件系统里。AI 要做的，是在需要时准确调用这些上下文，而不是把所有东西混成一团。

Anthropic 提高 Claude 使用额度，并与 SpaceX 扩充算力

Thu, 07 May 2026 14:26:14 +0800

Anthropic 在 2026 年 5 月 6 日宣布，提高 Claude Code 和 Claude API 的部分使用额度，同时披露与 SpaceX 达成新的算力合作。

这条消息表面上是“额度变多了”，但真正值得看的，是模型公司正在把产品体验、订阅价格、API 限流和基础设施供应绑在一起。对重度用户来说，算力不是抽象概念，而是能不能跑更多 Claude Code 任务、能不能少排队、能不能稳定调用 Opus 模型。

Claude Code 和 API 额度怎么变

Anthropic 这次公布了三项变化，并表示都从公告当天开始生效。

第一，Claude Code 面向 Pro、Max、Team 和按席位计费的 Enterprise 方案，把五小时窗口内的使用限制提高到原来的两倍。

这对 Claude Code 的重度用户很直接。过去如果在短时间内让 Claude Code 连续读代码、改代码、跑任务，很容易碰到五小时额度限制。额度翻倍后，同一段工作时间内能承载更多连续开发任务。

第二，Pro 和 Max 账户不再受 Claude Code 高峰时段额度下调影响。

这点比数字本身更重要。很多 AI 工具最影响体验的，不是平时额度，而是高峰期突然变慢、变少、变不稳定。取消高峰时段的限制下调，说明 Anthropic 想让付费用户在忙时也有更可预期的体验。

第三，Anthropic 提高了 Claude Opus 模型的 API rate limits。原文中相关数值以表格图片展示，核心结论是 Opus API 的调用上限被明显上调。

从开发者角度看，Opus 一直是更贵、更重、能力也更强的模型。提高 Opus API 限额，意味着 Anthropic 不只想让用户在聊天界面里多用 Claude，也希望更多企业和开发者把 Opus 放进真实业务流程。

SpaceX 算力合作的分量

额度提高背后，是新的算力供给。

Anthropic 表示，已经与 SpaceX 签署协议，将使用 SpaceX 的 Colossus 1 数据中心全部算力容量。这项合作会在一个月内带来超过 300 兆瓦的新容量，对应超过 22 万块 NVIDIA GPU。

这组数字说明两件事。

第一，前沿模型公司的瓶颈仍然是算力。模型能力、上下文长度、工具调用、代码代理、多模态和企业场景都会消耗大量推理资源。用户越多、任务越复杂，平台越需要稳定的大规模 GPU 供给。

第二，AI 基础设施竞争已经进入超大规模阶段。过去大家更关注模型榜单、产品功能和价格；现在，谁能更快拿到电力、机房、网络和 GPU，谁就更有机会把模型能力变成稳定产品。

Anthropic 还提到，这次 SpaceX 合作会直接改善 Claude Pro 和 Claude Max 订阅用户的容量体验。也就是说，它不是只服务训练集群，也会进入面向用户的推理供给。

Anthropic 的算力版图

SpaceX 不是 Anthropic 唯一的算力合作。

Anthropic 在公告中同时回顾了几项已经公布的基础设施安排：

与 Amazon 的最高 5GW 协议，其中包括到 2026 年底前接近 1GW 的新增容量。
与 Google 和 Broadcom 的 5GW 协议，预计从 2027 年开始逐步上线。
与 Microsoft 和 NVIDIA 的战略合作，其中包括 300 亿美元 Azure 容量。
通过 Fluidstack 在美国 AI 基础设施上投入 500 亿美元。

这些合作的共同点，是 Anthropic 不把自己绑定在单一硬件或单一云平台上。原文明确提到，Claude 的训练和运行会使用 AWS Trainium、Google TPU 和 NVIDIA GPU。

这种多供应商路线有现实意义。单靠一家云厂商，很难长期满足前沿模型训练和大规模推理的峰值需求。多平台布局虽然会增加工程复杂度，但能降低供应链和容量风险。

为什么额度提升本质上是算力问题

AI 产品的“额度”不是普通互联网产品里的会员权益文案，它背后对应真实成本。

Claude Code 每次读取仓库、生成补丁、执行长任务，都会消耗推理资源。API 用户如果把 Opus 接入客服、金融分析、代码审查、文档处理或 agent 工作流，也会产生持续调用。对平台来说，放宽限额就意味着要有更多稳定算力兜底。

所以这次公告的逻辑很清楚：先说明用户能获得更高限制，再解释这些限制为什么现在可以提高。新增的 SpaceX 容量，以及此前和 Amazon、Google、Microsoft、NVIDIA、Fluidstack 的合作，都是为了支撑更重的使用场景。

这也解释了为什么 AI 产品会越来越强调不同计划之间的分层。免费用户、Pro 用户、Max 用户、Team 用户、Enterprise 用户，对算力的消耗和付费能力不同。模型公司必须把额度、优先级、模型访问和基础设施成本重新匹配起来。

轨道 AI 算力的信号

公告里还有一个很有未来感的细节：Anthropic 表示，作为这项协议的一部分，它也表达了与 SpaceX 合作开发多吉瓦级轨道 AI 算力容量的兴趣。

这并不等于轨道数据中心马上会成为现实产品。更稳妥的理解是，前沿 AI 公司已经开始把未来算力供给想象到地面数据中心之外。

AI 数据中心受电力、土地、冷却、网络和监管限制。随着训练和推理需求继续扩大，行业会探索更多基础设施形态。轨道算力现在听起来很远，但它出现在 Anthropic 的正式公告里，本身就是一个信号：算力竞争的想象空间正在被拉大。

国际化和合规需求

Anthropic 还提到，企业客户，尤其是金融、医疗和政府等受监管行业，越来越需要本地化基础设施来满足合规和数据驻留要求。

这意味着模型公司不能只在美国集中建设数据中心。企业 AI 要进入真实业务，就必须处理区域合规、数据驻留、供应链安全、电力成本和当地社区关系。Anthropic 表示，与 Amazon 的合作中已经包括亚洲和欧洲的新增推理能力。

它还强调，会优先选择法律和监管框架支持大规模投资、供应链安全的民主国家，并探索把美国数据中心电价承诺扩展到其他司法辖区。

这部分内容说明，AI 基础设施不只是技术问题，也会越来越像能源、制造业和地缘经济问题。

简短判断

Anthropic 这次公告可以概括为一句话：Claude 的额度提高，是因为背后有新的大规模算力供给。

对用户来说，短期影响是 Claude Code 五小时限制提高、Pro 和 Max 高峰期限制减少、Opus API 调用空间变大。对行业来说，更重要的是模型公司竞争正在从“谁的模型更强”扩展到“谁能持续拿到足够多、足够稳定、足够合规的算力”。

未来 AI 产品的体验差距，很可能不只来自模型参数和产品设计，也来自基础设施能力。谁能把电力、GPU、数据中心、云合作和区域合规组织起来，谁就更有机会把前沿模型变成可长期使用的服务。

CC Switch：一个桌面工具统一管理 Claude Code、Codex、Gemini CLI 和 OpenClaw

Wed, 06 May 2026 09:03:08 +0800

CC Switch 是一个面向 AI 编程重度用户的桌面管理工具。它要解决的问题很直接：现在很多人同时使用 Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw，但每个工具都有自己的配置格式、Provider 写法、MCP 配置和 Skills 管理方式。

当你只用一个工具时，手动改配置还能忍；一旦多个工具混用，再加上官方账号、第三方 API、中转服务、本地模型和团队共享配置，手动编辑 JSON、TOML、.env 很快就会变成一件很烦的事。

CC Switch 的定位，就是把这些分散配置收进一个跨平台桌面应用里。

它解决什么问题

现代 AI 编程工具越来越像“命令行里的开发同事”，但每个工具的生态还没有完全统一。

常见痛点包括：

Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw 配置格式不同。
切换 API Provider 时，要反复改配置文件。
MCP server 在不同工具之间重复配置。
CLAUDE.md、AGENTS.md、GEMINI.md 这类提示文件难以统一维护。
Skills 安装、同步、备份和卸载缺少一个集中入口。
多个账号、多个 relay、多个模型服务切换很容易搞混。
配置文件手工修改出错后，排查成本很高。

CC Switch 的思路是：不要让用户记住每个工具的配置细节，而是用一个统一界面管理 Provider、MCP、Prompts、Skills、Sessions 和代理。

支持哪些工具

README 中列出的核心支持对象包括五类：

Claude Code
Codex
Gemini CLI
OpenCode
OpenClaw

这几个工具本身定位相近，都是围绕 AI 编程、Agent 工作流和命令行协作展开。但它们的配置体系不同，CC Switch 的价值就在于把这些差异包装起来。

对经常比较不同 AI 编程工具的人来说，这比每次手动翻配置文件省心很多。

Provider 管理

CC Switch 的第一层能力是 Provider 管理。

它内置了 50 多个 Provider 预设，README 中提到的方向包括 AWS Bedrock、NVIDIA NIM，以及各种社区 relay。用户可以复制 API key，一键导入，然后在界面中切换。

实用点主要有几个：

一键添加 Provider。
Provider 拖拽排序。
系统托盘快速切换。
Provider 导入和导出。
部分通用 Provider 可同步到多个应用。

对很多人来说，这个功能已经足够有吸引力。因为 AI 编程工具的日常使用，经常不是“模型不会用”，而是“今天这个 key 用哪个工具、哪个 endpoint、哪个账号”容易乱。

本地代理与故障切换

除了写配置文件，CC Switch 还提供本地代理模式。

这个能力的重点是：

热切换 Provider。
格式转换。
自动故障转移。
熔断器。
Provider 健康检查。
请求修正。

简单说，它不只是把配置写进目标工具，还可以在中间加一层本地代理，让不同工具通过代理访问模型服务。

这对多 Provider 用户很有用：一个服务挂了，可以切到另一个；一个模型贵，可以换成更便宜的；某个请求格式不兼容，也可以通过代理层做适配。

MCP、Prompts 和 Skills

CC Switch 比较重要的第二层能力，是统一管理 MCP、Prompts 和 Skills。

MCP

它提供统一 MCP 面板，可以在多个应用之间管理 MCP server，并支持双向同步和 Deep Link 导入。

这对正在用 MCP 的用户很实用。因为 MCP server 一多，配置很容易分散在不同客户端里。统一面板可以减少重复配置，也方便迁移。

Prompts

Prompts 部分支持 Markdown 编辑，并且可以在不同工具之间同步对应文件，例如：

CLAUDE.md
AGENTS.md
GEMINI.md

这些文件本质上都是给 Agent 的项目说明书。统一管理后，可以更容易维护团队规则、项目约定和全局提示。

Skills

Skills 支持从 GitHub 仓库或 ZIP 文件一键安装，也支持自定义仓库管理、符号链接和文件复制。

如果你同时使用 Claude Code、Codex、OpenClaw 这类工具，Skills 很容易变成一堆散落在不同目录的文件。CC Switch 把它们集中起来，能降低维护成本。

会话与工作区

README 还提到 Session Manager 和 Workspace 相关能力。

它可以浏览、搜索和恢复多个应用里的会话历史。对长期使用 AI 编程工具的人来说，会话管理其实很重要：很多有价值的上下文、调试过程、方案比较，都埋在旧对话里。

此外，它还为 OpenClaw 提供 Workspace editor，可以编辑 AGENTS.md、SOUL.md 等 agent 文件，并带 Markdown 预览。

这说明 CC Switch 不只是一个“切换 key 的小工具”，而是在往 AI Agent 工作台方向扩展。

云同步与数据存储

CC Switch 支持通过 Dropbox、OneDrive、iCloud、NAS 或 WebDAV 同步 Provider 数据。

本地数据存储方式也比较清楚：

数据库：~/.cc-switch/cc-switch.db
本地设置：~/.cc-switch/settings.json
自动备份：~/.cc-switch/backups/
Skills：~/.cc-switch/skills/
Skill 备份：~/.cc-switch/skill-backups/

它使用 SQLite 作为主要数据源，并强调原子写入和自动备份，目标是避免配置文件在切换或写入时损坏。

这个设计对重度用户很关键。因为一旦配置管理工具本身把配置写坏，影响的是所有 AI 编程工具。

安装方式

CC Switch 是跨平台桌面应用，基于 Tauri 2 构建。

系统要求大致如下：

Windows：Windows 10 及以上
macOS：macOS 12 Monterey 及以上
Linux：Ubuntu 22.04+、Debian 11+、Fedora 34+ 等主流发行版

Windows 用户可以下载 .msi 安装包或便携版压缩包。

macOS 用户可以用 Homebrew：

1
2

brew tap farion1231/ccswitch
brew install --cask cc-switch

更新：

`1`	`brew upgrade --cask cc-switch`

Linux 用户可以选择 .deb、.rpm 或 AppImage。Arch Linux 用户也可以通过 paru -S cc-switch-bin 安装。

截至 2026 年 5 月 6 日，仓库页面显示最新 release 为 CC Switch v3.14.1，发布时间是 2026 年 4 月 23 日。

技术栈

从仓库结构看，CC Switch 是典型的 Tauri 桌面应用：

前端：React 18、TypeScript、Vite、TailwindCSS、TanStack Query、shadcn/ui
后端：Tauri 2、Rust、SQLite、Tokio
测试：Vitest、MSW、Testing Library

核心设计模式包括：

SQLite 作为 Single Source of Truth。
JSON 保存设备级本地设置。
切换时写入目标工具的 live config。
编辑当前 Provider 时从 live config 回填。
使用临时文件加 rename 的方式做原子写入。
数据库连接加锁，避免并发写入问题。

这类架构说明项目并不是简单脚本，而是按长期桌面工具来设计的。

适合谁用

CC Switch 适合下面几类用户：

同时使用 Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw。
经常切换官方账号、第三方 relay、本地模型或团队 Provider。
已经开始大量使用 MCP。
想统一维护 CLAUDE.md、AGENTS.md、GEMINI.md。
经常安装、测试和迁移 Skills。
想看不同工具的会话历史和使用情况。

如果你只用一个 AI 编程工具，而且一直走官方登录，不怎么折腾 Provider、MCP 和 Skills，那它的价值可能没那么明显。

但如果你已经进入“多工具、多账号、多 Provider、多项目”的状态，它能省掉很多琐碎配置工作。

需要注意什么

这类工具很方便，但也要注意边界。

第一，它会管理多个 AI CLI 的配置，因此要确认自己信任这个工具和它的写入逻辑。

第二，API key、relay endpoint、MCP server 都属于敏感配置。开启云同步前，要确认同步目录和 WebDAV 服务本身安全可靠。

第三，切换 Provider 后，多数工具仍然需要重启终端或 CLI 才能生效。README 中提到，Claude Code 对 Provider 数据支持热切换，但其他工具通常仍需要重启。

第四，切回官方登录时，最好按项目说明添加 official provider，再重新走对应工具的登录流程。

小结

CC Switch 的价值不在于又做了一个 AI 编程工具，而在于它承认了一个现实：AI 编程生态已经进入多工具并存阶段。

Claude Code、Codex、Gemini CLI、OpenCode、OpenClaw 各有自己的配置系统，MCP、Skills、Prompts、Provider 又在快速扩展。继续靠手动改配置，迟早会变成负担。

CC Switch 把这些东西收进一个桌面应用里，让用户可以更轻松地切换 Provider、同步 MCP、管理 Skills、维护提示文件和查看会话。对重度 AI 编程用户来说，这类工具很可能会从“可选小工具”变成“日常基础设施”。

参考资料

farion1231/cc-switch

Claude Code 的 HERMES.md 计费故障是怎么回事

Sat, 02 May 2026 11:05:48 +0800

Claude Code 最近有一次很典型的计费故障：用户只是启动 CLI，还没有正式发出请求，就因为本地 HERMES.md 文件被读取而产生了大额费用。

这件事值得单独看，不是因为某个用户损失了多少钱，而是因为它暴露了 AI 编程工具的一个新风险：只要工具会自动读取上下文，本地文件就可能变成真实 token 成本。

发生了什么

公开 issue 显示，用户在工作目录里放了一个很大的 HERMES.md 文件。启动 Claude Code 后，CLI 会扫描并加载项目上下文。问题在于，这个文件被自动纳入上下文，并被计入 API 使用量。

用户并没有明确要求模型处理这份文件，但计费已经发生。更麻烦的是，这类行为发生在工具初始化或上下文准备阶段，用户不一定能第一时间意识到费用正在产生。

Anthropic 后续在 issue 中回复，表示会退还异常费用，并额外提供额度补偿。这个回应说明问题至少已被官方确认和处理，但它仍然提醒用户：AI CLI 的“自动上下文”不是免费的。

HERMES.md 为什么会触发问题

HERMES.md 本身不是重点。它可以换成任何大文件：长日志、导出的文档、测试数据、数据库 dump、生成报告，都可能造成类似问题。

真正的问题在于三件事叠加：

Claude Code 会自动读取项目上下文。
被读取的文件可能很大。
上下文 token 会进入计费链路。

如果一个文件足够大，哪怕只是被工具“顺手带上”，也可能产生明显费用。对按 token 计费的模型来说，自动化越强，越需要明确边界。

这不是普通 bug

普通 CLI bug 可能只是命令失败、输出错误或功能不可用。计费 bug 更敏感，因为它直接影响用户账单。

对 AI 编程工具来说，计费边界很容易变模糊：

系统提示会消耗 token。
项目规则会消耗 token。
自动读取的文件会消耗 token。
工具调用结果会消耗 token。
重试、压缩、摘要也可能继续消耗 token。

用户看到的是一次“启动工具”或“一次对话”，后台实际可能已经发生多次请求和大量上下文传输。

用户应该怎么防

如果你使用 Claude Code、Codex、Cline 这类 AI 编程工具，可以先做几件事：

不要把大文件直接放在项目根目录。
把日志、导出数据、构建产物、临时文件加入忽略规则。
检查工具是否支持类似 .ignore、上下文排除、文件白名单的配置。
开启预算提醒或用量限制。
第一次在大型仓库运行前，先用小目录测试。

如果仓库里必须保留大文件，最好明确告诉工具不要读取它们。项目规则里也可以写清楚：不要主动读取日志、dump、数据集、归档文件和大体积 Markdown。

工具厂商该怎么改

这类问题不能只靠用户小心。工具本身也应该给出硬边界。

更合理的设计包括：

初始化阶段不应隐式计入大文件。
自动读取超大文件前要提示用户确认。
CLI 应显示本次请求预计 token 和费用区间。
默认忽略常见大文件和生成目录。
对异常 token 激增设置保护阈值。

AI 编程工具越像“自动代理”，越需要把成本透明化。否则用户很难判断一次操作到底会产生多少费用。

小结

Claude Code 的 HERMES.md 计费故障，本质上是自动上下文和按量计费之间的冲突。

对用户来说，最重要的是把项目上下文管住：大文件不要默认暴露给 AI 工具，预算和用量也要设上限。对工具厂商来说，自动读取文件必须配套可见的成本提示和保护机制。

参考：

DeepSeek V4 降价如何改写 AI Agent 的成本模型

Fri, 01 May 2026 19:47:47 +0800

DeepSeek V4 发布时没有制造出特别夸张的声量。没有大型发布会，也没有一眼碾压所有对手的跑分叙事。但几天之后，它真正影响行业的地方开始显现：连续降价。

这次变化的重点不是“模型强了一点”，而是“使用成本被打到另一个层级”。当 Token 价格低到普通 Agent 任务几毛钱、一两块钱就能跑完时，很多 Coding Plan、Token Plan 的商业逻辑都会被重新审视。

发布当天没有炸场

DeepSeek V4 的第一波反馈并不算热烈。很多人期待它像 R1 那样带来强烈冲击：跑分全面领先、国产算力验证、多模态和 Agent 能力一起爆发。但真正发布后，大家发现它更像一次稳健升级。

V4 Pro 确实是强模型，尤其在代码、数学、长上下文和 agentic coding 上表现不错。但它不是那种让所有同类模型瞬间失色的产品。所以发布当天，舆论一度有些尴尬：想夸，但很难找到一个足够爆炸的角度。

真正的转折点不是发布当天，而是后续价格调整。

连续降价才是关键

DeepSeek V4 发布后，价格开始连续下探。按照 DeepSeek 官方价格页和原文整理的信息，当时的大致价格是：

DeepSeek V4 Flash：输入 100 万 Token 约 1 元；缓存命中后 100 万 Token 约 2 分钱；
DeepSeek V4 Pro：输入 100 万 Token 约 3 元；缓存命中后 100 万 Token 约 2.5 分；
全系列模型输入缓存命中价格降到首发价格的 1/10；
V4 Pro 曾处在 2.5 折优惠期，优惠延长到 2026 年 5 月 31 日 23:59。

如果按美元 API 价格看，会更直观：

模型	缓存命中输入	非缓存输入	输出	上下文
`deepseek-v4-flash`	$0.0028 / 100万 Token	$0.14 / 100万 Token	$0.28 / 100万 Token	1M
`deepseek-v4-pro` 促销价	$0.003625 / 100万 Token	$0.435 / 100万 Token	$0.87 / 100万 Token	1M
`deepseek-v4-pro` 原价	$0.0145 / 100万 Token	$1.74 / 100万 Token	$3.48 / 100万 Token	1M

这里要注意两个点。

第一，V4 Pro 的 $0.435 / $0.87 是促销价，不是长期原价。 DeepSeek 官方说明里，这个 75% 折扣延长到 2026 年 5 月 31 日 15:59 UTC。

第二，缓存命中价格才是 Agent 成本模型里的关键。 Flash 的缓存命中输入低到 $0.0028 / 100万 Token，Pro 促销期缓存命中输入是 $0.003625 / 100万 Token。这意味着大量重复项目上下文、工具定义、系统提示词和历史摘要，不再按完整输入价格计费。

这个价格最重要的地方，是它让很多任务的 Token 成本变得“不敏感”。过去开发者会担心一次 Agent 任务吃掉大量上下文、反复读写代码、频繁调用工具。现在只要缓存命中率足够高，成本会被压得很低。

和 GPT、Claude 的价格对比

只看 DeepSeek 自己的价格，还不容易感受到差距。把它和同期常见的闭源模型放在一起，对比会更明显。

模型	输入	缓存输入	输出	适合场景
`deepseek-v4-flash`	$0.14 / M	$0.0028 / M	$0.28 / M	高频 Agent、常规 coding、批量任务
`deepseek-v4-pro` 促销价	$0.435 / M	$0.003625 / M	$0.87 / M	复杂 coding、规划、事实核查
`deepseek-v4-pro` 原价	$1.74 / M	$0.0145 / M	$3.48 / M	促销结束后的 Pro 成本基准
GPT-5.5	$5 / M	$0.50 / M	$30 / M	高质量复杂任务、通用推理
GPT-5.4	$2.50 / M	$0.25 / M	$15 / M	编程和专业任务的中档选择
GPT-5.4 mini	$0.75 / M	$0.075 / M	$4.50 / M	成本更低的通用/子任务模型
Claude Opus 4.7	$5 / M	$0.50 / M	$25 / M	高质量写作、复杂推理、长任务
Claude Sonnet 4.6	$3 / M	$0.30 / M	$15 / M	编程、Agent、综合任务
Claude Haiku 4.5	$1 / M	$0.10 / M	$5 / M	轻量任务、摘要、分类

这张表里最刺眼的是输出价格。 Agent 不只读上下文，还会不断生成计划、补丁、解释、日志和下一步动作。如果输出很多，DeepSeek V4 Pro 促销价的 $0.87 / M 和 GPT-5.5 的 $30 / M、Claude Sonnet 4.6 的 $15 / M 相比，差距会被不断放大。

即使按 V4 Pro 原价 $3.48 / M 输出算，它也明显低于 GPT-5.4、GPT-5.5 和 Claude Sonnet / Opus。如果任务可以用 Flash 承担，输出价会进一步降到 $0.28 / M。

缓存输入差距更夸张。 DeepSeek V4 Flash 的缓存输入是 $0.0028 / M，而 GPT-5.5 和 Claude Opus 4.7 的缓存输入都是 $0.50 / M。这不是同一个数量级。对反复读取同一代码仓库的 Agent 来说，这个差距比普通聊天更重要。

Agent 任务为什么特别受影响

AI Agent 和普通聊天不一样。普通聊天通常是一问一答，输入上下文相对有限。 Agent 任务会反复读取项目文件、生成计划、调用工具、检查结果、再修改代码。

这类任务有两个特点：

Token 消耗大；
重复上下文多。

第二点很关键。在代码项目里，模型会反复读取同一批文件、目录结构、错误日志和修改结果。如果平台支持缓存命中，重复输入的成本会大幅下降。

原文里提到一次实际体验：把 DeepSeek V4 Pro 和 Flash 接到 Claude Code 一类工具中，让它拉取一个提示词仓库并做成本地搜索网站。任务最终完成，总成本大约 8 毛多，其中 Pro 缓存命中率达到 98.7%。

这个例子说明了一个现实问题：Agent 任务越像“围绕同一个项目反复工作”，缓存命中越有价值。如果一次生成网站、修 bug、改前端只花几毛钱到几块钱，订阅套餐的吸引力就会下降。

可以用一个简化任务估算差距。假设一次 coding agent 任务包含：

50 万 Token 输入，其中 80% 能命中缓存；
5 万 Token 输出；
不计算工具调用、搜索和平台加价，只看模型 Token 成本。

大致成本如下：

模型	估算成本
DeepSeek V4 Flash	约 $0.03
DeepSeek V4 Pro 促销价	约 $0.09
DeepSeek V4 Pro 原价	约 $0.36
GPT-5.4 mini	约 $0.30
GPT-5.4	约 $1.01
GPT-5.5	约 $1.75
Claude Sonnet 4.6	约 $1.11
Claude Opus 4.7	约 $1.65

这个估算不是说 DeepSeek 在所有任务上都更好。模型质量、工具调用稳定性、长上下文检索能力、代码风格和事实可靠性都要单独评估。但从成本上看，DeepSeek V4 把“让 Agent 多跑几轮”的边际成本压得很低。这会鼓励开发者设计更长流程、更频繁的自检和更多候选方案，而不是每次都担心 Token 账单。

Coding Plan 和 Token Plan 的差别

很多 AI 产品现在会提供两类套餐：Coding Plan 和 Token Plan。

它们的差别大致是：

Coding Plan 通常主要面向编程；
Token Plan 通常覆盖更多能力，例如 STT、TTS、绘图、搜索、embedding、RAG；
STT 是语音转文字；
TTS 是文字转语音；
Coding Plan 往往把用户限制在编程场景里，其他能力还需要另买。

从商业角度看，Coding Plan 更像自助餐。用户预先付一笔固定费用，厂商赌的是大多数人不会把额度用满。有人用得多，有人用得少，平均下来平台仍然能赚钱。

但如果按量 Token 价格足够低，用户就会开始计算：我为什么一定要买套餐？如果一个月真实使用成本只有几块钱、十几块钱，买 40 元、200 元的套餐就不一定划算。

降价为什么会冲击套餐模式

订阅套餐的成立，需要一个前提：用户觉得单次使用很贵，或者不想计算每次调用成本。当 Token 价格高时，套餐看起来更安心。当 Token 价格低到几乎无感时，按量付费反而更自然。

DeepSeek V4 的降价相当于把底牌亮出来：

Agent 任务可以很便宜；
长上下文不一定贵到不能用；
缓存命中可以显著降低成本；
普通开发者不一定需要固定订阅；
模型入口可以从“套餐平台”转向“低价 API”。

这会让做 Coding Plan 的平台不舒服。如果用户发现按量调用更便宜、更自由，就没必要为了一个平台的套餐被绑定。

Flash 和 Pro 怎么选

DeepSeek V4 的一个实用思路，是把 Flash 和 Pro 分工使用。

Flash 适合高频、轻量、可重复的任务：

改 bug；
写前端；
写脚本；
做常规代码理解；
处理较长上下文里的普通信息整理；
跑大量子任务。

Flash 便宜，速度快，而且同样支持很长上下文。对日常 coding agent 来说，很多任务不需要一上来就用 Pro。

Pro 更适合复杂判断和兜底任务：

多轮规划；
复杂 Agent 流程；
多次 function call；
事实核查；
财经研究；
需要更强知识和判断力的内容生产；
高风险代码修改。

一个合理配置是：Flash 负责跑量，Pro 负责兜底。普通任务先用 Flash，遇到长程规划、复杂判断、事实核查或多工具协作时再切 Pro。这样既能控制成本，也能保留模型质量。

DeepSeek 为什么可以这么定价

DeepSeek 和很多大厂的业务结构不同。它没有电商、社交、短视频、云计算、手机、汽车、办公套件、操作系统、浏览器或大规模企业 SaaS 生态。

这意味着它不需要把用户锁在一个完整平台里。它可以只卖文本模型能力：你在这里用便宜的文本模型，其他能力要调用谁都可以。

大厂的逻辑通常不同。如果你买了它的 Coding Plan 或 Token Plan，就会被拉进它的云、搜索、绘图、语音、数据库和开发工具生态。套餐不是单纯卖模型，而是在争夺用户入口。

DeepSeek 的打法更直接：把文本模型价格压低，争取成为 Agent 的默认模型入口。只要默认入口被占住，很多开发者和工具链就会自然围绕它适配。

开源模型和默认入口

DeepSeek V4 如果保持开放模型路线，第三方云厂商和平台很可能会自行部署并提供服务。这对 DeepSeek 来说既是传播，也可能是分流。

低价官方 API 的意义就在这里。如果官方价格已经足够低，其他平台即使能部署，也很难在价格上明显更有优势。用户会倾向于直接使用默认、便宜、稳定的入口。

对 Agent 工具尤其如此。 Agent 任务依赖长上下文、缓存、工具调用和稳定吞吐。一旦某个模型在这些场景里成本足够低，它就有机会成为默认选项。

Coding Plan 仍然不是完全没用

这并不意味着 Coding Plan 会马上消失。它仍然有适合的人群。

如果某些用户真的是高强度使用者，每天把套餐额度打满，那么固定订阅可能仍然划算。就像自助餐，如果完全没有人能吃回本，用户也不会愿意买。

但问题在于，绝大多数用户不是这种极端高频用户。低频用户、轻量开发者、偶尔写脚本或改项目的人，更适合按量付费。当 DeepSeek 把按量成本压低后，套餐的吸引力会被削弱。

未来更可能出现的是分层选择：

高频重度用户继续买 Coding Plan；
普通用户转向低价 API；
Agent 工具根据任务自动选择 Flash / Pro；
平台套餐需要提供更多非模型价值，例如工作流、IDE 集成、部署、团队管理和安全审计。

小结

DeepSeek V4 的发布并没有靠跑分制造最大冲击。真正改变行业预期的是后续降价。

当输入 Token 和缓存命中价格被压到很低时，AI Agent 的使用成本会发生变化。过去看起来昂贵的长上下文、代码项目分析、多轮工具调用，现在可能变成几毛钱到几块钱的日常消耗。

这会直接冲击 Coding Plan 和 Token Plan 的商业逻辑。如果用户可以按量付费、自由组合模型和工具，而且成本足够低，就不一定愿意被绑定在某个平台套餐里。

DeepSeek V4 这次真正动到的，不只是模型能力排名，而是 AI Agent 的成本结构和默认入口之争。

参考来源：

mattpocock/skills：给 AI 编程 Agent 准备的实用技能集合

Fri, 01 May 2026 03:43:20 +0800

mattpocock/skills 是 Matt Pocock 公开的一组 AI 编程 agent skills。

它不是一个完整的应用，也不是一个新的聊天客户端，而是一套可以给 AI 编程助手使用的工作技能。它的思路很实用：把 AI 编程里经常出现的问题拆成一个个小技能，让 Agent 在合适的任务里调用，而不是每次都靠一大段提示词硬撑。

如果你经常使用 Claude Code、Codex、Cursor 或类似的 AI 编程工具，这类 skills 很值得关注。因为真正影响 AI 编程体验的，往往不是“模型会不会写代码”，而是它能不能按你的工作方式推进任务。

它解决什么问题

AI 编程助手很强，但也很容易出问题。

常见情况包括：

还没理解需求就开始改代码
一次性改太多文件
输出解释很多，真正有用的行动很少
遇到报错后盲目尝试
没有及时运行测试或检查
忽略项目里已有模式
为了完成任务引入不必要的抽象
写完代码后没有真正 review 风险

这些问题不一定是模型能力不够，而是工作流没有被约束好。

mattpocock/skills 的价值在于，把这些常见失败模式拆成可以复用的操作方式，让 Agent 在不同场景下更像一个有经验的工程协作者。

Skills 是什么

在 AI Agent 语境里，skill 可以理解成一段可复用的任务说明、工作方法或专业流程。

它不一定是代码插件，也不一定必须调用外部服务。很多时候，一个 skill 就是一套明确规则：

什么时候使用
先做什么
不要做什么
需要输出什么
怎么判断任务完成

这和普通提示词模板有点像，但粒度更接近“任务能力”。

普通提示词模板通常是用户每次临时复制粘贴；skills 则更适合作为 agent 工具箱的一部分，让 Agent 根据任务选择合适流程。

为什么要小而可组合

README 中强调这些 skills 是小而可组合的。

这个方向很重要。

如果一个 skill 试图包办所有事情，它很快就会变成新的大提示词：又长、又模糊、又难维护。小技能的优势是边界清楚。

比如一个 skill 专门负责：

先做计划
修复 TypeScript 错误
运行测试并根据结果修复
做代码 review
总结项目约定
改进提示词
清理无用抽象

这些技能可以按任务组合使用。简单任务只用一个技能，复杂任务再串起来。

这更接近真实工程工作：你不会用同一套流程处理所有问题，而是根据问题选择工具。

保留工程师控制权

这个仓库的一个重要取向，是让工程师仍然掌握控制权。

AI 编程很容易滑向两种极端：

第一种是完全手动。AI 只是帮你写几行代码，所有上下文、计划、验证都靠你自己盯。

第二种是完全放手。你把任务丢给 Agent，让它自己大改一通，最后再面对一堆难以审查的 diff。

skills 的作用是在中间找一个更稳的位置。

它让 AI 承担更多重复流程，但仍然用规则限制它：

先理解任务再动手
先阅读相关文件再改
修改范围要可控
出现不确定时要回报
改完要验证
不能为了炫技重构无关代码

这不是削弱 AI，而是让 AI 的行动更容易被人类审查和接管。

对齐问题

AI 编程失败的第一类问题通常是对齐失败。

用户想要的是一个很具体的改动，但 Agent 可能理解成一个更大的重构；用户只想修 Bug，它却顺手改了样式；用户希望遵守现有架构，它却引入新模式。

Skills 可以在任务开始阶段帮助 Agent 做几件事：

重述目标
找出影响范围
识别已有实现模式
给出计划
明确不做哪些事情

这一步很像工程师开工前的自检。

如果 Agent 连任务边界都没说清楚，就直接写代码，后面很容易越走越偏。

反馈循环问题

AI 写代码不能只靠一次生成。

真实开发里，反馈循环很重要：

改一小步
跑测试或类型检查
看错误
修正
再验证

很多 Agent 失败，是因为它跳过了中间反馈。它一次性改很多内容，然后凭感觉总结“应该可以工作”。

Skills 可以把反馈循环显式写进流程里。比如要求 Agent：

修改后运行相关检查
如果检查失败，先读错误信息
不要盲目改无关文件
每轮修复后重新验证
最后报告验证结果

这会让 AI 编程更像真实调试，而不是一次性作文。

架构控制问题

AI 很擅长生成抽象，也很擅长过度生成抽象。

为了完成一个小需求，它可能新建服务层、工具函数、配置对象、类型包装、适配器，最后让代码比需求本身复杂得多。

这类问题在大型项目里尤其危险。因为 AI 生成的抽象看起来很“专业”，但它可能不符合项目已有风格，也可能增加维护成本。

好的 skills 会提醒 Agent：

优先沿用现有模式
不引入没有必要的新抽象
不顺手重构无关区域
修改要和任务规模匹配
先理解代码再设计结构

这能减少“看起来很工程化，实际上更难维护”的输出。

Review 技能为什么重要

写代码和 review 代码是两种不同状态。

Agent 在写代码时，通常会倾向于证明自己的实现成立。它会解释为什么这样改可以工作，但不一定主动找风险。

Review skill 的意义，是让 Agent 切换角色：

找潜在 Bug
找行为回归
找遗漏测试
找边界条件
找复杂度上升
找和现有约定不一致的地方

这对 AI 编程很重要。因为 AI 生成代码的速度很快，如果没有 review，用户很容易被大量 diff 淹没。

一个好的 review 输出应该优先列问题，而不是先夸实现。它要帮助工程师判断这次改动能不能合并。

和普通 rules 文件有什么区别

很多 AI 编程工具都支持 rules、instructions 或 memory。

这些文件通常记录长期规则，比如：

项目技术栈
命名规范
测试命令
不要修改哪些目录
回答风格偏好

Skills 更偏任务流程。

rules 告诉 Agent “长期应该怎么做”，skills 告诉 Agent “面对某类任务时应该怎么执行”。

两者最好一起用。

比如 rules 里写项目用 pnpm test，review skill 里要求改完后检查测试覆盖。这样 Agent 不仅知道命令，也知道什么时候该用。

适合什么场景

mattpocock/skills 这类仓库适合这些场景：

高频使用 AI 编程工具
经常让 Agent 处理真实代码库
想减少 AI 越界修改
想让 Agent 更主动地验证结果
想把自己的工程习惯沉淀成技能
想学习别人如何设计 agent workflows
想把一堆临时提示词整理成可维护的技能集合

如果你只是偶尔让 AI 写一个小函数，可能不需要专门维护 skills。

但如果你已经把 AI 当成长期开发伙伴，skills 会逐渐变得重要。它们相当于给 Agent 配了一套可复用的工作方法。

怎么借鉴这个仓库

即使你不直接使用其中的每个 skill，也可以从这个仓库学到几件事。

第一，把失败模式写下来。

不要只在 AI 出错时临时抱怨。把它经常出错的模式整理成规则，下一次让 skill 提前防住。

第二，技能要短。

一个 skill 最好解决一个明确问题。越短越容易被正确调用，也越容易维护。

第三，输出格式要清楚。

如果你希望 Agent 先列计划、再执行、最后总结验证结果，就把输出结构写清楚。模糊要求通常会得到模糊结果。

第四，保留人工接管点。

好的 skill 不应该让 AI 独自跑到很远。遇到不确定、影响范围扩大、测试失败或需要产品判断时，应该让它停下来说明情况。

使用时要注意

第一，不要把所有事情都技能化。

太多 skills 会让系统变复杂，Agent 也可能不知道该选哪个。先从最高频、最痛的几个场景开始。

第二，skills 需要迭代。

第一次写出来的 skill 不一定好。看 AI 实际执行效果，再逐步删减、补充和改写。

第三，不要让 skill 替代工程判断。

Skill 可以改善流程，但不能保证实现正确。测试、review、构建检查和人类判断仍然重要。

第四，注意不同 Agent 的差异。

Claude Code、Codex、Cursor、Copilot 对 instructions、skills、rules 的支持方式不同。同一套思想可以复用，但具体格式要按工具调整。

参考

mattpocock/skills

最后一句

mattpocock/skills 值得关注的地方，不是里面某一个神奇提示词，而是它展示了一种更实用的 AI 编程思路：把工程经验拆成小技能，再让 Agent 按场景组合使用。

当 AI 编程从偶尔辅助变成日常工作流，skills 会成为约束 Agent、保留工程师控制权和提升反馈质量的重要工具。

free-claude-code：用代理把 Claude Code 接到 OpenRouter、DeepSeek 和本地模型

Fri, 01 May 2026 03:41:49 +0800

free-claude-code 是一个给 Claude Code 使用的 Anthropic-compatible proxy。

它的思路不是破解 Claude Code，也不是提供官方免费的 Claude 服务，而是在本地启动一个兼容 Anthropic API 形状的代理服务，把 Claude Code 发出的请求转发到其他模型后端。README 中提到的后端包括 NVIDIA NIM、OpenRouter、DeepSeek、LM Studio、llama.cpp 和 Ollama。

简单说，它想解决的是：你喜欢 Claude Code 的终端体验，但希望把模型请求接到别的 provider 或本地模型上。

它解决什么问题

Claude Code 的交互体验很适合开发任务。

它可以在终端里阅读代码、修改文件、执行命令、根据项目上下文推进任务。问题是，很多用户并不一定想始终使用同一个模型后端：

想试试 OpenRouter 上的不同模型
想用 DeepSeek 这类模型降低成本
想把请求接到本地 Ollama
想用 LM Studio 或 llama.cpp 跑本地模型
想在开发环境里统一走一个代理入口
想比较不同模型在 Claude Code 工作流里的表现

free-claude-code 的定位，就是在 Claude Code 和这些模型服务之间加一层兼容代理。

这样 Claude Code 仍然按 Anthropic 风格发请求，代理负责把请求适配到不同后端。

工作方式

可以把它理解成三层：

前端是 Claude Code
中间是 free-claude-code 代理
后端是 OpenRouter、DeepSeek、本地模型或其他模型服务

Claude Code 以为自己在访问一个 Anthropic-compatible API。

代理收到请求后，根据配置选择目标 provider，转换必要字段，再把响应返回给 Claude Code。

这类结构的好处是，你不用改 Claude Code 本身，也不用让每个模型服务都原生支持 Claude Code。只要代理能把接口对齐，就能把更多模型接进同一个工作流。

支持哪些后端

README 中列出的方向包括：

NVIDIA NIM
OpenRouter
DeepSeek
LM Studio
llama.cpp
Ollama

这些后端代表了几类不同使用方式。

OpenRouter 更像模型聚合入口，可以测试不同商业和开源模型。

DeepSeek 适合关注中文能力、代码能力和成本的人。

LM Studio、llama.cpp、Ollama 则偏本地模型路线。它们适合在自己的机器或内网环境里运行模型，减少外部 API 依赖，也方便做离线实验。

NVIDIA NIM 则更偏企业和 GPU 推理部署场景。

为什么是 Anthropic-compatible proxy

Claude Code 本来围绕 Anthropic 的接口和模型习惯设计。

如果你想让它接入其他模型，最直接的问题就是接口不一致：

请求字段不同
模型名称不同
streaming 格式不同
tool use 表达不同
错误返回格式不同
token 和上下文限制不同

代理层的价值就在这里。

它把 Claude Code 这边看到的接口维持在接近 Anthropic 的形状，再在后端做适配。对用户来说，配置一次代理后，就可以在相同 Claude Code 工作流里测试不同模型。

适合什么场景

free-claude-code 适合这些场景：

想用 Claude Code 的终端工作流
想测试非 Anthropic 模型在 Claude Code 里的表现
想降低模型调用成本
想把 Claude Code 接到 OpenRouter
想接入 DeepSeek 等兼容模型服务
想用 Ollama、LM Studio、llama.cpp 跑本地模型
想为团队统一配置一个模型代理入口

如果你只是正常使用官方 Claude Code，并且对模型提供方、成本和本地部署没有特殊需求，那不一定需要这类代理。

但如果你经常比较模型，或者希望让 Claude Code 接入本地和第三方模型，这类工具会很有用。

和直接用 OpenRouter 或 Ollama 有什么区别

直接用 OpenRouter、Ollama 或 LM Studio，通常只是和模型聊天，或者通过 API 调用模型。

free-claude-code 的重点不是替代这些服务，而是把它们接到 Claude Code 这个开发工作流里。

区别在于：

你仍然使用 Claude Code 的终端体验
AI 可以围绕代码仓库执行任务
模型后端可以换成其他 provider
本地模型也有机会进入 Claude Code 工作流
配置集中在代理层，而不是每个工具单独改

所以它更像桥接器，而不是新的聊天客户端。

本地模型要注意什么

把 Claude Code 接到本地模型很有吸引力，但也要注意现实限制。

第一，模型能力差距。

Claude Code 的任务通常不只是聊天，还包括理解代码、规划修改、编辑文件、处理命令输出。本地小模型不一定能稳定完成这些任务。

第二，上下文窗口。

代码任务很吃上下文。模型上下文太小，会导致它读不全文件、漏掉约束，或者在多轮任务里丢失背景。

第三，tool use 兼容性。

Claude Code 工作流依赖工具调用和结构化行为。后端模型即使能聊天，也未必擅长遵循工具调用协议。

第四，速度和硬件。

本地模型的速度取决于机器配置、量化方式和模型大小。代码任务如果响应太慢，体验会明显下降。

所以，本地模型更适合实验、低风险任务和特定场景。真正复杂的代码任务，仍然要根据模型能力谨慎选择。

使用边界

这类项目很容易被标题误解，所以边界要说清楚。

第一，它不是官方 Claude Code 免费额度。

它只是把 Claude Code 的请求转发到其他模型后端。你使用 OpenRouter、DeepSeek、NVIDIA NIM 或其他 API 时，仍然需要遵守对应服务的价格、额度和使用条款。

第二，它不是绕过授权的工具。

使用任何代理工具时，都应该遵守 Claude Code、模型服务商和项目本身的许可协议。不要把它理解成规避官方限制的方式。

第三，代理会处理你的请求内容。

代码、命令输出、项目上下文可能会经过代理和后端服务。部署时要考虑日志、密钥、网络和隐私边界。涉及公司代码或敏感项目时，最好使用受控环境。

第四，不同模型表现差异会很大。

同样的 Claude Code 操作，换一个模型后可能出现完全不同的行为。不要默认所有模型都能替代 Claude。

和 LiteLLM 这类代理有什么关系

从思路上看，free-claude-code 属于“兼容接口代理”这一类工具。

这类工具的共同目标是减少上层应用和底层模型服务之间的耦合。上层应用只需要面对一个相对统一的接口，底层 provider 可以按配置切换。

不同项目的侧重点不同。有的更偏通用模型网关，有的更偏 OpenAI-compatible API，有的专门为 Claude Code 这类工具做适配。

free-claude-code 值得关注的地方，是它把目标场景直接放在 Claude Code 上，而不是做一个泛泛的聊天代理。

适合怎样的用户

它更适合有一定折腾能力的用户：

熟悉 Claude Code
知道 API key 和模型 provider 怎么配置
能理解代理服务的启动和环境变量
能排查网络、端口、模型名称和 streaming 问题
愿意比较不同模型在代码任务里的表现

如果你只想开箱即用，官方配置通常更省心。

如果你愿意搭代理、换模型、调参数，并且想让 Claude Code 进入更多模型环境，这个项目就值得研究。

参考

Alishahryar1/free-claude-code

最后一句

free-claude-code 的价值，不在于“免费”这个词，而在于它把 Claude Code 和更多模型后端之间接了一座桥。

当你想保留 Claude Code 的开发体验，同时测试 OpenRouter、DeepSeek、本地模型或企业推理服务时，这类 Anthropic-compatible proxy 就有了用武之地。

Compound Engineering Plugin：把 AI 编程变成计划、执行、评审的工程循环

Fri, 01 May 2026 03:15:39 +0800

Compound Engineering Plugin 是 Every Inc 开源的一个 AI 编程工作流插件。

它关注的不是“让 AI 更快写一段代码”，而是把 AI 编程放进一个更像工程团队的循环里：先计划，再实现，再评审，再把经验沉淀下来。对经常使用 Claude Code、Codex、Cursor、Copilot 这类工具的人来说，这类插件解决的是工作流问题，而不只是提示词问题。

AI 编程工具越来越强，但真实项目里最难的往往不是生成代码，而是让它持续按项目规则做事、理解任务边界、避免重复犯错，并在多轮迭代中积累上下文。

它解决什么问题

很多人使用 AI 编程助手时，流程大概是这样：

直接描述需求
让 AI 改代码
看结果是否能跑
出错后继续补充说明
下次新任务再从头解释一遍

这种方式能完成小任务，但在复杂项目里很容易遇到问题：

需求没有先拆清楚，AI 直接开始改
改完代码后缺少系统性 review
项目规范靠用户反复提醒
同类错误下次仍然出现
多个 Agent 工具之间缺少统一工作方法
经验没有沉淀成可复用规则

Compound Engineering Plugin 想解决的就是这类问题。它把 AI 编程拆成多个阶段，让 Agent 不只是执行命令，而是参与一个更完整的工程流程。

什么是 Compound Engineering

从项目 README 的描述看，Compound Engineering 可以理解为一种 AI 辅助软件开发方法。

它强调一个循环：

计划：先理解目标、拆分任务、确认路径
执行：按计划修改代码、运行命令、处理问题
评审：检查实现质量、风险和测试覆盖
学习：把经验沉淀成后续可复用的规则

这个循环很像真实工程团队的工作方式。

一个靠谱的工程师不会拿到需求就立刻乱改，也不会改完就直接交差。他会先判断影响范围，再动手实现，之后检查风险和测试结果，最后把踩过的坑记录下来。AI Agent 也需要类似约束。

为什么需要插件

提示词可以告诉 AI “请先计划再执行”，但提示词本身不一定稳定。

一旦会话变长、上下文变复杂，模型可能会跳过计划、忽略规则，或者为了完成任务而过度自信。插件的价值在于把流程固化下来，让不同 Agent 环境都能遵循类似方法。

这类插件通常会把工作流拆成命令、规则、模板或子流程。用户不需要每次手写完整提示词，而是通过固定入口触发某个阶段。

比如：

先让 Agent 生成计划
再按计划逐步实现
改完后触发 review
发现问题后返回修正
把值得保留的经验写入记忆或规则

这会让 AI 编程更像“受控协作”，而不是一次性聊天。

支持哪些 Agent 环境

README 中提到，项目支持多个 AI 编程环境，包括：

Claude Code
Codex
Cursor
GitHub Copilot
Amp
Factory
Qwen Code

这点值得注意。

很多工作流工具只绑定一个客户端，换工具后规则就不能复用。Compound Engineering Plugin 更像一套跨 Agent 的工程方法，把类似的计划、执行、评审流程带到不同工具里。

如果你同时使用多个 AI 编程助手，这类统一工作流会更有价值。不同工具能力不同，但项目规范、评审习惯和任务拆解方法应该尽量一致。

计划阶段有什么用

计划阶段的价值，是防止 AI 过早动手。

复杂任务里，真正重要的问题通常是：

要改哪些文件
哪些模块可能受影响
现有模式是什么
有没有测试
风险点在哪里
是否需要先阅读文档
能不能拆成更小步骤

如果 Agent 没有先想清楚这些问题，就直接开始写代码，很容易做出看似完成、实际偏离项目结构的实现。

计划并不一定要很长。好的计划应该短、具体、可执行。它的目的不是制造文档，而是让后续实现有边界。

执行阶段要避免什么

AI 执行代码任务时，最容易出现几类问题：

顺手重构无关代码
覆盖用户已有修改
只改 happy path
忽略错误处理
不按项目已有风格写
没有运行必要验证
遇到报错后盲目尝试

工作流插件无法保证这些问题完全消失，但可以通过规则和阶段约束减少发生概率。

比如，执行阶段可以要求 Agent 按计划逐步推进；遇到超出计划范围的发现时，先说明风险；修改共享模块时，补充测试或至少运行相关验证。

这种约束对大型代码库尤其重要。AI 写代码越快，越需要流程来限制它的惯性。

评审阶段为什么重要

很多 AI 编程失败，不是因为代码完全不能运行，而是因为细节有问题：

边界条件没处理
状态更新不一致
API 合约被悄悄改了
测试覆盖不到关键路径
错误提示不清楚
性能或安全风险没有被提到

评审阶段就是把 Agent 从“作者模式”切换到“审查模式”。

作者模式容易为自己的实现找理由；审查模式则要主动找漏洞、回归风险和遗漏测试。把这两个阶段分开，会比让同一个回复里同时完成实现和自我审查更可靠。

对用户来说，评审输出也更有价值。它能帮助你快速判断这次修改是否值得合并，还是需要继续返工。

学习和记忆的意义

项目名字里的 “Compound” 暗示了一个重要想法：工程经验应该复利增长。

如果 AI 每次犯错后只是当场修好，下次又犯同样错误，效率提升就很有限。更好的方式是把有价值的经验沉淀下来：

这个项目的目录约定
某类错误的排查方法
测试命令和注意事项
不要触碰的生成文件
代码风格偏好
常见实现模式

这些经验可以变成规则、记忆、文档或模板。后续任务中，Agent 先读取这些沉淀，再开始工作。

这就是 AI 编程从“单次问答”走向“长期协作”的关键。

适合什么场景

Compound Engineering Plugin 适合这些场景：

长期使用 AI Agent 写代码
一个项目会被多次、多轮修改
希望 AI 先计划再实现
希望改完后自动进入 review 思维
团队想统一 AI 编程流程
同时使用 Claude Code、Codex、Cursor 等多个工具
希望把项目经验沉淀成可复用规则

如果只是偶尔让 AI 写一个小脚本，完整流程可能显得偏重。

但如果你正在把 AI 编程助手当成日常开发伙伴，计划、执行、评审、学习这套循环就会明显有用。

和普通提示词模板有什么区别

普通提示词模板通常解决的是“怎么说清楚任务”。

比如：

请一步步思考
请先阅读文件
请保持代码风格一致
请运行测试
请总结修改内容

这些提示当然有用，但它们还是依赖用户每次正确使用。

Compound Engineering Plugin 更偏工作流层。它把这些要求组织成可重复的过程，并适配不同 Agent 工具。这样你不是每次从零写提示词，而是在一套流程里推进任务。

简单说，提示词模板像提醒，工作流插件像制度。

使用时要注意

第一，不要把流程变成负担。

小任务不一定需要完整计划和长篇评审。好的工作流应该能根据任务复杂度调整，简单问题快速处理，复杂问题再走完整循环。

第二，评审不能替代测试。

Agent review 能发现很多问题，但它仍然可能漏掉真实运行时错误。最终判断还要看测试、类型检查、构建结果和人工审查。

第三，规则要持续清理。

沉淀经验很重要，但规则越积越多也会变成噪声。过时规则、重复规则、只适合某次任务的临时经验，都应该定期整理。

第四，跨工具一致不等于完全相同。

Claude Code、Codex、Cursor、Copilot 等工具能力和交互方式不同。统一的是工作方法，不一定是每个命令、每个配置细节都完全一样。

适合怎样的团队

如果一个团队已经允许 AI Agent 修改真实代码，那么只讨论“哪个模型更强”是不够的。

更应该关心：

AI 修改前是否理解任务
AI 修改中是否遵守项目边界
AI 修改后是否主动审查风险
AI 是否能从历史错误中学习
团队是否有统一的 Agent 使用规范

Compound Engineering Plugin 这类项目的意义就在这里。它把 AI 编程从个人技巧，往团队可复用流程推进了一步。

参考

EveryInc/compound-engineering-plugin

最后一句

Compound Engineering Plugin 值得关注的地方，不是多一个 AI 编程命令，而是把 AI 编程组织成可循环改进的工程流程。

当 AI Agent 开始参与真实项目，计划、执行、评审和经验沉淀会比单次生成代码更重要。

Claude Code Hooks Mastery：13 个 Hooks 生命周期与自动化控制入门

Fri, 01 May 2026 03:11:27 +0800

claude-code-hooks-mastery 是一个围绕 Claude Code Hooks 的学习项目。

它不是只给几个零散脚本，而是把 Claude Code 的 hooks 生命周期、配置方式、脚本写法和常见自动化场景放在一起讲清楚。对于想让 Claude Code 更可控、更像工程化助手的人来说，这类资料很值得看。

Claude Code 默认已经能读代码、改文件、跑命令。但如果你想让它在特定时机自动检查权限、拦截危险操作、注入项目规范、运行测试、提醒团队规则，单靠聊天指令就不够稳定。Hooks 的价值就在这里：把“每次都要提醒 AI 的规则”变成可执行的流程。

Hooks 解决什么问题

使用 Claude Code 一段时间后，常见痛点大概有这些：

每次新会话都要重复告诉它项目规则
担心它执行不该执行的命令
希望文件修改前后自动做检查
想在提交前自动跑格式化、测试或安全扫描
想把团队规范写成固定流程，而不是靠口头提醒
想在工具调用前后拿到上下文，做记录或拦截
希望复杂任务可以触发子代理或专门脚本处理

Hooks 就是为这些“固定时机的自动动作”准备的。

你可以把它理解成 Claude Code 工作流里的事件钩子：当会话开始、用户提交提示词、模型准备调用工具、工具调用完成、代理即将结束等节点发生时，Claude Code 可以执行你配置的脚本。

13 个 Hooks 生命周期

项目 README 的重点之一，是系统整理了 Claude Code 的 13 个 hook 事件。

这些事件覆盖了从会话开始到工具调用、从用户输入到代理结束的多个节点。按用途可以粗略分成几类：

会话启动相关：用于初始化环境、注入项目上下文
用户输入相关：用于检查提示词、补充规则、做审计
工具调用前相关：用于权限判断、命令拦截、安全检查
工具调用后相关：用于记录结果、触发格式化、运行验证
任务结束相关：用于总结、清理、通知或保存状态

这种生命周期设计让你不必把所有规则都写进一个超长提示词里。

比如，权限控制应该发生在工具调用前；格式化检查更适合发生在文件修改后；项目规范注入适合发生在会话开始或用户输入后。把规则放到正确的 hook 节点，通常比把所有内容塞进 system prompt 更可靠。

配置文件在哪里

Claude Code 的 hooks 通常通过设置文件配置。

常见位置包括：

用户级配置：~/.claude/settings.json
项目级配置：.claude/settings.json

用户级配置适合放个人偏好，比如通用安全规则、命令拦截、日志路径。

项目级配置适合放仓库相关规则，比如这个项目必须跑什么测试、哪些目录不能改、生成文件怎么处理、提交前要做哪些检查。

如果你在团队里使用 Claude Code，更推荐把项目级配置放进仓库。这样每个人打开项目时，拿到的是同一套 AI 协作约束，而不是各自凭记忆提醒。

单文件脚本为什么重要

项目里强调了 UV 单文件脚本的写法。

这类脚本的好处是部署简单。一个 Python 文件就可以声明依赖并运行，不必为了一个 hook 单独维护复杂环境。对 hooks 来说，这很合适，因为很多 hook 只是做一件小事：

检查命令是否允许执行
判断文件路径是否安全
读取项目规范并返回给 Claude
扫描输出中是否包含敏感信息
在修改后运行格式化或测试
把事件写入日志

Hook 脚本越小，越容易维护，也越不容易变成新的复杂系统。

可以做哪些自动化

claude-code-hooks-mastery 展示的方向比较多，实际工作中最常见的是下面几类。

1. 权限和安全控制

这是 hooks 最直接的用途。

比如在 Claude Code 准备执行命令之前，先检查命令内容。如果命令包含删除、重置、清空、覆盖等高风险动作，就阻止执行或要求人工确认。

类似规则还可以用于文件路径：

不允许修改生产配置
不允许写入密钥文件
不允许删除迁移脚本
不允许触碰指定目录
不允许执行未批准的网络命令

这类保护放在工具调用前，比写一句“不要做危险操作”更可靠。

2. 上下文注入

很多项目都有固定背景：

技术栈
编码规范
测试命令
分支策略
目录结构
禁止事项
生成文件处理规则

这些内容每次手动告诉 Claude Code 很麻烦，也容易漏。Hooks 可以在会话开始或用户提交提示词后，把必要上下文自动注入进去。

这相当于给 Claude Code 配一个项目级的工作说明书。它不会替代 README 或开发文档，但能让 AI 在执行任务前更快进入正确状态。

3. 修改后的验证

当 Claude Code 修改文件后，可以通过 hook 自动触发检查。

常见动作包括：

运行格式化
运行 lint
运行单元测试
检查类型错误
扫描生成文件
校验 Markdown 或 JSON 格式

这对减少低级错误很有帮助。尤其是 AI 改动多个文件时，修改后自动跑一轮轻量验证，可以更早发现问题。

不过也要注意，hook 里不适合默认塞太重的任务。每次文件改动都跑完整测试套件，可能会让体验变得很慢。更实用的做法是按文件类型、目录和任务风险选择检查范围。

4. 团队规则验证

如果团队已经有明确约定，可以把一部分约定放进 hooks。

比如：

提交信息格式
代码风格规则
禁止直接修改某些生成文件
文档必须同步更新
API 变更必须改测试
某些目录只能用指定工具生成

这会让 Claude Code 更像团队流程的一部分，而不是一个不受约束的外部助手。

当然，hooks 不应该替代 CI。它更适合做本地快速提醒和前置拦截，真正的最终验证仍然应该交给 CI、review 和测试系统。

5. 子代理和专门任务

README 里还提到子代理相关内容。

这类用法适合把复杂任务拆给更专门的流程处理。比如主会话负责理解需求，hook 或配置触发专门的检查、审计、总结、文档整理任务。

对个人用户来说，最先值得做的不是复杂代理编排，而是把重复、明确、低风险的动作交给 hooks。等规则稳定后，再考虑更复杂的自动化。

Statusline 和输出样式

项目还覆盖了状态栏和输出样式。

这部分看起来像体验细节，但对长期使用 Claude Code 很有意义。状态栏可以展示当前上下文、任务状态、环境信息或提示信息；输出样式则可以让 Claude Code 的回答更符合你的工作习惯。

如果你每天都在同一个终端里和 AI 协作，这些细节会影响效率。好的状态提示能减少误操作，也能让你更快判断当前会话是否处在正确项目、正确分支、正确环境里。

不要把 hooks 写得过重

Hooks 很强，但不适合什么都往里面塞。

比较好的规则是：

高频动作要快
安全拦截要明确
输出要短
失败原因要可读
脚本尽量单一职责
重型检查交给显式命令或 CI

如果一个 hook 每次都执行十几秒，用户很快就会想关掉它。如果一个 hook 拦截规则含糊不清，Claude Code 和用户都会难以理解下一步该怎么做。

Hooks 最适合处理那些边界清楚的事情：允许或拒绝、补充上下文、记录日志、运行轻量检查、提示下一步。

适合怎样的使用者

如果你只是偶尔让 Claude Code 改一小段代码，可能暂时不需要深入 hooks。

但如果你符合下面几种情况，就很适合研究这个项目：

高频使用 Claude Code
经常让 AI 修改真实项目代码
担心 AI 执行危险命令
想把团队规范自动注入 AI 工作流
希望修改后自动跑检查
想把重复提醒变成配置
正在搭建更稳定的 AI 编程流程

尤其是多人协作项目，hooks 的意义会更明显。它可以把一部分团队经验沉淀成脚本，而不是靠每个人临时提醒 AI。

使用时要注意

第一，先从安全类 hook 开始。

相比复杂自动化，命令拦截、路径保护、敏感文件检查更容易落地，也更能立刻降低风险。

第二，项目级规则要谨慎提交。

.claude/settings.json 会影响所有使用这个仓库的人。把规则提交前，最好确认它不会过度限制正常开发，也不会依赖只有你本机才存在的路径。

第三，hook 输出要简洁。

Claude Code 会消费这些输出。输出太长，会污染上下文；输出太模糊，又起不到指导作用。最好只返回必要判断和下一步建议。

第四，保持可调试。

Hooks 一旦变多，问题可能出在配置、脚本、权限、路径、依赖或 Claude Code 本身。给脚本留下清晰日志，会让后续排查轻松很多。

参考

disler/claude-code-hooks-mastery

最后一句

Claude Code Hooks 的价值，是把“希望 AI 每次都记住的规矩”变成真正会执行的流程。

如果你已经开始把 Claude Code 用在真实项目里，hooks 会是从“会聊天的编程助手”走向“可约束的工程协作者”的关键一步。

Claude-Mem：给 Claude Code 加上跨会话长期记忆

Fri, 01 May 2026 03:01:02 +0800

Claude-Mem 是一个给 Claude Code 使用的持久化记忆系统。

它想解决的问题很具体：AI 编程助手每次开新会话时，往往会忘记之前讨论过的架构决策、踩过的坑、项目偏好和实现背景。
如果一个项目做得久，每次都重新解释上下文，非常浪费时间。

Claude-Mem 的思路是：把 Claude Code 的会话内容压缩成记忆，存进本地数据库和向量库，之后再通过搜索工具找回来。

它解决什么问题

Claude Code 很适合处理代码任务，但会话上下文毕竟有限。

常见痛点包括：

新会话不知道旧会话做过什么
项目里的设计决策需要反复解释
曾经排查过的问题容易重复踩
长期任务缺少连续记忆
多次对话之间很难沉淀项目知识

Claude-Mem 就是围绕这些问题设计的。

它不是简单保存聊天记录，而是把会话压缩成更容易检索的记忆片段。这样后续需要时，可以通过语义搜索把相关上下文找回来。

工作方式

从 README 的设计看，Claude-Mem 主要由几部分组成。

第一部分是 hooks。

它会接入 Claude Code 的会话流程，在合适的时机捕获会话数据。

第二部分是后台 worker。

worker 负责把原始会话内容处理成更短、更可检索的记忆。

第三部分是本地存储。

项目使用 SQLite 保存结构化元数据，用 Chroma 保存向量索引。这样既能保留会话记录的基本信息，也能支持语义检索。

第四部分是 mem-search。

这是给 Claude Code 使用的查询入口。需要找回旧上下文时，可以通过它搜索相关记忆。

整体流程可以理解为：

Claude Code 会话产生内容
hooks 捕获会话数据
worker 异步压缩和整理
记忆写入 SQLite 与 Chroma
后续通过 mem-search 检索

适合什么场景

Claude-Mem 适合长期项目，而不是一次性小任务。

比如：

一个仓库持续开发很多天
代码结构复杂，背景说明很多
需要记住项目约定、命名习惯和架构选择
经常让 Claude Code 修 Bug、写功能、整理文档
希望 AI 能记住“之前为什么这么改”

如果你只是临时让 Claude Code 改一行代码，长期记忆意义不大。
但如果你把 Claude Code 当作长期协作者，它就会变得有用。

安装和启动

README 中给出的安装方式很直接：

1
2

npm install -g claude-mem
claude-mem install

启动时可以使用：

`1`	`claude-mem start`

查看状态：

`1`	`claude-mem status`

如果需要停止：

`1`	`claude-mem stop`

这些命令背后的目标，是把记忆系统作为一个长期运行的本地服务接到 Claude Code 工作流里。

`mem-search` 怎么用

mem-search 是找回记忆的关键入口。

它的用途不是替代普通搜索，而是让 Claude Code 能按语义查询过去会话中的内容。

比如你可以让 Claude Code 查询：

某个模块之前为什么这样设计
某个 Bug 当时怎么排查
项目里约定的命名规则
之前讨论过的技术取舍
某次重构的背景原因

这种查询和简单关键词搜索不同。
如果记忆压缩和向量索引做得好，即使你不记得原话，也能找回相近语义的内容。

和普通项目文档有什么区别

项目文档适合记录稳定结论。

比如：

架构说明
部署流程
API 约定
数据库结构
开发规范

Claude-Mem 更适合记录会话过程中产生的上下文。

比如：

为什么某个方案被放弃
某个临时问题怎么绕过
某个实现背后的讨论过程
还没来得及写进文档的项目偏好
多次对话里积累出的任务背景

两者不是互相替代。
比较好的方式是：稳定知识写进项目文档，过程性上下文交给记忆系统辅助检索。

使用时要注意什么

第一，长期记忆不是越多越好。

如果所有对话都无差别保存，后续检索可能会变得嘈杂。真正有价值的是项目决策、实现背景、问题排查和长期偏好。

第二，记忆不能替代代码和文档。

AI 搜到的旧上下文只能作为参考。最终判断仍然要看当前代码、测试结果和最新需求。

第三，隐私和本地数据要注意。

既然它会保存会话内容，就要清楚哪些项目适合接入，哪些敏感信息不应该进入对话。

第四，记忆系统需要维护。

随着项目推进，旧记忆可能过时。过时的上下文如果被误用，反而会误导后续任务。

为什么这类工具值得关注

AI 编程工具正在从“单次问答”走向“长期协作”。

单次问答里，模型只要回答当前问题就够了。
长期协作里，它需要知道项目历史、之前的决策、团队偏好和已经踩过的坑。

Claude-Mem 这类工具的意义就在这里：它把“记住上下文”从临时聊天能力，变成一个可以安装、运行、检索的本地系统。

对真实工程项目来说，这比单纯让模型上下文窗口变长更实用。
因为很多信息不是一次性塞进上下文就好，而是需要在合适的时候被找回来。

适合谁尝试

如果你符合下面几种情况，可以考虑试试：

高频使用 Claude Code
经常跨天处理同一个项目
项目上下文比较复杂
经常需要向 AI 重复解释背景
想把会话里的经验沉淀下来

如果你只是偶尔使用 Claude Code，或者项目很小，暂时不一定需要这类系统。

参考

thedotmack/claude-mem

最后一句

Claude-Mem 的重点不是“保存聊天记录”，而是让 Claude Code 能在后续任务里找回有用上下文。

当 AI 编程从一次性任务变成长期项目协作，记忆系统会越来越重要。
它不能替代文档和测试，但可以减少重复解释，让 AI 更像一个了解项目历史的助手。

Ralph 和多智能体协同：怎么让 AI 长时间稳定工作

Mon, 27 Apr 2026 08:19:02 +0800

如果你最近在折腾 coding agent，很快就会遇到一个现实问题：AI 当然能干活，但怎么让它连续干几个小时，还不在中途跑偏、忘要求、返工一堆？

围绕 Ralph 和多智能体协同的这类讨论，真正值得看的也正是这个问题。它不是单纯比较某个模型有多强，而是把重点放在一层更实际的东西上：怎么设计工作流，才能让 AI 在长任务里保持稳定输出。

把这个问题拆开看，常见的路线主要有两条：

Ralph 方案：不断启动新会话，通过文件系统衔接上下文
多智能体方案：主 Agent 做协调，子 Agent 分工执行

如果把它压成一句更好理解的话，这期内容讲的其实不是“哪个模型更厉害”，而是“怎么把 AI 组织起来，让它更像一个能持续交付的小团队”。

01 为什么长时任务容易失控

短任务里，很多问题不明显。你给一句指令，模型读几份文件，改几行代码，事情也就结束了。

但任务一旦拉长，问题会集中冒出来：

会话越来越长，上下文开始膨胀
早先的要求被新信息挤掉
一个 Agent 既要想方案，又要写代码，还要自己测，容易顾不过来
没有明确验收环节时，看起来“做完了”，其实只是“说自己做完了”

所以长时间运行 AI，真正考验的往往不是模型单次输出能力，而是 任务拆分、状态衔接、角色分工和反馈回路。

02 Ralph 方案：把长任务拆成很多短回合

Ralph 的思路很适合先解决“上下文越跑越脏”这个问题。

它的核心做法是：

用循环不断启动新的 agent 会话
每轮只处理一个足够小的任务
把跨轮状态放到文件里，而不是全压在同一个对话上下文里

这样做的好处很直接：每次都是 fresh context，单轮会更聚焦，也更不容易被历史消息拖慢。

如果你已经看过 Ralph 相关项目，会发现这套方法背后的逻辑很一致：

当前任务写在结构化文件里
中间经验写到进度文件里
代码变化留在 git 历史里

换句话说，Ralph 不是试图让一个 Agent “永远记住所有事”，而是主动把记忆外置，让会话本身保持轻一点。

这类方案特别适合下面几种情况：

任务已经能拆成一组小 story
每个 story 都能在单个上下文窗口里完成
项目里已经有测试、typecheck 或其他检查机制

它解决的是“如何让 AI 一轮一轮稳定推进”。

03 多智能体方案：把一个人做不完的事分出去

另一条路线是多智能体协同。

从这类工作流设计思路来看，更值得推荐的通常是这种方式：主 Agent 不直接埋头干活，而是负责协调；子 Agent 各自处理开发、测试、检查、验收等不同任务。

这和 Ralph 的区别在于：

Ralph 更像串行迭代
多智能体更像并行分工

如果任务里天然有不同角色，多智能体会更顺手。比如：

一个 Agent 负责拆任务和写执行计划
一个 Agent 负责具体实现
一个 Agent 负责测试和验证
一个 Agent 负责回看结果是不是符合最初需求

这样做的价值不是“多开几个窗口显得很高级”，而是让不同工作职责分离开。原来塞在一个 Agent 身上的几件事，现在可以拆成几个更明确的环节。

一旦角色边界清楚，很多问题都会变轻：

写的人不必同时当审的人
跑测试的人不必重新推导整套需求
主 Agent 不会被实现细节淹没

它解决的是“如何让 AI 像一个小团队那样配合”。

04 真正关键的，不是多开，而是怎么拆

无论是 Ralph 还是多智能体，最容易被忽略的一点都是：流程设计比多开几个 Agent 更重要。

如果任务拆分不对，就算开再多 Agent，也只是把混乱并行化。

比较稳的拆法通常有几个特点：

一个任务只对应一个明确目标
一个角色只负责一类输出
每轮都有清楚的完成标准
上一轮的结果能被下一轮直接消费

比如比起给 AI 一个“把整个功能做完”的大指令，更稳的方式往往是：

先拆出需求和边界
再拆实现
再拆测试
最后单独做验收

这类拆法的好处是，问题一旦出现，更容易知道是出在理解、实现、测试，还是交付标准上。

05 为什么验收环节特别重要

很多 AI 工作流失败，不是因为前面完全没做事，而是因为最后缺了一个真正独立的确认动作。

在长任务里，“已经生成结果”和“结果真的可用”之间，经常隔着一整层差距。

这里有个很值得重视的方向，就是把开发和验收拆开看。哪怕不做到特别复杂，至少也应该把这些问题单独问一遍：

它真的完成了最初那条任务吗
有没有只改表面、没解决根因
测试是不是只验证了最顺利的路径
有没有把上游要求悄悄改掉

只要这层检查缺位，AI 很容易在长流程里不断“自我宣布成功”。

06 两条路线怎么选

如果只是想快速判断，可以先这么理解：

你最痛的是上下文膨胀和长会话失焦，先看 Ralph
你最痛的是一个 Agent 身兼多职、任务之间互相打架，先看多智能体

再具体一点：

Ralph 更适合流程清楚、任务细碎、可以按回合推进的工作
多智能体更适合角色明显、需要并行和交叉验证的工作

很多时候，这两条路也不是非此即彼。比较成熟的做法，反而可能是把它们组合起来：

外层用 Ralph 这种迭代循环推进大任务
内层在单轮里再用多智能体处理研究、实现、测试和验收

这样既能控制长上下文，又能提高单轮内部的协作效率。

07 一句话总结

这类方法最值得看的地方，不是单独推荐了 Ralph 或多智能体，而是把一个很现实的问题讲清楚了：让 AI 长时间稳定工作，关键从来不只是模型本身，而是你有没有把上下文、任务、角色和验收设计好。

如果你已经开始让 Claude Code、Codex 或其他 coding agent 处理更长的真实任务，这类工作流思路会比“再换一个更强模型”更值得优先补课。

Ralph 是什么：把 Claude Code 和 Amp 变成可循环执行的自主开发流程

Mon, 27 Apr 2026 08:08:55 +0800

如果你最近在关注 coding agent 的长流程执行，snarktank/ralph 是个很值得看一眼的小项目。它不是再做一个新的模型壳子，也不是再包一层聊天界面，而是把 Claude Code 或 Amp 组织成一个可以反复运行的 autonomous loop，让 AI 按 PRD 里的 story 一项一项往前做，直到全部完成。

它的核心思路其实很直接：不要让同一个 agent 在一个越来越长、越来越脏的上下文里硬撑，而是每轮都重新启动一个全新的 AI coding session。 这样做的好处是，上下文不会一路膨胀，任务边界也更清楚。

01 Ralph 是什么

Ralph 的官方定位很明确：它是一个 autonomous AI agent loop，会反复调用 AI coding tool，直到 PRD 里的项目都做完。

当前仓库支持两种工具：

Amp CLI
Claude Code

每一轮迭代都会启动一个 fresh instance。也就是说，不依赖“同一个会话一直聊下去”，而是依赖这些外部状态来保存记忆：

git 历史
progress.txt
prd.json

这点非常关键。很多人让 agent 跑长任务时，最大的痛点不是模型不会写，而是会话越跑越重，最后开始漏上下文、忘要求、反复返工。Ralph 的设计，基本就是冲着这个问题去的。

02 它怎么工作

Ralph 的工作流分成三步：

1. 先写 PRD

README 里建议先用配套的 prd skill 生成需求文档，把功能拆成比较细的 story。

2. 再把 PRD 转成 `prd.json`

然后用 ralph skill，把 Markdown 版 PRD 转成结构化的 prd.json。这个文件里会保存 user stories，以及每一项是不是已经通过。

3. 运行循环脚本

真正执行的是 ralph.sh。命令大致是：

1
2

./scripts/ralph/ralph.sh [max_iterations]
./scripts/ralph/ralph.sh --tool claude [max_iterations]

默认是 10 轮。每一轮大致会做这些事：

从 branchName 创建分支
选择优先级最高、passes: false 的 story
只实现这一项
跑质量检查，比如 typecheck 和 tests
检查通过后提交代码
更新 prd.json
把经验追加到 progress.txt
继续下一轮

也就是说，Ralph 并不追求“一口气把整件事做完”，而是把任务压缩成很多个能在单个上下文窗口里完成的小闭环。

03 Ralph 最有意思的地方

1. 每轮都是 fresh context

这是 Ralph 最核心的设计点。README 里强调，每次迭代都是一个新的 AI 实例，跨轮记忆只靠 git、progress.txt 和 prd.json。

这和很多人平时直接在一个长对话里让 Claude Code 或其他工具连续工作很不一样。后者在任务变大后，很容易被历史消息拖慢，还会逐渐失去焦点。Ralph 则是主动接受“单轮记不住全部”，然后把记忆放到外部文件里。

2. 强制把任务拆小

仓库文档特别强调，单个 PRD item 必须小到能在一个 context window 里完成。像“加一个筛选器”“改一个 server action”“补一列数据库字段”这种粒度比较合适；而“重构整个 API”“做完整 dashboard”这种就太大了。

这个约束其实很现实。很多 autonomous agent 跑崩，不是 loop 本身有问题，而是任务切分太粗，让模型一轮里就背了过量目标。

3. 不是只有代码，连经验也要沉淀

除了 progress.txt，README 还特别强调要更新 AGENTS.md。原因也很实际：未来迭代和未来开发者都会读这些说明，所以每轮发现的模式、坑点、约定，最好都落到项目文档里。

换句话说，Ralph 不只是让 agent 连续写代码，也想让它连续积累对代码库的工作记忆。

04 它适合什么场景

如果你的任务具备这些特征，Ralph 会比较对路：

已经能拆成一组明确的 user stories
代码库里有比较可靠的反馈回路，比如测试、typecheck、CI
你希望 agent 持续推进，但不想把所有事压在单个长对话里
你接受它按迭代方式一点点完成，而不是一次性全做完

反过来说，如果你的需求还很模糊，或者任务本身高度依赖来回讨论、频繁改方向，那 Ralph 可能还不是第一选择。它更适合“需求已经整理好，现在需要稳定推进执行”的阶段。

05 它和普通 Claude Code 用法有什么不同

如果平时直接用 Claude Code，常见模式是你开一个会话，让它持续读代码、改代码、跑命令。这个方式在中小任务上很好用，但在大任务上容易碰到两个问题：

上下文越来越长
中间决策不容易结构化沉淀

Ralph 的做法更像把 Claude Code 或 Amp 变成一个“批处理执行器”：

任务来源不是临时聊天，而是 prd.json
每轮只认一个 story
完成状态写回文件
经验写进 progress.txt
代码提交进 git

所以它更像是“给 coding agent 加了一层迭代控制器”，而不是换了一个新的 AI assistant。

06 一个值得注意的前提

Ralph 能不能跑顺，关键不在 loop 本身，而在反馈回路够不够好。README 里写得很直白：如果没有 typecheck、tests、CI 这些机制，错误会在后续迭代里不断累积。

对于前端任务，仓库甚至明确建议把“用浏览器验证”写进 acceptance criteria。因为如果没有实际验证，agent 很容易把“看起来写完了”和“真的可用”混在一起。

这点很重要。Ralph 不是 magical automation，它更像把你现有的工程纪律放大。如果你的项目本来就有清晰任务拆分和可靠检查，它会更有价值；如果这些基础还没有，loop 只会把混乱重复很多次。

07 一句话总结

Ralph 最值得看的地方，不是它写了多少新基础设施，而是它把一个朴素但很有用的思路落成了现成流程：让 Claude Code 或 Amp 每轮只做一个足够小的 story，用 fresh context 保持专注，再靠 git、prd.json 和 progress.txt 维持跨轮连续性。

如果你已经开始把 coding agent 用到真实项目里，并且正在被“长任务怎么稳定推进”这个问题困住，Ralph 这套方法很值得参考。

参考链接

GitHub 仓库：https://github.com/snarktank/ralph
交互式流程图：https://snarktank.github.io

Claude Code 环境配置四件套：CLAUDE.md、Rules、Memory、Hooks 一次讲清

Thu, 23 Apr 2026 10:35:00 +0800

如果你用 Claude Code 一段时间，就会很快发现一件事：模型本身当然重要，但给它什么环境、什么边界、什么规则，同样重要。

很多人刚开始会把注意力放在“我这次 prompt 怎么写”，但真正把 Claude Code 用成熟之后，你会更关心另一件事：

它知不知道你是谁
它知不知道你怎么工作
它知不知道哪些规则不能违反
它知不知道什么事情必须先确认
它能不能长期记住这些边界

Claude Code 之所以能变成一个成熟工具，不只是因为模型强，而是因为它有一整套机制，帮你把这些工作方式沉淀下来。核心上可以拆成四层：

CLAUDE.md
Rules
Memory
Hooks

这篇文章就把这四个部分一次讲清楚。

为什么环境配置比单次提示词更重要

你可以把 Claude Code 想成你请来的一个助理。

第一天上岗时，你不会只跟他说一句“帮我做事”，而是会给他一份说明书，告诉他：

你的身份是什么
你的沟通语气偏好是什么
哪些操作必须先确认
哪些错误之前犯过，未来不能再犯
这个项目最重要的文档放在哪里

这就是为什么，长期来看，环境配置往往比单次 prompt 更重要。

因为 prompt 解决的是“这一次要做什么”，而环境配置解决的是“以后每次都要怎么做”。

第一层：`CLAUDE.md`

先从最基础的开始，CLAUDE.md 本质上就是一个文字文件。

你可以在里面写给 Claude 的说明，例如：

你是谁
你在做什么
你的沟通偏好
需要遵守的规则
当前项目的特殊背景
重要文档或目录的位置

每次 Claude Code 启动时，这份文档都会被自动送进上下文里，所以模型一定会读到。

我通常把它叫做“默契档”，因为它本质上就是你和模型之间长期协作的默契。

`CLAUDE.md` 适合写什么

最适合写进 CLAUDE.md 的，大致有这几类：

身份与工作背景
沟通语气和输出偏好
全局性的行为规则
经常会用到的重要项目背景
常见错误与避免方式

比如：

你所在的时区
你是否接受模型直接发送邮件或消息
哪些操作属于不可逆行为
处理文档和文件时的习惯
安全规范和敏感信息边界

一个很重要的原则：尽量精简

CLAUDE.md 有一个很重要的原则，就是一定要尽量精简。

原因很简单：它每次都会被强制注入上下文。

如果你写得太长，就会占掉大量上下文空间，导致真正重要的信息被稀释。模型不是不读，而是注意力会分散，最后更容易漏掉你最在意的规则。

官方建议通常是最好不要超过 400 行。

我自己的习惯会更保守一些，尽量控制在 200 行以内。

`CLAUDE.md` 的常见作用范围

CLAUDE.md 实际上有不同的放置层级，对应不同的作用范围。最常用的是两个：

1. User Level

这是全局层级。

它放在你电脑环境里，对你本机操作的所有项目都有效。

这个位置适合放：

你的身份信息
通用的沟通偏好
你跨项目都适用的做事习惯
全局性的安全规则

比如，如果你的时区不是默认常见值，而是曼谷时间，那这类信息就很适合放在 user level，这样模型以后帮你安排时间时就不容易出错。

2. Project Level

这是项目层级。

它放在具体项目目录下面，只对那个项目有效。

这个位置适合放：

项目专属背景
只在这个项目里成立的规则
项目的目录结构说明
这个项目的重要文档入口

举个例子，如果一个项目处理财务，另一个项目处理人事，那两边的背景和约束显然不同，就不应该混在同一个全局说明里。

怎么判断该放哪一层

判断方式其实很简单：

你写进去的东西，如果换到另一个项目里还成立，那就放 user level。

如果一换项目就不成立，那就放 project level。

怎么开始写第一版

最常见的起手方式有两种：

1. 用 `/init`

你可以直接在终端里运行斜线命令 /init，让 Claude 扫描当前项目，自动帮你生成一份基础版 CLAUDE.md。

2. 让 Claude 帮你整理

你也可以直接让 Claude 去搜索别人是怎么写 CLAUDE.md 的，再结合你的情况问你问题，最后帮你整理成适合你自己的版本。

很多时候，这比自己从零开始写更轻松。

一个很实用的习惯

在你和 Claude 长期协作的过程中，只要你发现某件事情属于“未来一定要记住、不要再犯”的内容，就可以直接让它写进 CLAUDE.md。

不过写之前还是要判断一下：

这是全局规则
还是当前项目规则

别把所有东西都塞进一个文件里。

第二层：`Rules`

接下来是 Rules。

它和 CLAUDE.md 最大的差别，不是文件形式，而是加载方式。

CLAUDE.md 是无论你做什么，模型都会读到。

而 Rules 的优势在于：可以条件加载。

也就是说，只有在某些路径、某些文件、某些工具或某些场景下，这条规则才会被读到。

为什么条件加载很重要

因为上下文空间永远是稀缺资源。

如果所有规则都无差别地塞进上下文里，就会发生两件事：

模型负担变重
真正关键的规则反而被淹没

按需加载的价值就在这里：让模型在刚好的时候读到刚好的信息。

什么时候该把规则从 `CLAUDE.md` 挪到 `Rules`

通常有两种情况：

1. `CLAUDE.md` 太长了

如果你的 CLAUDE.md 开始超过 200 行，规则越来越多，重要内容被稀释，那就该考虑把一部分规则拆出去。

2. 某些规则只和特定路径相关

如果你已经明显知道某些规则只在某类文件里才有意义，比如：

只对 Python 脚本有效
只对某个 hooks 目录有效
只对某个子项目有效

那这些规则就更适合移到 Rules。

`Rules` 最适合的场景

最典型的就是“特定情境、特定路径、特定文件类型”。

比如：

只在处理 hooks 文件时触发的规范
只在某类脚本中要遵守的编码规则
只在某个目录下适用的工作方式

这些内容如果继续塞在 CLAUDE.md 里，其实是不划算的。

第三层：`Memory`

第三个层面是 Memory。

它和 CLAUDE.md、Rules 一样，也会进入模型上下文，但它最核心的区别是：

CLAUDE.md 是你主动设定的。

Memory 则更像是 Claude 在协作过程中，写给自己的笔记。

`Memory` 记的是什么

当 Claude 判断某件事值得记住，或者需要短期保留，它就会把这些内容写进 Memory。

常见内容包括：

你纠正过它的某个做法
你最近新增的偏好
当前项目的临时状态
你今天没做完、明天还要继续的事
你最近在跟哪些人合作
某些最近才提到的个人信息或上下文

换句话说，Memory 更像动态知识，而不是长期制度。

`Memory` 和前两者的区别

一个简单的区分方式是：

CLAUDE.md / Rules：偏长期、偏制度、偏明确规则
Memory：偏临时、偏动态、偏工作过程中的新理解

如果某件事只是最近几天有效，或者项目状态在持续变化，那它通常更适合放进 Memory，而不是写成长期规则。

`Memory` 也可以手动写

虽然 Memory 有自动整理能力，但你也可以主动告诉 Claude：

请记下来我明天要做什么
请记下来我要追踪谁的状态
请记下来这个月某个项目的关键节点

它也可以帮你写进 Memory。

你还可以通过斜线命令 /memory 查看当前有哪些记忆，并手动编辑或删除。

不过很多时候，我自己不会频繁手动维护，因为 Claude 本身也会定期整理这些记忆，把已经过时的部分清掉。

第四层：`Hooks`

最后也是最重要、最进阶的一层，就是 Hooks。

前面讲到的 CLAUDE.md、Rules、Memory，本质上都还是自然语言说明。

你写了规则，模型通常会遵守，但它仍然是在“理解之后执行”。

只要还是自然语言，就会存在几个问题：

模型偶尔会漏掉
规则太多时，注意力会分散
某些情境下它会自行判断这条规则不重要

这不是你写得不够认真，而是自然语言规则本来就很难做到 100% 强制。

`Hooks` 的本质是什么

Hooks 不再是自然语言说明，而是一段脚本。

它是事件触发的、程序级别的强制逻辑。

只要某个事件发生，这段逻辑就一定会执行，不会被模型“自己判断后略过”。

这就是 Hooks 最关键的价值：

把“建议遵守”变成“必须执行”。

什么时候该上 `Hooks`

当你发现某条规则已经写进了 CLAUDE.md 或 Rules，但 Claude 偶尔还是不执行，而且这件事一旦漏掉，风险就比较大，那就应该考虑改成 Hooks。

简单说：

低风险的，写规则
高风险的，写 Hooks

最典型的 `Hooks` 场景

最典型的，就是那些你绝对不希望出错的动作，比如：

发邮件前必须确认
发 Slack、Outlook、Gmail 消息前必须确认
删除危险文件前必须拦截
检测到要外发密码或 API Key 时必须阻止

如果这些要求只是写成一句自然语言规则，模型有可能哪天忙中出错，真的就发出去了。

但如果写成 Hooks，只要事件发生，就会被强制拦截。

这才是程序层面的硬防线。

`Hooks` 常见的触发时机

Hooks 可以设置在很多不同阶段，例如：

对话刚开始时注入提醒
某个工具执行前进行检查
某个工具执行后做结果校验

你不一定需要自己知道专业术语。

很多时候，只要你能清楚描述需求，让 Claude 帮你判断“这条规则适不适合改成 hook”，它就能帮你一起设计。

你也可以通过斜线命令 /hook 去查看系统当前已经设置了哪些 hooks。

一套更实用的上手顺序

如果你想把这四层串起来，我自己更推荐下面这条路径：

第一步：先用 `/init` 生成基础版 `CLAUDE.md`

不要一开始就手写一份特别完整的规则文档。

先让 Claude 帮你扫描项目，生成一个起点版本，再慢慢迭代。

第二步：边用边补

在协作过程中，只要你发现：

这件事以后一定要记得
这个错误以后不能再犯
这个偏好以后每次都适用

就让 Claude 帮你写进 CLAUDE.md。

第三步：当 `CLAUDE.md` 变长时，拆到 `Rules`

一旦你发现 CLAUDE.md 越来越长，模型开始不一定遵守每一条规则，就该考虑拆分：

哪些是全局规则
哪些只和某些路径相关

把后者移到 Rules，改成条件加载。

第四步：再把高风险规则升级成 `Hooks`

如果某些规则即使写了，模型还是偶尔会漏，而且漏掉代价很高，那就不要再停留在自然语言层面，直接升级成 Hooks。

也就是把“提醒”变成“强制”。

第五步：把临时状态交给 `Memory`

对于那些会过期、会变化、不是长期制度的内容，不要一股脑写进 CLAUDE.md。

更合适的做法是交给 Memory：

当前项目进度
最近合作对象
最近新增偏好
近期计划和待办

这样上下文会更清爽，模型也更容易保持稳定表现。

这四层分别该记什么

如果你想快速记住，可以直接用下面这个区分：

CLAUDE.md：长期默契、全局说明、项目基础背景
Rules：按路径或场景加载的专项规则
Memory：动态知识、临时状态、最近学到的东西
Hooks：高风险操作的程序级强制拦截

结语

很多人把 Claude Code 当成“会写代码的聊天界面”，但真正用深之后，你会发现它更像一个长期协作的智能工作台。

关键不只是你每次怎么下指令，而是你有没有给它一套稳定、清晰、可长期积累的环境。

一旦你把这四层搭起来：

CLAUDE.md
Rules
Memory
Hooks

你和模型之间的协作质量，通常会有非常明显的提升。

因为你终于不是每次都从零开始解释自己是谁、怎么工作、什么事不能做，而是把这些真正沉淀成了环境。

这才是把一个强模型，真正用成成熟工具的关键一步。

Claude Code 多 Agent 协作：Subagents 和 Agent Teams 怎么选

Wed, 22 Apr 2026 21:35:52 +0800

Claude Code 里和多 Agent 协作相关的能力，最容易混淆的就是 Subagents 和 Agent Teams。它们看起来都像“多开几个 Agent 一起做事”，但定位并不一样。简单说，前者更适合把独立任务分出去做，后者更适合让多个 Agent 围绕同一件事持续协作、互相验证。

如果你之前用过 Skill，也可以先这样理解：

Skill 负责定义流程和规则
Subagent 或 Agent teammate 负责实际执行任务

所以问题不在于“哪个更高级”，而在于你要解决的是哪一类协作。

Subagents：把支线任务分出去

Subagents 更像是在当前会话里临时派出去的分身。每个分身都有自己的上下文窗口，做完之后只把结果摘要带回来，主对话不会被大量中间输出塞满。

这类能力的优势很直接：

主线对话更干净，不容易被测试日志、搜索结果或长输出污染
可以把相互独立的研究或执行任务并行化
适合“给我结果就行”的任务，不需要持续讨论

原文提到，Claude Code 内置了三类 Subagent：

Explore：只读、适合快速搜索代码库
Plan：只读、适合在 plan mode 下后台收集信息
General-purpose：可读可写，适合同时探索和修改的任务

自定义 Subagent

如果内置能力不够，可以自己定义一个 Subagent。方式也不复杂，本质上就是写一个 Markdown 文件：

.claude/agents/：只对当前项目生效
~/.claude/agents/：对所有项目生效

文件格式类似这样：

---
name: code-reviewer
description: Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code.
tools: Read, Grep, Glob, Bash
model: inherit
---
You are a senior code reviewer ensuring high standards of code quality and security.

When invoked:

1. Run git diff to see recent changes
2. Focus on modified files
3. Begin review immediately

Review checklist:

- Code is clear and readable
- Functions and variables are well-named
- No duplicated code
- Proper error handling
- No exposed secrets or API keys
- Input validation implemented
- Good test coverage
- Performance considerations addressed
Provide feedback organized by priority:

- Critical issues (must fix)
- Warnings (should fix)
- Suggestions (consider improving)

Include specific examples of how to fix issues.

这里最关键的是 description。Claude 会根据这段描述判断什么时候应该调用这个 Subagent，所以写得越清楚，触发越准。

另外几个常见配置项也很实用：

tools：限制它能用哪些工具
model：决定使用 sonnet、opus、haiku 或 inherit
permissionMode：控制编辑权限和权限提示行为
memory：给 Subagent 配跨对话记忆目录

如果只是临时用一次，也可以直接通过 CLI 注入：

claude --agents '{
  "code-reviewer": {
    "description": "Expert code reviewer. Use proactively after code changes.",
    "prompt": "You are a senior code reviewer. Focus on code quality, security, and best practices.",
    "tools": ["Read", "Grep", "Glob", "Bash"],
    "model": "sonnet"
  }
}'

Subagents 适合什么场景

最适合 Subagents 的，通常是这些任务：

跑测试并返回失败摘要，而不是把几千行日志全塞回主会话
并行调查几个互不依赖的模块
把“检查问题”和“修问题”拆成两步流水线

例如：

`1`	`Research the authentication, database, and API modules in parallel using separate subagents`

`1`	`Use the code-reviewer subagent to find performance issues, then use the optimizer subagent to fix them`

但如果任务需要频繁来回修正、多个阶段共享大量上下文，或者改动高度集中在少数几个文件里，那么直接在主对话里做，往往比派 Subagent 更省事。

Agent Teams：多个独立会话一起协作

Agent Teams 是另一个层级的能力。它不是在一个会话里派出分身，而是启动多个彼此独立的 Claude Code 实例，让它们围绕共享任务列表协作，还可以互相发消息。

这意味着它更像一个真正的小团队，而不只是“分出去做个支线”。

原文提到，这项能力目前还是实验功能，需要先开启：

{
    "env": {
        "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
    }
}

把它加到 settings.json 后，就可以让 Claude 按你的要求组织一个 team。比如：

1
2
3

I'm designing a CLI tool that helps developers track TODO comments across
their codebase. Create an agent team to explore this from different angles: one
teammate on UX, one on technical architecture, one playing devil's advocate.

Agent Teams 的组成

一个 Agent Team 主要由三部分组成：

Team lead：你当前正在使用的主会话，负责组队、分派和汇总
Teammates：多个独立的 Claude Code 实例
Task list 和 Mailbox：共享任务列表与消息通道

和 Subagents 最大的不同在于，teammates 之间可以直接沟通，不需要每次都经过 lead 中转。任务状态通常会在 pending、in progress、completed 之间流转，成员完成一个任务后，还可以继续认领下一个任务。

Agent Teams 适合什么场景

当任务需要多角度讨论、互相挑战结论、或者拆成多个模块并行推进时，Agent Teams 会更合适。

原文给了几个很典型的场景：

多人并行审查同一个 PR，但每个人关注不同维度
围绕同一个 bug 提出不同假设，并互相反驳
前端、后端、测试分别推进不同模块

比如并行代码审查：

Create an agent team to review PR #142. Spawn three reviewers:
- One focused on security implications
- One checking performance impact
- One validating test coverage
Have them each review and report findings.

再比如竞争假说式调试：

Users report the app exits after one message instead of staying connected.
Spawn 5 agent teammates to investigate different hypotheses. Have them talk to
each other to try to disprove each other's theories, like a scientific
debate. Update the findings doc with whatever consensus emerges.

这类任务的共性是：不是只要一个结果，而是需要不同 Agent 之间不断交换判断、修正方向，最后再形成比较可靠的结论。

两者怎么选

如果要快速区分，可以直接记这条：

做完给结果，用 Subagents
需要讨论和相互验证，用 Agent Teams

再展开一点，区别主要在这几个维度：

通信方式：Subagents 主要把结果回传给主对话；Agent Teams 的成员之间可以直接通信
协调模式：Subagents 更依赖主会话统一调度；Agent Teams 有共享任务列表，成员可以自己认领任务
Token 成本：Subagents 更省；Agent Teams 成本更高，因为每个 teammate 都是独立实例
适合任务：Subagents 更适合独立、结果导向的任务；Agent Teams 更适合需要讨论、交叉验证的任务

使用时要注意什么

Agent Teams 虽然更强，但并不意味着任何任务都值得开 team。原文特别提醒了几个现实问题：

token 消耗明显更高
同时让多个 teammate 改同一个文件，很容易互相覆盖
teammate 太多会增加协调成本，收益未必继续增长

因此，比较稳妥的做法通常是：

3 到 5 个 teammate 作为起点
按模块或文件拆任务，避免写入冲突
如果 lead 过早接手了 teammate 的任务，要明确告诉它先等队友完成

另外，当前实验能力还有一些限制，例如：

不支持 /resume 和 /rewind 恢复 in-process teammates
任务状态偶尔会滞后，需要人工提醒更新
一个 lead 一次只能管理一个 team
teammate 不能再继续派子 team

简单结论

这两个能力并不是替代关系，而是分别解决两类协作问题。

如果你的需求是“把支线任务并行做掉，别污染主上下文”，优先用 Subagents。如果你的需求是“让几个 Agent 像一个小团队一样协作、讨论、交叉验证”，再考虑 Agent Teams。

先用一个真实场景试一次，通常很快就能体会到差别：一个强调上下文隔离和结果回收，另一个强调多视角协同和持续互动。

nuwa-skill：把“蒸馏一个人”从灵感变成可执行流程

Wed, 22 Apr 2026 16:20:00 +0800

[alchaincyf/nuwa-skill](https://github.com/alchaincyf/nuwa-skill) 很容易让人先想到一句话：让 AI 模仿名人的口吻回答问题。但它真正有意思的地方，不在“像不像”，而在于它试图把“蒸馏一个人的思维方式”做成一条可重复执行的流程。

这件事一旦成立，价值就不只是做几个好玩的角色 prompt，而是把某个人的判断框架、关注重点、常见启发式和表达习惯，沉淀成一个可以反复调用的 skill。你要的不是一句像某某说出来的话，而是一个更接近“如果他来分析这件事，会先看哪里、怎么取舍、会质疑什么”的工作接口。

它解决的不是“模仿”，而是“建模”

很多所谓的人物 prompt，本质上只是风格贴皮。

它们通常会要求模型：

用某个人的语气说话
多引用这个人的经典句式
尽量模仿他公开表达里的措辞

这样做在演示里很抓眼球，但一到真实任务就很容易露馅。原因也很简单：语气是表层，判断结构才是核心。一个人物之所以有辨识度，不是因为他爱说哪几个词，而是因为他在面对问题时，总会用某些稳定的方法切入。

nuwa-skill 的方向更像是把这种“稳定的方法”提取出来。换句话说，它关心的不是“怎么说得像”，而是“怎么想得像”。

一个更完整的工作流

从仓库说明来看，nuwa-skill 想做的是一套端到端流程：输入一个人名，然后自动完成调研、提炼、验证，再把结果组织成能在 Claude Code 里调用的 skill。

这背后有几个很关键的变化。

第一，它默认蒸馏对象可以不是你团队里的同事。很多人第一次接触这类能力，会先想到“把优秀同事的方法论沉淀下来”。这当然有价值，但边界也很明显：可学习样本有限，而且往往只覆盖团队内部经验。nuwa-skill 直接把对象扩展到更广的人群，比如创业者、投资人、科学家、产品经理、写作者。

第二，它强调的是“自动完成”，而不是让用户手工拼 prompt。真正让这类能力能落地的，不是 prompt 文案写得多华丽，而是你能不能稳定完成资料搜集、观点归纳、模式抽取和结果校验。只要其中某一步完全依赖手工，复用成本就会快速上升。

第三，它试图把产物变成一个 skill，而不是一段一次性对话。前者可以被多次调用、组合、迭代；后者往往只在当前上下文里有效，过几轮就散了。

为什么这种方向值得关注

如果把 AI 当成问答机，最自然的用法是“给我一个答案”。但如果把 AI 当成工作台，问题就会变成“给我一个看问题的方法”。

nuwa-skill 的价值，更偏向后者。

比如你面对一个产品决策，想要的未必是一个标准答案，而是几种截然不同的分析框架：

有人会先看长期复利
有人会先看资源约束
有人会先看用户体验的一致性
有人会先看市场进入时机

如果这些框架能被稳定封装出来，AI 的角色就会从“替你写一段话”变成“帮你快速切换视角”。这比单纯模仿名人语录有用得多，因为它直接作用在决策质量上。

它最打动人的地方：把隐性知识变成可调用资产

很多高价值能力本来就很难写成 SOP。

一个人为什么判断比别人准，往往不是因为他掌握了更多显性规则，而是因为他在长期实践里形成了一套隐性的筛选机制：

什么信号值得优先关注
什么噪音应该直接忽略
哪些问题要拆开看
哪些问题要反过来问
哪些结论必须等待更多证据

这类能力平时很难沉淀，因为它不总能被本人完整说清楚。也正因为如此，一旦能被结构化提取，价值会很高。nuwa-skill 吸引人的地方就在这里：它想处理的不是表面知识搬运，而是认知习惯的再组织。

适合什么场景

我觉得这类 skill 最适合以下几种场景。

1. 决策前的多视角审视

当你已经有一个方案，但担心自己只是在顺着熟悉的路径思考时，切换到不同“人物视角”去审视同一问题，会比让模型继续顺着你的原话扩写更有价值。

2. 学习某类高手的判断框架

很多人学习高手，习惯收藏语录、看访谈、抄摘要，但最后往往只记住了几句漂亮话。把思维模式做成 skill 之后，学习方式会更接近“带着问题反复调用”，而不是“做一堆静态摘抄”。

3. 让团队共享一种分析方式

团队里真正稀缺的，不只是知识文档，而是“我们遇到问题时通常怎样想”。如果未来这套流程成熟，它也可以反过来用于沉淀组织内部高手的方法论，只是它显然不打算把这个能力局限在组织内部。

这类项目真正难的地方

当然，方向有吸引力，不代表问题已经解决。

这类项目最难的，从来不是安装一个 skill，而是下面几件事：

资料源是否足够可靠
提炼出的模式是不是稳定，而不是偶然语料带来的错觉
模型是在使用人物框架分析，还是只是在复述常见印象
不同人物之间的边界会不会被模型自动抹平

也就是说，最关键的不是“能不能生成一段像样的话”，而是“这个 skill 产出的认知框架是否经得起多任务复用”。如果未来它在验证环节继续做深，这类项目的可信度会明显提高。

为什么它比“提示词模板库”更进一步

过去不少项目会把这类能力做成模板库：一个人物对应一段 prompt，用户复制进去就用。问题是模板库本质上还是静态资产，更新慢、验证弱，而且很难形成完整的生产流程。

nuwa-skill 更进一步的地方，是它把“人物蒸馏”从一个模板问题，推进成一个流程问题。

一旦工作重心从“写一段 prompt”转到“如何系统生成、校验、迭代一个人物 skill”，这件事就更像工程，而不是灵感。对真正想长期使用的人来说，后者显然更重要。

结语

nuwa-skill 有意思，不是因为它把 AI 变成了名人模仿秀，而是因为它把“如何学习一个人的思考方式”这件事，往可执行、可复用、可迭代的方向推进了一步。

如果说很多人物 prompt 解决的是“像谁说话”，那它想解决的，是“像谁那样看问题”。前者适合演示，后者才更接近生产力工具。

参考链接

GitHub 仓库：https://github.com/alchaincyf/nuwa-skill
项目说明：https://github.com/alchaincyf/nuwa-skill/blob/main/README.md
Skill 定义：https://github.com/alchaincyf/nuwa-skill/blob/main/SKILL.md

Karpathy 的 65 行 CLAUDE.md：让 AI 编程少犯三类错误

Sun, 19 Apr 2026 18:27:23 +0800

最近 GitHub 上有一个围绕 AI 编程的项目很火，核心其实只是一个大约 65 行的 CLAUDE.md 文件。它之所以能拿到大量 star，不是因为技术实现复杂，而是因为它抓住了很多人使用 AI 写代码时反复遇到的问题。

这个项目的背景，要从 Andrej Karpathy 对 AI 编程的观察说起。Karpathy 是 AI 领域很有影响力的教育者和工程师：斯坦福博士，参与过 OpenAI 早期工作，也曾在 Tesla 负责 Autopilot 视觉系统。后来他持续分享对大模型、教育和 AI 工具的理解，所以他对编程方式变化的判断，总会引起很多开发者关注。

他在一次分享中提到，自己使用 Claude Code 几周后，编程方式发生了明显变化：过去大概是 80% 手写代码、20% AI 辅助，现在更接近 80% 让 AI 写代码，自己做 20% 修改。他形容这像是“用英语编程”，通过自然语言告诉 LLM 要写什么。

但他也指出了 AI 编程的几个典型问题。

01 错误假设

第一个问题是模型很容易替用户做假设，然后沿着这个假设一路写下去。它不一定会主动管理自己的困惑，也不一定会在需求含糊时停下来追问。

比如用户只说“添加用户导出功能”，模型可能会默认导出全部用户，默认输出 JSON，默认写成本地文件，默认权限和字段都不需要再确认。等代码写完，用户才发现它理解的需求和真实场景并不一致。

更好的做法应该是先把不确定点列出来：导出全部用户还是筛选结果？是浏览器下载还是后台任务？需要哪些字段？数据量大不大？是否有权限限制？这些问题不问清楚，后面写得越快，偏得也越远。

02 过度复杂化

第二个问题是模型很容易把简单问题写复杂。一个函数能解决的问题，它可能加上抽象类、策略模式、工厂模式、配置层和一堆“未来可能有用”的扩展点。

这类代码看起来很工程化，实际却增加了维护负担。AI 尤其擅长快速生成大量结构，但并不总能判断这些结构是否真的必要。结果就是一百行能解决的任务，被膨胀成一千行。

判断标准其实很直接：一个资深工程师看到这段改动，会不会觉得它过度设计？如果答案是会，就应该删掉多余层次，用最少的代码解决当前问题。

03 附带伤害

第三个问题是模型有时会修改或删除自己没有充分理解的代码。它可能在修一个小 bug 的时候顺手改注释、重排格式、清理看似无用的 import，甚至动到和当前任务无关的逻辑。

这类“顺手优化”很危险，因为它扩大了变更范围，也让 review 变得更困难。用户本来只想修复一个空邮件导致验证器崩溃的问题，结果模型顺便增强了邮件验证、加了用户名校验、改了文档字符串，最后很难判断到底哪一行影响了行为。

更稳妥的原则是：只动必须动的代码，只清理自己造成的问题。原本就存在的死代码、格式问题或历史包袱，除非任务明确要求处理，否则最多提醒一句，不要直接改。

04 把吐槽变成 CLAUDE.md

在 Karpathy 的观点被大量传播后，开发者 Forrest Cheung 做了一件很聪明的事：他把这些吐槽整理成可以执行的行为准则，写进一个 CLAUDE.md 文件。

这个项目没有复杂代码，关键就是把 AI 编程中最容易出问题的地方，转成明确的工作规则。大致可以概括为四条。

第一条是先想再写。不要默默假设，不要隐藏困惑；如果需求有多种理解，就把它们列出来；如果存在更简单的方案，也要说出来；该追问时追问，该反驳时反驳。

第二条是简单优先。不添加没被要求的功能，不为一次性代码做抽象，不加入多余配置，也不为极小概率场景写大量防御代码。如果 50 行能解决，就不要写成 200 行。

第三条是精准修改。每一行改动都应该能直接追溯到用户请求。不要顺手改善邻近代码，不要重构没坏的东西，尽量匹配项目既有风格。

第四条是目标驱动。不要只给模型一个模糊指令，而是给它可验证的成功标准。比如“修复 bug”可以变成“先写一个能复现 bug 的测试，再让测试通过”；“添加校验”可以变成“写无效输入测试并通过”。成功标准越清楚，模型越容易自己循环到完成。

05 为什么它会火

这个项目能火，不是因为内容很玄，而是因为它足够贴近真实开发。

很多人用 AI 编程时都经历过类似场景：模型自信地误解需求，代码越写越复杂，或者在不该动的地方动手。CLAUDE.md 的价值，是把这些经验变成可以放进项目里的协作规则。

它的门槛也很低：一个文件就能开始生效，不需要复杂接入。再加上 Karpathy 本人的影响力，以及项目里有实战对比案例，它很自然会在 Claude Code 用户和 AI 编程社区里传播开来。

更重要的是，这类规则不是只适用于 Claude Code。无论使用哪种 AI 编程工具，本质问题都很相似：模型需要知道什么时候该问、什么时候该简化、什么时候该停手、怎样判断任务已经完成。

06 对普通开发者的启发

这件事给普通开发者的启发很简单：AI 编程不是把一句需求丢给模型，然后等待奇迹发生。真正有效的方式，是给模型建立边界。

需求不清楚时，让它先暴露假设。实现方案变复杂时，让它主动回到最小可行解。修改代码时，让它只围绕任务目标行动。完成任务时，用测试、命令或明确检查点来验证结果。

AI 写代码的能力已经很强，但它仍然需要好的协作约束。一个短小的 CLAUDE.md 能获得大量关注，说明开发者真正需要的并不只是更聪明的模型，也包括更可靠的工作方式。

简单总结：

先想再写，减少错误假设。
简单优先，避免过度设计。
精准修改，控制变更范围。
目标驱动，用可验证标准推动完成。

这四条并不复杂，却很实用。AI 编程真正提升效率的前提，不是让模型写得更多，而是让它写得更准、更少、更可控。

Claude Code 额度省着用：模型选择、上下文、缓存与 /compact

Sun, 19 Apr 2026 15:26:56 +0800

最近很多人在用 Claude Code 或 Claude Max 时会遇到一个问题：明明买了 Pro、Max 5x，甚至 Max 20x，结果没跑多久就提示额度快满，或者直接需要等重置。尤其是在大项目里让 Claude Code 读很多文件、修复杂 bug、跑长任务时，这种感觉会更明显。

这里先说结论：额度不是按“时间”线性扣的，而是和模型、上下文长度、附件、代码库规模、对话历史、工具调用和当前容量都有关系。同样 5 小时窗口，有的人能用很久，有的人十几分钟就耗尽，通常不是账号坏了，而是每次请求都太重。

这篇整理一套比较实用的省额度习惯。

01 先理解 Claude 的用量窗口

Claude Pro 和 Max 都有使用限制，Claude Code 的使用量会和 Claude 网页、桌面、移动端共享同一套订阅额度。官方说明里提到，消息数量会受到消息长度、附件大小、当前对话长度、所用模型或功能影响；Claude Code 还会受到项目复杂度、代码库大小、自动接受设置等影响。

大致可以这样理解：

Pro：适合轻量使用和小项目。
Max 5x：适合更频繁使用和较大的代码库。
Max 20x：适合更重度、日常高频协作。
用量窗口按 5 小时会话重置。
长消息、长对话、大文件、复杂任务会更快消耗额度。
Opus 这类更强模型会比 Sonnet 更快触发限制。

所以“我只用了 20 分钟”这个说法不一定能说明问题。真正重要的是这 20 分钟里 Claude 读了多少上下文、用了什么模型、是否反复处理大文件、是否在同一个长对话里继续加任务。

02 第一件事：不要默认一直用最贵模型

Claude 系列里常见的定位是：

Opus：能力最强，适合复杂推理、架构决策、疑难 bug。
Sonnet：能力和成本比较均衡，适合大部分日常编码任务。
Haiku：更轻量，适合简单分类、摘要、格式转换等任务。

日常写脚本、改小 bug、整理文档、解释代码，大多数时候 Sonnet 已经够用。Opus 更适合留给这些场景：

复杂架构设计。
多文件深度重构。
难复现的 bug。
需要长链路推理的排障。
普通模型明显卡住的任务。

Claude Code 里可以用 /model 切换模型，也可以在 /config 里设置默认模型。比较稳的习惯是：默认 Sonnet，关键节点再切 Opus，而不是整场任务都用 Opus 扛。

03 第二件事：控制上下文，不要让旧任务拖着走

上下文越长，Claude 每次处理要看的内容越多，额度消耗也越高。Claude Code 官方文档明确建议主动管理上下文：

换到不相关任务时，用 /clear 清空历史。
当前任务做完一个阶段但还要保留重点时，用 /compact 压缩。
想知道上下文里什么占空间，用 /context。
想持续看到状态，可以配置 status line。

一个好用的节奏是：

小阶段完成：/compact
大任务结束：/clear
切换无关项目：/clear
上下文接近很高占用：提前 /compact

/compact 会把前面的对话压成摘要，保留关键任务状态、结论、文件路径、待办事项，但减少后续每次请求要携带的历史。你也可以给它补一句重点：

`1`	`/compact 保留已修改文件、测试结果、剩余待办和关键设计决策`

不要等自动压缩才处理。官方文档提到，Claude Code 会在上下文接近容量上限时自动压缩，但手动在阶段边界压缩，通常更可控。

04 第三件事：长对话和大文件会让每次请求变贵

很多人以为“我只是继续问一句”，应该很便宜。但在长对话里，这一句背后可能带着大量历史、文件摘要、工具定义和系统规则。

特别容易涨上下文的东西包括：

一直不清理的长对话。
让 Claude 读完整大文件。
贴很长日志、构建输出、测试输出。
一次性塞很多截图或图片。
让它反复扫描整个仓库。
过长的 CLAUDE.md。
开了很多 MCP server。

比较省的做法是：日志只贴关键报错，测试输出只给失败部分，大文件让它先用 rg、head、tail、符号搜索定位，再读必要片段。能用命令行过滤的内容，不要整包塞进上下文。

05 第四件事：理解缓存，但不要迷信缓存

Anthropic 的 Prompt Caching 会缓存重复的 prompt 前缀。默认缓存生命周期是 5 分钟，也支持 1 小时缓存。缓存命中时，重复的大段上下文不需要完整重新处理，有助于降低成本和改善额度利用。

但缓存有几个限制：

需要内容完全匹配，文字和图片都要一致。
默认缓存是短生命周期。
改模型、改工具、改系统提示、改上下文结构，都可能降低命中。
输出 token 不会因为缓存而消失，该生成的回答仍然要生成。
Claude Code 具体如何利用缓存，是产品层实现细节，不要把它当成永远稳定的“免费记忆”。

实际使用里，最重要的不是研究缓存细节，而是保持会话稳定：

同一阶段尽量别频繁切模型。
不要中途反复改大量规则。
不要在同一任务里不停贴新图片。
长任务中间不要闲置太久后又继续塞大请求。
阶段结束主动 /compact。

这样更容易让重复上下文保持可复用，也能降低后续请求负担。

06 关于高峰时段：能避开就避开，但不要当固定公式

网上常有人说某些时段额度会更紧。官方帮助中心的表述更谨慎：可发送数量会受到 Claude 当前容量、对话长度、附件、模型和功能影响。也就是说，高峰容量确实可能影响体验，但不要把某个地区的某个时间段当成永久固定规则。

实用建议是：

大重构、大批量分析尽量放到自己网络和服务都稳定的时段。
不要在快到休息时开启一个超长任务。
预计会离开很久时，先 /compact 或 /clear。
如果只是小改动，不要开 Opus 加长上下文硬跑。

这比记一个固定“几点到几点不能用”的规则更可靠。

07 精简 CLAUDE.md、rules、MCP 和 skills

Claude Code 会在会话中加载项目规则、工具信息和一部分环境上下文。官方文档也建议把通用规则和专用规则分开，避免每次启动都带着一大包不相关内容。

比较推荐的拆法：

CLAUDE.md：只放全局都适用的核心规则。
rules：放特定路径、特定文件类型才需要的规则。
skills：放特定工作流，例如发文章、部署、生成图片、提交代码。
MCP：只启用当前任务真的会用到的 server。

如果 CLAUDE.md 写了几百上千行，每次会话都要带进去。更好的方式是把“偶尔才用”的流程移到 skill 里，需要时再调用。

MCP 也是一样。工具多不等于效率高。Claude Code 文档提到可以用 /mcp 查看并禁用不需要的 server，也可以用 /context 看是什么占用了上下文空间。

08 实用指令清单

日常最常用的是这几个：

/model

切换模型。默认建议用 Sonnet，复杂推理再用 Opus。

/clear

清空当前上下文。换无关任务时用，最省。

`1`	`/compact`

压缩历史上下文。一个阶段完成但还要继续同一任务时用。

`1`	`/context`

查看上下文占用，排查是什么吃掉空间。

/status

查看当前订阅或额度相关状态。官方帮助中心也建议用它监控剩余额度。

/mcp

查看和管理 MCP server，关闭当前不用的工具。

如果你用 API 计费模式，还可以关注 /cost；但如果是 Pro/Max 订阅，官方文档说明 /cost 的美元估算不适合作为订阅账单依据，订阅用户更应该看 /stats 和 /status 这类使用信息。

09 一套省额度工作流

比较顺手的流程可以是这样：

新任务开始前先 /clear。
默认用 Sonnet。
先让 Claude 读项目结构和关键文件，不要一口气读全仓库。
每做完一个小阶段就 /compact。
复杂卡点再切 Opus。
日志、报错、测试输出先过滤再给。
任务完成后 /clear，不要拖着旧上下文开新活。
定期检查 CLAUDE.md、MCP 和 skills，把常驻上下文压小。

这个流程的核心是：让 Claude 每次只看当前真正需要看的东西。

10 小结

Claude Code 额度快速耗尽，通常不是单一原因，而是几个因素叠加：用了高成本模型、长对话一直不清、文件和日志塞太多、MCP 和规则常驻过重、缓存命中变差，再加上高峰容量波动。

省额度的核心也很简单：

日常任务优先 Sonnet。
Opus 留给真正复杂的问题。
阶段完成用 /compact。
换任务用 /clear。
用 /context 找上下文占用来源。
精简 CLAUDE.md、rules、MCP 和 skills。
不要把整仓库、整日志、整图片包都丢进去。

同样的 Pro 或 Max 方案，能做多少事，很大程度取决于你怎么管理上下文。把上下文变小、任务边界变清楚，Claude Code 的可用时间和稳定性都会明显好很多。

参考链接

Claude Help Center：Using Claude Code with your Pro or Max plan：https://support.claude.com/en/articles/11145838-using-claude-code-with-your-pro-or-max-plan
Claude Help Center：About Claude’s Max Plan Usage：https://support.anthropic.com/en/articles/11014257-about-claude-s-max-plan-usage/
Claude Code Docs：Manage costs effectively：https://code.claude.com/docs/en/costs
Anthropic Docs：Prompt caching：https://docs.anthropic.com/en/docs/build-with-claude/prompt-caching