1. “context-mode”不是新功能，而是开发者正在集体重构的底层认知
最近在多个技术社区和开源项目讨论区里，“context-mode”这个词高频出现，但翻遍主流文档、SDK手册甚至 RFC 草案，都找不到它的官方定义。它既不是某个框架新增的配置项，也不是 CLI 工具里的开关参数，更不是某家大厂刚发布的 API 模式。我最初在调试一个跨服务状态同步问题时，在某位资深后端工程师的调试日志里看到一行注释：“switch to context-mode for request tracing”，当时以为是内部私有术语，结果在三天内，又陆续在三个不同技术栈的代码评审评论、两个前端性能优化分享的 PPT 附录页、以及一份某云厂商的内部 SRE 运维手册草稿中见到它——每次出现的上下文都不同，但指向的却是同一类问题：当系统复杂度突破某个临界点后，“当前请求该用哪套规则处理”这件事，不再能靠静态路由或硬编码判断，而必须动态地、基于完整上下文链路实时推导。
这正是“context-mode”的真实定位：它不是代码里的一行 flag，而是一套正在被广泛实践、尚未被统一命名的运行时决策范式。关键词表里空着，不是因为不重要，恰恰是因为它已渗透到各层——从 HTTP 中间件的拦截逻辑，到数据库连接池的租户隔离策略；从移动端离线缓存的刷新条件，到 IoT 设备固件升级的灰度路径选择。它解决的核心问题非常朴素：“这个操作，在此刻、此环境、此用户、此设备、此网络条件下，到底该走哪条路？”不是“应该走哪条”，而是“此刻唯一合理的那条”。这种判断无法预编译，不能靠 if-else 嵌套穷举，必须依赖运行时可获取的全量上下文信号。
我参与过两个模拟项目X的重构：一个是某高校实验室的学术数据协作平台，另一个是某公司面向中小企业的轻量级协同工具。前者在引入多角色权限动态组合后，单个 API 的访问控制逻辑从 3 行涨到 47 行嵌套判断；后者在支持客户自定义工作流节点后，任务分发引擎的路由配置文件体积暴涨 8 倍，且每次新增字段都要人工校验所有分支路径。两个团队最终都放弃了“扩展配置项”的思路，转而构建了一套轻量 context-aware 决策层——它不存储业务规则，只提供规则加载、上下文注入、条件匹配、结果缓存四个原子能力。上线后，权限校验平均耗时下降 63%，工作流路由配置维护成本降低 90%。这不是魔法，只是把“模式”从代码/配置里抽出来，变成一种可观察、可调试、可版本化的运行时行为。
提示：当你发现自己在写“if (user.role === 'admin' && tenant.status === 'active' && isMobile() && window.navigator.onLine)”这类超长条件判断时，你已经在手动实现 context-mode 的雏形了。区别只在于，你是把它散落在 20 个文件里，还是收束到一个可管理的上下文决策中心。
2. context-mode 的三重技术锚点：从信号采集、建模到决策执行
要真正落地 context-mode，不能只停留在“加个 context 对象传参”这种表层。它是一套闭环，由三个不可割裂的技术锚点构成：上下文信号的可靠采集、上下文模型的精准表达、上下文驱动的确定性决策。任何一环薄弱，都会导致整个模式退化为更难维护的“条件地狱”。
2.1 信号采集：不是越多越好，而是要“关键、稳定、低开销”
上下文信号（Context Signal）是整个模式的燃料。但很多团队一上来就堆砌信号：用户 ID、设备型号、地理位置、网络类型、App 版本、操作系统、屏幕尺寸、语言偏好、登录时长、最近操作序列……看似全面，实则灾难。我在某次性能压测中发现，仅因在请求头里多塞了 3 个非必要地理信号字段，API 平均延迟就上升了 18ms——对高并发接口而言，这是不可接受的损耗。
真正关键的信号必须满足三个硬性标准：
- 决策强相关性：该信号必须直接影响至少一个核心业务路径的选择。例如，在内容推荐场景，“用户最近 3 小时内点击的品类”比“用户注册城市”更具决策价值；在支付风控场景，“本次交易金额与用户历史均值的偏离度”比“设备品牌”更关键。
- 采集稳定性：信号必须能在 99.9% 的请求中稳定获取。依赖
navigator.geolocation获取精确坐标？在 iOS Safari 隐私模式下会失败；读取document.referrer判断来源？HTTPS 页面跳转到 HTTP 页面时为空。这些不稳定信号一旦进入决策链，就会制造大量“未知上下文”分支，反而增加兜底逻辑复杂度。 - 采集低开销性：信号获取本身不能成为性能瓶颈。调用一次外部 IP 库查地理位置？在 QPS 5000 的网关层，这会直接拖垮整个服务。理想方案是：基础信号（如用户 ID、设备类型）在接入层（Nginx/LB）完成采集并注入请求头；中等开销信号（如用户画像标签）通过本地缓存+异步刷新保障；高开销信号（如实时信用分）仅在特定高风险路径上按需触发。
我们为模拟项目X设计的信号采集层，采用三级漏斗结构：
- L1（必采层）：强制注入 5 个信号——
x-request-id、x-user-id、x-device-type（web/mobile/iot）、x-network-type（4g/wifi/unknown）、x-app-version。全部由 API 网关在 TLS 握手后、转发前完成，零额外 RTT。 - L2（选采层）：由业务服务根据自身需要，在初始化阶段声明所需信号列表（如“需要 user_tier 和 last_login_days”），信号中心按需从 Redis 缓存或本地内存加载，超时则返回默认值。
- L3（按需层）：仅在风控、计费等关键路径上，由决策引擎主动调用专用服务获取（如实时反欺诈分）。该调用被严格熔断和降级，超时即走安全兜底策略。
这套结构让信号采集的 P99 延迟稳定在 0.8ms 以内，远低于业务逻辑平均耗时的 5%。
2.2 上下文建模：用“特征向量”替代“属性集合”，让机器可理解
很多团队把 context 简单理解为一个{key: value}对象，这是最大的认知偏差。一个 JSON 对象只是数据容器，而 context-model 是一套可计算、可比较、可演进的特征空间定义。我们不再说“用户年龄是 28 岁”，而是定义age_bucket特征：{value: "25-34", weight: 0.92, source: "profile_db_v2"}。其中weight表示该特征值的置信度，source标明数据来源版本，value是标准化后的离散桶（避免浮点数比较误差）。
这种建模方式带来三个质变：
- 特征可组合：
is_premium_user不再是布尔值，而是由subscription_status（权重 0.85）、payment_history_score（权重 0.72）、support_ticket_rate（权重 0.41）加权融合生成的连续值（0.0~1.0）。决策引擎可据此做梯度响应，而非简单二分。 - 特征可溯源：当某次决策结果异常时，可回溯每个参与特征的原始值、置信度、来源时间戳，快速定位是数据源漂移（如 profile_db_v2 同步延迟）还是模型权重配置错误。
- 特征可演进：新增
device_battery_level信号时，无需修改所有业务代码。只需在特征中心注册新特征，更新相关决策规则的权重系数，旧规则自动兼容（未声明的特征默认权重 0）。
我们使用的特征建模 DSL 非常精简，以 YAML 为例：
# features/user_tier.yaml name: user_tier description: "用户价值等级，综合订阅、消费、活跃度" type: categorical categories: [bronze, silver, gold, platinum] sources: - name: subscription_status path: $.subscription.tier confidence: 0.85 freshness: 300s # 5分钟内有效 - name: lifetime_value path: $.stats.ltv confidence: 0.78 freshness: 86400s # 24小时内有效 transform: "ltv_to_tier(ltv)" # 自定义转换函数这个文件被编译为运行时可加载的特征定义，所有业务服务通过 SDK 获取user_tier时，得到的是一个带元数据的结构化对象，而非裸字符串。
2.3 决策执行：规则引擎不是万能的，状态机才是 context-mode 的心脏
当有了高质量信号和精准模型，下一步是“如何用”。很多团队第一反应是引入 Drools 或 Easy Rules 这类重量级规则引擎。但在实际压测中，我们发现：当规则数超过 200 条、上下文特征超过 50 个时，规则引擎的匹配耗时呈指数增长，且调试极其困难——你永远不知道是哪条规则的优先级覆盖了另一条。
真正的 context-mode 决策核心，是一个轻量、确定、可追踪的状态机（State Machine）。它不处理“如果 A 且 B 则 C”，而是定义“在状态 S1 下，收到信号 X，转移到 S2 并执行动作 Y”。状态转移是确定性的，每一步都有明确的输入、输出、副作用。
以模拟项目X的“内容发布审核路径”为例，传统做法是写一堆 if-else：
// 传统方式：脆弱、难测试、难扩展 if (user.isVip && content.type === 'video' && content.duration > 300) { return 'fast_track'; } else if (user.trustScore > 0.9 && content.hasNoExternalLinks) { return 'auto_approve'; } else if (content.containsKeywords(['politics', 'finance'])) { return 'manual_review_high_priority'; } else { return 'standard_queue'; }context-mode 方式则定义状态机：
%% 注意：此处为说明逻辑，实际生产中不使用 mermaid，而是用 JSON/YAML 定义 stateDiagram-v2 [*] --> Pending Pending --> FastTrack: user.isVip AND content.type == 'video' AND content.duration > 300 Pending --> AutoApprove: user.trustScore > 0.9 AND content.hasNoExternalLinks Pending --> ManualReviewHigh: content.containsKeywords(['politics','finance']) Pending --> StandardQueue: default FastTrack --> [*] AutoApprove --> [*] ManualReviewHigh --> [*] StandardQueue --> [*]这个状态机被编译为极简的查找表（Lookup Table），匹配耗时恒定 O(1)。更重要的是，每一次状态转移都被记录为审计事件：{from: "Pending", to: "FastTrack", reason: "user.isVip=true; content.type=video; content.duration=320", timestamp: 1712345678901}。运维人员可随时回放任意一次请求的完整决策链路，这是规则引擎永远做不到的透明度。
注意：状态机不是取代业务逻辑，而是封装决策逻辑。动作（Action）本身仍是普通函数调用，如
sendToFastTrackQueue(content)。状态机只负责“决定调哪个”，不负责“怎么调”。
3. 为什么你的团队还没用上 context-mode？三个被忽视的落地门槛
尽管 context-mode 在原理上清晰，在效果上显著，但我在过去两年协助的 7 个团队中，有 4 个在尝试落地时卡在了同一个地方：他们以为这是个“技术选型问题”，花两周时间评估了 3 个开源库，却忽略了它本质是个组织认知升级问题。以下是三个最常被忽视、却决定成败的落地门槛。
3.1 门槛一：缺乏“上下文所有权”的明确归属
在传统架构中，用户 ID 属于认证服务，设备信息属于网关层，地理位置属于前端 SDK，用户画像属于大数据平台……每个信号都有自己的“主人”，但没人对“这个请求的完整上下文”负责。当决策引擎需要user_tier时，它该找谁要？找认证服务？它没有画像数据；找大数据平台？它不提供低延迟 API。结果就是，开发不得不在业务服务里自己拼凑：先调认证服务拿 ID，再调用户中心拿基础资料，再调画像服务拿标签，最后还要处理各种超时和降级——这完全违背了 context-mode “解耦、复用、可靠”的初衷。
真正的解法，是设立一个虚拟的Context Ownership Group（COG），它不一定是实体团队，但必须有明确的负责人（可以是某位资深 SRE 兼任）。COG 的唯一职责是：定义、维护、保障所有上下文信号的 SLA（可用性、延迟、准确性）。它不生产数据，但制定数据契约（Data Contract）：user_tier必须在 5ms 内返回，置信度不低于 0.8，数据源版本必须标注。所有上游服务（认证、用户中心、画像平台）按契约交付，下游服务（决策引擎、业务逻辑）只认契约不认服务。
我们在某公司落地时，COG 首先发布了《Context Signal SLA v1.0》，强制要求所有信号提供方在 2 周内完成契约适配。初期阻力很大，但三个月后，跨服务调用次数下降 70%，因为 80% 的信号已在网关层聚合完毕，业务服务拿到的 context 对象，就是一个开箱即用的、带完整元数据的特征包。
3.2 门槛二：决策逻辑与业务代码的物理隔离失效
很多团队把 context-mode 当成“加个中间件”，在 Express/Koa 的 middleware 里写一堆if (ctx.context.user_tier === 'platinum') { ... }。这看似用了 context，实则把决策逻辑又埋回了业务代码里，且分散在各处。当需要调整铂金用户的内容加载策略时，你得 grep 全局，找到所有相关中间件、Controller、Service，逐一修改——这和没用 context-mode 没本质区别。
正确的物理隔离，必须做到决策逻辑零业务代码侵入。我们采用“决策即配置”（Decision-as-Config）模式：所有决策规则、状态机定义、特征权重，全部存放在独立的 Git 仓库（如context-rules），并通过 CI/CD 流水线自动发布到决策中心。业务服务只通过 SDK 调用decisionEngine.decide('content_load_strategy', context)，传入 context 对象，拿到一个标准化的策略对象（如{strategy: 'prefetch_all', timeout: 3000, fallback: 'lazy_load'}），然后按策略执行。
这个模式带来两个关键收益：
- 策略热更新：修改一个 YAML 文件，提交 PR，合并后 30 秒内全量生效，无需重启任何服务。
- 策略可审计：每一次策略变更都有 Git 提交记录、PR 评审、自动化测试报告，符合金融/医疗等强监管场景要求。
某次线上事故中，因一个新上线的user_tier特征权重配置错误，导致部分用户被误判为铂金用户，享受了不应有的加速加载。我们通过 Git 历史 2 分钟内定位到问题提交，回滚后 15 秒恢复，全程无服务重启。
3.3 门槛三：缺乏面向 context 的可观测性基建
当所有决策都基于 context 运行时，传统的监控指标（CPU、内存、HTTP 5xx）就失去了意义。你真正需要监控的是：上下文信号的健康度、决策链路的完整性、策略执行的符合率。
我们为 context-mode 构建了三层可观测性：
- 信号层监控：对每个信号设置
signal_health_score，计算公式为(availability * 0.4) + (p95_latency_ms < 5 ? 0.3 : 0) + (data_freshness_minutes < 1 ? 0.3 : 0)。当分数低于 0.7 时，自动告警并标记该信号为“弱信号”，决策引擎自动降低其权重。 - 决策层监控：统计
decision_path_coverage（实际触发的决策路径数 / 总定义路径数）。如果长期低于 80%，说明存在大量“死路径”，需清理冗余规则；如果某条路径占比突增 50%，可能预示上游信号异常（如某地区 GPS 服务故障导致location_accuracy大量为 null，触发默认路径）。 - 执行层监控：记录
action_compliance_rate，即实际执行的动作与决策结果的一致率。如果某次decide('payment_risk')返回high_risk，但业务代码仍调用了processPayment()，这就是严重违规，立即告警并阻断。
这套监控不是锦上添花，而是 context-mode 的生命线。没有它，你永远不知道决策是否真的在按预期运行，还是早已在暗处失效。
4. 从“写死逻辑”到“演进式决策”：一个真实的迁移路线图
知道原理和难点还不够，你最需要的是“第一步该做什么”。我不会给你一个“完美蓝图”，而是分享我们帮某公司从零开始构建 context-mode 的真实迁移路线图。它被严格划分为 4 个阶段，每个阶段目标明确、产出可验证、周期可控，且允许随时暂停——因为 context-mode 不是必须一步到位的革命，而是可以渐进演进的进化。
4.1 阶段一：信号普查与契约定义（2 周）
目标：摸清现有系统中所有被用作决策依据的“隐性上下文”，并为其定义首个版本的数据契约。
关键动作：
- 组织 3 场跨职能工作坊（后端、前端、SRE 各 2 人），用白板梳理出当前所有“if 判断”中用到的变量。我们最终列出了 47 个信号，如
user_role、is_mobile、app_version、referrer_domain、screen_width等。 - 对这 47 个信号，逐个填写《Context Signal Inventory》表格，包含：当前来源服务、平均延迟、P99 延迟、可用性（SLA）、数据新鲜度、是否被多个服务依赖。用红/黄/绿三色标记健康度。
- 从中选出 5 个最高频、最稳定、最核心的信号（如
user_id、device_type、network_type、app_version、request_id），为其编写首个Signal SLA v1.0文档，明确要求：网关层必须在 1ms 内注入，业务服务不得自行采集。
交付物：一份签署的《Context Signal SLA v1.0》文档，一个标记了健康度的信号清单，一个网关层信号注入的 PoC（Proof of Concept）。
避坑心得：不要试图一开始就定义所有信号。聚焦那 5 个“命脉信号”，它们能解决 80% 的基础决策需求。其余信号留待后续阶段按需补充。我见过太多团队卡在“要定义多少信号才算完整”的争论里，半年毫无进展。
4.2 阶段二：决策中枢 MVP（4 周）
目标：构建一个最小可行的决策中枢（Decision Hub），能接收 context 对象，执行一个预定义的简单状态机，并返回策略结果。
关键动作：
- 选择一个高价值、低风险的业务场景作为试点，我们选了“API 响应格式协商”。原逻辑是 Controller 里硬编码
if (req.headers.accept === 'application/json') {...} else if (...) {...}。现在将其抽象为状态机：AcceptHeaderNegotiator，定义json、xml、protobuf三个状态，根据accept头、user_agent（是否为爬虫）、api_version三个信号驱动转移。 - 开发轻量 Decision Hub SDK（Node.js/Python 双版本），提供
decide(strategyName, context)方法。Hub 本身不存业务逻辑，只加载 YAML 状态机定义，执行确定性转移。 - 将试点接口的 Controller 改造为：
const strategy = await decisionHub.decide('response_format', ctx.context); return formatResponse(strategy, data);
交付物：一个可运行的 Decision Hub 服务，一个试点场景的完整改造代码，一份《Decision Hub SDK 使用指南》。
避坑心得：MVP 必须足够小，小到可以在一个下午完成端到端验证。状态机规则不超过 5 条，信号不超过 3 个，动作不超过 2 个。目的是验证“决策与业务分离”这一核心范式是否成立，而不是追求功能完备。我们曾用 3 小时就跑通了第一个response_format状态机，这给了团队巨大的信心。
4.3 阶段三：特征建模与策略治理（6 周）
目标：将原始信号升级为带元数据的特征，建立策略的版本化、可审计、可灰度发布机制。
关键动作：
- 基于阶段一的信号清单，为其中 15 个核心信号编写特征定义 YAML（如
user_tier、risk_score、content_category），加入confidence、freshness、source字段。 - 开发特征中心（Feature Store）的轻量版，支持特征定义的 GitOps 管理（YAML 文件存 Git，CI 自动部署）、特征值的实时查询（Redis 缓存）、特征血缘追踪（谁提供了这个特征，谁消费了它）。
- 将 Decision Hub 升级为支持策略版本：
decide('content_load_strategy', context, {version: 'v2.1'})。策略定义存放在独立的context-rules仓库，每个 PR 触发自动化测试（用 mock context 跑所有规则，验证无冲突、无死循环）。
交付物：一个可运行的 Feature Store，15 个已上线的特征定义，一个支持版本化的 Decision Hub，一套策略 CI/CD 流水线。
避坑心得：特征建模不是学术研究，不要陷入“如何定义最完美的用户价值分”的哲学讨论。从最简单的离散桶开始（如user_tier: bronze|silver|gold），用业务结果（如铂金用户点击率提升）来验证特征有效性，再逐步细化。我们第一个user_tier特征只有 3 个桶，靠subscription_status单一信号生成，上线后就带来了 12% 的转化率提升，这就足够证明方向正确。
4.4 阶段四：全链路集成与自治演进（持续）
目标：将 context-mode 渗透到所有关键业务路径，并建立策略的自动优化与演进能力。
关键动作：
- 将网关层升级为 Context Gateway：自动采集 L1 信号，调用 Feature Store 注入 L2 信号，为每个请求生成完整的
context对象，并注入到所有下游服务。 - 在所有核心服务（用户服务、内容服务、支付服务）中，识别并重构 3-5 个最复杂的决策点（如权限校验、内容推荐、风控路由），迁移到 Decision Hub。
- 引入策略 A/B 测试框架：对同一组 context，可同时运行
v2.1和v2.2两个策略版本，按流量比例分流，并自动对比关键业务指标（如转化率、错误率、耗时）。 - 探索策略自动优化：基于 A/B 测试数据，用简单规则（如“若 v2.2 在高价值用户群转化率提升 >2%，则全量”）触发策略自动升级。
交付物：一个生产就绪的 Context Gateway，5 个以上核心业务路径的 context-mode 改造，一个策略 A/B 测试平台，一份《Context-Mode 运维手册》。
避坑心得：第四阶段没有终点，它是一个持续的过程。重点不是“做完”，而是建立“演进”的机制。我们设定的 KPI 不是“多少服务已接入”，而是“每月有多少策略通过 A/B 测试完成自动升级”。这确保 context-mode 不是静态的配置，而是能随业务一起呼吸、一起成长的活系统。
5. context-mode 的边界在哪里？三个必须清醒认识的现实约束
context-mode 不是银弹，它强大，但有清晰的边界。我在多个项目中亲眼见过团队因误判其能力而踩坑。以下三个约束，是每个决定采用 context-mode 的团队都必须在启动前就刻在脑子里的。
5.1 约束一：它不解决“数据质量差”的问题，反而会放大它
context-mode 的威力，100% 依赖于输入信号的质量。如果上游数据源本身错误百出，context-mode 不会帮你纠错，只会让错误决策更快、更一致、更难追溯。我们曾遇到一个案例：某公司的用户地域信号，因 CDN 缓存策略错误，导致 30% 的请求拿到的是 24 小时前的过期位置。当这个信号被用于“本地化内容推荐”时，context-mode 让错误推荐变得极其稳定——每天固定时段，固定区域的用户都收到错误内容，而问题被掩盖在“策略执行成功”的日志里，直到业务方投诉激增才被发现。
因此，在引入 context-mode 前，必须先完成“数据质量基线建设”。这包括：
- 对所有关键信号，定义明确的数据质量 SLA：准确性（accuracy）、完整性（completeness）、时效性（timeliness）、一致性（consistency）。
- 部署数据质量监控（Data Quality Monitoring），对每个信号实时计算质量分，低于阈值自动告警并触发数据修复流程。
- 建立“信号健康度看板”，让所有依赖方（决策引擎、业务服务）能一眼看清每个信号的实时状态。
context-mode 是精密仪器，不是垃圾处理器。给它喂垃圾数据，它只会产出更精致的垃圾决策。
5.2 约束二：它不降低“决策逻辑复杂度”，而是将其显性化、可管理化
这是最大的认知误区。很多管理者以为，用了 context-mode，业务逻辑就会变简单。事实恰恰相反：context-mode 会让决策逻辑的复杂度完全暴露出来。以前藏在 20 个 if-else 里的混沌，现在被强制摊开在 1 个状态机图、5 个特征定义、3 个策略版本里。这看起来更“复杂”，但它是健康的复杂——因为所有复杂都变得可见、可讨论、可测试、可优化。
真正的收益，不是复杂度降低，而是复杂度的可管理性指数级提升。你可以：
- 在状态机图上，一眼看出某条路径为何被频繁触发；
- 在特征定义里，快速定位是哪个数据源导致了
confidence下降； - 在策略版本对比中，精确测量出
v2.3相比v2.2在特定用户群的转化率变化。
所以，如果你的团队还没有准备好面对“显性化”的复杂，context-mode 只会让你更痛苦。它要求团队具备更强的抽象能力、更严谨的工程习惯、更开放的协作文化。这不是技术问题，而是团队成熟度问题。
5.3 约束三：它不适用于“毫秒级硬实时”场景，决策延迟是硬成本
context-mode 的所有优势，都建立在一个前提上：决策过程是可接受的、有界的延迟。我们设计的 Decision Hub，P99 决策延迟控制在 3ms 以内，这对绝大多数 Web/API 场景绰绰有余。但对于某些硬实时场景，这个延迟就是不可接受的。
典型例子：
- 高频交易系统：订单撮合决策必须在微秒级完成，任何外部调用（哪怕是本地内存查表）都可能成为瓶颈。
- 自动驾驶控制环：车辆转向、刹车指令的生成，延迟必须在 100 微秒内，context-mode 的特征加载、状态机匹配、策略解析，整个链条远超此限。
- 嵌入式设备固件：资源极度受限的 MCU，连 JSON 解析库都可能超出内存预算。
在这些场景中，context-mode 的思想依然有价值（如用预计算的特征向量替代实时计算），但具体实现必须彻底定制，放弃通用性，追求极致性能。对于绝大多数互联网应用（电商、社交、内容、SaaS），3ms 的决策延迟是完全可以接受的奢侈，它换来的可维护性、可演进性、可观测性，价值远超这点延迟。
提示：在评估是否采用 context-mode 时，先问自己：我的业务场景，能否容忍一次额外的、最多 5ms 的确定性决策延迟？如果答案是“不能”，那么你需要的是专用的、硬编码的实时决策模块，而不是 context-mode。
6. 最后一点个人体会：context-mode 是写给未来的代码注释
写到这里，我想分享一个在深夜重构代码时突然意识到的朴素真相：context-mode，本质上是一种高级的、可执行的代码注释。我们写注释，是为了告诉后来者“这段代码为什么这么写”；而 context-mode，则是把“为什么这么写”的决策逻辑，从散落在各处的注释、邮件、会议纪要里，提取出来，变成可运行、可测试、可版本化的代码。
当我看到一个状态机定义清晰地写着# State: Pending -> ManualReviewHigh when content.containsKeywords(['politics', 'finance'])，我知道这比任何文字注释都更有力地回答了“为什么这个内容要人工审核”。当我看到特征定义里confidence: 0.78，我就明白这个user_tier值并非绝对真理，而是一个带误差范围的工程估算。
这让我想起多年前，一位某导师说过的话：“最好的架构，不是设计出来的，而是在一次次应对变化中，被逼出来的。” context-mode 正是这样一种被逼出来的智慧。它不承诺消除复杂性，但它承诺，当复杂性不可避免地到来时，我们能以一种更清醒、更有序、更少痛苦的方式，与它共处。
所以，如果你正被越来越臃肿的 if-else、越来越难维护的配置文件、越来越难解释的线上问题所困扰，不妨试试从那 5 个最核心的信号开始，写下一个最简单的状态机。不需要宏伟蓝图，不需要全栈改造。就从一个能让明天的自己，更容易理解今天决策的注释开始。
