前端智能审查先给调用链设一条止损线把大模型接进 PR 审查最容易被忽略的不是提示词而是调用边界。有人先把完整 diff 发给模型等账单、429 和重复评论一起出现才发现这件事没有“默认安全”的运行方式。模型审查更适合做补充它可以帮忙发现可疑分支、重复实现和解释不清的改动却不该承担构建是否通过、成本是否可控这些确定性职责。前端或 Node.js 服务要把这些职责留在代码里哪些文件不送审、一次送多少、失败后怎么退、模型给出的结果能否进入评论区都应该有明确规则。先找出钱和时间花在了哪里排查时不要只盯模型返回的文字。应把一次审查拆成几段记录收到的变更文件数、过滤后的文件数、每个片段大小、请求并发数、重试次数、返回结果数以及实际计费信息。这样才能分清是输入过大还是错误重试把同一批内容发了多次。常见的浪费很朴素。锁文件、压缩产物、代码生成文件和格式化造成的大面积换行通常没有必要交给模型判断。另一个问题是把几十个文件拼成一个请求。上下文越大不一定越准反而会让模型遗漏局部细节也让一次失败的代价变大。重复评论往往不是模型“太啰嗦”而是调用侧没有幂等。重试后的结果与第一次结果同时写入或者两个 worker 对同一提交工作最后都会在同一行留下相似意见。先确认任务 ID、提交 SHA 和文件版本是否被正确去重再讨论如何改提示词。过滤规则要能解释也要能回退第一层过滤不需要追求聪明先把明显无效的输入挡住即可。可以维护一份目录和文件模式的忽略清单例如依赖锁定文件、发布目录、压缩文件、声明生成文件。清单要跟着仓库习惯维护不能把所有看起来“改动很大”的文件一概跳过。对剩下的 diff可以按函数、组件或明确的变更块切分。AST 在这里有用但它不是必须条件。它的价值是帮助找到函数声明、条件分支、异步调用和组件逻辑而不是把整棵语法树都交给模型。若解析失败最稳妥的做法是降级为小块文本切分并把该文件标记为需要人工关注不要因为解析失败就把原始大文件全量重发。还应给单个文件设置上限。超过上限时CI 可以给出“变更过大建议人工审查”的提示或仅运行已有静态检查。这里的上限是团队策略不是固定常数仓库中既有大型页面也有自动生成文件规则应允许按目录覆盖。预算、限流和重试要放在同一个控制面很多实现把 429 当作一次普通异常给每个 worker 各自做指数退避。这会造成一个反直觉的结果服务越忙重试请求越集中。正确的控制对象不是单次 fetch而是整个审查队列。调用前先估算本次片段的成本进入队列时占用预算请求完成后再用接口返回的实际用量结算。预算接近阈值时系统要有可预期的行为例如停止低优先级 PR 的模型审查、只保留高风险目录或直接退回静态规则。不要等到供应商拒绝请求后才开始“节流”。并发限制也应是共享的。单进程里的信号量只能约束当前 runner若 CI 同时跑多个任务限流状态应放在共享组件中或由任务调度器统一控制。限流触发时需要把原因写清楚是每日预算不足、瞬时并发已满还是上游服务不可用。这样开发者看到的是明确的降级说明不是一串难懂的网络错误。重试只适用于短暂失败并且必须有次数上限。请求超时、网络抖动或明确的服务端限流可以重试输入不合法、输出无法解析、权限错误不应原样重发。每次重试都要带同一任务标识写入端根据这个标识保证幂等。模型输出先过质量门再出现在 PR 里不要直接把模型返回的 JSON 当成评论。先校验字段是否完整行号是否在当前 diff 范围内严重级别是否属于允许的枚举建议文字是否为空。模型可能返回解释性内容、错误的行号或者针对未改动代码提出意见这些都不该自动写回平台。对同一文件和同一行可按规则 ID、文本相似度或稳定的哈希做去重。这里无需追求复杂的语义算法先保证同一个任务不会重复写入已经能解决大部分噪声。质量门拒绝的结果也不要悄悄丢掉应记录拒绝原因方便调整结构化协议。我更倾向于把模型意见默认标为普通建议而不是阻断构建。只有在团队验证过某类规则的准确性并且能由确定性条件复核时才考虑把它升为必需检查。安全漏洞、类型错误、依赖许可之类明确问题仍然应该由专门扫描器和人工流程兜底。一条可落地的处理顺序一次 PR 审查可以按下面的顺序走接收事件后先用提交 SHA 建立任务过滤无需审查的文件将保留内容切成受控大小的片段在共享队列中申请并发和预算带超时发起调用校验和去重输出最后才写入 PR。任一步失败都要给任务一个最终状态避免下一次事件把旧任务重新跑一遍。上线前可以准备几类样本只有锁文件的提交、单个小函数改动、多文件重构、模型返回非 JSON、上游持续限流。观察的也不只是命中率还包括每类提交是否按预期降级、是否出现重复评论、失败任务能否被定位。没有这些记录后面很难判断一条新规则究竟节省了调用还是把有价值的审查一起过滤掉了。智能审查的价值在于补上人工容易漏看的角落。把预算、筛选、超时、幂等和结果校验做扎实它才是一项可长期运行的工程能力否则一次看似方便的模型调用很快就会变成 CI 里最难解释的噪声来源。
前端智能审查先给调用链设一条止损线把大模型接进 PR 审查最容易被忽略的不是提示词而是调用边界。有人先把完整 diff 发给模型等账单、429 和重复评论一起出现才发现这件事没有“默认安全”的运行方式。模型审查更适合做补充它可以帮忙发现可疑分支、重复实现和解释不清的改动却不该承担构建是否通过、成本是否可控这些确定性职责。前端或 Node.js 服务要把这些职责留在代码里哪些文件不送审、一次送多少、失败后怎么退、模型给出的结果能否进入评论区都应该有明确规则。先找出钱和时间花在了哪里排查时不要只盯模型返回的文字。应把一次审查拆成几段记录收到的变更文件数、过滤后的文件数、每个片段大小、请求并发数、重试次数、返回结果数以及实际计费信息。这样才能分清是输入过大还是错误重试把同一批内容发了多次。常见的浪费很朴素。锁文件、压缩产物、代码生成文件和格式化造成的大面积换行通常没有必要交给模型判断。另一个问题是把几十个文件拼成一个请求。上下文越大不一定越准反而会让模型遗漏局部细节也让一次失败的代价变大。重复评论往往不是模型“太啰嗦”而是调用侧没有幂等。重试后的结果与第一次结果同时写入或者两个 worker 对同一提交工作最后都会在同一行留下相似意见。先确认任务 ID、提交 SHA 和文件版本是否被正确去重再讨论如何改提示词。过滤规则要能解释也要能回退第一层过滤不需要追求聪明先把明显无效的输入挡住即可。可以维护一份目录和文件模式的忽略清单例如依赖锁定文件、发布目录、压缩文件、声明生成文件。清单要跟着仓库习惯维护不能把所有看起来“改动很大”的文件一概跳过。对剩下的 diff可以按函数、组件或明确的变更块切分。AST 在这里有用但它不是必须条件。它的价值是帮助找到函数声明、条件分支、异步调用和组件逻辑而不是把整棵语法树都交给模型。若解析失败最稳妥的做法是降级为小块文本切分并把该文件标记为需要人工关注不要因为解析失败就把原始大文件全量重发。还应给单个文件设置上限。超过上限时CI 可以给出“变更过大建议人工审查”的提示或仅运行已有静态检查。这里的上限是团队策略不是固定常数仓库中既有大型页面也有自动生成文件规则应允许按目录覆盖。预算、限流和重试要放在同一个控制面很多实现把 429 当作一次普通异常给每个 worker 各自做指数退避。这会造成一个反直觉的结果服务越忙重试请求越集中。正确的控制对象不是单次 fetch而是整个审查队列。调用前先估算本次片段的成本进入队列时占用预算请求完成后再用接口返回的实际用量结算。预算接近阈值时系统要有可预期的行为例如停止低优先级 PR 的模型审查、只保留高风险目录或直接退回静态规则。不要等到供应商拒绝请求后才开始“节流”。并发限制也应是共享的。单进程里的信号量只能约束当前 runner若 CI 同时跑多个任务限流状态应放在共享组件中或由任务调度器统一控制。限流触发时需要把原因写清楚是每日预算不足、瞬时并发已满还是上游服务不可用。这样开发者看到的是明确的降级说明不是一串难懂的网络错误。重试只适用于短暂失败并且必须有次数上限。请求超时、网络抖动或明确的服务端限流可以重试输入不合法、输出无法解析、权限错误不应原样重发。每次重试都要带同一任务标识写入端根据这个标识保证幂等。模型输出先过质量门再出现在 PR 里不要直接把模型返回的 JSON 当成评论。先校验字段是否完整行号是否在当前 diff 范围内严重级别是否属于允许的枚举建议文字是否为空。模型可能返回解释性内容、错误的行号或者针对未改动代码提出意见这些都不该自动写回平台。对同一文件和同一行可按规则 ID、文本相似度或稳定的哈希做去重。这里无需追求复杂的语义算法先保证同一个任务不会重复写入已经能解决大部分噪声。质量门拒绝的结果也不要悄悄丢掉应记录拒绝原因方便调整结构化协议。我更倾向于把模型意见默认标为普通建议而不是阻断构建。只有在团队验证过某类规则的准确性并且能由确定性条件复核时才考虑把它升为必需检查。安全漏洞、类型错误、依赖许可之类明确问题仍然应该由专门扫描器和人工流程兜底。一条可落地的处理顺序一次 PR 审查可以按下面的顺序走接收事件后先用提交 SHA 建立任务过滤无需审查的文件将保留内容切成受控大小的片段在共享队列中申请并发和预算带超时发起调用校验和去重输出最后才写入 PR。任一步失败都要给任务一个最终状态避免下一次事件把旧任务重新跑一遍。上线前可以准备几类样本只有锁文件的提交、单个小函数改动、多文件重构、模型返回非 JSON、上游持续限流。观察的也不只是命中率还包括每类提交是否按预期降级、是否出现重复评论、失败任务能否被定位。没有这些记录后面很难判断一条新规则究竟节省了调用还是把有价值的审查一起过滤掉了。智能审查的价值在于补上人工容易漏看的角落。把预算、筛选、超时、幂等和结果校验做扎实它才是一项可长期运行的工程能力否则一次看似方便的模型调用很快就会变成 CI 里最难解释的噪声来源。
