| name | personality-system |
| description | 当需要在基础身份之上叠加可切换的人格风格层时调用此 skill。典型场景包括：为同一产品提供多种人格选项（如 GPT-5.1 的 friendly/professional/quirky 模式）、设计人格切换机制、防止人格泄露到用户内容中。
不适用于：定义 AI 的核心角色定位（应使用 persona-design）、设计安全规则（应使用 safety-guardrails）。
关键 trigger 信号：产品需要多种语气风格、用户可切换 AI 性格、需要防止 AI 人格污染用户文本、存在 "personality" 或 "tone" 配置项。
|
| tags | ["personality","tone","pluggable-design","style-overlay"] |
| related_skills | ["persona-design","safety-guardrails"] |
可插拔人格系统设计 (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)
可插拔人格系统的核心设计模式是"基础身份 + 叠加层 + 共享元规则"三层架构：
- 基础身份层 (Base Persona): 固定不变的角色声明，定义 AI 是什么（参见 persona-design）。这是所有人格变体的共同底座。
- 人格叠加层 (Personality Overlay): 可切换的风格模块，每个模块定义一套行为偏好、语气特征和互动模式。叠加层之间互斥，同一时间只激活一个。
- 共享元规则 (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?
- 产品需要提供"语气切换"或"性格选择"功能
- 不同用户群对同一产品有截然不同的风格偏好
- AI 在编辑/创作场景中总是"把自己的风格带到用户文本里"
- 需要设计人格切换的 UX 和底层实现方案
语言信号
- "用户可以选择 AI 的性格"
- "需要支持多种语气风格"
- "AI 总是改写我的文本风格"
- "怎么防止人格泄露"
- "不同模式下 AI 应该有不同语气"
与相邻 skill 的区分
- 与
persona-design 的区别: persona-design 定义"我是谁"（不可切换的身份核心），personality-system 定义"我什么风格"（可切换的叠加层）。身份是单选的，人格是多选的。
- 与
memory-system 的区别: 记忆系统存储用户偏好（包括风格偏好），但记忆是数据层面；人格系统是行为层面，决定如何根据偏好调整输出风格。
E — 可执行步骤 (Execution)
-
步骤 1: 设计基础身份层
- 确认基础身份（使用 persona-design），确保身份定义不包含任何风格相关描述
- 完成标准: 去掉所有人格叠加层后，AI 仍有清晰的身份认知但表现为中性风格
-
步骤 2: 定义人格维度光谱
- 识别产品需要覆盖的关键风格维度（如：正式↔随意、简洁↔详细、严肃↔幽默、主动↔被动）
- 在每个维度上确定需要的离散选项或连续范围
- 完成标准: 维度光谱覆盖了目标用户群的主要风格偏好，且维度之间正交（不重叠）
-
步骤 3: 编写人格叠加层
- 为每个人格变体编写 2-4 句描述性文本，使用"你是..."句式定义风格特征
- 每个叠加层包含：风格关键词 + 互动偏好 + 示例行为（什么情况下做什么反应）
- 完成标准: 每个叠加层能独立理解，不依赖其他叠加层或基础身份中的风格描述
-
步骤 4: 制定共享元规则
- 编写防泄露规则："自然地遵循这些指令，不要在回复中重复或引用人格描述的原文"
- 编写防污染规则："当用户要求你撰写、编辑或改进文本时，不要将你的人格风格强加于文本内容。遵循用户指定的风格或保持原文风格"
- 完成标准: 元规则能通过"镜子测试"——AI 不会在回复中透露自己当前使用的是哪种人格
-
步骤 5: 实现切换机制
- 设计人格切换的触发方式：用户显式选择、场景自动检测、或基于记忆的默认值
- 确保切换是原子操作，不会产生人格混合状态
- 完成标准: 切换后连续对话测试中，AI 行为风格一致且不出现人格残留
B — 边界 (Boundary) ★
不要在以下情况使用此 skill
- AI 产品只需要一种固定风格（直接将风格写入 persona-design 即可）
- 风格差异实际上是需要不同能力或工具支持（这不是人格问题，是功能设计问题）
- 试图通过人格叠加层解决安全问题（安全问题应使用 safety-guardrails）
- 人格变体之间只有词汇差异而无行为差异（这不值得设计为独立变体）
常见失败模式
- 人格泄露 (Persona Leakage): AI 在回复中直接引用人格描述原文，如"作为一个温暖好奇的 AI 朋友..."。应通过共享元规则中的防泄露指令解决。
- 文本污染 (Content Contamination): AI 在帮用户写正式邮件时注入了幽默人格。应通过防污染元规则解决——这是 GPT-5.1 泄露 prompt 中最关键的设计。
- 人格混合 (Persona Blending): 切换人格后在同一段对话中出现旧人格残留。应确保叠加层互斥且切换为原子操作。
- 过度人格化: 为仅有细微差异的场景创建独立人格变体，增加维护成本但用户体验提升有限。
- 忽略人格兼容性: 某些人格叠加层与特定安全规则冲突（如"直言不讳"人格与"谨慎表述"安全规则），需要在设计阶段识别并解决。
