用智能工具写代码评审时怎样发现隐性风险AI 能快速补全样板代码却不知道调用链的取消语义、资源上限和业务约束。代码通过题目样例或单元测试只能说明覆盖到的路径正确不能证明服务在异常输入和并发下可靠。先看四类高风险点检查项常见遗漏应如何验证goroutine发送方等待无法读取的 channel让接收方提前退出确认发送方能随ctx.Done()返回输入边界下标、长度和枚举值没有校验用空值、超长值和非法枚举写测试共享状态map、切片或循环变量被并发读写运行go test -race并检查同步策略失败处理错误被丢弃或 panic 直接穿透覆盖依赖超时、序列化失败和取消请求“每个 goroutine 都加 recover”不是通用规则。更重要的是明确启动者、退出条件、结果去向和取消传播只有隔离边界的长期任务才可能需要恢复 panic并记录足够的上下文。CI 能做什么不能做什么静态检查和测试适合拦截确定问题审查人负责判断业务语义。可以把以下命令放进 CIgo vet ./... go test -race ./... go test -count1 ./...LLM 审查可以帮助列问题但不能用一个“评分阈值”替代合并决策。它的输出应作为评论或待办并要求给出对应代码位置和可复现的反例。一个更安全的发送模式func sendResult(ctx context.Context, ch chan- Result, result Result) error { select { case ch - result: return nil case -ctx.Done(): return ctx.Err() } }评审此类代码时还应追问谁关闭 channel如果消费者停止读取会怎样结果是否允许丢弃这些答案比“代码是不是 AI 生成的”更有价值。