AI 编程助手中的两种“角色“：开发角色与业务角色

一、背景：你让 AI 写代码时，有没有觉得它"什么都懂但什么都不深入"？

​ 用 AI 编程助手写过几个项目的人，大概率有过这样的体验：让它写一个后端接口，它给你加了一堆前端友好的返回格式；让它写数据管道，它突然开始关心用户体验；让它改个权限逻辑，它把"管理员能做什么"和"代码应该怎么组织"搅在了一起。

​ 问题出在哪？不是模型能力不够，而是你没告诉它以什么身份干活 ，也没把应用里谁能做什么讲清楚。

​ 这两件事听起来像一回事，实际上是两种完全不同的"角色"。搞混了，轻则代码风格飘忽，重则权限逻辑写错。本文把这两种角色掰开讲清楚：开发角色 决定 AI 怎么写代码，业务角色决定代码里的用户能做什么。分清楚这两件事，AI 编程助手的输出质量会有明显提升。

二、基础知识：两种角色到底是什么

• 开发角色：AI 以什么身份写代码，它是后端工程师、前端工程师，还是数据工程师？
• 业务角色：应用里的用户分几类，管理员、普通用户、访客？各自能做什么？

	开发角色	业务角色
一句话定义	AI 写代码时扮演的工程师身份	应用中不同用户类型的权限与行为
典型例子	后端工程师、前端工程师、数据工程师	管理员、普通用户、学生、教师
影响什么	代码风格、设计决策、技术选型偏好	业务逻辑、权限校验、数据隔离
写在哪	系统提示词 / 角色定义区域	项目规范 / 需求文档区域
不写会怎样	AI 用"全栈通才"模式，什么都沾一点	AI 不主动考虑权限，写出"裸奔"接口

​ 用一个类比帮助理解：开发角色就像你招了一个人，他的简历上写着"5 年后端经验，擅长安全和 API 设计"，这决定了他看问题的角度和写代码的习惯。业务角色则是产品需求文档里的用户画像，管理员能看所有数据，普通用户只能看自己的，这决定了代码里要写什么样的 if 判断。

​ 两者的交汇点在于：开发角色决定 AI 用什么方式实现权限逻辑，业务角色决定权限逻辑的内容是什么。

​ 开发角色就像工程师的简历，定义身份、擅长领域和做事偏好；业务角色就像产品需求文档，定义用户类型、权限范围和行为边界。两者各自输入给 AI 编程助手，协同影响最终的代码输出。

三、技术原理：两种角色如何影响 AI 的行为

3.1 开发角色：改变 AI 的"决策倾向"

​ 不设开发角色时，AI 编程助手处于一种"通才模式"，它知道所有技术栈，但不会主动在某个维度上深入。设了之后，它的行为会出现几个明显变化：

(1) 优先级排序变了

​ 告诉 AI "你是一个注重安全性的后端工程师"，它写用户注册接口时，会主动加密码哈希、输入校验、SQL 参数化，不是因为你提了这些需求，而是角色定义改变了它评估"什么重要"的权重。

• 不写角色定义的版本：

  @app.route('/register', methods=['POST'])
  def register():
      data = request.json
      user = User(username=data['username'], password=data['password'])
      db.session.add(user)
      db.session.commit()
      return {'message': 'ok'}

• 写了"安全优先的后端工程师"之后：

  @app.route('/register', methods=['POST'])
  def register():
      data = request.get_json(silent=True)
      if not data or not data.get('username') or not data.get('password'):
          return {'error': '用户名和密码不能为空'}, 400
  
      if User.query.filter_by(username=data['username']).first():
          return {'error': '用户名已存在'}, 409
  
      hashed = generate_password_hash(data['password'])
      user = User(username=data['username'], password=hashed)
      db.session.add(user)
      db.session.commit()
      return {'message': '注册成功'}, 201

​ 同样一句"写个注册接口"，输出差别很大。第一个版本明文存密码、不做任何校验；第二个版本自动处理了输入验证、唯一性检查、密码哈希、正确的状态码。区别不是提示词里多写了几个需求点，而是角色定义让 AI 带着安全工程师的思维方式去补全了你没说的部分。

​ 同样一句"写个注册接口"，左边是通才模式的产出，能跑但漏洞百出；右边是设了开发角色之后的产出，自动补全了安全相关的细节。角色定义改变的不是 AI 的能力上限，而是它的默认行为。

(2) 技术选型有了立场

​ 没有角色定义时，AI 面对"用什么做状态管理"之类的问题倾向于给你列一堆选项。有了角色定义，比如"注重性能的前端工程师"它会给出明确偏好：优先选轻量方案，给出理由，而不是罗列 Redux、MobX、Zustand 让你自己挑。

(3) 代码审查的视角固定了

​ 让 AI 审查代码时，角色定义决定了它"从哪个角度挑毛病"。同一段代码，后端安全工程师会先看注入风险，前端工程师会先看渲染性能，数据工程师会先看幂等性。没有角色定义，它会泛泛地说"可以考虑加点错误处理"。

3.2 业务角色：驱动 AI 主动生成权限逻辑

​ 业务角色解决的是另一个问题：AI 不知道你的应用里有几类用户，也不知道谁能做什么。

​ 不写业务角色定义时，AI 默认写出的接口是不设防的，任何人可以访问任何数据。这不是 bug，是因为你没告诉它"这个系统里有不同身份的人"。

​ 一旦在项目规范里写清楚业务角色：

业务角色与权限：
- 普通用户：只能增删改查自己的数据
- 管理员：可查看和管理所有用户的数据
- 访客：只读公开数据，不能修改

​ AI 的行为会出现两个变化。

(1) 自动加权限校验

​ 写"查询待办列表"接口时，它不会返回全量数据，而是先判断当前用户身份，普通用户只返回 user_id 匹配的记录。你没有在这次对话里提"加个权限判断"，但业务角色定义让 AI 把权限校验当成了默认行为。

@app.route('/todos', methods=['GET'])
@login_required
def list_todos():
    if current_user.role == 'admin':
        todos = Todo.query.all()
    else:
        todos = Todo.query.filter_by(user_id=current_user.id).all()
    return {'todos': [t.to_dict() for t in todos]}

(2)设计数据模型时考虑隔离

​ 知道有多种用户角色后，AI 建表时会主动加 user_id 外键、加角色字段，而不是设计一个"所有人共享一张表"的结构。

3.3 两种角色对比

​ 左侧的开发角色影响 AI 怎么写代码：风格、决策、审查视角；右侧的业务角色影响代码写什么：权限校验、数据隔离、身份判断。两者通过 AI 编程助手这个中间层各自发挥作用，互不干涉但协同生效。

四、实践：怎么写好这两种角色定义

​ 知道了区别，接下来看怎么落地。不管你用的是 Claude Code、Cursor、GitHub Copilot 还是其他 AI 编程工具，原理都一样，通过系统提示词或项目级配置，把这两种角色信息传递给 AI。

4.1 开发角色的写法

​ 一个好的开发角色定义包含三个层次：身份 + 擅长领域 + 决策偏好。

• 反面例子：太泛，等于没写：

  你是一个优秀的程序员。

• 正面例子：有明确的决策指导：

  你是一个有经验的 Python 后端工程师，熟悉 Flask 生态和 REST API 设计。
  写代码时优先考虑安全性和可维护性，不要过度设计。
  对不确定的设计决策，倾向于先给出简单方案并说明权衡。

​ 第二个版本多了什么？决策规则。 "安全性优先"告诉 AI 遇到权衡时往哪边倒，"不要过度设计"约束了它的发挥边界，"先给简单方案并说明权衡"规定了它面对不确定性时的行为模式。

(1) 开发者侧重点

​ 不同项目类型的开发角色，侧重点不同：

项目类型	角色定义侧重
后端 API	安全性、接口规范、错误处理一致性
数据管道	数据质量、幂等性、容错与重试
前端应用	用户体验、可访问性、渲染性能
CLI 工具	参数设计、错误提示可读性、跨平台兼容
移动应用	离线支持、电量敏感、手势交互

4.2 业务角色的写法

​ 业务角色写法的关键是每个角色对应一组明确的能/不能：

业务角色与权限：
- 教师：创建课程、发布作业、查看所有学生提交、打分
- 学生：查看已选课程、提交作业、查看自己的成绩
- 管理员：管理用户账号、查看全校数据、系统配置
- 访客：浏览公开课程列表，不能查看课程内容

• 注意几个要点：

  • 用动词而非形容词。 "教师可以创建课程"比"教师拥有课程管理权限"更明确。AI 能直接把动词映射成 API endpoint。

  • 写清楚"不能做什么"。 很多人只写"管理员能做一切"，但不写普通用户不能做什么。"学生只能查看自己的成绩"里的"只能"两个字，直接驱动 AI 在查询时加 WHERE student_id = current_user.id。

  • 标注未来扩展。 如果某个角色是后续才实现的，标明出来。这能防止 AI 在当前阶段为一个还不存在的角色过度设计。

    • 管理员（第二阶段实现）：可查看所有用户的数据

4.3 多角色项目的组织方式

​ 当项目同时包含前端、后端、数据处理等多个模块时，一个开发角色定义就不够了，后端要强调安全性，前端要关注可访问性，数据模块要注重幂等性，塞在一起会互相干扰。

​ 解决方案是按模块拆分开发角色，每个模块给 AI 一个独立的角色上下文。以目录结构为例：

my-project/
├── 全局配置          # 项目概览、通用约定（代码风格、Git 规范）
├── backend/
│   └── 角色配置      # 后端：安全优先、API 设计规范、错误格式
├── frontend/
│   └── 角色配置      # 前端：组件规范、样式约定、可访问性
└── data-pipeline/
    └── 角色配置      # 数据：幂等性要求、重试策略、日志规范

​ AI 操作 backend/ 下的文件时，加载后端角色定义，自动切换到后端工程师视角；切到 frontend/ 时，角色就变成前端工程师了。目录结构本身就是角色切换的机制。

​ 全局配置承载通用约定和业务角色定义，每个子目录叠加自己的开发角色。AI 在不同目录间切换时，开发角色自动跟着变，业务角色始终一致，这是多模块项目管理角色的核心模式。

​ 而业务角色只需要写一份，放在全局配置里。因为不管是前端还是后端，"管理员能做什么、普通用户能做什么"的规则是一致的，前端根据角色控制页面可见性，后端根据角色做接口鉴权，数据层根据角色做查询过滤。

4.4 一个容易犯的错误：把两种角色混在一起写

​ 看这段角色定义：

你是一个后端工程师。
管理员可以查看所有用户数据。
普通用户只能操作自己的数据。
写代码时优先考虑性能。
所有接口返回 JSON 格式。

​ 五行字，开发角色和业务角色交叉出现。AI 读到这段，会把所有内容当成一种同质的"指令"来理解。结果是：它在写业务逻辑时可能忽略权限规则（因为和代码风格混在了一起，权重被稀释），在写工具函数时又突然冒出权限判断（因为分不清哪些规则在哪些场景下生效）。

​ 拆开之后：

# 开发角色
你是一个有经验的后端工程师。
写代码时优先考虑性能。
所有接口返回 JSON 格式。

# 业务角色与权限
管理员：查看和管理所有用户数据
普通用户：只能增删改查自己的数据

​ 结构清晰了，AI 就能在对的场景调用对的规则。

​ 左边混写的版本，两种角色信息交叉出现，AI 无法区分哪些规则在什么场景下生效；右边拆分后，每类信息各自成块，AI 能在正确的上下文中调用正确的规则。

五、总结

1. 两种角色解决不同问题。 开发角色回答"AI 应该用什么方式写代码"，业务角色回答"代码里的用户能做什么"。前者影响代码风格和设计决策，后者影响业务逻辑和权限设计。
2. 分开写，不要混在一起。 开发角色放在角色定义区域，业务角色放在项目规范区域。混写会稀释两者的效果，AI 分不清哪些规则在哪些场景下生效。
3. 开发角色可以按模块拆分，业务角色保持全局统一。 前端模块和后端模块需要不同的开发角色视角，但"管理员能做什么"这件事，整个项目只需要一份定义。

​ 写好角色定义之后，你会发现 AI 编程助手的输出从"正确但泛泛"变成"像一个真正理解项目的同事在写代码"。这个差距，不是靠更好的模型补上的，是靠你在提示词里多花的那几分钟。