移动开发笔记

我之前也遇到过类似问题，后来换了方案。

这个思路不错，收藏了。

写得挺好，建议补充一些性能数据。

写得挺好，建议补充一些性能数据。

我之前也遇到过类似问题，后来换了方案。

确实，Cursor不会自动读你项目里的规范，得手动把eslint配置或几个典型组件贴进prompt里，它才能照着来。

维度不是越高越好，关键看模型本身，中文技术文档建议试试bge-base或m3e，几百维就够用了。

我后来在项目根目录放了个`.cursorrules`文件，把“禁止新增抽象层、禁止用render props、组件超过80行就拆”这些硬性规则写进去，效果比在prompt里临时强调稳定多了。另外可以试试把现有最简单的那个组件文件在对话里@出来，让它照着这个风格改，光贴代码片段它容易忽略上下文。不过说实话，对已有代码库的适配确实偏弱，我现在复杂改动还是自己写，只让它干重复性的活。

硬编码兜底说明任务拆解太粗了，先把分支收敛到模型能选对再谈智能吧。

你这个问题太典型了，我上个月刚踩过一模一样的坑。纯向量检索对“2024年Q3财报”这种带时间约束和实体约束的query其实很不友好，embedding会把“Q2财报摘要”和“Q3财报”算得特别近，因为语义结构几乎一样。我的做法是在检索后面加一层rerank，用bge-reranker或者cohere的rerank接口，先粗召回50条再精排到5条，效果提升很明显。另外你可以考虑在metadata里把

8G显存跑8B的4-bit量化确实挺紧的，7.5G占用说明基本吃满了，多并发OOM很正常。我之前用3070跑Qwen 7B的Q4_K_M也差不多这情况，后来换成Q3_K_M能压到6G出头，但说实话输出质量下降还挺明显的，尤其是长文本生成容易崩。如果你只是内部小团队用，其实可以考虑限制并发数为1或者2，配合llama.cpp的continuous batching，单请求速度反而更稳。vLLM确实省

我们去年也是几百万条中文数据，最后选了Milvus，运维确实有点门槛但社区文档挺全，装个单机版跑起来没那么吓人。中文场景主要看你的embedding模型，数据库本身对分词没啥影响，这块不用太担心。Pinecone延迟确实稳，但量大了账单涨得飞快，可以先拿Milvus试跑一下再决定。

我也踩过这坑，后来只留GitHub和文件系统两个，顺滑多了。工具多了AI反而选择困难，跟人一样。

数据里加些噪声样本，再用格式校验层兜底，别全指望模型自觉。

我也被ReAct循环坑过，感觉问题多半出在工具描述和中间步骤的反馈上。GPT-4看到模糊的observation就容易自己脑补，然后开始自言自语或者重复调用。建议把每个tool的description写死一点，明确告诉它什么条件下必须停。另外可以试试把飞书读取和Notion写入拆成两个独立的chain，别让一个agent扛太多事。

维度真不是越高越好，我拿1536和768的模型在同一批文档上跑过，召回差距其实很小，关键是你的chunk切法和检索策略。换模型肯定要全部重跑向量，两套模型空间不通用，PCA降维能省存储但会损失一点语义，除非Milvus扛不住否则没必要折腾。实际项目里我基本从头到尾锁死一个模型，中途换成本太高，调参不如去优化rerank那一步。

我之前也踩过这个坑，LangGraph里多个节点并行写同一个state字段，后写的确实会把先写的覆盖掉，checkpointer只能保证持久化，解决不了并发写的冲突。你可以试试给每个Agent的输出单独开一个字段，别都往summary上塞，最后再用一个聚合节点去合并。或者干脆用subgraph把各自的状态隔离起来，只在边界传必要的数据，会清爽很多。

几万条文档其实不算大，Chroma召回不行未必是库的锅，先看看embedding模型和切块策略是不是拖后腿了。我之前也遇到过类似情况，换成bge-m3加合理的overlap之后，同样的Chroma召回率提升挺明显的。Milvus确实重，etcd加minio一套下来，单机跑着心里都不踏实，小项目真没必要上这个。Qdrant我用过一阵，单二进制部署很省心，过滤和payload检索比Chroma强不少，

Prompt管不住顺序的，模型本质是并行预测，工具编排还得靠客户端做依赖控制。

你这种情况我也遇到过，ResNet18这种结构在ONNX里确实经常跑不过原生PyTorch。FP16在PyTorch里走的是cuDNN高度优化过的kernel，而onnxruntime的CUDA EP对fp16支持其实挺一般的，很多算子还是回退到fp32跑，中间来回转换反而更慢。建议你先用fp32导出对比一下，如果fp32下ONNX就不慢，那基本就是精度的问题。另外可以试试TensorRT EP，