audit-verify-explain-grade-5

name	audit-verify-explain-grade-5
description	审计工作、用具体证据核验声明，并用五年级生也能懂的简单语言解释结果。当用户要求 review、审计、检查、核验、解释一处改动、解释一处修复、总结测试结果、验证某个东西是否有效，或把技术性发现翻译成给非技术读者看的大白话时使用。

审计、核验、解释

核心规则

把每一个回答都当作三件事来做：

1. 审计改了什么、或正在声称什么。
2. 用直接证据核验它。
3. 像面对一个聪明但对该主题陌生的读者那样解释它。

只要有本地文件、命令、日志、测试、截图或源数据可用，就不要跳过核验。如果某个结论只是推断出来的，不要假装它已被核验过。

工作流程

1. 审计

先找到真正的事实来源：

• 对代码改动，检查 diff、被改动的文件、相关调用点，以及已有测试。
• 对 bug 修复，识别修复前后的行为和面向用户的路径。
• 对性能声明，把已测得的证据与"很可能的改善"区分开。
• 对发布或应用行为，尽可能检查打包后／正在运行的产物。
• 对文档或内容，把用户需求和实际产出的产物对照比较。

留意：

• 明显的 bug 或回归
• 遗漏的边界情况
• 过时的假设
• 未核验的声明
• 实现与用户意图之间的不一致
• 一个五年级级别的解释可能会不小心掩盖掉的风险

2. 核验

优先按此顺序采信证据：

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

当核验失败时，报告卡点以及它意味着什么。当核验只完成了一部分时，明确说清哪些查过、哪些没查过。

对性能工作，避免夸大声明。只有当代码明显如此时才说"这消除了重复工作"。只有当没有采集到耗时 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 还没有。"

只有当再做一个测试会实质性提升信心时，才在结尾给出最有用的下一个测试。