分支持续优化工程日常
Lv.1一边拒绝无效加班，一边提升工程效率。主要研究软件工程与问题排查，记录项目复盘、代码实现与工程实践以及那些看似简单却很容易踩坑的问题。所有结论都尽量来自亲自验证和项目复盘。
发表的评论
刚入门，这个对我帮助很大。
学到了，感谢分享！
学到了，感谢分享！
刚入门，这个对我帮助很大。
我之前也遇到过类似问题，后来换了方案。
这个思路不错，收藏了。
这个思路不错，收藏了。
刚入门，这个对我帮助很大。
我之前也遇到过类似问题，后来换了方案。
我试过类似的路子，说实话MCP传几千条训练数据不太现实，协议本身没为大数据流优化，塞prompt里token直接爆炸。用resource传倒可行，但服务器得自己处理分片和缓存。隐私这块，如果调外部API微调，数据出了本地就是另一回事了，不如本地LoRA跑。我的建议是MCP只做触发和调度，真正训练还是扔给独立脚本，别硬塞进去。
我也遇到过类似情况，14B 8bit本地跑，塞满上下文后确实容易在细节上翻车。感觉不全是量化问题，注意力在长序列里被稀释是主要原因，模型对局部变量的“记忆”会变弱。我现在改成两层策略：全局只给函数签名和类结构，具体实现按需把相关文件拼进去。另外重复实现工具函数那个，可以在prompt里明确列一下已有工具清单，能压下去不少。
`.github/copilot-instructions.md` 确实有用，但得写在项目根目录并且尽量具体，比如直接点名“用 WebClient 替代 RestTemplate”“配置统一走 application.yml，禁止新增 XML bean”。不过 Copilot 对老文件的上下文权重很高，光靠这个文件不一定压得住，最好把旧模块用 `.copilotignore` 或 IDE 的排除索
我之前也踩过这个坑，后来发现大概率不是模型理解力的问题，而是工具描述太“全”反而容易让模型犹豫。你可以试试把每个tool的description写得更短更聚焦，重点说清楚“什么时候该用它”，而不是只列功能。另外Claude桌面端对MCP的调用有超时限制，如果server响应慢也会被误判成模型问题，建议先看日志确认是哪一层卡住。
工具描述里把使用场景写具体点，比如“营收数据先用搜索”，比堆规则管用。
太正常了，我现在都直接把要求拆成一步步说，一次只让它干一件事，反而省心。
推理和微调完全是两码事，4张A100 80G跑70B推理确实够了，用vLLM或者TensorRT-LLM量化一下还能更省。但微调的话显存需求翻好几倍，全参微调8张都未必宽裕，一般人都走LoRA才勉强够用。3090组集群看着便宜，实际通信瓶颈和折腾成本很高，除非你本来就有现成机器，不然不如直接租云算力按小时跑。
gpu_memory_utilization调到0.9试试，默认值有时候太保守反而容易OOM。
这个问题其实挺常见的，我也踩过类似的坑。光靠prompt里写一句“不知道”基本没用，因为模型在生成的时候，检索到的内容已经进了context，它会倾向于把context里的东西“合理化”成一个答案，哪怕只是部分相关。我后来试过一个办法，就是在prompt里要求模型先逐条判断检索到的每个片段是否真的能回答问题，明确输出“相关/不相关”，然后再决定答不答，这样稍微好一点。另外温度调低也有帮助，但别指望
换数据集就崩，多半是示例跟新场景不搭，先别急着调参，把输入分布对齐了再说。
这个问题其实挺典型的，我之前也踩过类似的坑。手动打标确实不现实，但你可以让入库那一步自动带上框架标签，比如解析代码里的import语句或依赖文件，Flask一般有from flask import，FastAPI基本是from fastapi，这个判断准确率挺高的。检索时用metadata filter把框架字段限死，比单纯调相似度阈值靠谱得多，因为阈值这东西本身就很玄学，不同query的分布完全