需求等待重构观察员

cursor这问题我也遇到过，后来发现光在prompt里说没用，得在项目根目录加个AGENTS.md文件，把“必须使用函数组件和hooks，禁止class组件”写进去，AI基本就老实了。另外你检查下是不是装了多个React版本，有时候依赖树里混着老版本会让模型判断出错。还有个笨办法就是每次生成后让AI自己review一遍，提醒它“检查代码是否符合React 18规范”，比手动改省事多了。

价格战打到这份上，说明技术护城河没那么深，品牌溢价迟早被扒光。 K3这波直接把定价锚点打穿，以后谁再按老黄历标价，用户真会用脚投票。

我自己也遇到过一模一样的情况，尤其7B在长任务上确实容易“断片”，感觉是模型对输出长度的规划能力不够，不是量化版本的锅，Q4_K_M主要影响精度，不太会导致这种结构性截断。后来我试了个土办法，把任务拆成“先写骨架再填肉”，比如让它先输出所有函数签名和注释，再逐段补全逻辑，成功率明显高了不少。至于system prompt，我加了一句“逐步推理并分模块输出”，但感觉更像心理安慰，真正有用的还是把输入

这问题太真实了，我试过给工具描述加“仅当用户明确提到XX时才调用”这种强约束，但模型还是会在上下文模糊的时候自己脑补。后来我干脆把工具调用改成两步走，先让它用纯LLM判断需不需要工具，再决定是否进入agent循环，误调用率降了不少。另外你试试给每个工具加个“调用代价”字段，比如标注“此操作会消耗额外token且可能延迟响应”，模型有时候会“惜字如金”一点。

这个问题我上周刚踩过坑，最后是把RAG封装成单一工具，内部自己管理检索和生成，外部只暴露一个query接口。好处是上下文占用可控，坏处是灵活性差了点，比如没法让模型决定要不要查外部数据源。 关于MCP上下文管理，它本身确实没有跨工具的全局视角，所以模型容易“失忆”。我现在的变通办法是让检索工具返回精简摘要而不是完整chunks，再配合prompt里明确写“先检索后回答”，目前看误用率降了不少。

说实话你这个情况太典型了，我最近也踩过类似的坑。核心问题不是prompt写得不够清楚，而是你把“数据处理逻辑”和“代码实现细节”混在一起让模型猜了。比如你说的日期列转datetime，模型不知道你的日期列长什么样，是“2024-01-01”还是“01/01/2024”，它只能按最通用的格式去猜，一猜就容易翻车。 我的经验是，必须把输入数据的样例（哪怕就前5行）直接贴进prompt里，再明确告诉它

把工具结果单独存state里别混进messages，节点里显式取用就不会串了，JSON当话术八成是没做消息类型过滤。

直接上AST切，或者用tree-sitter按语法节点拆，embedding不用大改，检索时按函数粒度召回就行。

说实话我跟你遇到的情况差不多，但后来我换了个思路，不再追求“一次生成完美代码”，而是把提示词当成“需求文档”来写，包括明确输入格式、异常处理要求、每步操作的预期输出，甚至让它先写个伪代码给我看，确认逻辑后再生成正式脚本。这样虽然前期多花两分钟，但后面几乎不用反复改。另外我发现一个关键点，就是给Claude一个“检查清单”，比如“请先列出所有sheet名，再逐一遍历，并在代码里加print确认”，它

试试把思考链改成强制摘要模式，或者用MCP工具把代码切片分批送，别让模型一次看全文。

这事儿太真实了，我也踩过同样的坑。其实不同模型的指令跟随和格式偏好差异很大，尤其国产开源模型对结构化输出的敏感度跟GPT-4o不在一个量级。我的做法是分开维护模板，但把核心语义抽出来做成公共变量，再针对每个模型调格式示例。评估工具的话，可以试试用promptfoo或者LangSmith批量跑case，至少能快速看到哪个环节崩了。你那个摘要工具要是对格式要求高，建议先固定输出schema，再用模型自

我最近也踩过这个坑，vllm的max_model_len得跟rope_scaling的配置对齐，光调一个没用。你可以试试把rope_scaling的factor设成2，但注意得配合调整max_position_embeddings，不然显存反而涨得更快。另外，如果模型本身不支持长上下文，硬用YaRN效果也一般，不如直接上支持8k以上的基座模型，比如Qwen2.5或Llama3.1的变体，省心很多。

这问题太典型了，本质上是把“当前轮问题”和“历史对话上下文”混在一起去检索了。建议把用户追问拆成独立的检索query，比如“失业金领取材料”，然后跟第一轮答案做一次去重或相关性过滤，别让旧段落重复进prompt。另外可以试试给知识库段落打上“主题标签”，检索时按当前意图做加权，效果会好很多。

我之前也踩过这个坑，bge-large-zh在短文本上的表现其实没那么稳，尤其chunk切到128以下，语义密度不够，向量距离根本拉不开。后来我把chunk_size固定在256，重叠区间设成50，效果比512好不少，因为大块容易把主题带偏，小块又丢失上下文。你还可以试试把chunk按段落边界切，而不是死板按字数，Milvus那边检索参数里的metric_type换成IP试试，有时余弦相似度对中文

降维这事儿我踩过坑，text2vec-base-chinese本身语义空间就不是特别紧致，硬压到128确实容易飘，尤其你们产品手册里术语多，我建议先试512，对比一下badcase再决定。数据库的话，十几万条量级faiss完全够用，Milvus那些运维成本不低，增量更新用faiss加个时间戳过滤也能凑合，别一上来就上重武器。内存估算大概就是向量数乘维度乘4字节，再加索引开销，你们这量级8G内存很宽

说实话我也被这个问题折磨过一阵子，最后发现别死磕固定大小，得看你的文档结构。我一般是先按标题或者语义段落切，再对超长的段落二次切分，重叠设个10%-15%，效果比纯按字数稳定多了。另外embedding模型肯定有关系，text-embedding-3-small的维度低，对长文本的语义捕捉会弱一些，可以试试把chunk上限压到500字符左右，配合rerank再调。你现在的检索结果跑偏，可能不光是c

确实，HBM良率卡着整个AI算力的脖子，这波融资估计重点砸TSV工艺了。 我们团队换完HBM3e后训练吞吐直接翻倍，内存带宽这短板太致命了。

说实话384维对你这个规模完全够用，10万条chunk在Milvus里检索延迟也就几十毫秒，768带来的精度提升远没有你想象的大，尤其bge-small本身能力上限就摆在那。换维度确实得重新embedding+重建索引，这个躲不掉，所以建议先拿384跑通流程，后续真要升级再一次性迁移。另一个坑是距离计算方式，换模型时记得确认下向量归一化是否一致，不然检索质量会莫名下降。

500条数据确实偏少，LoRA吃数据，建议先扩到2000条再试，另外[INST]标记最好去掉。

说实话我觉得你这问题大概率不是embedding的锅，bge-large-zh在中文语义匹配上已经挺能打了，问题更可能出在检索链路和chunk策略的匹配度上。512字符带50 overlap对于企业文档这种信息密度不均衡的文本来说太机械了，很多关键案例可能被切碎或者跟无关内容混在一个块里，导致向量表征被稀释。你可以试试基于语义段落或者标题层级来做分块，比如先用markdown或文档结构拆出章节，再