context-mode实战：从设计到落地的模式切换与上下文管理

1. 从“上下文模式”说起：一个被低估的工程概念

第一次看到“context-mode”这个词，很多人会下意识觉得它是个抽象到没法落地的东西。上下文嘛，听起来像是哲学问题；模式嘛，又像是设计模式那一套。但如果你真正在工程一线待过，就会发现这个词其实非常具体——它描述的是一套系统在“当前处于什么状态、该以什么方式响应”这件事上的整体决策逻辑。

我最早接触这个概念是在做对话系统的时候。当时团队里有个争论：用户发来一句“帮我查一下明天的天气”，系统到底应该直接调天气接口，还是先反问“您要查哪个城市”？这个看似简单的选择，背后其实就是context-mode在起作用。如果系统判断当前处于“信息不足”模式，它就应该追问；如果判断处于“快速响应”模式，它就应该基于历史上下文直接推断城市。两种模式没有绝对的对错，但选错了模式，用户体验就会断崖式下跌。

所以context-mode本质上是一个状态感知与响应策略的集合。它决定了系统在特定时刻应该关注哪些信息、忽略哪些信息、以什么优先级处理信息、以及最终以什么形式输出结果。它不是一个具体的算法，而是一层“调度逻辑”，把输入、状态、历史、目标这几个要素糅合在一起，输出一个当前最合理的动作。

这篇文章适合谁看？如果你正在做对话系统、推荐系统、自动化工作流、甚至游戏AI，只要你面对的是“系统需要根据当前情境决定怎么做”这类问题，context-mode就值得你花时间搞清楚。我会从设计思路、核心细节、实操落地、问题排查四个层面，把这套东西拆开讲透。不是教科书式的定义罗列，而是我在实际项目中踩过坑、调过参、重构过三次之后沉淀下来的经验。

2. 内容整体设计与思路拆解

2.1 为什么需要context-mode：从“一刀切”到“分场景”

早期做系统设计的时候，很多人喜欢用一套逻辑打天下。用户输入进来，走同一条处理链路，该解析解析，该查询查询，该返回返回。这种做法在简单场景下没问题，一旦场景变复杂，就会暴露出两个致命问题：一是响应僵化，二是资源浪费。

举个例子。假设你做了一个智能助手，既能回答知识问答，又能帮用户订机票。如果只有一套处理逻辑，那么当用户说“今天天气怎么样”的时候，系统可能会傻乎乎地去调用订票接口，因为它不知道当前应该进入“问答模式”还是“订票模式”。反过来，当用户说“帮我订一张去上海的票”，系统又可能把它当成一个知识问题去检索“去上海的票”相关文档。这就是典型的模式缺失。

context-mode要解决的核心问题就是：让系统在正确的时间做正确的事。它通过维护一个“当前模式”的状态变量，配合一套模式切换规则，让系统能够根据输入特征、历史交互、外部信号等因素，动态调整自己的行为策略。

我试过在一个客服机器人项目里引入context-mode，效果非常明显。之前用户抱怨最多的是“答非所问”，引入模式判断之后，系统会先判断用户是在“咨询产品信息”还是“投诉售后问题”还是“查询订单状态”，然后走不同的处理链路。投诉模式下的语气更温和、响应更谨慎；查询模式下的响应更直接、速度更快。同一个系统，因为模式不同，表现出了完全不同的“性格”。

2.2 模式划分的粒度：太粗没用，太细崩溃

设计context-mode的第一个难题是：到底该划分多少个模式？我见过两种极端做法。一种是只分两个模式，比如“正常模式”和“异常模式”，结果发现根本不够用，很多场景落不进去。另一种是分了二十几个模式，每个模式对应一种极其具体的场景，结果维护成本爆炸，模式之间的边界模糊，切换逻辑复杂到没人敢改。

我的经验是：模式数量控制在5到9个之间。这个区间既能覆盖大多数常见场景，又不至于让状态机变得不可维护。具体怎么分，取决于你的业务核心维度。比如对话系统可以按“意图类型”分：问答模式、任务模式、闲聊模式、纠错模式、引导模式。推荐系统可以按“用户状态”分：新用户探索模式、老用户利用模式、流失召回模式、高活激励模式。

划分模式的时候有一个关键原则：每个模式必须有明确的进入条件和退出条件。如果某个模式的边界说不清楚，那它就不应该独立存在。我踩过的一个坑是，曾经设计了一个“混合模式”，用来处理那些“既像问答又像任务”的输入。结果这个模式变成了一个垃圾桶，什么乱七八糟的输入都往里扔，最后它的行为完全不可预测。后来我把混合模式拆成了“优先任务模式”和“优先问答模式”，用优先级规则来裁决，问题才解决。

2.3 模式切换的触发机制：谁来决定换模式

模式切换的触发机制是context-mode设计中最容易出bug的地方。常见的触发信号有三类：输入信号、状态信号、外部信号。

输入信号是最直接的，比如用户说了一句包含“订票”关键词的话，系统就应该从问答模式切换到任务模式。但关键词匹配太脆弱，用户说“我想了解一下订票流程”和“帮我订一张票”，关键词一样但意图完全不同。所以输入信号需要配合意图识别模型来用，不能只靠规则。

状态信号是指系统内部的状态变化。比如对话轮次超过5轮还没解决问题，就应该从正常模式切换到引导模式，主动给用户提供选项。再比如用户连续两次否定系统回答，就应该从问答模式切换到纠错模式，换一种解释方式。

外部信号包括时间、地点、设备、业务事件等。比如晚上11点之后，系统可以自动切换到“简洁模式”，减少冗余信息；检测到用户从手机端访问，可以切换到“短响应模式”。

这三类信号需要有一个优先级排序。我的做法是：外部信号 > 状态信号 > 输入信号。因为外部信号通常是硬约束，状态信号反映的是系统自身的健康度，输入信号虽然直接但最容易误判。当然这个优先级不是绝对的，具体项目要具体调整。

2.4 模式与上下文的耦合关系：别把模式当孤立状态

很多人设计context-mode的时候，容易把模式当成一个孤立的开关，切过去就完事了。但实际上，模式是和上下文深度耦合的。同一个模式，在不同的上下文下，行为也应该不同。

举个例子。假设系统处于“问答模式”，用户问“这个多少钱”。如果上下文是用户刚刚浏览了某件商品，那系统应该直接回答该商品的价格。如果上下文是用户刚进入首页，没有任何浏览记录，那系统应该反问“您指的是哪件商品”。模式相同，但上下文不同，响应策略就不同。

所以context-mode的设计必须包含一个“上下文快照”机制。每次进入某个模式的时候，系统要记录当前的关键上下文信息，比如最近三轮对话、用户画像标签、当前页面状态等。这些信息会作为模式内部决策的输入，影响最终的输出。

我在实际项目中用的是一个“上下文栈”结构。每次模式切换的时候，把当前上下文压入栈中；切回某个模式的时候，从栈中恢复对应的上下文。这样做的好处是，用户从任务模式回到问答模式时，系统还能记得之前聊到哪儿了，不会出现“失忆”的情况。

3. 核心细节解析与实操要点

3.1 模式定义表：把模糊概念变成可执行配置

设计context-mode的第一步，是写一张模式定义表。这张表要包含每个模式的名称、描述、进入条件、退出条件、优先级、以及在该模式下的行为配置。听起来很繁琐，但这一步做扎实了，后面的代码会好写很多。

我通常用YAML来定义这张表，因为可读性好，也方便非技术人员参与评审。下面是一个简化版的示例：

modes: - name: qa_mode description: "知识问答模式，用于回答事实性问题" enter_conditions: - intent in ["ask_fact", "ask_definition", "ask_howto"] - no_pending_task exit_conditions: - intent in ["create_task", "cancel", "chitchat"] - consecutive_failures >= 2 priority: 3 behavior: response_style: "concise" max_length: 200 fallback_action: "ask_clarify" - name: task_mode description: "任务执行模式，用于完成订票、下单等操作" enter_conditions: - intent in ["book", "order", "cancel_order"] - slots_required_satisfied exit_conditions: - task_completed - user_cancel - timeout_30s priority: 5 behavior: response_style: "confirm" max_length: 150 fallback_action: "ask_slot"

这张表的好处是，模式之间的边界一目了然。你可以直接看到qa_mode和task_mode的进入条件互斥，不会出现同时满足两个模式的情况。优先级字段用来处理边界情况，比如用户说“帮我订票然后告诉我天气”，这同时触发了task_mode和qa_mode，优先级高的先执行。

注意：进入条件和退出条件一定要写成可计算的表达式，不要写“用户看起来想订票”这种模糊描述。我见过一个项目，条件写的是“用户语气比较着急”，结果开发完全没法实现，最后不了了之。

3.2 上下文采集与存储：模式决策的燃料

context-mode的决策质量，很大程度上取决于上下文信息的质量。上下文采集要解决三个问题：采什么、从哪采、存多久。

采什么？我通常把上下文分成四层：会话层、用户层、环境层、业务层。会话层包括最近N轮对话、当前意图、已填槽位；用户层包括用户画像、历史行为、偏好标签；环境层包括时间、设备、网络状态、地理位置；业务层包括当前订单状态、库存情况、促销活动。

从哪采？会话层直接从对话管理模块拿；用户层从用户画像服务拿；环境层从客户端上报的数据拿；业务层从业务数据库拿。每一层的数据获取方式不同，延迟也不同。会话层是实时的，用户层可能是准实时的，环境层和业务层可能是分钟级甚至小时级的。设计的时候要考虑数据新鲜度对模式决策的影响。

存多久？我的经验是：会话层保留最近10轮，用户层保留最近30天，环境层只保留当前快照，业务层按业务需求保留。存太久没必要，还会拖慢查询速度；存太短又可能导致模式切换时上下文丢失。

实际实现的时候，我用的是一个Redis Hash结构，key是session_id，field是上下文类型，value是序列化后的数据。每次模式切换的时候，从Redis里拉取当前会话的上下文快照，注入到模式决策引擎中。这样做的延迟在5ms以内，完全不影响用户体验。

3.3 模式切换的决策引擎：规则与模型的混合

模式切换的决策引擎有两种实现方式：纯规则和模型驱动。纯规则的好处是可解释、易调试，坏处是覆盖不全、维护成本高。模型驱动的好处是泛化能力强，坏处是黑盒、难排查。

我的建议是混合使用：用规则处理高频、明确的切换场景，用模型处理模糊、复杂的切换场景。具体来说，可以设计一个两级决策流程。第一级是规则过滤器，快速判断是否满足某个模式的硬性进入条件。如果满足，直接切换；如果不满足，进入第二级模型判断。

模型部分我通常用一个轻量级的分类器，输入是上下文特征向量，输出是各个模式的概率分布。取概率最高的模式作为候选，如果最高概率低于某个阈值（比如0.6），就保持当前模式不变，避免频繁切换。

这里有一个关键参数：切换冷却时间。意思是两次模式切换之间必须间隔一定时间或轮次，防止系统在边界情况下反复横跳。我一般设置冷却时间为2轮对话或5秒。这个参数需要根据实际场景调，太短了会抖动，太长了会反应迟钝。

3.4 模式内的行为配置：让每个模式有独特的“性格”

模式切换只是第一步，更重要的是每个模式内部的行为配置。同一个系统，在不同模式下应该表现出不同的“性格”。问答模式下要简洁直接，任务模式下要严谨确认，闲聊模式下要轻松自然，纠错模式下要耐心细致。

行为配置通常包括这几个维度：响应长度、语气风格、确认策略、兜底策略、超时策略。响应长度控制输出的字数上限；语气风格控制用词和句式；确认策略决定是否需要用户二次确认；兜底策略决定无法处理时怎么回应；超时策略决定多久没进展就退出模式。

我做过一个对比实验：同一个订票任务，在“快速模式”下系统直接执行，在“确认模式”下系统先复述一遍再执行。结果发现，对于老用户，快速模式的完成率更高；对于新用户，确认模式的满意度更高。所以后来我加了一个规则：根据用户历史订单数来决定进入哪个子模式。这就是模式内部再细分的思路。

实操心得：行为配置不要写死在代码里，要做成可配置的。我吃过亏，有一次为了改一个语气词，重新部署了整个服务，结果引入了新的bug。后来把所有行为配置抽到配置中心，改完即时生效，安全多了。

4. 实操过程与核心环节实现

4.1 环境准备与基础框架搭建

动手实现context-mode之前，先把基础环境搭好。我用的是Python技术栈，核心依赖就三个：一个Web框架（FastAPI）、一个缓存（Redis）、一个规则引擎（我自己写了一个轻量级的）。不需要太重的框架，context-mode本身逻辑不复杂，重的是细节。

目录结构这样组织：

context_mode/ ├── config/ │ ├── modes.yaml # 模式定义表 │ └── behaviors.yaml # 行为配置表 ├── core/ │ ├── mode_manager.py # 模式管理器 │ ├── context_collector.py # 上下文采集器 │ ├── decision_engine.py # 决策引擎 │ └── behavior_executor.py # 行为执行器 ├── models/ │ └── mode_classifier.pkl # 模式分类模型 └── main.py # 入口

这个结构的好处是职责清晰。mode_manager负责模式的注册、查询、切换；context_collector负责从各个数据源拉取上下文；decision_engine负责根据规则和模型做切换决策；behavior_executor负责执行当前模式下的具体行为。

搭建的时候有一个坑要注意：上下文采集器的超时控制。因为要拉取多个数据源，如果某个源响应慢，会拖垮整个决策链路。我的做法是给每个数据源设置独立的超时时间（通常200ms），超时了就返回默认值，不阻塞主流程。这个细节在文档里很少提，但实际生产中非常关键。

4.2 模式管理器的核心实现

模式管理器是整个context-mode的心脏。它需要维护当前模式状态、处理模式切换请求、管理模式定义表。核心方法有三个：get_current_mode()、switch_mode(target_mode)、can_switch(target_mode)。

can_switch方法是最复杂的，它要检查目标模式的进入条件是否满足、当前模式是否允许退出、是否在冷却期内、优先级是否足够高。我实现的时候用了一个责任链模式，把各种检查条件串起来，任何一个不通过就返回False。

class ModeManager: def __init__(self, modes_config): self.modes = {m['name']: m for m in modes_config} self.current_mode = 'default_mode' self.last_switch_time = 0 self.switch_cooldown = 5 # 秒 def can_switch(self, target_mode, context): if time.time() - self.last_switch_time < self.switch_cooldown: return False target = self.modes.get(target_mode) if not target: return False if not self._check_enter_conditions(target, context): return False if not self._check_exit_conditions(self.current_mode, context): return False if target['priority'] < self.modes[self.current_mode]['priority']: return False return True def switch_mode(self, target_mode, context): if not self.can_switch(target_mode, context): return False self.current_mode = target_mode self.last_switch_time = time.time() return True

这段代码看起来简单，但有几个细节值得说。冷却时间我设的是5秒，这是经过多次调整后的值。太短了会导致模式抖动，太长了会让用户觉得系统反应慢。优先级比较那里，我用了“小于”而不是“小于等于”，意味着同优先级的模式不能互相切换，必须有一个更高优先级的模式来打破僵局。这是为了防止两个同优先级模式互相抢位。

4.3 上下文采集器的实现细节

上下文采集器要并行拉取多个数据源，我用的是asyncio.gather配合超时控制。每个数据源封装成一个协程，设置独立的超时时间，超时了返回默认值。

async def collect_context(session_id): tasks = [ asyncio.wait_for(fetch_session_context(session_id), timeout=0.2), asyncio.wait_for(fetch_user_profile(session_id), timeout=0.2), asyncio.wait_for(fetch_environment(), timeout=0.1), asyncio.wait_for(fetch_business_context(session_id), timeout=0.3), ] results = await asyncio.gather(*tasks, return_exceptions=True) context = {} for i, result in enumerate(results): if isinstance(result, Exception): context[CONTEXT_KEYS[i]] = DEFAULT_VALUES[i] else: context[CONTEXT_KEYS[i]] = result return context

这里的关键是return_exceptions=True，这样即使某个数据源抛异常，也不会影响其他数据源的采集。超时时间我设得比较短，因为模式决策是实时链路，不能等太久。如果某个数据源经常超时，就要考虑把它改成异步更新，不放在实时链路里。

注意：上下文采集一定要做降级处理。我见过一个系统，因为用户画像服务挂了，整个对话系统都不可用了。这就是没有做降级的下场。每个数据源都要有默认值，拿不到就用默认值，保证主流程能跑通。

4.4 决策引擎的规则与模型融合

决策引擎我分成了两层。第一层是规则层，用YAML配置的规则做快速过滤。第二层是模型层，用一个小型分类器做精细判断。

规则层的实现很简单，就是把模式定义表中的进入条件翻译成可执行的表达式。我用了一个简单的表达式解析器，支持in、==、>=这些操作符。规则层的特点是快，通常在1ms内就能出结果。

模型层我用的是LightGBM，输入特征包括：当前意图的置信度分布、最近三轮意图序列、用户历史模式偏好、当前时间、会话轮次等。输出是各个模式的概率。模型文件在服务启动时加载到内存，推理时间在3ms左右。

两层的融合逻辑是：如果规则层有明确结果（某个模式的进入条件完全满足且其他模式不满足），直接用规则层结果；如果规则层结果模糊（多个模式同时满足或都不满足），用模型层结果。这样既保证了高频场景的确定性，又保留了复杂场景的灵活性。

4.5 行为执行器的配置化实现

行为执行器负责根据当前模式执行具体行为。我把行为配置抽到了behaviors.yaml里，每个模式对应一组行为参数。

behaviors: qa_mode: response_style: concise max_length: 200 confirm_required: false fallback_action: ask_clarify timeout_seconds: 30 task_mode: response_style: confirm max_length: 150 confirm_required: true fallback_action: ask_slot timeout_seconds: 60

执行器读取当前模式的行为配置，然后应用到响应生成逻辑中。比如response_style会影响prompt的构造，max_length会截断过长的响应，confirm_required会决定是否插入确认步骤。

这种配置化的好处是，调整行为不需要改代码。我试过在线上直接改配置，把某个模式的max_length从200改成150，即时生效，用户无感知。这在快速迭代的时候非常有用。

5. 常见问题与排查技巧实录

5.1 模式抖动：系统在边界反复横跳

模式抖动是最常见的问题。表现是系统在两个模式之间快速切换，用户感觉系统“精神分裂”。根本原因通常是进入条件和退出条件不对称，或者冷却时间太短。

排查方法：打开模式切换日志，看每次切换的触发条件和时间戳。如果发现两个模式在短时间内反复切换，就是抖动。解决方法有三个：一是增加冷却时间，二是让进入条件更严格，三是引入“滞后效应”——退出某个模式的条件比进入该模式的条件更宽松。

我遇到过一个典型案例：用户说“帮我查一下订单”，系统进入查询模式；然后用户说“算了”，系统退出查询模式；然后用户又说“还是查一下吧”，系统又进入查询模式。三次切换在10秒内完成，用户体验很差。后来我加了一个规则：如果用户在30秒内重复进入同一个模式，就直接保持该模式，不再退出。问题解决。

5.2 上下文丢失：切换模式后系统“失忆”

上下文丢失通常发生在模式切换的时候。如果切换时没有保存和恢复上下文，系统就会忘记之前聊了什么。表现是用户从任务模式回到问答模式后，问“刚才那个多少钱”，系统完全不知道“刚才那个”指的是什么。

解决方法是在模式切换时做上下文快照。我的做法是在switch_mode方法里，先把当前上下文序列化存入Redis，key是context:{session_id}:{mode_name}。切回某个模式时，先从Redis里恢复上下文，再继续处理。

实操心得：上下文快照不要存太多，只存关键信息。我一开始把整个对话历史都存了，结果Redis内存暴涨。后来改成只存最近三轮对话和关键槽位，内存占用降了80%，效果没差。

5.3 模式覆盖不全：新场景无处安放

随着业务发展，总会出现新的场景无法归入现有模式。这时候有两种选择：一是新增模式，二是扩展现有模式。我的经验是，优先扩展现有模式，除非新场景和现有模式的差异非常大。

新增模式的成本很高，要定义进入退出条件、配置行为、更新决策引擎、重新训练模型。扩展现有模式只需要调整行为配置和进入条件。我一般会先尝试扩展，如果扩展后模式内部逻辑变得太复杂（比如超过5个分支），再考虑拆分。

5.4 性能瓶颈：决策链路太慢

context-mode的决策链路涉及上下文采集、规则匹配、模型推理、行为执行多个环节，任何一个环节慢了都会影响整体响应时间。我实测下来，整个链路要控制在50ms以内，用户才感觉不到延迟。

排查性能问题的时候，我会在每个环节打点计时，找出耗时最长的环节。常见瓶颈有两个：一是上下文采集时某个数据源响应慢，二是模型推理时特征计算太复杂。前者用超时降级解决，后者用特征预计算和缓存解决。

下面是我整理的一个常见问题速查表：

5.5 模型与规则的冲突处理

规则层和模型层偶尔会给出矛盾的判断。比如规则层认为应该进入任务模式，模型层认为应该进入问答模式。这时候需要一个仲裁机制。

我的做法是：规则层有一票否决权，但没有一票通过权。意思是，如果规则层明确判断某个模式不应该进入，那就绝对不进入；但如果规则层判断应该进入，还要看模型层的概率是否超过阈值。这样既保留了规则的硬约束，又利用了模型的泛化能力。

具体实现的时候，我给每个模式设了一个“规则置信度”和“模型置信度”。规则置信度是二值的（0或1），模型置信度是概率值。最终得分是两者的加权和，权重根据实际效果调整。我通常把规则权重设得高一些（0.7），模型权重设得低一些（0.3），因为规则更可控。

6. 模式设计的进阶思路与个人体会

6.1 模式继承：减少重复配置

当模式数量增多的时候，会发现很多模式之间有大量重复配置。比如“问答模式”和“闲聊模式”都需要简洁的响应风格，只是兜底策略不同。这时候可以用模式继承来减少重复。

我设计了一个简单的继承机制：每个模式可以指定一个父模式，子模式继承父模式的所有配置，只覆盖需要修改的字段。这样“闲聊模式”只需要写parent: qa_mode和fallback_action: chitchat，其他配置自动继承。

继承机制让模式定义表从200行缩减到了80行，维护成本大幅降低。但要注意继承层级不要超过两层，否则配置来源会变得难以追踪。

6.2 模式组合：应对复杂场景

有些场景需要同时激活多个模式。比如用户说“帮我订票，顺便告诉我那边天气”，这既需要任务模式又需要问答模式。这时候可以用模式组合，把多个模式的行为合并输出。

我的做法是定义一个“组合模式”，它包含一个模式列表和一个合并策略。合并策略决定多个模式的输出如何拼接：是串行执行还是并行执行，是取交集还是取并集。串行执行适合有依赖关系的场景，并行执行适合独立场景。

组合模式的风险是行为冲突。比如任务模式要求确认，问答模式要求直接回答，两者合并后到底确不确认？我的解决方案是给每个行为维度设一个优先级，冲突时取优先级高的模式的行为。

6.3 模式演化：让系统自己学会调整

最理想的context-mode是能够自我演化的。系统根据用户反馈自动调整模式定义和切换规则，不需要人工干预。我在这方面做了一些尝试，效果还不错。

具体做法是：记录每次模式切换后的用户反馈（比如是否继续对话、是否点赞、是否重复提问），用这些反馈作为奖励信号，用强化学习的方法优化切换策略。一开始效果不稳定，后来加了人工审核环节，把模型建议的调整先跑离线评估，通过后再上线，稳定性就好了很多。

这个方向还在探索中，但我觉得是context-mode的未来。现在的模式定义还是太依赖人工经验，如果能让系统从数据中自己学习模式边界，那维护成本会进一步降低。

6.4 我踩过的最大的坑：模式太多导致决策瘫痪

最后分享一个我踩过的最大的坑。有一个项目，我一开始设计了12个模式，觉得覆盖得很全面。结果上线后发现，模式切换的决策时间从5ms涨到了50ms，因为每次都要遍历所有模式的进入条件。更糟糕的是，模式之间的边界变得模糊，经常出现误判。

后来我痛定思痛，把12个模式合并成了6个。合并的原则是：如果两个模式的进入条件有超过50%的重叠，就合并；如果两个模式的行为配置有超过70%的相似，就合并。合并之后，决策时间降回了8ms，误判率也降了一半。

这个教训让我明白：模式不是越多越好，而是越准越好。每个模式都应该有明确的、不可替代的存在价值。如果一个模式可以被另一个模式覆盖，那它就不应该存在。

6.5 一个实用小技巧：模式决策的可视化

最后分享一个实用小技巧。我写了一个简单的可视化工具，把每次模式切换的决策过程画成时序图。横轴是时间，纵轴是模式，每次切换画一条线，线上标注触发条件。这个图帮我快速定位了很多问题，比如抖动、误判、切换延迟等。

工具本身很简单，就是用matplotlib画图，数据从日志里读。但效果非常好，产品经理和运营也能看懂，沟通成本大幅降低。如果你也在做context-mode，强烈建议做一个类似的可视化工具，绝对物超所值。

这个内容后续还可以这样扩展：把模式决策和A/B测试结合起来，用实验数据驱动模式定义的优化；或者把模式决策做成一个独立的微服务，供多个业务线复用。这些都是我在实际项目中验证过可行的方向，有机会再展开聊。