dead-code-check（死代码检测）Skill 是什么？如何安装？

死代码检测Skill：一键为多语言项目配好死代码检查，抓住“写了却没接上”的功能

定位清晰：dead-code-check（死代码检测Skill）不是又一个代码分析器，而是为 loom 计划的验证环节“生成死代码检测配置”的专家型技能，直接产出可复制的命令与 YAML 片段。
五语言覆盖：Rust（clippy）、TypeScript（ts-prune）、Python（vulture）、Go（staticcheck）、JavaScript（unimported）各自给出安装命令、检测命令、失败模式与忽略模式。
双重用途：既做“接线验证”（功能实现了但没被调用、路由没挂载、CLI 命令没注册），也做“代码质量”（清理重构遗留、无用导入与变量）。
落地成本低：技能内自带 acceptance / truths / wiring 三层写法示例、误报处理清单与 working_dir 路径规则，复制粘贴后按项目结构调整即可。
避免踩坑：明确提醒不要把三重反引号写进 YAML 描述、grep 要用 -q、退出码工具可直接当验收条件使用。

1. 该技能叫什么？如何下载安装 AI 技能提升开发效率？

技能中文名：死代码检测Skill 技能英文名：dead-code-check 技能ID：13513

它解决的问题非常具体：当你用 AI 编码代理或分阶段计划（loom 计划）推进一个功能时，最容易出现的失败不是“编译不过”，而是代码写完了却从未被调用——函数安安静静躺在文件里、模块导出了但没人导入、CLI 子命令没注册进命令枚举、路由没挂载。这类“不完整接线”问题，普通单元测试往往覆盖不到，因为测试通常只测那些已经被调用的代码。dead-code-check 的作用，就是把“死代码检测”这件事标准化：告诉你每种语言该用什么工具、怎么装、命令怎么写、失败输出长什么样、哪些结果是故意保留的、以及如何把这些检查写进 loom 计划的验收标准（acceptance）、真理字段（truths）和接线检查（wiring）里。

安装思路与步骤（通用流程，具体入口与命令以官方说明为准）：

安装前提：你使用的 AI 编程助手/技能平台支持技能（Skill）机制，并已具备文件读写与命令执行能力。该技能允许的工具为 Read、Grep、Glob、Edit、Write、Bash，也就是说它既能读取你的项目结构，也能写入或修改计划配置文件，还能执行本地检测命令。
找到技能入口：在平台的技能市场或技能列表中，用技能名称「dead-code-check」或中文名「死代码检测」检索；如平台支持按 ID 检索，可直接使用技能ID 13513 定位。
安装/启用：按平台提供的安装方式启用技能（一键安装、复制技能链接导入或在工作区启用，实际做法以官方说明为准）。
确认已生效：在对话中说出触发关键词，例如「帮我给这个 Rust 项目加死代码检测」「检查未使用导入和未使用函数」「死代码检查怎么配进验收标准」。若技能已生效，回复应围绕具体语言的检测命令、失败模式、忽略模式和 YAML 模板展开，而不是泛泛而谈“建议做代码审查”。
补一次工具检查：技能本身不包含检测器，真正干活的还是各语言工具。落地前先按“工具安装检查清单”核对：Rust 用随 rustup 提供的 cargo/clippy；TypeScript 与 JavaScript 需要 ts-prune、unimported；Python 需要 vulture；Go 需要 staticcheck。建议把这些安装步骤写进项目的 knowledge-bootstrap 阶段或 README，避免每个新环境重装一遍。

2. 该技能的主要功能和特点

按语言给方案，而不是给一句“用 lint”：Rust、TypeScript、Python、Go、JavaScript 五套独立配置，每种都包含推荐命令、失败模式关键词、忽略模式与配置文件样例。
命令可直接照抄：如 Rust 的 cargo clippy -- -D warnings、RUSTFLAGS="-D dead_code" cargo build 2>&1；TypeScript 的 npx ts-prune --error；Python 的 vulture src/ --min-confidence 80；Go 的 staticcheck ./...；JavaScript 的 npx unimported。
失败模式清单化：例如 Rust 的 dead_code、unused import、never used、never constructed；Python 的 unused function、unreachable code；Go 的 U1000、U1001。这让“检查是否通过”可以写成机器可判定的条件。
忽略模式内建：入口点、测试代码、框架魔法（装饰器、派生宏）、公共 API/库导出、功能标志与条件编译、动态加载与反射——六类误报场景都给出对应处理方式。
产出 loom 计划片段：给出 acceptance（验收标准）、truths（真理字段）、wiring（接线检查）三种写法的可粘贴模板，覆盖“宽松检查”和“精确检查”两种严格度。
强调路径正确性：反复提醒 working_dir 必须指向构建工具期望的位置（Cargo.toml、package.json、go.mod 所在目录），并说明所有路径都相对于 working_dir 解析。
YAML 写作规范：禁止在 YAML 描述里用三重反引号（会破坏解析）；用 grep -q 静默匹配；用 ! 取反表示“找不到即通过”。
与普通工具的区别：普通工具只告诉你“有死代码”，这个技能告诉你“该怎么把死代码检查变成计划里的一道质量门”，并且明确死代码检测是强信号但非决定性证据，需要和接线检查、功能验证组合成三重检查。

3. 如何使用该技能？

步骤 1：触发技能并说明上下文。 在对话中给出项目语言、目录结构和当前阶段，例如：“这是一个 Rust 项目，代码在 loom/ 目录下，我想在集成验证阶段加死代码检查，应该怎么写 acceptance 和 truths？”也可直接用触发词“死代码检测”“未使用导入”“接线验证”。

步骤 2：确认检测工具是否就位。 按技能给出的清单安装：TypeScript 用 npm install --save-dev ts-prune 或 bun add --dev ts-prune；Python 用 pip install vulture 或 uv add --dev vulture；Go 用 go install honnef.co/go/tools/cmd/staticcheck@latest；JavaScript 用 npm install --save-dev unimported 或 bun add --dev unimported。

步骤 3：选择严格度。 只想要“尽量多抓问题”，就把工具放进验收标准（acceptance），例如 cargo clippy -- -D warnings；想精确断言“零死代码警告”，就写进真理字段（truths），例如 ! cargo clippy -- -D dead_code 2>&1 | grep -q 'warning:'。

步骤 4：配置忽略模式。 TypeScript 建立 .tsprunerc（如 {"ignore": "index.ts|types.d.ts"}）；Python 在 pyproject.toml 写 [tool.vulture]，设置 min_confidence、paths、ignore_names；Go 用 .staticcheck.conf（如 checks = ["all", "-ST1000"]）；JavaScript 用 .unimportedrc.json 配置 entry、extensions、ignorePatterns。

步骤 5：设置正确的工作目录。 如果项目结构是 .worktrees/my-stage/loom/Cargo.toml，则在阶段配置中设 working_dir: "loom"；写成 . 会直接因为找不到 Cargo.toml 而失败。

步骤 6：与接线检查组合。 在 integration-verify 阶段同时加入三类条件：死代码检查（cargo clippy -- -D warnings）、接线模式（如 source: "src/main.rs"、pattern: "Commands::NewCommand"）、功能验证（如 loom new-command --help）。

输入示例：

“Python 数据管道项目，源码在 pipeline/src/，测试用 pytest，想在集成验证阶段加死代码检查，并且要能抓出未被调用的函数。”

输出说明（技能会给出的内容形态）：

stages:
  - id: verify-pipeline
    name: "验证数据管道"
    stage_type: integration-verify
    working_dir: "pipeline"
    acceptance:
      - "pytest"
      - "vulture src/ --min-confidence 80"
      - "mypy src/"
    truths:
      - "! vulture src/ --min-confidence 80 | grep -q 'unused function'"
      - "test -f src/pipeline/transform.py"
    wiring:
      - source: "src/main.py"
        pattern: "from pipeline.transform import TransformStage"
        description: "转换阶段在主管道中导入"

同时会说明该项目的典型失败输出（unused function、unused import、unreachable code）、需要忽略的对象（__init__.py、__all__、魔术方法、测试夹具）以及 --min-confidence 取值对误报率的影响。

4. 同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
死代码检测Skill（dead-code-check）	为 loom 计划生成死代码检测配置的“配置专家”	五语言检测命令、失败模式、忽略模式、异常场景处理、acceptance/truths/wiring 模板	需先启用技能机制，再单独安装各语言检测工具；无代码改动侵入	分阶段实现计划的质量门、集成验证、接线验证	优势：跨语言统一口径，直接产出可粘贴 YAML，强调误报与工作目录；不足：不替代检测器本身，需自行维护工具版本
语言原生检查器（cargo clippy / staticcheck / vulture / ts-prune / unimported）	底层检测工具	检出未使用代码、未使用导入、未解析导入等	各自安装，命令与忽略方式互不相同	单语言项目日常检查	优势：精准、生态成熟、可接入任意 CI；不足：跨语言配置知识分散，误报处理需逐个踩坑，缺少与计划阶段的结合范式
通用代码质量平台（如 SonarQube 类工具）	全栈代码质量与安全扫描	重复代码、复杂度、漏洞、代码异味等多维规则	需部署服务端、配置扫描器与项目令牌，门槛较高	团队级持续质量看板与合规审计	优势：规则全、报表强、可做趋势管理；不足：接入成本高，死代码只是其中一类规则，对“功能是否接线”的判断不敏感
编辑器/IDE 内置检视	编写时的即时提示	未使用变量、未使用导入、不可达代码灰显	装上 IDE 即用，零配置	个人开发时的即时清理	优势：反馈最快、零成本；不足：不可作为 CI 或计划的强制门禁，跨文件与跨模块的孤立代码容易漏检

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

场景一：AI 编码代理分阶段实现新功能（最常见）。 角色：使用分阶段计划的开发者。痛点是每个阶段都“测试通过”，但最终功能在真实入口里根本调不到。使用方式：在 integration-verify 阶段把 cargo clippy -- -D warnings 放进 acceptance，把 ! cargo clippy -- -D dead_code 2>&1 | grep -q 'warning:' 放进 truths，再加一条 wiring 断言命令已在 CLI 枚举中注册。实际体验：上手几乎零成本，因为技能直接给出可粘贴片段；效果上最容易抓到“模块写了但 mod 没导出”“命令枚举没注册”这类问题；注意事项是必须先设对 working_dir，否则报错信息会指向“找不到 Cargo.toml”，让人误以为是工具没装。

场景二：TypeScript 后端 API 的功能收尾。 角色：Node/TypeScript 服务端开发者。痛点是重构后留下大量“导出但无人引用”的函数，以及 barrel 文件导致的误报。使用方式：bunx ts-prune --error 进 acceptance，bunx ts-prune | wc -l | grep -q '^0$' 进 truths，并用 .tsprunerc 忽略 index.ts 与类型声明文件。实际体验：--error 让“发现未使用导出即失败”变得非常干脆；主要注意点是桶文件与纯类型导出会产生噪声，忽略配置不到位会频繁误报。

场景三：Python 数据管道清理与接线验证。 角色：数据工程师。痛点是脚本越来越多，某些转换函数早已被新流程替代却仍在仓库里。使用方式：vulture src/ --min-confidence 80 进验收标准，ignore_names 里加上 setUp、tearDown、test_*。实际体验：--min-confidence 是最关键的旋钮，调低会涌出大量误报，调高则更稳但可能漏检；建议从中等阈值起步再逐步收紧。

场景四：Go 微服务上线前的最后一道门。 角色：后端工程师。痛点是接口实现与未被调用的私有函数混在一起。使用方式：staticcheck ./... 进 acceptance，truths 里分别否定 U1000 与 is unused。实际体验：检查覆盖面比单纯死代码更广，能顺手带出其他静态问题；注意库包里的导出符号属于公共 API，不应视为死代码，构建标签后的代码也需要启用对应变体再检查。

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

把“隐性缺陷”变成“可判定条件”：功能没接线是 AI 辅助开发中最隐蔽的失败模式，死代码检查把它转化为一条命令的退出码，让计划阶段可以自动判定通过或失败。
省掉跨语言试错时间：五种语言的工具选型、安装命令、失败关键词、忽略写法一次给全，避免“每种语言重新查一遍文档”的重复劳动。
降低误报治理门槛：入口点、测试、装饰器与派生宏、公共 API、功能标志、动态加载六类误报场景及对应解法成体系给出，减少“检查一上线就被噪声淹没”的情况。
减少长期维护负担：重构与功能下线后遗留的孤立代码越早清理越便宜，把清理动作固化进流程比事后专项治理成本低得多。
形成可复用的质量资产：acceptance + truths + wiring 的三重检查范式可以沉淀为团队模板，新项目直接套用，检查标准不再依赖个人经验。

7. 常见问题 FAQ

Q1：这个技能怎么安装？装完怎么确认生效？ 在技能平台中按名称「dead-code-check」或中文名「死代码检测」检索并启用，支持 ID 检索时可用 13513 定位，具体入口与步骤以官方说明为准。验证方式是抛出触发词，例如“帮我配死代码检查”，若回复给出具体语言的命令、失败模式和 YAML 模板，说明已生效。注意技能本身不含检测器，各语言的检测工具需另行安装。

Q2：它是收费的吗？ 技能详情中未包含任何价格信息，是否收费取决于你所在技能平台的计费策略，以官方说明为准。需要额外留意的是底层检测工具（如 clippy、staticcheck、vulture、ts-prune、unimported）各自有独立的开源许可与使用条款。

Q3：适合谁用？前后端都做的小团队值得装吗？ 适合正在使用分阶段实现计划或 AI 编码代理、并且项目横跨多种语言的开发者与团队。小团队收益尤其明显：不需要为每种语言单独摸索忽略配置，直接复用技能给出的模板即可；如果只维护单一语言且已有成熟 CI 规范，收益主要体现在误报处理和计划集成这两块。

Q4：和直接在 CI 里写 clippy / staticcheck 有什么区别？ 底层命令是同一套，区别在于“怎么配、怎么判、怎么排噪”。技能提供的是配置方法论：验收标准与真理字段该选哪种、working_dir 如何设置、YAML 里不能写三重反引号、grep 要用 -q、退出码工具可直接作为门禁，以及死代码检测需要与接线检查、功能验证组合才能可靠捕获集成问题。

Q5：误报太多怎么办？会不会把公共 API 也报成死代码？ 按技能给出的忽略模式处理：Rust 用 #[allow(dead_code)] 并注意 pub 项与 #[cfg(test)] 的默认排除；Python 用 __all__ 标记公共 API 并调整 min_confidence；TypeScript 用 .tsprunerc 忽略桶文件与类型声明；Go 的库包导出符号默认不算死代码。若项目使用了功能标志或构建标签，检查时先启用相关特性，避免把暂时关闭的代码误判为死代码。