刚入门的云原生玩家日常

碰到这个情况太正常了，24G跑多轮并发确实紧巴。你可以试试把max_model_len砍到8k，然后vLLM里把gpu_memory_utilization调到0.9，再把max_num_seqs设小点，基本能缓解。另外上下文管理别全指望框架，自己写个滑动窗口，只保留最近几轮对话和关键摘要，能省不少显存。至于轻量框架，我最近在看LiteLLM，它对并发和上下文截断的处理比较傻瓜式，不用折腾底层参数

我试过先画状态流转图再写prompt，效果比直接贴伪代码稳定不少，但图别画太细，画到关键分支就行。禁用useEffect这个思路挺好，我一般会明确加一句“联动逻辑放在事件处理函数里”，生成代码干净很多，不过偶尔需要多轮纠正。另外建议把边界条件写进prompt，比如“清空日期范围时保留已选部门”，AI容易漏这个。

我们之前也踩过这个坑，后来是把历史对话里的关键实体抽出来塞回当前query，比如“退款”+“到账时间”一起做检索，比直接拼全文效果好很多。重排确实能缓解漂移，但得配合意图识别，不然成本扛不住。想问下你试过用对话状态跟踪（DST）来维护上下文槽位吗？感觉比让LLM自由改写更可控。

说实话你这问题我太有共鸣了，之前调GPT-4写报表SQL也是被它编出来的字段名坑到怀疑人生。后来我发现光靠“严格基于表结构”这种指令基本没用，模型对约束的敏感度远不如对上下文的格式敏感。我的做法是改用few-shot，给它两三个你手写的正确SQL例子，特别是把关联类型和字段来源标清楚，它模仿的准确率会明显提升，比单纯加规则靠谱得多。另外一个小技巧是让它先输出一个执行计划或者字段清单，你确认无误后再

跟你情况差不多，后来我发现把伪代码写得跟需求文档似的，字段名、返回类型全给它标清楚，AI基本就不跑偏了。至于改bug，我都是直接说“只改第X行到第Y行，其他别动”，然后盯着diff看，要是它自作主张就ctrl+z回退，多来几次它就老实了。还有就是事务注解这种，我干脆在prompt里加一句“不要加任何注解”，省得它乱来。

我最近也踩过这个坑，Sonnet在长上下文里确实容易把格式带偏。后来我是直接在MCP工具返回前加了个JSON解析+校验的中间层，解析失败就自动重试一次，并在重试提示里把上次的错误原样贴回去，效果立竿见影。另外试试把schema直接嵌在prompt里，比few-shot稳得多，变量占位符反而容易让它更放飞。你校验层打算用哪个库？拿正则硬抠还是用pydantic之类的？