指出"生成代码容易,构建可扩展应用难",给出在 AI 辅助下先定义业务边界、数据库 schema、应用架构再开始生成的结构化方法论。
Vibe Coding 改变了开发者构建软件的方式。
你可以向 AI 编程助手描述一个功能,并在几分钟内获得可运行的代码。这非常强大。
但问题在于:
生成代码很容易。构建一个可扩展的应用却很难。
对于严肃的项目,我认为最好的方式不是:
“给 AI 一个提示词,让它构建所有东西。”
更好的方式是:先给 AI 结构、规则和上下文,再让它生成代码。
在写代码之前,先明确应用实际需要什么。
需要哪些功能?
需要存储哪些数据?
业务规则是什么?
需要哪些集成?
应用可能会增长到多大?
这给了 AI 一个清晰的目标。
接下来,定义基本架构:
Frontend → API → Backend → Database → External Services
确定以下重要事项:
PostgreSQL 或其他数据库
先不要开始生成大量文件。
对于大多数应用来说,数据库是最重要的基础之一。
在创建实际数据库之前,我也喜欢用 Mermaid 生成 ERD。
这样在实现之前可以轻松审查关系。
schema 审批通过后,创建数据库和迁移脚本。
对于 PostgreSQL,不要盲目地在所有地方加索引。
要考虑应用实际会执行的查询。
哪些列经常用于搜索?
哪些列用于排序?
哪些列在过滤器中一起使用?
有没有慢查询的 JOIN?
查询是否返回了不必要的数据?
使用 EXPLAIN ANALYZE 等工具来了解实际的查询性能。
最好的索引取决于查询。
现在 AI 可以基于已批准的架构和 schema 生成后端。
一个简单的结构可能是:
Controller → Service → Repository → Database
重要的一点是:AI 应该遵循架构,而不是为每个功能都发明一套新结构。
在连接前端之前,先清晰定义 API。
对于每个端点,指定:
Method + URL + Request + Response + Errors + Authentication
这可以防止前端和后端逐渐变得不一致。
现在连接前端到 API。
UI → State → API Client → Backend
保持 API 调用的组织性,不要在组件中到处散落原始请求。
适当使用乐观更新。
AI 也可以生成测试,但生成的测试是不够的。
没有人运行的测试不会保护你的应用。
上线生产环境之前,审查:
敏感数据泄露
性能方面,先测量再优化。
找出实际的瓶颈,而不是因为 AI 建议就优化所有东西。
我不认为未来的趋势是开发者消失。
我认为趋势是开发者变得更擅长指挥 AI。
不是:
“构建我的整个应用。”
而是:
“这是我的架构、数据库 schema、API 契约、编码规范和约束。实现这个功能,解释这些改动,并用测试验证。”
这就是 AI 生成代码与 AI 辅助工程的区别。
AI 可以写大量代码。
但你仍然需要设计系统。