RAG项目里AI编程助手老改错代码，是我的提示词问题还是它真不行？

说实话我最近也在折腾类似的RAG项目，用的是FastAPI加LlamaIndex，也遇到过Cursor改代码改歪的情况。我觉得问题可能不光是提示词，很多时候是AI对“chunk”和“document”这两个概念的理解跟你的项目上下文脱节，它看到retriever返回的其实是整个document对象，就自作聪明去拼了。你可以试试在提示词里明确告诉它“Chroma的get函数返回的metadata里有个chunk_index字段，你要用这个字段去映射原始文本列表”，最好直接把那几行关键数据结构的代码贴给它看，光描述不够。另外我有个土办法，就是先让它生成一个最小的测试用例，你手动跑一遍看输出，再让它基于这个失败用例去修，比反复改提示词管用。当然GPT-4o-mini本身在复杂指令跟随上确实不如大模型稳，如果你预算允许，局部逻辑用o1-mini或者Claude试一下可能更靠谱。还有个小坑，Cursor的自动补全有时候会覆盖你手动写的部分，建议把retriever相关的代码单独拆个文件，减少它乱改的几率。

这情况我也踩过坑，cursor对“chunk”和“document”的理解经常取决于上下文里有没有明确的变量名，你光在提示词里说“引用原文片段”不够，最好直接把retriever返回的变量结构贴给它，比如retrieved_docs[0].page_content这种。另外它确实容易“偷懒”去读整个document，因为那样更省事，你得在代码审查时重点卡这一点，而不是反复调提示词。还有个思路是直接把你要的逻辑写成一个小函数塞给它，让它照着改，比纯文字描述稳定多了。

说实话我觉得这锅一半得给Cursor背，一半得怪RAG本身的抽象层级。你让它“返回source chunk”，但LangChain里Document和Chunk的边界本来就很模糊，尤其Chroma返回的metadata里如果没有显式存chunk_id，模型很容易就把整个Document当成最小单位。我最近在搞类似项目，发现一个土办法挺管用：直接在retriever的返回结果里强行加一个字段，比如把chunk的内容hash一下塞进metadata，然后提示词里明确说“引用这个hash对应的文本片段”，而不是靠语义描述，AI助手犯错率明显降了。另外你试试把“参考已有代码风格”这种模糊指令换成具体例子，比如直接把retriever的调用链和输出格式贴进提示词，让它照着改，比说一百句“只改retriever部分”都强。说到底，AI编程助手对RAG这种多组件数据流项目的理解还是太浅，它经常“聪明地”帮你重新设计逻辑，而不是执行你脑子里的精确改动。你要真想省心，建议把检索和生成彻底解耦，先单独跑retriever拿到chunk，再喂给LLM生成，这样Cursor只需要改中间那段胶水代码，错误率会低很多。当然，如果你用的是GPT-4o-mini，可能还得考虑是不是模型上下文窗口太小，导致它“看到”的原始文档信息太多，反而忽略了chunk的边界。