我不会写代码。准确地说，我能读懂一些 Python，会写几行 Shell 脚本，但”编程”这件事对我来说一直是黑箱。变量、类型、生命周期、所有权——这些概念我知道它们存在，但让我从零写一个完整的程序，做不到。

然后我用 Rust 写了一个命令行工具。从开始到完成，花了大概两个周末。全程没有写超过 10 行未经 AI 辅助的代码。

这不是炫耀，这是我想分享的经验：AI 时代，编程的门槛已经不是”会不会写代码”，而是”会不会描述需求”。

为什么是 Rust

在 AI 辅助编程的语境下，语言选择出奇地重要。

很多人推荐初学者用 Python，理由是”简单”。但我选了 Rust，原因很务实：

• 编译器是最严格的老师——Python 的错误在运行时才暴露，Rust 的错误在编译时就被抓住。AI 写的代码有 bug 是常态，编译器帮你把大部分 bug 挡在门外
• 生成的二进制文件是独立的——不需要安装 Python 环境，不需要处理依赖，编译完就是一个可执行文件，拷到任何 Linux 机器上直接跑
• clippy 是第二双眼睛——Rust 的 linter 不仅检查语法错误，还会给你写代码风格的建议。很多 AI 生成的代码虽然能跑，但不够 idiomatic，clippy 会帮你改进

简单来说：Rust 的工具链本身就是一种质量保证。 对于不会写代码的人来说，你少了一个需要担心的维度——编译器在替你把关。

我的工具做了什么

我需要一个工具来批量处理 Markdown 文件：读取指定目录下的所有 .md 文件，提取 front matter 中的日期，按日期重命名文件。

需求很具体，很机械，很适合自动化。但就这么一个简单的工具，如果让我纯手工写，我不知道从哪里开始——我不知道怎么遍历目录，不知道怎么解析 YAML，不知道怎么处理文件系统操作。

但我知道我要什么。

工作流程

我的实际工作流程是这样的：

第一步：描述需求

我告诉 AI（当时用的是 Claude）：

我需要一个命令行工具，功能如下：扫描指定目录下的所有 .md 文件，提取 YAML front matter 中的 date 字段，然后按照 YYYY-MM-DD-title.md 的格式重命名文件。用 Rust 实现，使用 clap 做命令行参数解析。

这一步的关键是：把”我要什么”说清楚。 你不需要知道怎么做，但你需要知道要什么。这个能力不是编程能力，是产品能力。

第二步：让 AI 生成代码，然后交给编译器

AI 会生成一大段代码。这段代码大概率编译不过。这不重要。

重要的是编译器会告诉你哪里错了。然后你把编译错误粘贴给 AI，让它修复。这个过程会重复几次——生成、编译、报错、修复、再编译——直到编译通过。

整个过程我甚至不需要理解代码在做什么。我只需要：

1. 把编译错误复制给 AI
2. 把 AI 的修复结果粘贴到编辑器
3. 运行 cargo build
4. 重复

编译器是最耐心的 Debug 伙伴。 它不会不耐烦，不会给你模糊的建议，它只会精确地告诉你第几行第几列出了什么问题。

第三步：测试真实数据

编译通过不代表能用。我会准备几个真实的 Markdown 文件，用各种边界情况测试：

• 没有 front matter 的文件
• date 字段格式不对的文件
• 文件名包含中文的文件
• 空目录

每次发现问题，就把错误现象和预期行为描述给 AI，让它修复。

第四步：用 clippy 打磨

编译通过、功能正确之后，运行 cargo clippy。clippy 会给出一系列建议——不必要的 clone、可以用更简洁的写法、某个 import 没用到。把 clippy 的输出给 AI，让它优化。

这步不是必须的，但它让代码质量从”能用”提升到”像样”。

遇到的坑

当然不会一帆风顺。几个主要的坑：

所有权和借用。 AI 生成的代码经常会有所有权问题——编译器最常报的错就是这个。好消息是，编译器的错误信息非常友好，直接粘贴给 AI 就能解决。坏消息是，有时候修复一个问题会引入新的问题，需要几轮迭代。

依赖版本。 cargo add 拉取的依赖版本和 AI 生成代码时假设的版本可能不一致。API 变了，代码就废了。解决办法是固定版本号，或者在提示词里明确指定依赖版本。

边界情况。 AI 倾向于生成 happy path 的代码。现实中的文件可能没有 front matter，可能 date 字段缺失，可能文件名有特殊字符。这些都需要你主动去测试和发现。

最大的坑其实是：不知道该测什么。 作为一个不会写代码的人，我对”代码可能出什么错”没有直觉。我漏掉了很多边界情况，直到它们在真实使用中暴露出来。

我学到了什么

虽然我不会写 Rust，但这个过程让我对编程有了新的理解：

编程最难的部分从来不是写代码，而是定义问题。 当你能清晰地描述一个问题，AI 就能帮你实现。但”清晰地描述问题”本身就是一种稀缺能力。

类型系统不是障碍，是安全网。 Rust 的类型系统看起来吓人，但它在我不会写代码的情况下保护了我——编译器帮我挡住了大量运行时才会暴露的错误。

“够用就行”是一种合理策略。 我不需要理解 Rust 的每一个概念。我只需要能描述需求、能读编译错误、能测试输出。这就像你不需要理解内燃机的原理就能开车一样。

对”不会写代码的人”的建议

如果你和我一样，不是程序员，但想用 AI 来构建工具，我的建议：

1. 选 Rust 或 Go——强类型 + 编译器 = 更少的运行时惊喜。Python 不是不能选，但对于不会写代码的人来说，运行时错误更难调试
2. 从一个真实的、具体的需求开始——“我想搭个个人博客系统”太大了。“我想批量重命名文件”刚刚好
3. 学会读编译错误——你不需要理解代码，但你需要能读懂编译器的错误信息，因为这是你和 AI 协作的主要媒介
4. 准备测试数据——在真实的、杂乱的、有边界情况的数据上测试，不要只在理想数据上验证
5. 别学 Rust，用 Rust——不要先去读《Rust Programming Language》，直接开始做你的项目。遇到不懂的概念再查，查了就用，用了就忘——没关系

更大的图景

这次经历让我重新思考了”编程能力”的定义。

在过去，编程能力 = 能从零写出正确的代码。在 AI 时代，编程能力 = 能把需求翻译成正确的指令，并且能验证输出的正确性。

这不是一个更低的门槛，这是一个不同维度的门槛。有些人能写出正确的代码但描述不清需求，有些人能描述清楚需求但不会写代码。AI 消除了后者的障碍，同时放大了前者的价值。

但最终，能同时做好两件事的人会赢——既能清晰描述需求，又能在 AI 帮助下理解代码在做什么。你不需要成为 Rust 专家，但你应该能读懂你自己工具的主要逻辑。这不是为了”学编程”，而是为了对自己的工具有掌控感。

两个周末，一个 Rust 工具，零行手写代码。这件事在两年前是不可能的。现在它不仅可能，而且可复制。

门槛已经变了。问题是，你要不要跨过去。