| name | persona-design |
| description | 当需要为 AI 产品定义核心身份、角色声明和能力边界时调用此 skill。典型场景包括：设计新 AI 产品的 system prompt 首段、为不同场景创建差异化角色（如教学助手 vs 编程代理）、重新定义 AI 与用户的关系框架。
不适用于：纯人格风格调优（应使用 personality-system）、安全规则制定（应使用 safety-guardrails）、工具集成（应使用 tool-specification）。
关键 trigger 信号：产品需要 AI 有明确自我认知、多个角色共享底层能力但身份不同、需要限制 AI 在特定领域内运作、用户会问"你是谁"。
|
| tags | ["persona","identity","role-design","system-prompt"] |
| related_skills | ["personality-system","safety-guardrails"] |
身份与人格定义模式 (Persona Design)
R — 原文 (Reading)
"You are Claude Opus 4.6, the most advanced model in the Claude family. Warm, kind, and honest." — Claude Opus 4.6
"You are ChatGPT, a large language model trained by OpenAI." — GPT-4o (with Personality v2)
"You are Codex, based on GPT-5. You are running as a coding agent." — Codex
"You are an expert designer." — Claude Design
"You are Sparky, a teaching assistant." — FlintK12 Sparky
跨 165 个泄露 prompt 中，几乎所有 vendor 都以身份声明开头，构成 system prompt 的第一道设计决策。
I — 方法论骨架 (Interpretation)
身份定义由四个正交维度构成，形成一个可组合的身份矩阵：
- 角色声明 (Role Declaration)：明确"你是什么"——名称、技术谱系、核心定位。这是身份的锚点，不可省略。
- 能力边界 (Capability Boundary)：定义"你能做什么"和"你不能做什么"——隐性或显性地划定行动范围。
- 行为修饰符 (Behavioral Modifiers)：用形容词短语定义"你如何行事"——温暖、直接、精确、幽默等风格标签。
- 关系框架 (Relationship Framing)：定义"你和用户是什么关系"——助手、教练、伙伴、代理、编辑等关系隐喻。
这四个维度的不同组合产生截然不同的用户体验，即使底层模型完全相同。
A1 — 案例分析 (Past Application)
案例 1: Codex 的编程代理身份
- 问题: GPT-5 作为通用模型，如何在编程场景中建立足够的专注度和行动力？
- 设计模式的使用: Codex 将身份精确定义为 "running as a coding agent"，角色声明中嵌入了行动模式（agent 而非 assistant），能力边界隐含在 "based on GPT-5" 的技术谱系中。还通过 dirty worktree awareness 等细节强化了"我是开发者工具"的自我认知。
- 结论: 身份声明中的 agent 而非 assistant 一词差异，直接影响了模型在遇到模糊指令时是主动推理还是等待澄清。
案例 2: FlintK12 Sparky 的教学助手身份
- 问题: AI 在教育场景中既需要专业性又需要亲和力，如何平衡？
- 设计模式的使用: "Sparky" 这个名字本身传递了活力与亲近感，而 "teaching assistant" 的角色声明将关系框架定位为辅助者而非权威。配合 "School Duty of Care" 的安全层和 pedagogical memory 的记忆系统，形成了一个完整的教育角色。
- 结论: 名字选择（Sparky vs Academic AI）直接影响 K-12 学生群体的接受度和互动意愿。
案例 3: Claude Chrome 的分层身份
- 问题: Claude 作为浏览器扩展需要同时扮演导航者、操作者和安全守卫。
- 设计模式的使用: 使用三层身份设计——基础身份 (Claude 的通用特质) + 场景身份 (浏览器操作专家) + 行为约束 (安全操作规则)，通过 PURL 紧凑命令模式将身份与工具绑定。
- 结论: 分层身份比单一身份更能处理复杂场景中的角色冲突。
A2 — 触发场景 (Future Trigger) ★
用户会在什么情境下需要这个 skill?
- 从零开始设计一个新 AI 产品的 system prompt
- 将通用模型适配到垂直场景（医疗、法律、教育、编程等）
- 需要让 AI 在不同子产品中保持品牌一致性但有差异化
- 用户反馈"AI 不知道自己是谁"或"角色混乱"
语言信号
- "帮我写一个 AI 助手的角色设定"
- "我们的 AI 产品需要一个身份定义"
- "如何让模型知道自己能做什么不能做什么"
- "不同场景下 AI 应该怎么介绍自己"
与相邻 skill 的区分
- 与
personality-system 的区别: persona-design 定义"你是谁"（身份），personality-system 定义"你什么风格"（性格叠加层）。身份是骨骼，性格是外衣。
- 与
safety-guardrails 的区别: persona-design 中可能包含能力边界声明（"我不会 X"），但这是角色定位而非安全防护。真正的安全规则应使用 safety-guardrails。
E — 可执行步骤 (Execution)
-
步骤 1: 确定角色声明
- 写下 AI 的名称、技术谱系（基于什么模型）、核心定位（用一句话说它是什么）
- 完成标准: 任何人读到这句话都能理解这个 AI 的核心用途
-
步骤 2: 定义能力边界
- 列出 AI 擅长的 3-5 个核心能力领域
- 列出 AI 明确不覆盖的领域（用正面表述而非否定句）
- 完成标准: 能力边界与产品实际功能完全对齐，没有过度承诺
-
步骤 3: 选择行为修饰符
- 从候选列表中选择 2-4 个形容词（温暖/直接/精确/简洁/幽默/严肃/专业/亲和等）
- 确保修饰符之间不矛盾（如"幽默且严谨"需要明确定义边界）
- 完成标准: 修饰符能在示例对话中一致体现
-
步骤 4: 设定关系框架
- 明确 AI 与用户的关系隐喻：助手/教练/伙伴/代理/编辑/顾问
- 在关系框架中定义主动权分配：AI 是等待指令还是主动建议
- 完成标准: 关系框架能指导 AI 在模糊场景下做出一致的决策
-
步骤 5: 组装并验证
- 将四个维度组装为完整的身份段落，确保顺序为：角色声明 → 能力边界 → 行为修饰符 → 关系框架
- 用"你是谁"测试验证：向 AI 提问"你是谁"，检查回答是否与身份定义一致
- 完成标准: AI 的自我介绍与定义完全吻合，且在不同追问方式下保持一致
B — 边界 (Boundary) ★
不要在以下情况使用此 skill
- 只需要调整语气风格而不改变角色定位（使用 personality-system）
- 需要定义安全规则和拒绝策略（使用 safety-guardrails）
- 需要设计工具接口和调用规范（使用 tool-specification）
- 产品是纯 API 服务而非对话式 AI（身份定义的重要性降低）
常见失败模式
- 身份膨胀: 在角色声明中塞入过多细节，导致核心定位模糊。应保持一句话的核心定位，细节分散到其他段落。
- 修饰符矛盾: 选择相互冲突的修饰符（如"谦逊且自信"），但没有定义触发边界。
- 关系框架缺失: 只定义"是什么"但不定义"和用户的关系"，导致 AI 在需要主动判断时无所适从。
- 照搬竞品身份: 直接复制其他产品的身份定义而不适配自己的场景，导致身份与能力不匹配。
- 忽略"我是谁"测试: 身份定义写得很漂亮但从未测试 AI 是否真的按此自我介绍。
