AI代码生成过于冗长，需要更好衡量可维护性
问题概述
现有基准只衡量解决率和成本，未惩罚冗余代码，导致生成的代码库难以维护。评论者普遍希望能够测量代码复杂度和可读性（如循环复杂度），并希望通过抽象语法层面的度量来消除格式和注释带来的“噪音”。他们希望有更明确的指标来评估AI生成代码的长期可维护性。
痛点标签
- 过度冗长的代码导致代码库难以维护
- 缺乏衡量代码复杂性和可读性的指标（如循环复杂度）
- 现有基准未惩罚冗余代码，导致难以评估长期可维护性
待验证问题
- 您是否在实际项目中遇到过AI生成代码过于冗长或复杂的问题？
- 您是否愿意使用类似 Parsimony 的度量方法来评估代码质量？
- 您认为还需要哪些额外的度量指标来更好地评估AI生成代码的可维护性？
证据
事实
Existing benchmarks measure solve rate and token output/cost, but don't punish excess code, which makes a codebase harder to work with in the long term.
事实
it takes the patches that benchmarks already publish (DeepSWE, SWE-bench Verified, SWE-bench Live) and counts "coding units": syntax elements like statements, calls, names and literals. I didn't use lines of code, so cramming code isn't rewarded. Deleted code is subtracted, so it measures net units.
原话 · @Anonymous
On the one hand, I absolutely agree that we should try to measure and reduce verbosity that LLMs are slopping into our codebases.
原话 · @Anonymous
Yeah, I love this. We can't manage what we don't measure, and adjusting the mesurement to be on the abstract syntax level removes an entire layer of "mess" that comes from comments and formatting.
原话 · @Anonymous
Would love to see cyclomatic complexity as a supporting metric for readability. I increasingly find AI-adjacent and AI-written code suffering from this.
免责声明：本卡片由 AI 从社区讨论中提炼，属于「痛点证据」，是需求分析与验证的起点，不等同于「已验证的市场需求」。AI 存在分析局限，关键决策前请打开上方原始讨论人工复核。