认真做复盘创作局
Lv.1关注内容创作，长期记录案例拆解、设计系统建设和从需求到交付的完整过程。偏爱把复杂问题拆成清晰步骤，希望用清晰的方法帮助产品与业务更高效地落地。
发表的评论
我最近也遇到了类似情况，尤其是项目里同时开着十几个文件的时候，补全明显开始“精神分裂”。后来发现把无关文件全关掉，只留当前模块和依赖的模型定义，准确率能回来不少，你可以试试这个办法。 另外我觉得它可能不是变笨，而是上下文窗口的注意力被稀释了，特别是FastAPI这种依赖类型推断的代码，它一旦抓错一个字段，后面就跟着错。换个工具未必能根治，Cursor我也试过，新鲜感过了其实差不多。 我现在反而
说实话我也踩过这个坑，base64塞进模板里模型根本分不清那是图像还是乱码。我的做法是在server端直接预处理，把图片调成低分辨率再转成描述性文本（比如用现成的caption模型），这样模板里只留纯文本和结构化数据，模型就稳多了。 另外你可以在模板里给工具返回加个明确的标签，比如用`[IMAGE_DATA]`和`[JSON_DATA]`包起来，然后在system prompt里强调“遇到IMA
遇到同样的问题，我后来是直接用torchdata的zip组合器把图像和文本的DataLoader拼在一起，batch维度会自动对齐，内存也稳了。如果自定义Dataset，记得在__getitem__里返回字典，然后collate_fn里统一处理padding，别让长度不一致的文本炸掉batch。你试试把tokenize放到collate_fn里，不要在getitem里做，这样resize和归一化也
八成是MCP的环境变量没传进去，试试在torchrun命令里显式指定--master_addr和--master_port。
最近刚在MCP上试过Copilot和Cursor，Copilot在IDE里用MCP协议补代码确实顺，但写复杂函数时经常跑偏，得反复调prompt。Cursor对上下文理解好一点，尤其是跨文件重构时能跟上思路，不过对MCP终端集成支持一般，得靠插件。你试过把MCP server挂到本地再配Cursor吗？感觉写单元测试时准确率高不少。
 哈哈，这个问题太真实了，我当初刚用Cursor的时候也踩过同样的坑。xlrd和urllib2这俩简直是AI的“祖传代码”了，尤其是urllib2，Python 3都出来多少年了它还在推，服了。 其实核心原因就是训练数据的时间切片问题，GPT-4的知识截止日期大概在2023年，但很多库的更新迭