如何用 AI 做全栈开发

搭一套能上线的应用，难在哪一层

从零搭一个带前端、后端、数据库和认证的应用，难点不在写出第一个接口，而在让各层之间的边界、约定和兜底都站得住。后端目录怎么按功能组织、控制器和服务怎么分层、配置如何校验、日志要不要结构化；前端调用 REST、GraphQL 还是 tRPC，返回格式是否统一，跨域和鉴权链路是否接稳；上线前还有健康检查、CORS、安全头、优雅关闭这一串生产硬化。这些环节横跨前后端，任意一层含糊都会让应用"能跑但不稳"。

这个技能怎么把应用骨架立稳

它的做法是"先决策、后落地"。开工前，它先收集技术栈、数据库、集成协议、实时和认证需求，把选型敲定；随后针对项目结构、API 客户端、错误处理和认证架构做出明确决策，而不是边写边改。落地阶段，它提供一套成体系的模式：按功能组织目录、控制器-服务-仓储三层、配置校验、结构化日志、输入验证、缓存、文件上传，以及 SSE、WebSocket 等实时通信。上线前再补齐健康检查、CORS、安全头和优雅关闭这类生产硬化项，并通过构建与烟测来验证整体可用。

怎么用它

用法是把要做的应用、技术栈和当前痛点用自然语言说清楚，由它先决策、再落地、最后验证。例如可以这样对它说：

它适合这些场景：从零搭建带前端、后端、数据库和认证的 CRUD 应用；已有后端服务需要梳理模块边界、错误格式和日志体系；前端要接入 REST、GraphQL、tRPC 或 OpenAPI 生成客户端；产品上线前补齐健康检查、CORS、安全头和优雅关闭。

大家常问

什么是前后端分离？和不分离有什么区别？

不分离架构里前端模板和后端业务混在一个工程，由服务端渲染整页 HTML；分离架构则把前端和后端拆成两个独立项目，通过 HTTP API 以 JSON 交换数据，前端只管 UI 渲染，后端只暴露接口和业务逻辑。两者最大区别在部署解耦、并行开发，以及前端必须自己管理状态。

搭一套带前端、后端、数据库和认证的应用，为什么难点在层与层的边界？

每一层抽象模型不同：前端是事件驱动、后端是请求-响应、数据库是集合论与事务，边界处就是这些模型碰撞的地方。前后端契约、状态同步、鉴权令牌传递、ORM 阻抗失配、数据库迁移节奏等问题都不在单层内部，而是发生在层与层的连接处，靠跨层共识才能稳住。

控制器-服务-仓储三层架构是什么？为什么写后端要拆这三层？

控制器只翻译 HTTP 输入输出、做参数校验和响应包装；服务层编排业务逻辑、控制事务边界；仓储层封装数据访问，屏蔽 ORM 和 SQL 细节。调用方向严格单向：Controller→Service→Repository。拆分之后每层可独立测试、并行开发、单独替换实现，业务一长也不会失控。

为什么 API 上线前要做配置校验、健康检查和优雅关闭这些生产硬化？

这三项把"意外"变成"可控"：配置校验在启动时把 CORS、连接串、限流这类参数核对一遍，错了直接拒启；健康检查向负载均衡器汇报数据库、缓存等依赖是否真能用，连不上就摘除流量；优雅关闭收到 SIGTERM 后先注销、再等正在处理的请求结束，避免每次部署都甩出一批 502。