fuck-u-code AI Agent Skill让 Claude Code / Cursor 自动执行 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本文基于 skills/README.md 及其配套的 SKILL.md 展开讲解如何把 fuck-u-code 的fuck-u-code-analysis技能安装进 AI AgentClaude Code、opencode、Cursor 等并完整走通运行分析 → 解读 7 维度 11 项指标 → 输出可执行重构报告的标准化流程。读完后你能在自己的 Agent 工作流中嵌入一套基于语言特定阈值与加权评分体系的质量审查机制并获得有行号级证据的重构建议。这个 Skill 是什么、何时触发fuck-u-code-analysis是仓库内为 AI Agent 提供的技能包skills面向 fuck-u-code——一个用 tree-sitter 做 AST 解析、离线运行的代码质量分析器。按 SKILL.md 中 frontmatter 的定义它的触发场景非常明确时机代码改动完成后、提交或创建 PR 之前实现功能、修复 Bug 或重构之后意图用户要求检查代码质量、分析技术债、审查 code smell或提到 fuck-u-code、code quality、shit mountain、static analysis 等关键词覆盖范围14 种语言——Go、JS、TS、Python、Java、C、C、Rust、C#、Lua、PHP、Ruby、Swift、Shell。技能的核心动作是三步运行fuck-u-code analyze拿到量化指标0-100 总分7 个维度共 11 项指标用语言特定阈值14 种语言各有独立阈值表解读结果给出带精确行号引用的可执行重构建议。安装先装 CLI再把技能拉进 Agent1. 全局安装分析器技能本身只是说明书真正干活的是 fuck-u-code CLI。npm 包名是eff-u-codepackage.json 中bin字段声明了fuck-u-code与fuck-u-code-mcp两个可执行入口要求Node.js 18.0.0npm install -g eff-u-code fuck-u-code --version # 验证安装2. 用 npx degit 把技能拉到 Agent 的 skills 目录官方推荐直接用npx degit拉取单个技能目录无需 clone 整个仓库也不留临时目录macOS / Linux# 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-analysisWindows (PowerShell)# Claude Code npx degit Done-0/fuck-u-code/skills/fuck-u-code-analysis $HOME\.claude\skills\fuck-u-code-analysis # opencode npx degit Done-0/fuck-u-code/skills/fuck-u-code-analysis $HOME\.config\opencode\skills\fuck-u-code-analysis如果目标目录已存在给degit加--force。拉下来的技能包含两个关键文件SKILL.md工作流与评审标准和references/thresholds.md14 种语言的完整阈值表。标准工作流四步从分析到报告SKILL.md 用一张流程图定义了技能的工作流Run analyze → Read JSON → 找出 score 60 的关键文件 → 逐项指标深挖metrics[]→ 套用评审标准 → 输出整改报告Step 1运行分析技能推荐的三组典型命令JSON 是技能解读的主数据源# 基础分析 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对应的 CLI 参数与 README.md 的 Usage 章节一致-f指定 console/markdown/json/html 四种输出格式-o写文件-t指定 Top N 最差文件默认 10-e追加 glob 排除规则-l切换 en/zh/ru/zh-tw 语言。Step 2定位问题区域从 JSON 报告中提取三个关键结构overallScore项目级 0-100 分按代码行数加权平均aggregatedMetrics每项指标在所有文件上的均值、中位数、min/maxfiles[]逐文件结果按分数升序最差的在前。技能的判定基准是score 60 的文件进入shit mountain区必须逐个审查。Step 3逐项指标深挖每个文件有一个metrics[]数组其中每一项指标的结构在 src/metrics/types.ts 中定义为MetricResult接口与技能文档的字段表一一对应字段含义name指标标识见下文 11 项指标category维度组complexity / size / duplication / structure / error / documentation / namingnormalizedScore0-100分越高越好源码注释明确 100 is bestseverityinfo/warning/error/criticaldetails人类可读摘要locations[]精确到行/函数的具体位置排序策略优先处理severity error的指标同严重度下按类别权重排complexity 32% duplication 20% size 18% …。Step 4输出整改报告技能强制规定报告必须使用固定 Markdown 结构Summary、Overall Assessment、Key Issues、Refactoring Plan、Security Concerns 五个 section 缺一不可每条建议 ≤ 30 词、必须锚定指标值和locations[]中的具体行号。评分体系7 维度 11 指标的权重与来源权重分配总分是 7 个类别的加权平均默认权重源自行业缺陷相关性研究SonarQube / NASA / Microsoft如下表类别权重理由Complexity32%与缺陷强相关Pearson 0.7-0.8Duplication20%维护成本直接倍增因子Size18%代码量与函数粒度Structure12%文件组织与耦合Error Handling8%鲁棒性与可靠性Documentation5%长期可维护性Naming5%可读性与规范符合度这套权重在源码中有两处精确落点可以交叉验证src/metrics/index.ts 的createMetrics()工厂函数实例化全部 11 个指标并且把 complexity 的 32% 均分给 3 个指标各约 10.67%、size 的 18% 均分给 3 个指标各 6%——这与技能文档中weight: 32% total, split 3 ways的表述完全一致src/scoring/index.ts 的getCategoryWeight()定义了同一组默认权重常量calculateScore()则对每个文件的指标做加权平均——即技能所说higher better的 0-100 分由此算出且权重支持从配置中覆盖。11 项指标速览类别指标核心判定逻辑Complexitycyclomatic_complexityCC 1 决策点if/for/while/case/catch///三元Complexitycognitive_complexity近似公式 CC nestingDepth × 2对嵌套指数级惩罚Complexitynesting_depth函数内最大控制流嵌套层数Duplicationcode_duplication基于控制流签名if/for/while/return/赋值模式序列检测重复Sizefunction_length每个函数的代码行数均值与最大值各占 50% 权重Sizefile_length每个文件的代码行去空行与注释Sizeparameter_count函数最大参数个数Structurestructure_analysis综合分嵌套质量 60% 文件组织 25% 导入耦合 15%Error Handlingerror_handling未妥善处理的易错 API 调用I/O、网络、解析、数据库占比Documentationcomment_ratio注释行/代码行最优区间 10-25%Namingnaming_convention语言特定命名规范符合率每项指标采用四级阈值体系excellent / good / acceptable / poor且阈值是语言特定的。以通用的 cyclomatic_complexity 为例≤5 为 excellent100 分6-10 good11-15 acceptable15 poor。语言特定阈值为什么 Ruby 和 Swift 更严格技能明确要求判断前先查阈值表——Python 允许比 Go 更深的嵌套Ruby 的函数应比 Java 方法更短。完整表格见 references/thresholds.md其数据源即 src/metrics/thresholds/language-thresholds.tsLANGUAGE_THRESHOLDS记录并声明所有取值基于各语言官方 linter 默认值ESLint、Pylint、RuboCop、Clippy、SwiftLint、ShellCheck 等。几个值得记住的差异化基准语言显著差异Ruby全面最严CC good ≤ 7、cognitive good ≤ 8、函数长度 good ≤ 50 行RuboCop 默认强调短方法Swift文件长度最紧good ≤ 350、acceptable ≤ 600函数 good ≤ 40 行SwiftLint 默认Python函数 good ≤ 50 行但嵌套宽松good ≤ 5、acceptable ≤ 7C函数 good ≤ 80 行Linux 内核风格强调简短Shell文件 good ≤ 300、acceptable ≤ 600脚本每行复杂度天然更高PHP与 Python 一样允许更深嵌套acceptable ≤ 7JS/TSCC acceptable 放宽到 ≤ 20文件 good ≤ 400评审标准如何让 Agent 的建议可执行技能把评审纪律写进了 SKILL.md 的 Review Standards 一节这本质上是约束 LLM 输出质量的元规则优先级性能瓶颈 安全漏洞 可维护性风险 代码风格。四条建议质量规则具体可执行——不写优化代码结构而写把 45-67 行提取为calculateMetrics(data)返回MetricResult[]锚定证据——每条建议必须引用分析输出中的具体指标值和位置简洁——每条建议 ≤ 30 词无寒暄尊重语言习惯——重构建议必须使用目标语言的真实语法与惯用法。按类别的整改模板示例技能原文ComplexityprocessOrderL45-189CC 达 24 → 把校验逻辑L48-82提取为validateOrderInput(input): ValidationResult把计算L90-150提取为calculateOrderTotal(items, discounts): numberDuplicationgetUser/getOrder/getProduct共享同一 fetch-and-parse 模式 → 建fetchResourceT(endpoint: string): PromiseTSizehandleSubmitL120-380260 行 8 参数 → 拆成SubmitCoordinator类的validate()/transform()/submit()8 参数改为SubmitConfig对象Structureutils.ts52 个函数 24 个 import → 按域拆成utils/string.ts、utils/date.ts、utils/validation.tsErrorL67 的readFile无 try-catch → 包裹后返回ResultContent, ReadErrorDocumentation注释比 2.1%parseAST()L30-95处理 4 个边界情况却无 docstring → 补 JSDocNamingfnL23、calc2L45违反 camelCase → 改名为calculateDiscount、computeTaxRate。快速参考表与常见误区命令速查命令用途fuck-u-code analyze .分析当前目录fuck-u-code analyze . -f json -o report.jsonJSON 输出到文件fuck-u-code analyze . -v -t 20详细模式最差 Top 20fuck-u-code analyze . -e **/*.test.ts排除 glob 模式fuck-u-code analyze . -l zh中文输出分数区间 → 行动决策分数区间级别行动90-100CleanShip it75-89Mild建议小修60-74Moderate合并前需重构40-59Bad需要大量清理0-39Disaster建议重写Severity 语义info无问题/warning次要问题应处理/error显著问题需关注/critical发布前必须修复。五个常见误区技能最后用一节Common Mistakes总结了 Agent 使用中最容易犯的错误值得逐条对照只看总分——项目级 80 分可能掩盖个别 20 分的文件必须查逐文件分解忽略权重差异——naming5%问题远不如 complexity32%问题重要应按 权重 × 严重度 排序建议含糊——重构这个函数不可执行必须写清楚提取什么、哪几行、叫什么名字跳过 locations[]——locations数组里有精确行号和函数名建议中必须使用忘记语言特定阈值——判断前查 references/thresholds.md不同语言的好标准不同。小结这套 skill 的设计本质是把一个离线静态分析器的量化输出翻译成 LLM 能稳定执行、可验证、可追溯的评审流程CLI 负责算数11 项指标 × 14 套语言阈值 × 7 维加权SKILL.md 负责定规触发时机、严重度排序、建议质量规则、报告模板阈值表负责校准每门语言自己的 linter 默认值。三者结合后Agent 在 commit 前给出的每一条重构建议都能锚定到具体的文件、函数和行号这也是它区别于让 AI 泛泛点评代码的关键。【免费下载链接】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），仅供参考