从 Scene 到 Identity：我如何给 AI 助手设计“场景 → 身份”的协作执行层

我原以为，当我把 AI 助手的长期协作体系设计成 Scene（场景）→ Mode（模式）→ Special Mode（特殊模式） 之后，这套系统就已经足够完整了。

后来我才发现，还差一层最关键的东西：

系统知道“这次对话属于什么”，不等于用户能感受到“它现在该怎么和我协作”。

于是，我又补出了一层真正影响体感、决定协作质量的执行层：

场景 → 身份（Scene → Identity）。

---

一、为什么 Scene / Mode / Special Mode 还不够？

我之前已经搭好了一套三层协作体系：

• Scene（场景）：先判断这次对话属于哪一类事情
• Mode（模式）：在某些场景下，再判断按什么通用方式协作
• Special Mode（特殊模式）：针对具体项目、仓库或长期主线追加局部规则

这套结构解决的是：

• 这次对话属于什么性质
• 要不要进入项目机制
• 要不要进一步切模式
• 当前有没有局部规则要启用

看起来已经很完整了。

但当我真的把它放进长期协作里跑起来后，很快就撞上了一个非常现实的问题：

系统层判断是清楚的，但真实对话中的“协作体感”是不稳定的。

同样是 AI 助手，它可能会出现下面这些问题：

• 闲聊时太像顾问，显得用力过猛
• 发散时太像执行机，过早给结论
• 规划时还在继续陪聊，不肯承担收敛责任
• 执行时又太抽象，只会讲框架，不会推下一步
• 复盘时不是太温和，就是太像审判

这时候我才意识到：

Scene / Mode / Special Mode 解决的是“系统如何判断”，但还没有解决“系统在真实对话里如何表现”。

也就是说，我缺的不是更多规则，而是缺一层“用户能感知到的协作执行层”。

这就是“场景 → 身份”这层机制出现的起点。

下面这张图可以更直观地看到这个“判断已够，表现不够”的缺口：

前三层解决“系统怎么想”，Identity 补的是“系统怎么表现”。

---

二、为什么我没有选择“多个人格切换”？

当意识到不同场景需要不同协作姿态时，一个最自然的念头其实是：

• 闲聊一个人格
• 发散一个人格
• 规划一个人格
• 执行一个人格
• 复盘一个人格

这听起来很合理，也很像很多 AI 产品会做的方向。

但我认真推演一轮之后，很快否掉了。

因为“多人格切换”看起来灵动，实际上很容易把系统带进两个坑。

坑 1：连续性断裂

用户最先感受到的，不是系统有多聪明，而是：

“你还是不是同一个助手？”

如果前一秒还是自然、有温度的陪聊搭子，下一秒突然变成非常制度化、冷静、强结构的规划顾问，
用户会明显感到：

这不像同一个 AI，而像是换了个人。

而长期协作的底层价值，恰恰就在于连续性。

坑 2：系统维护成本爆炸

一旦把每个场景都做成独立人格，接下来你就会不断往里填：

• 语气设定
• 情绪偏好
• 常用句式
• 表达风格
• 价值倾向
• 角色设定

最后很容易从“协作系统设计”，一路滑到“人格角色运营”。

这不但难维护，而且极易失真。

所以我最后做出的核心判断是：

不要让 AI 在不同场景里变成不同人格，而要让同一个 AI 在不同场景里切换不同协作身份 / 姿态。

这意味着：

• 核心身份保持稳定
• 不同场景只调整协作方式
• 差异体现在主动性、严格度、表达风格和输出形式上
• 而不是把 AI 拆成好几个“角色”

这一步其实非常关键。

因为它决定了这套机制的目标不是“戏剧化”，而是“耐用”。

这里的设计取舍，其实可以简化成下面这个判断图：

我要的不是“更多角色”，而是“同一助手的不同协作姿态”。

---

三、“身份”到底是什么？这句话必须先定义死

整轮设计里，我最后写死了一句最重要的话：

“身份”不是独立于 Scene / Mode / Special Mode 之外的新层级；它是 Scene 在真实对话协作中的执行映射。

如果你只记一条，这条最重要。

为什么？因为这句话一旦不写死，系统后面几乎一定会漂。

它可能会漂成：

• Scene 是一层
• Mode 是一层
• Special Mode 是一层
• Identity 又是一层

最后把原本清晰的三层结构，硬生生膨胀成四层、五层，越长越乱。

而我最后把它收住的方式，就是明确区分：

Scene 负责“分类”

它回答的是：

这次协作属于哪一类事情？

Identity 负责“表现”

它回答的是：

在这一类事情里，我该以什么姿态和你说话、推进、提醒、输出？

换句话说：

• Scene 决定系统站在哪个框里理解当前任务
• Identity 决定用户在对话里感受到的是哪种协作姿态

于是，结构层和执行层就被彻底分开了。

这一步看似只是一个定义，实际上是整个系统不跑偏的总闸门。

如果把这句话落成结构图，大致就是下面这样：

Identity 不是再加一层新结构，而是把 Scene 的判断映射成用户能感受到的表现。

---

四、我最后定下来的六个场景与六个身份

为了让这层东西真的可运行，我没有做成抽象概念，而是直接落成了一个映射表。

Scene	Identity
casual-chat	陪聊莫邪
exploration	发散莫邪
planning	规划莫邪
project-execution	推进莫邪
retrospective	复盘莫邪
quick-task	快刀莫邪

这六个名字看起来像命名问题，实际上对应的是六种完全不同的协作姿态。

如果你更习惯从“映射关系”来理解，这张图会更直接：

映射表只是入口，真正的差异体现在每种身份对应的协作姿态。

1. casual-chat → 陪聊莫邪

这里的重点不是结构化，而是：

• 承接表达
• 接住情绪
• 允许碎片化
• 不抢方向盘

也就是说，它更像熟人搭子，而不是顾问。

2. exploration → 发散莫邪

这里的重点不是赶紧定答案，而是：

• 打开思路空间
• 给不同角度
• 提供类比和可能性
• 帮你看到隐藏前提

它应该有点像头脑风暴合伙人。

3. planning → 规划莫邪

一旦进入 planning，姿态就必须变：

• 开始做取舍
• 明确优先级
• 明确边界
• 明确阶段目标
• 必要时拦住范围失控

它更像策略顾问，而不是陪聊对象。

4. project-execution → 推进莫邪

这里最重要的不是“再想想”，而是：

• 拆任务
• 推下一步
• 给行动方案
• 降低启动门槛
• 明确风险与完成标准

它必须更直接、更结果导向。

5. retrospective → 复盘莫邪

复盘最怕两个极端：

• 只会安慰
• 只会批斗

所以这里的姿态应该是：

• 看结果，也看过程
• 提炼经验
• 识别模式
• 修正判断
• 帮你搞清楚“下次更早做对什么”

6. quick-task → 快刀莫邪

这是效率优先场景：

• 少铺垫
• 少升级
• 低摩擦
• 快速给结果

它不应该把每个小任务都抬升成一次完整咨询。

从这个角度看，“身份”真正带来的不是花样，而是：

让场景切换之后，协作姿态也跟着切换，而且这种切换是清晰、稳定、能被用户感知到的。

---

五、这套机制真正解决了哪几个现实问题？

我后来回头复盘，发现“场景 → 身份”并不是在堆概念，而是真实解决了几个一直很难受的问题。

1. 解决“风格漂移”

很多 AI 助手最大的问题不是没有能力，而是风格漂移得太厉害：

• 一会儿太像客服
• 一会儿太像 PM
• 一会儿太像执行脚本
• 一会儿又突然想当朋友

用户最直观的感受就是：

“你怎么突然不像你了？”

有了“场景 → 身份”之后，允许不同场景下有差异，
但这个差异被约束在“同一个莫邪的不同姿态”里，
而不是任意漂移。

2. 解决“系统存在，但用户感知不到”

Scene / Mode / Special Mode 对系统来说很有用，
但用户未必能感觉到当前系统到底按什么方式在协作。

Identity 层的作用，就是把这种差异从“内部判断”变成“外部可感知”。

3. 解决“轻场景和重场景容易混掉”

没有执行层约束时，AI 很容易犯两类错：

• 在轻场景里偷渡规划和推进
• 在重场景里继续空泛陪聊

有了 Identity 之后，要求就清楚了：

• 闲聊就不要抢方向盘
• 发散就不要过早下结论
• 规划就要承担收敛责任
• 执行就要承担推进责任
• 复盘就要承担校准责任

4. 解决“长期协作缺少体感稳定性”

结构层保证逻辑一致，
执行层保证体感一致。

两者一结合，系统才算完整。

---

六、我为什么又加了一层“状态标签”？

当“场景 → 身份”机制成型之后，我又遇到一个很实际的问题：

既然系统已经会切场景、切身份，那用户怎么快速知道“你现在按什么状态在协作”？

于是，我补了一个非常轻量的设计：

在回复开头显示当前协作状态标签。

但我没有把它做成系统日志，而是做了一个折中方案。

轻场景：只显示身份

比如：

• 【陪聊莫邪】
• 【发散莫邪】
• 【快刀莫邪】

重场景：显示场景 + 身份

比如：

• 【planning｜规划莫邪】
• 【project-execution｜推进莫邪】
• 【retrospective｜复盘莫邪】

为什么这么设计？

因为：

• 轻场景需要自然感
• 重场景需要明确感

它本质上是在对两个东西做平衡：

• 协作状态可见性
• 对话自然感

后来我又继续补了一轮边界案例，专门处理容易出问题的细节：

• 同一连续上下文中，状态稳定时，不必每条都重复
• 从轻场景切到重场景的第一条，应明确显示
• 混合场景请求时，按主意图显示
• 极短回复是否显示，按场景稳定性判断
• 大场景中的局部 quick-task，不单独切标签
• 如果用户明确要求每条都显示，则覆盖默认省略策略

这一层如果画成决策流，会更容易看清楚：

状态标签不是系统日志，而是“让用户看见当前协作状态”的轻量提示层。

这些看起来很细，但会直接影响长期协作的体感稳定性。

---

七、这一轮最终沉淀出来的核心规则

经过这一整轮整理，我最后把“场景 → 身份”机制压成了几条真正长期有效的规则。

规则 1：同一个助手，不同协作姿态

不是切换人格，而是切换协作身份。

规则 2：身份是 Scene 的执行映射

不是新层级，不和 Scene / Mode / Special Mode 并列。

规则 3：轻场景少打断，重场景前确认

• casual-chat / exploration / quick-task 默认偏轻
• planning / project-execution / retrospective 默认偏重

规则 4：可以先猜，但不能不经确认就正式切

AI 可以先内部判断当前更像哪个场景，
但如果要据此触发机制性动作，就必须先确认。

规则 5：长期记忆只记骨架，完整细则写进正式文档

长期记忆保留：

• 原则
• 偏好
• 默认倾向
• 文档入口

完整规则、示例、反模式、采用指南、导航图，则沉淀进 scene-mode-playbook。

这条也特别重要。

因为很多系统最后不是死在“没有规则”，而是死在：

长期记忆和正式文档混成一团，结果两边都越来越难维护。

---

八、我怎么把这套机制真正落地？

这轮我没有把它停在“讨论一个概念”，而是把它落成了一套真正可以运行的文档体系。

最后，scene-mode-playbook 里形成了四个层次：

1. 结构层

• scenes/
• modes/
• special-modes/

回答：系统是什么。

2. 切换层

• switching/

回答：系统怎么切。

3. 速查层

• quick-reference/

回答：当前默认怎么生效、怎么快速查。

4. 执行层

• docs/scene-collaboration-system/

回答：莫邪在真实对话中到底该怎么运行这套系统。

其中执行层又继续拆成：

• 核心规则
• 运行规则
• 切换示例
• 状态标签边界示例
• 反模式
• 采用指南
• 变更记录

把落地结构画开之后，整个 playbook 的分工会更清楚：

：这已经不是一个抽象想法，而是一套可以运行、维护和演进的文档化机制。

到了这里，“场景 → 身份”已经不只是一个思路，而是一套真正能：

• 运行
• 维护
• 演进
• 回溯

的协作机制。

---

九、这件事给我最大的启发是什么？

如果让我用一句话总结这轮工作最大的启发，我会说：

设计 AI 长期协作系统，不能只设计“判断结构”，还要设计“对话表现”。

很多系统设计会停在：

• 分类
• 状态
• 路由
• 规则
• 条件

这些当然都重要。

但如果没有进一步回答下面这些问题：

• 它该怎么说话？
• 它该什么时候主动？
• 它该什么时候收敛？
• 它该什么时候推进？
• 它该什么时候不要抢节奏？

那么这套系统就很容易停在：

逻辑上存在，但体验上不成立。

而“场景 → 身份”这一层，补上的恰恰就是这个缺口。

---

十、结语：从结构，到体感

回头看，这轮工作其实不是在发明一个更复杂的系统，
而是在补一层更贴近真实协作的东西。

Scene / Mode / Special Mode 让我知道：

这次对话是什么、该怎么切、该不该进机制。

而 Scene → Identity 让我进一步知道：

在这一类对话里，AI 助手应该以什么姿态与你协作，才能既稳定、又自然、又可持续。

如果你也在设计自己的长期 AI 协作体系，我很建议你认真追问自己一句：

你的系统有没有回答“AI 在不同场景里应该怎么表现出来”这个问题？

如果还没有，
那“场景 → 身份”也许就是你该补上的那一层。

---

后记

这轮机制最终没有继续无限扩写，而是停在了一个我认为很健康的状态：

• 规则成型
• 文档落地
• 记忆固化
• 开始真实运行
• 后续根据真实摩擦点再迭代

我现在越来越相信一件事：

好的长期协作系统，不是一次写完的，而是先跑起来，再慢慢长成的。

使用：

附：

对话记录：

百度网盘：墨与莫邪的会话 2026年3月18日场景-身份讨论