一线大模型案例库

这问题我也踩过坑，后来发现光写“只修改某文件”不够，得在prompt里把具体要改的代码块贴出来，再强调“保持其他代码原样”。另外试试对话里开新会话，让它重新读一遍文件上下文，有时候旧对话它记混了。git diff乱的话，我习惯每改一次就手动commit一次，至少回滚省心点。

我之前也卡在这块好久，最后发现固定token数切真的不如按语义段落切，尤其技术手册里的小节标题和列表结构很关键。你可以试试先把文档按标题层级拆成块，再对超长的块用滑动窗口二次切分，overlap设个50-100词就够了。另外强烈建议建个小规模的标注测试集，比如20个典型问题，每次调完策略跑一遍看召回和答案准确率，比自己凭感觉调高效得多。

7B这规模确实对prompt的敏感度会高不少，尤其是Qwen2.5这种指令微调版本，它不像大模型那样能稳定抓住“意图”，更像是在“猜”你想要的格式。我自己试过几次，发现它对你给出的“边界”特别敏感，比如你只说“爬一个接口”，它默认就给你最简版，但你一旦把“输出格式”“异常处理”甚至“打印日志”都写清楚，它反而容易跑偏，因为信息太杂它分不清主次。 我后来摸索了个笨办法，就是把prompt拆成两段，

这现象太真实了，我试过把system prompt重复三遍才稍微好点，感觉跟上下文长度关系不大。 我之前也踩过这坑，vLLM默认的chat template可能没把system prompt当回事，换成带特殊标记的格式就稳多了。

动态调整更有用，固定模板模型容易偷懒。否定示例得加，但放一两条就够，多了它反而会绕开所有道歉话术。 建议试试把场景拆成对话历史+当前用户输入，角色指令放system里，效果比全塞进prompt稳很多。

我最近也踩过这个坑，后来用了LangChain的`with_retry`装饰器配合指数退避，基本能扛住大部分网络问题。不过像数据库查询这种幂等操作还好，邮件发送要是重试没处理好容易出重复，建议在工具函数里加个唯一请求ID做去重。另外你试过把超时时间调大点吗？有些接口默认只等几秒确实太紧了。