원클릭으로 Manus에서 모든 스킬 실행

memory-system

스타122

포크31

업데이트2026년 5월 4일 05:08

当需要为 AI 设计记忆存储、检索、应用和更新机制时调用此 skill。典型场景包括：设计持久化记忆架构（用户偏好、历史上下文、项目知识）、定义记忆的创建/读取/更新/删除生命周期、实现静默记忆应用（不在回复中透露记忆内容）、管理敏感记忆边界。不适用于：定义工具接口（tool-specification）、定义安全规则（safety-guardrails）、定义人格风格（personality-system）。关键 trigger 信号：AI 需要跨会话记住用户信息、记忆内容可能敏感、需要在回复中隐式应用记忆而非显式引用、用户要求"记住这个"。

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

kangarooking

kangarooking/system-prompt-skills

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

记忆与个性化架构 (Memory System)

R — 原文 (Reading)

Claude Web: userMemories 注入 + memory_user_edits tool + 选择性应用规则 + 静默归因 + 边界示例 Claude Code: File-based persistent memory with typed memories (user, feedback, project, reference) + MEMORY.md index Claude Opus 4.7: "NEVER reference sensitive memories in unrelated contexts" + bad example (proactively mentioning deceased pet) GPT-4o/GPT-4.5: bio tool for persistence + sensitive data prohibition FlintK12: Pedagogical memory (interests, preferences, grade level) + mandatory create_memory call Gemini CLI: save_memory tool + GEMINI.md files for project context

I — 方法论骨架 (Interpretation)

记忆系统的核心设计模式围绕"生命周期管理"和"边界控制"两个轴展开：

记忆生命周期 (CRUL 模型):

Create (创建): 决定何时创建记忆。FlintK12 采用"强制创建"策略（mandatory create_memory call），确保关键教学信息不被遗漏。Claude Web 采用"选择性创建"——只在用户明确表达偏好时创建。
Retrieve (检索): 在每轮对话开始时，将相关记忆注入 context window。关键设计决策是"注入多少"和"注入什么"——全部注入会消耗上下文窗口，选择性注入需要相关性判断。
Apply (应用): 静默地应用记忆内容来调整回复，而不在回复中显式引用。Claude Opus 4.7 的反面教材极为重要：如果用户曾提到宠物去世，AI 不应在无关对话中主动提及。
Update (更新): 允许用户编辑或删除已存储的记忆。Claude Web 的 memory_user_edits 工具和 Claude Code 的 typed memory 系统都支持这一能力。

类型化记忆 (Typed Memory): Claude Code 将记忆分为四类：user（用户偏好）、feedback（交互反馈）、project（项目上下文）、reference（参考文档）。不同类型有不同的存储策略、检索优先级和应用规则。

边界控制: 记忆系统最大的风险不是"记不住"，而是"在不该记住的时候记住了"或"在不该引用的时候引用了"。

A1 — 案例分析 (Past Application)

案例 1: Claude Web 的静默记忆应用

问题: 如何让 AI 利用用户记忆但不让对话变得尴尬或侵犯隐私？
设计模式的使用: Claude Web 实现了"静默归因"策略——记忆被注入 context 后，AI 在回复中不应透露"根据我的记忆"或"我记得你说过"等表述。配合边界示例（如"不要在无关上下文中提及用户已故宠物"），确保记忆应用既有效又不突兀。
结论: 记忆系统的用户体验质量取决于"隐性应用"而非"显性提及"。

案例 2: Claude Code 的文件型持久记忆

问题: 编程 agent 如何在长项目中保持上下文连贯性？
设计模式的使用: 采用文件型持久记忆，将记忆存储为 typed 文件（user/feedback/project/reference），并使用 MEMORY.md 作为索引文件。每次会话开始时通过读取 MEMORY.md 恢复项目上下文。这种方式比数据库存储更透明、更可编辑、更易于版本控制。
结论: 在专业工具场景中，记忆的透明性和可编辑性比自动化程度更重要。

案例 3: FlintK12 的教学记忆强制创建

问题: AI 如何在有限的对话轮次中积累足够的学生画像以实现个性化教学？
设计模式的使用: 实现 mandatory create_memory call——在每次教学交互中，AI 必须调用记忆创建工具记录学生的兴趣、理解水平和学习偏好。Pedagogical memory 存储兴趣、偏好、年级等信息，用于后续教学内容的个性化适配。
结论: 在高价值场景中（教育效果直接取决于个性化程度），强制创建记忆优于等待显式触发。

A2 — 触发场景 (Future Trigger) ★

用户会在什么情境下需要这个 skill?

AI 需要跨会话记住用户偏好、历史或上下文
产品需要"个性化"体验但不确定如何实现记忆架构
记忆内容可能包含敏感信息，需要设计访问控制
AI 在回复中暴露了不该暴露的记忆内容
需要决定记忆的存储方式（文件、数据库、向量存储）

语言信号

"AI 需要记住用户的偏好"
"跨会话保持上下文"
"用户说'记住这个'时该怎么处理"
"记忆中包含敏感信息"
"如何设计个性化推荐"

与相邻 skill 的区分

与 persona-design 的区别: persona-design 定义"AI 是谁"（静态身份），memory-system 定义"AI 知道用户什么"（动态信息）。身份不变，记忆不断积累。
与 safety-guardrails 的区别: safety-guardrails 约束 AI 的行为边界，memory-system 中敏感记忆的处理需要 safety-guardrails 的支持，但记忆系统本身是数据管理而非行为约束。
与 personality-system 的区别: personality-system 定义可切换的风格叠加层，memory-system 存储用户的风格偏好（如"用户喜欢简洁回复"），这些偏好可以触发特定人格变体的选择。

E — 可执行步骤 (Execution)

步骤 1: 定义记忆类型体系
- 识别产品需要记忆的信息类别：用户偏好、交互历史、项目上下文、领域知识等
- 为每个类别定义创建触发条件、存储格式和过期策略
- 完成标准: 每种记忆类型有明确的边界定义，不同类型之间不重叠
步骤 2: 设计创建机制
- 确定创建策略：强制创建（FlintK12 模式，适合高价值场景）或选择性创建（Claude Web 模式，适合通用场景）
- 定义创建触发器：显式触发（"记住这个"）+ 隐式触发（检测到偏好表达）
- 完成标准: 创建机制在 95% 的情况下能正确判断是否需要创建记忆
步骤 3: 实现静默应用规则
- 编写核心应用规则：记忆内容应隐性影响回复，不应显式引用
- 编写反面教材：列出不应在回复中出现的行为（如"根据我的记忆"、"我记得你之前说过"）
- 完成标准: 用户在对话中感受不到"被记忆"的不适感，但能体验到个性化的便利
步骤 4: 设计边界控制
- 定义敏感记忆类别（健康、财务、家庭变故等）并制定特殊处理规则
- 实现跨上下文隔离：Claude Opus 4.7 的规则"绝不在无关上下文中引用敏感记忆"
- 设计记忆编辑/删除机制，允许用户查看和管理已存储的记忆
- 完成标准: 敏感记忆不会被错误引用，用户有完全的记忆控制权
步骤 5: 选择存储策略
- 文件型存储（Claude Code 的 MEMORY.md）：适合专业工具，透明可编辑
- 结构化存储（Claude Web 的 userMemories）：适合消费产品，高性能检索
- 向量存储：适合大规模知识和语义检索场景
- 完成标准: 存储策略与产品的记忆规模、检索需求和用户期望一致

B — 边界 (Boundary) ★

不要在以下情况使用此 skill

AI 产品不需要任何跨会话持久化（纯一次性对话）
记忆需求实际上可以通过简单的 system prompt 配置解决（如"始终用中文回复"）
试图用记忆系统替代知识库或 RAG（记忆是用户相关的个性化数据，不是通用知识）
没有设计记忆删除/编辑机制就上线记忆功能（这会严重损害用户信任）

常见失败模式

记忆过度引用: AI 在回复中频繁使用"根据我的记忆"等表述，让用户感到被监视。应严格执行静默应用规则。
敏感记忆泄露: 在无关对话中主动提及用户的敏感信息。Claude Opus 4.7 明确指出这是严重错误——如果用户提到宠物去世，AI 不应在后续关于"周末计划"的对话中说"考虑到你的宠物刚去世..."。
记忆膨胀: 创建过多低价值记忆（如"用户使用了感叹号"），导致记忆存储膨胀且检索效率下降。应设置严格的创建门槛。
记忆冲突: 存储了相互矛盾的记忆（如用户在不同时间表达了不同偏好），没有设计冲突解决策略。应采用"最新优先"或"显式覆盖"策略。
忽略记忆透明性: 用户不知道 AI 记住了什么、无法查看或删除记忆。应提供记忆管理界面。

이 저장소의 다른 Skills

같은 저장소

agent-delegation

kangarooking/system-prompt-skills

当系统提示词需要设计多代理协作架构、子代理专业化分工、代理间上下文隔离与传递机制、任务生命周期管理时调用此 Skill。适用于 AI Agent 平台、多工具编排系统、代码审查流水线、跨应用协作场景等。不适用于：单代理系统（无委派需求）、简单工具调用（无子代理概念）、纯 API 编排（无 AI 决策）。当需求聚焦于"单代理内的对话路由"而非"多代理间的任务分配"时，应该用 conversation-flow 而非本 Skill。

2026-05-04122

citation-system

kangarooking/system-prompt-skills

当系统提示需要设计引用格式、信息溯源机制、来源标注系统时调用。适用于文档问答、搜索增强生成（RAG）、代码引用、浏览器辅助等需要让用户追溯信息来源的场景。不适用于纯创作类输出（如故事、诗歌），不适用于无需溯源的常识问答，也不适用于注入防御（虽然两者都涉及内容可信度）。

2026-05-04122

code-engineering

kangarooking/system-prompt-skills

当系统提示面向编程代理（Coding Agent）场景时调用。适用于构建代码编辑、文件操作、Git 工作流、自动化编程助手的系统提示。不适用于代码解释或教学场景（无文件修改），不适用于 DevOps 基础设施配置（非代码层），不适用于纯对话式代码问答（无工具调用）。

2026-05-04122

context-management

kangarooking/system-prompt-skills

当系统提示词需要设计 token 预算分配、上下文压缩策略、延迟加载机制、记忆持久化方案时调用此 Skill。适用于长对话 AI 助手、代码编辑器集成、研究型 Agent、多会话系统等需要精细管理上下文窗口的场景。不适用于：单轮交互系统（无上下文管理需求）、纯无状态 API（无对话历史）、简单的 prompt 模板设计。当需求聚焦于"如何搜索外部信息"而非"如何管理已有信息"时，应该用 search-integration 而非本 Skill。

2026-05-04122

conversation-flow

kangarooking/system-prompt-skills

当系统提示词需要定义 AI 如何分类用户意图、路由到不同处理流程、决定澄清策略和自主度级别时调用此 Skill。适用于多任务型 AI 助手、客服机器人、编程工具、研究助手等需要结构化对话管理的场景。不适用于：纯问答型系统（无任务执行）、单轮交互（无对话状态）、简单的 prompt 模板（无路由逻辑）。当需求仅涉及"输出什么格式"而非"如何决定输出什么"时，应该用 output-formatting 而非本 Skill。

2026-05-04122

injection-defense

kangarooking/system-prompt-skills

当系统提示需要防御提示注入、越狱攻击、社会工程、内容信任边界突破等安全威胁时调用此 Skill。适用于构建 AI Agent、聊天机器人、文档处理助手等任何接受外部输入的系统提示。不适用于纯内部工具调用场景或已完全隔离的沙箱环境，也不适用于 UI 布局或响应格式设计。

2026-05-04122

name	memory-system
description	当需要为 AI 设计记忆存储、检索、应用和更新机制时调用此 skill。典型场景包括：设计持久化记忆架构（用户偏好、历史上下文、项目知识）、定义记忆的创建/读取/更新/删除生命周期、实现静默记忆应用（不在回复中透露记忆内容）、管理敏感记忆边界。不适用于：定义工具接口（tool-specification）、定义安全规则（safety-guardrails）、定义人格风格（personality-system）。关键 trigger 信号：AI 需要跨会话记住用户信息、记忆内容可能敏感、需要在回复中隐式应用记忆而非显式引用、用户要求"记住这个"。
tags	["memory","personalization","persistence","context-management"]
related_skills	["persona-design","safety-guardrails"]

记忆与个性化架构 (Memory System)

R — 原文 (Reading)

Claude Web: userMemories 注入 + memory_user_edits tool + 选择性应用规则 + 静默归因 + 边界示例 Claude Code: File-based persistent memory with typed memories (user, feedback, project, reference) + MEMORY.md index Claude Opus 4.7: "NEVER reference sensitive memories in unrelated contexts" + bad example (proactively mentioning deceased pet) GPT-4o/GPT-4.5: bio tool for persistence + sensitive data prohibition FlintK12: Pedagogical memory (interests, preferences, grade level) + mandatory create_memory call Gemini CLI: save_memory tool + GEMINI.md files for project context

I — 方法论骨架 (Interpretation)

记忆系统的核心设计模式围绕"生命周期管理"和"边界控制"两个轴展开：

记忆生命周期 (CRUL 模型):

Create (创建): 决定何时创建记忆。FlintK12 采用"强制创建"策略（mandatory create_memory call），确保关键教学信息不被遗漏。Claude Web 采用"选择性创建"——只在用户明确表达偏好时创建。
Retrieve (检索): 在每轮对话开始时，将相关记忆注入 context window。关键设计决策是"注入多少"和"注入什么"——全部注入会消耗上下文窗口，选择性注入需要相关性判断。
Apply (应用): 静默地应用记忆内容来调整回复，而不在回复中显式引用。Claude Opus 4.7 的反面教材极为重要：如果用户曾提到宠物去世，AI 不应在无关对话中主动提及。
Update (更新): 允许用户编辑或删除已存储的记忆。Claude Web 的 memory_user_edits 工具和 Claude Code 的 typed memory 系统都支持这一能力。

边界控制: 记忆系统最大的风险不是"记不住"，而是"在不该记住的时候记住了"或"在不该引用的时候引用了"。

A1 — 案例分析 (Past Application)

案例 1: Claude Web 的静默记忆应用

问题: 如何让 AI 利用用户记忆但不让对话变得尴尬或侵犯隐私？
设计模式的使用: Claude Web 实现了"静默归因"策略——记忆被注入 context 后，AI 在回复中不应透露"根据我的记忆"或"我记得你说过"等表述。配合边界示例（如"不要在无关上下文中提及用户已故宠物"），确保记忆应用既有效又不突兀。
结论: 记忆系统的用户体验质量取决于"隐性应用"而非"显性提及"。

案例 2: Claude Code 的文件型持久记忆

问题: 编程 agent 如何在长项目中保持上下文连贯性？
设计模式的使用: 采用文件型持久记忆，将记忆存储为 typed 文件（user/feedback/project/reference），并使用 MEMORY.md 作为索引文件。每次会话开始时通过读取 MEMORY.md 恢复项目上下文。这种方式比数据库存储更透明、更可编辑、更易于版本控制。
结论: 在专业工具场景中，记忆的透明性和可编辑性比自动化程度更重要。

案例 3: FlintK12 的教学记忆强制创建

问题: AI 如何在有限的对话轮次中积累足够的学生画像以实现个性化教学？
设计模式的使用: 实现 mandatory create_memory call——在每次教学交互中，AI 必须调用记忆创建工具记录学生的兴趣、理解水平和学习偏好。Pedagogical memory 存储兴趣、偏好、年级等信息，用于后续教学内容的个性化适配。
结论: 在高价值场景中（教育效果直接取决于个性化程度），强制创建记忆优于等待显式触发。

A2 — 触发场景 (Future Trigger) ★

用户会在什么情境下需要这个 skill?

AI 需要跨会话记住用户偏好、历史或上下文
产品需要"个性化"体验但不确定如何实现记忆架构
记忆内容可能包含敏感信息，需要设计访问控制
AI 在回复中暴露了不该暴露的记忆内容
需要决定记忆的存储方式（文件、数据库、向量存储）

语言信号

"AI 需要记住用户的偏好"
"跨会话保持上下文"
"用户说'记住这个'时该怎么处理"
"记忆中包含敏感信息"
"如何设计个性化推荐"

与相邻 skill 的区分

与 persona-design 的区别: persona-design 定义"AI 是谁"（静态身份），memory-system 定义"AI 知道用户什么"（动态信息）。身份不变，记忆不断积累。
与 safety-guardrails 的区别: safety-guardrails 约束 AI 的行为边界，memory-system 中敏感记忆的处理需要 safety-guardrails 的支持，但记忆系统本身是数据管理而非行为约束。
与 personality-system 的区别: personality-system 定义可切换的风格叠加层，memory-system 存储用户的风格偏好（如"用户喜欢简洁回复"），这些偏好可以触发特定人格变体的选择。

E — 可执行步骤 (Execution)

步骤 1: 定义记忆类型体系
- 识别产品需要记忆的信息类别：用户偏好、交互历史、项目上下文、领域知识等
- 为每个类别定义创建触发条件、存储格式和过期策略
- 完成标准: 每种记忆类型有明确的边界定义，不同类型之间不重叠
步骤 2: 设计创建机制
- 确定创建策略：强制创建（FlintK12 模式，适合高价值场景）或选择性创建（Claude Web 模式，适合通用场景）
- 定义创建触发器：显式触发（"记住这个"）+ 隐式触发（检测到偏好表达）
- 完成标准: 创建机制在 95% 的情况下能正确判断是否需要创建记忆
步骤 3: 实现静默应用规则
- 编写核心应用规则：记忆内容应隐性影响回复，不应显式引用
- 编写反面教材：列出不应在回复中出现的行为（如"根据我的记忆"、"我记得你之前说过"）
- 完成标准: 用户在对话中感受不到"被记忆"的不适感，但能体验到个性化的便利
步骤 4: 设计边界控制
- 定义敏感记忆类别（健康、财务、家庭变故等）并制定特殊处理规则
- 实现跨上下文隔离：Claude Opus 4.7 的规则"绝不在无关上下文中引用敏感记忆"
- 设计记忆编辑/删除机制，允许用户查看和管理已存储的记忆
- 完成标准: 敏感记忆不会被错误引用，用户有完全的记忆控制权
步骤 5: 选择存储策略
- 文件型存储（Claude Code 的 MEMORY.md）：适合专业工具，透明可编辑
- 结构化存储（Claude Web 的 userMemories）：适合消费产品，高性能检索
- 向量存储：适合大规模知识和语义检索场景
- 完成标准: 存储策略与产品的记忆规模、检索需求和用户期望一致

B — 边界 (Boundary) ★

不要在以下情况使用此 skill

AI 产品不需要任何跨会话持久化（纯一次性对话）
记忆需求实际上可以通过简单的 system prompt 配置解决（如"始终用中文回复"）
试图用记忆系统替代知识库或 RAG（记忆是用户相关的个性化数据，不是通用知识）
没有设计记忆删除/编辑机制就上线记忆功能（这会严重损害用户信任）

常见失败模式

记忆过度引用: AI 在回复中频繁使用"根据我的记忆"等表述，让用户感到被监视。应严格执行静默应用规则。
敏感记忆泄露: 在无关对话中主动提及用户的敏感信息。Claude Opus 4.7 明确指出这是严重错误——如果用户提到宠物去世，AI 不应在后续关于"周末计划"的对话中说"考虑到你的宠物刚去世..."。
记忆膨胀: 创建过多低价值记忆（如"用户使用了感叹号"），导致记忆存储膨胀且检索效率下降。应设置严格的创建门槛。
记忆冲突: 存储了相互矛盾的记忆（如用户在不同时间表达了不同偏好），没有设计冲突解决策略。应采用"最新优先"或"显式覆盖"策略。
忽略记忆透明性: 用户不知道 AI 记住了什么、无法查看或删除记忆。应提供记忆管理界面。