企业官网建设流程全解析

不绕行：如何让存活两个月的 “合法值被拒” 现形 —— 定义方与执行方对比法

摘要

：一个评审维度的枚举值，在框架里定义了 4 处，升级时改了 3 处、漏了 1 处。这个不一致让所有 Java 技术方案评审卡在门禁前，存活约两个月。期间不是没人撞到 —— 撞到的人把维度改回旧值就绕过去了。只有我停下来问：为什么提示词允许的值，校验器不认？本文复盘这次排查，以及 “为什么它活这么久、却是我这个实习生发现的”。

背景

这是一篇实习期间的复盘沉淀。实习期间我深度使用公司自研 AI 编程框架做业务交付，从需求、设计、评审、编码、测试到上线门禁全程走完。这个 bug，是在真实业务交付的评审环节撞上的。

现象：校验器拒绝两个 “合法” 的值

方案本身单独跑校验器是通过的，但推审前被硬门禁挡住，报错指向评审结果文件里的两个字段值：

非法 axis 'goal\_support'（枚举 \[existence, completeness, contract, consistency, reviewability, reuse]） 非法 axis 'clarity'（枚举 \[同上]）

而这两个值，恰恰是评审员的提示词明文允许的：提示词说可以用 8 个维度，校验器却只认 6 个。

为什么它能活两个月：有绕法，就没人追究

这个 bug 能活两个月，原因有三：

1. 触发条件隐蔽：只有评审员用到两个新维度才会触发，不是每次必现；

2. 有绕法可走：把意见记到旧维度里（如 “目标支撑” 记进 completeness、标个前缀）就能过门禁 ——大家撞到了就绕，绕完就忘；

3. 测试盲区：升级单的测试只检查提示词取值集合，没检查校验器常量，两边各自绿、合起来不一致。

绕行是 bug 的氧气。只要有人绕，bug 就永远 “不算问题”。

排查过程：从 “我的问题” 到 “工具的问题”

第一步，怀疑自己的方案。单独跑校验器 —— 通过。方案没问题。

第二步，怀疑版本。升级到最新版 —— 依旧。换机器 —— 依旧。排除环境因素。

第三步，对比 “定义方” 和 “执行方”。这是关键转折：我不再盯着方案本身，而是去对比提示词（规则定义）和校验器（规则执行）的一致性。

结果发现：同一个字段（评审维度），在框架里有四处定义：

三处已同步，校验器是唯一漏改的那处。模板注释写着 “维度扩至 8 值”，校验器注释还停留在 “六轴”。

为什么是我发现的：不是运气，是行为差异

框架所有人都能用，为什么 “提示词 vs 校验器不一致” 这种问题，是我这个实习生先撞破的？我复盘了一下普通使用者和我的差异：

差别不在能力，在选择：遇到问题时，是选择 “把这一单跑完”，还是选择 “把它弄明白”。实习生不是 “更容易发现 bug”，而是 “更愿意在别人绕行的地方多看一眼”。框架给所有人同样的工具，决定发现率的是：要不要绕行、做不做闭环验证、读不读定义。

修复方案

1. 补常量：校验器枚举补齐两个值，与模板同序；

2. 加正样本：自测加入 “8 个值各写一条，断言全部通过”，防止再漂移；

3. 加契约断言（推荐）：测试直接比对 “提示词取值集合 == 校验器常量”，从根上杜绝这类不一致。

给所有人的提醒

枚举、常量、配置这类 “多处引用同一事实” 的东西，升级时永远要问一句：

我改的是定义，还是所有引用？

而遇到 “合法操作被拒”，先别急着绕 ——

绕过去的是这一单，留下来的是一条长期负债。

#Java#AI 编程#代码质量#配置管理