深度解析 Claude Code 的上下文压缩机制

IMPORTANT: This message and these instructions are NOT part of the actual
user conversation. Do NOT include any references to "note-taking",
"session notes extraction", or these update instructions in the notes content.

Based on the user conversation above (EXCLUDING this note-taking instruction
message as well as system prompt, claude.md entries, or any past session
summaries), update the session notes file.

The file {{notesPath}} has already been read for you. Here are its current
contents:
<current_notes_content>
{{currentNotes}}
</current_notes_content>

Your ONLY task is to use the Edit tool to update the notes file, then stop.
You can make multiple edits (update every section as needed) - make all Edit
tool calls in parallel in a single message. Do not call any other tools.

CRITICAL RULES FOR EDITING:
- The file must maintain its exact structure with all sections, headers, and
  italic descriptions intact
  - NEVER modify, delete, or add section headers (the lines starting with
    '#' like # Task specification)
  - NEVER modify or delete the italic _section description_ lines (these are
    the lines in italics immediately following each header - they start and
    end with underscores)
  - The italic _section descriptions_ are TEMPLATE INSTRUCTIONS that must be
    preserved exactly as-is - they guide what content belongs in each section
  - ONLY update the actual content that appears BELOW the italic _section
    descriptions_ within each existing section
  - Do NOT add any new sections, summaries, or information outside the
    existing structure
- Do NOT reference this note-taking process or instructions anywhere in
  the notes
- It's OK to skip updating a section if there are no substantial new
  insights to add. Do not add filler content like "No info yet", just
  leave sections blank/unedited if appropriate.
- Write DETAILED, INFO-DENSE content for each section - include specifics
  like file paths, function names, error messages, exact commands,
  technical details, etc.
- For "Key results", include the complete, exact output the user requested
  (e.g., full table, full answer, etc.)
- Do not include information that's already in the CLAUDE.md files included
  in the context
- Keep each section under ~2000 tokens/words - if a section is approaching
  this limit, condense it by cycling out less important details while
  preserving the most critical information
- Focus on actionable, specific information that would help someone
  understand or recreate the work discussed in the conversation
- IMPORTANT: Always update "Current State" to reflect the most recent
  work - this is critical for continuity after compaction

Use the Edit tool with file_path: {{notesPath}}

STRUCTURE PRESERVATION REMINDER:
Each section has TWO parts that must be preserved exactly as they appear
in the current file:
1. The section header (line starting with #)
2. The italic description line (the _italicized text_ immediately after
   the header - this is a template instruction)

You ONLY update the actual content that comes AFTER these two preserved
lines. The italic description lines starting and ending with underscores
are part of the template structure, NOT content to be edited or removed.

REMEMBER: Use the Edit tool in parallel and stop. Do not continue after
the edits. Only include insights from the actual user conversation, never
from these note-taking instructions. Do not delete or change section
headers or italic _section descriptions_.

# Session Title
_A short and distinctive 5-10 word descriptive title for the session.
Super info dense, no filler_

# Current State
_What is actively being worked on right now? Pending tasks not yet
completed. Immediate next steps._

# Task specification
_What did the user ask to build? Any design decisions or other
explanatory context_

# Files and Functions
_What are the important files? In short, what do they contain and
why are they relevant?_

# Workflow
_What bash commands are usually run and in what order? How to interpret
their output if not obvious?_

# Errors & Corrections
_Errors encountered and how they were fixed. What did the user correct?
What approaches failed and should not be tried again?_

# Codebase and System Documentation
_What are the important system components? How do they work/fit together?_

# Learnings
_What has worked well? What has not? What to avoid? Do not duplicate
items from other sections_

# Key results
_If the user asked a specific output such as an answer to a question,
a table, or other document, repeat the exact result here_

# Worklog
_Step by step, what was attempted, done? Very terse summary for each step_

CRITICAL: Respond with TEXT ONLY. Do NOT call any tools.

- Do NOT use Read, Bash, Grep, Glob, Edit, Write, or ANY other tool.
- You already have all the context you need in the conversation above.
- Tool calls will be REJECTED and will waste your only turn — you will
  fail the task.
- Your entire response must be plain text: an <analysis> block followed
  by a <summary> block.

Your task is to create a detailed summary of the conversation so far,
paying close attention to the user's explicit requests and your previous
actions. This summary should be thorough in capturing technical details,
code patterns, and architectural decisions that would be essential for
continuing development work without losing context.

Before providing your final summary, wrap your analysis in <analysis>
tags to organize your thoughts and ensure you've covered all necessary
points. In your analysis process:

1. Chronologically analyze each message and section of the conversation.
   For each section thoroughly identify:
   - The user's explicit requests and intents
   - Your approach to addressing the user's requests
   - Key decisions, technical concepts and code patterns
   - Specific details like:
     - file names
     - full code snippets
     - function signatures
     - file edits
   - Errors that you ran into and how you fixed them
   - Pay special attention to specific user feedback that you received,
     especially if the user told you to do something differently.
2. Double-check for technical accuracy and completeness, addressing each
   required element thoroughly.

Your summary should include the following sections:

1. Primary Request and Intent: Capture all of the user's explicit
   requests and intents in detail
2. Key Technical Concepts: List all important technical concepts,
   technologies, and frameworks discussed.
3. Files and Code Sections: Enumerate specific files and code sections
   examined, modified, or created. Pay special attention to the most
   recent messages and include full code snippets where applicable and
   include a summary of why this file read or edit is important.
4. Errors and fixes: List all errors that you ran into, and how you
   fixed them. Pay special attention to specific user feedback that you
   received, especially if the user told you to do something differently.
5. Problem Solving: Document problems solved and any ongoing
   troubleshooting efforts.
6. All user messages: List ALL user messages that are not tool results.
   These are critical for understanding the users' feedback and changing
   intent.
7. Pending Tasks: Outline any pending tasks that you have explicitly
   been asked to work on.
8. Current Work: Describe in detail precisely what was being worked on
   immediately before this summary request, paying special attention to
   the most recent messages from both user and assistant. Include file
   names and code snippets where applicable.
9. Optional Next Step: List the next step that you will take that is
   related to the most recent work you were doing. IMPORTANT: ensure
   that this step is DIRECTLY in line with the user's most recent
   explicit requests, and the task you were working on immediately
   before this summary request. If your last task was concluded, then
   only list next steps if they are explicitly in line with the users
   request. Do not start on tangential requests or really old requests
   that were already completed without confirming with the user first.
   If there is a next step, include direct quotes from the most recent
   conversation showing exactly what task you were working on and where
   you left off. This should be verbatim to ensure there's no drift in
   task interpretation.

<example>
<analysis>
[Your thought process, ensuring all points are covered thoroughly
and accurately]
</analysis>

<summary>
1. Primary Request and Intent:
   [Detailed description]

2. Key Technical Concepts:
   - [Concept 1]
   - [Concept 2]
   - [...]

3. Files and Code Sections:
   - [File Name 1]
      - [Summary of why this file is important]
      - [Summary of the changes made to this file, if any]
      - [Important Code Snippet]
   - [...]

4. Errors and fixes:
    - [Detailed description of error 1]:
      - [How you fixed the error]
      - [User feedback on the error if any]
    - [...]

5. Problem Solving:
   [Description of solved problems and ongoing troubleshooting]

6. All user messages:
    - [Detailed non tool use user message]
    - [...]

7. Pending Tasks:
   - [Task 1]
   - [Task 2]
   - [...]

8. Current Work:
   [Precise description of current work]

9. Optional Next Step:
   [Optional Next step to take]

</summary>
</example>

Please provide your summary based on the conversation so far, following
this structure and ensuring precision and thoroughness in your response.

There may be additional summarization instructions provided in the
included context. If so, remember to follow these instructions when
creating the above summary. Examples of instructions include:

<example>
## Compact Instructions
When summarizing the conversation focus on typescript code changes and
also remember the mistakes you made and how you fixed them.
</example>

<example>
# Summary instructions
When you are using compact - please focus on test output and code
changes. Include file reads verbatim.
</example>

REMINDER: Do NOT call any tools. Respond with plain text only — an
<analysis> block followed by a <summary> block. Tool calls will be
rejected and you will fail the task.