很多团队都在关注上线检查清单的制定。在预发环境中测试通过，一到生产环境就出问题的情况屡见不鲜，根源往往在于检查清单本身——并非没有执行检查，而是检查的标准和颗粒度存在缺陷。最常见的误区是：检查项过于宽泛模糊，例如“检查配置是否完成”——那么“完成”究竟如何定义？是将文件复制即算完成，还是必须符合生产环境的精确要求？因此，核心原则可以归结为一句话：检查清单关注的不应是“是否执行”，而是“是否正确”。

换言之，每一项检查的结果都必须输出明确的“是/否”判断，并附上具体依据，杜绝“看起来差不多”等模糊结论。那么，如何编写提示词（prompt）才能让AI模型准确执行这一任务？关键在于把握以下三个维度。

细化检查维度与颗粒度

第一步非常直接：在提示词的开头，用三句话明确锁定检查目标。注意——目标不是“是否已完成”，而是“是否符合上线安全规范”。同时，这段声明后必须附加一条强制约束：【必须写明“禁止模糊判断，每一项需输出‘是/否’+具体依据”】。不要忽视这条约束，否则模型默认会倾向于“只要执行了就算通过”。

第二步，将检查项拆解为可直接验证的原子操作。例如，不要写“检查配置”，这过于笼统。应改为：检查“.env文件中NODE_ENV值是否为'production'” → 检查“.env.production文件是否存在” → 检查“该文件是否包含DB_HOST且非localhost”。这样一来，每一步都可执行、可验证，模型无法含糊其辞。

第三步，对每一类风险强制绑定验证方法。例如“权限检查”，不能仅写“检查权限是否正常”，必须附带具体命令：“执行ls -l ./scripts/deploy.sh →确认返回结果中包含'-rwxr-xr-x'”。命令一旦固化，验证结果便一目了然。

注入否定式校验逻辑

一个非常实用的技巧是：在每条检查项后增加一句“反例拦截句”。例如，“确认API网关路由已生效”后面立即跟上——“若curl -I https://api.example.com/health 返回404或超时，则此项为‘否’”。这样一来，模型必须考虑“什么情况下应判定为否”，而非仅关注“存在即通过”。

更进阶的做法是：要求模型主动枚举失效场景。在提示词中明确写出：“对每个检查项，先列出1个典型失败案例，再给出验证命令。”例如，“数据库迁移未执行”对应的失败案例是“migrate_status表中latest_version < codebase中version”，然后再给出如何查找该差异的命令。这一步骤操作简单，只需将失败案例嵌入提示词即可——但若遗漏，模型会默认只寻找“存在即合格”，而不会识别“存在但错配”的情况。而这正是许多线上问题的真正根源。

绑定上下文快照指令

最后一步，在提示词末尾添加一条固定指令。其作用是：在模型开始逐项比对之前，先让它获取当前的上下文快照。如何编写？例如：“请先执行以下命令获取当前上下文快照，然后逐项比对：git status --porcelain → cat .git/config | grep 'url =' → ls -A config/ | grep -E '^(prod|release)' → docker-compose ps | grep -E '(web|api)' | awk '{print $5}'。”

这里必须添加一句强约束：【若未执行上述快照命令就输出检查结论，视为无效响应】。模型有一个常见问题——它经常跳过这一步直接回答，因此如果你不用强约束锁定执行顺序，它就会走捷径。而这正是导致检查结果遗漏关键上下文的原因。

总结一下：检查清单应具备细致的颗粒度、绑定的验证方式、主动枚举的反例以及强制抓取的上下文快照。将这些要素融入提示词，模型产出的结果质量将显著提升。