30-模块四-AI代码审核实战 第30讲-模块实战 - CodeSentinel 自动审核管线完整实现(从 PR 提交到审核报告)

本讲目标：把模块四散落能力收敛为一条可运行的端到端链路：从 GitHub Webhook 接收 PR 事件，到拉取 diff、分块、运行多阶段审核（安全、架构合规、性能、质量、AGENTS.md 合规），再到聚合ReviewReport、格式化 Markdown 评论、写回 PR 与提交状态；附带集成测试（mock webhook）与 Docker Compose 交付物，以及 curl 演示脚本。本讲是模块四的「集成交付」，强调可观测、可重试、可扩展。请预留至少两小时动手：一小时跑通 demo，一小时把module4测试改写到你的仓库路径上。开场：模块四的终点不是更多规则，而是一条可靠管线如果你完成了前几讲却停在「各自能跑」，团队感知仍然是碎片化工具：安全扫描归安全，性能提示归性能，规范合规归文档。研发真正需要的是：一次 PR 推送，一次清晰结论。结论应当分层：哪些必须修、哪些建议修、哪些属于信息提示；同时给出可点击的定位与可审计的记录。本讲要把 CodeSentinel 推过这道门槛，变成「像 CI 一样默认存在」的基础设施。我们会实现一个显式编排器ReviewPipeline：它不做具体规则细节，而是定义阶段（stage）契约、统一输入输出、聚合结果、生成报告。各阶段分别对应你在模块四已建立的心智模型：安全审核（第 26 讲占位实现）、架构合规（第 25 讲占位实现）、性能检测（第 27 讲PerformanceChecker思路落地简化版）、质量评分（第 28 讲QualityScorer）、以及模块三的AGENTS.md合规（以最小启发式占位，避免本讲篇幅失控）。占位实现不是偷懒，而是教学上的「插拔点」：你能在不推翻架构的情况下替换为真实规则引擎与 LLM 调用。完成本讲后，你应能演示一次完整闭环：推送 PR → Webhook 触发 → 状态 pending → 审核完成 → 评论出现 → 状态 success/failure。并且你能解释：为什么编排器要幂等、为什么评论要分层、为什么集成测试必须 mock 平台 API。下面先给出总体架构与端到端时序，再给出完整代码与 Compose。在落地时，请把「演示成功」与「生产可用」刻意分开。演示成功只需要一条路径跑通；生产可用需要失败重试、权限边界、机密管理、限流、可观测性与回滚策略。本讲代码同时服务两者：核心结构按生产思路写，但部署形态保持教学简洁。你应当能指出哪些行在真实环境必须替换（例如同步 httpx、缺少队列、以及过于天真的密钥正则）。这也是 AI 架构师常见工作：不是写不出 demo，而是知道 demo 离生产还差哪些硬条件。另外，本讲刻意把 Markdown 代码围栏与 Python 源码中的反引号处理干净，避免「文档里的代码块被提前截断」这种低级但致命的问题。你在维护自己的课程文档或内部 wiki 时，也应建立同样规范：长代码优先放仓库文件，文档只引用路径；或在生成代码时避免三反引号字面量。仓库中的module4/目录就是为解决这个问题而准备的「单一真相来源」。全局视角：模块四完整管线架构（Mermaid）外部系统CodeSentinel 核心边缘层GitHub WebhookFastAPI验签DiffParser(unified diff → chunks)ReviewPipelineorchestratorSecurityStageArchitectureStagePerformanceStageQualityStageAgentsComplianceStageReviewReportaggregatorGitHubCommentFormatterGitHub REST APIcodesentinel-clean-lab/reviews 可选端到端序列：从 PR 事件到评论回写（Mermaid）GitHub APIReviewPipelineCodeSentinelGitHub研发推送GitHub APIReviewPipelineCodeSentinelGitHub研发推送