这是交付前强制 gate，不是可选建议。只看代码、只跑局部函数、只凭感觉判断“应该可以”都不算通过。
核心规则
- 从用户入口跑到目标出口
- Web/GUI/TUI：从界面点、输、看结果。
- CLI：用用户实际会输入的命令。
- API：用真实 endpoint/curl 验证请求和状态变化。
- 智能体/对话系统：从真实对话入口或同一 server-side agent endpoint 输入真实问题并观察回复。
- UI 无法操作时，才用同一个 server-side endpoint/API 做等价验证，并说明等价关系。
- 第三者视角检查
- 检查时把自己当成没有参与实现的人类用户。
- 按用户真实路径确认：会看到什么、会不会卡住、结果是否满足原始需求。
- 自查-修复-复查循环
- 发现问题、异常、遗漏、结果不符合预期时，先修复。
- 修复后重新从用户入口做端到端检查。
- 循环到全链路通过后才允许交付。
- 不确定先查证
- 出现“可能、也许、大概、估计”时，先查官方/网络资料、本地 Markdown 历史经验、当前项目 docs/reports/git 历史。
- 穷尽后仍无证据，才可以明确标注“已查过 X/Y/Z，以下是推测”。
- 不把最后一公里推给用户
- 战术选择由你负责。遇到 SDK、配置、平台行为不确定时，先查证并自己选择可验证方案。
- 三次自查加一次搜索仍无解，才向用户求助；求助时说明已尝试内容、失败原因和需要用户补充的信息。
- 证据化交付
- 最终回复必须说明实际验证入口、执行动作和观察到的结果。
- 无法验证的部分必须明说，不能包装成已完成。
检查清单
- [ ] 从真实用户入口或等价入口实际跑通。
- [ ] 模拟人类用户执行关键操作，而不是只看实现。
- [ ] 结果符合用户原始目标和可见预期。
- [ ] 发现的问题已修复，并重新完成端到端复查。
- [ ] 没有把战术选择推给用户。
- [ ] 不确定说法已通过资料、本地经验或项目历史核查。
- [ ] 疑难问题已有根因证据或独立交叉验证。
- [ ] 技术交付中出现数学、统计、算法、优化、概率、因果公式时，已默认使用
$...$/$$...$$或目标平台等价 LaTeX 渲染；机器可读位置未被误改成 LaTeX。 - [ ] 最终回复写出验证入口、动作和结果。
OpenClaw 常见验证入口
- 机器人行为：优先用
openclaw agent --agent main --message "<真实问题>" --json或当前部署等价命令，从 agent 入口观察回复。 - Discord/外部频道：能安全发真实消息时用真实频道；不适合打扰频道时，用同一 gateway/agent CLI 入口做等价验证，并说明没有
--deliver。 - 配置和 skill 变更：确认 skill 被加载到新 session，再用匹配描述的真实任务触发它。
- 运维变更：检查服务监听、日志、实际请求链路和回滚线索。
禁止的假验证
- 只说“代码看起来没问题”。
- 只跑内部 helper，不跑用户入口。
- 只检查文件存在，不确认 agent 能读到或行为变化。
- 只做一次局部成功就交付疑难问题。