推文

@fireandstart · 2026-10-11 02:26

我们总想给 coding agent 更大的上下文窗口，但窗口变大并不会自动让任务更清楚。真正有用的是把问题相关的文件、函数、报错和运行环境放在一起：改动前的调用链说明约束，失败日志指出偏差，最小复现帮助区分根因与巧合，修复后的测试或实际运行结果再验证判断。否则把整个仓库塞进上下文，重复定义、过期文档和无关模块只会稀释关键线索，甚至让模型把相邻但不相关的实现当成依据。所谓“更聪明的上下文”，不应只是更激进的压缩或检索，而是一个可追溯的选择过程：为什么这些文件与当前问题有关，依据是哪条错误或调用关系，结论又由什么结果证实。上下文质量最终要看它能否减少误改、返工和定位时间，而不是单看塞进去了多少 token。对于复杂问题，我会先给 agent 任务边界和失败证据，再按需要补充相邻代码；如果假设被运行结果推翻，就更新上下文，而不是继续堆材料。这样的闭环，比单纯扩窗口更接近可靠的工程协作。

曝光 49 · 评论 1 · 点赞 0 · 书签 0 · 曝光/时 3.4956490399225504