上个季度我接了一个内部使用的数据看板项目需求说大不大说小也不小要对接三个业务系统的数据做清洗和聚合提供实时看板和每日定时报表前端还得支持非技术人员自助配置指标。按我以前的习惯这种项目从需求梳理到上线少说也得三到四周每天泡在IDE里敲代码中间还要应付需求变更、联调、部署环境这些破事。但这一次我换了个思路全程用AI来端到端交付从需求文档、架构设计、SQL编写、前端页面、后端接口、测试用例到Docker部署几乎没手写几行业务代码。项目最终提前一周上线整体代码量大概六千多行我亲手敲的估计不到两百行其余都是AI生成的我只做审查、调整和集成。这篇文章我就把整个过程摊开讲包括我用了哪些AI工具、怎么设计人机协作的流程、每条关键提示词长什么样、AI生成的代码怎么保证质量、以及踩过的那些坑。如果你也准备用AI去交付一个完整项目这篇文章应该能帮你少走很多弯路。1. 为什么敢让AI端到端交付一个项目1.1 先说清楚这个项目到底是什么这个项目是一个运营数据中台的前端展示层加报表系统。核心功能大概有四块第一接入三个不同来源的业务数据库每天凌晨定时抽取数据第二对原始数据进行清洗和聚合比如去除重复记录、按维度汇总、计算同比环比第三通过Web界面展示趋势图、排行榜和关键指标卡第四支持用户在界面上自定义指标公式并生成日报和月报的PDF导出。整体的技术栈是我和AI一起定的后端用Python FastAPI数据库用PostgreSQL缓存用Redis定时任务用Celery前端用React加Ant Design部署用Docker Compose。为什么选这套组合因为FastAPI写API效率高自带OpenAPI文档AI训练语料里对这种组合的覆盖密度非常大生成的代码质量明显比冷门框架高。这个选择对后续整个流程的顺利程度起了决定性作用。1.2 我评估过风险而且留了后手说完全不担心是假的。AI写代码最大的问题不是“写不出来”而是“写得很像但跑不起来”尤其是跨文件的接口对接和复杂业务逻辑。所以在开工之前我就定了几条原则所有AI生成的代码必须经过我的人工审查不允许直接合入主干。每个模块必须先让AI写测试再写实现代码至少保证核心函数有测试覆盖。AI只负责实现不负责做技术决策遇到架构分叉点必须停下来问我。我保留随时手动介入的能力关键模块的代码量控制在可读范围内防止AI生成过于抽象的封装。这些原则不是限制AI的发挥而是给我的工作流兜底。我见过太多人把提示词一贴生成的代码直接粘进项目结果线上出了事故还不知道问题出在哪。用AI交付项目的核心不是“把活扔给AI”而是“建立一个能让AI稳定产出、同时人能有效监督的流水线”。1.3 我对“端到端”的理解有人觉得端到端就是从写第一行代码到项目能跑起来但我认为真正的端到端交付必须覆盖“需求澄清—系统设计—代码实现—测试验证—部署上线—文档交付”整个链条。这次我刻意让AI参与了每个环节包括需求文档拆解和部署脚本编写。比如需求阶段我没有自己写PRD而是把和业务方的聊天记录、会议纪要、零散的Excel表头一次性丢给AI让它帮我整理成结构化的用户故事和验收标准。这个过程中的核心体会是AI能不能做出高质量的需求分析取决于你给它的信息的完整度以及你后续对产出物的审校能力。别指望AI能凭空猜出业务规则它只能把你给的信息变成更规范的形式。2. 工具链选型和协作模式设计2.1 我实际用到的AI工具清单这次项目我用了四个主要工具分别负责不同环节它们之间形成了互补关系工具承担角色使用场景ChatGPT / Claude架构咨询与需求分析整理PRD、设计数据模型、讨论技术方案Cursor内置AI主力编码环境生成后端接口、前端组件、SQL查询逻辑GitHub Copilot内联补全在Cursor生成结果上进行微调、变量重命名、小函数补全自建脚本 AI API批量任务处理让AI批量审查代码风格、生成测试数据、做合规检查这里面我特别想强调一下多AI协作的意义。不同模型擅长的方向不一样Claude在长上下文和代码审查上表现很好ChatGPT在整体架构讨论上更稳Cursor的AI在IDE里对项目上下文理解更强。我经常做的一件事是让Cursor生成完一段代码后复制到Claude里做一次“第四方代码审查”让Claude从安全性、边界条件、代码风格三个角度挑毛病。这比我自己逐行读代码要高效得多。2.2 为什么不用一个AI全干到底很多人问为什么不直接用一个Agent从头跑到尾我试过但结论是现阶段完全自动化不现实。单Agent在上下文窗口内可以完成单一任务但跨模块协作时经常出现“忘记需求”“重复生成同类代码”“生成与已有代码风格完全不同”的问题。我这次采用的是“人做导演、AI做演员”的模式。项目的整体架构、模块拆解、接口约定、任务优先级由我定AI负责在每个具体任务里发挥。任务的粒度被控制在“一个API端点”“一个React组件”“一条复杂SQL”这个级别每个任务都有明确的输入和验收条件。这样即使AI偶发生成错误代码我也能快速定位和修正不会出现“整个模块重写”的灾难。2.3 我设计的三级质量门禁为了确保AI产出的代码不会带崩项目我在流程里设置了三级质量门禁第一级是前置上下文检查。每次给AI派发编码任务前我必须提供一个完整的任务卡里面包含需求描述、相关接口定义、数据表结构、返回示例、验收标准。缺任何一个信息AI就开始猜一猜就会出问题。第二级是自动化测试门禁。所有AI生成的业务逻辑代码必须先配上单元测试。我用pytest组织测试用例要求AI生成的每个函数都必须覆盖正常路径、异常路径和边界值。没有测试的代码我一律不合并。第三级是人工抽查门禁。虽然我不逐行看代码但我会重点检查几个风险点数据库连接是否泄漏、权限校验是否遗漏、敏感信息是否被硬编码、异常是否被吞掉。这四个点是历史上AI代码最容易翻车的地方。我算过一笔账设计这三级门禁大概花了两个半天但整个项目过程中的返工率至少降低了一半。如果你打算用AI交付项目我强烈建议你在项目一开始就建立这套机制而不是等AI代码出问题后再补救。3. 核心环节实操我是怎么一步步交付的3.1 需求澄清把聊天记录变成PRD项目开始时业务方给我发了一段七十多字的语音加一张Excel截图加几条微信零散留言大意是“我们要看一下每天的转化情况最好能按渠道分以前那个报表太慢领导想看实时的”。这种需求在真实世界太常见了模糊、口语化、隐含大量未说出口的细节。我没有急着写代码而是把已有信息全部贴给AI然后用了这样一套提示词框架你是一名熟悉数据产品和Web系统的高级产品经理。下面是我们业务方提供的原始需求碎片请帮我整理成一份结构化的PRD包含以下内容背景与目标、用户角色、核心功能列表标注优先级P0/P1/P2、每个功能的详细描述、数据指标定义、页面原型文字描述、验收标准、疑问清单。对于信息不足的地方请用[待确认]标注不要自行假设。AI输出的PRD出乎意料地完整甚至帮我把“转化情况”拆成了“整体转化率”“渠道转化率”“分时趋势”三个角度还列出了可能需要业务方确认的十个问题。我拿着这份PRD和业务方开了一个小时的会确认了八个问题的答案补上了两个之前根本没提到的维度新老客拆分和地域维度。这一步给我的启示是AI做需求整理的价值不在于替你思考而在于把散乱信息结构化的速度极快。它的前提是你得把原始材料尽量完整地投喂给它同时你有足够的判断力去筛选和纠正它的输出。如果原始需求是几句话AI最终给你的PRD大概率也存在大量“幻觉式补充”。3.2 架构设计让AI做选择题我来做决策需求明确后下一步是架构设计。我没有直接让AI说“给我设计一套架构”因为那样得到的答案全是教科书模板。我采用的方式是把约束条件全部列清楚让AI在约束范围内提供方案对比。我当时给的约束包括团队目前只有我一个开发部署环境是一台4核8G的ECS数据量预估是每天新增50万条记录用户总数不超过30人不需要复杂的实时流处理开发周期只有两周。然后让AI比较三种方案单体FastAPI应用加Celery、微服务拆分成数据服务和API服务、引入ClickHouse做OLAP查询。AI给的对比表格非常清晰从开发成本、运维复杂度、查询性能、扩展性几个维度分析了一轮。最终我选了方案一加了一层物化视图和Redis缓存来应对查询性能问题理由也很简单这个项目最核心的瓶颈不是技术方案多高级而是我必须用两周时间交付一个稳定可靠系统。ClickHouse很好但我没有时间去维护第二个数据组件。在这个过程中我最大的体会是AI适合做“方案枚举和利弊分析”但最终决策必须由人来做。AI不会知道你的团队现状、运维能力、客户关系这些是决策中最重要的隐变量。我见过有人完全听AI的推荐选了一套三天都搭不起来的技术栈回头怪AI不靠谱其实是把决策权让渡错了。架构设计阶段的产出物是四份文档系统架构图说明、数据模型设计共12张表、API接口清单共28个端点、部署方案。这些文档全都由AI生成初稿我审查修订后作为后续编码任务的唯一依据。这保证了所有AI生成的代码能对接到同一套设计蓝图上不出现“各写各的”的混乱。3.3 数据模型和SQL让AI处理脏活累活数据模型设计是这次AI表现最亮眼的环节之一。原始数据有三个来源一个MySQL库、一个SQL Server库、一个CSV文件每日导入。这三份数据的字段命名和类型完全不同比如“用户ID”在MySQL里叫user_id在SQL Server里叫MemberID在CSV里叫“会员编号”。我要做的就是把它们统一到PostgreSQL里的一张宽表。我把三份数据的样例各抽了100条连同字段说明表一起交给AI要求它设计一套ETL映射规则。AI不仅给出了字段映射关系表还帮我生成了大部分清洗SQL包括去除重复、统一日期格式、处理NULL值、金额单位换算有的系统存分有的系统存元。这部分SQL如果我自己写大概需要一整天AI加我审校三小时就搞定了。但这里也有一个很大的坑AI生成的SQL会在边缘情况下出错。比如它生成的去重逻辑用的是ROW_NUMBER() OVER(PARTITION BY ...)逻辑本身没问题但我测试时发现有一个业务系统的同一个订单会被两个系统分别记录导致事实上的“重复”是业务合法的不能简单去重。这种业务知识AI不了解只能靠人发现。所以我的操作习惯是AI生成SQL后我一定要在真实数据样本上跑一遍并且自己构造几个极端情况测试。比如把日期字段传成NULL、金额字段传成负数、来源系统传一个不存在的ID看SQL会不会炸。AI写SQL的时候很少会自己考虑这些异常输入审查时你必须把它当成一个刚入职的新人既要用它的生产力又要给它的产出做质检。3.4 后端开发用任务卡驱动AI生成接口后端有28个API端点我是按模块分批让AI生成的。每个模块开工前我会准备一份“任务卡”里面包含以下内容功能描述这个接口解决什么问题面向什么调用方。请求方法、路径、参数格式参考已有的OpenAPI规范。数据表结构字段名、类型、索引、关联关系。返回结构统一封装的JSON格式code、message、data。异常处理要求什么情况返回404什么情况返回400什么情况返回500。性能要求预估调用频率、允许的最大响应时间。测试用例要求至少三个用例覆盖正常、异常、边界。举一个具体例子。我需要一个“查询渠道趋势数据”的接口任务卡里会写清楚GET /api/v1/trend/channel参数有start_date、end_date、channel_id、granularityday/week/month返回过去一段时间每天的PV、UV、订单量、GMV。然后AI在Cursor里生成对应的路由函数、查询逻辑、参数校验和响应序列化代码。这个模式下AI的成功率非常高。大部分接口一次生成就能通过基本测试偶尔会有一些小问题比如参数校验漏了枚举值范围、时间参数没有处理时区、分页参数没设上限。这些问题都在人工审查阶段被拦截了。整个过程里我真正动手敲的代码大概只有几个接口的权限校验装饰器因为业务方要求不同角色只能看不同渠道的数据这个权限模型很复杂AI生成的版本我改了三轮才满意。3.5 前端开发AI写组件我负责交互规范性前端部分是React加Ant Design页面数量大概十二个。坦白说AI写前端组件的能力比我预想的强尤其是布局工整、功能标准的表单和表格页面。我的做法是先让AI按照设计稿的文字描述生成页面骨架然后我再逐页检查交互细节。举个例子指标配置页面需要支持用户拖拽字段、设置聚合方式、保存配置。AI生成的初版能跑但下拉框在选项过多时没有搜索功能表单校验提示的文案不统一时间选择器默认值容易出闭环问题。这些问题让我一处处改反而耗时不少。后来我学乖了在每个前端任务卡里额外加上一行“交互细节要求”所有下拉选项超过10个必须支持搜索所有时间选择器必须包含快捷范围选项所有删除操作必须弹确认框所有loading状态必须用骨架屏而不是转圈。把交互规范写进任务卡之后AI生成的前端代码质量提升非常明显。这个经验也适用于后端与其返工让AI修单个问题不如在任务卡里把“组织级的约定”写清楚让AI从一开始就按照这些约定写。3.6 测试与部署让AI自己给自己找bug我自己一直有个观点AI写代码那就要让AI同时写测试。这次项目中每个后端功能模块都对应一个测试文件全部由AI生成。我重点检查的是测试有效性也就是测试到底有没有真正覆盖到风险逻辑还是说只是跑了一遍“快乐路径”。AI生成的测试里有很多无效用例比如只验证了函数能跑通没验证返回值正确性。我要求AI在每个测试用例的断言里必须有具体的期望值而不是只断言result is not None。这个要求执行后测试质量上了一个台阶。最终项目的核心模块测试覆盖率从最初的67%提到了89%已经达到上线标准。部署脚本也是AI写的。Dockerfile、docker-compose.yml、nginx配置、环境变量模板、数据库初始化脚本这些东西AI熟得不能再熟。我只做了一件事把ECS的硬件配置和联通性约束告诉AI让它调整了worker数量、内存限制、超时时间这些参数。关于参数我插一句具体的计算过程机器是4核8G后端进程预留2G内存PostgreSQL预留3G内存Redis预留512M还剩大概2.5G给Celery worker使用。我让Celery每个worker最大内存限制为1G并发数设置为2同时叠加了连接池上限20、数据库最大连接数50。这些数字都是我和AI反复对过资源预算后定的过程中AI负责计算和选项罗列我负责拍板。整套容器启动后我在测试环境跑了两天模拟数据确认定时任务稳定、内存没有持续增长、慢查询数量在合理范围后才切了正式流量。4. 踩坑实录AI项目交付中的典型问题与对策4.1 AI幻觉它义正言辞地生成了不存在的函数这是我遇到最多的问题类型。有一次AI写了一个数据导出功能用了pandas的to_excel方法并加了一个engine参数叫xlsxwriter看起来挺专业但实际运行直接报错。原因是我项目里安装的是旧版pandasxlsxwriter引擎没有启用。AI不会主动检查你当前环境的依赖版本它只会按照训练数据里的“常见版本”生成代码。解决这个问题的方法是要求AI在生成代码的时候标注依赖版本并主动检查requirements.txt。具体来说我会在任务卡里加上一句“在生成代码前请先查看项目根目录的requirements.txt文件确保你使用的库函数与当前版本匹配”。另外运行报错时把完整traceback喂给AI它会自己意识到用了不存在的函数或错误参数。4.2 上下文丢失任务一多AI就“失忆”多轮对话中AI经常在前面记住了需求后面就忘了。比如数据看板首页要求“只显示昨天及之前的数据”AI在第三轮写趋势图时还记得写到第五轮的下载功能时就不管了直接允许导出全部历史数据。这就是典型的上下文丢失。我的对策是使用一个“项目约定文档”放在项目根目录的docs/project_conventions.md里。所有跨模块的全局约束比如时间口径、权限规则、金额精度、分页大小、状态码风格全部写在这份文档中。然后在每张任务卡的结尾都附上一句“如果没有特别说明请严格遵守docs/project_conventions.md中的约定。”这个办法非常奏效把AI的短期记忆问题转化成了长期检索问题。AI每次生成代码前都会先读项目文档相当于给它建了一个“外接硬盘”。4.3 过度工程化AI总想给你造一个框架AI生成代码时有一个隐蔽的毛病喜欢引入新的抽象层。有一个小的数据转换函数本来十行if-else就搞定了AI非要写一个策略模式定义了三个接口类和一个工厂类。它把简单问题复杂化的能力有时候比人类还强。遇到这种情况我的处理原则是只要AI生成的代码超过了我的预期复杂度毫不犹豫地删掉重写。项目里有一处报表导出功能AI生成的版本有200行封装我手动改成了60行平铺逻辑。虽然代码风格没那么“优雅”但可读性和可维护性高后续业务调整时改动成本低。记住AI生成代码的默认目标是“看起来完整正确”不是“最简单好用”。4.4 慢SQL和潜在性能问题AI生成的联表查询和聚合SQL经常存在性能隐患尤其是当它面对复杂数据模型时容易写出嵌套子查询或者跨表笛卡尔积。我这次项目中有个看板接口AI生成的SQL在没有数据的情况下响应12秒让我一度怀疑是网络问题。排查方式是用EXPLAIN ANALYZE分析SQL执行计划发现AI在一个小表和大表关联时没有加过滤条件导致先处理后筛选。我直接把执行计划丢给AI让它优化。AI给出的优化方案是调整ON顺序、增加复合索引、把子查询改成LATERAL JOIN修改后响应时间降到了300毫秒以内。这件事让我养成了习惯凡是AI生成的SQL必须强制检查执行计划不能只看返回结果对不对。4.5 依赖冲突和环境不一致AI生成的requirements.txt有几个固定版本号但实际部署到ECS后发现安装包互相冲突。最典型的是pydantic版本和FastAPI版本不兼容AI生成时没有做全量依赖解析。虽然这个问题不完全是AI的责任但AI可以帮助解决。我把报错信息复制给AI它推荐我用pipdeptree查看依赖树然后给出了三个调整方案。我选了一个改动最小的方案锁定FastAPI版本为0.111.0并把pydantic列进requirements.txt强制降级到2.7.0。整个过程大概半小时比我自己Google搜一圈快多了。4.6 权限与安全漏洞AI生成的代码在权限校验上经常存在漏洞。比如有一个管理员接口AI只做了登录校验没有做角色校验再比如文件导出接口没有校验用户是否有该渠道的数据权限只要登录就能导出全部数据。这类问题非常隐蔽靠单元测试测不出来只能靠人工review和渗透思路来检查。我在审查阶段专门准备了“AI代码安全审查四问”第一这个接口/函数拿到的用户身份是什么第二它是否对用户身份做了最小化权限校验第三敏感操作是否有操作审计第四异常信息是否会暴露内部细节每次让AI生成代码前我都会把这四问写进任务卡让AI自己先自查一遍。试验后效果明显AI自查能发现大部分常见安全问题剩下极少数由我人工兜底。5. 常见问题速查表与交付清单5.1 AI项目交付常见问题速查表症状根源对策生成代码运行报函数不存在依赖版本不一致任务卡要求先看requirements.txt报错后把堆栈丢给AI让它修改多轮对话后逻辑跑偏上下文丢失建立项目约定文档每个任务卡都引导AI先读文档代码过度设计AI默认追求“完整架构”审查时发现抽象层级过高直接重写为平铺代码SQL查询极慢缺少执行计划检查用EXPLAIN ANALYZE分析把执行计划丢给AI优化测试断言太弱AI默认只验证不报错要求每个断言必须有具体期望值否则测试无效依赖包冲突缺少全量依赖解析用pipdeptree分析让AI给出调整方案权限校验缺失AI不熟悉业务权限模型用“安全审查四问”强制AI自查前端交互不规范风格约定没有前置把交互规范写进任务卡如搜索、确认框、骨架屏接口参数边界不校验AI习惯信任调用方任务卡明确要求校验枚举值、时间范围、分页上限部署环境不一致本地与生产参数未同步环境变量模板和部署脚本都让AI生成并自动比对差异这张表是我这次项目过程中自己总结的基本覆盖了AI辅助编码中最常见的十类问题。你在自己的项目里大概率也会遇到其中两三类遇到时直接对照表格找方案就行。5.2 上线前我自己过的交付清单项目正式上线前我手写了一份交付检查清单把整个项目从头到尾过了一遍。这份清单不是AI生成的是我基于过往上线经验总结的在这里分享给你每一个API端点都跑通了冒烟测试且验证了参数校验逻辑。核心报表数据同手工从数据库里查出来的数字对比一致。定时任务连续跑48小时无异常任务失败有告警通知。所有敏感配置项数据库密码、API密钥都放在环境变量里没有硬编码。nginx配置了HTTPS和基本的请求限制防抖和防重放做了基础处理。数据库全量备份脚本和恢复演练各执行了一次。生产环境的Docker镜像是从CI流水线构建的不是本地手动打的包。文档补齐了部署手册、接口文档、数据字典、运维FAQ。每一个检查项通过后我都会在边上备注当时验证的截图和日志确保不是“我觉得应该没问题”而是“我已经用结果证明了没问题”。这套清单用了很多年以前手工开发时适用AI辅助开发时更加必要因为AI不会为你的上线负责只有你会。6. 复盘AI端到端交付我的真实感受项目交付到现在快一个月了线上运行稳定业务方反馈良好后台的自动报表每天准时推送没有出过幺蛾子。回过头看这次经历我最大的感受是AI并没有取代开发它改变的是开发的“手速”但没有改变开发的“脑力”。那些没有写代码的时间里我把省下来的精力全部投入到了更重要的事情上搞清楚业务方真正要什么、设计一个方便后续扩展的数据模型、确定合理的部署架构、做扎实的测试和质量门禁。AI帮我节省的是敲键盘的时间不是做决策的时间。如果你在项目中感到困惑多半不是因为代码写得慢而是因为目标和路径不清晰AI再好也帮不了你。最后说一个我自己的实用技巧每完成一个模块我会专门留十分钟让AI写一段“给未来维护者的话”内容包括这个模块为什么这么设计、有哪些潜在的坑、后续改动需要注意什么。这段内容放在代码文件的头部注释里虽然不会影响运行但对三个月后的我帮助巨大。AI生成的代码本来就是它的“思路产物”让AI自己解释思路远比我在代码里慢慢猜要高效。这个习惯我现在已经带到了所有项目里建议你也可以试试。
