企鹅追着需求跑日记

我之前也踩过这个坑，后来发现问题往往不在chunk大小本身，而是检索策略太单一。你可以试试先做父文档切分，检索时用小块召回，再映射回大块喂给模型，这样能解决“太碎”和“漏信息”的矛盾。另外embedding模型最好跟你文档的语言和领域匹配，bge-m3对中文技术文档其实不差，但你可以测下query和文档的相似度分布，如果普遍偏低，可能是预处理时噪音太多。

几百万条对pgvector来说确实到临界点了，但400ms大概率不是向量索引的锅，先看看你的IVFFlat索引是不是没按数据量调好参数，还有list和probes的关系。我之前换过HNSW，倒腾一下能把p95压到100ms内，所以不一定非要迁移。不过如果你们的查询模式复杂，比如需要混合过滤，那Milvus这类确实省心，但运维成本也上来了，自己权衡吧。 --- p95 400ms有点夸张，我跑过

说实话我觉得问题不全在prompt上，这类对抗性逻辑本身就依赖对目标站点具体行为的实时分析，AI训练数据里的反爬案例都是通用的，它没法替你判断那个网站到底用的是哪套风控策略。你让它“加随机UA”，它可能就给你塞个fake_useragent库，但对方校验的可能是Header顺序或者TLS指纹，这根本不是prompt能解决的。我自己的经验是，把网站实际的请求头、cookie、还有那个token的生成

试试把工具调用当成一个有向图，用队列加状态机管理流转，比if-else清爽多了。

试试在prompt里加一句“只改我标注要改的地方”，或者用.git追踪代码，它乱改就直接diff回滚。

这个问题我最近也踩过类似的坑，试下来感觉光靠system prompt压格式真的不太够，模型在长上下文里很容易“忘事”。我现在的做法是把输出schema直接塞进最后一个user消息里，并且用XML标签把JSON示例包起来，比如“请严格按<example>里的结构返回”，效果比单靠system prompt稳定不少。另外MCP的工具调用确实会引入额外的系统消息，这些消息会挤占模型对指令的注意力，所以

说实话你这个情况我太熟了，bge-large-zh-v1.5本身对短文本的语义捕捉还行，但固定512字符切分遇到长短差距大的文档，很容易把完整语义切碎，或者把无关内容硬凑一块儿。我建议你先别急着换Embedding，试试按Markdown标题或者文档结构切块，把每个章节作为独立单元，再对特别长的段落做二次切分，这样至少能保住语义边界。另外你举例的“修改密码”和“密码复杂度”这种问题，本质上是语义相

老实说我觉得AI写CRUD和工具类是真顺手，但一碰状态机这种就得把它当实习生用，每一步都得喂给它明确的输入输出和边界条件。你那个定时任务死循环的问题，我猜是没告诉它任务执行完要改状态标志，这种隐含约束光靠注释真不行。我的土办法是把业务规则拆成几个小函数，每个函数单独让它写，最后自己再拼起来，比让它一口气生成整个流程靠谱得多。另外试试对话里直接贴错误日志和期望结果，比光给注释管用。

试试用MMR做多样性重排，既能控数量又能保留关键信息，比单纯调TopK稳多了。

这问题我也踩过坑，MCP本身不负责调度，工具并发返回时确实容易互相覆盖。我是用了个简单的请求队列，给每个工具调用加个时间戳和上下文ID，最后按用户问题里的实体来合并结果。你那个复合问题其实可以拆成两个子任务串行处理，或者用LLM先做意图路由，别一股脑全发出去。另外工具返回的结构最好统一成JSON再进上下文，不然格式乱了更容易打架。

说实话，你这个帖子我看了好几遍，感觉特别有共鸣。因为我自己从去年开始重度使用Cursor做后端开发，中间也经历过几乎一模一样的痛苦期，尤其是项目规模从两三千行往五千行以上爬坡的时候，那种“AI帮倒忙”的感觉会越来越强烈。我先直接回答你最核心的问题：不是你打开方式不对，而是Cursor这类基于大模型补全的工具，在项目复杂度跨越某个阈值后，它的工作模式和你作为人类工程师的预期会产生根本性冲突。这个阈值