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

说实话这个问题我太有同感了，之前用其他模型搭审查Agent也踩过同样的坑。你往system prompt里写“注意业务上下文”基本没用，因为LLM对“业务”这个词的理解跟咱们完全不一样，它更擅长抓通用代码模式，但没法感知PR背后那些隐性的历史包袱。我的经验是，光塞业务文档也不行，文档写得太规范，模型反而会把“文档里没提到的边界情况”当成违规，误报率更高。比较有效的做法是给Agent喂“正反例”——把你们仓库里过去真实被通过的那些“业务妥协”代码抽出来，标注成“允许的例外”，再配几条真正需要修的bug样例，让它学会对比着判断。另外可以把规则拆细，比如单独写一条“如果代码注释里说明了兼容原因，则跳过复杂度检查”，比让模型自己权衡靠谱得多。还有个土办法，就是给Agent加个“提问模式”，遇到拿不准的标注先不直接报bug，而是生成评论问开发者“这里是否是出于业务兼容考虑”，把判断权交回给人，虽然多一步交互，但误报率能降一大截。

这事儿我太有同感了，之前用别的模型做审查也这样，把兼容逻辑当死代码，差点给删了。你光靠prompt确实不行，模型压根不知道你业务里那些“历史包袱”的来龙去脉。我后来是把关键模块的注释和几个典型PR的讨论摘出来，整理成一份简短的“业务约束清单”丢进知识库，效果立竿见影。另外建议在Agent的规则里加一条“遇到可疑点先归类为‘需人工确认’，别直接标bug”，能少很多噪音。

这问题太真实了，我当初用Agent做review也踩过这个坑。核心矛盾在于，模型对“正确性”的理解是统计意义上的，而业务代码里大量“看似不合理”的逻辑恰恰是历史包袱和现实约束的产物。你光在prompt里写“注意业务上下文”等于没写，因为它没有具体例子去锚定什么算“妥协”。我的做法是，先别急着上知识库，那玩意儿维护成本太高，更有效的是给Agent喂“反例样本”——把你们PR里那些被误报但实际正确的代码块整理成few-shot，明确告诉它“这类模式是允许的”。另外可以试试调低它报“复杂度”和“死代码”的置信度阈值，很多Agent框架支持按错误类型设置不同敏感度。还有个土办法，让Agent只输出“潜在问题”和“业务理由猜测”两个字段，强制它先解释为什么觉得是bug，再让它自己判断这个理由是否充分，误报率能降不少。说到底，Agent现在就是个高级正则引擎，得靠你持续调教它的“业务边界感”，没有一劳永逸的方案。

这问题太真实了，我拿GPT-4o做类似事情的时候也踩过这坑。你光在prompt里写“注意业务上下文”肯定不够，模型对“业务妥协”和“坏味道”的边界理解其实很依赖具体例子，不如直接给它喂你们项目里几个典型的“故意写丑但必须保留”的代码片段，让它先学一下这类模式的“豁免清单”。另外我试过把业务文档塞进知识库，效果有提升但很有限，因为文档往往是讲功能，不会告诉你“这里为什么故意不重构”，所以更有效的反而是让Agent在报bug时强制输出“这个问题影响了什么具体行为，如果改了会破坏哪些场景”，逼它自己先做一轮因果推演。还有一个取巧的办法：给审查Agent加一个“怀疑等级”机制，比如对状态机、兼容逻辑这类高频误报模式，让它默认降权，只有能明确说出“这个分支永远不可达”或者“这个条件在真实数据下必真”时才标成疑似bug。说到底，Agent现在缺的不是业务知识，而是对“代码里隐形的设计约束”的建模能力，这个光靠调prompt很难根治，建议你在流程上加一个人工复核层，让误报直接回流到Agent的训练集里，跑几轮就准多了。

这问题太真实了，纯靠prompt基本无解，因为LLM压根没有你项目的“领域常识”。我试过把业务文档塞进知识库，效果也就那样，文档本身写得抽象，它反而更容易瞎联想。现在我的做法是给规则文件加白名单，比如特定目录下的状态机代码直接跳过复杂度检查，或者把“兼容旧逻辑”改成自定义规则，单独标注而不是报warning。另外你也可以试试让它先输出“疑似问题+理由”，再让另一个Agent专门判断这理由是否属于业务妥协，两个模型互相制衡，比改一个prompt靠谱多了。

我试过类似方案，最后发现单纯靠prompt真不行，业务上下文这东西对LLM来说太隐晦了。你塞业务文档进知识库也是个办法，但文档更新频率跟不上代码变更的话，反而会引入更多误报。我现在的做法是给Agent加了个“白名单机制”，在审查规则里明确列出哪些文件、哪些函数是已知的业务妥协点，直接跳过，效果立竿见影。另外你提到状态机那类逻辑，其实可以换个思路，让Agent先输出“可疑点+理由”，再通过一个二次过滤层（比如人工或者规则引擎）去判断是不是真bug，别让它直接下结论。还有个偏门技巧，把git blame信息喂进去，让Agent知道这段代码是谁写的、什么时候改的，有时候“历史原因”比“代码逻辑”更能解释为什么写成这样。最后想提醒下，DeepSeek对中文业务语义的理解上限可能就那样，你要是常遇到这类问题，不如试试把业务规则抽成结构化规则文件，让Agent按规则匹配而不是自由发挥。

这问题太真实了，我拿Agent试过一阵子，最后发现光靠prompt真不行，它压根不知道哪些是故意为之的“技术债”。建议你把项目里的ADR（架构决策记录）或者关键模块的注释喂进去，效果比塞整个业务文档强。另外可以在规则里加个“白名单模式”，把那些已知的兼容逻辑或状态机直接跳过，至少能少烦你几次。

这问题太真实了，我拿GPT-4做审查也这样，它根本分不清“刻意为之”和“写砸了”。你光塞业务文档没用，它读文档跟你读代码完全是两套理解，建议直接在规则里加白名单，比如把状态机、兼容判断这类模式明确写成“允许的例外”，比让它自己判断靠谱多了。另外可以试试让agent先输出“疑似问题+理由”，你手动标记哪些是误报，攒几轮样本做few-shot，比改prompt管用。

这问题太真实了，我试过类似方案时也踩过这个坑。光靠system prompt根本不够，模型对“业务妥协”和“烂代码”的边界理解很模糊。建议你试试把项目里几个典型的历史PR（尤其是那些特意写注释说明“别改，改了会炸”的）喂给Agent做few-shot，比塞业务文档更直接。另外可以在审查规则里加一个“当检测到异常模式时，先给出业务合理性猜测，再给技术建议”，让Agent学会用假设语气而不是直接下结论。

我之前调的时候发现，把“业务上下文”写进prompt不如直接改审查指令的粒度。比如让它只报“会导致明显bug或性能问题”的硬伤，把风格类、复杂度类的建议单独开一个“仅供参考”列表，这样就不会混淆了。你那个状态机的例子，其实可以加一条规则：如果代码里有注释说明是刻意为之，就跳过。

这问题太真实了，我试过类似方案也翻车。光靠system prompt不够，模型对“业务妥协”的理解太浅，建议把PR描述和关联issue塞进上下文，让agent先看变更意图再判断。另外可以给agent加个规则：疑似问题必须附上“修复后可能影响哪些调用方”的说明，强制它思考权衡。我后来还用了两步审查，先让它提全部疑点，再基于业务文档过滤掉非bug类逻辑，准确率能提升不少。

这问题太真实了，我试过类似的方案，光靠system prompt根本压不住。后来我把项目里那些“历史原因”的注释和issue链接直接喂给Agent，让它先查这些再报问题，误报率明显降了。另外你试试在审查规则里加个“豁免清单”，把常见的业务妥协模式明确列进去，比塞一堆文档管用。

其实我觉得核心是Agent对“意图”的理解太弱，业务代码往往有很强的上下文依赖。你可以考虑先让它跑两轮，第一轮只报“客观问题”比如空指针、资源泄漏，第二轮再让它结合git commit消息判断是不是故意这么写的。别指望一次调好，这玩意儿得靠反馈循环慢慢磨。

我倒是好奇，你用的Cline对长上下文的支持咋样？我之前试过把业务文档塞进知识库，结果它经常在无关代码里引用文档内容，反而更乱。要不你试试把业务规则写成结构化的yaml，配合自定义lint规则，可能比自然语言提示词更精准。

这问题太真实了，我拿GPT-4做类似的事也翻车。光靠prompt真不够，模型对“业务妥协”和“坏味道”的边界理解太弱，尤其状态机这种反直觉的东西。我觉得把业务文档塞知识库是必须的，但关键得结构化，比如把“兼容旧接口”“状态机流转”这些规则直接写进审查清单，让它对照着查，而不是让它自己推理。另外可以试试分层审查，先让Agent只报客观问题（空指针、资源泄漏），业务逻辑相关的全过滤掉，人工再看。

这个问题我太有同感了，之前用别的Agent做review也踩过一模一样的坑。后来我试了个笨办法，与其塞业务文档，不如在prompt里给它几个具体的“业务妥协”的例子，比如把你说的兼容旧接口那个真实case写进去，告诉它“这种属于历史包袱，只提示风险别标bug”，效果立竿见影。另外我发现一个关键点，就是让Agent每次先输出“这段代码的意图是什么”，再判断是不是坏味道，这样能逼它先理解上下文。不过说实话，现在这些模型对“隐性知识”的把握还是太差，像状态机这种，除非你在注释里写清楚为什么手动处理，否则它真看不出来。你有没有试过在PR描述里自动附加上下文？比如让Cline先读一下关联的issue或者设计文档，再跑审查，可能比改prompt管用。还有个偏方，就是分级报告，让它把可疑项分成“建议”和“必须改”，业务逻辑相关的默认降级，这样至少不会刷屏。你可以试试把“业务妥协”单独建一个list，每次审查前动态喂进去，比固定system prompt灵活多了。

这问题太真实了，光靠system prompt还真不够。我之前试过把业务文档塞进知识库，但文档更新跟不上代码变化，反而让agent更confused。后来我改成在PR描述里手动标注“业务妥协”区域，再让agent只审查未标注的diff，误报率降了不少。你可以试试给agent加个规则：遇到状态机或兼容逻辑先问“这是否有历史原因”，而不是直接报问题。

这问题太真实了，光靠system prompt根本喂不进去业务上下文。我试过把项目README和核心模块注释塞进知识库，效果有提升但噪音还是不少，后来改成让Agent只报“会引发运行时错误”和“明显违反项目约定”的问题，规则类检查交给ESLint那些工具，反而顺多了。

另外你可以试试在PR描述里强制要求写清楚“为什么这么改”，让Agent先读那个再下结论，或者给它几个历史例子当few-shot，比写一堆抽象规则管用。不过说实话，指望它完全懂业务妥协挺难的，我现在基本把Agent当第二双眼睛，真正拍板还是人工。

这问题太真实了，我试过给Agent塞业务文档，结果它反而开始把正常代码也当业务妥协放过了。后来发现最有效的还是把审查规则拆细，比如明确告诉它“兼容逻辑要检查是否有注释说明，没有才报”，比让它理解业务上下文靠谱多了。你试试在prompt里加个“当代码看起来异常但可能有业务原因时，输出为提示而非错误”的兜底规则，会少很多噪音。

这问题太真实了，我试过类似方案，最后发现光靠prompt真不够。你不如把PR描述和关联issue一起喂给Agent，让它先理解“为什么这么改”再判断，比塞整本业务文档轻量多了。另外可以在规则里加个白名单，比如某些兼容性注释直接跳过检查，不然每次都得人工复核，效率反而更低。

把业务文档塞进去会好点，但更关键是要给Agent看历史PR的决议记录，让它学哪些是故意为之的妥协。

试试给Agent加个“业务豁免清单”的规矩，让它优先对齐已有注释和代码里的TODO逻辑，这招对我这挺管用。

说实话，你这个痛点太真实了，我拿GPT-4做类似尝试时也被这种“正确但没用”的反馈搞到头疼。核心问题在于Agent没有“意图识别”能力，它只能看到代码结构，看不到你写这段代码时背后要扛的历史包袱。我之前试过把业务文档塞进知识库，结果更糟——它开始从文档里“脑补”出各种不存在的规则，报得更离谱。后来我发现一个相对可行的路子：在审查规则里明确加一层“豁免清单”，比如把状态机、兼容逻辑这类模式写成白名单，告诉Agent这些是已知的业务妥协，只要不触发特定异常就别报。另外，调system prompt时别写“注意业务上下文”这种废话，得给具体例子，比如“当看到XX模式时，请先检查它是否对应YY历史需求，是则跳过”。还有一招是让Agent先输出“它理解的业务背景”再出审查结果，这样你至少能看出它哪儿理解偏了。但说实话，只要是用通用模型做审查，这种误报率很难降到零，我最后是加了个人工确认环节，只让Agent标“疑似问题”，最终判断还是自己来。你试试把审查粒度从“问题”改成“需要人工复核的提示”，会舒服很多。

把业务文档塞进去会好点，但更关键的是给Agent喂几个正反例，让它学会啥叫“业务妥协”。