Claude Code 实战：我用 skill-creator 做了一个 context-snapshot，把长对话压成“可继承的会话快照”

开篇：当 AI 开始”编造”代码

你可能也遇到过这种情况：和 AI 聊了几十轮后，它突然开始”编造”一些不存在的代码逻辑，或者忘记了你之前明确提出的约束条件。

我也一样。总结上下文、AI 接力、新开对话是我日常工作的一部分。平时我用 Claude 和 Cursor 来工作，每次上下文过长时，我都会手动敲出一段 Prompt 来总结当前进度，但每次都不一样，效率很低。

问题是什么：AI 对话在上下文过长时，幻觉概率大大增加，导致工作效率下降。

影响是什么：每次手动总结上下文耗时 5-10 分钟，而且总结质量不稳定，新会话继承时容易丢失关键信息。

我打算怎么解决：创建一个专用的 Skill，标准化上下文压缩流程，确保新会话能精准继承所有关键信息。

背景：AI 对话的老大难问题

上下文过长的真实影响

在日常使用 Claude Code 的过程中，我发现一个规律：当对话轮次超过 30-40 轮时，AI 开始出现以下问题：

选择性遗忘：忘记之前明确的技术选型决策
编造细节：猜测不存在的代码逻辑或配置项
重复劳动：反复询问已经回答过的问题
方向偏离：逐渐偏离最初的目标

这不是 AI 的问题，而是 Transformer 架构的固有限制。上下文窗口再大，也有信息密度的上限。

我的旧方案：手动 Prompt

之前我的做法是：

请总结当前对话的关键信息：
1. 已完成的任务
2. 进行中的任务
3. 关键决策和原因
4. 代码变更摘要
5. 待解决问题

理想很丰满，但现实是：

每次 Prompt 都不一样，质量不稳定
总结的粒度难以把握（太粗丢信息，太细太冗长）
新会话继承时，AI 仍然需要”理解”这段总结，容易产生二次幻觉

方案选择：Skill vs MCP

Claude Code 的两种扩展方式

在决定解决方案之前，我需要搞清楚 Claude Code 的两种扩展机制：

核心卡点：对于我的需求来说，上下文压缩是一个”流程问题”，不需要调用外部 API，也不需要复杂的服务端逻辑。所以 Skill 是最合适的选择。

请记住：Skill 封装流程，MCP 扩展功能，选择取决于你的需求本质。

实现过程：与 Claude Code 的交互

Step 1: 明确需求

我在 Claude Code 中输入了初始需求：

ai对话通常在上下文过长的时候大大增加出现幻觉的概率。
为了解决这个问题我打算设计一个skill，来压缩上下文。
工作流计划是这样：
1. 当我识别到上下文过长的时候，通过关键词触发skill
2. claude code 收到以后调用skill，这个skill中精确描述了ai应该如何回顾当前上下文中所有有效的信息、知识点、Todo
3. 生成简要总结，这个总结能无缝新开会话以后直接输入对话框
4. 新的对话框能精准继承所有关键的上下文

补充说明：
1. 可以通过文件来转交，Markdown记录沉淀
2. 最佳实践是什么样的？基于我这个需求 跟我探讨以后调用skill-creator skill帮我创建一个skill

Step 2: Claude Code 的澄清式提问

Claude Code 没有直接开始创建，而是先问了 5 个关键问题：

1. 触发词: 你倾向于 /compress 还是 /save-context 还是其他?
2. 自动git提交: 压缩时是否自动提交当前工作到git? (便于回溯)
3. diff检测: 是否自动运行 git diff 来总结代码变更?
4. 交互式确认: 生成总结后,是否需要你review再保存? 还是直接保存+显示?
5. 新会话启动: 你希望总结文件包含"一键继承"的精确提示词吗?

这一步非常关键。Claude Code 通过提问，帮我澄清了以下设计决策：

触发词设计：是用简短的命令式（/compress）还是自然语言（总结上下文并保存）？
自动化边界：哪些操作应该自动执行，哪些应该留给用户？
交互模式：是”生成后确认”还是”直接生成”？

Step 3: 我的决策

基于个人使用习惯，我的回复：

1. 触发词我选择 "总结上下文并保存"
2. 不需要Git提交
3. 不需要diff检测
4. 不需要Review，我会看一遍生成的文件内容，然后我自己修改后在新会话使用。
5. 包含用于一键继承的Prompt
6. 在设计Prompt的时候，要通过Prompt让模型知道，总结出的上下文一定要精确、有价值，不能丢失任何关键信息，否则新会话也会产生幻觉，这会有很大的影响！！！

说白了，我选择了”最小自动化”策略：

✅ 自动生成总结文件
❌ 不自动提交 Git（我需要先 review）
❌ 不自动运行 git diff（避免不必要的开销）
✅ 包含一键继承 Prompt（降低新会话的理解成本）

请记住：自动化不是越多越好，关键是找到”信任边界”——哪些操作可以放心交给 AI，哪些必须人工确认。

Skill 的结构：元数据 + 工作流

Skill 的两个核心部分

Claude Code 生成的 Skill 文件结构非常清晰，分为两部分：

元数据（YAML Front Matter）

---
name: context-snapshot
description: 上下文压缩与会话继承工具。当对话上下文过长、需要总结保存当前进度、或准备开启新会话时使用。触发词："总结上下文并保存"、"压缩上下文"、"保存会话快照"。自动提取任务状态、代码变更、决策记录、知识沉淀等关键信息，生成结构化Markdown文件供新会话无损继承。
---

关键字段：

name：Skill 的唯一标识符
description：触发条件 + 功能描述（Claude Code 用这个判断是否调用该 Skill）

工作流（Markdown 正文）

工作流部分是纯 Markdown 文档，描述了 AI 应该如何执行任务。核心章节包括：

## 核心原则

### 1. 完整性优先
**绝对不允许遗漏关键信息**。宁可冗余也不可省略。

### 2. 精确性验证
所有引用必须准确：
- 文件路径必须完整精确
- 错误信息必须原文引用
- 配置项必须包含具体值

### 3. 防幻觉设计
生成的快照文件必须包含明确的"继承要求"，强制新会话AI：
- 完整阅读所有内容
- 验证而非假设
- 查看原始代码而非猜测

工作流的分层设计

Skill 的工作流分为 4 个步骤：

flowchart TD
    A[Step 1: 全面分析对话历史] --> B[Step 2: 生成结构化文件]
    B --> C[Step 3: 质量检查]
    C --> D[Step 4: 输出总结]

    A --> A1[任务清单状态]
    A --> A2[关键决策记录]
    A --> A3[代码变更摘要]
    A --> A4[知识沉淀]
    A --> A5[依赖上下文]
    A --> A6[待解决问题]

    C --> C1[完整性检查]
    C --> C2[精确性检查]
    C --> C3[结构化检查]
    C --> C4[可操作性检查]
    C --> C5[敏感信息检查]

核心设计思想：

清单化提取：将对话历史拆解为 6 个维度（任务、决策、代码、知识、依赖、问题）
结构化输出：使用固定的 Markdown 模板，确保新会话能快速定位信息
质量门禁：5 项自动检查，防止生成低质量总结
一键继承：文件末尾包含精确的继承 Prompt

关键代码片段：文件命名规范

文件命名规范：.claude/sessions/YYYY-MM-DD_HHmm_主题简述.md

示例：
- `.claude/sessions/2026-01-16_1430_feature-auth.md`
- `.claude/sessions/2026-01-16_2215_bugfix-login.md`

**主题简述规范**：
- 使用kebab-case格式
- 3-5个单词描述核心任务
- 区分feature/bugfix/refactor/optimization等类型

为什么这样设计？

时间戳前缀：便于按时间排序，快速找到最近的会话
主题简述：一眼看出这个会话在做什么
类型前缀：便于分类管理（feature/bugfix/refactor）

验证与结果

生成的 Skill 质量

Claude Code 生成的 Skill 文件长达 276 行，包含：

实际效果对比

量化指标：

总结生成时间：从 5-10 分钟 降低到 30 秒
信息遗漏率：从 约 30% 降低到 < 5%（基于主观评估）
新会话理解成本：从 需要 3-5 轮澄清 降低到 直接继承

经验总结：创建 Skill 的最佳实践

需求澄清比直接实现更重要

不要急于让 AI 开始写代码。Claude Code 的澄清式提问帮我避免了以下问题：

触发词设计不合理（太长或太短）
自动化边界不清晰（哪些该自动，哪些该手动）
输出格式不明确（直接显示还是保存文件）

可复用原则：在创建 Skill 之前，先列出 5-10 个设计决策点，逐一确认。

Skill 的价值在于流程标准化

Skill 不是”写一段 Prompt”，而是”封装一套可复用的工作流”。

对比：

❌ 差的 Skill：只是一段固定的 Prompt
✅ 好的 Skill：包含清单、检查项、边界条件、异常处理

元数据的 `description` 字段是触发关键

Claude Code 通过 description 字段判断是否调用 Skill。这个字段必须包含：

触发词：用户可能输入的关键词（支持多个）
功能描述：这个 Skill 解决什么问题
适用场景：什么时候应该用这个 Skill

工作流要”防呆设计”

假设 AI 会犯错，在 Skill 中明确：

不允许做什么：例如”绝对不允许遗漏关键信息”
必须验证什么：例如”文件路径必须完整精确”
如何处理异常：例如”文件冲突时自动追加序号”

一键继承是关键

新会话继承上下文时，最大的问题是”AI 需要理解总结”。解决方案：

在总结文件末尾，包含一段精确的继承 Prompt
这段 Prompt 明确告诉 AI：“完整阅读所有内容，验证而非假设”

请记住：Skill 的终极目标是让 AI 能够”无损继承”上下文，而不是”理解总结”。

总结

本文记录了使用 Claude Code 的 skill-creator 创建 context-snapshot Skill 的完整过程。

请记住：好的 Skill 不是写出来的，而是通过澄清式提问”设计”出来的。

核心要点：

选择 Skill 而非 MCP：流程标准化用 Skill，外部集成用 MCP
澄清式提问：在实现之前，先确认 5-10 个设计决策点
清单化提取：将复杂任务拆解为多个维度的清单
防呆设计：明确”不允许做什么”和”必须验证什么”
一键继承：包含精确的继承 Prompt，降低新会话理解成本

可复用 Checklist

当你需要创建一个新的 Skill 时，可以参考以下清单：

明确需求本质：这是流程问题（用 Skill）还是功能扩展（用 MCP）？
列出设计决策点：触发词、自动化边界、交互模式、输出格式
与 AI 澄清需求：不要急于实现，先确认所有决策点
设计元数据：name 简洁，description 包含触发词和功能描述
清单化工作流：将任务拆解为多个步骤和维度
增加质量检查：完整性、精确性、结构化、可操作性
防呆设计：明确”不允许”和”必须验证”
异常处理：文件冲突、敏感信息、长文件优化
一键继承：包含精确的继承 Prompt
测试验证：实际使用 3-5 次，迭代优化

欢迎大家在评论区交流。

Perfecto