持续研究品牌随身笔记

这问题太真实了，我试过在系统提示词里直接写“组件props严格遵循最小化原则，不得添加未明确要求的属性”，然后把常用组件接口文档贴进去，能好一点。不过说实话，Cursor对上下文的理解还是比人差远了，有时候你给它看一个现有组件的写法，它才会照着模仿，单靠嘴说确实不稳定。

说实话你这思路我踩过一模一样的坑，Qwen2.5的隐藏层输出本质上是为生成任务优化的，跟专门做语义匹配的embedding模型在特征分布上差别挺大，所以检索效果不稳定太正常了。池化和归一化确实会影响结果，但就算调好了也很难追上专门的embedding模型，毕竟人家训练目标就是拉近相似样本的距离。建议直接换bge-small或者gte-small这类轻量模型，几百MB跑本地完全够用，检索质量提升会非

1亿条768维这个量级，单机跑确实有点吃力了，但不是没救。你现在的核心问题大概率不是索引类型选错，而是内存带宽和CPU缓存命中率撞墙了，HNSW在超高维数据上构建图结构本身就吃内存，而且查询时随机访问内存的代价比IVF系列高不少。我个人建议先切回IVF_FLAT或者IVF_SQ8试试，SQ8能把内存砍掉四分之三，召回率损失在可接受范围，同时把nlist调成你数据量的平方根量级，nprobe从64开

试试把onnx的opset调到17以上，然后trt那边min/opt/max三个维度必须严格对应实际输入范围，我之前就是这么解决的。

这loss水平对7B代码模型挺正常，试试把alpha调成32或换带缩放基线的数据集看下。

试试把对话历史先做一轮意图压缩再拼接，能少很多噪音，或者直接看下MemGPT那套分层思路。

torch.compile对动态shape的支持其实比JIT好不少，它有专门的dynamic shape模式，但默认开启的话编译开销会摊薄到每次输入变化上，你可以试试把mode设成max-autotune或者限一下动态维度。自定义注意力掩码只要不是纯Python控制流，一般都能被graph break处理，顶多回退到eager，不会报错但加速效果会打折。我建议你先用torch.compile的pr

Qdrant上手快但集群扩容时坑不少，Milvus功能全可运维成本高，小团队慎选。 Milvus坑在依赖太多，部署起来头大；Qdrant单机性能不错，但中文文档少得可怜。

max_iterations设小点，输出格式锚死，再加个中间结果校验，跑偏概率能降不少。

说实话我觉得你现在的瓶颈大概率不在向量库本身，而是embedding和检索策略的问题。ChromaDB在几千篇文档的规模下性能不会差到哪去，准确率飘更多是分块方式或者向量模型对长文档语义捕捉不够。你可以先试试换更强的embedding模型，比如bge-m3或者e5-large，再配合混合检索（关键词+向量），说不定成本最低的提升就来了。 真要换库的话，Milvus单机版在Mac上跑起来其实没想象

混合召回对rerank延迟影响挺大的，建议先拿bge做主力，text2vec当候选补充，实测多路召回得加缓存。 单卡T4跑bge-large其实能接受，把分块调小点，速度能上来，召回率也比text2vec稳。

说实话我之前也卡在“AI只建议不执行”这个点上，后来发现MCP更像是个“读权限”的增强，真要让Cursor跑命令还得靠它内置的终端工具或者自定义agent，不是靠MCP本身。你连不上本地Node服务大概率是环境变量或者权限问题，试试把server跑成后台进程再让MCP走http协议，别用stdio模式，能省不少麻烦。至于自动修TS报错，我现在的做法是让AI先改代码，然后我手动触发一次tsc检查，完

我最近也踩过这个坑，光靠LLM打分做路由确实容易来回踢，后来直接加了全局max_rounds兜底，但更关键的是让每个Agent在内部判断时带上“置信度阈值”，低于阈值就强制返回一个明确失败信号，而不是继续传递。另外你可以试试给每个Agent配一个固定的“职责边界”说明，让LLM在回答前先自我检查是否超出边界，这样比事后判断终止要干净得多。你现在的工具函数是每个Agent独立调用的，还是共享的？我怀

试试把文档按章节拆开分段喂，每段强制输出“数字+上下文”，最后再汇总，漏数据的情况会好很多。

其实你可以试试在项目根目录放一个`.cursorrules`文件，把你们现有的组件写法、禁用泛型或者Hook的规则直接写进去，比每次prompt管用得多。另外我猜它“想当然”是因为训练数据里好代码都长那样，你可以给它一两个你们项目最典型的组件当few-shot示例，它模仿能力比听指令强。不过说实话，对老代码库的适配确实弱，我这边最后是直接让它只改我圈出来的代码块，别让它碰整个文件。 --- 我

固定字符切分对你这场景确实容易翻车，bge-large-zh-v1.5本身对短文本和长文本的表征差异挺大的，512字符塞进去，语义重心容易被长段落里的无关信息带偏。我建议你先按Markdown标题或者文档结构切块，把每个小节当独立单元，这样至少保证每个块有完整主题，再对超长的块做递归切分，但切之前最好先看下Embedding的相似度分布，别盲目套参数。另外问“如何修改密码”召回“密码复杂度要求”，

我是直接写单元测试当prompt，AI改完必须过测试，没过就让它接着修，效果还行。

同感，这问题太真实了。我试过把prompt拆成“角色+背景+任务+约束+示例”五段式，虽然不算万能但至少能减少随机性。你可以看看OpenAI的官方指南里关于“分隔符”和“思维链”的用法，对结构化很有帮助。另外长上下文建议用“分块+总结”策略，一次性塞太多逻辑容易跑偏。

说实话看到你这个loss曲线我第一反应是学习率可能给高了，LoRA微调本身参数敏感，2e-4对Llama3来说容易震荡，尤其你batch size才4，梯度估计噪声比较大。我之前试过类似场景，降到1e-4甚至5e-5之后loss才慢慢往下走，你可以在前几百步先跑个warmup看看曲线形态。另外数据集这块，客服问答对如果只是纯文本拼接，没有用chat template或者特殊分隔符，模型可能根本分不

大概率是微调把embedding分布拉偏了，试试冻结embedding层或者用两阶段训练。