2026山东大学项目实训3月29日

一、项目背景在 CodeGuard AI 项目中我们尝试实现一个面向 GitHub Pull Request 场景的 AI 代码审查助手。整体思路并不是一开始就构建一个完整的平台而是优先完成一个“可运行的 MVP”先把核心流程打通再逐步补充配置能力和扩展能力。当前系统的主链路已经比较清晰从 GitHub Webhook 进入到审查任务创建再到异步执行分析流程最后生成结构化问题和评论草稿。整个过程涉及静态分析、代码解析、模型生成以及规则治理等多个环节。在这个体系中我负责的部分主要是为 AI 引擎提供代码分析数据支持。相比前端展示或者最终审查结果这一部分更偏底层但它直接影响后续分析是否稳定、结果是否可解释以及系统是否具备持续演进能力。因此在初期阶段我的重点是围绕静态分析、AST 解析和规范映射逐步搭建数据底座。二、当前架构中的位置与职责从整体架构来看当前 CodeGuard AI 的端到端流程如下GitHub Webhook 请求进入系统接口后端创建或复用项目与仓库绑定关系持久化 PR 快照与审查任务Celery Worker 拉起异步审查流程通过 Git 提供方获取 PR 元数据与变更文件静态分析器和内置技能生成候选信号代码解析器提取 Python / Java 上下文信息LLM 根据输入生成结构化问题治理模块完成去重、评分与评论草稿生成审查人确认或发布评论并回写 GitHub 或 Mock在这条链路中我主要参与的是中间分析层包括StaticAnalyzer静态分析CodeParser代码解析KnowledgeMatcher规范映射这些模块的共同目标是把原始代码变更转换为可结构化、可计算的数据输入为后续 LLM 和技能引擎提供基础。三、为什么优先做“数据底座”在项目初期一个比较明显的取舍是不急于优化模型效果而是先把数据输入准备好。原因比较直接如果没有静态分析信号模型容易只依赖局部上下文如果没有 AST 结构信息复杂代码关系难以表达如果没有规范映射审查结果缺乏依据如果数据结构不统一后续模块难以协同因此这一阶段的重点不在“输出多智能”而在“输入是否可靠”。当前的工作更接近于把代码从“文本”转变为“可分析数据”让后续流程能够在统一结构上运行而不是依赖零散信息拼接。四、静态分析工具集成Semgrep静态分析是最先展开的一块工作。项目中选择使用 Semgrep 作为基础分析工具其主要作用是提供一层规则驱动的检测信号。在初期阶段重点不是工具本身的接入而是围绕以下几个问题展开规则范围如何定义安全类与质量类哪些规则适合当前 MVP 场景如何让规则结果能够进入系统数据结构如何为规则效果准备验证样本目前正在逐步整理规则配置重点覆盖常见的安全问题和代码质量问题。同时也在同步准备测试代码片段用于后续验证规则命中情况。这里的关键点在于规则不是越多越好而是要和实际审查场景对齐。否则即使工具能检测出问题也不一定能在系统中产生有效价值。五、测试数据集的准备为了验证静态分析工具的实际效果需要构建一组具有代表性的测试数据。测试集主要用于两个目的验证规则是否能够覆盖典型问题为后续调整规则提供参考依据在当前阶段测试数据的整理还在持续进行中。重点是按照问题类型进行分类而不是简单堆积代码片段。这样在后续分析时可以更清晰地看到不同规则在不同场景下的表现。相比结果本身这一步更像是在为后续调优建立基准。如果没有统一的测试集后面很难判断规则效果是否真的发生变化。六、AST 解析能力tree-sitter除了静态分析AST 解析是另一项基础能力。项目中使用 tree-sitter 来支持 Python 和 Java 的语法解析。这一阶段的工作重点主要集中在确认多语言解析能力是否稳定设计解析结果的数据结构提取基础的函数信息和调用关系控制解析性能适配 PR 场景需要注意的是这里的目标并不是做复杂的语义分析而是先提供基础结构信息。例如函数定义、调用关系、代码块层级等这些信息可以为后续技能判断提供支持。从工程角度来看AST 的价值在于让系统具备“理解代码结构”的能力而不是只停留在文本匹配层面。七、技能引擎的数据准备在当前架构中审查能力并不是完全依赖 LLM而是通过“技能引擎”进行一定程度的结构化分析。为了让技能引擎能够正常工作需要提前准备数据输入。这一部分主要包括静态分析产生的候选信号AST 提供的上下文信息规范映射所需的关键词数据目前的重点在于统一这些数据的表达方式使不同来源的信息能够在同一结构下进行组合。这样后续技能模块在处理时不需要额外适配不同数据来源。从实现角度来看这一步属于“接口前置设计”目的是降低后续模块之间的耦合。八、轻量级知识库与规范映射在知识层面项目初期没有引入复杂的向量检索或 RAG而是先采用关键词映射的方式实现一个轻量级版本。当前主要工作包括从规范文档中提取关键词建立关键词与规范条款之间的映射关系为常见问题类型准备匹配数据这种方式虽然简单但可以在不增加系统复杂度的情况下让审查结果具备基础的“规范引用能力”。例如当某个问题命中关键词时可以在输出中附带对应的规范说明。在这一阶段更关注的是匹配的稳定性而不是覆盖的全面性。优先保证常见问题能够正确映射再逐步扩展范围。九、当前阶段的工程取舍当前 MVP 在设计上有一些明确的取舍这些取舍也影响到数据层的实现方式默认数据库使用 MySQL同时保留 SQLite 作为轻量环境在缺少外部凭据时系统会进入 Mock 模式GitLab、向量检索等能力暂时只保留接口这些设计使得项目在开发阶段可以更容易运行和调试也意味着在实现数据分析模块时需要考虑“降级路径”保证在简化环境下仍然具备基本功能。十、小结从整体来看这一阶段的工作重点为先把“代码 → 可分析数据”这条链路建立起来。当前主要在推进的内容包括静态分析规则与测试数据准备AST 解析能力的接入与结构设计技能引擎的数据输入整理规范关键词映射的基础配置这些工作大多属于底层准备不会直接体现在最终展示效果中但它们决定了后续 AI 审查能力能否稳定运行。