在项目中我主要负责代码审查链路中的代码分析和静态扫描具体包括以下几个方面1. 静态分析与结构上下文构建负责将 PR 变更代码、Semgrep 扫描结果和 Tree-sitter 解析结果进行统一组织形成可用于后续审查的结构化证据输入。这部分工作重点是把零散的代码变更信息转换为具备行级定位、符号级上下文和规则命中信息的审查材料为后续模型判断提供可靠依据。核心文件analyzers.py、parsers.py、review_pipeline.py2. 技能路由与 AI 审查流程设计参与审查任务的技能路由将变更内容、静态信号、技能信息和上下文证据统一送入模型生成结构化 Finding。这一部分的重点不是简单调用大模型而是让模型在正确的上下文中完成审查并输出可追踪、可解释的结果。核心文件router.py、review_pipeline.py、prompting.py3. 审查质量控制与结果治理参与候选 Finding 的二次校验、规则治理机制降低误报率并提升结果稳定性。通过二次校验和规则引擎的联动对候选结论进行过滤和策略化处理确保最终输出结果更准确、更适合落地。核心文件review_pipeline.py、rule_engine.py4. 稳定性与可维护性保障同时配合回归测试、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. 审查质量深化包括执行器重构、上下文增强、二次校验和知识文档补全。十一、总结这段时间我的工作本质上是从“搭分析底座”推进到“做质量闭环”先把静态分析和解析能力接入再让信号进入治理链路最后通过测试门禁和二次校验让审查结果更稳定。