dialyzer-configuration（Dialyzer配置技能）Skill 怎么配置？

Dialyzer配置技能：让 Erlang/Elixir 静态类型分析一次配置到位

是什么：一个面向 Erlang/Elixir 项目的 Dialyzer 配置知识技能，覆盖忽略文件、mix.exs 配置、PLT 管理、分析标志与 CI 集成。
解决什么：解决"知道 Dialyzer 有用，但不知道 ignore 文件怎么写、PLT 放哪、flag 该开哪些、CI 里怎么跑"的落地难题。
怎么用：属于被动触发型技能（不可手动调用），安装后在处理 Dialyzer 相关任务时会自动被引用，直接以自然语言下达配置任务即可。
最大亮点：把分散在官方文档、社区博客里的配置片段，收敛成一套可直接抄用的配置范式与最佳实践。
适合谁：Elixir/Phoenix 后端团队、维护遗留 Erlang 项目的工程师、需要在 CI 中引入类型检查的技术负责人。

该技能叫什么？如何一键安装 AI 技能提升开发效率？

技能中文名：Dialyzer配置技能Skill 技能英文名：dialyzer-configuration 技能ID：13874

它要解决的问题非常具体：Dialyzer 是 Erlang 与 Elixir 生态里的静态分析工具，能识别类型错误、不可达代码和不必要的测试等"软件差异"，但它的配置面相当零散——忽略警告的写法有两套（dialyzer.ignore-warnings 与 .dialyzer_ignore.exs）、PLT 文件的构建方式有多种、分析标志（flags）一开就可能是成百上千条警告。很多团队因此卡在"第一次成功跑通"之前。这个技能把配置文件格式、常见配置选项、最佳实践和典型模式沉淀为可复用的知识，让 AI 助手在协助你时直接给出对症的配置方案。

关于"一键安装"，需要先说明本技能的一个关键属性：技能元信息中标注了 user-invocable: false，即它不是一个由用户手动键入命令调用的技能，而是一个在特定任务上下文（配置 Dialyzer 做类型检查与静态分析）中被自动引用的能力。同时它的 allowed-tools 为空，意味着它本身不额外申请工具权限，定位是"知识与配置范式的提供者"，而非执行器。

因此，推荐的落地路径如下（具体入口与命令以你所使用平台的官方说明为准）：

确认前提：你使用的 AI 编程助手或技能平台支持技能安装；本地已有可运行的 Erlang/Elixir 项目与 Mix 构建环境。
查找技能：在平台的技能市场/技能库中，通过技能ID 13874 或英文名 dialyzer-configuration 检索。
安装：按平台提供的安装方式（通常为项目级或账号级安装，具体以官方说明为准）把技能添加到你的工作区。
验证是否生效：在对话中直接提出一个 Dialyzer 相关任务，例如"帮我写一份 .dialyzer_ignore.exs，忽略 lib/generated_code.ex 的 no_return 警告"，观察回答是否给出与技能内容一致的结构化配置。若回答命中忽略文件格式与示例，说明技能已被正确引用。
建立习惯：把"配置 Dialyzer"“梳理 PLT”"接入 CI"这类任务统一走技能通道，避免每次重新拼凑配置。

该技能的主要功能和特点

多形态配置文件输出：同时掌握 dialyzer.ignore-warnings（按文件行号忽略具体警告）与 .dialyzer_ignore.exs（支持正则、按模块与警告类型忽略）两种忽略机制，能根据项目规模给出取舍建议。
mix.exs 集成配置：可产出完整的 dialyzer 配置块，包含 plt_add_apps、plt_core_path、plt_file、flags、ignore_warnings、list_unused_filters 等键。
PLT 管理知识：覆盖 plt_add_apps（追加应用）、plt_core_path（核心 PLT 目录）、plt_file（自定义 PLT 位置）、plt_add_deps（依赖纳入策略：:app_tree、:apps_direct、:transitive）四类选项，直击"PLT 构建慢、CI 每次都重建"的痛点。
分析标志解读：解释 :error_handling、:underspecs、:unmatched_returns、:unknown、:overspecs 各自检查什么，帮助使用者按阶段逐步放开，而不是一次性开满。
过滤治理能力：通过 ignore_warnings 指定忽略模式文件，并用 list_unused_filters 暴露"已经失效的忽略规则"，让警告白名单不至于腐烂。
最佳实践沉淀：增量 PLT 构建、逐步采用、CI 集成、完善的 @spec 注解、记录有意的忽略——五条实践直接对应团队协作中的常见失误。
CI 与脚本模式：提供 mix dialyzer --format github 这类输出格式化用法，以及 GitHub Actions 步骤写法与自定义检查脚本的结构。

和"直接搜文档"相比，它的差异在于：输出是面向当前项目上下文的成稿配置，而不是需要你自己拼接的碎片；和纯执行型工具相比，它的差异在于：它不替你跑分析，而是确保你跑分析的方式是对的。

如何使用该技能？

由于技能不可手动调用，使用方式是"用自然语言描述任务 + 提供项目上下文"，技能会自动被引用。以下为典型分步流程：

明确目标与现状。先告诉助手项目形态，例如：“这是一个 Phoenix 项目，依赖较多，CI 上跑 Dialyzer 每次都要重建 PLT，超过十分钟。”
索要 mix.exs 配置。输入示例：“帮我在 mix.exs 里加上 dialyzer 配置，PLT 放到 priv/plts，开启错误处理与未匹配返回值检查，忽略文件用 .dialyzer_ignore.exs，并显示未使用的过滤规则。” 输出说明：应得到类似下述结构的配置块（取自技能内容）：

def project do
  [
    app: :my_app,
    dialyzer: [
      plt_add_apps: [:mix, :ex_unit],
      plt_core_path: "priv/plts",
      plt_file: {:no_warn, "priv/plts/dialyzer.plt"},
      flags: [:error_handling, :underspecs, :unmatched_returns],
      ignore_warnings: ".dialyzer_ignore.exs",
      list_unused_filters: true
    ]
  ]
end

生成忽略规则。输入示例：“lib/generated_code.ex 有 no_return 警告，老代码目录 lib/legacy/ 里全是 unknown_function，分别怎么忽略？” 输出说明：会得到按元组与正则两种写法区分的列表，例如：

[
  {"lib/generated_code.ex", :no_return},
  {~r/lib\/legacy\/.*/, :unknown_function}
]

处理单个位置的精确忽略。若只想屏蔽某一行的一条警告，可用 dialyzer.ignore-warnings 的逐行格式，例如 lib/my_module.ex:42:pattern_match_cov。
控制依赖范围（可选）。当项目只依赖少量库时，通过 plt_add_deps 选择 :app_tree、:apps_direct 或 :transitive，减少 PLT 体积。
接入 CI。输入示例：“给出 GitHub Actions 里运行 Dialyzer 的步骤。” 输出说明：得到运行 mix dialyzer --format github 的步骤片段，使告警直接显示在 PR 的变更行上。
按环境隔离依赖（可选）。在 mix.exs 中按环境引入分析依赖，示例：

if Mix.env() in [:dev, :test] do
  {:dialyxir, "~> 1.4", only: [:dev, :test], runtime: false}
end

校验与迭代：先小范围开启 flag，观察警告数量；再用 list_unused_filters: true 清理无效忽略；最后把 @spec 注解补齐作为长期任务。

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
Dialyzer配置技能（本技能）	Dialyzer 配置知识与范式提供的 AI 技能	输出 ignore 文件、mix.exs 配置、PLT 策略、flags 选择、CI 模式与最佳实践	需在支持技能的平台安装；不可手动调用，随任务上下文自动引用	首次接入 Dialyzer、警告治理、CI 加速、配置评审	优势：配置成稿快、范式统一、覆盖忽略与 PLT 两条主线；不足：不执行分析，仍需本地环境配合
Dialyxir	Elixir 生态的 Dialyzer Mix 任务封装	提供 Mix 任务入口、配置项解析、格式化输出	需自行添加依赖并配置，门槛中等	项目日常静态分析、CI 运行	优势：执行能力强、生态成熟；不足：配置项仍需自行设计与调优
原生 Dialyzer（Erlang/OTP 自带）	底层静态分析器	类型差异检测、不可达代码识别	配置繁琐，需手工维护 PLT 与参数	纯 Erlang 项目、深度定制	优势：能力最底层、无额外依赖；不足：命令行参数复杂，缺少 Elixir 友好的配置层
Credo	Elixir 代码风格与一致性检查	风格、复杂度、一致性规则	依赖引入即可，门槛低	代码规范与可读性治理	优势：上手快、可读性强；不足：不擅长类型层面的差异检测，与 Dialyzer 互补而非替代

从表中可以看出：Dialyxir 解决"能不能跑"，原生 Dialyzer 解决"能力上限"，Credo 解决"风格一致性"，而本技能解决的是**“怎么配置才对、才不痛”**这一层。实际项目中，把本技能与 Dialyxir 搭配使用是最常见的组合。

该技能的典型应用场景与实际体验情况

场景一：Phoenix 团队首次引入 Dialyzer 角色是后端技术负责人，痛点是团队里没人真正配过 Dialyzer，PR 上又急需类型层面的把关。使用方式是让助手基于项目结构直接产出 mix.exs 配置与初始忽略文件。实际体验：上手难度低，配置块可直接粘贴；需要注意的是首次 PLT 构建耗时较长，建议先按技能建议做增量 PLT 与独立目录，避免污染全局。

场景二：遗留项目警告爆炸的治理 角色是维护老代码的工程师，痛点是开一次 Dialyzer 就报出成百上千条警告，无法收敛。使用方式是先用正则批量忽略历史目录，再通过 list_unused_filters: true 定期清理。实际体验：效果显著，能把"从零到可用的告警基线"这件事从几天压缩到一次会话；注意忽略规则要写注释说明原因，避免变成永久性技术债。

场景三：CI 流水线提速 角色是 DevOps/平台工程师，痛点是每次 CI 都重建 PLT，流水线时间被拉长。使用方式是把 plt_core_path、plt_file 指向可缓存的目录，并按 GitHub Actions 步骤运行 mix dialyzer --format github。实际体验：配置思路清晰，缓存目录与文件路径的对应关系一目了然；注意缓存失效策略要跟依赖锁文件绑定，否则会出现陈旧 PLT 导致的诡异结果。

场景四：多应用/伞形项目的依赖范围控制 角色是负责多个子应用的架构师，痛点是 PLT 里塞了太多无关应用。使用方式是结合 plt_add_apps 与 plt_add_deps 的三种策略做取舍。实际体验：这类问题以往只能靠试错，现在能直接获得可选项与适用边界；注意不同策略的构建时间与召回率需要自行实测对比。

该技能能为用户带来的价值

降低入门门槛：Dialyzer 的学习曲线主要不在"跑"，而在"配"。技能把配置层的关键决策（PLT 放哪、flag 开哪些、忽略怎么写）直接给出答案，让第一次接入从"查半天文档"变成"一次对话"。
提升配置质量：提供的是被验证过的实践组合——增量 PLT、逐步采用、CI 集成、完善的 @spec、记录有意的忽略，避免团队踩到"一次性开满 flags 然后放弃"的典型坑。
压缩治理周期：警告白名单与正则忽略的组合，加上未使用过滤器的自检能力，让"历史告警基线"的建立与维护具备可持续性，而不是越堆越乱。
加速反馈闭环：--format github 与 GitHub Actions 的写法，把静态分析结果推到代码评审现场，问题在合并前暴露，修复成本最低。
长期价值：配置一旦沉淀进仓库，就变成了团队共享的工程资产——新人无需重新摸索，评审时有统一口径，静态分析从"某个人会用的工具"变成"团队默认的质量门禁"。

常见问题 FAQ

Q1：这个技能怎么安装？为什么我在命令里调不到它？ A：它是被动触发型技能（元信息标注 user-invocable: false），不提供手动调用命令，安装后在涉及 Dialyzer 配置的任务中自动被引用。安装入口与具体命令以你所使用平台的官方说明为准，可通过技能ID 13874 或英文名 dialyzer-configuration 检索定位。

Q2：使用这个技能收费吗？ A：技能详情本身未包含任何定价信息，是否收费取决于承载它的平台策略，请以官方说明为准。技能自身 allowed-tools 为空，不额外引入第三方工具调用，因此不会产生额外的工具调用成本。

Q3：它和 Dialyxir 是什么关系，需要二选一吗？ A：不需要二选一，两者是不同层次的东西。Dialyxir 提供 mix dialyzer 这样的执行入口，本技能提供"如何配置这一入口"的知识与范式（包括 mix.exs 中的 dialyzer 配置块、忽略文件结构等）。常见做法是引入 Dialyxir 负责执行，用本技能确定配置方案。

Q4：忽略文件到底用 dialyzer.ignore-warnings 还是 .dialyzer_ignore.exs？ A：取决于颗粒度需求。前者适合按"文件:行号:警告类型"做精确的单点忽略，例如 lib/my_module.ex:42:pattern_match_cov；后者支持元组与正则，适合按模块或整目录批量忽略，例如 {~r/lib\/legacy\/.*/, :unknown_function}。实践中两者可以并存，但建议把规则集中记录并定期用 list_unused_filters 清理。

Q5：适合谁用？什么情况下不建议用？ A：适合正在或计划对 Erlang/Elixir 项目做静态分析的人——后端工程师、技术负责人、平台/DevOps 工程师。如果项目还没有可运行的 Mix 构建环境，或团队尚未打算引入 @spec 注解，建议先把基础工程与类型规范补齐，再引入 Dialyzer 配置，否则容易陷入"配了一堆忽略规则"的无效循环。