Claude Code 反馈记忆保存指南：何时记录用户纠正与确认，让 Agent 在后续对话中保持一致-平芜编程栈

文档
提示工程
人工智能

【免费下载链接】claude-code-system-prompts

All parts of Claude Code's system prompt, 27 builtin tool descriptions, sub agent prompts (Plan/Explore/Task), utility prompts (CLAUDE.md, compact, statusline, magic docs, WebFetch, Bash cmd, security review, agent creation). Updated for each Claude Code version.

项目地址：https://gitcode.com/gh_mirrors/cl/claude-code-system-prompts

点击查看免费下载

本文围绕 Claude Code 系统提示中的反馈记忆（Feedback Memory）保存指引展开：当用户纠正你的做法、或确认某个并不显而易见的方案有效时，应当在何时把这类信息写入持久化记忆，以及如何在记忆中同时保存"规则、原因、应用方式"，从而让 Agent 在未来会话中既能避免重复犯错，又能保持已被用户验证的做事方式。

一、反馈记忆是什么：从用户反馈中沉淀"做事方式"

在 Claude Code 的持久化记忆体系中，反馈记忆（Feedback Memory）是四种记忆类型之一，另外三种分别是user（用户档案）、project（项目状态）、reference（参考资料）。这一点可以追溯到 system-prompt-memory-instructions.md 中定义的记忆文件格式——每个记忆是一个文件、保存一条事实，并通过 frontmatter 声明类型：

--- name: <short-kebab-case-slug> description: <one-line summary, used to decide relevance during recall> metadata: type: user | feedback | project | reference --- <the fact; for feedback/project, follow with **Why:** and **How to apply:** lines. Link related memories with [[their-name]].>

其中feedback类型的记忆，按 system-prompt-memory-description-of-user-feedback.md 的定义，是：

"用户就你应如何开展工作给出的指导——既包括应该避免什么，也包括应该继续做什么。"

这类记忆之所以重要，是因为它让 Agent 在项目中的工作方式保持连贯、贴合用户期待，是"读"和"写"都应当高度重视的一类记忆。而本指南文档（system-prompt-feedback-memory-save-guidance.md）正是回答其中的关键问题：什么时刻应该保存一条反馈记忆。

二、什么时候保存：纠正与确认，两种触发信号

指南给出了一个明确的判断规则<when_to_save>，核心可以归纳为两类触发场景：

场景一：用户纠正你的做法（Corrections）

只要用户对你的做法表示否定，就应当触发保存判断。指南中给出的典型措辞包括：

"no not that"（不是那样）
"don't"（别这么做）
"stop doing X"（停止做某事）

这类纠正信号很容易被注意到——它们通常带有明确的否定语气，Agent 能立即感知到自己偏离了用户预期。

场景二：用户确认一个并不显而易见的方案（Confirmations）

用户明确肯定某个非显而易见的方法奏效时，同样应当保存。典型措辞包括：

"yes exactly"（对，正是这样）
"perfect, keep doing that"（完美，继续这么做）
对某个不寻常的选择没有提出异议（accepting an unusual choice without pushback）

与纠正相比，确认信号要安静得多——用户很少会用激烈的语气表扬你，更多是一句简短的肯定或默许。指南特别提醒：确认是更安静的信号，要主动留意（watch for them），不能因为用户没有反对就以为"不需要记录"。

两种信号背后的统一判断标准

无论是纠正还是确认，指南给出了统一的保存标准：

在两种情况中，保存那些对未来对话适用的内容，尤其是令人意外、或从代码中看不出来的部分。

这意味着判断的核心不是"用户说了话"这个事实本身，而是这条信息是否具备跨会话复用价值：

判断维度	说明
是否适用于未来对话	该偏好只影响当前这一次任务，还是会影响后续同类工作？
是否令人意外	与 Agent 默认行为差异越大，越值得记录
是否从代码中看不出来	若从源码、文档中即可推断，则无需占用记忆；反之必须记录

三、为什么必须保存"为什么"（Why）

指南在最后给出了一条关键要求：

Include *why* so you can judge edge cases later.

（保存时必须包含"为什么"，这样你将来才能判断边界情况。）

这一点与反馈记忆的正文结构完全呼应。按 system-prompt-feedback-memory-body-structure.md 的定义，反馈记忆的正文应遵循三段式：

以规则本身开头，然后是Why:行（用户给出的原因——通常是过去的某个事件或强烈偏好）和How to apply:行（这条指导在什么时间/什么场景生效）。

结构中明确说明：知道"为什么"让你能够判断边界情况，而不是盲目遵循规则。

为什么 Why 如此重要

判断边界情况：任何规则都有例外。"不要修改这个目录下的文件"和"不要修改这个目录下的文件，因为它是 CI 生成的"是两条不同级别的规则——后者让你在"手动重建该目录"这类边缘场景下能做出合理判断。
避免机械执行：只有规则没有原因的记忆，会导致 Agent 在规则不再适用时仍然生搬硬套，产生过度谨慎或错误坚持。
沉淀用户真实意图：用户给出的原因（过去的某次事故、某个强偏好）本身就是最有价值的上下文。

三段式结构示例

将"保存时机 + 正文结构"合在一起，一条完整的反馈记忆长这样：

--- name: avoid-formatting-vendor-directory description: Do not run formatters on the vendor directory for this project metadata: type: feedback --- Do not format files under vendor/. **Why:** A previous run reformatted generated code, producing a massive diff that delayed the release; user explicitly asked to stop. **How to apply:** When running formatters or linters with --fix, always exclude vendor/; when discussing diff size, keep vendor/ out of scope.

注意其中的description字段：它是一行摘要，用于在召回（recall）阶段判断相关性——这正是 system-prompt-memory-instructions.md 中定义的记忆 frontmatter 约定。

四、不只记录失败：成功经验同样重要

保存反馈记忆时存在一个常见的偏斜：只记录纠正、只记录失败。但按 system-prompt-memory-description-of-user-feedback.md 的明确说明，这样做是有害的：

要从失败和成功中都记录：如果你只保存纠正，你会避免过去的错误，但会逐渐偏离用户已经验证过的方法，并且可能变得过度谨慎。

这段话点出了两条核心原理：

避免"过度谨慎漂移"：只记错误会让 Agent 越来越倾向于回避一切曾经被否定的做法，最终变得畏首畏尾、失去效率。
锚定已验证路径：用户确认过的方法（哪怕只是"accepting an unusual choice without pushback"）是宝贵的行为锚点，让 Agent 在后续对话中持续保持用户认可的工作方式。

这也再次印证了本指南强调"确认信号虽然安静、但要主动留意"的原因——成功经验恰恰是最容易被忽略的反馈记忆来源。

五、保存前的检查：与团队记忆的一致性

反馈记忆还有一个保存前必须执行的冲突检查。按 system-prompt-memory-description-of-user-feedback.md 的要求：

保存一条私人反馈记忆之前，检查它是否与团队反馈记忆（team feedback memory）相矛盾——如果矛盾，要么不保存，要么明确注明这个覆盖（override）。

这意味着当用户给出的指导与团队层面的既有约定冲突时，Agent 不能无脑写入个人记忆，而必须：

判断冲突是否成立；
若冲突，选择"不保存"或"明确标注这是一次覆盖"；
若保存，必须在记忆内容中显式说明该规则对团队记忆的覆盖关系，避免后续会话在两条矛盾规则间摇摆。

六、保存后的落盘：索引指针与持久化边界

保存反馈记忆不只写一个.md文件，还需要完成索引登记。按 system-prompt-memory-index-pointer-instructions.md 的规定：

第 2 步—— 在索引位置中添加指向该文件的指针。索引文件是一个索引，而不是记忆本身——每条目应为一行、约 150 字符以内：- Title — one-line hook。它没有 frontmatter。永远不要把记忆内容直接写进索引文件。

典型形态如下：

- avoid-formatting-vendor-directory — skip vendor/ in formatters; user requested after big-diff incident

同时要理解反馈记忆的持久化边界。按 system-prompt-memory-persistence-scope.md 的说明：

记忆是你在当前会话中协助用户时可用的多种持久化机制之一。区别通常在于：记忆可以被未来的会话召回，因此不应用来持久化仅在当前会话内有用的信息。

这给出了一条反向过滤条件：判断是否保存时，如果这条信息只对"当下这一次对话"有意义（比如某个一次性任务的临时约定），它就不应进入反馈记忆，而应留在会话上下文或其他短期机制中。

七、把整套规则串起来：保存决策流程

综合本指南及其关联的反馈记忆体系，一条反馈记忆从识别到落盘，遵循如下决策流程：

识别触发信号：用户纠正（"don't"、"stop doing X"）或确认（"yes exactly"、"keep doing that"、默许不寻常选择）；
评估复用价值：是否适用于未来对话？是否令人意外？是否从代码中看不出来？——三者满足其一或更多，值得保存；
检查冲突：与团队反馈记忆是否矛盾？矛盾则不保存或显式标注 override；
组织正文：先写规则，再写Why:（用户给出的原因），最后写How to apply:（何时何地生效），必要时用[[their-name]]链接相关记忆；
写入索引：在索引文件中追加一行约 150 字符的指针条目，保持索引与记忆内容分离；
等待召回：未来会话通过description判断相关性后召回，并在应用时结合 Why 判断边界情况。

这套机制让 Claude Code 的 Agent 在跨会话工作中保持行为一致性：既不会重蹈覆辙，也不会丢掉用户已经认可的成功路径，更不会因为"只知道规则、不知道为什么"而在边界场景下机械行事。

八、延伸阅读

反馈记忆只是 Claude Code 持久化记忆体系的一环，围绕本主题可继续深入阅读：

system-prompt-memory-instructions.md：记忆文件格式、类型、索引与陈旧记忆处理的整体约定；
system-prompt-feedback-memory-body-structure.md：反馈记忆正文的 Why / How to apply 结构规范；
system-prompt-memory-description-of-user-feedback.md：反馈记忆类型定义、失败与成功并重原则、团队记忆冲突检查；
system-prompt-memory-save-exclusions.md：即使被要求也不应写入记忆的内容类别；
system-prompt-project-memory-save-guidance.md：另一类记忆（项目状态记忆）的保存时机与绝对日期约定；
system-prompt-memory-persistence-scope.md：记忆与其他持久化机制的边界。