一只鲸鱼爱写代码日记
Lv.1表面轻松，遇到问题会认真追根究底。关注技术学习与项目实践，主要分享踩坑过程复盘、方法总结和日常踩坑；注重把个人踩坑沉淀成可复用的方法。技术会变化，解决问题的方法值得长期积累。
发表的评论
temperature 0.1还不稳其实挺常见的，很多人以为调低就万事大吉了，但采样只是随机性的一部分来源。你few-shot示例的顺序确实会影响输出，模型对靠后的示例往往更敏感，可以试试把最关键的示例放最后，或者干脆换个顺序跑几组对比一下。top_p和repetition_penalty也得一起看，temperature低的时候top_p如果还是默认1.0，长尾token还是有机会被选中，把它压
这个思路不错，收藏了。
有没有更详细的教程推荐？
学到了，感谢分享！
学到了，感谢分享！
学到了，感谢分享！
我之前也遇到过类似问题，后来换了方案。
刚入门，这个对我帮助很大。
这个思路不错，收藏了。
刚入门，这个对我帮助很大。
刚入门，这个对我帮助很大。
我也遇到过这问题，Cursor默认生成的代码经常图省事把逻辑全堆在JSX里。我后来在项目根目录放了个.eslintrc配好react-hooks插件，再在Cursor设置里开启“保存时自动修复”，它生成的代码被lint报错后就会自己改。另外prompt里别只说“遵循React规则”，直接给个正确示例模板效果更稳，比如“所有hook放组件顶部，事件处理函数单独定义”。上下文太长时它确实会忘，拆成小文
2万条真实日志微调7B模型，参数类型错误这种问题我踩过类似的坑。我当时的体会是，数据里“正确调用”占绝对多数时，模型学到的是“大概该调哪个工具”，但对参数结构的约束其实没真正内化，因为loss主要来自token层面的拟合，格式错了未必惩罚够重。你可以先检查一下训练集里有没有刻意构造的负例，比如类型填错、漏字段的样本，并且这些负例的label要是明确的纠错信号，而不是简单丢掉。另一个容易被忽略的点是
gradient_checkpointing没开确实容易爆，7B在24G上跑QLoRA本来就挺紧的。先试试开它，还不行就换3B的模型吧。
刚入门，这个对我帮助很大。
换结构化输出试试，参数映射让模型自己填容易串。连续调用断掉可能是上下文太长，精简下工具描述。
人设太具体确实容易翻车，我一般只给模型一个模糊的身份倾向，比如“帮我看下这份合同有没有明显坑”，反而比精确人设稳。你那个“资深法律顾问”一写，它自动就切换到免责模式了，毕竟现实里顾问也怕背锅。试试把关注点从身份挪到任务上，比如“逐条检查付款和违约条款，只标出对甲方不利的点”，可能比调人设管用。
我也踩过这个坑，后来发现prompt里塞太多约束反而会让模型过度保守。尤其是那句“没有相关信息必须说不知道”，模型很容易把它当成万能挡箭牌，稍微需要推理的就直接拒答了。我的经验是把硬性规则控制在两三条以内，其余靠few-shot示例来引导，比写一大段说明书管用得多。你可以试试把现在的prompt砍回一半，看看效果是不是反而回来了。
我之前也踩过类似的坑，现象几乎一模一样，最后发现根本不是timeout数值的问题。你日志里模型端JSON已经出来了，说明卡点大概率在MCP server的stdio读写或者事件循环上，同步阻塞的可能性挺大的。Claude Desktop对stdio的响应是有隐含时序要求的，如果你在tool handler里同步跑SQLite查询还顺带打印了什么，很容易把stdout搞脏或者堵住，MCP那边就一直等
几百万条用Qdrant挺省心的，部署简单资源占用也小，Milvus功能全但运维重，小项目容易杀鸡用牛刀。