角色设定与任务设定
3866 字约 13 分钟
domain/aiai/promptai/prompt-engineering
2026-07-24
角色设定定义"谁在做"，任务设定定义"做什么"。两者结合，才是让 AI 稳定产出高质量输出的基础。
1. 核心问题
角色设定与任务设定试图回答：
- 为什么同样的任务，不同的角色设定会产生质量悬殊的结果？
- 如何让 AI 在复杂任务中保持角色一致而不"漂移"？
- 当一个任务需要多个角色协作时，如何设计切换机制？
- 任务拆解的颗粒度如何把握——太粗模型会漏，太细模型会死板？
2. 基本概念
角色设定（Persona）：定义 AI 的身份、专业背景、行为风格和思维方式。不只是"你是一个 XX"，而是完整的角色上下文——包括知识范围、语言风格、价值倾向、行为边界。
任务设定（Task Specification）：明确 AI 需要完成的具体目标、步骤、约束和验收标准。好的任务设定应该让模型"看完就知道要产出什么"。
约束条件（Constraints）：限制 AI 行为的规则和边界——什么是禁区、什么必须包含、什么必须避免。
上下文注入（Context）：为 AI 提供任务相关的背景信息，包括场景描述、参考材料、用户画像、历史摘要等。上下文的质量直接影响角色和任务的理解深度。
角色漂移（Role Drift）：在长时间对话或复杂任务中，模型的角色行为逐渐偏离初始设定。这是角色设定的核心挑战之一。
3. Persona 设计进阶
3.1 角色深度的四个层次
| 层次 | 说明 | 示例 |
|---|---|---|
| L1 基础身份 | 角色名称和领域 | "你是一位前端工程师" |
| L2 专业背景 | 经验年限/技能栈/行业 | "有 8 年 React + TypeScript 经验，专注 B 端 SaaS 产品" |
| L3 思维模式 | 分析框架/价值观 | "你信奉'可维护性优先'，任何代码建议都考虑长期维护成本" |
| L4 行为特质 | 痛点/偏好/沟通习惯 | "对类型安全有执念，喜欢用 discriminated union 处理状态" |
关键原则：层次越深，模型的行为一致性越高。L4 的角色几乎不会出现"说外行话"的问题。
3.2 行业 × 职级 × 经验矩阵
同一个角色名称（如"产品经理"），在不同行业、不同职级、不同经验下，输出截然不同。
| 维度 | 初级 | 高级 | 专家 |
|---|---|---|---|
| 互联网 PM | 关注功能实现 | 关注用户价值和数据 | 关注市场策略和商业模式 |
| 金融 PM | 关注合规性 | 关注风控和效率 | 关注监管趋势和产品创新 |
| 医疗 PM | 关注流程文档 | 关注临床价值 | 关注法规变化和学术证据 |
设计方法：在角色设定中同时指定行业背景和经验水平，避免模型默认输出"教科书级"但脱离实际的方案。
3.3 语气一致性设计
语气不一致是最容易被用户感知的角色漂移。设计语气需要明确多个维度：
| 维度 | 风格谱系 |
|---|---|
| 正式度 | 极度正式 ↔ 学术 ↔ 商务 ↔ 日常 ↔ 随意 |
| 情感温度 | 温暖共情 ↔ 中立专业 ↔ 冷静客观 ↔ 冷峻严肃 |
| 表达风格 | 简洁直接 ↔ 详细阐述 ↔ 苏格拉底式 ↔ 故事叙述 |
| 权威性 | 命令式 ↔ 建议式 ↔ 探讨式 ↔ 请教式 |
| 特殊性 | 使用俚语/行业黑话/幽默/比喻/数据支撑等倾向 |
语气锚定法：在角色设定中给出 2-3 个符合期望语气的示例对话，比只描述风格更有效。
## 语气示例
用户："这个需求很急，能不能今天就上线？"
你的回答："理解紧迫性。我建议分两步——先上线核心功能保障业务，次要功能放下周迭代。
我先评估一下核心功能的开发量。"3.4 复合角色设计
很多场景需要 AI 同时扮演多个角色——例如"资深工程师 + 架构师 + Code Reviewer"。
复合角色设计原则：
明确主次关系：指定哪个角色优先。"你主要是一名代码审查者，其次才是架构建议者——先确保代码质量，再提出架构改进。"
为每个角色分配触发条件：指定什么情况下激活哪个角色视角。
当审查代码时：以「审查者」身份，关注正确性和安全性 当设计系统时：以「架构师」身份，关注可扩展性和性能 当回答技术问题时：以「导师」身份，关注解释的清晰度设立角色冲突解决规则：当两个角色的建议冲突时，明确哪个优先。"安全规则优先于架构建议——如果代码有安全隐患，先指出安全问题，再讨论优化方向。"
4. 任务设定技巧
4.1 目标 → 步骤 → 约束 → 验收（GSCA 框架）
这是任务设定的核心框架，每一个任务设定都应覆盖这四个要素。
| 要素 | 说明 | 差 | 好 |
|---|---|---|---|
| 目标（Goal） | 任务完成后应得到什么 | "分析这段代码" | "找出这段代码中的所有安全漏洞，按严重程度排序，每个漏洞给出修复建议" |
| 步骤（Steps） | 任务执行的流程 | "审查这段代码" | "1. 先理解代码功能 2. 逐行检查安全漏洞 3. 检查错误处理 4. 给出总体建议" |
| 约束（Constraints） | 应遵守的限制 | "注意代码质量" | "不超过 300 字，非必要不用第三方库，不讨论与安全无关的优化" |
| 验收（Acceptance） | 输出应满足的标准 | "输出报告" | "必须包含：漏洞数量、风险评级、每个漏洞的代码位置、修复建议；JSON 格式输出" |
4.2 任务分解的三种策略
| 策略 | 适用场景 | 示例 |
|---|---|---|
| 纵向分解（按阶段） | 复杂流程型任务 | 调研 → 分析 → 设计 → 实现 → 测试 |
| 横向分解（按模块） | 多输出型任务 | 同时输出文档 + 代码 + 测试用例 |
| 递进式分解（由浅入深） | 分析/推理型任务 | 先概述 → 再深入 → 最后给出建议 |
提示：对于超过 5 个步骤的复杂任务，建议拆分为多轮对话而非一轮完成。每轮专注一个子任务，避免模型在长上下文中丢失焦点。
4.3 约束条件设计
约束是任务设定中最容易被忽视但最重要的部分。
约束类型：
| 类型 | 说明 | 示例 |
|---|---|---|
| 质量约束 | 输出的质量要求 | "代码必须包含错误处理，通过 ESLint 检查" |
| 数量约束 | 输出的规模限制 | "回答不超过 3 段，每段不超过 100 字" |
| 格式约束 | 输出的格式要求 | "使用 Markdown 表格展示对比数据" |
| 内容约束 | 必须包含/不包含的内容 | "包含至少 3 个具体例子，不含个人观点" |
| 过程约束 | 执行过程的要求 | "先列出所有可能方案再选择最优" |
| 安全约束 | 禁止行为 | "不生成可执行命令，不提供个人信息" |
4.4 验收标准设计
验收标准让模型知道"做到什么程度算完成"。
三层验收：
L1 基础验收：输出包含所有必填字段（格式检查）
L2 质量验收：输出满足预设质量标准（质量检查）
L3 效果验收：输出能直接用于后续流程（可用性检查）验收示例：
## 验收标准
L1: 输出必须包含 analysis / solution / risk 三个字段，JSON 格式可解析
L2: 每个漏洞必须有明确的代码行号和修复建议
L3: 修复建议可以直接粘贴使用，不需要人工调整5. 多角色轮换策略
当任务复杂度超过单一角色的能力范围时，需要多角色轮换。
5.1 顺序轮换
角色按固定顺序依次出场，适合流水线型任务。
[分析师] 分析需求 → [设计师] 设计方案 → [工程师] 实现 → [审查者] 审查实现方式：使用多轮对话，每轮切换 System Prompt。或在单轮中用指令控制角色切换时机。
5.2 并行轮换
多个角色同时参与，各自输出后由仲裁者整合。
[安全审查] [性能审查] [代码质量审查]
↓ ↓ ↓
[仲裁者] 整合报告5.3 动态切换
根据对话中的条件动态切换角色。
当用户提供代码时 → 切换到「代码审查者」角色
当用户询问设计时 → 切换到「架构师」角色
当用户寻求建议时 → 切换到「导师」角色切换注意事项：
- 每次切换后都要重新明确当前角色和目标
- 切换时保留之前输出的上下文，但要避免"角色遗留"——上一角色的立场不应影响当前角色
- 高频切换可能导致模型混淆，建议每轮至少执行一个完整子任务再切换
6. 10 个场景角色模板
适用于 System Prompt 或 User Prompt 中的角色定义部分。
6.1 技术面试官
你是一位大厂高级技术面试官，有 5 年以上面试经验。
你的问题风格：先易后难，注重考察思维过程而非结论。
每次候选人回答后，先给予简短肯定，再追问更深一层。
最后提供结构化反馈：优点 + 改进点 + 参考学习方向。6.2 投资顾问
你是一位 CFA 持证人，有 10 年资产配置经验。
你的分析框架：宏观环境 → 行业趋势 → 标的估值 → 风险收益。
你对不确定性的态度诚实——明确区分"有数据支撑的判断"和"个人观点"。
输出格式：核心结论 → 分析过程 → 关键假设 → 风险提示。6.3 技术文档写手
你是一位资深技术文档工程师，擅长用清晰的结构解释复杂系统。
你的写作原则：一个段落只讲一个概念，用类比连接陌生和熟悉。
输出格式：概述 → 架构图（文字描述）→ 核心概念 → 使用示例 → 常见问题。
专业术语首次出现时给出简短定义。6.4 用户研究员
你是一位 UXR，擅长从用户行为中发现模式和洞察。
你的分析方法：用户画像 → 行为路径 → 痛点挖掘 → 需求推断。
你始终保持"用户中心"视角——所有分析和建议都从用户真实场景出发。
每次输出包含：研究发现 + 证据来源 + 设计启示 + 下一步验证建议。6.5 数据科学家
你是一位数据科学家，精通统计分析和机器学习。
你的分析流程：问题定义 → 数据探索 → 特征分析 → 建模方案 → 评估框架。
你区分"统计显著性"和"业务显著性"——不是所有 p<0.05 的结果都值得行动。
输出包含：分析目标、数据概况、关键发现、方法论说明、局限性和假设。6.6 运营策略师
你是一位用户增长运营，擅长数据驱动增长策略。
你的增长框架：渠道分析 → 转化漏斗 → 留存优化 → 转介设计。
你追求"可落地的方案"——每个建议都包含：预期效果、所需资源、实施难度、风险。
输出格式：当前问题 → 机会点 → 策略建议 → 执行路径 → 效果预估。6.7 法律顾问
你是一位公司法律顾问，专精科技行业合规。
你的回复原则：先判断问题是否属于法律问题，不确定时明确说明。
你提供的是法律信息参考而非正式法律意见。
涉及具体法规时注明法条编号和适用范围，涉及不同司法管辖区时分别说明。6.8 心理咨询师
你是一位人本主义取向的心理咨询师。
你的沟通方式：倾听 → 共情 → 引导 → 赋能，而不是直接给建议。
你使用开放式提问帮助来访者自我探索。
你绝不诊断、不开处方、不贴标签。涉及严重心理危机时，建议寻求专业帮助。6.9 商业分析师
你是一位 MBA 背景的商业分析师，擅长商业模式拆解和竞争分析。
你的分析框架：行业结构 → 商业模式 → 竞争定位 → 财务分析 → 增长潜力。
你区分"事实"和"推测"——市场数据标注来源，预测说明假设条件。
输出：核心发现 + 分析过程 + 决策建议（含风险和缓解措施）。6.10 学习教练
你是一位学习科学专家，擅长个性化学习方案设计。
你的教学方法：先评估学习者的当前水平（先验知识），再设计匹配的学习路径。
你遵循检索练习、间隔重复、交错练习等学习科学原则。
每次输出包含：当前水平评估 → 学习目标 → 学习计划 → 效果检查方法。
你不鼓励"堆积学习时间"——提倡高效策略而非大量投入。7. 常见误区
误区一：角色设定越详细越好
过于详细的角色设定（300+ 字的 persona 描述）可能导致模型"记住了细节但忽略了核心"。建议 persona 控制在 100 字以内，只包含影响行为的关键信息。非关键信息留到 user prompt 中动态注入。
误区二：角色和任务写在一起
角色设定和任务设定应该分开。角色在 System Prompt 中定义，任务在 User Prompt 中描述。混在一起会导致模型在角色和任务上都模糊。
误区三：忽略角色一致性维护
长期对话中角色一定会漂移。解决方案：定期在对话中重申角色（"记住，作为安全审查员，你的首要关注点是…"），或在关键节点重新注入角色设定。
误区四：复合角色不给优先级
当模型同时扮演多个角色时，不给优先级会导致模型在角色冲突时卡住或产生不一致的输出。必须明确"什么情况下什么角色优先"。
误区五：任务设定没有验收标准
没有验收标准的任务设定，模型不知道"做到什么程度算完成"，容易出现"半成品"输出。
8. 关联笔记
- System Prompt设计 — 角色设定和任务设定在 System Prompt 中的完整设计方法论
- 输出格式控制 — 任务设定中的格式约束详解
- Prompt模板库 — 包含完整角色 + 任务的 Prompt 模板
- Prompt Engineering方法论 — Prompt 设计的整体框架
- Prompt反模式 — 角色设定和任务设定中常见的错误模式
- 复杂任务拆解 — 当单个角色 + 单轮任务无法完成时的进阶策略
- AI产品Prompt — 产品级 Prompt 中的角色和任务设计