audit-verify-explain-grade-5

审查、验证、说明

何时使用此技能

• 用户要求你在信任某项更改、修复或说法之前，先对其进行审查、审核或检查。
• 用户希望你用具体证据（测试、运行应用、日志、截图或产物）验证结果，而不是想当然地认为它们有效。
• 用户要求你总结测试结果，或验证某项内容是否确实有效。
• 用户希望你用五年级学生也能看懂的简单语言，向非技术读者说明某项技术发现、差异或修复。
• 需要根据测量证据核查性能或改进方面的说法，而不是想当然地认为它们成立。
• 对于纯粹编写新代码或内容、无需审查／验证／说明步骤的任务，或用户希望面向专家读者提供高度技术化、充满术语的说明时，请勿使用此技能；应改用标准的实现或写作工作流。

核心规则

将每个回答视为三项工作：

1. 审查已更改的内容或相关说法。
2. 用直接证据验证。
3. 用简单易懂的方式向聪明但刚接触此主题的读者说明。

如果有本地文件、命令、日志、测试、截图或源数据可用，请勿跳过验证。若只是推断得出，就不要声称已经验证。

工作流

1. 审查

先找出真正可信的信息来源：

• 对于代码更改，检查差异、涉及的文件、相关调用位置和现有测试。
• 对于错误修复，确定修复前后的行为以及用户实际操作路径。
• 对于性能说法，区分测量证据和可能的改进。
• 对于发布或应用行为，尽可能检查打包后的产物或正在运行的应用。
• 对于文档或内容，将用户请求与实际产物进行比较。

留意：

• 明显的错误或回归问题
• 遗漏的边界情况
• 过时的假设
• 未经验证的说法
• 实现与用户意图不一致之处
• 五年级水平的说明可能无意中掩盖的风险

2. 验证

优先采用以下证据，顺序如下：

1. 自动化测试、构建、代码检查、类型检查或验证器。
2. 运行实际应用或工作流。
3. 日志、进程检查、截图、生成的产物或实时输出。
4. 无法实际运行时，静态检查代码。
5. 没有更有力的证据时，明确标注推断。

验证失败时，报告阻碍因素及其影响。验证不完整时，准确说明已检查和未检查的内容。

对于性能相关工作，避免夸大结论。只有代码明确消除了重复工作时，才说“这消除了重复工作”。没有采集计时记录时，只说“应该会有所改进”。只有存在前后测量结果时，才说“测量结果显示速度更快”。

3. 简单说明

用五年级学生能看懂的语言说明，但不要居高临下：

• 使用简短的句子。
• 用通俗的语言解释技术术语。
• 只有确实有帮助时，才使用一个简单的类比。
• 说明改了什么、为何重要，以及如何测试。
• 清楚呈现重要的注意事项。

优先采用以下结构：

What changed:
- ...

Why it matters:
- ...

How I verified it:
- ...

What is still not proven:
- ...

回答非常简短时，用一小段话即可，不必勉强添加标题。

说明标准

按以下方式解释技术概念：

• “缓存” -> “记住答案，这样就不用重复问同一个问题”
• “元数据” -> “关于文件的一些简单信息，例如大小或修改日期”
• “回归问题” -> “以前能用，但后来出问题的内容”
• “产物” -> “实际生成的文件或应用”
• “静态检查” -> “不运行代码，只阅读代码”

除非完整工作流已经过测试，否则不要说“一切正常”。如果只验证了系统的一部分，就说“已检查的部分正常”。

输出规则

先给出答案。语气保持平和、清晰。

在证据中注明文件路径、命令、提交哈希、测试名称或日志片段。保持简洁。

区分事实与判断：

• 事实：“测试通过了。”
• 判断：“这让我们对时间线规划器更有信心，但对完整的编辑器 UI 还不能确定。”

只有在其他测试能显著增强信心时，才以最有用的下一项测试收尾。

参考资料

• 上游源代码：https://github.com/MengTo/Skills/tree/main/agent-skills/codex/audit-verify-explain-grade-5
• agents/openai.yaml — 此技能的 OpenAI/Codex 接口元数据（显示名称、简短描述、默认提示词）