ARTICLE DETAIL

资讯详情

深耕郑州网站建设与运营推广的一线实战洞察。

fuck-u-code 分析技能实战指南:让 AI Agent 按七维 11 指标评分体系完成代码质量审查

fuck-u-code 分析技能实战指南:让 AI Agent 按七维 11 指标评分体系完成代码质量审查 fuck-u-code 分析技能实战指南让 AI Agent 按七维 11 指标评分体系完成代码质量审查【免费下载链接】fuck-u-codeLegacy-Mess Detector – assess the “legacy-mess level” of your code and output a beautiful report项目地址: https://gitcode.com/GitHub_Trending/fu/fuck-u-code本篇围绕 fuck-u-code 仓库中的 AI Agent 技能文档 SKILL.md 展开完整拆解这套「代码质量分析与审查」工作流如何运行fuck-u-code analyze获取 0-100 分的量化报告、如何解读 7 大维度 11 项指标的阈值与严重程度、以及如何按固定模板产出可执行的修复建议。读完后你可以把这套技能装进 Claude Code、opencode、Cursor 等 Agent让它在你提交代码或创建 PR 之前自动完成「分析 → 定位 → 解读 → 修复报告」全流程。一、这个技能是什么、何时触发suck-u-code-analysis 是仓库 skills/ 目录下为 AI Agent 设计的技能定义。其 frontmatter 中声明的触发条件如下代码变更完成、准备提交或创建 PR 之前实现功能、修复 bug、重构之后用户要求检查代码质量、分析技术债务、审查 code smell提及 fuck-u-code、code quality、shit mountain、code review、static analysis 等关键词。该技能覆盖14 种语言Go、JS、TS、Python、Java、C、C、Rust、C#、Lua、PHP、Ruby、Swift、Shell。技能的工作分三步见 skills/README.md运行fuck-u-code analyze获取量化指标0-100 总分7 维度 11 指标按语言专属阈值14 种语言解读结果给出带精确行号引用的可执行重构建议。二、前置条件安装与验证使用技能前需先全局安装 fuck-u-codenpm install -g eff-u-code验证安装fuck-u-code --version要求 Node.js 18.0.0。这与 package.json 中声明的engines.node: 18.0.0一致npm 包名为eff-u-code注册的可执行命令为fuck-u-codebin 映射见 package.json 的bin字段。若要把技能本体拉取到 Agent 的技能目录skills/README.md 提供了基于npx degit的一键方式无需完整 clone# Claude Code npx degit Done-0/fuck-u-code/skills/fuck-u-code-analysis ~/.claude/skills/fuck-u-code-analysis # opencode npx degit Done-0/fuck-u-code/skills/fuck-u-code-analysis ~/.config/opencode/skills/fuck-u-code-analysis目标目录已存在时加--force。三、总体工作流技能定义的标准工作流为原 dot 图的等价表述运行 fuck-u-code analyze → 读取 JSON 输出 → 识别关键问题文件score 60 → 钻取每项指标明细 → 应用审查标准Section 4→ 撰写可执行的修复报告工具产出一个 0-100 的总分和逐文件分数分数越高代表质量越好。下面逐步拆解。Step 1运行分析# 基础分析 fuck-u-code analyze . -f json -o /tmp/fuc-report.json # 详细模式输出最差的 20 个文件 fuck-u-code analyze . -v -t 20 -f json -o /tmp/fuc-report.json # 排除生成文件/测试文件 fuck-u-code analyze . -e **/*.test.ts -e **/generated/** -f json -o /tmp/fuc-report.json随后读取 JSON 输出文件获取结构化数据。这些选项在源码中均可对应到 analyze 命令实现选项含义默认值[path]要分析的项目路径.-v, --verbose显示详细输出关-t, --top n显示最差的 N 个文件10-f, --format fmt输出格式console/markdown/json/htmlconsole-o, --output file写入文件而非 stdout无-e, --exclude patterns...额外排除的 glob 模式无-c, --concurrency n并发 worker 数8CLI 层配置层默认 2上限 32-l, --locale locale语言en/zh/ruen并发默认值存在两处口径CLI 帮助文本标注 8而配置 schema 中 DEFAULT_CONFIG 的concurrency默认为 2、取值范围 1-32当配置文件未显式指定时CLI 帮助文案与实际生效值以 config/index.ts 的合并逻辑为准这里以「CLI 层默认 8」作为技能文档的表述。Step 2识别问题区域从 JSON 报告中提取三个层次overallScore全项目 0-100 分按代码行数加权的平均值aggregatedMetrics每项指标在全部文件上的平均值、中位数、最小/最大值files[]逐文件结果按分数升序排列最差的在前。重点关注 score 60 的文件技能称之为 shit mountain 区间。JSON 结构可直接在 json 输出实现 中核对顶层字段为$schema内嵌字段说明、projectPath、overallScore、summarytotalFiles/analyzedFiles/skippedFiles/analysisTime、aggregatedMetrics[]、files[]每个文件项含path、score、metrics[]name/category/value/normalizedScore/severity/details与parseResultlanguage、totalLines、codeLines、commentLines、functionCount、classCount。Step 3钻取指标明细对每个问题文件检查metrics[]数组每个指标含以下字段对应 MetricResult 类型定义字段含义name指标标识见第五节category维度分组complexity/size/duplication/structure/error/documentation/namingnormalizedScore0-100越高越好severityinfo/warning/error/criticaldetails人类可读的摘要locations[]具体的行/函数级问题位置含 filePath、line、column、functionName、message优先处理severity error的指标。Step 4撰写修复报告按第七节的固定输出格式撰写报告见下文。四、评分体系权重从哪来总分是 7 个类别的加权平均。默认权重经行业研究SonarQube、NASA、Microsoft 关于缺陷相关性的研究校准类别权重依据Complexity32%与缺陷相关性最强Pearson 0.7-0.8Duplication20%直接推高维护成本Size18%代码体量与函数粒度Structure12%文件组织与耦合Error Handling8%健壮性与可靠性Documentation5%长期可维护性Naming5%可读性与命名规范权重在源码中的落点默认权重硬编码在 scoring/index.ts 的getCategoryWeight中complexity 0.32、duplication 0.2、size 0.18、structure 0.12、error 0.08、documentation 0.05、naming 0.05未知类别回退 0.1配置层同样在 config/schema.ts 中定义了这 7 个权重的 zod schema 与默认值意味着你可以通过配置文件覆盖权重指标工厂 metrics/index.ts 会把 complexity 的 32% 均分给 3 个指标各 10.67%、size 的 18% 均分给 3 个指标各 6%其余 5 个指标各占其类别权重。计分公式calculateScore 对每个指标执行加权累加 Σ(normalizedScore × 类别权重)再除以总权重得到 0-100 分数指标为空时直接返回 100。单元测试 scoring.test.ts 验证了三个关键性质空指标返回 100、复杂度权重高于 size同样一高一低时复杂度高分的组合得分更高、加权平均介于两个分数之间。五、11 项指标详解Metrics Reference每项指标采用四级阈值体系excellent / good / acceptable / poor阈值按语言区分完整表见第六节及 references/thresholds.md。以下给出通用阈值、常见反模式与修复手段。5.1 复杂度类合计权重 32%3 项均分cyclomatic_complexity圈复杂度 CC公式CC 1 决策点数量if/for/while/case/catch//||/三元。它度量代码中独立执行路径的数量CC 越高意味着所需测试用例越多、缺陷概率越大。通用阈值级别CC 区间得分Excellent≤ 5100Good6-1080-100Acceptable11-1550-80Poor 150-50常见模式与修复长 if-else 链 → 改用策略模式、查表lookup table或多态嵌套条件 → 提取守卫子句guard clause用提前返回压平结构上帝函数CC 20→ 拆分为单一职责函数。cognitive_complexity认知复杂度公式CC nestingDepth × 2近似值。它度量代码的「理解难度」与圈复杂度不同它对嵌套结构施加更强惩罚。通用阈值级别区间得分Excellent≤ 7100Good8-1580-100Acceptable16-2545-80Poor 250-45常见模式与修复深层嵌套depth 4→ 反转条件、提取方法、使用 Optional/Result 类型线性流程中的中断continue/break/goto→ 重构循环改用 filter/map 等函数式操作无记忆化的递归 → 加缓存或改写为迭代。nesting_depth嵌套深度函数内控制流的最大嵌套层级。通用阈值级别深度得分Excellent≤ 3100Good480-100Acceptable545-80Poor 50-45常见模式与修复回调地狱 / 恐怖金字塔 → 使用 async/await 或 Promise 链if-for-if 嵌套 → 将内层逻辑提取为具名辅助函数循环内深 switch → 使用查表或分发映射。5.2 重复类权重 20%code_duplication代码重复通过分析控制流签名if/for/while/return/赋值模式的序列检测重复代码。级别重复率得分Excellent≤ 5%100Good5-10%80-100Acceptable10-20%45-80Poor 20%0-45常见模式与修复只有微小差异的复制粘贴函数 → 提取为参数化工具函数相似的 CRUD 操作 → 建立泛型 repository/service 层重复的校验逻辑 → 集中到 validator 模块多文件中的样板代码 → 使用代码生成或装饰器。5.3 尺寸类合计权重 18%3 项均分function_length函数长度每函数的代码行数平均值与最大值按 50/50 加权计入。通用阈值级别行数得分Excellent≤ 50100Good51-10085-100Acceptable101-20050-85Poor 2000-50常见模式与修复函数 100 行 → 识别不同职责各自提取为独立函数函数 300 行 → 大概率是「上帝方法」拆为协调者 工作者长 setup action teardown 结构 → 按阶段分别提取。file_length文件长度每文件的代码行数不含空行与注释。通用阈值级别代码行数得分Excellent≤ 300100Good301-50085-100Acceptable501-100050-85Poor 10000-50常见模式与修复文件 500 行 → 大概率承载多个职责拆为聚焦模块文件 1000 行 → 紧急按 feature/领域边界拆分关注点混杂API 业务逻辑 数据访问→ 应用分层架构。parameter_count参数数量单函数最大参数个数。通用阈值级别参数数得分Excellent≤ 3100Good4-585-100Acceptable6-750-85Poor 70-50常见模式与修复4 个及以上相关参数 → 归组为类型化的 options/config 对象6 个及以上参数 → 使用 builder 模式或参数对象解构布尔标志参数 → 拆分为独立的具名函数或使用枚举。5.4 结构类权重 12%structure_analysis结构分析复合得分 嵌套质量60% 文件组织25% 导入耦合15%。检测对象深嵌套5 为 critical、3 为 warning、超大文件1000 行、单文件函数过多50、导入过多20、循环依赖。常见模式与修复单文件函数过多 → 按职责归组为子模块循环依赖 → 引入接口/抽象层打破环路导入 20 → 模块承载过多职责拆分50 函数的上帝文件 → 按领域拆解为专属模块。5.5 错误处理类权重 8%error_handling错误处理易错 API 调用I/O、网络、解析、数据库中缺少正确错误处理的占比。级别未处理占比得分Excellent≤ 5%100Good5-15%80-100Acceptable15-30%45-80Poor 30%0-45检测形态无赋值/返回的裸调用、被忽略的错误_ ...、try-catch 之外的调用。常见模式与修复无 catch 的裸 API 调用 → 用 try-catch 或 .catch() 包裹忽略的返回值 → 显式处理错误或文档化「有意忽略」异步代码缺少错误边界 → 在 await 调用周围加 try-catchcatch 块中吞掉错误 → 记录日志或向上传播绝不静默忽略。5.6 文档类权重 5%comment_ratio注释比例注释行数与代码行数之比最优区间 10-25%。级别比例得分Optimal10-25%100Acceptable5-10% 或 25-40%60-100Poor 5% 或 40%0-60常见模式与修复 5% → 为公共 API 和复杂逻辑补充 JSDoc/docstring40% → 可能过度注释琐碎代码删除复述代码本身的注释注释掉的死代码 → 删除交给版本控制缺少模块级文档 → 添加说明模块用途的文件头。5.7 命名类权重 5%naming_convention命名规范对语言特定命名规范的符合率。级别符合率得分Excellent≥ 90%90-100Good70-90%70-90Acceptable50-70%50-70Poor 50%0-50语言特定规则语言函数类GoPascalCase/camelCasePascalCaseJS/TScamelCase/PascalCasePascalCasePythonsnake_casePascalCaseJavacamelCasePascalCaseRustsnake_casePascalCaseC#PascalCasePascalCaseRubysnake_casePascalCasePHPcamelCase/snake_casePascalCaseSwiftcamelCasePascalCaseShellsnake_case—C/Csnake_case/camelCasePascalCaseLuacamelCase/snake_case—常见模式与修复同一文件内命名风格不一致 → 全项目应用 linter/formatter缩写/单字母命名 → 重命名为描述性标识符混用多种约定 → 每类标识符选定一种约定并一致执行。六、语言专属阈值14 语言完整阈值表在 references/thresholds.md其数值来源为 language-thresholds.ts 中逐语言标注的官方 linter 默认值gocyclo、ESLint、Pylint、SonarQube、RuboCop、SwiftLint、Clippy 等。四列含义≤ Excellent 为优秀Good/Acceptable/Poor 为逐级放宽的上限。Gogocyclo / gocognit / Effective Go指标ExcellentGoodAcceptablePoor圈复杂度≤ 5≤ 10≤ 15 15认知复杂度≤ 7≤ 15≤ 25 25函数长度行≤ 50≤ 100≤ 200 200文件长度代码行≤ 300≤ 500≤ 1000 1000参数数量≤ 3≤ 5≤ 7 7嵌套深度≤ 3≤ 4≤ 5 5JavaScript / TypeScriptESLint complexity / max-params / max-depth指标ExcellentGoodAcceptablePoor圈复杂度≤ 5≤ 10≤ 20 20认知复杂度≤ 8≤ 15≤ 25 25函数长度行≤ 50≤ 100≤ 200 200文件长度代码行≤ 250≤ 400≤ 800 800参数数量≤ 3≤ 4≤ 6 6嵌套深度≤ 3≤ 4≤ 5 5PythonPylint / McCabe指标ExcellentGoodAcceptablePoor圈复杂度≤ 5≤ 10≤ 15 15认知复杂度≤ 7≤ 12≤ 20 20函数长度行≤ 30≤ 50≤ 100 100文件长度代码行≤ 300≤ 500≤ 1000 1000参数数量≤ 3≤ 5≤ 7 7嵌套深度≤ 3≤ 5≤ 7 7JavaSonarQube Java / Checkstyle / PMD指标ExcellentGoodAcceptablePoor圈复杂度≤ 5≤ 10≤ 15 15认知复杂度≤ 8≤ 15≤ 25 25函数长度行≤ 50≤ 100≤ 150 150文件长度代码行≤ 300≤ 500≤ 1000 1000参数数量≤ 3≤ 5≤ 7 7嵌套深度≤ 3≤ 4≤ 5 5CLinux Kernel Coding Style / SonarQube C指标ExcellentGoodAcceptablePoor圈复杂度≤ 5≤ 10≤ 15 15认知复杂度≤ 7≤ 12≤ 20 20函数长度行≤ 40≤ 80≤ 150 150文件长度代码行≤ 300≤ 500≤ 1000 1000参数数量≤ 3≤ 5≤ 7 7嵌套深度≤ 3≤ 4≤ 5 5CGoogle C Style Guide / LLVM / clang-tidy指标ExcellentGoodAcceptablePoor圈复杂度≤ 5≤ 10≤ 15 15认知复杂度≤ 8≤ 15≤ 25 25函数长度行≤ 50≤ 100≤ 200 200文件长度代码行≤ 300≤ 500≤ 1000 1000参数数量≤ 3≤ 5≤ 7 7嵌套深度≤ 3≤ 4≤ 5 5RustClippy cognitive_complexity / too_many_arguments / too_many_lines指标ExcellentGoodAcceptablePoor圈复杂度≤ 5≤ 10≤ 15 15认知复杂度≤ 8≤ 15≤ 25 25函数长度行≤ 50≤ 100≤ 200 200文件长度代码行≤ 300≤ 500≤ 1000 1000参数数量≤ 3≤ 5≤ 7 7嵌套深度≤ 3≤ 4≤ 5 5C#SonarQube C# / Microsoft conventions指标ExcellentGoodAcceptablePoor圈复杂度≤ 5≤ 10≤ 15 15认知复杂度≤ 8≤ 15≤ 25 25函数长度行≤ 50≤ 100≤ 200 200文件长度代码行≤ 300≤ 500≤ 1000 1000参数数量≤ 3≤ 5≤ 7 7嵌套深度≤ 3≤ 4≤ 5 5Lualuacheck / SonarQube defaults指标ExcellentGoodAcceptablePoor圈复杂度≤ 5≤ 10≤ 15 15认知复杂度≤ 8≤ 15≤ 25 25函数长度行≤ 50≤ 100≤ 200 200文件长度代码行≤ 300≤ 500≤ 1000 1000参数数量≤ 3≤ 5≤ 7 7嵌套深度≤ 3≤ 4≤ 5 5PHPPHP_CodeSniffer / PHPMD / SonarQube PHP指标ExcellentGoodAcceptablePoor圈复杂度≤ 5≤ 10≤ 15 15认知复杂度≤ 8≤ 15≤ 25 25函数长度行≤ 50≤ 100≤ 200 200文件长度代码行≤ 300≤ 500≤ 1000 1000参数数量≤ 3≤ 5≤ 7 7嵌套深度≤ 3≤ 5≤ 7 7RubyRuboCop Metrics 默认值指标ExcellentGoodAcceptablePoor圈复杂度≤ 4≤ 7≤ 12 12认知复杂度≤ 5≤ 8≤ 15 15函数长度行≤ 20≤ 50≤ 100 100文件长度代码行≤ 250≤ 400≤ 800 800参数数量≤ 3≤ 4≤ 6 6嵌套深度≤ 3≤ 4≤ 5 5Ruby 的阈值比大多数语言更严格——RuboCop 默认值强调短方法与低复杂度。SwiftSwiftLint 默认值 / Apple Swift API Design Guidelines指标ExcellentGoodAcceptablePoor圈复杂度≤ 5≤ 10≤ 20 20认知复杂度≤ 7≤ 12≤ 20 20函数长度行≤ 30≤ 40≤ 100 100文件长度代码行≤ 200≤ 350≤ 600 600参数数量≤ 3≤ 5≤ 7 7嵌套深度≤ 3≤ 4≤ 5 5Swift 的文件长度阈值最紧good ≤ 350acceptable ≤ 600SwiftLint 默认的函数体长度告警线仅 40 行。ShellGoogle Shell Style Guide / ShellCheck指标ExcellentGoodAcceptablePoor圈复杂度≤ 5≤ 10≤ 15 15认知复杂度≤ 7≤ 12≤ 20 20函数长度行≤ 30≤ 50≤ 100 100文件长度代码行≤ 200≤ 300≤ 600 600参数数量≤ 3≤ 5≤ 7 7嵌套深度≤ 3≤ 4≤ 5 5Shell 脚本由于每行固有复杂度更高尺寸阈值整体更低。值得注意的语言差异判断前务必先查表Ruby全面更严CC good ≤ 7、函数长度 good ≤ 50 行Ruby 文化崇尚短方法Swift文件长度上限最紧good ≤ 350、acceptable ≤ 600SwiftLint 强制小文件Python函数 good 上限更短≤ 50 行Pylint 与 Python 文化偏好紧凑函数C函数 good 上限更紧≤ 80 行Linux 内核风格强调简短Shell / Swift预期文件更小Shell 因每行复杂度高Swift 因 SwiftLintPHP / Python允许更深嵌套good ≤ 5、acceptable ≤ 7比 Go/JS/Java 宽松。七、审查标准与修复规范Review Standards撰写修复建议时遵循以下原则提炼自项目的 AI 审查系统优先级顺序性能瓶颈 安全漏洞 可维护性风险 代码风格建议的质量规则具体且可执行。不要写「优化代码结构」而要写「将 45-67 行提取为calculateMetrics(data)返回MetricResult[]」。锚定证据。每条建议必须引用分析输出中的具体指标值与位置。简洁。每条建议 ≤ 30 词无客套、无填充。尊重语言惯例。重构建议必须使用目标语言的真实语法与惯用法。分诊方法Triage对 JSON 输出中的每个问题文件按严重程度排序指标critical error warning同严重程度内按权重排序complexity 32% duplication 20% size 18% ...对每个被标记指标查看locations[]获取精确的函数名与行号优先为「最高严重度 × 最高权重」的问题撰写修复方案。修复建议模板各指标类别的建议遵循同一模式复杂度问题函数processOrderL 45-189圈复杂度为 24。修复将校验逻辑L 48-82提取为validateOrderInput(input): ValidationResult将计算逻辑L 90-150提取为calculateOrderTotal(items, discounts): number。重复问题3 个函数getUser、getOrder、getProduct共享相同的 fetch-and-parse 模式。修复创建fetchResourceT(endpoint: string): PromiseT并在各处调用。尺寸问题handleSubmitL 120-380有 260 行、8 个参数。修复提取为带validate()、transform()、submit()方法的SubmitCoordinator类传SubmitConfig对象替代 8 个参数。结构问题utils.ts有 52 个函数和 24 个导入。修复按领域拆分为utils/string.ts、utils/date.ts、utils/validation.ts。错误处理问题L 67 的readFile调用没有 try-catch。修复包裹 try-catch返回ResultContent, ReadError。文档问题注释比例 2.1%——parseAST()L 30-95处理了 4 个边界情况却没有 docstring。修复添加 JSDoc说明输入格式、边界情况与返回类型。命名问题函数fnL 23与calc2L 45违反 camelCase 约定。修复重命名为calculateDiscount与computeTaxRate。八、报告输出格式固定模板修复报告必须使用以下 Markdown 结构每节均为必填# Code Quality Review ## Summary 一句话点明最严重问题的根因解释其影响不复述指标数字。 ## Overall Assessment | Metric | Score | |--------|-------| | Overall | XX/100 | | Files Analyzed | N | | Critical Issues | N | ## Key Issues按严重程度排序 每个问题一行 - **FunctionNameL 起-止**根因描述 具体修复建议 ## Refactoring Plan 可执行步骤的编号列表。每步 ≤ 30 词直接可执行。 1. [带文件、函数与行号引用的具体动作] 2. [下一步具体动作] ## Security Concerns 列出安全顾虑含受影响代码位置 修复方式或声明 No security issues found.。九、快速参考Quick Reference命令速查命令用途fuck-u-code analyze .分析当前目录fuck-u-code analyze . -f json -o report.jsonJSON 输出到文件fuck-u-code analyze . -v -t 20详细模式、最差 20 文件fuck-u-code analyze . -e **/*.test.ts排除模式fuck-u-code analyze . -l zh中文输出分数区间与行动分数区间级别行动90-100Clean直接交付75-89Mild建议小修60-74Moderate合并前需重构40-59Bad需要大量清理0-39Disaster建议重写严重程度定义Severity含义info未检测到问题warning小问题应当处理error显著问题需要关注critical交付前必须修复十、常见误区Common Mistakes技能文档最后列出了 5 个高频错误值得逐条对照自查只看总分。项目级 80 分可能掩盖个别文件的 20 分。始终检查逐文件明细files[]按分数升序。忽略权重差异。命名问题5% 权重的影响远小于复杂度问题32%。按「权重 × 严重程度」排优先级。建议含糊。「重构这个函数」不可执行。必须指明从哪些行、提取什么、命名为什么。跳过 locations[]。该数组包含精确行号与函数名建议中必须使用。忘记语言专属阈值。Python 允许比 Go 更深的嵌套Ruby 函数应比 Java 方法更短。判断前先查 references/thresholds.md。十一、小结这套技能把「代码质量审查」从主观经验变成了可复现的流水线fuck-u-code analyze产出机器可读的 JSON结构可对照 src/cli/output/json.ts 与 src/metrics/types.ts 验证→ 按 0.32/0.2/0.18/0.12/0.08/0.05/0.05 的默认权重理解分数的构成src/scoring/index.ts、src/metrics/index.ts→ 用 14 语言阈值表定性每个指标src/metrics/thresholds/language-thresholds.ts→ 按固定模板输出带行号锚点的修复报告。整套流程的每个环节——CLI 选项、JSON 字段、权重常量、阈值来源——都能在仓库中找到对应实现因此既适合人类开发者上手也适合作为 AI Agent 的可执行技能被直接引用。【免费下载链接】fuck-u-codeLegacy-Mess Detector – assess the “legacy-mess level” of your code and output a beautiful report项目地址: https://gitcode.com/GitHub_Trending/fu/fuck-u-code创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考
返回列表