根据缺失信息逐步补充上下文

以下示例与示意结果由本站编写，用于说明方法，不是模型实测结果。

使用场景

你要给 API 端点接入限流，第一次搜索 rate limit 没找到实现，但中间件入口提到 throttle。教学项目中 middleware/index.ts 引用 throttle.ts，router.ts 给路由接入中间件；需要核对这些实际材料再判断是复用还是新增。

具体做法

第一轮用任务概念找候选，读后写出相关性理由和缺失问题。第二轮根据观察到的术语与引用追踪，实现、接线与相关测试逐步补齐。达到目标归属、接口和调用链都可说明的条件时停止；到约定检索预算仍有缺口就报告，不能用固定文件数或数字分数代替充分性。

反例

只搜索一次 rate limit，零命中就断言没有限流器，立即创建新的实现；不读已出现的 throttle 引用。

改进写法

为上述限流任务最多进行三轮针对性检索，这是本例预算。先查 rate limit 和中间件入口，记录缺少的实现与路由接线；发现 throttle 后读取 throttle.ts、router.ts 和相关测试。每轮解释新资料补了哪个缺口。接口归属、调用路径及接入条件明确时停止，优先复用已确认实现；预算结束仍未知则列出缺口，不从首次零命中推断不存在。

为什么这样改

新查询来自实际发现和未解决问题，能补足第一次词汇不匹配遗漏的路径。每轮明确缺口，也使扩展读取有目标，不把所有候选文件都当必要上下文。

如何验证

示意检索台账：第一轮发现 throttle 引用但缺实现；第二轮读实现与路由；必要时第三轮核对测试。最后能说明现有函数怎样接入，或明确哪个调用条件仍未确认。

只重复原关键词、达到三文件就停，或发现现有实现仍声明没有，都不满足检查。

适用边界

三轮和文件名是教学预算与材料，不是所有任务的固定上限。相关性评分不是校准概率；关键路径未找到时保留不完整结论，不扩大到任务之外的敏感资料。