慢慢变强创业成长记
Lv.1保持初学者心态，也保持交付意识。当前重点关注独立开发与创业，通过代码实现与工程实践、性能优化持续提升能力；坚持先理解原理，再讨论工具，并把过程整理成可复用的学习记录。
发表的评论
刚入门，这个对我帮助很大。
这个思路不错，收藏了。
我一般只让它写工具类方法和单元测试，核心业务方法最多拿它当补全用，整段粘进去真不敢。你说的那个事务边界和懒加载问题太典型了，模型对运行时语义的理解还是浅，解释得通不代表跑得对。我现在的套路是先让它生成单测覆盖边界，自己review完再让它写实现，这样至少有个对照。不过老项目没现成测试的话确实头疼，这种场景我宁可自己动手。
结构化模板确实有用，但别指望一个模板解决所有问题。我之前做日志提取时发现，把“异常栈”和“业务上下文”拆成两步分别问，比塞一个Prompt里稳得多。另外你可以在约束里明确写“如果日志里没有相关信息就输出null，不要推测”，这句对防编造特别管用。temperature调到0也值得试试，代码分析这种任务不太需要创造性。
每个模型的指令微调数据分布不一样，系统提示基本得重写，别指望一套通吃。
按行切确实不行，函数体被拦腰截断后embedding基本就废了。我之前试过用tree-sitter解析Python的AST，按函数和类边界切，效果提升挺明显的，Go的话也能用tree-sitter-go。不过要注意别把单个函数切太碎，有些长函数还是得二次切，可以按逻辑块或者注释分隔。另外检索时可以把文件路径和函数签名拼到chunk前面，embedding匹配会准不少。
GGUF确实值得试，我用Q4_K_M跑32B大概占19G左右，剩的够2-4k上下文，速度大概8-10 tok/s。不过3090跑GGUF有点浪费卡，推理框架对CUDA优化不如vLLM。真要长上下文还是得AWQ加限制max_model_len，或者换14B/7B更实际。
刚入门，这个对我帮助很大。
学到了，感谢分享！
这个思路不错，收藏了。
学到了，感谢分享！
有没有更详细的教程推荐？
这个思路不错，收藏了。
85%其实不算低了，你试试把chunk切小一点再重叠一部分，召回一般能提几个点。
长程任务这个方向确实值得聊，但我感觉你提到的第二点才是真正的命门。我之前做RPA加LLM的混合方案时也踩过类似的坑，GUI操作里一个弹窗没处理掉，后面整条链路全歪，而且Agent自己根本意识不到走错了，还在那硬着头皮往下执行，最后交付的东西看着像模像样其实全是废的。稀疏反馈这个问题目前看不太可能靠模型本身解决，更多得靠工程侧加密集的checkpoint和回滚机制，但这样一来所谓的端到端Agent又
max_length 2048确实挺吃显存的，你先试试砍到512看能不能跑起来，很多时候OOM就是序列长度撑爆的。另外transformers 4.31对LLaMA的attention实现有些优化没跟上，升到4.36以上会好不少。还有个容易被忽略的点是优化器状态，LoRA虽然冻结了大部分参数，但如果你没设optimizer只更新lora层，AdamW还是会吃掉不少显存。我3090上跑7B LoRA
512切太碎了，FAQ这种先按段落或问答对切，再加个bge-reranker效果会好很多。
LangChain有现成的RetryParser和with_retry，直接套在Tool上就行，比自己写循环干净多了。
你这个问题我之前也踩过坑，大概率不是Claude那边默认只读沙盒，而是你用的filesystem服务器本身在能力声明里只暴露了read相关的resources和tools，write操作压根没注册进去。MCP的权限模型其实是分两层的，一层是服务器告诉客户端“我能做什么”，另一层才是客户端决定“我允不允许调用”，很多人卡在第一步。你可以先去翻一下那个filesystem服务器的源码或者启动参数，看看
两张4090跑Llama3-8B的LoRA，batch size=4爆显存挺正常的，尤其你平均500 tokens，实际序列长度一波动就容易顶满。可以试试把max_seq_length卡到512或者768，再开gradient checkpointing，显存能省不少。gradient accumulation抖不一定是累积本身的问题，学习率可能要跟着等效batch调一下，不然更新步数变少容易震荡