文档别再改了观察员

我最近也踩过这个坑，后来干脆把项目进度拆成独立的markdown文件，每次写周报前用代码自动读最近的几条记录塞进prompt里当参考，比手动更新system prompt省心多了。你可以试试用向量数据库存历史周报，按日期和关键词检索相关段落，效果比硬塞全文稳定。另外记得在prompt里明确让它“基于以下历史内容续写”，不然模型还是会自己发挥。

这问题太真实了，我上个月用Cursor写个爬虫也踩了同样的坑，它给我整了个urllib2，我差点以为自己穿越回2015年了。后来我发现光在系统提示里写“用最新库”没用，它还是会按训练数据里的高频模式走。我的土办法是直接在代码注释里把关键库的版本号写死，比如“用pandas 2.x的read_excel，别用xlrd”，这样它基本能听话。还有个技巧是让它先跑一遍，报错了再贴错误信息让它自己修，比一开

说实话这事儿我踩坑踩得比你惨多了，后来干脆放弃在prompt里跟它讲道理，直接写了个MCP的工具函数，让AI每次装包前先跑一条命令读取当前环境的pip freeze，再结合requirements.txt做diff，把版本冲突的选项直接剔除掉再给模型看。效果立竿见影，但副作用是每次对话多出两轮工具调用，稍微慢点。另外我觉得你那个思路反了，与其在MCP server端过滤，不如在工具返回结果里带上“

这个差距我踩过同样的坑，大概率不是维度的问题，而是预训练任务和领域数据分布决定的。text2vec-base在通用语义上还行，但对“客服场景”这种带意图的查询，它的表征空间没对齐到业务语义上，ada-002在泛化性上确实强一截。建议你先别急着全量重embedding，拿一小批数据对比下两种模型的top-k结果，看看是不是只在特定查询类型上差异大。如果业务数据里技术文档占比高，text2vec反而可

这问题其实挺典型的，本质上是few-shot在RAG链路里到底该扮演什么角色——是教模型“怎么回答”，还是“怎么利用检索结果”。 我自己的实践下来，你说的第一种（query+answer）在通用场景下确实容易翻车，因为模型学到的是“直接输出格式”，而不是“先看上下文再输出”。尤其GPT-4这种指令跟随能力强的模型，你给几个纯query-answer对，它容易把few-shot当成“标准答案模板”

这其实是当前代码生成模型的一个通病，因为它们训练数据里充斥着防御性编程和教学式风格。你可以试试在Cursor的Custom Instructions里显式定义“生产级代码规范”，比如禁止中文注释、限制单行变量数，或者用`--style pep8`这类参数约束。实在不行就写个后处理脚本，用正则把`# 中文`这种注释批量干掉，比调prompt稳定得多。