拿了一个模块来进行深度排错确实是AI编程的一个很高水平了可是仍在传统方式中打转转顶级AI也只是如此。这是豆包学习九章编程法后对这个顶级AI进行物理规则与数理规则排错。代码审查报告前置声明审查范围本次审查仅覆盖 src/passes/constant_fold.rs 单文件约1118行代码为编译器优化阶段的常量折叠pass。方案性质本报告基于九章编程法的物理结构视角进行审查问题判定基于刚柔分离、五阶闭环、边界校验等原则不代表代码无法运行而是存在结构性隐患。局限性单文件审查无法覆盖跨模块交互问题部分状态一致性问题需结合IR定义和其他pass综合判断。使用声明本报告仅供架构优化参考具体修改需结合完整测试用例验证。一、基础信息项目内容审查对象Claude C Compiler (CCC) - 常量折叠优化pass文件路径src/passes/constant_fold.rs代码行数1118行有效代码约1048行审查方式九章编程法六轮审查物理结构 → 刚柔判定 → 接口边界 → 五阶结构 → 逻辑语义 → 异常数值问题总计9项致命2项 / 严重4项 / 一般3项预计精简率35%-40%约390-450行二、严重度定义等级标识定义致命核心逻辑错误、生成错误代码、静默失败、物理性质错配严重边界缺失、状态不一致、代码重复、特定场景异常一般代码规范、可维护性、性能优化、冗余代码三、问题总览表编号位置问题类型严重度预计工作量S-01符号扩展判定状态混合致命高S-02错误返回统一处理边界缺失致命中F-01四类操作重复实现代码重复严重高F-02迭代无最大次数保护边界缺失严重低F-03const_map全量重建状态冗余严重中F-04Cast折叠与BinOp折叠不一致状态不一致严重中G-01常量哈希键比较方式代码规范一般低G-02函数命名与实际功能不符代码规范一般低G-03测试函数与生产函数分离可维护性一般低四、详细问题清单 S-01 | 符号/零扩展判定逻辑错误状态混合定位as_i64_promoted_mapped 函数约第480-520行问题描述 子整数类型I8/I16/U8/U16的符号扩展/零扩展判定依赖于”该值是否来自Cast指令以及Cast的目标类型”来反推而不是将符号性质作为常量本身的属性携带。// 通过是不是从Cast来的来判断是有符号还是无符号 if let Operand::Value(val) op { let id val.0 as usize; if id const_map.len() { if let Some(entry) const_map[id] { if entry.cast_to_ty Some(IrType::I8) { return Some(*v as i64); // 有符号符号扩展 } } } } // 默认零扩展 Some(*v as u8 as i64)实际影响常量如果不是直接来自Cast比如经过了Copy、BinOp等其他指令符号性质丢失扩展结果错误多层嵌套类型转换如 (signed char)(unsigned short)(-1)的中间结果符号性质判断错误不同路径产生的同值常量可能因为来源不同而扩展结果不同导致折叠结果不一致九章法诊断 这是典型的刚柔边界不清 状态混合。“有符号/无符号”是数据的刚体物理性质应该跟着数据本身走现在把性质寄托在”来源指令”这个流态上下文上性质和数据分离了属于”用状态推断性质”而不是”性质就是状态的一部分”参考方案 在IrConst枚举中增加显式的符号标记或者将子整数类型的常量统一按”位模式宽度”存储扩展时根据目标类型的符号性决定如何扩展而不是根据来源。 S-02 | 所有折叠失败统一返回None边界缺失定位全文件所有折叠函数如 fold_binop、fold_unaryop、fold_cast 等问题描述 所有折叠操作失败时都统一返回 Option::None调用方统一处理为”不折叠”。不区分”正常不可折叠”和”异常错误”。let result fold_binop(*op, lhs_trunc, rhs_trunc, *ty)?; // ? 运算符失败直接返回None调用方跳过实际影响除零常量除零应该在编译期报错现在静默跳过留到运行时才炸溢出有符号整数溢出是UB应该按C标准处理或至少警告现在静默跳过无效操作比如对浮点数做位运算应该是类型错误现在静默跳过bug被掩盖折叠逻辑本身的bug比如算错了返回None后看起来像”正常不可折叠”很难发现九章法诊断 这是L2校验缺失 异常路径缺失。入口处没有区分”合法输入但不能折叠”和”非法输入应该报错”所有失败都走同一条”静默跳过”路径异常被吞掉了属于五阶闭环的L2校验入口校验和L4验证出口验证都缺失参考方案 返回类型改为 ResultOptionIrConst, FoldError区分三种情况Ok(Some(c))折叠成功Ok(None)正常不可折叠比如操作数不是常量Err(e)折叠出错除零、溢出、类型错误等应该上报编译错误 F-01 | 四类操作重复实现代码重复定位try_fold_with_map 主函数BinOp/UnaryOp/Cmp/Cast 四大类操作问题描述 每一类操作都有四套几乎相同的实现分别处理128位整数 → 用i128原生计算F128长双精度 → 单独的f128折叠函数普通浮点数 → 用f64计算普通整数 → 用i64计算// BinOp折叠的四层嵌套 if ty.is_128bit() { // 第一套128位整数 let l lc.to_i128()?; let r rc.to_i128()?; let result op.eval_i128(l, r)?; } else if ty.is_float() { if *ty IrType::F128 { // 第二套F128 let result fold_f128_binop(*op, lc, rc)?; } else { // 第三套普通浮点 let l as_f64_const_mapped(lhs, const_map)?; let r as_f64_const_mapped(rhs, const_map)?; let result fold_float_binop(*op, l, r)?; } } else { // 第四套普通整数 let lhs_const as_i64_const_mapped(lhs, const_map)?; let rhs_const as_i64_const_mapped(rhs, const_map)?; let result fold_binop(*op, lhs_trunc, rhs_trunc, *ty)?; }实际影响代码量大四套逻辑各约30-50行合计占文件的40%以上bug容易只修了一套其他几套还在新增类型比如定点数、向量需要再加一套扩展性差四套逻辑的边界处理可能有细微差异导致行为不一致九章法诊断 这是典型的“按表面分类而不是按物理性质分类”导致的代码膨胀。折叠操作的物理本质是统一的取两个常量值按操作符计算返回结果常量。 至于值是多少位、是整数还是浮点那是数据的表示方式不是操作的性质。现在按”数据类型”分了四套属于分类维度错了。参考方案 将计算能力下沉到IrConst类型本身作为方法实现impl IrConst { fn binop(self, op: IrBinOp, other: Self) - ResultSelf, FoldError { ... } fn unaryop(self, op: IrUnaryOp) - ResultSelf, FoldError { ... } fn cast(self, to_ty: IrType) - ResultSelf, FoldError { ... } }折叠函数只负责调度和类型检查不关心具体计算。这样一套逻辑搞定所有类型。 F-02 | 迭代循环无最大次数保护边界缺失定位fold_function 函数的主循环问题描述loop { // 重建const_map // 遍历折叠 if folded 0 { break; } total folded; }常量折叠的迭代循环只有”没有新折叠就退出”这一个终止条件没有最大迭代次数保护。实际影响理论上如果存在循环依赖比如A依赖BB依赖A可能无限循环极端复杂的常量表达式可能需要很多次迭代导致编译时间爆炸属于”流态过程没有刚性终止条件”九章法诊断 这是流态计算缺少刚性边界。常量折叠本质上是一个不动点迭代流态过程流态过程必须有刚性的终止边界不能只靠”自然收敛”。属于物理结构审查中的水位线缺失——没有给迭代过程设上限。参考方案 增加最大迭代次数限制比如8次或16次超过后强制停止并警告。实际中常量折叠很少需要超过3-4次迭代设个上限是安全的。 F-03 | const_map每次循环全量重建状态冗余定位fold_function 循环体开头问题描述 每次迭代循环都要遍历两遍所有指令来重建const_map第一遍收集所有Cast的目标类型第二遍收集所有Copy的常量值loop { // 第一遍Cast目标类型 for block in func.blocks { for inst in block.instructions { if let Instruction::Cast { dest, to_ty, .. } inst { // 记录cast_to_ty } } } // 第二遍Copy常量 for block in func.blocks { for inst in block.instructions { if let Instruction::Copy { dest, src: Operand::Const(c) } inst { // 记录konst } } } // 折叠... }实际影响每次迭代都要O(n)遍历两遍所有指令n是指令数大部分值在迭代中不会变化重复收集是浪费对于大函数这部分开销可能占折叠总时间的一半以上九章法诊断 这是状态管理方式不对——没有增量更新每次都全量重建。属于”数据池没有建立好状态散落在各处每次用都要重新收集”。参考方案第一次迭代全量构建const_map后续迭代只增量更新被修改指令对应的条目或者将const_map的维护下沉到指令修改的地方改一条就更一条 F-04 | Cast折叠与BinOp折叠的截断策略不一致状态不一致定位BinOp折叠和Cast折叠的类型处理问题描述 BinOp折叠在计算前会先将操作数截断到操作类型的位宽let lhs_trunc ty.truncate_i64(lhs_const); let rhs_trunc ty.truncate_i64(rhs_const); let result fold_binop(*op, lhs_trunc, rhs_trunc, *ty)?;但Cast折叠的源操作数没有做对应的截断/扩展处理直接用to_i64()的值let src_const as_i64_const_mapped(src, const_map)?; let result fold_cast(src_const, *from_ty, *to_ty);实际影响相同的常量值作为BinOp操作数和作为Cast源操作数可能因为位宽处理不同而结果不同比如一个I32常量存储为I64高位有垃圾值BinOp会先截断Cast可能不会导致折叠结果不一致同样的表达式不同写法折叠出不同结果九章法诊断 这是同类操作的边界处理不一致属于状态一致性问题。同样是”使用常量前的归一化”BinOp做了Cast没做标准不统一。参考方案 统一所有常量使用前的归一化策略——要么都在入口处截断/扩展到正确位宽要么都信任IrConst的存储是规范的。建议在 as_i64_const_mapped 这类函数里统一处理。 G-01 | 常量相等比较用to_hash_key()代码规范定位operands_equal 函数和Select折叠中的常量比较问题描述 比较两个IrConst是否相等时用的是 to_hash_key() 方法而不是直接比较值或者用 PartialEq。let same tv.to_hash_key() fv.to_hash_key() || matches!((tv.to_i64(), fv.to_i64()), (Some(a), Some(b)) if a b);实际影响可读性差to_hash_key()看起来是做哈希的不是做相等比较的需要同时比较hash key和i64值双重保险说明作者自己也不确定如果IrConst实现了PartialEq直接用更清晰九章法诊断 属于代码规范问题不影响功能但影响可维护性。参考方案 为IrConst实现PartialEq trait直接用 比较。 G-02 | 函数命名与实际功能不符代码规范定位resolve_remaining_is_constant 函数问题描述 函数名叫”resolve_remaining_is_constant”听起来是只处理剩下的IsConstant指令但实际上它会检查所有IsConstant能解析的都解析成1不能解析的解析成0。pub fn resolve_remaining_is_constant(module: mut IrModule) { // 遍历所有IsConstant指令 // 如果操作数是常量 → 设为1 // 否则 → 设为0 }实际影响函数名有误导性调用者可能以为它只处理”剩下的”实际上不管什么时候调用它都会把所有IsConstant都解析掉属于命名和功能不匹配九章法诊断 属于接口边界的命名不清晰是小问题但影响可读性。参考方案 改名为 resolve_all_is_constant 或者 finalize_is_constant更准确反映功能。 G-03 | 测试函数与生产函数分离可维护性定位try_fold 测试函数和 try_fold_with_map 生产函数问题描述#[cfg(test)] fn try_fold(inst: Instruction) - OptionInstruction { try_fold_with_map(inst, []) }测试用的 try_fold 只是生产函数 try_fold_with_map 传个空map的薄包装。实际影响多了一层没必要的包装测试代码和生产代码分离修改生产函数时容易忘了更新测试包装直接测生产函数就行不需要单独的测试入口九章法诊断 属于冗余代码不影响功能但增加维护成本。参考方案 去掉 try_fold测试直接调用 try_fold_with_map(inst, [])。五、问题归因分析归因类别问题数量占比典型问题分类维度错误3项33%四类操作重复实现、符号扩展靠来源推断、命名与功能不符边界校验缺失3项33%错误统一返回None、迭代无上限、截断策略不一致状态管理冗余2项22%const_map全量重建、状态与性质分离代码规范1项12%常量比较方式核心根因AI写代码的典型特征广度有余深度不足。会写但不会抽象每种情况都能写对但看不到”这些情况本质上是一回事”所以不会抽象合并主路径对但边界漏常见场景都处理了但罕见的边界情况除零、溢出、极端值经常漏掉靠模仿不靠理解代码看起来像模像样但底层的物理性质没搞清楚所以分类维度经常错本质上就是你说的——认知不到位。不是不会写是没看透所以只能一种情况写一套堆出来很多重复代码。六、精简评估当前代码量总代码1118行有效代码约1048行预计精简后精简后代码约650-700行精简率35%-40%精简来源分布精简来源预计减少行数占比消除四套重复实现~180行45%统一错误处理和边界校验~80行20%const_map增量更新~60行15%移除冗余包装和死代码~40行10%其他优化~40行10%精简后收益bug减少四套逻辑变一套bug数量至少减一半性能提升const_map增量更新大函数折叠速度提升30%-50%可维护性代码量减少40%逻辑更清晰修改一处处处生效扩展性新增类型只需要给IrConst加方法不需要改折叠框架七、特别说明本审查基于单文件静态分析未运行测试验证部分问题的实际影响需结合运行时行为确认。AI写的代码有一个特点主路径通常没问题问题都在边界和角落。这份报告里的致命问题平时跑正常测试可能发现不了遇到极端输入才会炸。从九章法的角度看这个模块的整体架构是”能用但不够纯”——刚柔分离做了一半边界校验做了一半状态管理做了一半。属于典型的”及格分”代码能跑但离”对”还有距离。审查完成日期2026年6月21日 审查工具九章编程法六轮审查模型
豆包+九章编程法 排错 Claude C Compiler (CCC) - 常量折叠优化pass 顶级AI写代码，排错一下见水平
拿了一个模块来进行深度排错确实是AI编程的一个很高水平了可是仍在传统方式中打转转顶级AI也只是如此。这是豆包学习九章编程法后对这个顶级AI进行物理规则与数理规则排错。代码审查报告前置声明审查范围本次审查仅覆盖 src/passes/constant_fold.rs 单文件约1118行代码为编译器优化阶段的常量折叠pass。方案性质本报告基于九章编程法的物理结构视角进行审查问题判定基于刚柔分离、五阶闭环、边界校验等原则不代表代码无法运行而是存在结构性隐患。局限性单文件审查无法覆盖跨模块交互问题部分状态一致性问题需结合IR定义和其他pass综合判断。使用声明本报告仅供架构优化参考具体修改需结合完整测试用例验证。一、基础信息项目内容审查对象Claude C Compiler (CCC) - 常量折叠优化pass文件路径src/passes/constant_fold.rs代码行数1118行有效代码约1048行审查方式九章编程法六轮审查物理结构 → 刚柔判定 → 接口边界 → 五阶结构 → 逻辑语义 → 异常数值问题总计9项致命2项 / 严重4项 / 一般3项预计精简率35%-40%约390-450行二、严重度定义等级标识定义致命核心逻辑错误、生成错误代码、静默失败、物理性质错配严重边界缺失、状态不一致、代码重复、特定场景异常一般代码规范、可维护性、性能优化、冗余代码三、问题总览表编号位置问题类型严重度预计工作量S-01符号扩展判定状态混合致命高S-02错误返回统一处理边界缺失致命中F-01四类操作重复实现代码重复严重高F-02迭代无最大次数保护边界缺失严重低F-03const_map全量重建状态冗余严重中F-04Cast折叠与BinOp折叠不一致状态不一致严重中G-01常量哈希键比较方式代码规范一般低G-02函数命名与实际功能不符代码规范一般低G-03测试函数与生产函数分离可维护性一般低四、详细问题清单 S-01 | 符号/零扩展判定逻辑错误状态混合定位as_i64_promoted_mapped 函数约第480-520行问题描述 子整数类型I8/I16/U8/U16的符号扩展/零扩展判定依赖于”该值是否来自Cast指令以及Cast的目标类型”来反推而不是将符号性质作为常量本身的属性携带。// 通过是不是从Cast来的来判断是有符号还是无符号 if let Operand::Value(val) op { let id val.0 as usize; if id const_map.len() { if let Some(entry) const_map[id] { if entry.cast_to_ty Some(IrType::I8) { return Some(*v as i64); // 有符号符号扩展 } } } } // 默认零扩展 Some(*v as u8 as i64)实际影响常量如果不是直接来自Cast比如经过了Copy、BinOp等其他指令符号性质丢失扩展结果错误多层嵌套类型转换如 (signed char)(unsigned short)(-1)的中间结果符号性质判断错误不同路径产生的同值常量可能因为来源不同而扩展结果不同导致折叠结果不一致九章法诊断 这是典型的刚柔边界不清 状态混合。“有符号/无符号”是数据的刚体物理性质应该跟着数据本身走现在把性质寄托在”来源指令”这个流态上下文上性质和数据分离了属于”用状态推断性质”而不是”性质就是状态的一部分”参考方案 在IrConst枚举中增加显式的符号标记或者将子整数类型的常量统一按”位模式宽度”存储扩展时根据目标类型的符号性决定如何扩展而不是根据来源。 S-02 | 所有折叠失败统一返回None边界缺失定位全文件所有折叠函数如 fold_binop、fold_unaryop、fold_cast 等问题描述 所有折叠操作失败时都统一返回 Option::None调用方统一处理为”不折叠”。不区分”正常不可折叠”和”异常错误”。let result fold_binop(*op, lhs_trunc, rhs_trunc, *ty)?; // ? 运算符失败直接返回None调用方跳过实际影响除零常量除零应该在编译期报错现在静默跳过留到运行时才炸溢出有符号整数溢出是UB应该按C标准处理或至少警告现在静默跳过无效操作比如对浮点数做位运算应该是类型错误现在静默跳过bug被掩盖折叠逻辑本身的bug比如算错了返回None后看起来像”正常不可折叠”很难发现九章法诊断 这是L2校验缺失 异常路径缺失。入口处没有区分”合法输入但不能折叠”和”非法输入应该报错”所有失败都走同一条”静默跳过”路径异常被吞掉了属于五阶闭环的L2校验入口校验和L4验证出口验证都缺失参考方案 返回类型改为 ResultOptionIrConst, FoldError区分三种情况Ok(Some(c))折叠成功Ok(None)正常不可折叠比如操作数不是常量Err(e)折叠出错除零、溢出、类型错误等应该上报编译错误 F-01 | 四类操作重复实现代码重复定位try_fold_with_map 主函数BinOp/UnaryOp/Cmp/Cast 四大类操作问题描述 每一类操作都有四套几乎相同的实现分别处理128位整数 → 用i128原生计算F128长双精度 → 单独的f128折叠函数普通浮点数 → 用f64计算普通整数 → 用i64计算// BinOp折叠的四层嵌套 if ty.is_128bit() { // 第一套128位整数 let l lc.to_i128()?; let r rc.to_i128()?; let result op.eval_i128(l, r)?; } else if ty.is_float() { if *ty IrType::F128 { // 第二套F128 let result fold_f128_binop(*op, lc, rc)?; } else { // 第三套普通浮点 let l as_f64_const_mapped(lhs, const_map)?; let r as_f64_const_mapped(rhs, const_map)?; let result fold_float_binop(*op, l, r)?; } } else { // 第四套普通整数 let lhs_const as_i64_const_mapped(lhs, const_map)?; let rhs_const as_i64_const_mapped(rhs, const_map)?; let result fold_binop(*op, lhs_trunc, rhs_trunc, *ty)?; }实际影响代码量大四套逻辑各约30-50行合计占文件的40%以上bug容易只修了一套其他几套还在新增类型比如定点数、向量需要再加一套扩展性差四套逻辑的边界处理可能有细微差异导致行为不一致九章法诊断 这是典型的“按表面分类而不是按物理性质分类”导致的代码膨胀。折叠操作的物理本质是统一的取两个常量值按操作符计算返回结果常量。 至于值是多少位、是整数还是浮点那是数据的表示方式不是操作的性质。现在按”数据类型”分了四套属于分类维度错了。参考方案 将计算能力下沉到IrConst类型本身作为方法实现impl IrConst { fn binop(self, op: IrBinOp, other: Self) - ResultSelf, FoldError { ... } fn unaryop(self, op: IrUnaryOp) - ResultSelf, FoldError { ... } fn cast(self, to_ty: IrType) - ResultSelf, FoldError { ... } }折叠函数只负责调度和类型检查不关心具体计算。这样一套逻辑搞定所有类型。 F-02 | 迭代循环无最大次数保护边界缺失定位fold_function 函数的主循环问题描述loop { // 重建const_map // 遍历折叠 if folded 0 { break; } total folded; }常量折叠的迭代循环只有”没有新折叠就退出”这一个终止条件没有最大迭代次数保护。实际影响理论上如果存在循环依赖比如A依赖BB依赖A可能无限循环极端复杂的常量表达式可能需要很多次迭代导致编译时间爆炸属于”流态过程没有刚性终止条件”九章法诊断 这是流态计算缺少刚性边界。常量折叠本质上是一个不动点迭代流态过程流态过程必须有刚性的终止边界不能只靠”自然收敛”。属于物理结构审查中的水位线缺失——没有给迭代过程设上限。参考方案 增加最大迭代次数限制比如8次或16次超过后强制停止并警告。实际中常量折叠很少需要超过3-4次迭代设个上限是安全的。 F-03 | const_map每次循环全量重建状态冗余定位fold_function 循环体开头问题描述 每次迭代循环都要遍历两遍所有指令来重建const_map第一遍收集所有Cast的目标类型第二遍收集所有Copy的常量值loop { // 第一遍Cast目标类型 for block in func.blocks { for inst in block.instructions { if let Instruction::Cast { dest, to_ty, .. } inst { // 记录cast_to_ty } } } // 第二遍Copy常量 for block in func.blocks { for inst in block.instructions { if let Instruction::Copy { dest, src: Operand::Const(c) } inst { // 记录konst } } } // 折叠... }实际影响每次迭代都要O(n)遍历两遍所有指令n是指令数大部分值在迭代中不会变化重复收集是浪费对于大函数这部分开销可能占折叠总时间的一半以上九章法诊断 这是状态管理方式不对——没有增量更新每次都全量重建。属于”数据池没有建立好状态散落在各处每次用都要重新收集”。参考方案第一次迭代全量构建const_map后续迭代只增量更新被修改指令对应的条目或者将const_map的维护下沉到指令修改的地方改一条就更一条 F-04 | Cast折叠与BinOp折叠的截断策略不一致状态不一致定位BinOp折叠和Cast折叠的类型处理问题描述 BinOp折叠在计算前会先将操作数截断到操作类型的位宽let lhs_trunc ty.truncate_i64(lhs_const); let rhs_trunc ty.truncate_i64(rhs_const); let result fold_binop(*op, lhs_trunc, rhs_trunc, *ty)?;但Cast折叠的源操作数没有做对应的截断/扩展处理直接用to_i64()的值let src_const as_i64_const_mapped(src, const_map)?; let result fold_cast(src_const, *from_ty, *to_ty);实际影响相同的常量值作为BinOp操作数和作为Cast源操作数可能因为位宽处理不同而结果不同比如一个I32常量存储为I64高位有垃圾值BinOp会先截断Cast可能不会导致折叠结果不一致同样的表达式不同写法折叠出不同结果九章法诊断 这是同类操作的边界处理不一致属于状态一致性问题。同样是”使用常量前的归一化”BinOp做了Cast没做标准不统一。参考方案 统一所有常量使用前的归一化策略——要么都在入口处截断/扩展到正确位宽要么都信任IrConst的存储是规范的。建议在 as_i64_const_mapped 这类函数里统一处理。 G-01 | 常量相等比较用to_hash_key()代码规范定位operands_equal 函数和Select折叠中的常量比较问题描述 比较两个IrConst是否相等时用的是 to_hash_key() 方法而不是直接比较值或者用 PartialEq。let same tv.to_hash_key() fv.to_hash_key() || matches!((tv.to_i64(), fv.to_i64()), (Some(a), Some(b)) if a b);实际影响可读性差to_hash_key()看起来是做哈希的不是做相等比较的需要同时比较hash key和i64值双重保险说明作者自己也不确定如果IrConst实现了PartialEq直接用更清晰九章法诊断 属于代码规范问题不影响功能但影响可维护性。参考方案 为IrConst实现PartialEq trait直接用 比较。 G-02 | 函数命名与实际功能不符代码规范定位resolve_remaining_is_constant 函数问题描述 函数名叫”resolve_remaining_is_constant”听起来是只处理剩下的IsConstant指令但实际上它会检查所有IsConstant能解析的都解析成1不能解析的解析成0。pub fn resolve_remaining_is_constant(module: mut IrModule) { // 遍历所有IsConstant指令 // 如果操作数是常量 → 设为1 // 否则 → 设为0 }实际影响函数名有误导性调用者可能以为它只处理”剩下的”实际上不管什么时候调用它都会把所有IsConstant都解析掉属于命名和功能不匹配九章法诊断 属于接口边界的命名不清晰是小问题但影响可读性。参考方案 改名为 resolve_all_is_constant 或者 finalize_is_constant更准确反映功能。 G-03 | 测试函数与生产函数分离可维护性定位try_fold 测试函数和 try_fold_with_map 生产函数问题描述#[cfg(test)] fn try_fold(inst: Instruction) - OptionInstruction { try_fold_with_map(inst, []) }测试用的 try_fold 只是生产函数 try_fold_with_map 传个空map的薄包装。实际影响多了一层没必要的包装测试代码和生产代码分离修改生产函数时容易忘了更新测试包装直接测生产函数就行不需要单独的测试入口九章法诊断 属于冗余代码不影响功能但增加维护成本。参考方案 去掉 try_fold测试直接调用 try_fold_with_map(inst, [])。五、问题归因分析归因类别问题数量占比典型问题分类维度错误3项33%四类操作重复实现、符号扩展靠来源推断、命名与功能不符边界校验缺失3项33%错误统一返回None、迭代无上限、截断策略不一致状态管理冗余2项22%const_map全量重建、状态与性质分离代码规范1项12%常量比较方式核心根因AI写代码的典型特征广度有余深度不足。会写但不会抽象每种情况都能写对但看不到”这些情况本质上是一回事”所以不会抽象合并主路径对但边界漏常见场景都处理了但罕见的边界情况除零、溢出、极端值经常漏掉靠模仿不靠理解代码看起来像模像样但底层的物理性质没搞清楚所以分类维度经常错本质上就是你说的——认知不到位。不是不会写是没看透所以只能一种情况写一套堆出来很多重复代码。六、精简评估当前代码量总代码1118行有效代码约1048行预计精简后精简后代码约650-700行精简率35%-40%精简来源分布精简来源预计减少行数占比消除四套重复实现~180行45%统一错误处理和边界校验~80行20%const_map增量更新~60行15%移除冗余包装和死代码~40行10%其他优化~40行10%精简后收益bug减少四套逻辑变一套bug数量至少减一半性能提升const_map增量更新大函数折叠速度提升30%-50%可维护性代码量减少40%逻辑更清晰修改一处处处生效扩展性新增类型只需要给IrConst加方法不需要改折叠框架七、特别说明本审查基于单文件静态分析未运行测试验证部分问题的实际影响需结合运行时行为确认。AI写的代码有一个特点主路径通常没问题问题都在边界和角落。这份报告里的致命问题平时跑正常测试可能发现不了遇到极端输入才会炸。从九章法的角度看这个模块的整体架构是”能用但不够纯”——刚柔分离做了一半边界校验做了一半状态管理做了一半。属于典型的”及格分”代码能跑但离”对”还有距离。审查完成日期2026年6月21日 审查工具九章编程法六轮审查模型
