在复杂业务系统里，最难维护的往往不是算法，而是那些“默认前提”。
它们不写在接口里，不体现在模型中，却真实地影响着每一次决策。
这篇文章记录一次真实的上下文实践过程，以及它给系统带来的变化。
问题从哪里开始
最初的问题并不复杂：
同一套业务逻辑，在不同渠道和业务模式下，计算结果开始频繁出现偏差。
代码层面看，一切都合理：
参数齐全
分支覆盖
历史逻辑未改
但问题始终无法彻底解决，因为每一次修复，都会在别的场景引入新问题。
后来我们意识到一个事实：
系统在“算”，但它并不知道自己所处的业务语境已经发生了变化。
第一步：承认上下文是“独立对象”
转折点来自一个简单但关键的决定：
不再把上下文当作零散参数，而是把它当作一个完整对象。
我们开始刻意区分三类信息：
不随场景变化的事实
描述当前业务场景的条件
为一次决策临时组装的约束
这些信息原本散落在方法参数、配置和 if 判断中，现在被统一收敛到上下文模型里。
这一步做完，代码并没有立刻变少，但含义变清楚了。
第二步：让逻辑只依赖上下文
在重构过程中，我们做了一条明确的约束：
业务逻辑不得直接读取外部状态，只能通过上下文获取信息。
这迫使我们回答一些之前从未认真思考的问题：
这个判断依赖的前提到底是什么
是业务规则，还是运行态状态
是否真的属于当前决策所需
很多模糊判断，在这个阶段被迫“显形”，也顺带暴露出不少历史遗留问题。
第三步：用上下文收敛分支复杂度
过去新增场景的方式，通常是：
“在原有逻辑上加一个 if”
引入上下文后，新增场景的方式变成了：
“构造一个新的上下文，再复用既有逻辑”
逻辑代码不再关心“这是哪个渠道”，而只关心“当前上下文满足哪些条件”。
分支数量明显下降，策略组合也开始变得可控。
一个明显的变化
上线一段时间后，有两个变化非常直观：
第一，排查问题更快了
问题从“这段代码为什么算错”，变成“上下文是否构造正确”，定位路径清晰了很多。
第二，新需求的风险明显降低
新增业务场景不再需要大范围修改旧逻辑，大多数改动集中在上下文构造层。
关于 AI 的补充实践
后来在引入 AI 辅助决策时，这套上下文实践几乎是直接复用的。
我们没有让 AI 去“理解业务”，而是让它只面对已经结构化好的上下文。
结果是，AI 输出的稳定性和可解释性，都远高于早期实验阶段。
这也再次验证了一点：
AI 能力的上限，往往取决于上下文工程的下限。
总结
这次上下文实践并没有引入新的技术栈，也没有复杂框架，更多是一种工程习惯的改变。
但它带来的效果是长期的：
系统不再依赖个人经验运行，而是依赖清晰、可演进的上下文。
如果你的系统已经开始出现“场景一多就失控”的迹象，也许值得认真审视一次：
上下文，是否真的被设计过。