这次上下文工程实践，并不是源于一次技术升级计划，而是一次被业务逼出来的工程自救。
事情发生在一个非常具体的时间点：
618 前两周，业务正在做多渠道、多模式的集中放量。
一、事故出现的那一周
周一上午，运营同学反馈一个看起来很“诡异”的问题：
同一批商品，在不同渠道的售价不一致，而且不符合任何已知策略规则。
第一反应是数据延迟或缓存问题。
但很快我们发现：
数据是实时的
规则命中链路是完整的
日志显示“逻辑全部走对了”
但结果就是不对。
到了周三，这类问题开始密集出现，甚至影响到促销策略的执行节奏。
系统没有宕，但已经开始“不可控”。
二、排查的困境：所有人都说得通
排查过程中，一个现象非常危险：
定价系统说：我只是按策略算
风控系统说：我只是按上下文拦
渠道系统说：我只是透传参数
每个系统的解释都成立，但拼在一起却是错的。
这时候，一个事实开始变得清晰：
系统之间对“当前是什么业务场景”的理解，已经严重分裂。
三、一个被忽略的真实场景差异
真正的问题，来自一个看似不起眼的变化。
为了提升供给，业务在原有寄卖模式上，引入了一种混合结算形态：
上游结算逻辑偏寄卖
下游销售行为更接近买断
中间存在时间窗口与风险兜底
在业务侧，这是“寄卖的小变体”；
但在系统侧，它同时触发了多套历史假设。
问题是：
系统从未被明确告知，这是一种新的业务语境。
四、传统修法彻底失败
我们尝试过几种“常规解法”：
增加一个业务类型枚举
在关键逻辑前加判断
针对渠道单独兜底
结果是：
每修一个问题，就引入两个新分支。
代码开始出现明显的“策略纠缠”，而且已经没有人敢拍胸脯说“我全懂”。
这时我们意识到：
继续修逻辑，只会加速系统崩溃。
五、当场拍板：暂停加逻辑，先补上下文
在一次紧急技术讨论中，我们做了一个当时看起来“很冒险”的决定：
所有新增需求暂停，先补上下文工程。
这个决定的核心不是重构代码，而是回答一个问题：
系统在做每一次定价和风控决策时，到底应该知道哪些前提？
六、上下文第一次被“完整说清楚”
我们拉上业务、产品、技术，一起做了一件之前从未认真做过的事：
逐条写清楚一次决策的真实前提。
不是参数名，而是自然语言描述：
当前商品属于哪种供给关系
当前结算责任在谁
当前目标是转化、利润还是风险
当前渠道是否允许动态调价
最终整理出的上下文，比接口参数多得多，但第一次完整对齐了认知。
七、工程落地的关键约束
在落地时，我们定了几条“铁律”：
上下文必须一次性构建完成
决策过程中禁止再“临时查信息”
所有策略、风控只依赖上下文
上下文结构必须可扩展、可版本化
这意味着大量历史逻辑需要被拆解，但别无选择。
八、真实重构中的一个细节变化
一个非常直观的变化是：
过去的代码里，经常出现这种逻辑：
如果是 A 渠道且是寄卖且在促销期
再判断是否命中某个策略
重构后，这些判断全部前移到了上下文构造阶段。
策略代码只做一件事：
判断当前上下文是否满足条件。
这一步，看似简单，却极大降低了逻辑复杂度。
九、618 当天的真实结果
618 当天，我们经历了：
历史最高流量
多种业务模式同时运行
临时策略多次切换
但有一个明显变化：
没有再出现“解释不通”的异常结果。
即便出现问题，也能快速定位到：
是上下文构造错误，而不是策略失效。
这是系统第一次在高压下，表现出“可解释性”。
十、上下文工程带来的长期影响
事后复盘时，我们总结出几个明确变化：
新业务接入成本明显下降
历史逻辑回归风险显著降低
跨系统沟通成本大幅减少
更重要的是，系统不再依赖“某几个人的记忆”运行。
十一、与 AI 结合的后续实践
后来在引入 AI 辅助决策时，这套上下文体系几乎是直接复用的。
AI 不再面对混乱的参数，而是面对完整、清晰的业务语境。
输出结果的稳定性和可信度，都远超最初的 POC 阶段。
十二、最后的反思
这次上下文工程实践，并不是一次“技术升级”，而是一次工程认知的纠偏。
我们终于意识到：
系统真正复杂的地方，不在算法，而在那些从未被认真建模的前提条件。
如果说这次实践有什么经验可以复用，那只有一句话：
当系统开始靠经验运行时，真正需要重构的，往往是上下文。