AI 作为配对程序员：我如何在一天内构建 depx

Source: Dev.to

The debate is wrong

大多数关于 AI 在编程中的讨论都是二元的：要么是 “AI 将取代开发者”，要么是 “AI 是垃圾，总是出错”。 两者都没有抓住重点。

AI 只是一种工具——像编译器、IDE 或 Stack Overflow。问题不在于是否使用它，而在于 如何有效地使用它。

What I actually did

昨天我构建了 depx，一个用 Rust 编写的 CLI 工具，用来分析 JavaScript/TypeScript 项目，了解 node_modules 中到底有什么：

• 找出已安装但从未被导入的包
• 解释任意传递依赖的存在原因
• 检查真正影响你所使用版本的漏洞
• 列出已废弃的包

我把它发布到 crates.io，贴到了 Reddit，并收到了一个拥有 25 k 包的用户的反馈——他说我的审计命令会发起 25 000 次 API 请求。几小时内我实现了批量查询（v0.2.0），将请求数降至约 25 次。

How AI fit into this

整个过程我都在使用 Claude。实际情况是这样的：

What I did

• 确认问题（node_modules 混乱）
• 定义架构（分析器、图结构、lockfile 解析器、漏洞检查器）
• 做出技术决策（使用 oxc_parser、petgraph、OSV API）
• 评估输出并捕获边缘情况（@types 包、构建工具）
• 在真实项目上测试
• 响应用户反馈并优先处理修复

What Claude did

• 写代码的速度比我打字快
• 实现了我定义的结构
• 帮助调试问题
• 生成了我本来也会写的样板代码

The key insight

那些说 “AI 写的代码很糟糕” 的人，往往是让它完全取代自己。他们提示 “帮我构建一个应用”，结果得到一堆垃圾。

而有效使用 AI 的人把它当作 配对程序员。你负责驱动，AI 加速。你仍然需要：

• 深入理解问题
• 知道什么是好代码
• 评估解决方案是否正确
• 对结果负责

Transparency

如果你查看 depx 的 GitHub，你会看到 Claude 被列为贡献者。这是有意为之。我并没有隐藏使用了 AI——而是表明使用 AI 并不代表你没有真正构建出东西。

这个工具是可用的。它解决了真实的问题。用户在提供反馈，我在不断发布改进。这才是关键。

The real question

别再问 “开发者应该使用 AI 吗？”

而是要问 “有了这层杠杆，我现在能构建什么？”

depx on GitHub | depx on crates.io