MCP里用Prompt工程调教大模型，上下文窗口总崩怎么办？

这问题太典型了，MCP多轮交互里上下文膨胀基本是必然的，光靠精简Prompt治标不治本。我建议你试试把代码审查拆成两步：第一步只让模型提取关键函数和风险点，第二步再针对这些局部内容做深度分析，这样单次输入量能砍掉大半。另外，System Prompt里别塞太多格式约束，改成在User Prompt里动态注入当前轮次需要的规则，历史轮次的结果可以定期用摘要替换原文，相当于给上下文做“瘦身”。你那个“忽略历史错误”的写法其实很消耗token，不如直接清空无关轮次的对话记录，只保留必要的代码片段和结论。

这问题太典型了，我上周刚踩过一模一样的坑。你那个“先思考链再结论”的指令，本质上是让模型把推理过程全塞进上下文，代码一长，token直接爆炸。我后来把思考链改成“只输出关键判断依据，不重复代码内容”，比如让它引用行号而不是粘贴原代码片段，窗口压力瞬间小很多。但说实话，光靠Prompt精简治标不治本，MCP这种多轮交互，历史消息累积才是真凶。我现在的做法是在工具层做一个滑动窗口，只保留最近两轮对话的摘要，把旧的结论结构化存到外部存储里，需要时再按关键词调取。另外你那个“忽略历史错误”的结尾，我试过，反而容易让模型更困惑，不如直接在每个User Prompt开头用一句“基于最新输入，重置所有上下文假设”来得干净。还有一个野路子，就是给代码分块，每块单独一个MCP请求，最后再让模型汇总，虽然慢点，但稳得很。你那边如果方便，也可以试试把System Prompt里的格式要求拆成两个短句，比一大段管用。

说实话这问题我也踩过坑，MCP里多轮交互的上下文是叠加的，你Prompt再精简也没用，历史轮次全在消耗窗口。我后来是把代码拆成小块分批喂，每轮只让模型看一个函数，最后再汇总结论，崩的概率小多了。另外试试让模型把思考链写进临时变量而不是直接输出，能省不少token，你那个“忽略历史错误”的指令其实挺鸡肋的，模型根本分不清哪些该忽略。工具链层面如果能把代码结构化成AST再传，窗口压力会小很多，但实现成本你得权衡下。

试试把思考链改成外部工具输出，别让它写进上下文，MCP里挂个脚本存中间结果就行。

这题我熟，之前搞类似工具时也踩过这坑。核心问题不在Prompt本身，而是历史消息里塞了太多带代码块的中间过程，Claude得把整段对话重新编码一遍。建议试试只把当前文件的关键函数摘要和待审查的diff片段传进去，别一股脑全塞，MCP工具层做一下预处理，比指望Prompt精简更靠谱。

另外那个“忽略历史错误”的结尾其实没啥用，模型该看还是全看。你可以用System Prompt固定一个“每轮只输出最终结论，不重复思考链”的规则，把思考过程放到工具返回的临时变量里，这样上下文干净很多。实在不行就把代码拆成两三次请求，分别过一遍再汇总，代价是慢点但稳。

碰到这种问题多半不是Prompt写得不够简洁，而是你让模型在每轮都重复思考链，历史消息里堆了大量中间推理。建议把完整思考过程放到一个单独的tool调用里，只把最终结论写回对话，这样上下文里只留结构化结果，能省不少token。

另外可以试试给System Prompt加一条“每次只基于当前输入回答，不引用此前代码”，然后把单文件拆成函数级片段分批审，最后汇总。我试过用MCP的resource动态加载代码片段，比一股脑塞进User Prompt稳得多。

试试把思考链挪到工具输出里，不占对话上下文，或者干脆用摘要替换历史代码块。

压缩下历史轮次吧，MCP里把旧代码结果截断成摘要再喂，稳很多。

试试把历史对话截断只留最近一轮，或者用工具把代码先做摘要再喂给模型，别让上下文全被代码占满。

这问题太典型了，MCP多轮交互里context膨胀几乎是必然的，300行代码加思考链，几轮下来肯定爆。我建议别死磕Prompt精简，试试把代码切片分段送进去，每段单独让模型输出结论，最后再汇总一次，这样单轮上下文压力小很多。另外System Prompt里别堆太多格式要求，真正占地方的是历史对话，可以考虑用工具把之前轮次的输出做个摘要存下来，替换掉原始内容，效果比加“忽略历史”靠谱多了。

这问题我也踩过坑，MCP里多轮交互其实最怕的就是把历史全塞给模型。你那个“忽略历史错误”的结尾治标不治本，不如直接在工具层做截断，把超过一定轮次的对话摘要成关键词，或者干脆只保留当前文件相关的几轮上下文。

这问题太典型了，我最近也卡在类似的地方。你那个“先思考链再结论”的指令本身就会占掉不少token，代码一长确实容易爆。我的土办法是把思考链拆成单独一次调用，只把精简后的结论塞回上下文，相当于手动做一层“记忆压缩”。

另外可以试试让Claude先输出一段“代码摘要”替代完整源码进上下文，审查时只针对摘要提问。结构化的核心是别让所有信息都堆在同一个窗口里，不如把“审查步骤”拆成多个小工具调用，每个只处理一小段代码。

这问题太典型了，MCP里多轮交互的锅不能全甩给Prompt。你试试把思考链拆成独立工具调用，让模型先输出摘要再决定是否加载完整代码，别把全文塞进上下文。另外System Prompt里加个“只基于当前输入回答”的硬约束，比在User Prompt里补那句有用多了。

试试把思考链改成只输出关键判断节点，能省一半token，我这么干后崩的概率小多了。

别死磕prompt，代码先做AST裁剪或者只喂diff，上下文不够就上工具链压缩。

这问题我上周刚踩过坑，本质是MCP把整个对话历史都塞进上下文了，跟Prompt简洁不简洁关系不大。我当时是把代码审查拆成两轮，第一轮只让模型提取关键函数和风险点，第二轮再基于这些结构化摘要给结论，上下文占用能少一半以上。另外也可以试试在工具返回结果前用代码做个截断，只保留最近N行diff，比在Prompt里加“忽略历史”靠谱多了。

试试把思考链改成强制摘要模式，或者干脆拆文件分块调，300行确实太猛了。

上下文崩多半是历史消息堆太多，MCP里加个自动裁剪旧轮次的中间层试试。

遇到这种问题大概率不是Prompt写得不够好，而是你让模型在每轮都把整段代码重新塞进上下文做推理，窗口当然扛不住。建议把思考链压缩成几个固定的检查项关键词，比如“安全性/性能/可读性”，让Claude只针对当前diff输出结论，历史结论用变量存到MCP的memory里而不是靠对话保留。另外试试在工具层把超过300行的文件拆成函数级块，分多次调用，比硬调Prompt稳定多了。

试试把思考链拆成独立子任务，用工具逐段喂回去，别让历史全堆在主对话里，能省不少窗口。

这题我熟，之前做类似工具时也撞过这堵墙。你那个“先思考链再结论”的指令本身没问题，但MCP里每次工具调用都会把历史消息原样拼进去，代码稍长点token就爆了。我后来是直接在服务端做了层缓存，把上一次的分析结果摘要成一段话塞回上下文，而不是让模型自己记着全部代码，效果稳定很多。另外“忽略历史错误”这种指令其实挺鸡肋，模型该看还得看，不如试试在关键节点切断对话，用新会话单独处理大文件。

说到这个我可太有同感了，之前搞类似的工具也踩过这坑。你那个“先思考链再结论”的结构化指令，本质上是把推理过程全部塞进上下文里了，代码一长，中间步骤的token消耗直接翻倍，不崩才怪。我的建议是别把思考链留在对话里，让模型只输出最终结论，把“内部推理”改成“外部可见的简短摘要”，比如让它只输出风险等级和关键行号，这样能省一大截。另外MCP这种多轮交互，工具本身应该承担记忆功能，你可以在服务端把历史结论存起来，每次只传当前代码块和上次的总结，而不是把整段对话都丢给模型。我试过在工具层做截断，比如超过200行就拆成两段分两次调用，再用一个聚合节点合并结果，效果比硬调Prompt稳定多了。还有你那个“忽略历史错误”的结尾，其实挺鸡肋的，模型对长上下文的注意力衰减不是靠一句话能救回来的，不如直接在System Prompt里声明“只基于当前输入回答，不参考历史”，然后每次调用都重新初始化上下文。你要是实在想保留思考链，可以试试让它输出到外部文件，MCP里用资源协议回传，别让它在聊天窗口里刷屏，这样上下文窗口基本只吃输入和最终输出，能扛得住大文件。

试试在MCP这层把历史对话做个摘要再塞回去，别全量的喂，窗口压力能小不少。