configure-codacy-cloud

配置 Codacy（Cloud）

**术语表：**有关 Codacy 概念（问题、发现项、严重性、覆盖率、工具、规则模式等）的通用定义，请参阅 glossary.md。

此技能会直接在 Codacy Cloud 上调整代码库的 Codacy 配置，并以云端作为真实数据源。它不会运行本地分析。此技能会读取当前云端问题概况，应用一组信号更强的工具和规则模式，在 Codacy 上重新分析，并通过两轮迭代减少噪声，最终生成简洁且信号明确的配置，同时完整记录所有变更及其原因。

如果你想从头发现技术栈并在本地运行 codacy-analysis analyze，请改用本地优先版本 configure-codacy 技能。此技能适用于已接入 Codacy 并完成分析、且希望直接调整云端配置的代码库。

先决条件和要求

• Codacy Cloud CLI（codacy）——用于执行所有云端读取、更新和重新分析操作。有关设置，请参阅 codacy-cloud-cli。
• Codacy Analysis CLI（codacy-analysis）——仅用于配置文件操作（init --remote、init --auto、config --merge）。有关设置，请参阅 codacy-analysis-cli。
• 两个 CLI 共用 ~/.codacy/credentials 中的凭据，因此登录一次即可同时使用两者。

此技能有三项硬性要求。开始任何操作前，请确认三项要求均已满足；如有任一项不满足，请停止并提供明确指引：

1. 仓库已在 Codacy 上。 使用以下命令确认：

   codacy repo --output json
   

   如果确认失败（仓库不在 Codacy 上或未通过身份验证），请停止。告知用户先将仓库添加到 Codacy（例如 codacy repo --add）——此技能不会设置新仓库。

2. 仓库至少完成过一次分析。 检查 codacy repo --output json 的输出，确认其中有已完成／最近一次分析的指示，并确认问题概览会返回数据：

   codacy issues -O -o json 2>/dev/null | jq '.'
   

   如果仓库从未分析过，或分析仍在运行，请停止。告知用户等待首次分析完成——整个流程都依赖云端问题数据作为基准。

3. Cloud CLI 版本 ≥ 1.3.0（填充 fileCount 所必需）。使用以下命令确认：

   codacy repo -o json 2>/dev/null | jq -e '.repository.fileCount != null'
   

   如果输出为 false（或发生错误），请停止。已安装的 Cloud CLI 版本低于 1.3.0，无法填充摘要中的 fileCount 字段。告知用户至少升级到 1.3.0（npm install -g @codacy/codacy-cloud-cli@latest）后重新运行。该检查使用 != null 而非 has("fileCount")，因此既会拒绝缺失的键，也会拒绝值为 null 的键；同时，检查的是功能是否存在，而不是 --version，因为当前 CLI 的 --version 字符串是硬编码的。

在仓库内运行时，Cloud CLI 会根据 git 远程地址自动检测 provider、organization 和 repository，因此下方显示的显式 <provider> <org> <repo> 参数在实际使用中为可选参数。

CLI 输出注意事项： 两个 CLI 都会在输出 JSON 前向 stderr 打印进度行。通过管道传给 jq 时，请重定向 stderr：codacy ... -o json 2>/dev/null | jq '...'。

codacy patterns 分页注意事项： codacy patterns <tool> [--enabled] 目前只会返回前 100 个模式，且没有 --limit 标志（计划添加——在此之前，请假定列表会在 100 个模式处截断）。切勿使用其输出长度作为模式数量：对于启用模式超过 100 个的工具，你只会看到 100 个，却不会收到任何提示，这会造成模式“减少”的假象（例如，某个工具实际启用了 232 个模式，看起来却“只有 100 个”）。要检查或测试特定模式，请使用 --search <patternId> 按 id 筛选，或使用 codacy pattern <tool> <patternId> -o json 查询单个模式。要准确统计启用的模式数量，请从配置文件中计算（jq '[.tools[].patterns|length]|add' .codacy/auto.config.json），不要从模式列表中计算。

本地配置不会被触碰。 此技能通过自定义 --config-file 路径（.codacy/remote.config.json、.codacy/auto.config.json）运行，且绝不会创建或修改 .codacy/codacy.config.json。现有的任何本地配置都会保持原样。

此技能的工作原理

关键原则与本地版本相同：从信号更强的一组开始，然后用数据消除噪声——但所有测量和更改都在 Codacy Cloud 上进行。

工具分为两组，并通过两种不同的机制应用更改：

• Analysis CLI 支持的工具（codacy-analysis info 列出的工具，参见 supported-tools.md）通过编辑 .codacy/auto.config.json 文件并导入来配置：codacy tools --import .codacy/auto.config.json。导入会根据文件内容协调受支持的工具：文件中包含的受支持工具会用文件中的模式替换其现有模式；文件中未包含的受支持工具会在导入时被禁用（你会在导入计划中看到 N tool will be disabled: ...）。仅限云端的工具——不在 Analysis CLI 范围内的工具——不会出现在文件中，其状态也会保持不变。
• 仅限云端的工具（在 Codacy 中已启用，但无法通过 Analysis CLI 运行，例如 SonarSharp、Codacy ScalaMeta Pro）无法通过导入进行配置。请直接使用 Cloud CLI 更改它们：codacy tool、codacy pattern、codacy patterns。

Cloud 工具名称与配置中的 toolId。 Cloud CLI 命令（codacy tool、codacy pattern、codacy patterns）使用 codacy tools 显示的云端名称来指定工具——部分工具的云端名称与 Analysis CLI 配置中的 toolId 不同。最明显的例子是：配置中的 toolId 为 Semgrep，但云端工具名为 Opengrep，因此 codacy patterns Semgrep 会因 Tool "Semgrep" not found 而失败，而 codacy patterns Opengrep 则可以正常运行。Cloud CLI 命令报告找不到工具时，请检查 codacy tools -o json 中的名称并使用该名称。（使用 toolId 作为键的导入方式不受影响。）

编辑 auto.config.json 之前，请阅读配置格式参考。其结构为：顶层包含一个 tools[] 数组，每个条目以**toolId（例如 "Biome"、"Semgrep"、"ESLint9"）为键，并包含一个 patterns[] 数组；数组中的条目以patternId为键，并可选地包含一个parameters对象——这些条目中没有** uuid、name 或 enabled 键，因此请按 toolId / patternId 筛选和编辑。要禁用某个模式，请将其从 patterns 数组中移除；要调整某个模式，请编辑其 parameters；要禁用某个工具，请移除整个工具条目。

工作流

Configuration Progress:
- [ ] Startup: verify requirements, capture baseline, import cloud config, split tools
- [ ] First pass: generate + merge config, first noise cut, apply, reanalyze
- [ ] Second pass: evaluate impact, second noise cut, apply, reanalyze
- [ ] Final: capture after metrics, evaluate, emit JSON summary, clean up

启动

1. 创建临时目录：

   mkdir -p .codacy/tmp
   

2. 捕获基线概览（BEFORE 参考数据）：

   codacy issues -O -o json 2>/dev/null > .codacy/tmp/overview-before.json
   

   此概览是 BEFORE issues 总数、issuesByCategory 和 issuesBySeverity 分类统计，以及各模式的问题数和误报数的来源。

   概览 JSON 结构（输出嵌套在顶层 overview 键下——不要假设字段名称是扁平的）：

   • .overview.categories[] → { name, total } — 例如，Security、ErrorProne、CodeStyle。BEFORE issues 总数是 .overview.categories[].total 的总和。
   • .overview.levels[] → { name, total } — 这些是严重性分类，但名称为 Error / High / Warning / Info。将它们映射为摘要中的严重性名称：Error → Critical，High → High，Warning → Medium，Info → Minor。
   • .overview.patterns[] → { id, title, total } — 各模式的问题数，按 jq '.overview.patterns | sort_by(-.total)' 排序。这是主要噪声信号：优先处理问题数最多的模式。
   • .overview.potentialFalsePositives[] → { name, total }。

   如果某个 CLI 版本还提供建议操作（占所有问题 10% 以上或达到各模式平均问题数的 3 倍，并附有可直接运行的禁用命令），请使用这些建议——但不要依赖该字段一定存在；上面的各模式问题数才是可靠信号。

3. 将当前云配置导入文件：

   rm -f .codacy/remote.config.json
   codacy-analysis init --remote <provider> <org> <repo> --config-file .codacy/remote.config.json
   

   （init --remote 会拒绝覆盖已存在的目标文件，因此需要 rm -f。）这会捕获 Analysis CLI 支持的工具的云配置。

4. 将工具划分为受支持工具和仅限云端工具：

   # Tools the Analysis CLI can configure via import
   codacy-analysis info 2>/dev/null
   
   # Tools currently enabled on Codacy Cloud
   codacy tools -o json 2>/dev/null | jq '[.[] | select(.settings.isEnabled == true) | .name]'
   

   任何已启用云端的工具，若不在 codacy-analysis info 列表中，就是仅限云端工具——请记录下来；其模式必须通过 Cloud CLI 修改，绝不能通过导入修改。

5. 尽早检查编码标准锁定情况。 检查仓库遵循哪些编码标准：

   codacy repo -o json 2>/dev/null | jq '.repository.repository.standards'
   

   如果存在任何编码标准，请预期其中一些工具/模式会受到它们的强制执行，无法在仓库级别修改。对于之后计划禁用或调整的任何工具或模式，先检查其 enabledBy 字段——非空的 enabledBy 表示该项受编码标准强制执行，因此禁用操作会被拒绝并返回 409：

   codacy pattern <toolName> <patternId> -o json 2>/dev/null | jq '.enabledBy'   # [] / null ⇒ repo-level (changeable); [{name: ...}] ⇒ standard-enforced (locked)
   

   提前将受标准强制执行的工具/模式归入 conflicts[]，不要等到请求被拒绝后才发现——这样可以避免无谓的反复尝试，并确保整个降噪计划如实说明实际可实现的目标。绝不要解除标准关联，也不要使用 --force。

6. 记录 BEFORE 计数：

   # Enabled tools
   codacy tools -o json 2>/dev/null | jq '[.[] | select(.settings.isEnabled == true)] | length'
   
   # Enabled patterns for supported tools (from the imported config)
   jq '[.tools[].patterns | length] | add' .codacy/remote.config.json
   

   对于仅限云端的工具，按每个工具添加其已启用模式数：codacy patterns <tool> --enabled -o json 2>/dev/null | jq 'length'——但请注意上面的分页限制：最多返回 100 条，因此已启用模式超过 100 个的仅限云端工具会被少计。BEFORE enabledPatterns 是受支持工具计数与仅限云端工具计数之和；BEFORE enabledTools 是已启用工具数。

7. 捕获仓库级描述信息，用于摘要：

   codacy repo -o json 2>/dev/null > .codacy/tmp/repo.json
   jq '.repository.repository.languages | length' .codacy/tmp/repo.json   # → languageCount
   jq '.repository.fileCount'                    .codacy/tmp/repo.json   # → fileCount
   

   将响应缓存到磁盘，以便从同一次调用中读取这两个字段。这些是仓库状态的快照，不是前后指标——它们直接作为标量放在 summary 下。

第一轮

1. 生成更高信噪比的自动配置：

   rm -f .codacy/auto.config.json
   codacy-analysis init --auto "AllSecurity,ErrorProne,Performance,BestPractice,Compatibility,Critical,High" --config-file .codacy/auto.config.json
   

   此筛选条件刻意比本地变体的宽泛集合更严格——优先选择安全性、容易出错和严重性较高的问题，避免低价值的风格噪声淹没云端。

2. 将当前云端配置合并到自动配置中（并集，远程 → 自动）：

   codacy-analysis config --merge --source .codacy/remote.config.json --dest .codacy/auto.config.json
   

   --dest 会被并集覆盖，因此 .codacy/auto.config.json 现在包含云端已启用的规则（适用于受支持的工具）以及新建议的规则。这是导入流程要使用的工作配置。

3. 首次噪声评估，依据 .codacy/tmp/overview-before.json。按问题数量从高到低逐个检查规则，并遵循噪声评估指南：

   • 从概览中建议的操作、每条规则的问题数量和误报率入手。
   • 如果某条噪声较多的规则可通过参数调整（例如 Lizard CCN/NLOC 的复杂度阈值、行长度限制），则提高参数值，而不是禁用规则。
   • 否则，如果某条规则噪声较多且无关紧要，则将其禁用。
   • 决策前若要检查某条规则的具体示例：codacy issues -p <patternId> -o json 2>/dev/null | jq '.'。

4. 应用更改（双重机制）：

   • 受支持的工具——编辑 .codacy/auto.config.json（删除要禁用的规则；编辑 parameters 以调整参数；删除工具条目以禁用工具），然后导入：

     codacy tools --import .codacy/auto.config.json -y
     

   • 仅限云端的工具——直接通过 Cloud CLI 更改：

     codacy pattern <provider> <org> <repo> <tool> <patternId> --disable
     codacy pattern <provider> <org> <repo> <tool> <patternId> --parameter threshold=20
     codacy patterns <provider> <org> <repo> <tool> --categories CodeStyle --severities Minor --disable-all
     codacy tool <provider> <org> <repo> <tool> --disable
     

   • 如果任何更改因409 冲突被拒绝——该规则/工具由 Coding Standard 强制执行，或者该工具使用自己的 Configuration File——则将其记录在 conflicts[] 中并继续处理。绝不要取消关联标准，也不要使用 --force。

5. 重新分析并等待：

   codacy repo --reanalyze-and-wait -o json 2>/dev/null > .codacy/tmp/delta-pass1.json
   

   这会在 Codacy 上触发重新分析，并轮询直至完成（最多约 20 分钟），然后返回按规则、严重性和类别统计的问题变化差异报告。如果超时，请记录下来并继续。

第二轮

1. 刷新概览并与基线比较：

   codacy issues -O -o json 2>/dev/null > .codacy/tmp/overview-pass1.json
   

   读取 delta-pass1.json，并将 overview-pass1.json 与 overview-before.json 比较，了解第一轮实际对各模式、类别和严重性做出了哪些更改。

2. 第二轮噪声评估——强化信号：

   • 减少第一轮后仍然存在的噪声模式。
   • **评估新启用的模式：**它们发现的是相关问题，还是噪声？如果某些模式对这个代码库无关紧要，或只产生误报，就将其禁用（对下文指导中描述的 Security 模式也要同样谨慎）。
   • 问题总数护栏：此技能的目标之一是减少结果数量，同时提高相关性。如果问题总数与基线相比显著增加，请决定从新启用的模式中删去哪些内容——最终数量高于基线是一个危险信号，除非符合以下情况之一：(a) 仓库最初使用的是非常精简的配置（适度增长是预期且有益的）；或 (b) 基线中的主要噪声由强制执行的编码标准导致，因此无法从仓库中移除。在情况 (b) 下，总数持平或增加是预期结果，不代表失败——请在 conflicts[] 中记录受限制的模式/工具，并建议修改标准；不要为了压低总数而过度删减真正有价值的新发现（尤其是 Security 发现）。请明智取舍：保留高价值的新发现，精简其余部分。

3. 再次应用更改，使用相同的双重机制（对受支持的工具，编辑 .codacy/auto.config.json 并运行 codacy tools --import .codacy/auto.config.json；对仅支持云端的工具，使用 codacy pattern/patterns/tool）。在 conflicts[] 中记录任何新的 409 冲突。

4. 重新分析并等待：

   codacy repo --reanalyze-and-wait -o json 2>/dev/null > .codacy/tmp/delta-pass2.json
   

最终阶段

1. 获取最终状态：

   codacy issues -O -o json 2>/dev/null > .codacy/tmp/overview-after.json
   

2. **记录 AFTER 计数：**从 codacy tools -o json 获取已启用工具数（启用数量）；已启用模式数为 .codacy/auto.config.json 中受支持工具的模式总数，加上仅支持云端的已启用模式数（按工具统计 codacy patterns <tool> --enabled 的数量，上限为 100，参见分页注意事项）；从 overview-after.json 获取问题总数以及类别/严重性细分数据。对于无法更改的工具（例如由标准强制执行的工具），直接使用其 BEFORE 计数，不要从受上限限制的模式列表中重新计数。

3. **评估结果。**如有需要，检查特定工具或模式以进行确认（codacy patterns <tool> --enabled -o json、codacy tool <tool> -o json）。请指出：

   • 效果良好的方面——噪声减少，以及新发现的相关问题（尤其是 Security 方面）。
   • 效果不佳的方面——由于工具使用自身的 Configuration File，或由于模式受 Coding Standard 强制执行，导致无法禁用的噪声模式。这些应列入 conflicts[]。
   • 模式以外的建议——产生过多噪声或可能造成未来噪声的文件或路径，可建议忽略。这些仅作为建议列入 recommendedPathsToIgnore[]。（云端文件排除项通过提交到默认分支的 .codacy.yaml 应用——请向用户说明这一点，但不要创建或修改任何文件。）

4. 将摘要写入 .codacy/configure-codacy-cloud-summary.json（架构如下），并向用户简要呈现前后对比摘要：指标表（模式、工具、问题，按类别和严重性细分）、主要改进、阻碍更改的冲突，以及建议忽略的路径。

5. 清理：

   rm -rf .codacy/tmp .codacy/remote.config.json .codacy/auto.config.json
   

摘要 JSON

写入 .codacy/configure-codacy-cloud-summary.json。before 值来自启动基线；after 值来自最终概览。

{
  "summary": {
    "languageCount": 4,
    "fileCount": 83,
    "enabledPatterns": { "before": 1000, "after": 300 },
    "enabledTools": { "before": 34, "after": 15 },
    "issues": { "before": 7000, "after": 550 },
    "issuesByCategory": {
      "Security": { "before": 56, "after": 89 },
      "ErrorProne": { "before": 140, "after": 123 },
      "CodeStyle": { "before": 3000, "after": 230 }
    },
    "issuesBySeverity": {
      "Critical": { "before": 56, "after": 89 },
      "High": { "before": 140, "after": 123 },
      "Medium": { "before": 900, "after": 210 },
      "Minor": { "before": 5904, "after": 128 }
    }
  },
  "toolChanges": [
    {
      "toolName": "Biome",
      "action": "disabled",
      "reason": "Project uses ESLint9 with local config; Biome is redundant and produced 16K false positives in TypeScript",
      "patternsAffected": 232
    },
    {
      "toolName": "AgentLinter",
      "action": "enabled",
      "reason": "New tool added for linting agent instruction files",
      "patternsAffected": 43
    }
  ],
  "patternChanges": [
    {
      "patternId": "Semgrep_python.lang.security.audit.xss.template-injection",
      "toolName": "Semgrep",
      "action": "disabled",
      "reason": "Wrong stack — pattern for Python; project is JavaScript-only",
      "deltaIssues": -45,
      "parameters": []
    },
    {
      "patternId": "Lizard_ccn-medium",
      "toolName": "Lizard",
      "action": "updated",
      "reason": "Raised threshold from 10 to 20 to match codebase complexity profile",
      "deltaIssues": -120,
      "parameters": [
        { "id": "threshold", "before": "10", "after": "20" }
      ]
    },
    {
      "patternId": "Semgrep_codacy.javascript.security.hard-coded-password",
      "toolName": "Semgrep",
      "action": "enabled",
      "reason": "New High Security pattern — detects hardcoded passwords; found 101 issues across 41 files for review",
      "deltaIssues": 101,
      "parameters": []
    }
  ],
  "recommendedPathsToIgnore": [
    {
      "path": "src/generated/**",
      "reason": "Generated code. Recommended to be ignored to avoid uncontrolled issues."
    },
    {
      "path": "src/tests/mocked.json",
      "reason": "Triggers a significant amount of security false positives (hardcoded passwords and secrets). Could be ignored."
    }
  ],
  "keyImprovements": [
    "Lizard complexity thresholds tuned to match a mature React SPA — 576 fewer noise issues while keeping genuinely complex functions flagged",
    "6 new security patterns detecting open redirects, unsafe dynamic methods, hardcoded passwords, and React href injection (119 new findings)",
    "AgentLinter added for agent instruction file quality",
    "Checkov expanded from 6 to 56 IaC security patterns"
  ],
  "conflicts": [
    {
      "toolName": "Biome",
      "conflict": "EnforcedByCodingStandard",
      "codingStandardName": "Default Security Rules",
      "reason": "Whole-tool conflict (no patternId). Biome is redundant with the project's ESLint9 yet produces most of the noise; disabling the tool was rejected with 409 because a coding standard enforces it. Recommend removing Biome from the coding standard."
    },
    {
      "patternId": "Semgrep_codacy.javascript.avoid_undefined_identifier",
      "toolName": "Semgrep",
      "conflict": "EnforcedByCodingStandard",
      "codingStandardName": "Default Security Rules",
      "reason": "Reports 1k+ low-relevance issues but is enforced by a coding standard, so it could not be disabled. Recommend disabling it in the coding standard."
    },
    {
      "patternId": "ESLint9_unused_import",
      "toolName": "ESLint9",
      "conflict": "ConfigurationFile",
      "reason": "ESLint9 uses the project's own config file, so this pattern cannot be changed from Codacy. Adjust the project's ESLint config instead."
    }
  ]
}

字段参考

• summary — 仓库描述信息以及变更前/后的计数。languageCount 是 codacy repo -o json 返回的 .repository.repository.languages 的长度；fileCount 是同一调用返回的 .repository.fileCount。这两个值都是在启动时采集一次的仓库状态快照，而非变更前/后的成对数据。enabledPatterns/enabledTools 统计 Codacy 上所有已启用的项（受支持的 + 仅限云端的）。issuesByCategory/issuesBySeverity 来自问题概览中的分类统计（应用 Error→Critical / High→High / Warning→Medium / Info→Minor 级别映射）。
• toolName（用于 toolChanges、patternChanges、conflicts）— codacy tools 显示的工具名称（即你实际存储并操作的云端标识符）。请注意，这可能与 Analysis CLI 配置中的 toolId 不同。
• toolChanges — 每个整体启用或停用的工具各有一项。action："enabled" 或 "disabled"。patternsAffected：该工具中的模式数量。
• patternChanges — 对保持启用的工具中的单个模式所做的每项变更各有一项。action："enabled"、"disabled" 或 "updated"。deltaIssues：该模式的问题数变化，即基线与最终值之差。parameters：针对已调整参数的 {id, before, after} 数组；否则为 []。不要列出作为整体工具变更一部分而添加/移除的模式——这些由 toolChanges 记录。
• recommendedPathsToIgnore — {path, reason} 数组。此处仅提供建议；不会向仓库写入任何内容。
• keyImprovements — 3–6 句易读的句子，总结影响最大的变更，适合展示给用户。
• conflicts — 曾尝试但受阻的变更数组。patternId 可选：整体工具冲突时省略（例如，标准强制启用某工具，导致该工具无法停用）；模式级冲突时则必须包含。conflict："EnforcedByCodingStandard"（包含 codingStandardName）或 "ConfigurationFile"。reason：说明报告的问题及建议的操作（编辑编码标准 / 编辑工具自己的配置文件）。

噪声评估指南

根据相关性酌情判断——停用重要模式前应更加谨慎，对低相关性噪声则可放宽标准。

• 安全模式需要格外谨慎。 如果某个 Security 模式与此代码库无关（使用了错误的技术栈或框架），或者只产生误报，那么停用它是可以的；但在停用任何安全模式前，请务必充分考虑并仔细核查。如有疑问，先检查实际示例（codacy issues -p <patternId> -o json），并优先调整参数或建议忽略路径，而非停用模式。
• 切勿轻率停用 Critical 或 High 严重级别的模式。 只有在明确属于错误技术栈或已确认是误报时，才停用它们。
• 对相关性较低的类别可以宽容些——CodeStyle、Documentation、Comprehensibility 和 Minor 严重级别的问题，如果噪声过多或与项目规范不符，应优先处理。
• 只要存在阈值，就优先调整参数而非停用（Lizard 复杂度、行长度、参数数量）；这样可以减少噪声，同时保留规则。
• 技术栈不符 → 停用。 针对仓库中未使用的语言或框架的模式纯属噪声。
• 消除重复覆盖。 当两个工具标记同一问题时，保留更精确工具的模式，并停用重复项——这样仍能覆盖该问题。
• 先检查再决定。 对于任何难以判断的模式，先列出其问题（codacy issues -p <patternId>），查看实际示例后再决定是否停用。

各工具的调优技巧

• Semgrep — 内置了适用于 30 多种语言的模式；停用仓库中未使用语言的模式，通常是减少噪声最有效的方法。可根据模式 ID 前缀（例如 python.、javascript.、java.）进行交叉检查。
• Lizard (complexity) — 提供 CCN、NLOC 和参数计数规则，并支持配置 threshold 参数。对于成熟的代码库，可提高中等阈值以匹配项目的特征，而不是停用规则，从而继续关注真正复杂的代码。
• ESLint9 / Stylelint — 如果仓库有自己的配置文件，且 Codacy 使用该文件，工具就会以 Configuration File 模式运行；无法在 Codacy 中更改其模式（这些冲突会显示为 ConfigurationFile）。请向用户说明这一点——必须在项目自己的配置中减少噪声。
• markdownlint — MD033（内联 HTML）、MD034（裸 URL）、MD024（重复标题）等规则在变更日志和生成的文档中会频繁触发。这些属于风格问题；建议忽略产生噪声的路径，而不是容忍这些噪声。