大家好，我是讯享网，很高兴认识大家。这里提供最前沿的Ai技术和互联网信息。



Claude Code 的核心不是"回答"，而是一个反复循环的代理过程：

收集上下文 → 采取行动 → 验证结果 → [完成 or 回到收集] ↑ ↓ CLAUDE.md Hooks / 权限 / 沙箱 Skills Tools / MCP Memory 

卡住的地方几乎从来不是模型不够聪明，更多时候是给了它错误的上下文，或者写出来了但根本没法判断对不对，也没法撤回。

真正要关注的五个层面：

简单记：给 Claude 新动作能力用 Tool/MCP，给它一套工作方法用 Skill，需要隔离执行环境用 Subagent，要强制约束和审计用 Hook，跨项目分发用 Plugin。

很多人把上下文当"容量问题"，但卡住的地方通常不是不够长，而是太吵了，有用的信息被大量无关内容淹没了。

200K 总上下文 ├── 固定开销 (~15-20K) │ ├── 系统指令: ~2K │ ├── 所有启用的 Skill 描述符: ~1-5K │ ├── MCP Server 工具定义: ~10-20K ← 最大隐形杀手 │ └── LSP 状态: ~2-5K │ ├── 半固定 (~5-10K) │ ├── CLAUDE.md: ~2-5K │ └── Memory: ~1-2K │ └── 动态可用 (~160-180K) ├── 对话历史 ├── 文件内容 └── 工具调用结果 

一个典型 MCP Server（如 GitHub）包含 20-30 个工具定义，每个约 200 tokens，合计 4,000-6,000 tokens。接 5 个 Server，光这部分固定开销就到了 25,000 tokens（12.5%）。我第一次算出这个数字的时候，真没想到有这么多，在要读大量代码的场景，这 12.5% 真的很关键。

推荐的上下文分层

始终常驻 → CLAUDE.md：项目契约 / 构建命令 / 禁止事项 按路径加载 → rules：语言 / 目录 / 文件类型特定规则 按需加载 → Skills：工作流 / 领域知识 隔离加载 → Subagents：大量探索 / 并行研究 不进上下文 → Hooks：确定性脚本 / 审计 / 阻断 

说白了，偶尔用的东西就不要每次都加载进来。

上下文**实践

保持 CLAUDE.md 短、硬、可执行，优先写命令、约束、架构边界。Anthropic 官方自己的 CLAUDE.md 大约只有 2.5K tokens，可以参考, 以下是一些经验：

• 把大型参考文档拆到 Skills 的 supporting files，不要塞进 SKILL.md 正文
• 使用 .claude/rules/ 做路径/语言规则，不让根 CLAUDE.md 承担所有差异
• 长会话主动用 /context 观察消耗，不要等系统自动压缩后再补救
• 任务切换优先 /clear，同一任务进入新阶段用 /compact
• 把 Compact Instructions 写进 CLAUDE.md，压缩后必须保留什么由你控制，不由算法猜

Tool Output 噪声：另一个隐形上下文杀手

# Claude 看到的原始输出 running 262 tests test auth::test_login ... ok ...（几千行） # 走 RTK 之后 ✓ cargo test: 262 passed (1 suite, 0.08s) 

Claude 真正需要知道的就是「过了还是挂了，挂在哪里」，其他都是噪声。它通过 Hook 透明重写命令，对 Claude Code 来说完全无感。后面第 6 节会提到 | head -30 这种手动截断，RTK 干的就是这件事，只是覆盖面更广，不用每条命令自己加，项目开源在github

压缩机制的陷阱

 Compact Instructions When compressing, preserve in priority order: 1. Architecture decisions (NEVER summarize) 2. Modified files and their key changes 3. Current verification status (pass/fail) 4. Open TODOs and rollback notes 5. Tool outputs (can delete, keep pass/fail only) 

Plan Mode 的工程价值

Plan Mode 的核心是把探索和执行拆开，探索阶段不动文件，确认方案后再执行：

• 探索阶段以只读操作为主
• Claude 可以先澄清目标和边界，再提交具体方案
• 执行成本在计划确认之后才发生
  
  对于复杂重构、迁移、跨模块改动，这样做比"急着出代码"有用多了，在错误假设上越跑越偏的情况会少很多。按两下 Shift+Tab 进入 Plan Mode，进阶玩法是开一个 Claude 写计划，再开一个 Codex 以"高级工程师"身份审这个计划，让 AI 审 AI，效果很好。
  
  
  
  
  

Skill 官方描述是"按需加载的知识与工作流"，描述符常驻上下文，完整内容按需加载，用起来和"保存的 Prompt"差别挺大的。

一个好 Skill 应该满足什么

• 描述要让模型知道"何时该用我"，而不是"我是干什么的"，这两个差很多
• 有完整步骤、输入、输出和停止条件，别写了个开头没有结尾
• 正文只放导航和核心约束，大资料拆到 supporting files 里
• 有副作用的 Skill 要显式设置 disable-model-invocation: true，不然 Claude 会自己决定要不要跑

Skill 怎么做到按需加载

Claude Code 团队在内部设计中反复强调 “progressive disclosure”，意思不是让模型一次性看到所有信息，而是先获得索引和导航，再按需拉取细节：

• SKILL.md 负责定义任务语义、边界和执行骨架
• supporting files 负责提供领域细节
• 脚本负责确定性收集上下文或证据

一个比较稳定的结构长这样：

.claude/skills/ └── incident-triage/ ├── SKILL.md ├── runbook.md ├── examples.md └── scripts/ └── collect-context.sh 

Skill 的三种典型类型

类型一：检查清单型（质量门禁）

发布前跑一遍，确保不漏项：

--- name: release-check description: Use before cutting a release to verify build, version, and smoke test. ---  Pre-flight (All must pass) - [ ] `cargo build --release` passes - [ ] `cargo clippy -- -D warnings` clean - [ ] Version bumped in Cargo.toml - [ ] CHANGELOG updated - [ ] `kaku doctor` passes on clean env  Output Pass / Fail per item. Any Fail must be fixed before release. 

类型二：工作流型（标准化操作）

配置迁移高风险，显式调用 + 内置回滚步骤：

--- name: config-migration description: Migrate config schema. Run only when explicitly requested. disable-model-invocation: true ---  Steps 1. Backup: `cp ~/.config/kaku/config.toml ~/.config/kaku/config.toml.bak` 2. Dry run: `kaku config migrate --dry-run` 3. Apply: remove `--dry-run` after confirming output 4. Verify: `kaku doctor` all pass  Rollback `cp ~/.config/kaku/config.toml.bak ~/.config/kaku/config.toml` 

类型三：领域专家型（封装决策框架）

运行时出问题时让 Claude 按固定路径收集证据，不要瞎猜：

--- name: runtime-diagnosis description: Use when kaku crashes, hangs, or behaves unexpectedly at runtime. ---  Evidence Collection 1. Run `kaku doctor` and capture full output 2. Last 50 lines of `~/.local/share/kaku/logs/` 3. Plugin state: `kaku --list-plugins`  Decision Matrix | Symptom | First Check | |---|---| | Crash on startup | doctor output → Lua syntax error | | Rendering glitch | GPU backend / terminal capability | | Config not applied | Config path + schema version |  Output Format Root cause / Blast radius / Fix steps / Verification command 

描述符写短点，每个 Skill 都在偷你的上下文空间，每个启用的 Skill，描述符常驻上下文，优化前后差距很大：

# 低效（~45 tokens） description: | This skill helps you review code changes in Rust projects. It checks for common issues like unsafe code, error handling... Use this when you want to ensure code quality before merging. # 高效（~9 tokens） description: Use for PR reviews with focus on correctness. 

还有一个很重要的 disable-auto-invoke 使用策略：

• 高频（>1 次/会话）→ 保持 auto-invoke，优化描述符
• 低频（<1 次/会话）→ disable-auto-invoke，手动触发，描述符完全脱离上下文
• 极低频（<1 次/月）→ 移除 Skill，改为 AGENTS.md 中的文档

• 描述过短：description: help with backend（任何后端工作都能触发，哈哈）
• 正文过长：几百行工作手册全塞进 SKILL.md 正文
• 一个 Skill 覆盖 review、deploy、debug、docs、incident 五件事
• 有副作用的 Skill 允许模型自动调用

给 Claude 的工具和给人写的 API 不是一回事。给人用的 API 往往会追求功能齐全，但给 agent 用，重点不是功能堆得多完整，而是让它更容易用对。

几个实用设计原则

• 名称前缀按系统或资源分层：github_pr_、jira_issue_
• 对大响应支持 response_format: concise / detailed
• 错误响应要教模型如何修正，不要只抛 opaque error code
• 能合并成高层任务工具时，不要暴露过多底层碎片工具，避免 list_all_* 让模型自行筛选

从 Claude Code 内部工具演进学到的

Claude Code 团队内部工具的这段演进时，感觉还挺有意思。像这种需要在任务中途停下来问用户的场景，他们前后试了三种做法：

• 第一版：给已有工具（如 Bash）加一个 question 参数，让 Claude 在调用工具时顺带提问。结果 Claude 大多数时候直接忽略这个参数，继续往下跑，根本不停下来问。
• 第二版：要求 Claude 在输出里写特定 markdown 格式，外层解析到这个格式就暂停。问题是没有强制约束，Claude 经常"忘了"按格式写，提问逻辑非常脆弱。
• 第三版：做成独立的 AskUserQuestion 工具。Claude 想提问就必须显式调用它，调用即暂停，没有歧义，比前两版靠谱多了。

Todo 工具的演进

早期用 TodoWrite 工具 + 每 5 轮插入提醒让 Claude 记住任务。随着模型变强，这个工具反而成了限制，Todo 提醒让 Claude 认为必须严格遵循，无法灵活修改计划。挺有意思的教训：当初加这个工具是因为模型不够强，模型变强之后它反而变成了枷锁。值得过段时间回来检查一下，当初加的限制还成不成立。

搜索工具的演进：最初用 RAG 向量数据库，虽然快但需要索引、不同环境脆弱，最重要的是 Claude 不喜欢用。改成 Grep 工具让 Claude 自己搜索后，好用很多。后来又发现一个顺带的好处：Claude 读 Skill 文件，Skill 文件又引用其他文件，模型会递归读取，按需发现信息，不需要提前塞进去，这个模式后来被叫做"渐进式披露"。

什么时候不该再加 Tool

• 本地 shell 可以可靠完成的事情
• 模型只需要静态知识，不需要真正与外部交互
• 需求更适合 Skill 的工作流约束，而不是 Tool 的动作能力
• 还没验证过工具描述、schema 和返回格式能被模型稳定使用

Hooks 很容易被当成"自动运行的脚本"，但我自己用下来，觉得它更像是把一些不能交给 Claude 临场发挥的事情，重新收回到确定性的流程里。

适合 vs 不适合放到 Hooks 的

适合：阻断修改受保护文件、Edit 后自动格式化/lint/轻量校验、SessionStart 后注入动态上下文（Git 分支、环境变量）、任务完成后推送通知。

不适合：需要读大量上下文的复杂语义判断、长时间运行的业务流程、需要多步推理和权衡的决策，这些该在 Skill 或 Subagent 里。

json

{ "hooks": { "PostToolUse": [ { "matcher": "Edit", "pattern": "*.rs", "hooks": [ { "type": "command", "command": "cargo check 2>&1 | head -30", "statusMessage": "Running cargo check..." } ] } ], "Notification": [  ] } } 

Hooks：越早发现错误，越省时间

在 100 次编辑的会话中，每次节省 30-60 秒，累积节省 1-2 小时，还挺可观的。注意限制输出长度（| head -30），避免 Hook 输出反而污染上下文。如果不想在每条命令后面手动加截断，可以看看第 3 节提到的 RTK，它把这件事系统化了。

Hooks + Skills + CLAUDE.md 三层叠加

• CLAUDE.md：声明"提交前必须通过测试和 lint"
• Skill：告诉 Claude 在什么顺序下运行测试、如何看失败、如何修复
• Hook：对关键路径执行硬性校验，必要时阻断

用下来感觉，三样少任何一层都会有漏洞。只写 CLAUDE.md 规则，Claude 经常当没看见；只靠 Hooks，细节判断又做不了，放在一起才比较稳。

配置时要显式约束

• tools / disallowedTools：限定能用什么工具，别给和主线程一样宽的权限
• model：探索任务用 Haiku/Sonnet，重要审查用 Opus
• maxTurns：防止跑飞
• isolation: worktree：需要动文件时隔离文件系统
  另一个实用细节：长时间运行的 bash 命令可以按 Ctrl+B 移到后台，Claude 之后会用 BashOutput 工具查看结果，不会阻塞主线程继续工作。subagent 同理，直接告诉它「在后台跑」就行。
  
  

几个常见反模式

• 子代理权限和主线程一样宽，隔离没有意义
• 输出格式不固定，主线程拿到没法用
• 子任务之间强依赖，频繁要共享中间状态，这种情况用 Subagent 不合适

Prompt 缓存是按前缀匹配工作的，从请求开头到每个 cache_control 断点之前的内容都会被缓存。所以这里的顺序很重要：

Claude Code 的 Prompt 顺序： 1. System Prompt → 静态，锁定 2. Tool Definitions → 静态，锁定 3. Chat History → 动态，在后面 4. 当前用户输入 → 最后 

破坏缓存的常见陷阱

• 在静态系统 Prompt 中放入带时间戳的内容（让它每次都变）
• 非确定性地打乱工具定义顺序
• 会话中途增删工具

那像当前时间这种动态信息怎么办？别去动系统 Prompt，放到下一条消息里传进去就行。Claude Code 自己也是这么做的，用户消息里加 标签，系统 Prompt 不动，缓存也就不会被打坏。

Prompt 缓存是模型唯一的。假如你已经和 Opus 对话了 100K tokens，想问个简单问题，切换到 Haiku 实际上比继续用 Opus 更贵，因为要为 Haiku 重建整个缓存。确实需要切换的话，用 Subagent 交接：Opus 准备一条"交接消息"给另一个模型，说明需要完成的任务就行。

Compaction 的实际实现

上图是 Compaction（上下文压缩）的执行流程：左边是上下文快满时的状态，中间是 Claude Code 开一个 fork 调用，把完整对话历史喂给模型，加一句"Summarize this conversation"，这一步命中缓存所以只需 1/10 的价格，右边是压缩完之后，原来几十轮对话被替换成一段 ~20k tokens 的摘要，System + Tools 还在，再挂上之前用到的文件引用，腾出空间继续新的轮次。
直觉上 Plan Mode 应该切换成只读工具集，但这会破坏缓存。实际实现是：EnterPlanMode 是模型可以自己调用的工具，检测到复杂问题时自主进入 plan mode，工具集不变，缓存不受影响。

defer_loading：工具的延迟加载

Claude Code 有数十个 MCP 工具，每次请求全量包含会很贵，但中途移除会破坏缓存。解决方案是发送轻量级 stub，只有工具名，标记 defer_loading: true。模型通过 ToolSearch 工具"发现"它们，完整的工具 schema 只在模型选择后才加载，这样缓存前缀保持稳定。

「Claude 说完成了」其实没啥用，你得能知道它做没做对、出了问题能退回来、过程还能查，这才算数。

• 最低层：命令退出码、lint、typecheck、unit test
• 中间层：集成测试、截图对比、contract test、smoke test
• 更高层：生产日志验证、监控指标、人工审查清单

在 Prompt、Skill 和 CLAUDE.md 中显式定义验证

 Verification

For backend changes:

• Run `make test` and `make lint`
• For API changes, update contract tests under `tests/contracts/`

For UI changes:

• Capture before/after screenshots if visual

Definition of done:

• All tests pass
• Lint passes
• No TODO left behind unless explicitly tracked

  写任务 Prompt 或 Skill 的时候，最好把验收标准提前说清楚。哪些命令跑完算完成，失败了先查什么，截图和日志看到什么才算过，这些越早讲明白，后面越省事。

  我自己有个很简单的判断：假如一个任务你都说不清楚「Claude 怎么才算做对了」，那它大概率也不适合直接丢给 Claude 自动完成

这些命令说白了就干一件事：主动管理上下文，别等系统自己处理。

上下文管理

/context # 查看 token 占用结构，排查 MCP 和文件读取占比 /clear # 清空会话，同一问题被纠偏两次以上就重来 /compact # 压缩但保留重点，配合 Compact Instructions /memory # 确认哪些 CLAUDE.md 真的被加载了 

能力与治理

/mcp # 管理 MCP 连接，检查 token 成本，断开闲置 server /hooks # 管理 hooks，控制平面入口 /permissions # 查看或更新权限白名单 /sandbox # 配置沙箱隔离，高自动化场景必备 /model # 切换模型：Opus 用于深度推理，Sonnet 用于常规，Haiku 用于快速探索 

会话连续性与并行

claude –continue # 恢复当前目录最近会话，隔天接着做 claude –resume # 打开选择器恢复历史会话 claude –continue –fork # 从已有会话分叉，同一起点不同方案 claude –worktree # 创建隔离 git worktree claude -p “prompt” # 非交互模式，接入 CI / pre-commit / 脚本 claude -p –output-format json # 结构化输出，便于脚本消费 

/simplify：对刚改完的代码做三维检查，代码复用、质量和效率，发现问题直接修掉。特别适合改完一段逻辑后立刻跑一遍，代替手动 review。

/rewind：不是“撤销”，而是回到某个会话 checkpoint 重新总结。适合：Claude 已沿错误路径探索太久；想保留前半段共识但丢掉后半段失败。

/btw：在不打断主任务的前提下快速问一个侧问题，适合“两个命令有什么区别”这类单轮旁路问答，不适合需要读仓库或调用工具的问题。

claude -p –output-format stream-json：实时 JSON 事件流，适合长任务监控、增量处理、流式集成到自己的工具。

/insight：让 Claude 分析当前会话，提炼出哪些内容值得沉淀到 CLAUDE.md。用法是会话做了一段之后跑一次，它会指出“这个约定你们反复提到，但没有写进契约”之类的盲点，是迭代优化 CLAUDE.md 的好手段。

双击 ESC 回溯：按两次 ESC 可以回到上一条输入重新编辑，不用重新手打。Claude 走偏了、或者上一句话没说清楚，双击 ESC 修改后重发，比重新开会话省事得多。

对话历史都在本地：所有会话记录存放在 ~/.claude/projects/ 下，文件夹名按项目路径命名（斜杠变横杠），每个会话是一个 .jsonl 文件。想找某个话题的历史，直接 grep -rl “关键词” ~/.claude/projects/ 就能定位，或者直接告诉 Claude「帮我搜一下之前关于 X 的讨论」，它会自己去翻。