禁止的 import，
必须在 MR 里被指出。
团队规范很明确：不能使用阿里云 StringUtils。真正的问题是，它能否稳定、自动、逐行地落到开发现场？
规则卡片固化规范，规则检测器用正则 / 代码模式匹配检测，MR（合并请求）创建后自动评论违规 import 与替代建议。
循环体内禁止调用 IO
检测器沿 代码结构追踪“循环体 → IO 调用”的关系，在规则层直接确认风险，保证同样的代码得到同样的结论。
大部分团队的代码审查停留在文档纸面上，成员之间口口相传。
疲劳、无时间、主观偏见、认知局限，让审查质量随人和时段波动。
只看代码表面，难以识别业务背景、状态边界和服务职责。
评论停在当前 MR（合并请求），误报、漏报和修复经验没有回到下一次审查。
从 webhook 到评论区，
一条直线。
它能快速生成意见，但判断路径通常是自由的：规则、业务知识与证据没有被拆开管理。
GitLab MR（合并请求）、Webhook、状态与评论。
规则检测器、项目模型与智能体。
规则、知识库、Skill 与版本证据。
仪表盘、模型配置与审查详情。
线上意见回流为质量资产。
结论能回到代码、知识与过程。
只运行规则卡片检测器，无需配置 LLM。适合禁用 API、引用方式、结构性约束，稳定、快速、可门禁。
无需 LLM / 正则 / 代码模式 / 结构分析先做规则检测；已有知识库作为上下文，又希望以较低延迟得到评审结果时使用。
规则检测 + 知识库 + LLM先做规则检测；有业务知识库、业务语义复杂，并需要配合审查 Skill 推理时使用。
规则检测 + 知识库 + Skill + 智能体把一句“应该避免”，
编译成一张规则卡。
规则卡片记录规则意图、适用范围、正反例、严重级别、修复建议与确定性规则检测器。
规则描述 → 正反例 → 规则检测器 → 行级证据 → 版本迭代
规则层不接入任何模型。
能用正则表达式解决的，不用猜；能用代码模式匹配解决的，不交给生成式判断；需要关系分析时，用代码结构与数据流分析。
精确捕捉禁用类、包名与固定模式。
匹配调用、条件、返回值等代码形状。
识别循环体与 IO 调用关系。
直接产出可定位、可复核的代码证据。
规则与业务知识，
分开管理。
规则卡片约束代码写法；知识库沉淀业务边界、背景和正式事实，帮助审查判断 MR（合并请求）的修改方向有没有走偏。当前主要以 Git 仓库中的 Markdown 资产接入，审查使用知识快照，保证依据固定、可追溯、可复现。
Skill 不是提示词装饰，
而是审查方法。
它规定上下文读取顺序、关注的风险维度、证据引用方式、结论格式与停止条件，让 Codex / Qoder Agent 的深度审查可复用。
从规则加载、命中结果、知识引用，到完整审查详情，每个结论都有对应的过程记录。
知道哪一版规则卡片触发了结论。
知道哪一行、哪一种规则检测器发现了问题。
业务判断能回到正式知识与快照。
审查详情保留模式、模型、Skill 与结果。
