口径变更的三层陷阱：改代码 ≠ 改数据 ≠ 改缓存

陷阱一：改代码 ≠ 改数据#

场景：某个统计从”排除 X”翻转为”纳入 X”。

你把代码改了：查询逻辑、聚合逻辑、前端显示全改了，单测也过了。但线上的数字没变。

为什么？因为过去的历史数据在”排除 X”阶段就已经被清理掉了。X 现在根本不在数据库里，代码再对，也无米下锅。

口径从”排除 X”翻转为”纳入 X”时，多问一句：X 现在在数据库里吗？ 如果之前是”同步即删”的设计，光改代码不够，必须触发一次全量重同步，让新逻辑把 X 重新拉回来。

陷阱二：改生成端 ≠ 清展示端缓存#

场景：数字是 AI 生成的结论。你改了生成规则（比如禁用一个指标），提示词对了、喂的数据对了、服务重启了、单测过了。用户看到的结论还是旧的。

为什么？因为展示端是读结论缓存表的，旧记录还在表里，页面读缓存直接显示，根本不会触发重新生成。你改了”生产端”，但”展示端”的历史结论没清。

正确的闭环有四段，缺一不可：

1. 改生成端：提示词 + 喂给模型的数据
2. 清展示端缓存：删掉结论缓存里的旧记录
3. 触发一次重算：让新规则落进缓存
4. 验证新输出：拉一条结论，grep 旧关键词确认 0 命中

光改生成端 + 重启 ≠ 用户看到新结论。 这条是”改了但没效”的典型：代码层完全正确，但展示链路里的旧状态还在。

陷阱三：改 AI 结论，剥字段比改提示词可靠#

接上面的场景：你想让 AI 结论里不再出现某个指标（比如加班时长）。光在提示词里加一句”禁止使用 X”够吗？不够。 模型还是会从喂给它的数据字段里自己推出来——字段里有 hours_over_8h、total_overtime_h，它自然会用。

模型的结论口径 = 喂的数据 + 提示词约束，共同决定。 提示词禁令是”口头劝阻”，剥字段是”物理约束”。改 AI 口径先想：这些字段还要不要喂？能不喂就不喂。

陷阱四：用户口述自相矛盾 → 结构化锁定#

口径变更里最隐蔽的坑：用户自己说的话前后矛盾。

比如需求文档里写”指标 A 改为指标 B”，用户口述却是”指标 A 改为指标 C”。两个词长得很像，语义完全不同。你按其中一句猜着改了，必然返工。

解法不是猜，是给结构化选项让用户一次拍死：

用 4 个选项把口径问清楚（保持 A / 统一为 B / 统一为 C / 其他），附一个推荐项。代价是 1 个问题，收益是不返工。

口述越模糊、术语越相近，越要用选择题，而不是靠上下文猜。

一个共性#

这四个陷阱背后是同一个认知：“改了源头” ≠ “改了运行时” ≠ “改了展示链路的旧状态”。代码正确只是第一层，历史数据要重新同步，展示缓存要显式失效，AI 结论要物理约束喂的数据。

口径变更不是一次代码修改，是代码、数据、缓存、验证四个动作的一次组合拳。

下一次改任何”数字怎么算”的需求，先列这张清单再动手：改代码 → 重同步数据 → 失效缓存 → 触发重算 → 验证新输出。一步都不能省。