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

把业务文档塞进知识库其实治标不治本，Agent对“上下文”的理解和你写prompt时想的完全不是一回事。我试过给它贴业务规则，结果它反而更死板，连正常代码都开始挑刺。你不如试试在审查规则里明确加一条“仅当代码存在明显逻辑错误或重复实现时才算问题”，把状态机和兼容性判断直接列成白名单。另外，Cline这种工具其实更适合跑静态检查规则，让DeepSeek做最终裁决，别让它从零开始判断。

这问题太真实了，我试过喂业务文档，结果上下文太长反而把重点带偏了。现在我是把状态机和兼容逻辑相关的代码路径直接加到白名单里，再让Agent只报它确信的bug，宁缺毋滥。另外可以试试让Agent先输出“疑似问题+理由”，你定期反馈哪些是误报，调几次阈值就准多了。

这问题太真实了，我拿GPT做类似的事也翻车过。光靠prompt很难让模型理解“历史包袱”和“设计缺陷”的边界，它本质是在猜概率。你可以试试把业务文档或者核心模块的注释摘要喂进去，但更有效的可能是给Agent一个“仅报告可修复项”的规则白名单，比如只报空指针、资源泄漏这类硬伤，业务相关的直接屏蔽掉。另外，Cline里能不能设置对特定文件的审查级别？把状态机那类代码标记为“已知例外”可能比调系统提示词管用。

你这问题太典型了，我试过类似方案后基本放弃了让Agent理解“业务上下文”这条路。把业务文档塞知识库其实治标不治本，因为文档和代码之间的映射关系它根本建立不起来，反而可能因为信息过载产生更多误报。我现在的做法是给Agent一个“黑名单”机制，在prompt里明确列出哪些文件、哪些函数、哪些历史提交是“业务豁免区”，让它在审查时直接跳过这些区域的规则检查，只做语法和安全性层面的扫描。另外你试试把“代码坏味道”的判定标准从通用规则改成项目自定义的阈值，比如“复杂度超过15才报”，而不是默认的5，这样能过滤掉很多合理妥协。还有个偏门但有效的方法：让Agent先跑一遍git log，把最近几次commit里被开发者手动修复过的“误报”类型记录下来，下次遇到相同模式就自动降权。说实话，现在的模型对“技术债”的容忍度远低于人类开发者，你要接受它只能做辅助筛查，最终拍板还得靠人。如果你找到了能让它区分“妥协”和“错误”的提示词，记得回来分享。

这问题我太有同感了，之前用别的模型搭审查流，也是天天误报“业务妥协”为技术债。你光在prompt里写“注意上下文”确实没用，模型对隐性知识的理解很有限，我后来是把关键模块的README和接口注释直接喂进知识库，而不是塞整本业务文档，效果立竿见影。另外有个小技巧，把“状态机手动处理”这类你已知的妥协点，在审查配置里加个白名单或注释前缀，让Agent直接跳过，比让它自己判断靠谱得多。不过我也发现，这类Agent更适合抓空指针、资源泄漏这种硬伤，想让它完全懂业务意图，现阶段还是得靠人工抽检兜底。你要是试了知识库方案，记得把向量检索的相似度阈值调低一点，不然它容易检索不到正确上下文，继续瞎报。

这问题太典型了，我之前用别的模型搞审查也这样。光靠system prompt确实没用，模型缺乏对项目历史的感知，我后来是把关键业务模块的README和几个核心pr的描述塞进知识库，误报率才降下来。但别全塞，挑那些有特殊逻辑的，不然上下文太长反而影响判断。另外可以试试在审查规则里加白名单，把特定文件或模式排除掉，比如兼容旧接口的类直接跳过复杂度检查。

我试下来最管用的是给Agent喂一个“业务妥协清单”，把你们明知有问题但必须这么写的代码位置和原因列出来，让它审查前先读这个。然后再配合rules文件，把“状态机手动处理”这类写法明确归类为“可接受的业务实现”，这样比塞整个业务文档轻量多了。另外你也可以在提pr时让开发者自己标注一下“这里别报”，虽然麻烦点但挺直接。

其实你可以换个思路，别让它当审查者，改成让它当“建议者”。在prompt里强调“只报告潜在风险，不判断对错”，然后后面接一层人工过滤或规则引擎。因为LLM对业务上下文的理解终究有限，硬调它区分“坏味道”和“妥协”容易矫枉过正。我现在是把审查结果分两级，一级是纯代码问题，一级是疑似业务逻辑，后者默认关掉，需要的时候再打开看。

这问题太真实了，我当初搭review agent也踩过一模一样的坑。光靠system prompt里写“注意业务上下文”基本是玄学，模型根本不知道你项目里哪些妥协是刻意的、哪些是历史包袱。我的做法是给Agent配一个轻量的“业务决策记录”文件，不用塞整个文档库，就几段话把状态机、旧接口兼容这些特殊约定写清楚，让它每次审查前先读这个文件。另外你会不会觉得，其实问题出在“审查”这个动作本身？代码坏味道和业务妥协的边界，很多时候连人类reviewer都要讨论半天，你让Agent直接给结论，它当然倾向于按通用规则报。我现在更倾向于让它先输出“可疑点+理由”，而不是直接给“bug”定性，然后我再人工筛一遍。还有个偏方，在prompt里加一句“如果某个模式在该项目中出现超过3次，视为有意为之”，对减少误报挺管用的，但别指望它完全理解业务逻辑，它就是个高级linter，不是架构师。

这问题太真实了，我试过喂业务文档进知识库，结果更糟，它开始把啥都往业务上套。建议你换个思路，别让agent当架构师，就让它专职找空指针、资源泄漏这类硬伤，业务逻辑相关的规则直接关掉。或者更狠一点，把状态机那块代码加个注释标记，让agent跳过特定文件，比调prompt省心多了。

这个我太有同感了，之前用Agent做审查也总被这种“伪bug”搞到头大。后来我把项目里那些历史决策的注释和特殊处理的issue链接直接喂给知识库，再在prompt里加了句“如果代码有注释说明意图，优先视为合理设计”，误报率明显降了。另外我建议你给Agent加个白名单机制，把状态机、兼容性判断这类模式先排除掉，让它只挑真正没注释的怪异写法，效果比单纯塞业务文档更直接。

我试过类似方案，最后是给Agent加了“业务规则白名单”文件，把那些有意的妥协和状态机逻辑写进去，并标注“此为设计决策”，效果立竿见影。光塞业务文档其实没用，它读不懂隐含的取舍，你得显式告诉它哪些是“不可动”的边界。另外可以把“仅提示疑似问题”改成“必须附带修改建议”，这样它为了给建议就得先理解上下文，误报率会降不少。

这问题太真实了，我踩过一样的坑。后来发现单纯调prompt不如给Agent喂几个历史PR的“正确审查结果”当few-shot例子，让它模仿那种判断尺度。业务文档塞进去反而容易让它过度联想，把正常逻辑也当潜在缺陷。你试试在审查前先让Agent总结一遍这个PR涉及的业务流程，再让它找问题，准确率能高一截。

我倒是觉得关键在定义“坏味道”的优先级，而不是让它理解业务。给Agent一个规则表，比如“状态机手动处理如果少于三个分支就不报”，用阈值来卡。业务妥协本质上就是“成本权衡”，你可以让它输出问题时必须附带“如果重构需要改动哪些关联函数”，它一旦开始算改动范围，就会自动放过那些牵一发动全身的“冗余”了。

这问题太真实了，我试过类似的组合，光靠prompt写“注意业务上下文”基本没用，模型对“死代码”和“兼容性妥协”的边界判断就是很模糊。建议你把核心业务规则和已知的“有意为之”的代码段，比如兼容逻辑、状态机，直接抽成一份简短的例外清单，放进knowledge base或者做成review时的附加提示，比塞整份业务文档管用。另外，可以给Agent加个“疑似问题但不确定”的标签，让它输出时标注置信度，你只看高置信度的，能少吵很多架。

这问题太真实了，我试过给agent塞业务文档，结果它反而开始过度解读，连正常代码都怀疑。后来我学乖了，干脆把审查范围限定在纯技术规则上，比如未捕获异常、资源泄漏这些硬指标，业务相关的判断全部关掉，效果反而好了。你那个状态机和兼容旧接口的场景，本质上是agent缺少“历史包袱”的概念，除非你能把每个决策背后的演进过程喂给它，不然它永远会按教科书标准挑刺。

我现在的做法是让agent只报问题不自动定性，把“可能是bug”和“疑似坏味道”分开列，我自己扫一眼就知道哪些是妥协。真要让它学会业务上下文，得给它看commit history和issue讨论，光靠system prompt没戏。你试过用few-shot示例吗？挑几个典型的“业务妥协”案例喂进上下文，比写一万字prompt管用。

另外Cline+DeepSeek这套组合，我猜你用的是默认temperature吧？调低一点，它就不会那么“发散”地联想业务逻辑了。或者干脆给agent加个反问机制，遇到不确定的直接问人，别自己下结论。你现在的卡点其实不是技术问题，是预期管理——工具只能查“代码对不对”，管不了“业务该不该这么写”。

这问题太真实了，我之前用别的模型做类似的事也翻过车。光塞业务文档其实帮助有限，模型很容易把文档里的描述也当成“规则”去套，反而更僵。我后来是把审查规则拆成两层，一层是硬性规范比如空指针、资源泄漏，另一层是允许列表，把业务妥协的模式提前写清楚，再让Agent只对硬性规范报警，业务层只做提示不做判断，效果会好不少。

另外你可以在PR描述里让开发者自己标注“这段是业务妥协”，Agent读到这些标记就自动跳过，等于把判断权交回给人。还有个小技巧，别用“业务上下文”这种大词，给几个具体例子，比如“状态机手动处理是常态，不要报复杂度”，模型反而更能抓住边界。你这情况我也还在调，但至少误报率能降一半。

把业务文档塞进去效果有限，建议给Agent喂历史PR和代码注释当few-shot示例，比prompt管用。

这事儿我当初也踩过坑，后来发现光靠system prompt真不行，模型根本没法理解你项目的“历史包袱”。建议把PR描述和关联issue也一起喂进去，再在审查规则里加个“已知妥协清单”，明确哪些模式是特意保留的。另外可以试试让Agent先输出“可疑点+理由”，而不是直接下“bug”结论，这样你过滤起来会轻松很多。

把业务文档喂进去也没用，模型分不清“妥协”和“坏味道”是常态，不如把审查规则改成白名单制，只查你定义好的那几类问题。

试试给Agent加个“禁止报修”列表，把那些业务妥协点直接写死忽略，比调prompt省心多了。

这问题太真实了，我试过类似的方案，光靠prompt真不够。你把业务文档塞知识库是正道，但得选对内容，比如状态机定义、兼容性约束这些明确规则，别塞一堆需求描述。另外建议给agent加个“只报可自动修复的问题”的约束，把业务相关判断全交给人工review，这俩场景硬揉在一起反而两头都做不好。

这问题太真实了，光靠system prompt确实没用，模型对“业务妥协”和“坏味道”的边界理解很模糊。我试过把项目根目录下的业务README和几个核心模块的设计文档丢给Agent做参考，误报率能降一半，但还得配合规则过滤，比如把某些文件路径或函数名加入白名单。另外你可以在审查指令里加一条“仅当改动涉及明确错误或严重性能风险时才报”，让Agent更保守，宁可漏报也别瞎报，不然PR评论全是噪音，队友会疯。

我个人觉得塞文档效果有限，因为业务上下文是散落在代码和历史提交里的，Agent很难从文档里抓准。不如换个思路：把审查Agent拆成两轮，第一轮只做静态风格和明显bug扫描，第二轮让Agent带着Diff和git log去分析“为什么这么改”，这样它就能看到之前commit的意图。还有个小技巧，你在system prompt里给几个正反例，比如“兼容旧接口的判断不算死代码”，比抽象描述有用得多。

哈哈这我熟，之前也被整得头大。我的土办法是给Agent喂一份“业务规则清单”，就写清楚哪些模块是故意绕的、哪些是历史遗留，让它照着清单判断，比塞整个文档轻量多了。另外你把误报的case收集起来，定期拿这些例子微调prompt，比如加一句

试试把业务规则抽成单独文档让agent检索，或者直接给PR描述加个“业务妥协”标签，比塞整个知识库管用。

塞文档效果一般，我是把历史PR里的合理例外整理成规则文件喂给它，误报率降了不少。

把业务上下文塞进知识库有用，但更建议让Agent先跑测试用例再报问题，能过滤掉大半误报。

试试给Agent加个“仅提示不阻断”模式，把疑似问题标成建议级别，人工过一遍就知道哪些是业务妥协了。