Depwire 场景聚焦：用确定性依赖图阻止 AI Agent 盲目重构
AI 编程助手越来越聪明，但它们仍然有一个根本的盲区：不知道代码架构。
你让 Claude Code 删掉一个工具文件，它删得干净利落，毫无警告。然后你跑构建，30 个文件断裂。Claude 根本不知道——它只看到了一个文件，没看到那 30 个下游消费者。
这不是模型的问题，是上下文的问题。AI 在盲目飞行。
这周我深度体验了一个叫 Depwire 的开源工具——它不是又一个 AI 编码助手，而是 AI 编码助手和代码库之间的上下文与安全层。Depwire 用 tree-sitter 构建了一个确定性的依赖图（不是 RAG、不是向量数据库、不是概率估算），通过 23 个 MCP 工具让 AI Agent 在动代码之前就知道后果。
三分钟上手
Depwire 是一个 CLI 工具，一条命令安装：
npm install -g depwire-cli
安装后有三个核心命令：
depwire whatif # 改动前模拟影响范围 depwire security # 发现 AI 引入的安全漏洞 depwire viz # 可视化整个架构
以 TypeScript 项目 honojs/hono（352 个文件、6,462 个符号）为例，depwire whatif 模拟删除一个工具函数，几毫秒内就给出了精确的影响报告：29 个受影响节点、30 个断裂的 import、零架构健康分下降。
这个精度来自 tree-sitter——不是 LLM 的最佳猜测，而是编译器级别的确定性分析。
为什么不是 RAG、不是构建图？
你可能在想：这和传统的代码分析工具有什么不同？
不是 RAG。Depwire 不做嵌入、不计算相似度、不用向量数据库。它遍历精确的依赖图，返回的是精确的文件列表——不是「看起来像」的估算答案。
不是构建图。Nx、Turborepo 这类工具跟踪的是包级别的依赖关系，用于构建缓存。Depwire 跟踪的是符号级别的依赖——每个函数、每个类、每个 import 关系。这才是模拟「删除这个函数会牵连哪些文件」所需要的精度。
五种模拟操作
Depwire 的 whatif 子命令支持五种变更模拟：
depwire whatif . --simulate delete --target src/utils/encode.ts depwire whatif . --simulate move --target src/utils/encode.ts --destination src/core/encode.ts depwire whatif . --simulate rename --target src/utils/encode.ts --destination src/utils/encoder.ts depwire whatif . --simulate split --target src/services/auth.ts --symbols "validateToken,refreshToken" depwire whatif . --simulate merge --target src/utils/helpers.ts --merge-target src/utils/formatters.ts
在模拟时，不会真正读写文件——所有运算在内存中完成，零 I/O、零副作用。不加 --simulate 参数会打开浏览器 UI，左右对照当前状态和模拟后状态的弧线图。
对于多模块项目（Maven、Gradle），Depwire 能跨模块解析依赖关系。测试中，google/guice（13 个模块的 Java DI 框架）模拟删除核心文件时，准确检测到了 124 个断裂的 import，其中 106 个是跨模块依赖。
给 AI 装架构眼睛：23 个 MCP 工具
Depwire 最实用的功能是 MCP 服务器集成。23 个 MCP 工具让 AI 编码助手在动代码之前就能获取架构上下文：
- what_if — 让 Claude Code 或 Cursor 在重构前先查询影响范围
- verify_change — 验证修改是否安全，检查断裂 import、新循环依赖、健康分变化和安全问题
- security_scan — 扫描代码安全风险（10 个检查类别）
- structural_diff — 对比两个 commit 之间的结构变化
- health_score — 查询当前架构健康分
举个实际工作流：你在 Cursor 中对 Terminal 说「重构 auth 模块」，Cursor 可以在执行前调用 verify_change MCP 工具，Depwire 返回一份变更报告：健康分变化、断裂 import 数量、新安全发现。Cursor 拿到这份报告后，要么自动修复问题，要么回退操作。
这种「先查后改」的模式，从根本上解决了 AI 盲目重构的问题。
安全扫描：架构感知的 SAST
一般的 SAST 工具会报一堆安全发现，但你分不清哪些是真正可被攻击的。Depwire 的 security_scan 有「图感知严重度提升」：一个中等严重度的漏洞，如果从 MCP 工具入口或 HTTP 路由可达，会被自动提升为严重级。
depwire security . # 全仓库扫描 depwire security . --target src/auth.ts # 单文件 depwire security . --format sarif # GitHub Security tab 集成 depwire security . --fail-on high # CI 门禁
对 honojs/hono 扫描结果：6 个严重、19 个高、14 个中、1 个低。覆盖 10 个检查类别——依赖 CVE、进程安全、凭据管理、路径安全、认证安全、输入验证、信息泄露、加密弱点、输出编码安全、架构级风险。
PR 代码审查：每个 PR 都能看见架构影响
Depwire 提供 GitHub Action，每次 PR 自动发布依赖影响报告：
name: Depwire PR Impact
on:
pull_request:
branches: [main]
jobs:
depwire:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- uses: actions/setup-node@v4
with:
node-version: '20'
- uses: depwire/depwire-action@v1
with:
github-token: ${{ secrets.GITHUB_TOKEN }}
reviewer 在 PR 页面就能看到哪些符号被修改、哪些 import 链断裂、健康分升降了多少。甚至可以设置门禁——健康分下降超过 5 分时自动阻止合并。
适合谁用
Depwire 的价值在项目规模达到一定程度时才显现出来：
- 50 个文件以内的项目：手动管理就够了
- 100-500 个文件的项目：AI 重构开始频繁出错，需要架构感知层
- 500+ 个文件或多模块项目：跨模块依赖的断裂几乎不可能靠人工追踪
它支持 16 种语言（TypeScript、JavaScript、Python、Go、Rust、Java、C#、C++、PHP、Ruby、Dart、Kotlin、Swift、Mojo、R 等），所以不管技术栈是什么，Depwire 都能覆盖。
总结
Depwire 解决的是一个非常具体但影响深远的痛点：AI 编码助手在做重构时不知道代码架构，导致批量断裂。它的设计理念很清晰——不给 AI 更多的「智能」，而是给 AI 更精确的「上下文」。
相关链接