2k tokens
context cost
the whole folder, loaded on every use
1
files
instructions only
0
copies elsewhere
how many repositories repackaged it
146
stars on the repo
on the repository, not the skill itself
Install
one command, takes just this skill from the repository
npx skills add https://github.com/kangarooking/system-prompt-skills --skill personality-system
The instruction itself
13 sections, as written by the author
可插拔人格系统设计 (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): 切换人格后在同一段对话中出现旧人格残留。应确保叠加层互斥且切换为原子操作。
- 过度人格化: 为仅有细微差异的场景创建独立人格变体,增加维护成本但用户体验提升有限。
- 忽略人格兼容性: 某些人格叠加层与特定安全规则冲突(如"直言不讳"人格与"谨慎表述"安全规则),需要在设计阶段识别并解决。