设计一套精准、不流于形式的自动化 Code Review 工作流核心在于“不能让 AI 大海捞针”。如果只给 AI 一段代码并扔下一句“帮我找找 Bug”它通常只会指出一些命名规范、加没加注释等无关痛痒的毛病而对真正的并发死锁、架构越权视而不见。要让 AI 精准识别并发风险与架构违规必须采取结构化上下文输入与角色分工Agent 化的设计策略。1. 核心工作流设计Workflow Architecture一个完整的自动化 Review 流水线不应该只在 IDE 里单兵作战而应深度嵌入 CI/CD 流程如 GitHub Actions、GitLab CI。其核心逻辑是将静态分析AST 树/依赖检查与大模型的语义理解相结合。[代码提交 (Git Push/PR)] │ ▼ [CI 脚本预处理] ───► 提取变更代码 (Git Diff) 自动匹配相关上下文 │ ▼ [多 Agent 审查] ───► 代理 A并发与性能专家 (聚焦线程安全/锁/内存) │ ───► 代理 B架构与规范守卫 (聚焦分层/设计模式/依赖) ▼ [结果聚合与过滤] ───► 过滤低噪音 ───► 以评论形式写回 PR (Markdown 呈现)关键工程技巧如何给 AI 喂上下文不仅仅喂 Diff并发和架构问题往往隐藏在修改的代码之外。例如你改了一个函数但这个函数是被多线程调用的。上下文补充包在 CI 脚本中除了拉取git diff还应自动读取并拼接两个文件项目架构守则 (architecture_guidelines.md)明确定义分层规则、依赖禁忌。核心依赖关系当前修改的类所在的命名空间以及相关的基础基类。2. 自动化 Review Prompt 深度定制为了防止 AI 发散思维Prompt 必须使用严格的 XML 标签隔离、限定返回格式如 JSON并采用Few-Shot少样本提示明确告诉它什么是误报。 视角一并发与异步风险审查 PromptMarkdown# Role 你是一名精通高性能、高并发系统设计的资深系统架构师。你的任务是严格审查以下代码变更Git Diff中的并发安全性、线程安全漏洞以及异步编程误区如死锁。 # Context - 目标平台: .NET Core / C# (包含多线程、Task 异步模型) - 系统特性: 包含高频硬件通信、视觉数据流处理UI 线程与后台工作线程频繁交互。 # CheckItems (重点审查) 1. **死锁风险** 检查是否存在在异步上下文中调用 .Result、.Wait() 或 .GetAwaiter().GetResult() 的同步阻塞行为。 2. **锁的粒度与竞态条件** - 检查 lock 关键字的使用。是否锁定了 this、Type 或 string错误做法是否在 lock 块内部使用了 await会导致编译错误或严重死锁 - 多个锁嵌套时是否存在因加锁顺序不一致导致的死锁风险 3. **线程安全集合** 在多线程写入场景下是否错误地使用了常规的 ListT 或 DictionaryK,V 而未加锁是否应当替换为 ConcurrentDictionary 或 ChannelT 4. **资源释放非托管** 异步流或图像指针是否可能因异常未能触发 Dispose。 # Output Format (严格 JSON 数组格式不要包含任何多余的解释) [ { file: 文件名, line: 123, severity: CRITICAL | WARNING, issue: 具体问题描述 (描述其触发并发风险的机理), recommendation: 修复后的代码示例 } ] # Code Diff To Review code_diff {{GIT_DIFF}} /code_diff️ 视角二架构违规与规范守卫 PromptMarkdown# Role 你是一名严苛的软件系统总设计师。你的职责是确保团队提交的代码绝对符合项目的分层架构设计规范严防“面条代码”与架构越权。 # Input Context - 核心架构模式: MVVM (Model-View-ViewModel) 依赖注入 (DI) - 架构层级依赖规则: 1. View 层只能包含 UI 逻辑绝对不允许直接编写业务逻辑或直接访问数据库/硬件 SDK。 2. ViewModel 只能通过 Interface 注入服务严禁直接 new 核心业务逻辑类。 3. 严禁跨层直接调用例如底层 PLC 通信驱动不允许直接引用 UI 控件。 # Project Architecture Rules rules {{PROJECT_ARCHITECTURE_GUIDELINES}} /rules # CheckItems (重点审查) 1. **跨层越权** 检查是否有不符合依赖规则的命名空间引用using。 2. **逻辑错位** 检查 View 的后台代码.xaml.cs 或 WinForms 后台中是否混入了业务状态更改或数据处理逻辑。 3. **硬编码与高耦合** 检查本应通过配置或 DI 注入的类是否被硬编码单例或直接实例化。 # Output Format (严格 JSON 数组格式) [ { file: 文件名, line: 45, severity: ARCH_VIOLATION, issue: 违背了哪条架构规则为什么这样会导致系统腐化, recommendation: 重构建议如将此逻辑抽离至 ViewModel并通过 IService 注入 } ] # Code Diff To Review code_diff {{GIT_DIFF}} /code_diff3. 防噪与精炼如何让工具有效落地许多团队在引入 AI Review 后没几天就关掉了因为信息噪音Noise太大。AI 天生喜欢当“大好人”提一堆“代码可以更优雅”的废话。要让这个工作流真正运转需要做到以下三点红线机制Severity Filter在聚合 Agent 返回的 JSON 时编写一个轻量级脚本进行过滤。只有当severity为CRITICAL并发死锁、未加锁或ARCH_VIOLATION架构越权时才允许在 Pull Request 上自动创建阻塞性评论。普通的WARNING或代码风格建议只汇总到一个低优先级的折叠面板中。禁止指手画脚风格Code Style Banned在 System Prompt 中加入一条铁律“如果某段代码虽然不够优雅但在逻辑、并发和架构上是完全正确且安全的请保持沉默不要返回任何内容。”构建负反馈环Few-shot Calibration当开发人员在 PR 中标记某个 AI 审查是“误报False Positive”时CI 脚本应支持一键将这段代码和上下文归档到项目的false_positives.json中。后续作为 Prompt 的 Few-shot 示例喂给 AI“以下是历史上曾被误报的场景请在本次审查中避免类似的误判。”通过这种多专家 Agent 分工 - 严格的上下文喂入 - JSON 结构化过滤 - 人工负反馈微调的闭环AI 代码审查才能真正演进为保护老代码、拦截重大并发故障的硬核防线。