企业 AI 项目 Wiki · 需求与业务场景

用户角色

也常写作User role · 业务角色 · 使用者角色 · 参与角色

定义

用户角色是按共同目标、责任、任务和使用上下文，对直接使用服务或参与其业务结果的一类人所作的稳定抽象。它说明这类参与者为什么进入场景、需要知道和完成什么、能够作出哪些业务决定、与谁交接以及受哪些条件限制，而不是用个人姓名或系统账号代替需求。

用户角色描述一类人的业务责任，不是账号标签

同一个系统里的“用户”并不是一种足够的需求。提交申请的人、核对资料的人、批准决定的人、处理异常的人和只接收结果的人，目标、所需信息、决定权限和错误后果都不同。把他们都写成“普通用户”，页面、流程、通知、权限和验收会在实现阶段才被迫猜测。

角色是对重复业务责任的抽象。多人可以承担同一角色，一个人也可以在不同场景或时段承担多个角色。例如门店经理既可以作为补货申请人，也可以在金额条件允许时作为批准人；系统必须根据当前业务对象和条件判断，而不能只凭姓名推断。

角色要从真实工作中形成，而不是从现有组织架构或系统权限表直接复制。岗位相同的人可能因地区、资质、代理状态或工作方式承担不同任务；岗位不同的人也可能完成同一类任务。现有账号配置只能说明今天怎样授权，不能单独证明目标服务应该怎样设计。

一份可用于项目的用户角色记录包含什么

角色名称只是入口，真正有用的是它背后的工作方式。同样叫“运营人员”的人，可能一个只查看结果，另一个却能修改资料和批准发布。角色记录要把任务、责任、所需信息和限制连起来，项目才能据此设计功能而不是猜岗位。

稳定名称与适用上下文

使用业务人员能识别的责任命名，例如“采购申请人”或“质量异常复核人”，并说明适用的组织、地区、产品、渠道或场景；避免“用户 A”“高级用户”这类无业务含义的名称。

目标与成功结果

说明角色进入服务要取得的业务结果，以及怎样知道责任已经完成。目标不是“使用系统”，而是提交合格申请、作出有依据决定或恢复受阻任务。

职责与不得承担的职责

列出角色负责发起、核对、决定、执行、通知、复核或接手中的哪些部分，并明确因职责分离、资质或风险不能同时承担什么。

主要任务与触发

列出角色参与的场景、开始工作的事件、频率、批量和时限。只保留影响需求与运营的任务，不把每次点击变成独立职责。

所需信息与产生记录

说明工作前需要看到哪些业务对象、来源、历史和决定依据，工作后新增或改变什么记录；同时标明敏感程度、最小可见范围和保留要求。

业务决定与授权边界

区分查看、建议、修改、提交、批准、撤销和例外处理，记录金额、地区、对象状态、时间窗口或双人复核等条件。角色说明授权语义，权限系统负责实施。

交接与协作

说明从谁接收任务、把什么结果交给谁、什么情况转人工或升级，以及代理、缺席、轮班和跨组织协作怎样处理。

能力、环境与辅助需求

记录领域知识、培训、语言、数字技能、使用设备、现场条件、网络限制和无障碍需要。不能假设同一职责的人都以相同方式操作。

风险与受影响范围

说明误操作、漏处理、偏见、越权或延迟会影响谁和什么，角色是否处理高金额、敏感数据、不可逆动作或受监管决定。

依据、负责人和版本

保留访谈、观察、制度、工单与日志等来源，指定业务确认人、适用日期和版本；组织、流程或系统变化后能够判断是否需要重验。

怎样从真实用户和工作中识别角色

组织架构图能告诉我们谁属于哪个部门，却不一定能说明谁实际完成哪一步工作。识别角色时，要看人怎样接收任务、作出判断、处理例外和承担结果；正式岗位、外包人员与临时代理人都可能在同一流程中扮演不同角色。

从任务和结果开始
先列出服务要支持的真实任务、触发和结束状态，再寻找实际完成、支持或受这些任务影响的人；不要先决定角色名称再寻找证据。
覆盖前台、后台和非数字参与者
研究直接操作界面的人，也研究电话、邮件、线下办理、案例处理、监督、运营和第三方人员。只看屏幕用户会遗漏决定和接手责任。
观察而不只询问
结合访谈、现场或远程观察、工单、表单、日志、制度和培训资料，比较正式规则、实际做法和临时变通；个人偏好不能自动成为角色特征。
按责任聚类
把具有相同目标、任务、决定、信息与交接的人归为候选角色。部门、职级或年龄只有在确实改变使用需要和责任时才用于区分。
寻找关键差异
检查金额权限、资质、地区、设备、批量、时间压力、辅助需要、代理状态和错误影响；差异会改变流程或验收时才拆分角色或子角色。
用业务场景回放
让候选角色逐一走过正常、资料不足、异常、越权和接手路径，确认谁在每个节点知道什么、决定什么、留下什么证据。
与真实参与者共同确认
由实际使用者、业务负责人、服务支持、技术、安全和无障碍相关人员按风险复核，记录分歧、少数场景和不能代表的群体。
建立可维护登记
给角色稳定编号，关联场景、需求、权限、培训、测试与负责人；变化时修改角色基线并评估下游影响，而不是静默覆盖旧定义。

什么时候应该拆分或合并用户角色

角色拆得太粗，会把高权限和低权限用户混在一起；拆得太细，又会为每个人造出一套无法维护的设计。判断是否拆分，重点不是职位名称是否不同，而是任务、信息、权限、风险或成功标准是否真的需要不同处理。

目标是否不同？
一个角色追求快速提交，另一个角色负责独立判断，即使使用同一页面也不应合并。
核对：目标、成功结果与承担后果。
业务责任或决定是否不同？
查看与批准、建议与执行、创建与复核通常需要明确区分，尤其涉及职责分离时。
核对：RACI、授权制度、审批与审计记录。
任务路径和信息是否实质不同？
只差部门名称未必需要拆分；若输入、规则、异常、设备或交接改变，则应形成子角色或独立角色。
核对：场景、字段、规则和接口差异。
能力与使用条件是否改变设计？
低数字技能、辅助技术、现场手套操作、移动网络或特定语言需求会改变交互和支持，不能用平均用户掩盖。
核对：用户研究、设备与无障碍测试。
是否只是权限级别不同？
若工作目标和任务相同，只因临时额度不同，可在授权条件中表达；不要为每个权限组合复制一个业务角色。
核对：角色定义与权限矩阵是否能分离维护。
样本是否足以支持区分？
不能根据一个人的习惯创造角色。证据不足时先登记假设和研究问题，再用更多用户与运行记录验证。
核对：研究范围、反例和未覆盖群体。

一个用户角色记录可以长什么样

下面继续使用独立构造、与任何客户无关的采购情境，让一条角色记录从名称读到任务、权限和责任。实际项目不必照抄字段，但应让接手者能够理解这个角色为什么存在，以及系统应怎样支持他。

UR-03：采购申请人

为已确认的业务需要准备并提交可核对的采购申请，跟进补充和最终结果；不负责批准自己的申请，也不直接修改预算余额。

适用人员和上下文

可能由不同部门员工承担，通过桌面或移动端处理本部门申请；具体地区、采购类别、代理提交和无障碍需要仍须调研。

主要任务

选择成本中心，说明用途与期望日期，提供供应商和报价资料，确认声明，提交后响应补充要求、撤回未处理申请并接收结果。

需要的信息

可查看适用于自己的采购规则摘要、必填资料、本部门可用成本中心、申请状态和退回理由，但不默认查看其他人的敏感申请或审批意见。

决定与限制

可以保存草稿、提交和在规定状态下撤回；不能批准本人申请、绕过必填证明或把 AI 建议当作采购授权。代理提交必须记录实际操作者和代表对象。

交接与异常

完整申请交给采购负责人；资料不足时接回补充；身份、成本中心或规则不可确认时停止提交并进入支持流程，保留已有内容和错误编号。

验证依据

项目应再用实际申请人访谈、代表性申请、支持工单、权限负面测试和无障碍测试确认此角色，不能直接把这组非客户资料写进验收。

用户角色怎样映射到账号与权限，而不与它们混为一谈

一个人可以承担多个业务角色，一个角色也可能由多人轮流承担；账号只是识别访问者，权限则决定此刻可以做什么。把三者直接画等号，人员调岗或临时代理时就容易留下过度授权，也会让业务责任失去对应的人。

角色先说明业务语义

先定义谁基于什么责任需要查看或执行什么，再把业务对象、动作和条件转换成授权规则。直接从菜单权限反推角色，会继承历史错误和过度授权。

身份确认谁在操作

账号、单点登录身份、服务账号和外部主体用于识别操作者；一个身份可以在不同组织或时间承担不同业务角色，角色也可以被多人承担。

权限决定当前允许什么

RBAC 可把权限分配给安全角色，但实际授权还可能依赖对象归属、金额、地区、状态、时间、设备风险或临时委托。业务角色不等于一个永久权限包。

职责分离需要组合检查

申请与批准、开发与生产发布、制作与复核等冲突责任要检查同一人的角色组合、当前业务对象和历史动作，而不是只禁止两个菜单同时出现。

代理和紧急权限必须留痕

替班、委托和紧急访问要有授权人、理由、范围、开始结束时间、再次确认和审计，不应悄悄改变基础角色定义。

验证允许与拒绝两面

每个关键角色既测试应能完成的场景，也测试不应查看、修改、批准或越界处理的对象，并核对日志能否还原身份、角色、条件和决定。

用户角色在范围、设计、测试和运营中怎样使用

角色不是需求阶段写完就归档的人物简介。范围要靠它确定服务谁，界面和流程要适应它的工作，测试要由代表性角色完成任务，上线后还要按角色观察错误、接手和支持需求。角色定义一旦脱离这些用途，就只剩标签。

项目范围

明确本期支持和不支持哪些角色、组织、地区、渠道和代理方式，并把所需研究、迁移、培训、权限和支持工作纳入范围。

需求与优先级

把角色目标、任务、信息、决定和异常连接到业务场景与需求；不能只按声音最大的管理者或最熟悉技术的用户排序。

交互与内容

依据角色当下任务、术语、频率、设备、压力和辅助需要安排信息与操作；同一业务对象可为不同角色提供不同视图，但核心状态应一致。

数据和权限

建立角色—场景—业务对象—动作—条件矩阵，确认字段可见、批量范围、导出、审批、删除、委托和审计要求。

测试与验收

按角色准备正常、异常、无权、跨角色交接和无障碍场景，指定代表参与者与业务确认人；一个管理员账号走通全部流程不能证明角色设计正确。

上线与培训

为各角色准备必要培训、操作说明、支持入口和变更通知，确认账号开通、权限审批、代理与离岗回收在正式使用前完成。

运营与维护

按角色观察任务完成、错误、升级、放弃和支持请求，定期核对组织变化、权限漂移和实际工作是否已偏离角色基线。

企业 AI 项目为什么要把不同人类角色分开

AI 输出会被谁看到、谁能让它执行动作、谁负责复核，决定了同一项能力的实际风险。直接使用者、被结果影响的人、审批者和运营人员可能不是同一批人；如果只写一个笼统的“用户”，重要责任就会落在空白处。

直接使用 AI 的人

他可能只是偶尔问一个问题，也可能每天把 AI 结果带进正式流程。系统需要让他看懂 AI 能做什么、回答依据在哪里、哪些内容必须核对，以及发现错误后怎样报告。不能假定每个人都会写提示词，再把难用或误用归因于用户不够熟练。

输出复核者

检查事实、完整性、格式或专业判断的人，要有原始资料、引用、模型与知识版本、修改和拒绝记录；复核责任不能只写成“人工在环”。

业务批准者

对付款、资格、质量、发布或其他高影响结果作最终决定的人，需要独立于模型建议的授权依据、拒绝和覆盖能力，并承担明确决定责任。

人工接手者

在资料不足、模型不确定、越权、冲突或工具失败时接管，需要收到足够上下文、已执行动作和停止原因，而不是从头猜测。

知识与规则负责人

确认资料是否可用、更新、撤回和适用于哪些人，处理权限传播、冲突来源与过期规则；这与日常提问者不是同一责任。

系统运营与风险监督者

监测质量、成本、延迟、滥用、漂移、事件和申诉，具有暂停、降级和恢复职责；开发者不应自动成为所有生产风险的唯一决定人。

被影响但不直接操作的人

AI 输出可能影响求职者、客户、供应商或员工。项目要识别他们收到解释、纠正、申诉或人工复核的路径，不能因没有账号而从角色分析中消失。

自动化主体与第三方系统

API、机器人或其他系统可以在 UML 中作为 Actor，但需求仍要指定背后的业务负责人、调用身份、权限、限额、失败责任和审计；不能把责任归给“AI 角色”。

用户角色容易与什么混淆

岗位、人物画像、账号、权限组和相关方都可能与某类人有关，但各自服务于不同判断。用户角色关心的是一类人在业务任务中的责任和行为；把其他概念直接拿来代替，会让设计、授权或沟通缺少必要的一层。

相关概念	与用户角色的区别
真实用户或个人	个人具有具体身份、经历、能力和多个责任；用户角色是为项目抽象出的共同责任。同一个人可承担多个角色，角色也不应暴露个人资料。
岗位或职称	岗位属于组织设计和劳动分工；用户角色围绕服务中的目标和任务。一个岗位可承担多个用户角色，同一角色也可能跨岗位或外部组织。
用户画像（Persona）	画像以研究证据表达一类用户的行为、需要、环境和差异，常用于建立同理心和设计判断；角色更集中于特定业务上下文中的责任、任务、决定与交接。
用户群或客户分群	用户群可按人口、市场、合同或行为特征划分；只有这些差异实质改变任务、责任或使用条件时，才应形成不同角色。
UML Actor	Actor 是某个系统边界之外与系统交互的角色，可由人、组织或系统承担；用户角色主要解释人类参与者的业务目标和责任，可以在系统边界确定前使用。
账号	账号是可识别的访问主体。账号本身不说明业务目标，一个账号可能获得多个角色，临时代理和服务账号还需要额外治理。
权限角色或 RBAC 角色	RBAC 角色把权限与组织职能关联以实施访问控制；业务用户角色是需求输入，两者可能映射但不必一一对应，也不能用业务名称证明权限最小化。
项目团队角色	产品负责人、项目经理、开发、测试等说明谁建设和治理项目；用户角色说明谁使用或参与目标服务。一个人可能同时处于两类角色，但责任基线不同。
相关方	相关方包括能影响项目或受项目影响的个人和组织，其中许多人不直接参与服务任务；用户角色只覆盖与使用和业务结果相关的一类参与责任。

依据与适用边界

本文解释需求、服务设计和企业 AI 项目中的用户角色：一类参与者在特定业务上下文中承担的目标、责任和任务。它不是某个真实个人、账号、用户名、组织岗位名称、用户画像、客户分群、UML Actor、权限组、项目团队岗位或所有相关方的统称。角色可以作为访问控制设计的输入，但本文不替代身份治理、RBAC 模型、安全评审、劳动分工或组织授权文件。实际角色、代理规则、职责分离和权限必须由相应业务与安全负责人确认。