在业务复杂度还不高的时候，系统往往可以靠“默认前提”顺畅运转。
但当业务模式、渠道和策略开始叠加，系统迟早会走到一个临界点：
所有问题都看起来像 bug，但实际上都是上下文问题。
这篇文章记录一次真实的上下文工程实践，完整复盘从“哪里出问题”到“如何落地”的全过程。
一、问题不是突然出现的
系统最早的问题并不严重。
同一套商品和库存，在不同销售通路下，偶尔会出现价格偏差；
某些边缘场景下，风险拦截和定价策略的命中结果不一致。
这些问题最初都被当成个例，通过补逻辑、加判断的方式被“修复”了。
直到有一天，我们发现一个现象：
同一个商品，在不同系统视角下，结论是完全不同的，而且都“有理有据”。
这已经不是简单的逻辑问题，而是系统对“当前所处语境”的理解彻底不一致。
二、一次失败的常规重构
第一反应是做一次常规重构：
梳理逻辑分支
合并重复代码
抽象公共方法
结果是代码更“干净”了，但问题并没有消失。
原因很快变得清晰：
我们只是在优化计算方式，而没有触碰计算前提本身。
上下文依旧分散在：
方法参数里
配置中心里
表字段的隐含含义中
以及几位核心同学的脑海里
系统仍然在一个模糊前提下运行。
三、真正的转折点：把“前提”当作一等公民
转折发生在一次问题复盘会上。
我们尝试用一句话描述某次异常计算的前提，却发现没人能完整说清：
到底是哪个业务模式
适用的是哪套规则
风控是在什么阶段介入的
这次讨论最终达成了一个共识：
系统缺的不是逻辑，而是一个被工程化管理的上下文。
从这一刻开始，我们不再讨论“怎么改逻辑”，而是先回答一个问题：
一次决策，究竟依赖哪些前提？
四、上下文拆解的真实过程
上下文拆解并不是一开始就很顺利。
我们最初列出的上下文信息超过 40 项，其中相当一部分是重复或语义模糊的。
经过多轮收敛，最终保留了几类核心上下文：
不可变事实：商品属性、货品状态、基础成本
场景信息：渠道、业务模式、生命周期阶段
决策目标：当前关注的是利润、周转还是风险
运行态信息：库存、流量、实时风险信号
一个重要原则是：
只要会影响决策结果，就必须显式进入上下文。
五、上下文对象的落地方式
在工程实现上，我们做了几个关键约束：
上下文对象在决策前一次性构建
决策过程只读上下文，不允许再查询外部状态
上下文具备清晰的构造入口和版本演进能力
这意味着，很多过去“顺手查一下”的逻辑，被强制前移到上下文构造阶段。
短期看，代码写起来更“麻烦”了；
但长期看，系统行为开始变得可预测、可解释。
六、最明显的变化：分支开始消失
引入上下文工程后，一个非常直观的变化是：
if/else 数量开始减少，而不是增加。
过去新增一个场景，往往意味着：
在已有逻辑上加一层判断
现在新增场景的方式变成了：
构造一个新的上下文组合，复用既有策略
逻辑代码只关心上下文满足哪些条件，而不关心“这是哪个业务线”。
七、一次真实的收益场景
在一次促销策略调整中，业务提出临时新增一种混合模式。
按照旧模式，这类需求通常意味着高风险改动；
而这次，只是新增了一种上下文组合方式，策略本身几乎未改。
最终上线过程平稳，没有引发历史场景回归问题。
这是团队第一次明确感受到：
上下文工程不是洁癖，而是真正的风险控制手段。
八、与 AI 协同的意外收获
后来在引入 AI 辅助定价和风险分析时，这套上下文体系直接成为了输入标准。
我们没有要求 AI 去理解复杂业务，而是只让它面对已经结构化好的上下文。
结果是：
输出稳定性显著提升
结果更容易解释和复盘
人工干预成本明显下降
这让我们更加确信：
AI 能否靠谱，前提是上下文是否靠谱。
九、踩过的坑
这次实践也并非一帆风顺：
上下文粒度过细，初期导致构造成本过高
部分历史逻辑对上下文依赖不清，重构成本被低估
团队需要时间适应“先想上下文，再写逻辑”的方式
这些问题最终都通过持续收敛和约束解决，但确实需要耐心。
十、最后的思考
回头看，这次上下文工程并没有引入新技术，也没有复杂框架。
它更像是一种“工程认知升级”。
系统真正成熟的标志，不是逻辑有多复杂，而是：
它是否清楚自己所处的环境，以及为什么会做出当前决策。
如果你的系统已经开始依赖“老同学经验”才能安全运行，
那很可能不是人不够努力，而是上下文还没有被工程化。
这，往往是下一次系统进化的起点。