【免费下载链接】repowiseCodebase intelligence for AI and humans: code health scores, auto-generated docs, git analytics, dead code detection, and architectural decisions via MCP.项目地址https://gitcode.com/gh_mirrors/re/repowise点击查看免费下载Repowise 的死代码检测能力通过 CLI 命令repowise dead-code与 MCP 工具get_dead_code对外提供其核心思路是先用图可达性判定哪些文件/符号从未被引用再用 Git 提交历史与运行时加载风险因子修正误报最后按置信度分层输出——只有标记为safe_to_delete的发现才建议直接删除其余一律作为待调查候选。本文面向 Claude Code、Codex、OpenCode 等 Agent 用户完整讲解该命令的触发方式、全部过滤参数、置信度分层原理、误报防御机制与删除前核查流程读完即可独立完成一次零 LLM、纯索引驱动的死代码审查。技术原理图可达性 Git 上下文无需 LLMRepowise 的死代码检测不依赖大模型推理而是基于两条证据链的交叉验证静态图可达性graph reachability分析器解析仓库全部源码构建文件 → 文件 / 符号 → 符号的引用图找出入度为 0从未被任何代码引用的文件与从未被导入的导出符号Git 上下文git context结合每个文件的最近提交时间、90 天提交次数、变更年龄等元数据为置信度打分——一个长时间无人改动且无引用的文件死代码置信度更高。该能力支持 index-only 模式只要仓库已经被repowise init/repowise update索引过dead-code命令可以直接从索引存储读取上次分析的结果无需重新解析源码、无需任何模型调用。这一设计在 CLI 实现中体现得很直接——dead_code_cmd.py 的_read_stored从 SQLite 索引中直接取回init/update时存储的发现记录。只有当请求超出已存数据范围时详见下文何时回退到实时分析命令才会现场解析工作区并运行分析器。前置条件仓库必须先建立索引死代码分析建立在完整索引之上。CLI 中的执行规则是如果仓库根目录下不存在.repowise/目录说明仓库尚未索引应提示用户先运行/repowise:init即repowise init再继续并停止后续步骤。关联文档位于 plugins/claude-code/commands/dead-code.md其共享版本见 plugins/shared/commands/dead-code.md两者内容一致分别服务于 Claude Code 插件与共享命令集。init不仅建立文件/符号引用图还会以默认配置运行一遍全部四个检测器并把结果持久化。从源码看这个存储下限是RISK_CAP_CONFIDENCE即 0.4——低于 0.4 置信度的发现不会被存储见 dead_code_cmd.py 的_STORED_FLOOR。update命令负责在代码变更后增量刷新这些发现。标准工作流三步完成一次死代码审查按关联文档的规定Agent 执行死代码检查应遵循以下三步索引检查若.repowise/不存在回复 This repo isnt indexed yet. Run/repowise:initfirst. 并停止运行命令执行repowise dead-code可携带从$ARGUMENTS解析出的过滤条件见下节分组呈现按置信度分组展示发现结果明确标注哪些是safe_to_delete对低置信度发现应表述为candidates to investigate待调查候选而不是直接建议删除。第二步中命令会打印一张 Rich 表格列出 Kind发现类型、File/Symbol、Confidence置信度百分比、Ready?是否safe_to_delete打 ✓/✗、Lines覆盖行数与 Reason原因摘要并在底部汇总可清理行数与 high/medium/low 三档计数见 dead_code_cmd.py。若部分发现被置信度阈值隐藏会提示pass --min-confidence 0.0 to see them。从 Agent 参数到 CLI 过滤器完整映射关联文档规定Agent 需将用户请求中的自然语言关键词映射为具体 CLI 参数。下表是权威映射关系用户请求关键词映射后的命令指定路径repowise dead-code pathsafe仅安全删除项repowise dead-code --safe-onlyfiles仅不可达文件repowise dead-code --kind unreachable_fileexports仅未使用导出repowise dead-code --kind unused_exportpackages / zombie僵尸包repowise dead-code --kind zombie_packagestrict严格模式repowise dead-code --min-confidence 0.7其中--min-confidence的默认值是0.4即RISK_CAP_CONFIDENCEstrict 将阈值提到 0.7。--kind取值与检测器的对应关系在源码中定义得很明确见 dead_code_cmd.py 的_KIND_SWITCH与 models.py 的DeadCodeKind枚举kind 值检测器配置开关含义unreachable_filedetect_unreachable_files入度为 0、无任何代码引用的文件unused_exportdetect_unused_exports公开导出但从未被导入的符号unused_internaldetect_unused_internals未使用的私有/内部符号默认关闭zombie_packagedetect_zombie_packagesmonorepo 中无外部引用方的包完整 CLI 参数参考源码级除了过滤器映射dead-code子命令还支持以下完整参数集全部来自 dead_code_cmd.py 的 Click 定义参数默认值说明path位置参数可选—限定分析范围的目标路径要求路径存在--min-confidence0.4置信度阈值低于该值的发现被隐藏传0.0可查看全部--safe-only关闭只输出safe_to_delete的发现高置信度且无运行时加载风险因子--kind—按发现类型过滤unreachable_file/unused_export/unused_internal/zombie_package传入时会覆盖单个检测开关聚焦单一类型--formattable输出格式table默认 Rich 表格/json/mdMarkdown 报告--include-internals/--no-include-internals关闭激进模式扫描私有符号误报率更高默认关闭--include-zombie-packages/--no-include-zombie-packages开启检测 monorepo 中无外部 importers 的包默认开启--no-unreachable关闭跳过不可达文件in_degree0检测--no-unused-exports关闭跳过未使用公开导出检测--repo alias—指定工作区workspace中的仓库别名进行分析隐含工作区模式--no-workspace关闭强制单仓库模式即使从工作区调用JSON 输出非常利于 Agent 程序化消费每条发现包含kind、file_path、symbol_name、confidence、reason、safe_to_delete、risk_factors、lines、primary_owner等字段见 dead_code_cmd.py。Markdown 输出则生成# Dead Code Report报告含总发现数、可清理行数与逐条列表[kind] name — reason (confidence)并标注(cleanup-ready)阈值隐藏的发现数也会单独说明。何时回退到实时分析而非读取索引从源码逻辑看dead_code_cmd.py 的_live_reason以下两种情况索引存储无法直接回答请求命令会现场解析工作区、构建引用图并运行完整分析器请求的--min-confidence低于 0.4 存储下限索引只存了置信度 ≥ 0.4 的发现--min-confidence 0.0之类请求需要实时重算索引落后于 HEADload_state中的last_sync_commit与当前HEAD不一致提示先运行repowise update让请求立即完成。此外当工作区存在未提交改动时命令会给出黄色警告索引不包含这些改动建议提交后运行repowise update刷新发现dead_code_cmd.py。实时分析路径本身也是一条完整的管线FileTraverser遍历文件尊重init时持久化的 submodule 开关→ASTParser多语言 AST 解析→GraphBuilder构建引用图接线tsconfig路径解析器→ 框架感知合成边Django、Laravel、TYPO3 等约定式加载→GitIndexer注入 git 元数据→DeadCodeAnalyzer综合打分见 dead_code_cmd.py。置信度分层与 safe_to_delete 判定Repowise 将发现分为high / medium / low三档各档位的置信度边界在 serving.py 的TIER_FLOORS中统一定义并保证 CLI、REST 路由、MCP 工具三端口径一致档位置信度区间语义high≥ 0.7代码库中无任何引用强清理候选——删除前仍需审查尤其整文件与运行时加载文件medium0.4 ~ 0.7很可能未使用但可能存在间接引用删除前必须审查low 0.4可能通过动态导入或反射被使用先调查再判断safe_to_delete的判定规则是单调的、只降不升risk_factors.py 的effective_safe_to_delete存储标记本身为False→ 永不升级为True置信度低于SAFE_CONFIDENCE_THRESHOLD0.7→ 不视为可删除路径携带任一运行时加载风险因子config / environment / bootstrap / database / script / asset→ 不视为可删除属于REVIEW_ONLY_KINDS即unreachable_file→ 永远只是审查候选即使置信度很高也不直接判为可删除——因为整文件可能被构建脚本、清单或运行时加载器按路径引用。值得注意的一个反直觉点源码注释特别强调置信度随无人改动而上升但对按路径加载的运行时文件写一次就永远正确年龄恰恰是最不可靠的证据——它会一路老化进最高置信档而这正是最不该删的文件。这就是风险因子机制存在的原因。运行时加载风险因子软信号的补救层静态可达性只能证明没有代码导入它不能证明运行时不会加载它。risk_factors.py实现了一套纯路径检查的分类器risk_factors.py对逃过永不标记白名单的文件追加软信号标记文件名 tokenconfig/settings/setup→ configenv/environment/dotenv→ environmentbootstrap/startup/entrypoint→ bootstrapdatabase/db/schema/seed/migration→ databasesw→ assetService Worker 按 URL 注册典型永远不该删案例文件名 token 组合如service-worker拆分 token 对→ asset目录段 tokenconfig、environments、bootstrap、database、migrations、scripts/bin/tasks→ scriptpublic/static/www→ asset。携带风险因子的发现会被压到RISK_CAP_CONFIDENCE0.4上限以下——它仍会出现在报告中作为 medium/待审查候选但永远不会被标记为safe_to_delete同时附上人类可读的证据串Runtime-load risk (config, database): files of this kind are often referenced outside static imports — review before deleting。这套分类器同样可在读取阶段防御性重算历史发现的有效安全性risk_factors.py。误报防御约定豁免、框架装饰器与动态加载模式死代码检测最容易误报的是被框架/运行时以非 import 方式加载的代码。Repowise 从三个层面防御永不标记白名单_NEVER_FLAG_PATTERNSconstants.py 维护了数百条路径 glob 约定覆盖各语言生态Next.js/Remix/SvelteKit 路由文件page.tsx、layout.tsx、route.ts、middleware.ts…、Alembic 迁移脚本、manage.py/wsgi.py/asgi.py、Django*__init__.py、*.sh/*.bash、.d.ts声明、测试文件后缀*.test.ts、*_test.go、*Test.java…、生成代码*.pb.cc、moc_*.cpp、*.g.dart…、C/C apps/demos/examples/benchmarks、Gomain.go/doc.go、vendored/third_party 目录等框架装饰器识别_FRAMEWORK_DECORATORSFlask/FastAPI 路由app.route、router.get…、Djangoadmin.register、receiver、Celeryapp.task、Click/Typerclick.command、Spring/Jakarta/Quarkus/Micronaut 注解Controller、Service、Scheduled…、JUnit/JMH 测试注解等constants.py凡命中者视为框架注册、必有活路默认动态模式_DEFAULT_DYNAMIC_PATTERNS*Plugin、*Handler、*Adapter、*Middleware、*Mixin、*Command、register_*、on_*、*_view、*_endpoint、*_route、*_callback、*_signal、*_task等命名模式被默认视为可能由插件系统/事件系统动态加载constants.py。关联文档对 Agent 的指示与此一致插件、处理器、适配器、框架路由等动态加载模式看起来未使用但实际在用——Repowise 过滤了常见情形但边界情况仍然存在需要 Agent 在呈现结果时保持警惕。整个误报防御体系在 tests/unit/dead_code 下有着 50 个针对性测试文件守护如test_framework_registration_rescues.py、test_decorators_dynamic.py、test_never_flag_regex.py、test_risk_factors.py。MCP 工具get_dead_code 与按目录/按负责人汇总除了 CLI相同能力通过 MCP 工具get_dead_code暴露给 Claude Code / Codex / OpenCode 等 Agent 运行时实现见 tool_dead_code.py。关联文档特别强调需要按目录或按负责人汇总时使用get_dead_code工具的group_bydirectory或group_byowner参数——这是工具参数tool params不是 CLI flags不要把两者混为一谈。对应实现正是 serving.py 的rollup_by_directory与rollup_by_owner。MCP 工具返回的响应以同样的三档结构组织tiers支持min_confidence、范围过滤、跨仓库聚合workspace 模式下合并各仓库发现并做跨仓库修正与删除影响评估impact且_meta会附带检索预算说明。每条发现的数据结构在 models.py 的DeadCodeFindingData中定型kind、file_path、symbol_name、symbol_kind、confidence、reason、last_commit_at、commit_count_90d、lines、evidence、safe_to_delete、primary_owner、age_days、risk_factors、start_line/end_line符号级发现记录定义行区间。删除前的四项强制核查关联文档明确要求任何删除建议提出前Agent 必须完成以下核查与用户确认展示发现名称、置信度与为什么看起来是死的reason 与 evidence 字段警惕近期改动最近被触碰过的死代码更可能是误报——git 元数据中的last_commit_at/commit_count_90d/age_days正是判断依据命中此情况必须主动标记复核动态加载模式插件、处理器、适配器、框架路由类文件/符号Repowise 已过滤常见情形但边界情况仍需人工复核复核爆炸半径删除文件或导出符号前用get_risk(targets[...])双重检查影响范围——确认删除不会波及其他仍被引用的代码。第四条直接呼应了仓库中风险/爆炸半径分析能力get_riskMCP 工具见 risk.ts 相关的类型定义与 docs/architecture/change-risk.md 对变更风险的阐述。工作区与多仓库模式在工作区workspace模式下dead-code默认分析主仓库primary repo通过--repo alias可切换到指定仓库--no-workspace可强制单仓库模式。需要说明的是跨仓库死代码检测目前尚不支持——应按仓库逐一运行dead_code_cmd.py。MCP 的get_dead_code则支持 workspace 模式的跨仓库聚合与修正两者能力边界不同按场景选用。小结把死代码审查变成可复现的确定性流程Repowise 死代码检测把传统上依赖人工与 LLM 猜测的清理工作变成了一个可复现、可过滤、可量化的确定性流程init建索引 →dead-code读发现 → 按--kind/--min-confidence/--safe-only过滤 → 用safe_to_delete与风险因子区分可删与待查 → 删除前用get_risk复核爆炸半径。整条链路无需 LLM适合 Agent 在编辑代码前作为安全护栏反复调用更多端到端用例可参考 examples/dead-code/README.md历史演进记录见 docs/layers/DEAD_CODE.md 与 docs/architecture/dead-code.md。赞分享【免费下载链接】repowiseCodebase intelligence for AI and humans: code health scores, auto-generated docs, git analytics, dead code detection, and architectural decisions via MCP.项目地址https://gitcode.com/gh_mirrors/re/repowise点击查看免费下载相关推荐Repowise Dead Code基于图可达性与 Git 上下文的死代码检测实战指南Repowise Dead Code基于图可达性与 Git 上下文的死代码检测实战指南 导读 本文讲解 Repowise 的 dead code 命令一种不用 Repowise 深度清理死代码图可达性检测、置信度分层与安全删除实战用 Repowise 深度清理死代码图可达性检测、置信度分层与安全删除实战 Repowise 的 repowise dead code 命令基于图可达性grRepowise 死代码清理实战基于图分析的置信度分级、安全检查与安全删除流程Repowise 死代码清理实战基于图分析的置信度分级、安全检查与安全删除流程 本文介绍 Repowise 如何通过图分析graph analysis与上一篇如何高效使用HTTP请求定时任务框架变量系统3大技巧终极指南下一篇在 Cloud Endpoints 上部署 Python gRPC 服务getting-started-grpc 完整快速上手指南创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考