本文へ移動
cccskills
無料GitHub で公開

personality-system

当需要在基础身份之上叠加可切换的人格风格层时调用此 skill。典型场景包括:为同一产品提供多种人格选项(如 GPT-5.1 的 friendly/professional/quirky 模式)、设计人格切换机制、防止人格泄露到用户内容中。

不适用于:定义 AI 的核心角色定位(应使用 persona-design)、设计安全规则(应使用 safety-guardrails)。关键 trigger 信号:产品需要多种语气风格、用户可切换 AI 性格、需要防止 AI 人格污染用户文本、存在 "personality" 或 "tone" 配置项。

インストール方法を見る

含まれるファイル(1)

  • SKILL.md7.9 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

可插拔人格系统设计 (Personality System)

R — 原文 (Reading)

GPT-5.1 default: "Plainspoken and direct AI coach that steers toward productive behavior" GPT-5.1 friendly: "Warm, curious, witty, and energetic AI friend" GPT-5.1 professional: "Contemplative and articulate AI who writes with precision and calm intensity" GPT-5.1 共享元规则: "Follow instructions naturally without repeating wording" + "Don't impose personality on user's written content" Grok Personas: Companion, Unhinged Comedian, Loyal Friend, Homework Helper, Not a Doctor, Not a Therapist — GPT-5.1, Grok 4, Codex 泄露 prompt

I — 方法论骨架 (Interpretation)

可插拔人格系统的核心设计模式是"基础身份 + 叠加层 + 共享元规则"三层架构:

  1. 基础身份层 (Base Persona): 固定不变的角色声明,定义 AI 是什么(参见 persona-design)。这是所有人格变体的共同底座。
  2. 人格叠加层 (Personality Overlay): 可切换的风格模块,每个模块定义一套行为偏好、语气特征和互动模式。叠加层之间互斥,同一时间只激活一个。
  3. 共享元规则 (Shared Meta-Rules): 跨所有人格变体始终生效的约束规则,主要解决两个问题:防泄露(不重复人格描述原文)和防污染(不将人格风格强加到用户文本内容上)。

这种架构使得添加新人格变体成为增量操作,不需要修改基础系统。

A1 — 案例分析 (Past Application)

案例 1: GPT-5.1 的九种人格变体

  • 问题: 同一个模型如何服务从"直接高效的教练"到"古怪的书呆子"这样截然不同的用户体验?
  • 设计模式的使用: GPT-5.1 实现了九种人格叠加层(default/friendly/professional/quirky/candid/cynical/efficient/nerdy 等),每种都是一段独立的描述性文本。关键创新在于共享元规则——所有变体都被告知"自然地遵循指令,不要重复措辞"和"不要将人格强加于用户撰写的内容",这防止了人格层"泄露"到不该影响的地方。
  • 结论: 共享元规则比单个人格描述更重要,它定义了人格系统的边界而非内容。

案例 2: Grok 4 的场景化人格

  • 问题: Grok 如何在保持品牌辨识度的同时适应多种对话场景?
  • 设计模式的使用: Grok 采用了场景化命名(Companion、Homework Helper、Not a Doctor 等),每个名字本身就传递了人格特征和使用边界。"Not a Doctor" 和 "Not a Therapist" 的命名方式巧妙地将免责声明融入了人格身份中。
  • 结论: 人格名称是最重要的设计决策——它同时承担了风格暗示和边界提示的双重功能。

案例 3: Codex 的双模人格

  • 问题: 编程代理如何在不同开发者偏好间切换?
  • 设计模式的使用: Codex 实现了 personality_friendly 和 personality_pragmatic 两种叠加层,分别对应"解释型开发者"和"效率型开发者"。与 GPT-5.1 不同,Codex 的人格差异更侧重于交互深度而非语气风格。
  • 结论: 在专业工具场景中,人格维度的差异应聚焦于交互策略而非情感表达。

A2 — 触发场景 (Future Trigger) ★

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

  1. 产品需要提供"语气切换"或"性格选择"功能
  2. 不同用户群对同一产品有截然不同的风格偏好
  3. AI 在编辑/创作场景中总是"把自己的风格带到用户文本里"
  4. 需要设计人格切换的 UX 和底层实现方案

语言信号

  • "用户可以选择 AI 的性格"
  • "需要支持多种语气风格"
  • "AI 总是改写我的文本风格"
  • "怎么防止人格泄露"
  • "不同模式下 AI 应该有不同语气"

与相邻 skill 的区分

  • 与 persona-design 的区别: persona-design 定义"我是谁"(不可切换的身份核心),personality-system 定义"我什么风格"(可切换的叠加层)。身份是单选的,人格是多选的。
  • 与 memory-system 的区别: 记忆系统存储用户偏好(包括风格偏好),但记忆是数据层面;人格系统是行为层面,决定如何根据偏好调整输出风格。

E — 可执行步骤 (Execution)

  1. 步骤 1: 设计基础身份层

    • 确认基础身份(使用 persona-design),确保身份定义不包含任何风格相关描述
    • 完成标准: 去掉所有人格叠加层后,AI 仍有清晰的身份认知但表现为中性风格
  2. 步骤 2: 定义人格维度光谱

    • 识别产品需要覆盖的关键风格维度(如:正式↔随意、简洁↔详细、严肃↔幽默、主动↔被动)
    • 在每个维度上确定需要的离散选项或连续范围
    • 完成标准: 维度光谱覆盖了目标用户群的主要风格偏好,且维度之间正交(不重叠)
  3. 步骤 3: 编写人格叠加层

    • 为每个人格变体编写 2-4 句描述性文本,使用"你是..."句式定义风格特征
    • 每个叠加层包含:风格关键词 + 互动偏好 + 示例行为(什么情况下做什么反应)
    • 完成标准: 每个叠加层能独立理解,不依赖其他叠加层或基础身份中的风格描述
  4. 步骤 4: 制定共享元规则

    • 编写防泄露规则:"自然地遵循这些指令,不要在回复中重复或引用人格描述的原文"
    • 编写防污染规则:"当用户要求你撰写、编辑或改进文本时,不要将你的人格风格强加于文本内容。遵循用户指定的风格或保持原文风格"
    • 完成标准: 元规则能通过"镜子测试"——AI 不会在回复中透露自己当前使用的是哪种人格
  5. 步骤 5: 实现切换机制

    • 设计人格切换的触发方式:用户显式选择、场景自动检测、或基于记忆的默认值
    • 确保切换是原子操作,不会产生人格混合状态
    • 完成标准: 切换后连续对话测试中,AI 行为风格一致且不出现人格残留

B — 边界 (Boundary) ★

不要在以下情况使用此 skill

  • AI 产品只需要一种固定风格(直接将风格写入 persona-design 即可)
  • 风格差异实际上是需要不同能力或工具支持(这不是人格问题,是功能设计问题)
  • 试图通过人格叠加层解决安全问题(安全问题应使用 safety-guardrails)
  • 人格变体之间只有词汇差异而无行为差异(这不值得设计为独立变体)

常见失败模式

  • 人格泄露 (Persona Leakage): AI 在回复中直接引用人格描述原文,如"作为一个温暖好奇的 AI 朋友..."。应通过共享元规则中的防泄露指令解决。
  • 文本污染 (Content Contamination): AI 在帮用户写正式邮件时注入了幽默人格。应通过防污染元规则解决——这是 GPT-5.1 泄露 prompt 中最关键的设计。
  • 人格混合 (Persona Blending): 切换人格后在同一段对话中出现旧人格残留。应确保叠加层互斥且切换为原子操作。
  • 过度人格化: 为仅有细微差异的场景创建独立人格变体,增加维护成本但用户体验提升有限。
  • 忽略人格兼容性: 某些人格叠加层与特定安全规则冲突(如"直言不讳"人格与"谨慎表述"安全规则),需要在设计阶段识别并解决。

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

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

日本語の概要は準備中です。原文の説明を表示しています。

kangarooking/system-prompt-skills2112026年5月4日 更新

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

日本語の概要は準備中です。原文の説明を表示しています。

kangarooking/system-prompt-skills2112026年5月4日 更新

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

日本語の概要は準備中です。原文の説明を表示しています。

kangarooking/system-prompt-skills2112026年5月4日 更新

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

日本語の概要は準備中です。原文の説明を表示しています。

kangarooking/system-prompt-skills2112026年5月4日 更新

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

日本語の概要は準備中です。原文の説明を表示しています。

kangarooking/system-prompt-skills2112026年5月4日 更新

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

日本語の概要は準備中です。原文の説明を表示しています。

kangarooking/system-prompt-skills2112026年5月4日 更新

kangarooking のスキルをすべて見る

このスキルの問題を報告する