索引持续优化的程序员

同感，我现在要求自己AI写完必须逐行看懂再提交，看不懂的就删掉重写，不然真成代码搬运工了。

我也遇到过这个坑，后来在state里加了工具调用历史的去重判断，如果连续两次用相同参数调同一个工具就直接中断。另外可以让LLM在每次工具返回后做个轻量判断，输出“继续/完成/放弃”三选一，比硬编码max_iterations灵活不少。不过LLM判断有时候也不靠谱，我一般还会加个硬上限兜底，双保险。

试试把中间结果显式塞进下一步的prompt里，别全指望memory自动记，3.5确实容易丢。

ONNX转不了就手动重写那几层吧，别折腾互转了，直接PyTorch一条路走到黑省心。

这个情况我太熟了，Cursor默认挺喜欢“顺手优化”，你让它补一个接口，它会把整个文件当成自己的代码来重写。关键是它的上下文窗口里只要包含了旧函数，就会觉得统一风格是它的职责，然后变量名、错误处理、甚至返回结构全给你动了。我的做法是别让它直接改现有文件，而是新建一个单独的文件让它写上传逻辑，写完之后自己手动合并进去。或者在prompt里明确说“只新增代码，不要修改任何已有函数，不要重命名变量”，但

我也遇到过这毛病，后来发现光在CLAUDE.md里写没用，得在每次prompt里把约束说死。我的做法是直接贴一段项目里现有的测试当模板，然后加一句“照着这个风格写，只覆盖我列出的case，别加任何额外断言或mock”。另外把describe/it这种偏好明确禁止掉，它其实挺听话的，就是默认想表现。实在不行就分两步，先让它列用例你确认，再让它写代码。

确实会这样，我后来都先自己搭好结构再让它填，不然越写越像它那一套。

torch.compile对动态shape的支持其实已经比JIT好了，它默认就是动态shape模式，但前提是你得把padding和mask处理好，不然重编译的开销确实会让你更难受。自定义注意力掩码只要不是纯Python控制流，一般都能被inductor捕获，建议先用torch.compile的mode=reduce-overhead跑一下benchmark对比下，别急着换JIT。另外可以试试把历史

试试14B量化版，速度比72B快不少，工具调用准确率比7B强一大截，我项目就是这配置。

同感，单测和线上完全两个世界。建议先别急着调chunk，把召回结果打出来看看，Top5里是不是混了大量不相关片段，先确认是检索的问题还是生成的问题。另外512的块对长文档确实容易切碎语义，可以试试按标题或段落结构切，或者用parent-child retriever这种分层策略。幻觉兜底的话，除了提示词，可以在生成后加一道rerank，或者对答案做事实性校验，比如把关键实体和原文做相似度对齐，不达

这问题太真实了，我也踩过一样的坑。后来我试了个土办法，就是每轮回复前把核心指令压缩成一句“暗号”塞在用户消息最前面，比如“【状态：项目经理模式】”再跟上新问题，效果比单纯重复system prompt稳一些。不过说实话，模型注意力一分散还是会漂，尤其是上下文一长，感觉它自己都顾不上人设了。你试试把角色设定跟任务进度绑在一起，每次输出时让它先复述一下当前目标，相当于自己给自己拽回来。

说实话我也踩过这个坑，后来发现问题的核心不在prompt本身，而在于你给AI的“约束边界”太模糊了。它每次随机发挥，是因为你只说了“做什么”，没说“怎么做”的具体细节，比如明确要求“只用csv模块和collections.Counter”，或者“输出格式必须是字典，不要打印额外信息”。我试过把需求拆成三步：第一步让它列一个实现方案，第二步我确认后再让它写代码，第三步要求它把代码压缩成单函数并附上测

八成是事件循环没跑起来，stdio传输得靠asyncio.run()撑着，试试把server主函数包一层再启动。

这问题太真实了，我一开始写MCP工具也踩过这坑。我的做法是强制工具内部做分页或截断，比如搜索工具默认只回前20条带高亮的片段，再加个total_count字段让LLM知道还有多少，它自己会决定要不要翻页。至于引用ID的方式我也试过，但前提是你得有配套的二次查询工具，不然LLM拿到ID也没法用，反而更懵。

这代T90的“对话式诊断”确实比上一代那种错题本模式高级不少，至少从技术路径上更接近“理解”而非“记录”。不过你提到的数据投喂问题我也纠结，现在孩子刷题本来就够机械了，如果连AI都在强化这个闭环，发散思维怕是更没空间。我倒挺好奇它有没有非应试的对话场景，比如鼓励孩子提问“为什么”而不是只给标准答案，这可能是区分“智能伙伴”和“高级题库”的关键。

2卡各跑一个实例更稳，4卡张量并行对TTFT没本质提升，量化用AWQ 4bit掉点能接受。

试试把项目文件塞进system prompt里做RAG，6.7B对局部上下文的敏感度确实不如Copilot的全局索引。 另外可以开下FIM中间填充模式，查查ollama的num_ctx参数是不是默认太小了。

试试把调用示例和参数说明做成独立的索引块，检索时用重排序模型优先匹配跨文件关联，比单纯拼片段靠谱。

说到这个我可太有同感了，固定token数切分真的是个坑，我也踩过。你试的200、500、1000其实都算常规操作，但核心问题在于：同样的chunk大小，对“苹果推出iPhone”和“财报分析”这种不同粒度的信息，检索效果完全不一样。我后来改用按段落或章节标题来做初步分割，再根据内容密度动态调整长度——比如对表格或列表这种结构化内容，保持整块不切，而对长段落则按句号做二次切分，效果比纯token数好

试试把MCP工具结果当成RAG的补充输入，让LLM自己整合成完整回答，比硬拼接自然多了。