← Volver a las guías

大型代码库长上下文排障：解决漏读文件、改错位置与调用成本上涨

给模型更大的上下文窗口，为什么仍然改错代码？大型代码库的难点是找到当前任务真正依赖的文件，并保留版本、调用关系和验收标准。有效的长上下文策略，应从检索、组织和验证三个环节入手。

问题一：模型总是遗漏关键文件，应该先检查什么？

先检查输入是否覆盖完整调用链。例如修复“订单重复扣款”，只提供支付函数可能遗漏重试入口、幂等键生成逻辑和数据库唯一约束。先定位报错或业务入口，再沿调用关系补充上下游。

• 用 rg --files -g '!vendor/**' -g '!dist/**' 列出候选文件，减少依赖包和构建产物干扰。
• 用 rg -n '函数名或错误文本' src tests 搜索定义、调用位置和相关测试；将目录名替换为项目实际路径。
• 优先提供入口、核心实现、数据结构、配置和测试；跨服务问题还需补充接口契约及请求日志。

如果模型仍然猜测依赖关系，让它先列出“已有证据、缺失文件、待验证假设”，补齐证据后再修改代码。

问题二：上下文很长，为什么模型还会忘记要求？

窗口容量不代表每条信息都会得到同等关注。长日志、重复文件和已经失效的讨论，都会干扰当前任务。把输入组织成三层：任务目标与验收标准、直接相关源码、必要的背景资料。每段源码标明文件路径与所属提交，避免混入不同版本。

可以先把输入控制在窗口容量的六至七成，为输出、工具结果和后续修正留出空间；这个比例只是起点，需要按模型和工具行为调整。发送前再次附上简短验收清单，例如“保持接口兼容、覆盖超时重试、通过指定测试”。

问题三：一次放不下整个仓库，怎样拆分任务？

按可验证的行为拆分，例如先修复幂等判断，再处理重试策略。每轮只携带完成该步骤所需的代码。如果使用语义检索，应同时保留精确符号搜索；涉及鉴权、事务或公共接口时，继续检查调用方，避免片段检索遗漏约束。

跨轮交接时记录当前提交、已确认事实、修改文件、测试结果和未解决问题。摘要用于恢复进度；关键条件、类型定义和错误堆栈仍应保留原文。代码更新后，重新读取相关文件。

问题四：模型说修好了，为什么测试仍然失败？

要求每项修改对应具体故障证据。先运行能复现问题的最小测试，再运行相关模块测试；涉及公共类型或接口时，补充类型检查和调用方测试。若环境缺少数据库或依赖服务，应明确记录未执行的验证，避免把推测当作通过。

问题五：长上下文调用太贵，怎样降低开销？

• 先用本地搜索缩小范围，再提交源码，避免每轮重复发送整个仓库。
• 让较低成本模型整理文件清单、提取日志，让能力更强的模型处理跨模块推理；是否适合仍以任务验证结果为准。
• 记录每次调用的输入、输出令牌和费用。只有模型与接入方式明确支持时，才把提示缓存计入预算。

59API提供低价、按量付费的Claude与GPT模型调用，按原生官方模型质量提供服务，不做模型降级，并兼容Claude Code、Codex及OpenAI SDK，适合需要反复检索、分析和验证的开发流程。API基础地址为https://api.59api.com，具体接口路径、模型标识和鉴权方式应按接入文档配置。

问题六：换成便宜的接口，就能解决上下文问题吗？

调用单价与上下文质量需要分别优化。低价接入可以降低试验成本，但相关文件、版本信息和测试证据仍需准备完整。评估时可比较每个成功修复任务的总费用，同时观察重试次数与人工返工时间。

如果你正在为大型项目选择调用入口，可以注册59API，用一个已有测试的真实缺陷评估成本与效果；平台也提供推荐返利，可按当前活动规则了解。

Precios · Docs