用 AI 写代码是什么体验？—— 我的 OpenCode 实战记录

从”AI 能不能帮我写代码”到”AI 帮我从零搭了一个完整项目”，这篇文章记录了我使用 OpenCode 的真实体验。

---

起因

之前搭建这个博客的时候，我就尝试用 OpenCode 辅助完成。当时只是抱着”试试看”的心态，让它帮我改改配置、写写 Markdown。结果出乎意料地好用——它不仅能读懂项目结构，还能按照 Hexo 的规范生成正确的 Front Matter 和目录结构。

这次我想更进一步：能不能完全用 AI 从零搭建一个完整的项目？

于是我给了它一个需求：

做一个批量重命名文件的 Web 工具，输入文件夹路径，选择文件类型，自定义命名规则，能预览、能备份替换、能打包下载。

过程

第一步：需求沟通

我没有直接扔给它一堆代码规范，而是用自然语言描述了我想做什么。它做了一件让我意外的事——先评估难度，再开始动手。

它给了我一个表格：

模块	难度	MVP策略
文件扫描	低	Node.js fs 模块
命名规则引擎	低	模板字符串
预览对照表	中	前端表格展示
拖拽排序	中高	MVP跳过，后续加
备份原文件	低	fs.copy 到备份目录
打包下载	中	archiver (zip优先)

它主动告诉我哪些功能可以先做、哪些可以后续完善。这种产品经理思维比我预期的聪明很多。

第二步：项目搭建

它选了 Node.js + Express + 原生 HTML/CSS/JS 的技术栈。没有引入 React/Vue 这些框架，理由是”最快落地，不引入框架开销”。

我认同这个判断。对于一个工具型项目，轻量级方案反而更合适。

整个项目结构它自动帮我建好了：

AI_Rename_Tool/
├── server.js          # 后端 API
├── package.json       # 依赖配置
├── public/
│   └── index.html     # 前端页面
├── backups/           # 自动备份目录
└── temp/              # 临时压缩目录

第三步：遇到问题

第一次跑起来后，扫描和下载都正常，但点击”备份并替换”按钮没有任何反应。

它自己定位到了问题：前端生成的预览数据缺少 newFullPath 字段，导致后端 fs.existsSync(undefined) 报错。

修复过程很干脆——改了前端的路径计算逻辑，后端加了防御性校验，然后自动跑了端到端测试验证修复结果。

这个自我修复的能力是我觉得最有价值的部分。不是它不犯错，而是它能快速定位、修复、验证。

我的几点感受

1. 描述需求比写代码更重要

AI 编程的核心能力不是”写代码”，而是理解意图。你描述得越清晰，它做得越准确。

好的需求描述应该包含：

• 目标：你想实现什么功能
• 输入输出：用户怎么操作，期望得到什么结果
• 优先级：哪些是必须的，哪些可以后续加
• 约束条件：技术栈偏好、性能要求等

2. 它适合做什么，不适合做什么

适合的：

• 从零搭建项目骨架
• 实现标准化的功能（CRUD、文件操作、API 接口）
• 快速原型验证
• 写文档和 README
• 排查和修复 Bug

不太适合的：

• 复杂的业务逻辑（需要大量领域知识）
• 性能调优（需要深入理解底层）
• 架构决策（它会给建议，但最终要你自己判断）

3. 你仍然需要懂技术

AI 不是魔法。它生成的代码你需要能看懂、能 review、能判断对错。

在这次实践中，我发现如果完全不懂 Express 的路由机制、不熟悉 Node.js 的 fs 模块，就很难判断它给出的方案是否合理。AI 是放大器，不是替代品——它放大的是你已有的技术能力。

4. 迭代式开发是最佳实践

不要指望一次对话就能得到完美结果。我的经验是：

1. 先让它搭骨架，跑通主流程
2. 测试验证，发现问题
3. 反馈问题，让它修复
4. 逐步添加新功能

这种小步快跑的方式比一次性给一个超长需求文档有效得多。

总结

AI 编程工具已经从”玩具”变成了”工具”。它不能替代工程师的思考，但能大幅减少重复劳动。

对我来说最大的改变是：我不再害怕从零开始做一个项目了。以前可能会犹豫”这个技术我没用过”、”前端我不熟”，现在知道有一个靠谱的助手可以帮我跨过最初的门槛。

剩下的，就是产品经理的思维和工程师的判断力了。

---

本文提到的批量重命名工具已开源在我的 GitHub 上，欢迎体验和交流。