CI绿了就能交？Grok Bot工程验收的版本对应原则

CI全绿不代表可以交付。B站UP主"马上花生"在《Grok Bot》系列第十五集中，用一套模拟证据练习拆解了这个常见误区：绿色的CI状态只是交付的必要条件，而非充分条件。真正决定能否进入代审状态的，是证据链是否完整、版本是否对应、检查是否真的覆盖了原始需求。

核心问题：绿色状态不等于测试通过

很多人看到CI流水线全绿，第一反应是"可以合并了"。但UP主明确指出，必须追问三个问题：测试是否真正执行了？哪些范围被跳过了？当前要求是否被覆盖了？

GitHub官方文档也印证了这一点：成功、跳过或中性状态都可能满足平台层面的检查要求，但这意味着绿色状态背后可能包含大量未验证的内容。一个有说服力的例子是——冒烟检查通过了，但核心排序回归失败了，这种情况不能被表述为"全部通过"。

跳过测试本身未必是错误，但必须说明跳过原因和未验证项。UP主的核心主张是：不能让颜色代替测试内容，每份证据都要写清楚提交、检查名称、命令和环境、时间、退出状态以及可打开的日志。

CI（持续集成） 指开发者频繁将代码变更合并到主干后，由自动化流水线执行构建、测试与检查的工程实践。流水线通常由多个 Job 组成，每个 Job 对应一项检查，最终汇聚为平台层面的状态标记。

在 GitHub 上，检查状态并不只有成功与失败两种。中性（neutral） 表示检查已完成但结果既非通过也非失败；跳过（skipped） 表示该检查因条件不满足而未执行。这两类状态在分支保护规则中默认可能被视为"通过"，因此绿色标记的语义比字面上更宽泛。

理解这一点是后续讨论的基础：状态颜色描述的是"平台是否放行"，而不是"测试是否验证了需求"。两者的差异正是本集反复强调的风险来源。

版本对应：最容易忽视的证据陷阱

本集设计中有一个典型的"反攻"练习：旧版本A的回归测试通过了，但新版本B后来修改了代码，却仍然引用A的通过截图。这种版本不一致直接导致测试无法证明新提交满足同样的需求。

正确做法是返回实际结果的提交哈希、对应检查名称与日志，再按相同的回归路径核对。截图看起来正常，并不能证明测试是在B上执行过的。版本本身就是证据的一部分。

GitHub官方对此有明确说明：必须检查要对应最新需要检查的提交；有合并测试提交状态时查它，否则查最新头提交。不能机械地只拿最早那次运行作为依据，还要核对检查名称、触发事件和仓库规则。

提交哈希（commit hash） 是 Git 为每次提交生成的唯一标识，通常为 40 位十六进制字符串，前 7 位即可用于日常引用。由于同一分支的后续提交会改变分支指向，任何测试证据都必须绑定到具体的提交哈希，而不是分支名或"最新版本"这类相对描述。

合并测试提交（merge commit） 指 PR 合并时自动生成的特殊提交，它同时包含目标分支与源分支的历史。平台在校验状态时会优先查看这一提交上的检查结果；若不存在，才会回退到分支的最新头提交。这就是为什么同一份截图在不同时间、不同提交上可能得出完全不同的结论，也是"版本即证据"这一主张的技术依据。

审查建议不等于盲目执行

审查意见指出某个检查需要去掉重复值，但原始需求明明要求保留。即使这个检查已经成功执行，这条行为变化仍然与任务不符——需要具体的修订和回归证据来支撑。

UP主的观点很明确：审查建议也要判断是否适用，不能盲目全部照改。要对照需求、影响和范围说明采纳理由。争议或超出范围的变化由负责人决定，不让执行器自己扩大任务边界。

失败分类：不同红色对应不同处理

并不是所有红色CI都意味着"再改改代码"。UP主将失败分为几个类型：结果不符合需求、代码行为与用例命令不符、环境失败（依赖无法访问或工具报告缺权限）。

对于环境类失败，修好环境后要真正重跑对应测试——恢复连接不等于已经证明代码正确。缺权限也不能靠重复请求绕过。给执行器的反馈必须是具体的失败版本、输入与期望，而不是笼统的要求。

可交付的判断标准

本集给出的操作框架是：当前版本B的核心回归失败且重复值被移除，只修相关函数与测试，保持有限数字前提，返回新提交和对应日志，不再引用A的通过截图。修正最多两轮，仍有相同问题或超出允许范围就升级人工处理。

限次是管理约定而非官方产品限制，目的是避免"从事写成无限循环任务"。停止操作不会撤销已有变更，必要修正仍需按真实目标和授权处理。

达到可审查结果后可以交付代审状态。合并时要另外核对具体PR、最新提交、目标分支和授权，不能只因一个链接或绿色标记就自动合并上线。

UP主在结尾强调了一个可复用的工程验收表：版本对应、检查实际需求满足、缺口可查、代审停点。绿色状态有意义，但必须和这次变更及原始要求放在一起读。下一集将切换到办公场景，讨论进展表中"完成八项、邮件说两项待验收"的口径差异问题。

升级人工处理（escalation） 是自动化工作流中的常见安全阀：当自动化代理在限定轮次内无法达成目标，或变更范围超出预先授权时，将任务交回人类负责人决策。这里的"两轮"并非产品层面的硬性限制，而是团队为控制成本与风险设定的管理约定。

设计升级机制的要点有三：明确触发条件（重复失败或越界）、明确交接内容（当前提交、日志、已尝试的修复）、明确停止边界（升级不等于回滚，已有变更仍然存在）。缺少任一项，自动化任务都容易退化为无界循环或留下难以追溯的半成品状态。