一两分钟，先想明白一件事。
从工程手记摘出的短笔记。每张便签留一个判断、一个例子，以及它的适用边界；想继续追问，再翻回长文。
整理于 · 原文日期见各则来源
一条答案错了，先沿链路找“最后一个正确产物”和“第一个错误产物”，再决定改哪里。
原文的构造问题是：v2 管理员能一次导出 200 条记录吗？参考资料允许管理员导出非归档记录，但单次最多 100 条。如果进入上下文的片段保留了“最多 100 条”，答案却写成“可以导出 200 条”，这次偏离发生在生成环节；把召回数量调大，未必能解决它。
如果“最多 100 条”在更早的上下文装配中已经被删掉，就要回到那次转换。逐步对照问题约束、过滤条件、候选片段、最终上下文与答案，先定位条件在哪一步失去，再做一次只改变该因素的验证。
适用边界这需要可靠的参考依据和可查看的中间产物。只看到最终答案时，可以提出排查假设，但还不能确定根因；修好当前题，也要再看相邻版本、角色和数量的反例。
有效评分的均值，描述的是拿到评分的那部分样本。它必须和覆盖率、缺失原因一起读。
原文有四条构造记录：A 的评分为 0.2，B 为 0.8，C 评估超时，D 材料缺失。有效均值是（0.2 + 0.8）÷ 2 = 0.50，有效覆盖却只有 2 / 4。单看 0.50，读者不知道另外两条发生了什么。
把 C、D 的缺失质量分直接填成 0，会得到 0.25，却混入了评估过程的问题。更合适的表达是“有效均值 0.50，覆盖 50%，另有一条超时、一条材料缺失”，然后判断该补什么证据。两次评估的均值变高时，也要先检查有效样本集合是否变了。
适用边界这里讨论的是有明确取值范围的质量评分。执行成功、有效评分和业务通过属于不同维度；覆盖达到多少才够、什么错误必须阻断，要按具体目标事先约定。
写操作发出后，响应丢失只能说明没有拿到回执。先核对结果，再决定是否重试。
原文的构造场景里，用户确认把套餐调整为团队版，下一周期生效。提交请求之后网络超时：申请可能没有到达，也可能已经成功受理，只是回执没有回来。此时直接再提交一次，可能产生重复动作。
先保留这次调用的对象、已确认参数和请求标识，按工具契约查询处理状态。确认已经受理，就继续核对生效安排；确认未受理，再按约定处理重试。如果状态仍不可查，明确告诉用户哪些结果未知，走复核或恢复流程。
适用边界这是对可能产生副作用的操作的判断。幂等与重试要依赖服务端契约；只读查询的重试规则可以不同。“提交完成”也不等于“业务已生效”，两者要分别确认。
便签记住一个判断，长文展开它的来路。
去实验室，动手看一次