山东大学项目实训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. 审查质量深化
包括执行器重构、上下文增强、二次校验和知识文档补全。
十一、总结
这段时间我的工作，本质上是从“搭分析底座”推进到“做质量闭环”：
先把静态分析和解析能力接入，再让信号进入治理链路，最后通过测试门禁和二次校验让审查结果更稳定。