用语法树核对复杂度结论但别把它当证明AI 生成题解时复杂度说明很容易跟代码脱节。一个双层循环未必是 O(n²)递归也不必然指数级循环边界、数据分布和摊还成本都会改变结论。因此AST 适合提取“需要复核的结构”不适合自动宣布准确的 Big-O。例如扫描 Go 代码中的循环和递归调用可以生成审核提示报告声称 O(n)但代码含有嵌套循环时应要求作者解释内层循环的总次数。这个提示不是判错因为双指针、单调队列等写法可能仍为线性复杂度。func parseGo(src string) error { fset : token.NewFileSet() _, err : parser.ParseFile(fset, solution.go, src, parser.ParseComments) if err ! nil { return fmt.Errorf(Go 语法错误: %w, err) } return nil }一个可靠的验证流程分三层先解析和编译再运行样例、边界用例与随机对拍最后由规则或人工审查复杂度论证。对不同语言使用各自的解析器不要拿 Go AST 去判断 C 或 Python 的结构。发布复杂度结论时写清输入规模的定义和假设例如哈希操作取期望 O(1)、递归深度是否受限。无法从代码静态证明的部分应标注为待验证并用基准测试观察增长趋势。基准测试只能提供证据不能替代数学证明。
