青空读书
Lv.1在快速变化的技术世界里慢慢积累，关注技术学习与数字生活，记录读书与思考、方法总结和真实实践中的思考；更关注能够真正落地的方法。持续更新，尽量让每一篇内容都有实际价值。
发表的评论
同感，本地7B和API端的差距其实不在prompt，主要是采样参数和量化损失。你试试把temperature调到0.2以下，top_p也压低点，重复惩罚开大，啰嗦和复读会改善很多。上下文长度倒不是关键，默认4k够用了。 另外system prompt对本地小模型确实更“钝”，别指望它严格遵循指令，不如把要求直接写进用户问题里，比如“用三句话回答，每句不超过20字”。还有，qwen2.5对英文pr
试试把max-num-seqs调小，默认256太高了，20并发用不到那么多。 --- 显存利用率和max-num-seqs是两码事，vLLM会按上限预分配KV cache，调低点试试。 --- 20并发就崩，感觉是max-num-seqs吃满了，限制到64应该能稳不少。
几行注释，确实得在prompt里写死“每行都要”，再丢个带注释的示例进去，稳很多。
大概率是MCP的stdio模式超时设置太短，试试把transport换成sse或者调大超时时间，我前几天也踩过这坑。
我之前也踩过这个坑，top-k拉太高噪音就多。后来我直接在prompt里加了一句“只依据与问题最相关的片段回答，忽略无关内容”，效果好了不少，但偶尔还是会翻车。更稳的做法是在LangChain里接个Cohere Rerank或者bge-reranker，对检索结果先重排再取前2段喂给LLM，代码量不大，但能砍掉大部分杂质。你deadline紧的话，建议先试试prompt硬过滤，不行再上rerank
试试给历史对话按相关性打分，只留top-k轮喂给模型，亲测能省不少token，效果也没掉太多。 做个轻量的记忆压缩模块，把关键实体和数值抽出来存成结构化状态，比硬塞原始对话靠谱。
这个问题我太有感触了，过去两年我一直在用各种AI辅助写React组件，从最早GPT-3.5到现在Cursor的Claude模型，踩过的坑能写一本小册子。你说的“有时候能用有时候乱七八糟”这个现象，本质上不是AI变笨了，而是prompt里的信息密度和结构对齐出了问题。我先说一个最反直觉的结论：不是写得越详细越好，而是要写AI能“执行”的详细，像写测试用例一样去写prompt，而不是像写需求文档。
同感，Gemini 2.5 Think那个思考链的可读性确实好，拿来给非技术的业务方做结果溯源简直不要太爽。不过Claude Opus 4在复杂逻辑推理上那个稳定性，写关键模块的时候还是得切过去用。想问下做长文档摘要对比时，Gemini的输出长度控制体验怎么样？我这边试了几次，感觉它在长文本上偶尔会无预警截断，有点头疼。