自动修复系统
Auto-Fix System
自动化代码修复框架，支持 dry-run 预览和修复后状态联动
子问题
1.Fixer registration and detection pipeline
2.Dry-run preview before applying changes
3.Post-fix state update and score recomputation
4.Move command with import update
5.Cascade cleanup after primary fix (orphaned imports/empty blocks)
6.Skip reason classification and audit trail
7.Generic fixer factory for external tool integration
8.小样本阻尼：低 check 数维度权重按比例衰减防止摆动整体分数
9.Concern 桥接：mechanical findings 聚合为结构化 Concern 供 LLM 评审
10.Zone 分区评分排除：非生产文件（test/config/generated/vendor）排除出评分
11.Dismissal 过期检测：Concern fingerprint 关联 source_findings 变更时自动失效
12.Systemic pattern 检测：3+ 文件共享相同 detector 组合时升级为架构级 concern
13.Finding pressure 合并：severity 三维权重（confidence×impact×fix_scope）驱动分数下压
各项目的解法1 solutions
横向对比
| 维度 | Desloppify |
|---|---|
| 修复器注册 | LangConfig.fixers 字典，按语言插件隔离，6 个 TS fixer |
| 检测修复分离 | FixerConfig 三字段：detect/fix/post_fix 独立 callable |
| 预览机制 | dry-run 参数贯穿全链路 + before→after 随机样本展示 |
| 状态联动 | fix 后自动 resolve findings + 四维 score 重算 + delta 展示 |
| 级联清理 | _COMMAND_POST_FIX 注册表 + post_fix 钩子自动链式清理 |
| 跳过追踪 | FixResult.skip_reasons 分类统计 + retro checklist 输出 |
| 通用工厂 | make_generic_fixer() 基于外部工具命令的通用 fixer 生成 |
| 检查方式 | 双池架构：mechanical detector（AST/正则）+ subjective LLM 评审，60/40 加权混合 |
| 评估维度 | 5 mechanical + 12 subjective 共 17 维度，每维度独立加权 |
| 评估粒度 | 文件级 finding → 维度级 pass_rate → 池级加权平均 → overall score |
| 迭代机制 | 无自动迭代，依赖 scan→review→import 手动循环 |
| 反馈机制 | Concern 桥接：mechanical findings 聚合为结构化 Concern 供 LLM 评审 |
| 自动修复 | 4 级 action_type：auto_fix/reorganize/refactor/manual_fix，部分 detector 有 fixer |
| 覆盖范围 | 25+ detector 覆盖 dead code/complexity/duplication/naming/security/coupling 等 |
| 安全防护 | anti-gaming integrity：≥2 维度命中目标 ±5% 则批量重置为 0 分 |
| 配置驱动 | DetectorScoringPolicy 数据驱动，register_scoring_policy 运行时扩展 |
| 降级路径 | score_confidence 机制：detector 覆盖不完整时标记 reduced 并降低置信度 |
| 评估模型隔离 | review findings 排除出 detection scoring pipeline，仅通过 assessment 影响分数 |
| 决策归一化 | 三模式 lenient/strict/verified_strict 对 finding 状态容忍度递减 |
| 错误归因 | Zone 分类排除 test/config/generated/vendor，防止非生产代码污染评分 |
| 阶段拆分防截断 | DimensionMergeScorer 分阶段合并：weighted_mean → floor_aware → issue_penalty → cap |
| 双重token约束 | 无 token 约束，评分在本地完成不调用 LLM |
| 约束类型丰富度 | confidence×impact_scope×fix_scope 三维 severity 权重 |
最佳实践
1.FixerConfig separates detect/fix/report concerns
2.Dry-run mode prevents unintended changes
3.Post-fix hook registry enables automatic cascade cleanup chains
4.FixResult carries skip_reasons for transparent audit of unfixable items
5.Git uncommitted changes warning before destructive auto-fix
6.双池隔离优于单一加权：mechanical 和 subjective 信号量纲不同，混合前必须分池归一化
7.三模式并行计算：同一 findings 同时产出 lenient/strict/verified_strict 三个分数，适配不同场景
8.Anti-gaming 用统计异常检测：多维度同时命中目标值是统计异常，比信任 LLM 输出更可靠
9.Zone 分类一次构建多次查询：FileZoneMap 缓存避免重复分类开销
10.Concern 是 ephemeral 的：每次从 state 重新计算，不持久化，只有 LLM 确认后才变成 Finding