导读
AI 写代码越来越快，网盘主端 FE 团队每月约 2000 次 CR 中，AI 生成代码占比已达 55.87%。代码产出速度提升，传统人工 Code Review 的压力同步放大——Reviewer 不仅要看代码风格，还要判断逻辑、调用链、API 契约和高危问题，精度与专注度双双下降。本文分享了他们如何在 CI/CD 流水线中嵌入 AICR 强制检测链路，用多维度多角色 AI 审查为人工 Reviewer 减负，以及建设过程中对检测耗时、误报治理、模型选型等问题的实战思考。
01 我们为什么需要建设AICR准入流程？
网盘主端 FE 团队每月大约有2000 次 CR，随着 AI Coding 的普及，其中由 AI 生成代码覆盖的比例已经达到约55.87%。代码产出速度变快以后，传统 Code Review 面临的压力也被同步放大：reviewer 不仅要看代码风格和实现细节，还要判断需求逻辑是否正确、跨文件调用是否同步、状态流是否完整、API 契约是否被破坏，以及是否存在运行时崩溃、资源泄漏、代码不可交付等高危问题。大量的CR以及每个CR中大规模的修改，都在使得人工CR的精度与专注度出现了下降，从而导致Cood Review作为入库的最后一道门禁，效果锐减。
在这样的背景下，我们需要的不是一个“给建议”的轻量工具，而是一套能进入准入链路的强阻塞质量检查能力。它必须能够识别高危代码问题，能够理解一定程度的需求和业务逻辑，能够对 AI 生成代码进行更严格的事实复核，也能够把每次审查结果沉淀成 可收集、可量化、可回溯、可升级的数据资产。
所以，我们的目标是建立一个深度嵌入场内工作流，以CR为维度，帮助Code Reviewer减负，帮助团队内的同学高质量接入的代码准入Agent工具。
网盘主端FE团队接入AICR阶段性数据：
*数据收集时间为0401-0621
02 检测链路与审查链路简介
目标：一套强制检测链路+ AI多维度多角色审查 = Reviewer思想解放
2.1 检测链路简介
从 icode 提交 CR，到 ipipe 动态资源、开发机、检测脚本、检测执行，最后回写结果。点击任一节点查看步骤作用。
步骤作用
icode 提交 CR
接收 CR 创建、更新或重开事件，把仓库、分支、提交、作者、diff 和策略整理成一次检测任务。
-
建立 trace_id，后续资源申请、脚本执行、AI审查和报告回写都能追踪。
-
提取 diff 范围和评审上下文，为后续选择检测脚本与模型上下文做准备。
2.2 多维度多角色审查步骤
AI审查步骤
大模型检测的核心步骤：组织上下文、编排任务、并行审查、核验证据、裁决风险、生成报告。点击任一节点查看 Prompt 节选。
Prompt 节选
上下文生成
把 diff、相关文件、调用关系、规则说明和历史风险压缩成模型可审查的上下文包。
你是 AICR 的上下文整理器。
请基于 CR diff、相关文件片段、仓库结构和规则策略，输出：
1. 本次变更意图
2. 关键代码路径
3. 需要重点审查的风险面
4. 可引用的证据位置
要求：不要发散，只保留会影响审查判断的信息。
03 建设过程中的思考
3.1 CI/CD流水线还是Pre-commit？
在网盘主端 FE 团队开始考虑接入 AICR 时，团队面前主要有两条路径：一种是深度集成场内工作流，以 CR 为维度，在每次向 iCode 提交 CR 请求时，自动触发对应的 AICR 检测流水线；另一种是在提交前通过本地工具介入，例如向团队成员统一发放 Husky，在 commit 前基于本地工作区 diff 触发 AICR 检测。
经过综合评估，网盘主端 FE 团队最终选择以 CI/CD 检测流水线作为团队代码准入的先行方案。核心原因在于：CI/CD 流水线更适合作为团队级、CR 级、可治理、可闭环的质量准入机制，而本地 Pre-commit 更适合作为个人开发阶段或分支级别的大范围提前检测手段。
CI/CD 检测流水线方案
CI/CD 检测流水线方案，是指将 AICR 嵌入 iPipe 等场内 CI/CD 流程中，在开发者提交 CR 后，由流水线自动拉取代码、执行 AICR 检测，并将检测结果回写到 iCode、如流工作卡等场内系统中。
1. 优点
第一，规则与脚本可以统一管理、热更新生效。流水线中执行的脚本来源于统一管理者，脚本更新、规则更新、模型选择策略更新都可以通过流水线模板集中完成。每次 CR 触发流水线时，都会自动使用最新版本的检测脚本和规则配置。依托 iPipe 流水线模板机制，一次更新即可影响所有引用该模板的代码仓库，具备较强的统一治理能力。
相比之下，本地 Pre-commit 依赖用户在本地手动更新脚本，或者依赖统一仓库更新后再被用户拉取生效。这个过程天然存在滞后，难以保证所有开发者本地环境中的规则、脚本和模型策略保持一致。
第二，可以深度接入场内权限与工作流，形成检测闭环。依赖 CI/CD 流水线执行的 AICR，可以由 iPipe 注入对应的场内权限。检测完成后，系统既可以向如流智能工作卡发送检测结果，推动提交者处理问题，也可以向 iCode CR 中写入评论和审查结论，帮助 Code Reviewer 快速理解本次修改内容、潜在风险和建议关注点。
这意味着 CI/CD 方案不仅能发现问题，还能完成结果触达、评论回写、反馈收集和流程闭环。而本地 Pre-commit 主要运行在开发者本地，只能服务提交者本人，无法有效帮助 Code Reviewer，也难以将检测结果嵌入团队正式 CR 流程。
第三，检测数据可以统一沉淀，便于后续分析和优化。CI/CD 流水线天然具备数据上报和留痕能力。每次检测结果都可以与对应 CR 绑定，形成长期可追溯的数据资产。这些数据可以用于后续分析团队代码质量趋势、误报类型、缺陷分布、模型效果、规则有效性以及不同业务模块的风险特征。
而 Pre-commit 运行在本地，检测结果通常不会与正式 CR 形成稳定关联，也缺少统一上报链路。对于后续模型选型优化、规则优化、误报治理和团队代码质量提升来说，本地方案的数据价值相对有限。
第四，可以使用统一标准的 Agent 工具与动态资源环境，提升性能稳定性。CI/CD 检测流水线可以使用统一标准的 Agent 工具，例如 zulu，来完成模型调用。同时，流水线可以基于标准动态资源镜像进行独立分析，避免受到开发者本地复杂线程环境、依赖环境、内存限制和机器性能差异的影响。
通过统一执行环境，AICR 可以获得更稳定的资源保障、更一致的运行结果和更可控的性能表现，从而减少检测耗时波动，提升整体审查体验。
2. 缺点
CI/CD 检测流水线的主要不足，是需要在动态资源服务器上下载代码。由于检测发生在流水线机器或动态资源服务器上，系统需要先拉取本次 CR 对应的代码内容，再进行分析和审查。这会引入额外的代码下载耗时。
相比之下，本地 Pre-commit 直接运行在开发者本地工作区，不需要额外下载代码，因此在代码获取环节具备天然优势。
本地 Pre-commit 方案
本地 Pre-commit 方案，是指通过 Husky 等机制，在开发者执行 commit 前，基于本地工作区 diff 触发 AICR 检测，将问题提前暴露在提交之前。
1. 优点
第一，不需要额外下载代码，启动链路更短。Pre-commit 直接读取本地工作区代码和 diff，不依赖远端流水线机器拉取仓库，因此在代码获取环节更轻量。
第二，更适合开发者个人提前自检。本地检测发生在 commit 前，可以帮助开发者在正式提交 CR 之前发现一部分问题，减少低级缺陷进入 CR 流程。
第三，更适合分支级别的大型检测。由于本地工作区可以包含更多未提交内容，Pre-commit 或本地检测机制更适合做分支级别、开发阶段的大范围扫描，而不局限于一次 CR 的轻量变更。
2. 缺点
第一，脚本、规则和模型策略难以统一更新。本地 Pre-commit 依赖用户本地环境。脚本更新、规则更新和模型选择策略更新，都需要依赖用户主动拉取、安装或更新。如果部分开发者未及时更新，就会导致检测标准不一致，影响团队级治理效果。
第二，无法深度接入 CR 审查流程。Pre-commit 的检测结果主要反馈给提交者本人，无法自然回写到 iCode CR，也无法向 Code Reviewer 提供修改概述、审查建议和风险提示。因此，它对正式 CR 审查流程的辅助价值有限。
第三，检测结果难以统一沉淀和分析。本地检测结果通常不会与 CR 形成稳定绑定，也缺少统一上报与留痕机制。长期来看，不利于团队分析误报来源、缺陷分布、模型效果和规则优化方向。
第四，运行环境受本地机器影响较大。不同开发者的本地机器性能、依赖版本、线程环境和内存限制都可能不同，这会导致 AICR 检测耗时和稳定性出现较大波动，也会增加排查问题的复杂度。
综合来看，网盘主端 FE团队选择 CI/CD 检测流水线作为 AICR 的先行接入方案，是因为它更符合团队级代码准入的核心诉求。
AICR 在网盘主端 FE团队中的目标，不只是帮助个人在提交前发现问题，而是要成为嵌入 CR 流程的质量保障机制。它需要具备统一规则、统一执行环境、统一数据沉淀、统一结果回写和完整反馈闭环的能力。
因此，CI/CD 流水线更适合作为当前阶段的主方案。它可以在每次 CR 提交后自动执行检测，将检测结果沉淀到正式流程中，并通过 iCode 评论、如流卡片和数据上报机制，持续帮助提交者、Reviewer 和团队管理者提升代码质量。
而本地 Pre-commit 并不是被否定的方案。它更适合作为后续补充能力，用于开发者个人自检、分支级大型检测或提交前提前发现问题。
CI/CD 流水线负责团队级准入与闭环治理，Pre-commit 负责个人级前置自检与分支级深度扫描。
3.2 如何做到检测与结果反馈闭环？
缺少闭环机制的检测结果，本质上是一种 “噪音”
我们深知，没有闭环的检测结果，很容易被大家忽视。因此，AICR 在检测完成后，会通过自动化推送、iCode 评论沉淀和智能工作卡反馈机制，形成完整闭环，确保问题能够被及时看到、快速处理，并持续优化检测效果。
-
检测结果自动推送给提交用户：AICR 检测结束后，ipipe 会将检测结果自动发送给 n8n 工作流。n8n 会判断是否存在缺陷问题；如果存在，则调用智能工作卡，将分支、amend 和检测报告通过如流推送给对应的提交用户。
-
检测结论同步沉淀到 iCode：在 AICR 检测结束前，系统会通过 iCode API，将检测结论、AI 认为有意义的建议，以及辅助 Reviewer 检查的修改概述，以评论形式输出到 iCode，方便所有人查看。
-
支持误报即时反馈：智能工作卡提供即时反馈机制。对于误报，用户可以直接在工作卡内反馈；AICR 服务收到反馈后，会自动打 0 分用于跳过。
-
检测报告可在如流中快速查看：用户也可以在智能工作卡的如流对话界面中直接查看检测报告，对检测结果进行快速确认。
n8n工作流：
3.3 误报是可以容忍的吗？
大语言模型的本质，是基于上下文对可能输出进行概率建模与生成。因此，AICR 需要在充分释放大模型能力和有效约束低质量输出之间取得平衡：既要让模型深入理解代码上下文、挖掘真实缺陷，也要通过规则、评分、过滤和反馈机制，抑制误报、无效问题和主观猜测，确保最终输出的问题具备明确依据、实际价值和可处理性。
1. 尽量释放大模型的上下文理解与缺陷识别能力在尽可能减少外部限制的情况下，大模型可以更充分地发挥自身能力，包括上下文阅读能力、代码依赖的深度检索能力、边界条件模拟能力，以及对运行时缺陷和逻辑漏洞的识别能力。
2. 在规则明确、上下文充分时，模型能发现更真实的问题当代码规则清晰、上下文信息充足时，大模型可以较敏锐地识别代码中潜在的运行时问题、逻辑不对称问题，以及实际执行过程中可能出现的边界异常。对于内存泄露相关代码，大模型也具备较强的识别和推理能力。
3. 高阶模型可辅助判断 UI 与交互层面风险部分高阶模型甚至能够对 UI 显示效果进行一定程度的模拟和判断，从而辅助发现交互、展示层面的潜在问题，为前端代码评审提供额外参考。
4. 缺少约束时，模型容易产生低质量噪音但如果缺少必要约束，大模型也容易代入“主动寻找问题”的角色，将“发现问题”本身视为目标或奖励。这会导致模型倾向于输出大量似是而非、吹毛求疵、低质量，甚至无中生有的猜测类问题。
5. 低质量输出会影响提交者、Reviewer 和接入方信心这类噪音不仅会给代码提交者带来额外困扰，也会干扰 Reviewer 对真正风险的判断，增加审查负担。长期来看，如果 AICR 输出的问题质量不稳定，接入方很容易对该机制失去信心。
6. 网盘主端 FE团队采用“中庸路线” ：一方面充分释放大模型能力，让模型理解上下文、挖掘真实缺陷；另一方面通过规则、评分、过滤和反馈机制，对低质量输出进行约束，确保 AICR 最终输出的问题更加可靠、有效、可处理。
加强审查的策略
先理解变更，再多路检测，最后复核兜底
AICR 在正式开始代码审查前，会先对本次修改进行逻辑序列化分析，帮助模型建立完整的代码变更上下文。在此基础上，再通过三路并行检测从多个方向独立审查问题，并结合复核 Agent 二次校验机制，提升缺陷发现的准确性、稳定性和可信度。
1. 审查前先进行逻辑序列化分析在正式代码审查前，AICR 会先使用 AI 对本次修改进行逻辑序列化分析。系统会围绕每一个修改点，识别其对应的修改维度、具体变更内容、影响范围以及调用链路，帮助模型在审查前建立完整的代码变更上下文。
2. 三路并行检测，从不同方向独立审查在完成变更理解后，AICR 会采用三路并行检测策略。三路检测会分别从不同角度对代码修改进行独立审查，例如运行时风险、逻辑一致性、边界条件、调用链影响、代码质量与可维护性等维度。
3. 多份结果统一聚合，形成最终检测报告每一路检测都会生成一份独立检测结果。随后，模型会对三份结果进行分析、去重、归并与聚合，最终形成一份更加完整、准确且可读的检测报告。
4. 新增复核 Agent，降低真实缺陷被误删的风险AICR 新增了复核 Agent 机制。当核实 Agent 判断某个缺陷需要删除时，复核 Agent 会对该删除行为再次复核，避免真实缺陷因误判被过滤掉。
5. 通过二次校验提升结果可靠性通过复核 Agent 的二次校验机制，AICR 可以进一步提升缺陷处理的可靠性，降低漏报风险，增强最终检测结果的稳定性和可信度。
减少误报与噪音的策略
核实验证、评论过滤、纠错沉淀
1. 核实 Agent 反向验证问题是否真实存在核实 Agent 会基于审查结论，反向检查代码实现与检测结论之间是否一致，判断该问题是否真实存在，以及对应错误是否值得被认定为缺陷。
2. 不只关注“是否发现问题”，更关注“是否值得输出”核实 Agent 不仅会关注模型是否发现了问题，还会进一步验证该问题是否具备明确代码依据、真实触发路径、实际影响范围和修复价值。
3. 过滤证据不足或价值较低的问题对于缺少充分证据、影响较弱，或判断依据不成立的问题，核实 Agent 会进行过滤，避免其进入最终输出结果，从源头降低误报和低质量问题。
4. 静态评论过滤，减少无效打扰AICR 建立了静态评论过滤机制。系统不会对所有检测结果都直接生成评论，而是会根据问题价值、影响程度和可操作性进行筛选，只有真正值得被评论的位置才会新增评论。
5. 控制重复评论和低价值提醒通过静态评论过滤，可以显著减少无效评论、重复评论和低价值提醒，降低对提交者和 Reviewer 的干扰。
6. 纠错本沉淀高频误报与业务规则AICR 还引入了纠错本机制。针对网盘主端 FE 等重点业务场景中高频出现的误报、固定业务逻辑、历史沉淀规则以及特定代码模式，系统会持续沉淀纠错经验，形成可复用的纠错本。
7. 结合纠错本修正类似问题，减少重复误报在后续检测过程中，AICR 会结合纠错本对类似问题进行识别和修正，从而减少重复误报带来的噪音，持续提升检测结果的稳定性和可信度。
3.4 检测耗时的Sweet Spot 在哪？
AICR 审查耗时控制：5 分钟甜点时间与分阶段管线
网盘主端 FE 团队的 AICR 审查管线已经深度嵌入整体 CR 提交与合入流程，并具备阻塞合入的能力。因此，AICR 不仅要保证检测质量，也必须对审查耗时进行精准控制，避免影响后续提测、合入和业务使用节奏。
结合代码提交后的固定编译耗时、CR 流程耗时，以及业务侧同学对使用体验的接受度，网盘主端 FE 团队将 AICR 的甜点时间定义为平均 5 分钟。
1. 以平均 5 分钟作为审查甜点时间：AICR 需要在平均 5 分钟内完成一次 CR 审查的核心链路，既保证模型有足够的上下文理解和缺陷发现能力，也避免因审查耗时过长影响业务侧同学的使用体验。
2. 对每个阶段进行思维负担控制与超时控制：为了稳定控制整体耗时，AICR 会对每个阶段设置合理的时间预算、超时策略和输出边界，避免单个阶段过度推理、反复发散或长时间等待。
3. CR 审查流程被拆分为多个明确阶段：一次完整 CR 审查的时间主要拆分为以下阶段：
-
下载代码：将本次 CR 涉及的代码下载到脚本部署机器，作为后续分析和审查的基础输入；
-
AI 分析修改维度：对本次变更进行逻辑序列化，识别修改点、影响范围、调用链路以及可能涉及的业务逻辑；
-
AI 代码缺陷审查：基于修改维度和上下文，检测潜在运行时缺陷、逻辑漏洞、边界问题、内存风险等；
-
AI 缺陷核实：对审查阶段发现的问题进行反向验证，确认问题是否真实存在，是否具备明确代码依据、触发路径和缺陷认定价值；
-
AI 缺陷复核：对核实阶段被删除或过滤的问题进行二次复核，避免真实缺陷因误判被过滤，降低漏报风险；
-
AI 绝对安全检查：对最终结果进行兜底检查，避免输出明显错误、无依据、高噪音或可能误导提交者的问题；
-
AI 生成建议与评论：将最终审查结论、修改概述、有效建议和必要评论生成结构化输出，并通过 iCode 评论、智能工作卡等方式触达提交者和 Reviewer。
4. 在检测质量与使用成本之间取得平衡：通过对审查阶段进行明确拆分，AICR 可以在整体 5 分钟甜点时间内，对各环节进行精细化控时。这样既能保证审查结果具备足够质量，也能避免流程对 CR 合入和业务交付造成额外阻塞，最终在检测质量与使用成本之间取得平衡。
04 遇到的问题与解决方案
4.1 模型变更后检测时间不可控问题
在 AICR 早期阶段，系统使用 GLM5.0 作为检测模型。基于当时的模型逻辑能力、缺陷检测能力以及场内部署资源，GLM5.0 是一个相对合适的选择。但由于早期模型自身的缺陷发现能力有限，整体缺陷检出能力只有约 5%，因此当时 AICR 采用了较细、较强的规则约束，希望通过强制模型深入检查来提升检测深度与广度。
后期切换到 GPT5.5 后，模型缺陷检测能力提升至约 25%，但同时也暴露出检测耗时过长、输出内容过多、无效上下文膨胀等问题。经过分析发现，GPT5.5 本身已经具备较强的上下文检索能力和自发的逻辑深度检测能力，此时如果继续使用过于强硬、过于细致的规则，反而会增加模型负担，导致审查链路整体偏离核心问题。
问题背景
1. GLM5.0 阶段需要依赖强规则提升检测深度
AICR 刚开始使用 GLM5.0 作为检测模型。当时从逻辑能力、检测能力和场内部署资源来看，GLM5.0 是较为合适的选择。但由于模型自身缺陷检出能力有限，检出能力只有约 5%，因此需要依赖更细、更强的规则来增强检测效果。
2. 早期规则更强调“彻查到底”和“逐行检验”
为了提升检测深度与广度，早期 AICR 的规则设计较为细致且强硬，会强制要求 AI 对修改调用链进行彻查，对代码进行逐行检验，尽可能覆盖更多潜在风险。
3. GPT5.5 阶段检测能力提升，但耗时和噪音也同步上升
后期更换为 GPT5.5 后，缺陷检测能力提升至约 25%。但与此同时，检测时间变得非常长，检出的内容也变得非常庞大，产生了大量无效上下文。
4. 强规则反而放大了高阶模型的推理负担
经过分析发现，GPT5.5 已经具备较强的上下文检索能力和自发的逻辑深度检测能力。在这种情况下，继续使用强制性的深度规则，反而会导致模型过度推理、上下文过度扩展，使检测时间暴增。
5. 无效上下文会影响后续审查管线稳定性
大量无效上下文不仅增加了检测耗时，也会导致审核 Agent 出现注意力偏移，使后续审查管线进行很多脱离主题的检测，影响最终结果质量。
解决方案&心得
1. 将强制性规则软化，降低模型负担
后续的优化方向是对检测规则进行软化，将部分强制性的规则调整为更主观、更引导式的规则，减少对模型的硬性约束。
2. 发挥高阶模型自身的上下文检索能力
对于 GPT5.5 这类高阶模型，不再强制要求其对所有调用链和代码细节进行机械式彻查，而是让模型基于自身理解能力，主动判断哪些上下文更有价值、哪些链路更值得深入分析。
3. 提升上下文质量，而不是单纯扩大上下文范围
规则软化后，模型能够产出关联性更强、价值更高的上下文，避免无效信息堆积。这样不仅大幅降低了时间成本，检测质量反而有所提升。
心得：越高阶的模型，规则可以越轻。
对于能力较弱的模型，细规则和强约束可以帮助其补足检测深度；但对于 GPT5.5 这类高阶模型，过强的规则反而会限制模型自身能力，增加推理负担，并带来更多无效输出。
因此，AICR 的规则设计需要根据模型能力动态调整：模型能力越强，越应该减少机械式约束，给大模型更多自主判断和发挥空间。这样才能在降低时间成本的同时，获得更高质量、更聚焦、更有价值的检测结果。
4.2 大模型的预设立场对检测主观偏移问题
大模型的主观思维不是局限，而是一种可以被设计和利用的能力。
利用模型主观性，发挥模型长处
在开发审查 Agent 和核实 Agent 的过程中，我们发现大语言模型存在一定的角色锚定偏差：当模型被赋予某种明确角色后，容易将该角色对应的任务目标放大，并把完成该目标视为一种隐含奖励。
审查 Agent：倾向于“为了发现问题而发现问题”：当模型被赋予“缺陷审查者”的身份时，它会倾向于尽可能发现问题，并将“找到缺陷”视为隐含目标。
这会导致模型出现自我脑补、过度推理和猜测缺陷的情况，甚至会从各种极端场景出发，将正常代码解释为异常风险。
核实 Agent：倾向于“为了核实问题而删除问题”：后续新增核实 Agent 后，也出现了类似问题。
当模型被赋予“谨慎核实者”的身份时，它又会倾向于将缺陷解释为正常逻辑，并将“核实掉问题”视为隐含目标，导致部分真实缺陷被误删。
核心问题：单一角色容易放大单一目标：无论是审查 Agent 还是核实 Agent，只要角色目标过于单一，模型就容易围绕该目标进行过度发挥。
审查 Agent 容易放大风险，带来误报；核实 Agent 容易淡化风险，带来漏报。因此，单一 Agent 很难同时兼顾缺陷发现能力和结果可信度。
经过实践，我们认为，大模型的主观判断能力既是风险，也是能力来源。关键不是完全压制模型的主观性，而是通过多 Agent 协作机制，对不同角色的判断进行交叉验证。
因此，AICR 在审查链路中新增了多个环节：
1. 并行审查 Agent
使用 3 个不同审查方向的 Agent，从不同角度对代码缺陷进行审查，尽可能扩大问题发现范围。
2. 聚合整理 Agent
对多个审查 Agent 输出的结果进行聚合、去重和整理，形成更完整、更清晰的问题集合。
3. 核实 Agent
对审查结果进行反向核实，判断问题是否真实存在，过滤明显误报和依据不足的问题。
4. 复核 Agent
当核实 Agent 导致缺陷减少时，复核 Agent 会对被判定为误报的问题进行二次复核，避免真实缺陷被错误删除。
AICR 的核心策略不是让单个模型一次性给出绝对正确的判断，而是通过多智能体协同审查，让模型之间互相补位、互相制衡。
审查 Agent 负责尽可能发现缺陷，核实 Agent 负责控制误报，复核 Agent 负责防止真实缺陷被误删。通过这种多角色协作方式，既能让缺陷尽可能“无所遁藏”，也能让误报尽可能减少。
4.3 常见误报收集与纠错机制
4.3.1 常见误报与对应策略
由于大语言模型的底层生成逻辑决定了其天然存在一定的幻觉与模型臆测风险，即使 AICR 已经引入多轮 Agent 核实、复核与过滤策略，误报也仍然难以完全避免。
-
大模型主观臆测错误原因： 模型在证据不足时容易主动补全上下文，生成似是而非的缺陷结论。治理： 接受误报客观存在，持续引入更快、更稳定、更高质量的模型，降低主观臆测比例。
-
注意力不集中导致漏读代码原因： 长上下文、多文件、多调用链场景下，模型容易遗漏关键代码，基于不完整信息做出判断。治理： 优化上下文组织方式，降低模型阅读负担；结合核实 Agent、复核机制与更强模型，减少漏读导致的误判。
-
对已有框架或私有写法不熟悉原因： 团队框架、私有封装、历史写法或特殊工程约定不完全符合通用范式，模型缺少相关背景认知。治理： 持续维护代码仓库对应的知识本体系，补充框架机制、私有写法和工程约定，增强模型审查前的项目认知。
-
对多代码库混合开发约定范式缺失原因： 单仓视角无法理解跨仓约定、构建注入、运行时兜底或业务侧保障，导致将实际安全的代码误判为缺陷。治理： 建立纠错本机制，沉淀“代码表面看似错误、但实际业务安全”的固定模式，并在后续检测中自动纠错，减少重复误报噪音。
4.3.2 常态化纠错机制
建立误报收集机制： AICR 的误报治理不是一次性完成的能力，而是一个持续迭代的过程。我们通过用户反馈入口收集真实使用中的误报，通过每周两次检测与复盘识别误报模式，再通过模型优化、知识本补充和纠错本沉淀，不断修正模型认知。
周期复盘：对收集到的误报问题和建议忽略 case，AICR 团队会定期进行二次分析与归类，识别高频误报、典型误报和规则缺口，并在团队周会上讨论是否需要统一处理、规则修正或知识补充。
沉淀持续纠错知识： 对于反复出现的误报模式，AICR 会通过知识本补充、纠错本沉淀和模型策略优化持续修正模型判断，减少同类误报重复出现。
控制噪音提升可信度： 我们对误报的态度不是简单追求“完全消除”，而是通过反馈收集、周期复盘、经验沉淀和规则纠错，持续降低误报率。最终目标是在保持缺陷发现能力的同时，减少无效噪音，让提交者和 Reviewer 看到的问题更加准确、可信、必要且具备处理价值。
4.4 大模型的等级与检测能力的影响
由于代码库密级限制，AICR 早期主要使用 GLM5 作为检测模型，但实际缺陷检出率仅约 5%，整体缺陷发现能力相对有限。
后续我们调整为根据代码库密级动态选择检测大模型，在合规前提下引入不同模型进行对比验证。过程中，我们先后尝试了 MiniMax M3、Kimi 2.6、DeepSeek V4 Pro、GPT5.5 等多款模型。
经过对比发现，GPT5.5 在综合能力上表现更均衡：既具备较强的上下文理解能力、代码依赖分析能力和缺陷推理能力，也能在检测质量、稳定性和误报控制之间取得更好的平衡。因此，在适用场景下，GPT5.5 更适合作为 AICR 的主力检测模型。
为验证不同模型在 AICR 场景下的检测效果，我们选取网盘主端 FE 团队一周内的 552 个 CR 作为对照样本，分别使用 GLM5 和 GPT5.5 进行检测。
实验结果显示，GPT5.5 检出 121 条问题，检出率为 21.8%；GLM5 检出 38 条问题，检出率为 6.9%。
从结果看，GPT5.5 的缺陷检出数量约为 GLM5 的 3.2 倍，检出率提升约 14.9 个百分点。这说明在网盘主端 FE 的真实 CR 场景中，GPT5.5 在上下文理解、代码依赖分析和缺陷识别能力上均明显优于 GLM5，更适合作为 AICR 的主力检测模型。
GPT5.5 全面优于GLM5
05 代码准入的下一步探索
5.1 探索SPEC模式下的检索知识的AICR
随着 Speckit / OpenSpec 等 Spec 模式逐渐流行，越来越多代码提交会同时携带对应的 step、task、design 等过程文档。我们曾尝试在采用 Spec 模式开发的代码仓库中，基于提交代码关联对应的 Spec 过程文档，并将这些文档作为知识输入，用于增强 CI/CD 流水线中的 AICR 检测。
经过半个月灰度验证后发现，Spec 文档并不适合作为后置 CI/CD 检测的主要知识来源。其核心问题在于：Spec 文档与代码之间并不总是强一致，文档知识在部分场景下反而会干扰模型判断，最终带来的检测收益也相对有限。
文档与代码不同步： Spec 文档和实际代码并不总是同步更新。有时文档缺失但代码已经实现，有时文档较新但代码还没有推进到对应阶段。此时 AI 很难准确判断当前代码是“遗漏实现”，还是“尚未开发到该阶段”，容易产生误判。
多仓知识存在冲突： 在多代码库并行开发场景中，不同仓库可能各自维护 Spec 文档，文档之间可能存在阶段差异、口径差异甚至内容冲突。对于 AI 来说，这类不一致知识不会带来正向增强，反而可能成为负向干扰。
后置检测收益偏低： Spec 模式本身已经在开发阶段对需求拆解、任务执行和实现路径进行了约束。知识越完备，AI 在开发过程中越不容易遗漏需求；同时，Spec 模式也可以继承一套执行后的 CR 检查逻辑。因此，当代码已经进入后置 CI/CD 阶段时，再基于 Spec 文档做检测，新增收益并不明显。
因此，我们认为在 Spec 模式下，更合理的做法不是把 Spec 文档作为 CI/CD 后置检测的主要知识来源，而是将团队沉淀的脚本检测规则、审查规则和代码准入标准，直接前置赋能到 Spec 执行过程中。
也就是说，将 AICR 的部分检测规则沉淀为 团队标准 SOP，在 Spec 阶段指导任务拆解、代码实现和自检执行。相比后置 CI/CD 检测，这种方式更贴合 Spec 模式的工作流，也能更早暴露问题，减少后置检测阶段的误判和低收益检查。
最终结论是：在常规 CR 场景中，CI/CD 流水线更适合作为团队代码准入机制；但在 Spec 模式开发中，将规则前置到 Spec SOP 内，比在后置 CI/CD 阶段再基于文档检测更合适。
5.2 开发全流程下各个阶段的CR建设展望
AICR代码准入建设不应该只发生在提交后的单一检测阶段，而应该贯穿需求拆解、代码编写、本地提交、分支合入、CR 审查、CI/CD 准入和后续质量复盘的完整链路。不同阶段承担不同职责，形成一套前置预防、过程纠偏、后置准入、持续治理的代码质量体系。
后续建设展望
1. Spec / 需求阶段：前置需求特殊规则在 Spec 或需求拆解阶段，结合实际开发内容，提前凝练本次需求涉及的特殊规则、架构约束、历史问题和重点风险场景，并沉淀到开发 SOP 中，减少问题在 CR 阶段集中暴露。
2. 开发中阶段：开发 Agent 集成审查 Skills让 Ducc、Codex、Comate 等开发 Agent 集成审查 Skills，在编码过程中完成局部解释、调用链分析、边界提醒和风险提示，帮助开发者及时纠偏。
建设进度：100%
3. Pre-commit 阶段：轻量低噪音自检建设简洁的提交前检查机制，聚焦代码质量、代码复用和明显风险；对不确定问题通过问答澄清，避免输出大量低质量结论。
建设进度：20%
4. CI/CD 流水线 AICR：CR 级正式准入依托 iPipe、iCode、如流等场内系统，实现统一执行环境、统一模型策略、统一规则更新、统一结果回写和统一数据沉淀，承担团队级 CR 准入职责。
建设进度：95%
5. 静态代码审查：确定性质量兜底编译、单测、类型检查、lint、format、依赖安全、包体积、循环依赖、接口兼容性、权限扫描和敏感信息扫描等确定性问题，仍由稳定工具兜底。
建设进度：厂内建设完善
6. 合入后质量复盘：全库或分支级整体 Review定期运行 Ducc 对整个代码库或重点开发分支做整体 Review，发现单次 CR diff 难以暴露的跨文件调用链、架构一致性、状态流转和复杂业务链路问题。
建设进度：40%
05 总结
在 AI 走入开发流程的今天，无论是 Vibe Coding、Spec 模式，还是 Harness 实践，核心目标都是让 AI 生成更符合人需求、更贴近团队标准的高质量代码。
随着 AI Coding 能力提升，传统 Reviewer 的审查边界正在被重新定义。过去“AI 写完，人再逐行细看”的方式已经难以支撑真实工程效率，用 AI 建设全流程代码准入能力，正在成为团队必须思考的问题。
AICR 不应只停留在 CR 后置检测，而应覆盖开发全流程：在 Spec 阶段前置规则，在开发中即时纠偏，在 Pre-commit 阶段轻量自检，在 CI/CD 阶段完成正式准入，在合入后持续复盘优化。
这套体系没有标准答案，就像开发框架一样，必须结合团队业务、代码复杂度和研发流程持续演进。适合团队的，才是最好的。
