一句话:DesignFix 通过注入规则说明、项目示例与结构上下文,用两步 LLM 流程为设计规则违规生成可审查的修复。
设计规则将项目特定的架构决策显式化并可自动检查,但检测到违规后,开发者仍需理解规则、定位代码并构造符合项目惯例的修复。DesignFix 是一个 IDE 集成方法,它在每个违规处附加规则描述、同一项目中满足规则的示例以及聚焦的结构上下文,并用两步 LLM 流水线分离修复推理与结构化编辑提取。论文报告了三项评估:在 7 种提示配置、9450 次修复试验中,完整流程达到最高 90% 修复成功率、89% 解释正确率和 90% 无关代码保持率,比基线提示高 26 个百分点;14 名开发者的对照实验中,使用 DesignFix 完成修复快 36%,正确修复率从 43% 提升至 93%,NASA-TLX 六个维度中五个的工作负荷显著降低;在六类用户研究任务上,自主 IDE 代理 Cline 仅有半数产生正确修复,且平均消耗 DesignFix 12.1 倍的 token。结果表明,有效的设计规则修复依赖于将 LLM 扎根于检查器推导的项目特定设计意图,并让修复处于开发者审查之下。
Design rules make project-specific design decisions explicit and checkable, helping teams preserve architectural intent as systems evolve. Although automated checkers can detect violations, developers must still interpret the rule, locate the code that must change, and construct a repair consistent with project conventions. We present DesignFix, an IDE-integrated approach that turns checker-reported violations into project-grounded, reviewable repairs. DesignFix augments each violation with the rule description, a rule-satisfying example from the same project, and focused structural context, while a two-step LLM pipeline separates repair reasoning from structured edit extraction. We report three complementary evaluations. A systematic study of seven prompt configurations across 9,450 repair trials found that the full workflow achieved up to 90% repair success, 89% explanation correctness, and 90% preservation of unrelated code: 26 percentage points above a baseline prompt. We conducted a controlled experiment with 14 developers. Compared to a control condition with browser-based LLMs, developers completed repairs 36% faster with DesignFix, increased correct repairs from 43% to 93%, and reported significantly lower workload on five of six NASA-TLX dimensions. Finally, we ran the autonomous in-IDE agent Cline on six repair task types drawn from our user study. Cline produced a correct repair for only half of them, while averaging 12.1× DesignFix’s token use and substantially higher API cost per run. Together, these results suggest that effective design-rule repair depends on grounding the LLM in checker-derived, project-specific design intent and on keeping repairs under developer review, needs that repository autonomy alone does not meet.