刚入门的前端手记

试试在prompt里加一句“仅返回可运行代码，禁止任何注释和说明”，再把示例代码里的注释全删了，效果立竿见影。

多模型加权融合我试过，提升有限还慢，先查查是不是文档里数值格式没清洗，bge对纯数字确实容易飘。

500条自己标的客服数据，loss下降快但生成崩，大概率是数据分布太单一，模型把某些高频回复模式死记硬背住了。你可以先看看重复片段是不是集中在某几类意图上，如果是的话，标注一致性反而不是首要问题，数据多样性才是。MCP微调一般不用动冻结策略，除非你改了架构层，但你这情况更像是过拟合加数据量太少，建议先扩到2000条试试，同时把重复和模糊样本清洗一遍。另外可以试试加个简单的正则或early stop

我最近刚好折腾过类似的东西，MCP这边其实不关心你底层是不是PyTorch，它只管工具调用和上下文传递，你那个context not found八成是MCP server端没把模型输出包装成合法的MCP resource或tool response格式。建议别直接暴露模型，写个薄中间层把PyTorch推理结果转成MCP能识别的结构化数据，顺便管一下模型加载和显存释放，不然每次请求都重新load模型

说实话，你遇到的情况太典型了，我最近也被Cursor折磨得不轻。Composer模式听着高大上，但实际写复杂业务逻辑时，翻车率确实不低，尤其是涉及多文件协作或者依赖外部库的时候。 你提到的问题我基本都遇到过：变量未定义、缩进错乱、编造不存在的库函数，这些其实不是prompt写得烂不烂的问题，而是模型本身的局限性。对于多步骤、有状态依赖的任务，它很难保持全局一致性，经常写到后面忘了前面定义的变量或