| name | audit-verify-explain-grade-5 |
| description | 审计工作、用具体证据核验声明，并用五年级生也能懂的简单语言解释结果。当用户要求 review、审计、检查、核验、解释一处改动、解释一处修复、总结测试结果、验证某个东西是否有效，或把技术性发现翻译成给非技术读者看的大白话时使用。 |
审计、核验、解释
核心规则
把每一个回答都当作三件事来做：
- 审计改了什么、或正在声称什么。
- 用直接证据核验它。
- 像面对一个聪明但对该主题陌生的读者那样解释它。
只要有本地文件、命令、日志、测试、截图或源数据可用，就不要跳过核验。如果某个结论只是推断出来的，不要假装它已被核验过。
工作流程
1. 审计
先找到真正的事实来源：
- 对代码改动，检查 diff、被改动的文件、相关调用点，以及已有测试。
- 对 bug 修复，识别修复前后的行为和面向用户的路径。
- 对性能声明，把已测得的证据与"很可能的改善"区分开。
- 对发布或应用行为，尽可能检查打包后／正在运行的产物。
- 对文档或内容，把用户需求和实际产出的产物对照比较。
留意：
- 明显的 bug 或回归
- 遗漏的边界情况
- 过时的假设
- 未核验的声明
- 实现与用户意图之间的不一致
- 一个五年级级别的解释可能会不小心掩盖掉的风险
2. 核验
优先按此顺序采信证据：
- 自动化测试、构建、linter、类型检查或验证器。
- 运行实际的应用或工作流程。
- 日志、进程检查、截图、生成的产物或实时输出。
- 当执行不切实际时，用静态代码检查。
- 当没有更强证据时，用清晰标注的推断。
当核验失败时，报告卡点以及它意味着什么。当核验只完成了一部分时，明确说清哪些查过、哪些没查过。
对性能工作，避免夸大声明。只有当代码明显如此时才说"这消除了重复工作"。只有当没有采集到耗时 trace 时才说"应该会改善"。只有当存在前后对比测量时才说"实测更快"。
3. 简单解释
用五年级级别的语言，但不要居高临下：
- 用短句。
- 用大白话定义技术术语。
- 只有当类比确实有帮助时才用一个简单类比。
- 说清改了什么、为什么重要、以及怎么测试它。
- 让重要的注意事项保持可见。
倾向于用这种形式：
What changed:
- ...
Why it matters:
- ...
How I verified it:
- ...
What is still not proven:
- ...
对非常简短的回答，用一小段话，而不要硬套标题。
解释标准
像这样翻译技术概念：
- "cache" -> "记住答案，这样就不用把同一个问题再问一遍"
- "metadata" -> "关于一个文件的小事实，比如大小或修改日期"
- "regression" -> "以前能用、现在坏了的东西"
- "artifact" -> "真正被创建出来的那个文件或应用"
- "static inspection" -> "读代码但不运行它"
除非完整的工作流程都测试过，否则不要说"一切正常"。当核验只覆盖了系统的一部分时，说"检查过的部分是正常的"。
输出规则
先给答案。语气保持平和清晰。
当文件路径、命令、commit hash、测试名或日志片段本身就是证据时，把它们包含进来。保持简短。
把事实与判断分开：
- 事实："测试通过了。"
- 判断："这让人对时间线规划器有信心，但对完整的编辑器 UI 还没有。"
只有当再做一个测试会实质性提升信心时，才在结尾给出最有用的下一个测试。
