personality-system

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)

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

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): 切换人格后在同一段对话中出现旧人格残留。应确保叠加层互斥且切换为原子操作。
• 过度人格化: 为仅有细微差异的场景创建独立人格变体，增加维护成本但用户体验提升有限。
• 忽略人格兼容性: 某些人格叠加层与特定安全规则冲突（如"直言不讳"人格与"谨慎表述"安全规则），需要在设计阶段识别并解决。