小林Lab

非侵入式确实省心，但升级后重新注入的稳定性咋样，有没有踩过坑？

我跟你感受差不多，工具脚本随便让它写，核心业务逻辑真不敢直接粘。我现在是让它先输出单测用例，跑通了再考虑合并实现，但就算这样也得自己再过一遍事务和边界。本地模型对上下文理解还是浅，尤其是老项目里那些隐藏的副作用，它根本看不出来。反正就当个提速的草稿机，最终review不能省。

我之前搞过一个内部知识库的RAG，试了大半个月，最后发现固定长度切块真的是死路一条。文档结构差异太大，特别是技术文档里那些表格和代码块，按字符切最容易把上下文拦腰斩断。后来我改成按Markdown标题层级做语义切块，比如二级标题下内容超过800字就再按段落拆，段落太长才用固定兜底，效果立竿见影。重叠部分我反而没怎么花心思，因为语义切块的边界天然是完整的逻辑单元，重叠设个50-100字符只是为了防万

我最近也遇到过类似情况，Ollama在长上下文下确实比vLLM慢不少，感觉它的注意力机制处理长文本时效率不太行。你试试把项目文件拆成多个小文件，或者用RAG只检索相关代码片段喂进去，比硬塞8000行靠谱。另外Django ORM补全重复字段名可能是模型对Python语法理解不够深，你可以试试在prompt里给它看一个完整的ORM查询示例，明确告诉它“基于这个模式补全”，比调系统提示词直接得多。

同款问题，我之前调支付接口也是硬重试，后来发现MCP的tool调用规范里其实没细说这块，全靠自己设计。我的做法是重试前先快速探活一下备用API，同时把超时时间按场景拆成两档，第一档短超时直接切缓存，第二档才走完整重试逻辑，体感会好很多。另外建议把重试和降级的状态暴露给Agent的上下文，让它能感知并调整后续决策，不然每次都是盲试。

试试在召回后加一层rerank，比如用cross-encoder或者cohere的rerank模型，比单纯调chunk size管用多了。另外可以给每个chunk打上metadata标签（比如章节、关键词），检索时先按标签过滤一轮再算相似度，能砍掉不少噪声。还有个土办法是调低top-k，先拿5个结果看下质量，再决定要不要放宽。混合检索的话，可以试试BM25和向量检索的结果做加权融合，有时候关键词匹

太正常了，我前两天让Claude写个分页查询，它非要给我套上防SQL注入的过滤逻辑，我项目里根本用不上。后来我学乖了，直接在Prompt里写“只实现基础功能，别加额外防护”，不然它真能把代码给你写“完美”到没法看。 你现在这种感觉我特别懂，Prompt调教到后面其实是在跟模型的“过度理解”较劲。我的办法是给它限定具体函数名和参数类型，甚至直接贴一段现有代码风格让它模仿，这样反而比描述需求省事多了

我之前也卡在这块好久，后来发现核心问题不是prompt本身，而是没把任务边界和决策分支拆清楚。现在习惯用“状态机”思路写提示词，明确每个API返回后有哪些可能走向，再针对每种走向给具体指令，稳定性明显好很多。另外，如果模型总是跳步骤，可以试试在关键节点强制输出一个“中间结果”字段，比如先让模型填summary再填action，结构上卡住它。但说实话，不同模型对同样提示词的敏感度差异挺大，可能还是得

我也遇到过这问题，后来发现把types.ts直接拖进对话里当附件比贴路径管用，再配合一句“所有props必须从该文件import，禁止重新声明”能好不少。另外建议少用tab补全，它上下文太短，还是得让Composer把相关文件都读一遍再动手。还有个偏方是写个eslint规则把显式any标红，AI看到报错就会收敛很多。

我试下来感觉你猜的方向是对的，输入输出格式和依赖环境不交代清楚，AI真能给你编出个不存在的库来。我现在写prompt都会直接贴一段样例数据，再告诉它用相对路径还是绝对路径，代码跑通率明显高了不少。至于分步骤问，我倒是习惯先让它出个框架，再一步步往里面填逻辑，比一次性要完整脚本稳当。不过同求一个通用模板，总感觉每次写提示词也挺耗时。 --- 我自己的经验是，把“报错信息”直接扔回给AI比什么都管

我之前也踩过这个坑，工具调用失败直接让整个Agent崩掉确实很烦。后来我试了在Tool内部自己包一层重试逻辑，用tenacity库，装饰器一加就搞定，比手动写循环干净多了。不过要注意，重试次数别设太多，我一般数据库查询这类重试2-3次，API调用看情况，如果是对实时性要求高的就1次，不然用户等太久。间隔的话用指数退避，从0.5秒开始，乘2往上加，这样能避免服务端还没恢复就狂刷请求。另外你提到Cal

说实话你这个痛点太真实了，我前阵子做合同审查的RAG也差点被chunk逼疯。我的经验是别指望单一切分策略通吃，得先按文档类型分流——纯文本用500字带少量overlap确实容易断句，但我后来改成先按段落边界切，再对超长段落做二次切分，召回和连贯性平衡了不少。你说的embedding语义切分我也试过，效果时好时坏，尤其PDF里表格和代码块一多，切出来的东西就跟乱码似的，后来干脆单独写了个模块，遇到表

别死磕prompt了，直接后端用JSON模式加正则校验，格式乱就重试一次，稳得很。

八成就是context length默认才2048，ollama跑长提示词得改num_ctx。温度调低点也确实能稳些。

显存那块其实挺正常的，vLLM默认会预分配KV cache和CUDA context，7B int8在4090上吃到20G+不奇怪，尤其你设了0.9利用率，它不会真按8G来算。第二张卡没跑起来大概率是tensor parallel的通信后端没配好，或者环境变量没设对，你检查下CUDA_VISIBLE_DEVICES和nccl。速度20 tokens/s偏慢，可能跟量化方式还有max-model-l

这问题我太有同感了，之前让AI写爬虫也是一样，不指定就是裸奔。后来我琢磨出一个办法，就是把异常处理直接写进功能描述里，别单独说“请包含”，而是说“用try-except捕获FileNotFoundError和PermissionError，并在except里打印错误日志后继续处理下一个文件”，这样它就知道具体要防什么了。另外我试过在Prompt开头加一段“你是一个有十年经验的防御性编程专家”，效果

7B模型确实容易在长指令和复杂约束上“失忆”，我试过把few-shot例子压缩到2个以内，并且把关键要求拆成短句放最后，效果比一大段角色设定稳很多。另外你问“介绍公司产品”这种开放问题，模型本身就容易自由发挥，不如直接改成“根据以下三条产品信息，用三句话回答：1...2...3...”，把范围焊死。还有个坑是别让模型“选择”要不要遵守资料，直接说“只允许使用资料里的内容”会更强制一点。你如果试了还

我遇到过几乎一模一样的情况，最后定位到根本不是缓存和chunk的问题，而是ReAct的推理路径被历史对话带偏了。你想想，Agent在拆子查询的时候，其实是在基于已有上下文做“猜测”，如果之前的对话里没有关于新文档的任何线索，它压根不会生成指向新内容的query，哪怕向量库里已经有数据了。我当时试了个笨办法，把整个会话清空，强制Agent重新从system prompt里读一遍知识库更新说明，结果立

10万条其实不大，直接上HNSW别纠结，内存贵点但省心，efConstruction调个200左右够用了。

测试集和线上query分布差异这么大，召回率掉是必然的，建议先按真实用户query聚类看看短板再调chunk。 bge对口语化表达本来就吃力，试试在切分前加query改写或者混合检索，别光赖embedding。