让 AI 写代码：从怀疑到依赖
那天晚上，我对着 Cursor 敲下了第一行 Prompt：「帮我写一个 Rust 模块，递归扫描指定目录下的所有文件，返回路径列表，支持过滤隐藏文件。」
我其实没抱太大希望。渡 Ferry 的核心就是文件扫描，这事儿以前用 Node.js 的 fs.readdir 做过，知道递归大目录有多坑。Rust 的 walkdir 库我听说过，但没写过。心想：让 AI 先给个框架，我再慢慢改。
30 秒后，它输出了 200 多行代码。
我复制到项目里，cargo build。编译通过。我随便指了个有 3000 多个文件的下载文件夹，跑了一下。1.2 秒，结果全出来了。我盯着终端，愣了好几秒。
这玩意儿，真的能跑。
从那以后，我对「让 AI 写代码」这件事的态度，彻底变了。以前是「试试看，不行自己写」；现在是「先让 AI 写，不行再改」。渡 Ferry 从零到能跑的 MVP，前后大概 6 周。如果全自己写，我估计得 3 个月。
但我也必须诚实：AI 不是万能的。有些事它干得漂亮，有些事它干得一塌糊涂。 用对了，是 10x 生产力；用错了，是 10x 返工。
AI 写了多少代码？
我大概算过一笔账。
前端 React 组件：大约 80% 是 AI 生成的。扫描进度条、文件列表、分类结果展示、支付确认弹窗——这些 UI 组件，我只需要描述「要什么效果」，它就能给出 React + Tailwind 的代码。改改细节，基本能用。
Rust 后端：大约 60%。文件扫描、数据库 CRUD、API 接口的序列化/反序列化——这些「有套路」的代码，AI 写得又快又准。但核心的 AI 调用流程、安全删除逻辑、跨进程通信，还是我写的。或者我写框架，AI 填细节。
Prompt 工程和系统设计：100% 是人。架构怎么拆、模块怎么划分、数据怎么流——这些决策，AI 给不了。它只能在你定好的框架里填空。
AI 特别强的场景
前端 UI 组件——这是 AI 最拿手的。你告诉它「一个卡片列表，每行显示文件名、大小、类型图标，支持多选，选中时高亮」，它就能给你一套完整的 React 组件。Tailwind 的 class 它熟得跟背过似的，布局、响应式、hover 效果，基本一次到位。渡 Ferry 的「扫描结果预览」页面，就是我先描述设计稿，AI 写出来的。我改了两处间距，就上线了。
样板代码——API 接口定义、数据库 CRUD、序列化/反序列化。这些代码有固定模式，AI 见过无数遍。你说「帮我写个 SQLite 的插入函数，表结构是 xxx」，它秒出。你说「给这个 struct 加 serde 的 Serialize」，它一行不差。渡 Ferry 的 API 层，大部分是 AI 根据我的数据模型定义生成的。
单元测试——给它函数签名，就能写出测试用例。边界条件、空值、异常路径，AI 都能想到。我写了一个 Rust 的 hash_file 函数（做 SHA-256 校验用），把签名贴给 AI，它给出了 8 个测试用例，覆盖了空文件、大文件、权限错误等情况。我跑了一遍，全过。
文档——JSDoc、README、API 文档。AI 写文档比写代码还稳。你说「给这个模块写 README」，它能把功能、用法、示例都写上。渡 Ferry 的 docs/ 目录里，好几篇是 AI 根据代码生成的，我只需要补充「为什么这么设计」。
AI 特别弱的场景
复杂的系统设计——架构决策还是得自己做。比如渡 Ferry 的前端和后端怎么通信？Tauri 的 IPC 怎么设计？状态在哪边存、哪边算？这些问题的答案，取决于你对产品、对性能、对扩展性的理解。AI 能给你几个方案，但「选哪个」——它不知道。它没见过你的用户，不知道你三个月后要加什么功能。
性能优化——AI 不知道真实的瓶颈在哪。它会给你「用 Arc 减少克隆」「用 rayon 并行」这种通用建议，但你的瓶颈可能是「SQLite 查询没建索引」或者「前端每 100ms 重渲染整个列表」。这些得你自己 profiling，自己定位。AI 能帮你写优化后的代码，但「优化哪里」——你得告诉它。
跨模块的状态管理——AI 看不到全局上下文。你让它改 A 模块，它不知道 B 模块依赖 A 的某个字段。你让它重构 C，它不知道 D 在监听 C 的副作用。渡 Ferry 的「扫描 → AI 分析 → 用户确认 → 执行迁移」这条链路，状态在好几个 store 之间流转。这种跨模块的协调，我都是自己画的图、自己理的逻辑，再让 AI 填具体实现。
安全相关逻辑——不能有 bug。SHA-256 校验、安全删除流程、支付回调验证——这些地方一旦出错，要么文件损坏，要么钱丢，要么用户隐私泄露。AI 写的代码，我每条都自己看过。校验逻辑我甚至写了额外的测试，用已知的文件和 hash 对了一遍。安全这块，我不信任 AI 的「大概对」，我要「确定对」。
人和 AI 协作的工作流
半年下来，我摸索出一套比较顺的流程。
第一步：人做系统设计和架构决策。模块怎么拆、接口怎么定、数据怎么流——这些想清楚，写下来，哪怕只是几段注释。
第二步：AI 写第一版代码。把设计文档和上下文给它，让它生成。不追求完美，先跑通。
第三步：人 review 和修改。AI 的代码常有「看起来对但实际有坑」的地方。类型对了但逻辑漏了、边界没处理、错误处理不完整——人来看，一眼能发现。改完再跑一遍。
第四步：AI 写测试。把改好的函数给 AI，让它写单元测试。人补充集成测试和边界用例。
第五步：人做集成和调试。把模块拼起来，跑完整流程，看哪里卡住。遇到 bug，把报错和上下文给 AI，让它修。通常 2-3 轮就能过。
渡 Ferry 的「安全删除」流程，就是这么搭出来的。我设计好「用户确认 → 校验文件 hash → 执行删除 → 更新数据库」的步骤，AI 写每个步骤的具体实现，我 review 安全相关的部分，AI 写测试，最后我跑完整流程验证。前后大概两天，如果全自己写，我估计得一周。
Cursor + Claude 的具体技巧
给 AI 足够的上下文——不要让它猜。打开相关文件，用 @file 引用。描述数据流：「这个组件的 props 来自父组件的 store，用户点击后会调用 Rust 的 xxx 接口」。上下文越多，AI 一次写对的概率越高。
让 AI 一次做一件事——不要一口气让它「重构整个扫描模块」。拆成「先改接口定义」「再改调用方」「最后改实现」。每步都能验证，出错也好定位。
用 @file 引用项目中的文件——让 AI 理解项目结构。你说「参考 src-tauri/src/scan.rs 的风格，在 api.rs 里加一个类似的函数」，它就能保持一致性。比你自己描述「我们项目用这种错误处理方式」管用多了。
对 Rust 代码：编译器是最好的 Prompt——先让 AI 写，cargo build 报错，把完整报错贴给 AI，它修。通常 2-3 轮就能编译通过。Rust 的编译器报错信息很详细，AI 能看懂。比你自己查文档快。
对 React 组件：先描述再迭代——第一版可以让 AI 自由发挥，跑起来看看。哪里不对，具体指出「这个按钮要左对齐」「列表要虚拟滚动」，让它改。比一开始就写长篇需求文档高效。
反思：10x 的倍增器，但你必须知道自己要什么
AI 写代码，最大的价值不是「写得快」，而是把你从「动手」中解放出来，让你把时间花在「思考」上。
以前写一个功能：查文档 20 分钟、写代码 40 分钟、调试 30 分钟。现在：想清楚要什么 10 分钟、让 AI 写 5 分钟、review 和改 15 分钟。思考的时间占比变大了。 你有多余的脑力去考虑「这个设计会不会有扩展性问题」「用户在这个环节会不会困惑」——而不是埋头写 for 循环。
但 AI 不能替你思考。它不知道你要做什么产品、用户是谁、三个月后要加什么功能。它只能根据你给的信息，生成「最可能对」的代码。如果你自己没想清楚，AI 会给你一个「看起来对」的答案——然后你上线后发现根本不是你要的。
你得知道自己要什么。 系统设计、架构决策、安全关键路径——这些必须你来做。AI 是替你动手的，不是替你拿主意的。
渡 Ferry 能做到 8MB 安装包、1 秒扫描 8000 个文件、SHA-256 校验零差错——这些数字背后，是人的设计 + AI 的实现。缺一不可。
本篇 Takeaway
- AI 写代码的真实比例：渡 Ferry 前端约 80%、Rust 后端约 60% 由 AI 生成，但 Prompt 工程和系统设计 100% 是人。AI 填空，人定框架。
- AI 强的场景：前端 UI 组件（React + Tailwind）、样板代码（API、CRUD、序列化）、单元测试、文档。这些有固定模式，AI 一次到位。
- AI 弱的场景：复杂系统设计、性能优化（不知道瓶颈在哪）、跨模块状态管理（看不到全局）、安全逻辑（不能有 bug）。这些必须人主导。
- 协作工作流：人设计 → AI 写第一版 → 人 review → AI 写测试 → 人集成调试。Rust 用编译器报错驱动 AI 修，2-3 轮通过。
- AI 是 10x 倍增器，但不能替你思考：它把你从「动手」解放出来，让你花更多时间「思考」。但你要什么、架构怎么定、安全怎么保证——这些必须你自己清楚。
系列导航
系列：AI 时代，我如何一人从想法到产品赚到第一个 10 万
