change-quiz

变更测验

经过长时间的会话后，Agent 往往做了比用户意识到的更多的事，而差异只呈现了表面内容。变更的行为取决于它如何与现有代码路径交互。用户只应合并自己能够通过测验的变更。

步骤

1. 先构建报告，分为四个简短部分：
   • 背景——本次会话旨在解决什么问题。
   • 变更内容——按意图（功能、修复、重构）分组，而非按文件分组。
   • 交互方式——变更涉及哪些现有代码路径，以及即使在差异未显示的文件中，现在哪些行为也发生了变化。
   • 直觉——用户应当牢记的 2-3 个心智模型更新（“重试现在具备幂等性，因为 X”）。
2. 对于较长的会话，提供一份独立完整的 HTML 页面报告，并将测验放在底部——这样读起来比一大段 Markdown 更清晰。
3. 然后进行测验：提出 5-8 个问题，聚焦可能让不了解情况的维护者措手不及的内容。
   • 将回忆类问题（“现在部署时，正在运行的任务会怎样？”）与预测类问题（“如果有人用过期令牌调用 X，会看到什么？”）结合起来。
   • 问题应侧重行为差异、边缘情况和交互影响，而非名称之类的琐事。
4. 每次只进行一轮，并如实评分。对于每个答错的问题，解释正确答案，并指出问题所在：这是用户心智模型中的缺口，还是变更设计得过于巧妙——要明确说明是哪一种。
5. 通过 = 可以合并。未通过 = 指出应重读报告中的哪些具体部分，然后提供一份全新的变体测验。标准不要放宽；这一做法的核心目的，就是不让未读懂的变更上线。

护栏

• 测验应覆盖变更及其影响范围，而非一般知识。
• 如果用户两轮后仍未通过，建议简化变更或将其拆分，而不是继续测验。
• 切勿为了顾及用户而判其答对。虚假的通过违背了这项技能的初衷。