按团队规则预审代码变更

这个场景能帮你做什么

代码差异单独看似合理，放进业务和历史约束里可能有问题。WorkBuddy 可以结合完整上下文和团队规则提示风险线索，为人工评审节省定位时间。

开始前需要准备什么

提供明确基准与变更、相关函数及调用上下文、编码规范、业务规则、历史故障和已有静态检查结果。说明本次风险范围，避免把格式建议淹没重要问题。

具体怎么做

第一步：理解变更意图

先核对需求与实际差异，说明行为如何变化。缺少上下文时请求相关文件，不对局部片段给全局正确结论。

第二步：按规则检查风险

重点检查输入校验、权限、事务、资源释放、错误处理、重试和数据一致性。静态规则已有确定工具时沿用，不用语言判断替代编译和扫描。

第三步：验证候选问题

每条意见给位置、触发条件、可能后果、规则依据和验证办法。历史防御性代码不能仅因表面冗余建议删除；无法证明的问题标线索。

第四步：交人工取舍

将确认问题、需补上下文与普通建议分开。评审人记录采纳或拒绝理由，便于改进规则，不能自动采纳全部修改。

可以直接交给 WorkBuddy 的完整要求

按附件需求、规范和历史约束预审代码变更，先说明意图与上下文范围。
聚焦行为错误及高影响风险，避免堆格式建议。每条给准确位置、触发条件、影响、依据和可验证方式。
证据不足标候选，不编造行号或漏洞。不要自动修复、删除防御逻辑或合并代码；输出人工需要确认的问题。

完成后会得到什么

一份定位明确、可以验证的风险清单，以及上下文缺口。没有发现问题只表示本轮范围内未检出，不代表代码安全无缺陷。

结果应该怎么检查

人工逐项复现关键风险，确认位置与代码版本一致。特别检查资金、权限和并发路径，避免由同一套 AI 的生成与自审替代独立判断。

遇到这些情况怎么处理

误报多时收窄规则并补业务上下文。缺历史背景时咨询维护者。变更过大难评审时按行为拆分，不仅按行数机械分割。

哪些必须人工决定

评审人与代码负责人决定修复、风险接受和合并。AI 输出线索，不能担任最终放行者。