前阵子我把自己手痒做的一个小工具项目翻出来用 AI 从需求梳理一直推到了线上交付整个过程中业务代码几乎没手写过全程主要在做“告诉 AI 做什么、检查它做出来的东西、让它改”这三件事。做完之后最大的感受是AI 已经把交付一条软件链路的门槛压得非常低了但真正决定项目成败的已经不是“会不会写代码”而是“会不会提需求”和“知不知道怎么验收”。这篇文章就聊聊这次端到端交付的完整过程包括项目选型、思路拆解、实操步骤、踩过的坑以及“全程没写几行代码”背后真实的经验边界。1. 项目选型与技术栈哪些项目适合让 AI 全流程交付1.1 项目背景与选型理由我做的这个项目是个轻量级的工具类应用功能不算复杂但链路完整用户注册登录、数据录入、列表查询、统计汇总、还有一份只读的管理端报表。这类项目非常适合用来验证 AI 端到端交付原因很简单业务逻辑清晰、没有复杂的算法或硬件依赖、交互流程常规、数据模型也不臃肿。换句话讲它的复杂性在于“涉及的环节多”而不是“某个环节深”这种项目最容易让 AI 代码生成发挥优势。如果你的项目需要大量定制化交互、复杂状态管理、或者涉及核心算法与特定行业合规逻辑那我建议还是先把 AI 定位成“辅助编码”而不是“全流程交付”。我的判断标准只有一条需求能不能在半小时内用自然语言描述清楚如果能就值得尝试端到端交给 AI如果需要连续不断的双向澄清才能让需求成型那更适合用 AI 做局部实现。1.2 技术栈选择的底层逻辑这个项目我选的技术栈是前端 Vue 3 Element Plus后端 FastAPI数据库 SQLite 起步、部署时切到了 PostgreSQL服务器上一律用 Docker 跑。这个组合并没有哪个参数特别复杂但它是目前 AI 对话式生成最容易出稳定结果的一套配置。Vue 3 和 Element Plus 的好处在于组件库足够标准和流行AI 训练语料里这类代码非常多生成出来的结构不太容易出现“很努力但看不懂”的情况。FastAPI 的代码风格天然简洁自动生成 OpenAPI 文档对调试很有帮助AI 写接口的速度和准确率都明显高于 Django 这种重量级框架。数据库选择 SQLite 是为了让开发阶段零成本跑通后面切到 PostgreSQL 时只需要改一行连接串这个过渡本身也是对项目结构是否干净的检验。1.3 “全程没写几行代码”的真实含义我知道看到标题肯定有人会质疑怎么可能全程不写代码我先把话说明白。我确实徒手写过几行但不是业务代码而是“脚手架”代码——比如创建项目目录、写 Dockerfile 基础段、在个别 AI 反复出错的地方用最笨的方式指定它改。业务层面的代码包括数据表结构、接口逻辑、页面组件、状态管理、路由配置这些确实都是 AI 生成的。真正有意义的问题不是“写没写几行”而是“不写代码的时间花在了哪里”。我这次至少 70% 的时间花在需求提炼、提示词设计、代码审查、问题定位这四件事上。如果一个人以为“不写代码就等于纯聊天半小时交付”那大概率会翻车。AI 只是把“手写代码”这个环节替代了并没有替代“想清楚、验清楚”的环节这两件事才是项目交付的核心成本。2. 需求理解与前置拆解把项目需求转化成 AI 能执行的语言2.1 需求拆解的方法从一个“项目描述”到“对话式需求卡”开工第一件事不是打开 AI 工具而是先把这个项目拆成一张需求卡。我拆成了四个层级用户角色、核心场景、数据维度、验收标准。用户角色上这个工具只有两类人普通用户和管理员。普通用户关心的是录入和查询方不方便管理员关心的是数据统计一眼能不能看懂。这两个角色决定了页面结构和权限模型不需要多想。核心场景更简单普通用户登录后进入自己的数据面板可以新增一条记录、编辑或删除自己的记录能按时间范围筛选管理员有一个独立列表能看到所有用户的数据汇总但不需要看到具体编辑按钮。这个场景已经足够覆盖大部分管理系统页面。数据维度我直接列了五个字段记录名称、分类、金额、备注、创建时间。分类字段需要预置选项金额需要支持保留两位小数创建时间默认取当前时间这些细节如果在需求阶段不写清楚后面 AI 生成的表单校验会非常难用。验收标准是最容易被忽略的部分。我给自己定了五个硬指标注册后能正常登录普通用户只能看到自己的数据新增、编辑、删除操作后列表能正确刷新筛选条件能联动刷新管理员看到的统计数字与明细一致。这五条不是空话每一条后面配合具体操作步骤AI 生成完代码后我直接按这个清单走测试省去大量“想到哪测到哪”的时间。2.2 提示词设计把需求卡改写成 AI 能“一步到位”的对话需求卡拆完以后真正关键的是怎么把它喂给 AI。这里我踩过几次坑最初我把需求描述得非常“文档化”比如“实现一个登录功能模块”结果 AI 给的代码虽然能跑但很多细节都要返工。后来我总结了一套写法提示词里要有项目全貌、模块说明、数据结构、页面行为、技术约束。举一个后端生成登录注册模块的提示词例子这个项目是一个内部数据管理工具用户可以注册和登录。 技术栈FastAPI SQLAlchemy PostgreSQL。 数据库已经有 User 表字段包括 id, username, password_hash, role, created_at。 角色字段只允许两种值user 和 admin。 请生成注册和登录接口 1. 注册接收用户名和密码用户名唯一密码使用 bcrypt 加密后存入 password_hash默认角色为 user。 2. 登录先验证用户名是否存在再校验密码成功后返回 JWT tokentoken 有效期设 24 小时。 3. 需要提供 /auth/register 和 /auth/login 两个路由。 4. 错误码统一用 400 和 401错误信息用中文返回。这种写法的最大的好处是把“实现目标”和“实现约束”同时给到 AI。它知道表结构长什么样、字段怎么命名、校验规则是什么生成的代码几乎不用改表结构。很多人失败的原因是只给了“实现登录”这个目标却没有给数据结构和约束AI 只能自由发挥最后表现出来就是各种字段对不上。2.3 数据库模型生成与验证数据模型我是分两步生成的。第一步让 AI 直接建表第二步让 AI 生成几条模拟数据然后用这几条数据反向校验模型是否合理。建表提示词大概是这样的根据下面的业务描述设计一张记录表 - 每条记录属于某个用户 - 字段包含记录名称必填最长100字、分类枚举餐饮、交通、办公、其他、金额十进制保留两位、备注可选最长500字、创建时间默认当前时间 - 外键关联用户表用户删除时级联删除该用户所有记录 请生成 SQLAlchemy 模型并补充必要的索引。AI 给出的模型基本靠谱但有一个细节我特别注意它默认把分类字段做成了普通字符串而我需要的是枚举。如果不改后续前端筛选下拉框会跟这个字段对不上。所以我在提示词里特意强调了“分类字段使用枚举类型”AI 生成的代码里也正确使用了 Python 的 enum这个细节点在验收时必须检查到。生成完表结构之后我做了个反向验证让 AI 生成 20 条模拟数据插入临时库再用几条 SQL 做统计。这个动作看起来多此一举但能很快发现字段长度、空值约束、类型精度的问题比写完整套代码再调试省心得多。3. 开发落地实操从后端接口到前端页面的完整过程3.1 后端接口生成与分段验收后端这块我没有尝试让 AI 一口气生成整个系统。先让它把注册登录、记录管理、统计报表三段分开生成每生成完一段我立即做一次本地启动验证。记录管理的核心接口有三类列表查询、新增记录、编辑和删除。我让 AI 生成的列表查询支持分页和三个筛选条件分类、金额区间、时间范围。提示词里我特意写了“筛选条件都是可选参数不传则返回全部”因为 AI 很容易把筛选参数写成必填导致前端调用时少传一个参数整个接口就报错。新增记录的接口我要求 AI 必须做权限校验只能增加自己名下的记录。这个需求在提示词里不强调AI 有时候会把用户信息的获取漏掉。我在验收时专门看了生成的代码里是否从 JWT 中解析出当前用户名这个逻辑如果漏掉后端代码表面上能正常出文档但数据归属全是错的。统计报表接口相对复杂我明确要求返回三个维度的数据总数、总金额、按分类分组汇总。AI 用 SQLAlchemy 的 group_by 配合聚合函数一次就写对了但我在实际测试时发现返回的分组字段命名不符合前端习惯昵称和后台统计数据的 key 对不上。这种细节不需要重写代码直接告诉 AI“把返回字段 key 改成我指定的值前端会按这个读取”几秒钟就改完了。后端生成阶段我还有一个习惯每生成完一个接口就让 AI 同时生成对应的 API 文档说明并且要求它给出一个 curl 示例。这不仅是给“人”看的也是给前端生成阶段当“输入”用的。前端联动生成的时候我会把后端文档和 curl 示例直接丢回给 AI这样前端代码里的接口调用基本一次就对。3.2 前端页面生成页面拆解与组件复用前端我没有让人工去写任何页面而是按照角色和页面做了拆分登录页、注册页、普通用户数据面板、管理员汇总页。每个页面都是单独生成这样出了问题定位容易。登录和注册页是整个项目结构与后端联调的第一步。我让 AI 生成的是 Element Plus 表单同时要求配置了输入校验规则用户名不能为空、密码长度不低于 6 位、注册页需要二次确认密码。这里有个细节AI 特别容易把登录页和注册页生成成同一个页面里组件的组合但实际使用中项目通常需要两个独立路由。我在提示词里明确写了“生成两个独立页面使用 Vue Router 实现路由跳转”后面就正常了。普通用户数据面板是这个系统的重头戏。我把需求拆给 AI上方放筛选区域中间放数据表格右上角放新增按钮表格操作列里有编辑和删除。提示词里我要求所有交互都走接口而且明确说明增删改之后需要重新拉取列表数据这个“数据刷新”看起来简单AI 漏掉的概率却很高。如果你在需求里不提它很可能只做局部更新而局部更新的实现细节一旦出 bug用户看到的就是旧数据残留。管理员汇总页我要求直接用卡片展示统计数字下面放一个分类汇总表格。这个页面不需要跟具体用户数据交互逻辑最简单但我依然给它定义了“统计结果来自哪个接口、接口返回结构长什么样”没有让它自己发挥。前端接手的每份数据都先按后端结构设计展示层能减少大量沟通成本。3.3 联调阶段跨域、鉴权与接口时序前端各个页面生成完后联调是最好玩也最容易暴露问题的阶段。最典型的坑就是跨域。前端开发服务器跑在 5173 端口后端在 8000 端口我用 Vite 配了一个代理前端访问 /api由代理转发到后端地址。这个方案在本地联调时最顺手开发态不需要后端额外开 CORS 允许跨域但生产部署就反过来走 Nginx 反代这个方案我在部署章节再详细说。鉴权联调主要看登录态能不能跨页面保持。AI 生成代码时一般默认用 localStorage 保存 token然后再通过请求拦截器在每次请求前把 token 塞进 header。这里有一个隐患刷新页面后如果前端路由守卫没有校验 token 的有效性用户会看到一个已经“登录成功”但后端实际已经返回 401 的页面。我要求 AI 在路由守卫里加一个逻辑存在 token 就让请求自动带上但接口返回 401 时统一跳回登录页并清掉本地 token。这个全局处理方式必须一开始就约定好避免每个接口单独处理异常。接口时序问题也值得提一下。比如编辑一条记录后页面需要同时更新当前表格的数据和右上角的统计卡片。这些数据来自不同接口天然有先后顺序。AI 生成的时候如果顺序没排对会先请求列表后请求统计或者干脆两个并行请求数据倒是不冲突但页面会出现一闪而过的旧数字。我直接在联调过程中发现后让 AI 改成在编辑接口成功回调里同时调用两个查询接口并在 UI 上加了 loading 状态。这类体验细节不实测很难发现但 AI 只要知道“用户想要什么效果”修改起来很快。4. 部署与交付从本地跑通到线上可用的最后一公里4.1 部署方案选型与配置本地一切正常以后我开始准备部署。这次我选定了一台最普通的 Linux 云服务器装机后只装了 Docker 和 Docker Compose。项目分成前端、后端、数据库三个容器来编排没有用更复杂的 Kubernetes 方案因为单体小项目的核心诉求是“稳定可复现”而不是“弹性伸缩”。我先让 AI 生成了 Dockerfile。前端的 Dockerfile 分成两段第一段用 Node 镜像做编译第二段用 Nginx 镜像承载编译产物。后端相对简单直接用 Python 基础镜像把依赖文件拷进去后装依赖然后启动 Uvicorn。数据库用现成的 PostgreSQL 镜像我建了一个独立卷来持久化数据。这里有个很多人会漏掉的点前端容器里的 Nginx 配置不只是托管静态文件还要做接口反向代理。前端打包后请求的是相对路径 /apiNginx 需要把 /api 下的请求转发到后端容器的端口。我在 Nginx 配置里加了这样一段location /api/ { proxy_pass http://backend:8000/api/; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }这个方案的好处是生产环境完全不需要后端处理 CORS因为从浏览器的角度看所有请求都指向同一个域名不存在跨域问题。4.2 环境变量、初始化数据与部署脚本部署阶段最容易出乱子的就是环境配置。我用一个 .env 文件统一管理数据库连接串、密钥、前端 API 地址Docker Compose 里通过 environment 读取这些变量。但这里有个很容易踩的坑后端如果已经直接把 SQLite 数据库文件打进容器部署时启动会报找不到数据库文件的错误。我在开发阶段用 SQLite、生产用 PostgreSQL所以需要在环境变量里区分数据库类型和连接串AI 生成代码的时候如果没有读环境变量的习惯就会把数据库地址硬编码在代码里。所以后端连接数据库的配置从一开始就要让 AI 用环境变量读取而不是写死常量。初始化数据这块我用了一个最简单的办法让 AI 生成一个脚本文件启动时检测数据库里有没有管理员账号没有就自动创建一个默认管理员。这个脚本放在后端容器启动命令中执行后面加执行权限通过 Docker Compose 的 command 字段来调用。很多项目的交付卡在“部署到线上没有数据、没有初始账号”这个脚本能省很多解释成本。部署脚本我分成了部署和回滚两个场景。部署时执行 docker compose up -d --build然后跑一个健康检查脚本确认后端接口返回 200再去检查前端页面是否能正常打开。如果失败就直接执行 docker compose down docker compose up -d 重新拉起旧版本容器。小项目不需要灰度发布但保留最近两个版本的镜像是有必要的避免“新版本启动失败又手忙脚乱找旧包”。4.3 线上验证流程与交付文档部署完成不是交付结束。我自己定了一个线上验证流程注册一个新账号创建两条记录编辑其中一条删除剩下的一条然后查看统计卡片数字是否正确变化。这个流程我特意没有自动化因为功能量级不大人工点一遍最多五分钟但是覆盖了主要通路比写一堆自动化测试用例更直观。最后我把所有关键信息整理成交付文档包括服务器访问地址、默认管理员账号和修改方式、环境变量说明、常用运维命令、备份数据库的方法、回滚方法。这个文档我用 AI 也生成了一半然后自己补了最终修改。为什么不全让 AI 生成因为这个文档需要和我实际部署环境一致AI 不知道我的服务器地址和真实账号配置人工校对是不可少的。5. 踩坑实录AI 生成代码的典型问题与排查方法论5.1 高频错误模式这次全程体验下来AI 生成代码会出现的错误其实有很强的规律性。我整理了一张表配合排查思路比遇到问题再瞎试更高效错误模式具体表现排查思路字段命名不一致前端收到的数据和后端返回的 key 对不上先看后端接口文档再对照前端请求代码鉴权逻辑缺失新增接口没有校验当前用户身份重点检查 JWT 解析代码和路由依赖注入数据刷新遗漏操作成功后页面展示旧数据检查回调里有没有重新调用列表查询接口枚举硬编码分类字段在前后端写死了不同选项用一个常量文件统一管理枚举值事务边界缺失多表写入时部分成功、部分失败检查是否加了事务包裹多表操作必须要求 AI 用事务过期代码复用用了旧版本框架写法导致运行报错直接报错误信息让 AI 根据报错重写这些错误并不会因为你“提示词写得好”就彻底消失而是说大多数问题可以用“给 AI 看报错 给 AI 看接口返回”的方式快速修复。真正令人崩溃的是那种不报错但逻辑不对的 bug比如统计数字从 103 变成 104这类问题只能靠验收流程来兜底。5.2 定位错误的实操手法我发现一个非常高效的定位方式先把问题“现状”完整描述给 AI把相关报错信息或页面表现截图转成文字再附加“我期望它怎样”。比如页面点击新增按钮没有任何反应我不会说“新增按钮坏了”而是说“前端点击新增按钮后接口 /api/records 没有发出请求控制台也没有报错预期是弹出一个表单弹窗点击确定后调用接口”。AI 看到这个描述往往能直接判断出是按钮事件没绑定还是组件库的 dialog 没引入。另外一个技巧是让 AI 自己写调试代码。比如某个筛选条件不生效我会让它临时加一段打印到控制台的日志把前端传的参数和后端接收的参数都打印出来。AI 在处理这种“加日志”的任务上准确率很高而且通过日志能很快确定是传参问题还是查询条件拼写问题。定位完再让它把日志删掉恢复成干净代码。5.3 代码审查的关键清单有人会问你又没写几行代码怎么审查 AI 生成的代码我承认不可能通篇读懂每一行但我有一套轻量审查清单只检查几个容易出问题的关键位置。数据库连接是否存在硬编码密码字段是否加密存储新增和修改接口是否校验了数据归属关键操作是否有事务包裹删除操作是否有二次确认所有接口是否都有统一的错误捕获这个清单不需要很懂技术也能对照执行。真正有技术经验的人可以再加几条更深入的比如 SQL 是否有注入风险、权限校验是否做在了后端而不是只在按钮上隐藏、模型字段是否和数据库 migration 对齐。审查的意义不是证明 AI 写的代码无 bug而是把高风险区域主动看一遍。6. 效率与成本AI 端到端交付的真实账本6.1 时间投入明细整个项目从开始到交付上线我记录了一下时间花销。需求拆解和提示词准备花了约 3 个小时后端生成与验证用了约 4 个小时前端生成与联调也差不多 4 个小时部署、验证和写文档加起来约 3 个小时。总共约 14 个小时对一个没有用 AI 辅助的人来说这类系统从零手写至少翻一倍时间以上。这里最有价值的不是“快了几个小时”而是在整个过程中我几乎没有经历“长时间卡在一个报错上”的状态。过去手写代码最怕遇到一个没见过的第三方库报错可能一查就是半小时。而现在直接把报错信息贴给 AI它给出的修复方案通常可以直接落地。即使第一次修复不对多给一两次上下文就能解决这个体验非常像身边坐了一位随时可以沟通的同事。6.2 成本账与收益边界成本大致是三个部分AI 工具的订阅费、服务器租用费、还有我自己的时间。订阅费用在最常用的配置上每月在可接受范围内换来的收益是至少两倍以上的交付效率。服务器费用对一个小型工具来说基本可以忽略。但这个模式有一个清晰的能力边界当项目规模大到一定程度比如十几张表之间的复杂关联、多种角色的细粒度权限、或者访问量需要水平扩容时AI 纯对话式的生成效率会明显下降。原因是它没有“项目全局记忆”在长对话中做跨模块设计容易“顾此失彼”。这个时候就需要引入更系统的做法比如让 AI 先生成设计文档并评审再分模块生成同时用专门的文件保存约定每次对话都喂给它。6.3 团队协作中的 AI 使用建议如果是团队里几个人协作我建议定一个简单的规范每个 AI 生成的模块提交到仓库时要在代码注释里标注“由 AI 生成人工已检查”。这个规范不是为了甩锅而是提醒后面接手的人这段代码的生成背景和审查程度不一样需要多留一份注意力。团队协作时AI 生成代码的命名风格也需要统一。每个开发者平时写代码的习惯不同有人喜欢长命名有人喜欢缩写AI 会继承对话里的写法。所以团队里应该选一个人统一写提示词模板保证变量命名、接口路径风格一致。不一致的代码在合并审查阶段会很痛苦甚至比手写还折磨。7. 我对这种交付方式的个人体会用 AI 端到端交付完这个项目之后我最大的体会不是“以后可以不写代码了”而是“以后的项目工作方式彻底变了”。写代码这个动作变轻了重的是对需求的理解、对系统边界的判断、对质量的验收以及跟 AI 高效沟通的能力。我身边有些朋友试了一次 AI 生成代码效果不好就放弃了原因多半是拿 AI 当“搜索引擎”用简单给一句话就期待它交付完美结果。但真正有效率的用法是把 AI 当成一个“需要一个好的 brief 的工程师”你描述得越明确、给的约束越具体它的输出就越稳定。像我在数据库模型里强调枚举字段在新增接口里强调权限归属这些细节并非代码多难而是只有“懂业务的人”才意识得到要提——在需求阶段清晰的提出来AI 才会给出对应的实现。最后我建议如果你也想体验一把“AI 端到端交付”不要一上来就选一个复杂的商业化系统先找一个小而完整的工具类项目跑通一遍全链路。做完之后你收获的不只是代码和功能还有一套属于你自己的“AI 协作方法论”提示词怎么写、验收怎么测、哪些地方要人工盯、哪些地方可以完全放手。这套方法论才是“不写几行代码也能交付项目”这句话背后真正值钱的东西。