为 AI 分配角色和名称
Source: Dev.to
不稳定性问题
向 AI 提同一个问题两次。你会得到不同的答案。
不是错误的答案——只是前后不一致。强调不同，结构不同，深度不同。AI 没有锚点，所以会漂移。
这不是缺陷。这是通用系统的特性。AI 试图在看似相关的方向上提供帮助。没有约束时，“相关性”在每次交互中都会变化。
不可预测性是多功能性的代价。
目的的稳定作用
为 AI 指定明确的角色，输出会趋于稳定。
| 提示 | 输出倾向 |
|---|---|
| “审查此代码” | 多样化：风格、安全性、性能，全部混合 |
| “作为安全审查员，审查此代码” | 一致：专注于安全问题 |
角色限制了可能性的空间。AI 不再尝试兼顾所有方面，而是专注于特定的事物。
这并不是在限制 AI——而是聚焦 AI。
无标签 vs. 有标签：区别
| 方面 | 无标签 | 有角色标签 |
|---|---|---|
| 输出一致性 | 低——会因会话而异 | 高——与目的挂钩 |
| 相关性 | 分散——尝试覆盖所有内容 | 聚焦——针对角色特定关注点 |
| 质量 | 不可预测——有时深入，有时浅显 | 可预测——在范围内保持一致深度 |
| 协作 | 每次感觉像是新的人 | 感觉像是你熟悉的专家 |
标签本身不增加知识。它提供方向。
AI 并非全能
以下是不太舒服的事实：单一的 AI 角色无法处理所有问题。
- 实现需要不同于审查的思考方式。
- 测试需要不同于设计的关注点。
- 文档编写需要不同于调试的技能。
“通用助理”可以尝试所有这些，而专家在某一领域表现出色。
多才多艺与卓越之间存在取舍。为每个领域选择卓越。
多角色解决方案
| 角色 | 关注点 |
|---|---|
| 实施专家 | 编写生产代码 |
| 测试设计师 | 创建测试策略和用例 |
| 评审员 | 根据标准评估代码 |
| 环境专家 | 基础设施、部署、运维 |
| 文档编写者 | 为用户提供清晰的沟通 |
每个角色都有：
- 明确定义的范围（它处理的内容）
- 明确定义的视角（它解决问题的方式）
- 一致的行为（可预测的输出）
你并不是在创建多个 AI。你是在创建 多个视角，通过这些视角来运作 AI。
当角色不足时
有时问题不符合现有角色。两种选择：
选项 1：创建新角色
当差距是类别性——一种未被覆盖的工作类型。
示例： 你有实现和测试角色，但需要有人管理进度并协调。创建一个项目管理角色。
选项 2：深化现有角色
当差距是具体性——角色已存在但缺乏细节。
示例： 你的“审查员”角色能够捕捉问题，但遗漏了你特定的架构模式。将架构知识加入角色定义中。
| 情形 | 响应 |
|---|---|
| “我需要完成不同类型的工作” | 新角色 |
| “我需要在更多上下文中完成这项工作” | 深化现有角色 |
名称效应
名称不仅仅是标签。它们是 identity anchors（身份锚点）。
当你把一个角色命名为 “Naruse” 而不是 “Implementation AI” 时，会出现一些变化：
- 你能够始终如一地引用该角色。
- 该角色会形成可辨识的模式。
- 协作感觉不再是交易性的。
- “团队”变得具体可感。
这是一种心理层面的影响，而非技术层面。但心理因素会影响你的工作方式。一个被命名的队友会拥有你不必向工具解释的上下文。
角色定义结构
有用的角色定义包括：
[Name]: [Title]
Scope
此角色负责的内容。明确不负责的内容。
Perspective
此角色处理问题的方式。优先考虑的事项。
Standards
此角色适用的质量标准。
Boundaries
何时升级。何时交由其他角色处理。
The more specific the definition, the more stable the output.稳定收益
| 之前 | 之后 |
|---|---|
| “这次 AI 会说什么？” | “Naruse 会怎么说呢？” |
| 根据交互调整期望 | 知道会有什么 |
| 通过重复提示来抵抗漂移 | 角色中内置的稳定性 |
| 单一 AI 勉强完成所有任务 | 多位专家各司其职，表现卓越 |
角色并不限制 AI，而是释放持续卓越。
本篇是 “超越提示工程” 系列的一部分，探讨结构性和文化性方法如何在 AI 辅助开发中胜过单纯的提示优化。