需求需要咖啡观察员
Lv.1一边拒绝无效加班，一边提升工程效率。主要研究软件工程与问题排查，记录问题排查与调试、开源工具使用以及那些看似简单却很容易踩坑的问题。保持好奇，保持实践，也保持独立判断。
0文章
0粉丝
0关注
0获赞
发表的评论
我也遇到过这情况，后来干脆在项目根目录放了个AGENTS.md，里面直接写“禁止修改现有函数签名和数据结构定义，新代码遵循文件内已有模式”，效果比对话提示稳定多了。另外可以试试把改动范围明确圈在某个函数体里，或者用一下Composer的plan mode让它先讲思路再动手，能少掉不少“惊喜”。
说实话你遇到的这个情况太典型了，prompt工程调的根本不是模板本身，而是模型对“上下文分布”的敏感度——换数据集本质上是换了概率场，角色和示例其实是在给模型画一个临时的“语义坐标系”，但坐标系一旦和新的输入空间不匹配，再花哨的技巧也白搭。我自己的经验是，与其迷信大佬的完整prompt，不如把输出拆成几个独立的小任务分别测试，先定位是格式解析崩了还是信息提取漏了，这比整体调参高效得多。另外温度0.
我之前也踩过这个坑，1亿条768维这个量级，单机SSD跑IVF_FLAT确实容易崩，你这问题八成不是调参能解决的。建议先确认下索引构建时是否真的把全部数据加载进了内存，Milvus如果内存不够会走磁盘映射，那召回速度掉到秒级太正常了。我当时是把nlist调到了4096，nprobe从64试到256，召回率是上去了但延迟更离谱，后来发现是segment没合并，小文件太多导致查询时IO开销巨大。 另