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

把业务文档塞进去效果有限，不如给Agent配个白名单规则，把已知的业务妥协点直接豁免掉。

可以试试在审查前先让Agent跑一遍历史PR，用你手动标注过的样本做few-shot，比改prompt管用。

这问题太真实了，我也踩过类似的坑。光靠system prompt真不够，模型对“业务妥协”和“坏味道”的边界理解很模糊。我是把项目的ADR（架构决策记录）和关键模块的注释摘要喂给Agent，再在审查规则里加了个“豁免名单”，把那些已知的历史包袱代码路径提前标出来，误报率明显降了。你可以试试让Agent先输出“疑似问题+业务依据”，再人工确认一轮，慢慢调它的判断阈值。

这问题太真实了，我试过类似方案，光靠system prompt真的没用。把业务文档塞进知识库会好点，但更关键是让Agent先理解“这是不是有意为之”，比如在PR描述里强制要求写清楚改动背景，或者把历史commit和issue链接喂给它当上下文。

我现在做法是分两层：第一层只查语法、安全、明显的空指针这类硬伤，第二层才做逻辑审查，并且让Agent对拿不准的只提“建议确认”而不是直接标bug。另外可以在规则里加一条“如果代码有注释说明原因，默认视为合理”，能挡掉不少误报。

不过说实话，Agent对业务妥协的容忍度天生就低，调来调去还是得靠人review关键改动，工具顶多帮忙减轻负担。你可以试试把状态机那类逻辑写成规范文档给它，但别指望它能完全理解“历史债务”这种概念。

这问题太真实了，我试过类似的方案，光靠system prompt根本没用。把业务文档塞知识库是个方向，但效果取决于你文档写得多细，不然还是抓瞎。我后来是把那些“业务妥协”的代码加了自定义注释标记，让Agent遇到注释就先跳过，误报率低了不少。你可以试试给Agent配个规则白名单，把状态机、兼容逻辑这类常见模式直接豁免，比让它理解上下文靠谱。

这事儿我太有同感了，之前用别的Agent审PR也是这德行，把兼容性注释当死代码删，差点没把我气死。后来我发现光改prompt没用，模型压根不知道你项目里哪些“丑”是故意留的债务，哪些是真该修的。我现在的做法是给Agent喂一个精简版的“业务规则速查表”，不是整本文档，就列关键流程的状态流转、历史兼容点，还有那种“明知烂但暂时不能动”的清单。另外，我还会在PR描述里手动标注“此改动涉及业务妥协，请勿按通用规范报错”，相当于给Agent划个红线。还有个笨办法但挺有效——把误报案例收集起来，定期补进few-shot示例里，让它在类似场景下学乖点。不过说实话，指望Agent完全懂业务上下文短期内不现实，我会把它的输出当“建议”而不是“结论”，最后人工过一遍还是省不掉。

把业务文档喂进去更靠谱，不过记得按模块拆开喂，不然上下文一长它照样乱报。

试试在规则里加个“兼容性豁免”白名单，把历史妥协代码单独标记出来，比调prompt省事。

把业务文档塞进去会好点，但更关键是让Agent先识别代码意图，再谈规范，不然它永远在瞎报。

试试给Agent配个“例外清单”，把已知的业务妥协写成白名单规则，比改prompt直接多了。

把业务文档塞进去作用不大，不如在审查规则里加个“白名单”模式，把已知妥协点手动过滤掉。

说实话这问题我也踩过坑，光在prompt里强调“业务上下文”根本没用，模型对“坏味道”的理解太字面了。我的做法是给Agent喂一个精简版的业务规则文档，但别塞整个知识库，只挑那些容易误判的模块写清楚“为什么这么写”，效果立竿见影。另外你可以在审查规则里加个白名单，把状态机这类已知妥协模式标成“业务约定”，让Agent直接跳过。

这问题太真实了，我试过类似的方案，光靠prompt确实压不住。你把业务文档塞进知识库也没多大用，因为模型分不清哪些是历史包袱哪些是当前约定。我后来是给Agent加了个规则白名单，把那些“已知妥协”的代码模式直接跳过审查，效果立竿见影，你可以试试。

其实核心问题是它缺少“意图”维度的判断，你不如给它几个具体例子，比如“看到这种兼容旧接口的写法就忽略”，比抽象描述业务上下文管用得多。另外我建议把审查粒度调细一点，让它只报能明确给出修改建议的问题，那种含糊的“可疑代码”直接过滤掉。

还有就是得看你用的模型版本，DeepSeek对长上下文的把握确实弱一些，我换成Claude Sonnet之后这类误报少了很多。不过说到底，AI Agent做审查还是适合当辅助，重大重构建议还是得靠人眼过一遍，别指望它全对。

这问题我也踩过坑，光靠prompt真不够，模型对“业务上下文”的理解太表面了。我现在是把项目的README、关键模块的设计文档，还有历史PR里被驳回的误报案例，整理成一个小型向量库挂给Agent检索，误报率降了不少。另外你可以试试在system prompt里加一条规则，让它遇到“看起来不优雅但注释说明是兼容性要求”的代码时，先输出“可能是业务妥协”再分析，比单纯说“注意上下文”管用。

这问题太真实了，我试过给Agent塞业务文档，结果它开始拿文档里的描述硬套代码，误报反而更多了。后来我改成在PR描述里把关键业务决策的背景写清楚，再让Agent只报“可修复且不影响逻辑”的问题，效果好了不少。你可以试试在审查规则里加个“豁免清单”，把那些已知的妥协点提前标出来，比调prompt省心。

说实话，塞知识库治标不治本，大模型对上下文的理解还是太线性。我现在的做法是给Agent加个分类步骤，先让它判断“这是否属于业务约束”，再决定要不要报，相当于人为加个过滤器。另外你可以在prompt里举例，比如给出几个你们项目里典型的“业务妥协”代码段，比抽象描述管用得多。

我怀疑你用的是默认的审查规则模板，那个太偏通用代码规范了。建议你直接改规则文件，把“复杂度高”这类检查的阈值调低，或者干脆关掉对状态机相关逻辑的检查。还有就是让Agent生成审查报告时附带置信度，低于某个值的直接过滤掉，能少一半误报。

这问题太真实了，我试过给Agent塞业务文档，结果它光顾着匹配关键词，报得更离谱。后来我干脆把规则反着写，明确列出“这类情况属于已知妥协，不要报”，比正向描述业务上下文管用得多。另外建议把PR描述和关联issue标题喂给它，比单纯靠system prompt约束上下文有用。你试试把“状态机”这类词直接加进忽略清单，能少一半误报。

把业务文档塞进知识库大概率没用，除非你能把每条业务规则都精确映射到代码模式。我自己的做法是让Agent只做“机械性问题”审查，比如空指针、资源泄漏，业务逻辑判断全砍掉，宁可漏报也别误报。反正代码审查最终还是得人看，Agent就当个低配版SonarQube用吧。

我倒是觉得可以换个思路，别让Agent直接报bug，让它输出“可疑点+理由”，然后你这边写个后置过滤器，把那些经常误报的模式手动标成白名单。跑个一两周，白名单攒够了，误报率能压到很低。就是前期调起来有点费劲，但比一直改prompt要省心。

遇到过类似情况，后来发现是温度参数太高了，模型老爱“发挥”。你把temperature调到0.1或者干脆0，再配合few-shot示例，给它几个“业务妥协”

这事我踩过一样的坑，光在prompt里喊“注意业务上下文”基本没用。后来我把项目根目录下的README和几个核心模块的设计文档扔进知识库，误报率明显降了，但得注意只喂关键部分，喂太多反而干扰判断。另外可以试试在审查规则里加个“已知妥协清单”，把常见的兼容性写法预先列进去当白名单。还有个取巧的办法，让Agent先输出“疑似问题+理由”，再让另一个Agent专门复核是不是业务需求，双重校验会稳很多。

试过类似方案，Cline+DeepSeek做审查最大的问题不是prompt，而是模型根本不知道你们业务里哪些“丑”是刻意为之。我后来是把项目的ADR（架构决策记录）和几个典型PR的讨论摘要直接塞进知识库，效果比单纯写“注意业务上下文”强太多，因为模型能对着具体例子学。另外你可以试试在审查规则里加一个“豁免关键词”列表，比如状态机、兼容旧接口、历史遗留，命中这些词的代码块直接跳过复杂度检查，只报真正的逻辑错误。还有个土办法，让Agent先输出“疑似问题+理由+涉及的业务模块”，你定期把误报的case拉出来微调few-shot示例，几次之后准确率能上来不少。不过说真的，指望它完全区分“坏味道”和“妥协”有点难，代码审查这事最后还得人拍板，Agent当个加强版lint用就行。

这问题太真实了，光靠system prompt确实没用，模型压根理解不了你项目的“潜规则”。我试过把架构文档和接口规范丢进知识库，比塞业务文档管用，因为agent需要的是判断边界，不是业务细节。另外你可以试试在审查规则里加白名单，比如特定目录或特定函数名直接跳过复杂度检查，效果立竿见影。还有个土办法，就是让agent把每个警告都附上“可能原因”和“修改建议”，你一眼就能看出它是真发现bug还是在瞎猜，过滤成本低很多。

把业务文档塞进知识库我试过，效果一般，反而容易让agent更“自信”地瞎报。我觉得核心是给它定义“坏味道”的明确标准，比如状态机手动处理，你可以直接告诉它“这是历史遗留的稳定代码，禁止触发复杂度规则”。另外，把PR描述和关联issue一起喂给agent，让它先理解这次改动要干嘛，再让它审，误报率会降不少。你可以试试在审查前加一步“先总结改动意图，再逐条检查”，比单纯堆上下文靠谱。

我倒是觉得你该换个思路，别指望它区分业务妥协和代码坏味道，这本来就模糊。不如把审查Agent分成两轮，第一轮只查硬性错误，比如空指针、资源泄漏、明显的安全漏洞，这些它判断很准。第二轮

这问题太真实了，我试过喂业务文档，结果它开始把啥都往业务上靠，更放飞了。后来我干脆给Agent配了个“忽略清单”，把状态机、兼容层这类文件路径直接排除，只在diff里看纯逻辑问题，效果立竿见影。你不如先试试限定检查范围，比塞知识库省事得多。

我是直接把业务规则写成了单独的规则文件，比如“xxx字段不允许为空”这种硬约束，让Agent只查这些。至于代码风格和复杂度，我直接关掉了那几类规则，毕竟PR里有人review，Agent就是抓个漏网之鱼，别指望它全懂。

我跟你反着来，我把业务文档摘要塞进knowledge base了，但只给顶层文件夹加权限，不让它看具体实现。这样它知道“这是兼容逻辑”但不会去深挖细节。不过说实话，调这玩意儿的精力够我自己看十次PR了，后来就放弃了，还是靠人肉过滤。

把业务文档塞进知识库也没用，它理解不了“妥协”和“坏味道”的边界。不如直接给Agent加个“仅报明确错误，不报风格建议”的开关。

这问题太真实了，我试过把异常分支全标注成TODO，它才消停点，要不你试试用PR描述里的关键词做过滤规则？

这问题太真实了，业务文档塞进去也白搭，模型根本分不清“妥协”和“坏味道”，不如直接给Agent列个忽略清单。

这个我太有同感了，之前用别的模型做审查也这样，把兼容逻辑全标成bug。光靠system prompt真不够，后来我把项目的wiki和几个核心模块的设计文档丢进知识库，然后加了条规则让它输出时先标“业务意图”再标“代码问题”，误报率降了不少。你可以试试给Agent几个具体的技术债例子，让它照着这个标准去比对，比单纯说“注意上下文”管用。