山东大学项目实训6月20日

在项目中，我主要负责代码审查链路中的代码分析和静态扫描，具体包括以下几个方面：

1. 静态分析与结构上下文构建

负责将 PR 变更代码、Semgrep 扫描结果和 Tree-sitter 解析结果进行统一组织，形成可用于后续审查的结构化证据输入。
这部分工作重点是把零散的代码变更信息转换为具备行级定位、符号级上下文和规则命中信息的审查材料，为后续模型判断提供可靠依据。
核心文件：analyzers.py、parsers.py、review_pipeline.py

2. 技能路由与 AI 审查流程设计

参与审查任务的技能路由，将变更内容、静态信号、技能信息和上下文证据统一送入模型，生成结构化 Finding。
这一部分的重点不是简单调用大模型，而是让模型在正确的上下文中完成审查，并输出可追踪、可解释的结果。
核心文件：router.py、review_pipeline.py、prompting.py

3. 审查质量控制与结果治理

参与候选 Finding 的二次校验、规则治理机制，降低误报率并提升结果稳定性。
通过二次校验和规则引擎的联动，对候选结论进行过滤和策略化处理，确保最终输出结果更准确、更适合落地。
核心文件：review_pipeline.py、rule_engine.py

4. 稳定性与可维护性保障

同时配合回归测试、CI 检查和本地验证机制，提升系统在不同运行环境下的稳定性和可维护性。
核心文件：review_pipeline.py、review_tasks.py、quality_gates.py

一、项目背景

在 CodeGuard AI 这个项目里，我负责的方向始终比较明确：为 AI 审查引擎提供代码分析数据，并把这些数据逐步接入规则、技能、规范和验证链路。
如果把这一段时间的工作连起来看，它是沿着一条递进路径展开的：

先把分析输入层搭起来，再把工具接进去，再把信号接进治理链路，随后补齐接入验证、权限与策略回归、工程化检查，最后再让审查质量本身稳定。

这篇文章按这个思路，把我在项目里负责的内容做一个总结。

二、起步阶段：先搭代码分析输入层

项目刚开始时，我的重点是解决一个基础的问题：AI 审查到底需要什么输入。

这一阶段我做的事情，可以概括成三件：

第一，明确自己的职责定位是为 AI 审查提供分析数据，而不是直接生成结论。
第二，把分析能力拆成三块基础方向：静态分析、AST 解析、轻量规范映射。
第三，设计降级路径，让简化环境下也能运行，保证项目至少在本地可调试、可演示。

因为如果输入层不稳定，后面无论是规则判断、技能引擎，还是评论草稿，都很难真正落地。

三、接入阶段：把关键工具加入到主链路

在分析底座的方向确定之后，接下来就是把工具接进来。

这一阶段我主要推进了两件事：

一是接入 Semgrep，把静态分析能力放进主流程里。
二是接入 tree-sitter，让 Python 和 Java 的代码结构上下文能够被提取出来。

同时，我也把系统内的分析职责分层得更清楚：

• StaticAnalyzer 负责规则信号

• CodeParser 负责结构上下文

• KnowledgeMatcher 负责规范映射

这样一来，审查主链路不再只是拿一段 diff 去给模型看，而是开始具备更完整的输入结构：规则信号、代码上下文和基础规范信息。

这一点的价值在于，AI 审查开始结合结构信息。

四、联动阶段：让分析结果进入治理体系

工具接进来之后，下一步不是简单叠加功能，而是让这些分析结果真正进入规则、技能和规范映射体系。

这一阶段，主要任务是三件事：

第一，把 Semgrep 和 AST 的信号接进规则、技能、规范映射体系。
第二，让 skill signal 不再只是日志，而是能进入 finding 生成链路。
第三，让规则开始约束技能启用和严重级别映射。

系统从能分析走到了能参与审查决策。
也就是说，分析结果不再只是提供参考，而是开始影响后续的审查输出。

这一步完成后，审查链路的结构就更完整了：
不是单纯发现问题，而是先筛选、再治理、再生成草稿，最后进入确认和发布流程。

五、接入验证阶段：协同保证链路可验证、可追踪

在分析和治理能力接上之后，我参与了与审查链路相关的验证工作，主要是确保系统在真实接入场景下可验证、可追踪、可回归。

这一阶段我协同补了三类能力：

第一类是接入状态校验。
包括 OAuth 后仓库可访问性校验、Webhook 状态校验、签名校验，确保接入过程不是只看“成功”提示，而是能明确知道当前链路是否可用。

第二类是链路回归。
从 webhook 到评论发布的整条链路都做了验证，确认每个环节都能正常流转。

第三类是稳定性追踪。
重复 webhook 去重、投递记录、审计日志这些能力都补上了，让系统在重复事件下也能保持幂等和可排查。

这一阶段之后，审查链路不只是能跑，而且具备了能验证、能定位、能复现的特征。

六、治理与权限阶段：参与协同策略生效和边界正确性

在团队策略和权限治理逐步加入后，我参与了与审查结果相关的验证工作，并协同完成角色边界、策略继承和准入流程的回归。

这一阶段我关注的主要是四个方面：

第一，验证团队策略继承是否真的会影响 findings。
第二，补齐 owner、editor、viewer 三种角色的权限边界测试。
第三，兼顾真实登录切换后的测试回归和 webhook 兼容。
第四，覆盖准入申请状态流转和权限拦截场景。

这一阶段的意义在于，系统开始从单仓库、单路径走向团队可治理、策略可继承的模式。
很多权限或策略问题会直接影响审查结果是否可信。
所以这一步不是简单的配套工作，而是让整个系统具备治理基础。

七、工程化阶段：补充回归体系和持续交付

在功能和治理能力逐步稳定之后，参与了与审查链路相关的测试门禁和回归固化，配合团队一起完善工程化检查。

具体来说，包括以下几类工作：

• 补统计接口正确性测试，验证过滤、趋势和 CSV 导出

• 验证多用户作用域隔离

• 推进 CI 自动检查

• 配套本地一键检查脚本

• 补迁移策略与安全改造的回归验证

这一层的意义在于，把功能能用推进到功能改了之后还能稳住。
项目越往后走，越不能只靠人工记忆去判断改动有没有问题。
所以这一阶段做的事情，是给整个项目建立一层持续可维护的回归基础。

八、稳态阶段：使关键行为保持稳定

到这个阶段，项目已经进入一个比较关键的状态：很多核心能力都已经接上了，但真正重要的是，它们能不能在变化中依然保持稳定。

所以我开始把一些关键行为进一步固化成可回归测试和快速门禁：

• 新增稳定性测试，覆盖 fallback、幂等跳过、退避窗口

• 接入 smoke-acceptance 快速门禁

• 固化关键词定位行为，确保具体关键词优先命中、路径可兜底

• 扩展审查详情字段回归，保证前后端一致可见

这一步的重点，是把那些在改动中最容易出问题的路径固定下来。
这样后面无论是做优化还是补功能，都能更快发现问题，不会等到整体流程出问题才回头排查。

九、质量深化阶段：稳定审查链路

最后一阶段的重点，是让审查质量本身继续提升。
这个阶段我做了几项比较关键的升级：

• 重构技能执行器，支持 builtin、semgrep、llm_judge、keyword_fallback

• 增强 tree-sitter 的上下文输出

• 增加候选 finding 的二次校验

• 补齐内置技能知识文档

这一轮补强之后，技能不再只靠关键词触发，解析也不再只是文本摘要，finding 也不再是发现就进入。
整个链路开始有了更清楚的边界：

• 技能执行更灵活

• 代码上下文更完整

• 候选证据要先过 verifier

• 内置技能判断有了更明确的适用场景和反例边界

这意味着审查结果不只是有问题，而是更接近于为什么是问题、证据在哪里、是不是值得进入治理。

十、累计完成工作的总体归纳

如果把这段时间的工作按能力维度来统计，我的职责相关内容已经形成了一套比较完整的链路：

1. 分析底座建设

包括 Semgrep、AST、轻量规范映射和降级路径设计。

2. 链路接入联动

包括分析信号接入技能、规则和 finding 生成链路。

3. 接入验证

包括 OAuth、Webhook、签名、去重和审计追踪。

4. 治理与权限稳定性

包括策略继承、角色边界、准入流程和登录切换回归。

5. 工程化回归体系

包括测试补强、CI、smoke 检查、迁移策略验证。

6. 审查质量深化

包括执行器重构、上下文增强、二次校验和知识文档补全。

十一、总结

这段时间我的工作，本质上是从“搭分析底座”推进到“做质量闭环”：

先把静态分析和解析能力接入，再让信号进入治理链路，最后通过测试门禁和二次校验让审查结果更稳定。