用AI Agent做代码审查时，总把业务逻辑当成bug报，怎么调？

这问题太真实了，我之前用别的模型跑审查也这样，光靠prompt里塞业务上下文基本没用。建议你把项目里那些“历史包袱”相关的注释或者issue链接直接喂给Agent，让它知道哪些是故意为之的设计决策，比单纯说“注意业务逻辑”管用。另外可以把“死代码”和“兼容逻辑”的判定规则单独拎出来，在审查脚本里加个白名单机制，命中直接跳过，省得它每次瞎报。

这个坑我太懂了，之前用别的模型也这样。光靠system prompt真不够，模型压根不知道你业务里那些“将就”是故意的。你试试把项目里常见的业务妥协案例整理成几个正反例，直接放到知识库或者few-shot里，比塞一堆文档管用。另外建议把审查规则拆细，比如单独定义“兼容代码”和“死代码”的区别，让Agent先分类再判断，误报率能低不少。

这问题太真实了，我调Cline时也撞过同样的墙。光在prompt里写“注意业务上下文”确实没用，模型根本不知道你业务里哪些妥协是合理的。我是把项目里几个核心模块的README和关键接口的注释抽出来，整理成一个精简版的业务约束文档丢进知识库，效果好了不少。另外建议把审查规则拆细一点，比如单独设一条“允许兼容性代码”的白名单，比让Agent自己判断靠谱。你试试把状态机那类逻辑先写成显式注释，看它还会不会误报。

这问题太真实了，我拿Agent跑过一阵子也有同感。光靠system prompt真不够，它压根理解不了“业务妥协”和“坏味道”的边界。我后来是把项目里几个典型的“故意这么写”的PR摘出来，做成few-shot示例丢给它，效果比塞文档好多了。另外建议把审查规则从“通用代码质量”改成“只报明确的技术债”，比如潜在NPE或者资源泄漏，少管风格和结构，业务逻辑那部分宁可漏报也别误报。

塞业务文档其实帮助有限，因为文档和代码的映射关系对模型来说还是太模糊。我试过把PR描述和关联issue的上下文一起喂给它，让它先总结“这个改动是为了干什么”，再让它判断代码是否匹配这个目的，误报率会低不少。你那个状态机的例子，可能得在规则里明确排除某些模式，或者干脆让Agent只输出“可疑点清单”而不是直接下bug结论，人工再筛一遍反而省心。

我之前也踩过这个坑，后来换了个思路：不让Agent直接报bug，而是让它只提“这个改动可能影响哪些地方”和“有哪些风险点”，把判断权留给人。业务逻辑这个东西，模型没吃过项目里的亏，确实很难悟。要不你试试把几个典型误报案例写成“反面教材”放进prompt，告诉它这种不算问题，

这问题我太有同感了，我之前用别的模型搭审查Agent也踩过同样的坑。你光在system prompt里写“注意业务上下文”是真没用，模型根本分不清哪些是“技术债”哪些是“必要妥协”，它只会机械地套用代码规范。我后来试了个稍微管用的办法，就是给Agent喂一个“例外清单”文件，里面明确列出哪些模块是历史遗留、哪些写法是为了兼容特殊场景，让它审查时先比对清单再报问题。但说实话，这也就是治标不治本，因为业务逻辑的上下文实在太动态了，清单更新跟不上代码变化。我现在的思路是砍掉它对“复杂度”“死代码”这类主观判断的权限，只让它抓明显的空指针、资源泄漏、逻辑矛盾这种硬伤，业务层的判断还是留给人工review。你试试把prompt改成“只报告确定会导致运行时错误的模式，所有风格类建议默认忽略”，可能比塞业务文档更有效，因为文档本身也会过时，而且塞多了它反而抓不住重点。

这问题太真实了，我试过把业务文档塞进知识库，结果它开始拿文档里的旧逻辑来卡新代码，更头疼。后来我干脆给Agent加了条硬规则：凡是涉及历史兼容或者特定业务分支的代码，必须先查git blame看提交记录，再决定报不报。另外建议你把“代码坏味道”和“业务妥协”分别定义成两个label，让它先分类再判断，而不是直接下结论。

我最近也在折腾这个，发现关键是别让它只看单文件，把PR描述和关联issue喂进去会好很多。你可以试试在system prompt里强调“只有当你确认这段代码没有对应的业务需求支撑时，才标记为问题”，效果比笼统说“注意上下文”强多了。

其实可以反过来，让它先列出它认为是bug的点，然后你每次在review结果里手动标注哪些是误报，跑个十几次，它慢慢就能学会你的偏好。我这么调了三天，现在准确率从五成提到了八成，比塞文档管用。

楼上说的git blame思路不错，我再补个招：给Agent加个“沉默阈值”，当代码改动是新增而非修改时，默认不报复杂度问题。因为新写的业务逻辑往往就是绕不开那些分支，只有改动老代码时才需要警惕坏味道。

这问题太真实了，我试过类似方案，光靠prompt真不够。你得把项目里那些“故意为之”的妥协点整理成文档，但别塞整个业务文档，就搞个“已知例外清单”，让agent每次审查前先读一遍。另外在规则里加一条“如果代码有注释说明原因，默认信任开发者”，能少很多误报。还有个土办法，把误报的case喂给它做few-shot，比改system prompt管用。

这问题太真实了，我拿Agent跑过一阵子也这样。光往prompt里塞“业务上下文”没用，它压根分不清哪些是刻意为之的妥协。我后来是把项目里那些“明知不优雅但必须保留”的代码块列了个清单，直接在审查规则里加白名单，并写上原因，效果立竿见影。另外别指望它能理解业务，你不如把review重点限定在空指针、资源泄漏这些硬伤上，规则越具体它越听话。

这问题我太懂了，之前用别的模型搭review agent也翻过同样的车。你光在system prompt里写“注意业务上下文”基本没用，模型根本不知道你业务里哪些是“妥协”哪些是“坏味道”，它只会按通用代码规范硬套。我的经验是把项目里常见的“业务豁免”场景整理成一个负面清单，比如“状态机手动流转是历史设计，不要报”“兼容旧接口的防御代码属于有意为之”，直接喂给agent当few-shot示例，比塞整个业务文档管用得多。另外，可以让agent在报bug时先输出“依据了什么通用规则”和“为什么觉得这里不符合”，你再加一层人工确认逻辑，把误报反馈回去微调prompt，跑几轮下来准确率能上去不少。你试试看，光加知识库反而容易让模型过度关注细节，产生更多误报。

这问题我太有同感了，之前用别的模型搭审查agent也踩过这坑。你光在system prompt里说“注意业务上下文”肯定不行，因为模型根本不知道你的业务到底是什么，它只能靠通用代码规范去硬套。我后来是把项目的README、核心模块的设计文档，甚至几个典型历史PR的注释都丢进向量知识库，让agent在审查时先检索相关上下文再判断，误报率降了大概一半。但说实话，完全区分“坏味道”和“业务妥协”还是难，毕竟连人review时都经常吵这个。另一个小技巧是给agent加一条规则：如果某个标记点涉及跨函数或跨模块的调用链，就默认不报，只报局部纯逻辑问题，这样能过滤掉不少“误伤”。另外，你可以在agent的反馈模板里强制它输出“为什么这是bug”和“如果这是有意为之，可能的业务原因是什么”两个字段，逼它自我解释，有时候它写着写着就发现自己理由站不住脚了。最后，别指望一次性调好，我建议你跑个20个PR样本，把误报类型统计出来，再针对性改prompt规则，比盲目塞文档高效多了。

哈哈这问题太真实了，我试过类似方案，最后发现光靠prompt真不行。建议把项目里常见的“业务妥协”案例整理成few-shot示例，直接喂给Agent当参考，比塞业务文档效率高多了。另外可以给它一个“只报告确定性技术问题”的开关，宁可漏报也别误报，不然PR review噪音太大，团队迟早不用这工具。

试试把业务规则的测试用例喂给它当few-shot，比塞文档管用，再不行就调低复杂度检查的权重。

把历史PR里被误报的案例整理成反例直接写进prompt，比塞业务文档省事，实测效果好不少。

试试在审查规则里加个白名单，把业务妥协的代码模式标记成例外，比塞业务文档好使。

给Agent喂几个历史PR当few-shot样例，比写prompt管用，它能自己学出边界。

个人感觉光塞业务文档作用有限，模型对“业务妥协”和“坏味道”的边界其实很模糊，你就算喂了文档它也容易过度联想。我试过在pr描述里强制要求开发者标注“已知妥协”段落，然后让agent只针对未标注部分提意见，误报率降了不少。另外可以试试给规则加白名单，比如状态机这种模式直接跳过，比让它理解上下文靠谱多了。

这问题太真实了，我试过给Agent塞业务文档，结果它开始过度解读，连正常写法都怀疑。后来我改成在审查规则里加了个“允许例外清单”，把状态机、兼容逻辑这类模式提前标记为白名单，效果比写一堆prompt靠谱。另外让Agent只报它高置信度的问题，宁可不报也别瞎报，省得人工过滤噪音更累。

这问题太真实了，Cline这类agent对业务妥协的容忍度几乎为零。我试过把项目README和核心模块的注释丢进知识库，稍微好点，但感觉它还是理解不了“历史包袱”这种东西。你不如试试在prompt里明确给它几个“允许例外”的模板，比如兼容旧接口的标记成“technical debt”而不是死代码，让它先分类再报错，效果比纯讲道理强。

另外，别指望它完全懂业务，我一般让它只报纯代码层面的问题，比如空指针、资源泄漏，业务逻辑相关的全过滤掉，人工再审一遍反而更高效。你可以调一下审查规则，把“复杂度高”这类主观判断的权重调低，重点抓客观错误，不然光看它瞎报就得累死。

这问题我太有同感了，之前用别的模型搭审查Agent也踩过这个坑。你光在system prompt里写“注意业务上下文”基本没用，模型对“上下文”的理解太抽象了，它更擅长从代码结构找模式，而不是从业务意图去推理。我的做法是搞了个轻量级的“业务规则文件”，不需要整个文档库，就把那些容易误判的妥协点，比如状态机跳转条件、旧接口兼容函数，用注释或者单独的md文件列出来，然后让Agent在审查时先读这个文件再分析代码。另外，把“坏味道”和“业务妥协”的判定标准拆成两个独立的检查项，比如“复杂度高”只提示风险等级，不直接标成bug，这样能减少很多噪音。还有个野路子，就是给Agent加个“反问机制”，当它命中某个规则但又不确定时，让它先输出疑问而不是结论，你人工确认一次后把结果反馈回去，几次下来能明显收敛误报。

把业务文档塞进去意义不大，关键是得给Agent喂PR描述和关联issue，让它先理解“为什么改”再判断。

试试在审查规则里加个“业务例外清单”，把已知的妥协点预先标记成白名单，比调prompt省心多了。