告别古法编程时代：我用 AI 从零生成了一个完整的 ERP 小程序

一、先说结论

一个字：爽。

过去需要三个月、两个前端一个后端吭哧吭哧写的项目，现在一个人 + 一台电脑，几天时间搞定。不是 demo，不是玩具，是一个真正能跑、能登录、能查数据、有权限控制、有聊天功能的完整医疗供应链 ERP 微信小程序。

所有的代码——前端的 Vue、后端的 Java、配置文件、样式、甚至这篇博客——全部由 AI 生成。我做的事情只有三件：描述需求、点确认、测试反馈。

---

二、项目背景

我要做的是一个医疗供应链管理 ERP 的小程序端。已有的 Web 系统是 Spring Boot + Vue 2 的架构，小程序需要从头开始搭建，技术栈选型为：

• 前端：uni-app 3.0 + Vue 3 + Pinia + uView Plus
• 后端：复用现有 Spring Boot 3 项目，新增 JWT 认证
• 通信：WebSocket 实时聊天

项目规模：5 个主 Tab 页面、35 个子页面、8 个聊天页面、14 个 API 模块、4 个状态管理 Store。如果古法编程，预估至少 3 人月。

用 AI 来完成，从零到 70% 完成度（基础设施 + 全部主页面 + 部分子页面），实际耗时不 到一周。

---

三、AI 编程的正确打开方式

3.1 不要当成"代码补全工具"

很多人对 AI 编程的理解还停留在 Copilot 式的"你写一半，它补一半"。这完全是用错了。真正的 AI 编程是：

你：我要一个登录页面，支持账号密码登录、微信登录、游客模式
AI：好的，这是完整的 login/index.vue，包含表单验证、验证码、记住密码……
你：运行
AI 生成的代码直接能跑。

你不需要写一行代码，你只需要准确描述你想要什么。

3.2 上下文是王道

AI 最怕的不是问题复杂，而是信息不全。一开始我没给够上下文，AI 经常猜错文件路径、搞错项目结构。后来写了 CLAUDE.md，把项目架构、技术栈、关键约定全部写进去，AI 的表现立刻上了一个台阶。

建议每个项目都维护一个 CLAUDE.md，内容至少包括：

• 项目概述和技术栈
• 目录结构和分层架构
• 关键约定（命名规范、样式单位、路径别名等）
• 已知的坑和注意事项

有了这个文件，AI 就像一个入职一周的新人，而不是一个刚进门啥也不知道的陌生人。

3.3 把 AI 当成你的全栈团队

我同时改三个项目——Java 后端、Web 前端、小程序前端——这在传统开发中需要三个人协作。但是现在我一个人就能完成，因为 AI 同时懂 Java、Vue 2、Vue 3、小程序、数据库、Redis……

你只需要说"后端的缩略图接口有问题，参考正常预览接口的写法修一下"，AI 自己去看代码、找到问题、写出修复，而且三个项目的风格保持一致。

---

四、踩过的坑

虽然效率极高，但也不是一帆风顺。下面是我踩过的几个典型坑，分享出来帮大家避雷。

4.1 路径幻觉

AI 有时候会"猜"文件路径，尤其是在项目初期上下文不足的时候。明明文件在 src/static/ 下，它会去项目根目录找 static/。解决方法很简单：首次交互就把项目结构说清楚，写进 CLAUDE.md。

教训：不要让 AI 猜，明确告诉它"源码目录是 src/，静态资源在 src/static/ 下面"。

4.2 密码明文传输

这是最经典的一个坑。Web 前端登录时密码做了 md5() 再发送，但 AI 生成小程序登录代码时直接传了明文。后端收到明文密码，跟数据库里存 MD5 比对，当然对不上，就一直登录失败。

直到我去看了 Web 前端的源码，才发现少了这一步。改完立刻好了。

教训：涉及安全的关键逻辑（密码、加密、认证），一定要主动告诉 AI 参考已有实现，不要假设 AI 会自动发现这些约定。

4.3 sed 批量替换的次生灾害

有一次需要批量改 7 个 Java 文件，我用 sed 直接替换。第一次替换把代码塞进了注释里，第二次行号因为前一次替换而偏移，又改错了位置。最后 AI 帮我一个个排查修复。

教训：批量操作后必须验证；AI 生成的 sed 命令和其他批量脚本，要让它先解释清楚会改哪些行，再用。

4.4 缩略图的 NPE

后端缩略图接口看着代码没问题，实际一跑就 404。查了半天，发现是：

1. ImageIO.read() 对某些格式返回 null，后面直接 NPE
2. 图片缩放的整数除法可能算出 0 像素的尺寸
3. PNG 透明图被当成不透明处理，透明区域变黑

这些问题在本地测试时不一定暴露，上线后才炸。AI 修起来倒是快，但发现问题的过程还是得靠人。

教训：AI 生成的代码能跑，但边界情况可能没覆盖全。特别是涉及图片处理、文件 I/O、网络请求的地方，要多测几种场景。

4.5 游客模式的全链路设计

游客登录功能看起来很简单的需求：生成一个假 token，不调后端 API。但实际实现涉及：

• API 层拦截（request.js 拒绝 guest_ 前缀）
• 页面级守卫（首页和聊天页跳过数据加载）
• 导航拦截（uni.addInterceptor 阻止跳转子页面）
• 部分页面放行（关于我们等公开页面）

AI 第一次只做了 API 层拦截，用户反馈后才逐步补全。这其实不是 AI 的问题，而是需求本身就需要逐步细化。

教训：跨切面的需求（权限、主题、国际化等），第一次描述时尽量把涉及的所有层面列出来，避免来回补齐。

---

五、效率对比

环节	古法编程预估	AI 辅助实际	提效倍数
项目初始化 + 架构搭建	3 天	2 小时	~12x
5 个 Tab 页面 + 登录页	5 天	1 天	~5x
API 层（14 个模块）	3 天	4 小时	~6x
Store 层（4 个模块）	2 天	3 小时	~5x
后端问题排查修复（5 个 bug）	2 天	4 小时	~4x
头像系统 + 图片预览	1.5 天	2 小时	~6x
登录链路完善（MD5/错误提示）	1 天	1 小时	~8x
总计	~17 天	~4 天	~4x

注意这里的"古法编程预估"是按熟练开发者估算的，实际很多团队因为不熟悉跨技术栈（Vue 3 + Java + 小程序），耗时只会更长。

---

六、AI 编程的边界

诚实地说，AI 不是万能的。目前阶段有几个明显的局限：

1. 复杂业务逻辑需要人类把关。 AI 能写出正确的语法，但业务维度的正确性——比如"游客应该能看到关于我们但不能看到业务数据"——需要人来定义。

2. 跨文件的连锁修改容易出遗漏。 改了一个接口，前端调用的地方可能漏改。虽然比人类遗漏的概率低，但还是需要验证。

3. 调试还是得靠人。 AI 能帮你分析报错日志，但"这个接口返回 500 是因为 Redis 没启动"这种环境问题，目前还不能自动发现。

4. UI 审美需要人类拍板。 AI 能做出功能齐全的界面，但好不好看、符不符合品牌调性，需要人来判断。

---

七、给想尝试的朋友一些建议

1. 从小项目开始。 先让 AI 写一个工具函数、一个页面组件，感受一下节奏，再逐步扩大范围。

2. 写好 CLAUDE.md / README。 这是 AI 的"新人入职文档"，越详细越好。项目结构、技术栈、命名规范、已知约定，全部写进去。

3. 把 AI 当成你的团队，而不是工具。 给它完整的上下文，描述清楚需求，像跟同事沟通一样。

4. 每次改完要验证。 AI 生成代码后，编译、运行、点击测试，确认没问题再进行下一步。不要信任任何未经测试的代码——无论是人写的还是 AI 写的。

5. 及时记录经验。 踩过的坑、有效的沟通方式、常用的指令模板，记下来下次直接用。

---

八、结语

以前说"程序员会被 AI 取代"，我还觉得是天方夜谭。现在看来，不是说 AI 会取代程序员，而是会用 AI 的程序员会取代不会用的。

当你不再需要纠结于 margin 和 padding 的区别、不用去查 Spring Boot 某个注解的用法、不用手动写重复的 CRUD 代码，你的精力可以完全放在业务逻辑和用户体验上。这才是编程本来该有的样子。

从"我写代码"到"我描述需求、AI 写代码"，这个转变一旦体验过，就再也回不去了。

爽。

---

本博客由 Claude Code 辅助撰写。是的，这篇也是 AI 写的。