1. 项目落地的第一道坎AI写出的接口为什么一上生产就崩先讲个我自己的真实经历。上个季度我接了个某库存管理Demo的私活客户要得急前后端加数据库要两周内跑通。我当时手里还有另一个维护项目时间根本不够于是第一次认真尝试用AI辅助做全流程开发。前三天特别爽——让AI生成用户模块的注册、登录、商品模块的增删改查接口代码刷刷地出几乎不需要我动手连SQL建表语句都给了一份。当时我心想这活稳了两周绰绰有余。结果第四天联调的时候直接翻车。前端调登录接口莫名其妙把用户名和密码拼成了一个对象传过去后端返回400商品列表接口明明写好了分页前端死活拿不到total字段一查发现AI生成的后端返回结构里根本没有这个字段。更离谱的是我在后端的用户表里加了一个is_active字段用来做软删除AI自动生成的ORM模型居然漏了这个字段导致所有查询都报错。这些问题没有一个是我主动去搜文档、查代码堆出来的全是在联调时由前端同事一个个帮我找出来的。后来我复盘了这件事发现一个很有代表性的规律AI生成的代码单看每个模块都很像回事但只要两个模块一交互就经常会出现接口字段对不上、类型不匹配、命名不统一这类问题。原因倒不复杂——AI是按你给的上下文逐段生成的它看到的只是局部它看不到你整个项目里字段的全局约定。所以它写登录接口的时候可能默认返回一个data对象封装所有信息而写前端请求的时候又习惯性地直接返回整个响应体。两边各自看起来都很合理放在一起就崩了。从这次经历之后我对AI编程的态度彻底变了。AI不是不能用而是不能把它当做一个“什么都会的同事”来用它更像一个“反应极快但缺乏全局意识的新手”。你要给它搭好框架、定好规矩、喂足上下文它才能发挥出真正的生产力。这篇文章我不讲那些玄学就把我从零到一用AI搭建一个全栈项目的完整链路、卡点、方法以及踩坑经验全部摊开讲适合那些正在尝试用AI提效、但总觉得“AI写的代码不敢用”的开发者和技术团队负责人。2. 前端不是堆页面而是学会让AI先搭骨架再填肉2.1 让AI生成前端页面的正确打开方式很多人用AI写前端第一反应就是甩给它一句话“帮我写一个商品管理页面要有表格、筛选、编辑弹窗、删除确认。”然后AI哗啦啦吐出一堆组件代码复制粘贴跑起来一看确实有表格有弹窗但布局很乱样式冲突状态管理一塌糊涂。你要改就得一句一句去调改着改着发现自己改的不比AI写的少干脆弃用。我试过几轮之后总结出一套比较高效的操作不要先让AI写完整页面而是先让它生成项目的目录结构建议和自己搭好基础骨架。以React技术栈为例我会先把我自己的目录结构标准定好比如components、pages、hooks、services、utils、types这几个基础目录然后在提示词里把结构全部明确写出来并附带当前项目的文件路径约束。举个例子项目是某库存管理Demo前端采用React TypeScript Vite。 请按以下目录结构生成代码 src/components/通用UI组件 src/pages/页面容器 src/services/接口请求封装 src/hooks/自定义逻辑 src/types/全局类型声明 src/utils/工具函数 其中types目录已经定义好下面的类型Product包含id、name、sku、stock、price、status、updatedAt字段请遵守这些类型定义。 现在请先创建商品管理页面的骨架代码包含 1. 页面顶部标题及“新增商品”按钮 2. 商品列表表格列的定义 3. 筛选表单的结构 4. 分页器占位 先不写逻辑只写结构和样式数据用mock。这一步的关键在于我提供了足够完整的上下文约束并且把任务拆得很小——只生成结构不生成逻辑。这么做的好处是极大的减少了“AI自由发挥”的空间。AI一旦被明确约束“先不写逻辑”它就很少再自作主张给你搞出一堆状态管理和自定义hook。生成的结果是个干净的页面骨架我只需要看一眼结构心里有数再一步步往下走。2.2 材料管理模块的批量生产与人工微调拿到骨架之后我会把具体功能拆成一个一个小卡片逐个让AI完成。所谓小卡片就是每个功能点单独写一个提示词一次只让AI做一件事比如请实现商品列表页面的数据请求接口为GET /api/products?page1pageSize10返回数据结构为ListResult{ list: Product[]; total: number }请将数据请求封装到services/product.ts中并在页面中用useEffect加载数据。请实现“新增商品”弹窗表单表单字段包括商品名称、SKU、库存、价格、状态其中价格为必填项提交成功后调用createProduct接口并刷新列表。这种颗粒度下的AI生成质量明显提高因为它面对的任务上下文是收敛的而且接口返回结构、类型定义都提前给好了。我只需要在它生成之后做两件事一是编译一遍看有没有TS类型报错二是跑一遍页面功能看交互是否符合预期。当然就算这么拆AI还是会有几个让我挠头的习惯。最典型的是它会习惯性地把很多操作塞进同一个函数里比如列表数据加载、筛选重置、开关切换、弹窗开关全堆在页面组件里导致一个组件文件几千行。遇到这种情况我的处理策略是下一步提示词里专门加一句“请把页面逻辑拆分为自定义hook组件只保留渲染和事件绑定”。还有一种情况是AI喜欢给组件加不必要的依赖库比如它为了做表单校验直接引入了一个没装过的validator库结果一npm install就报错。我现在会在系统提示词里提前写清楚“不要引入额外第三方依赖优先使用现有依赖和原生JS实现”这能帮我省掉大量装包和改包的时间。2.3 前端那些AI始终搞不定的“软磨硬泡”问题前端开发里有一类问题AI至今处理得不太好。这部分我把它总结为“软问题”——它们不报错、不崩溃但就是体验不对。比如动画过渡的微妙节奏、空状态与加载状态之间的切换时机、暗黑模式下某些颜色在特定屏幕上的对比度、移动端横屏时布局的异常表现。这些问题是需要实际打开浏览器、用真实数据、在多个屏幕尺寸下反复“看”才能感知的AI既没有视觉也没有真实环境它很难靠代码判断一个问题是否是问题。所以我的前端AI协作路线是能用AI解决的功能性、结构性、重复性工作尽量交给AI但对于视觉体验、动效细节、跨端兼容这类需要“感受”的部分自己上手做或者让AI生成多个版本自己选一个最合适的。拿表格加载状态举例。AI生成的列表页一般只有两态加载中显示一个loading组件数据返回后直接展示表格。但实际业务里常常出现第三种状态数据返回为空时的空状态页面。空状态在UI设计里是有讲究的要有插画、有引导文案、有操作按钮。你要是直接让AI写它大概率写一个“暂无数据”四个字。我会分两步走先让它把空状态和三态的切换逻辑写好再手动把空状态组件替换成设计师给的那个版本。这样AI做完了70%的结构性工作剩下的30%我只需要少量调整就能达到可发布的水准。3. 后端与数据层的AI协作边界能让AI做的和必须自己做的3.1 让AI写CRUD接口的正确姿势接口契约先行后端CRUD接口是AI最擅长的领域之一但同时也是最容易“看着能用、实则埋雷”的地方。我见过太多人让AI生成一个完整的用户管理系统AI很快给出了十几个接口的代码每个接口代码看起来都很有逻辑但数据库连接配置顺手写死密码加密用的是MD5分页逻辑没有处理页数越界事务完全没有加。这些都不是编译错误但每一个都是安全隐患或线上故障的种子。所以我现在给AI生成后端接口之前一定会先自己把接口契约全部定出来。所谓接口契约就是一份详细的接口文档包括每个接口的路径、请求方法、请求参数、参数类型、校验规则、返回结构、错误码约定。我把这份契约直接用提示词喂给AI让AI严格按契约实现。比如项目是某库存管理Demo后端采用FastAPI SQLAlchemy 2.0 PostgreSQL。 接口定义如下 POST /api/products - 新增商品 请求体{name: string(1-50), sku: string(5-20), price: number(0), stock: int(0), status: string(enums: online/offline)} 返回体{code: 0, message:ok, data: {id, name, sku, price, stock, status, updatedAt}} 请严格按照以上契约实现接口注意字段校验规则、事务处理和错误码约定。 错误码约定见项目根目录docs/error_codes.md。有了这套契约以后AI生成接口的准确率会非常高因为它的“自由发挥”空间被压缩在了最小的范围内——只需要写实现逻辑不需要设计接口格式。我是真的实测过同一个项目没用契约之前前端联调大约要花两三天时间在字段对齐上用了契约先行之后后端几乎一遍过前端拿到接口文档直接就能接上联调时间压缩到了半天以内。3.2 数据库建模AI可以给建议但要自己拍板数据库建模这件事我的态度始终如一AI只能当参谋绝不能让AI当指挥官。为什么因为数据库表结构一旦定下来后期改造成本极高。加一个索引可能要动用大量数据迁移改一个字段类型可能要把整条业务链路都带崩。这是一个典型的“前期决策”场景必须人工拍板。但AI在建模阶段还是很有用的——可以让它扮演“提问者”而不是“设计者”。我会把自己的初步设计发给AI让它从数据库范式、索引设计、常见查询模式、扩展性这几个角度给我挑毛病。比如我设计了一张商品表把供应商信息直接以JSON格式存进去AI会立刻提出反范式设计的顾虑并建议拆分为supplier表和product_supplier关联表。这个建议合不合理我可以自己判断——如果是低频使用场景JSON字段也许更省事如果需要高频按供应商维度做统计就应该拆表。AI给的是选项和提醒最终拍板的还是我。另外要特别提一个坑AI默认生成的模型里经常不包含数据库层面的默认值、索引、唯一约束。比如SKU字段理应唯一AI生成的模型里可能只是一个普通字符串字段。这种事情AI不会主动提醒你因为它不知道业务上方SKU这个字段是不能重复的。所以在让AI生成模型文件之前我建议把这类约束单独写成一个清单人工自己的笔记提一遍再放进提示词里。你用的顺手之后会明白一个道理后端让AI干的活越多前期约束就要定得越细否则返工率反而比你自己写还高。3.3 鉴权与性能优化不能放给AI自由发挥的“暗礁区”整个后端所有模块里有两条线我是绝对不会让AI自动设计的一是权限认证二是性能优化策略。不是说AI做不了而是这两个模块一旦出问题影响是系统性的、全局性的——轻则数据泄露重则服务崩溃。我自己的做法是鉴权逻辑自己先写好基础框架再让AI基于已有框架去扩展。比如我先把JWT签发的中间件、角色校验的装饰器、白名单配置全部写成一个基础模块然后再让AI基于这套已有的鉴权基础去写业务接口同时在提示词里大声强调“所有接口必须经过当前鉴权逻辑不能在接口内部自定义任何鉴权逻辑”。这样AI生成的接口天然就复用了我搭好的安全框架不会自己另起炉灶。对于后端性能这一块我更倾向于让AI输出分析建议而不是直接让它写代码。比如我会把当前列表接口使用的SQLAlchemy查询语句贴给AI请它分析是否存在N1查询问题、是否缺少必要的index、是否需要使用懒加载替代方案。它给出的分析与优化建议会比较合理因为这种问题本质上是固定的模式识别。但我会自己逐条评估每条建议的收益和风险再决定是否采纳。有一次AI建议我把某列表查询改成原生SQL以提升性能我拒绝了因为我们的数据量三个月内在几千到几万级别ORM相对原生SQL的差距完全在可接受范围内但代码可读性和维护成本会急剧恶化。这种取舍AI是拿不准的因为它看不见业务的实际数据规模。4. 联调、部署与数据初始化AI难以替代的“最后一公里”4.1 前后端联调阶段我用AI做接口自测和文档生成全栈项目推进到前后端联调通常是最紧张的阶段。前面单模块测试都跑通了两个模块一拼就可能出现各种令人头大的不兼容。以往这个时候我会花很多精力去对照接口文档逐项核查字段和类型。现在我用AI把这些琐碎工作压缩到了一个比较可控的范围。我的操作方法是让AI总结前后端对接的关键字段表。我会把后端接口契约文档和前端TypeScript类型定义都贴给它请它生成一个“字段一致性对照表”例如接口返回的是productId和product_name前端类型声明里写的是product_id和productNameAI可以快速把这种不一致的地方标记出来。省去了我自己一行行对字段的巨大工作量。另外一个很实用的做法是让AI帮忙生成接口自测用例直接用curl命令或Python脚本的方式运行这样我在写代码的同时就能验证接口不用每次都打开前端页面去点。4.2 数据初始化与种子脚本AI意外好用的一个细分场景说实话对于AI编程我一直是持“工具人”心态的直到我遇到种子数据脚本这个任务让我对AI的看法有了非常明显的改观。当时我给某库存管理Demo写种子脚本需要造一万条商品假数据包括随机名称、随机SKU、随机价格和库存还要模拟出“部分商品长期库存为零”的业务场景。这种任务本质上就是写一个for循环加随机数生成器逻辑极其简单但数据格式要求很多自己一条条写模板得磨半天。我用一个自然语言描述清楚了需求AI直接生成了一个完整的Python脚本连接PostgreSQL用transaction方式批量写入数据还自动模拟出了按类别分布的数据。我大概花了十分钟改了一下随机数种子和业务参数剩下的脚本直接跑一万条数据几分钟就灌进去了。这体验是真的舒服。所以我现在遇到类似“批量生成、转换、验证”这类工具型脚本都会优先交给AI它非常适合这种高熵低复杂度的工作。4.3 部署时AI的高光时刻与隐藏的大坑部署环节可能是AI编程全流程里最受益的部分了。当年我手动配Dockerfile和Nginx踩过的坑写一篇长文都不够后来有了AI只要把技术栈和部署目标描述清楚AI基本能给出可直接跑的Dockerfile、docker-compose.yml、Nginx反向代理配置甚至包括申请HTTPS证书的步骤说明。这个效率提升是实实在在的。但AI在部署层面同样有一个非常大的坑配置版本漂移。它给出的Dockerfile往往依赖它“记忆中”的软件版本号和基础镜像。比如它可能给你指定python:3.10-slim但你本地开发环境是3.12package依赖解析规则有了变化代码可能一跑就报错。所以我现在用AI生成的部署配置时会强制自己在第一遍review时确认所有版本号与本地环境一一对应。还有一个我踩过很多次的坑AI生成的entrypoint脚本里往往漏掉了“等待数据库就绪”的环节。容器编排之后你的应用容器可能先于数据库容器启动应用去连数据库直接失败退出。遇到这种情况不要慌不要觉得是AI没用而是要在生成的docker-compose里自己加一个healthcheck和depends_on的condition控制这个细节AI经常漏但从生产稳定性来说是必须的。5. AI全栈开发的核心方法论把提示词工程变成系统工程5.1 提示词里必须有的四个要素角色、上下文、约束、交付格式写到这里我发现整篇内容其实汇总成一句话就是AI编程的本质是系统工程提示词技巧只是其中的一个环节。但为了让整篇更系统我还是把我积累下来的提示词四要素模板完整分享出来。不管你是做前端、后端、脚本还是部署只要遵循这个框架AI生成代码的可用率会有非常显著的提升。四个要素分别是角色定义明确AI在本次任务中的身份比如“资深后端工程师”“全栈架构师”“可读性要求高的代码评审员”。上下文注入把项目背景、技术栈、目录结构、已有文件关键内容、接口契约、依赖版本全部放进去上下文越准确生成越精准。约束条件禁止引入新依赖、禁止自定义鉴权、字段名称必须遵循既有类型、不允许修改现有文件、只生成指定文件这类硬约束要给足。交付格式要求AI输出文件路径、代码内容、变更说明、运行命令如果有风险点要标注风险这样你拿到结果才能立刻使用。我拿我自己常用的一个提示词模板做例子给大家参考你是一名高级全栈工程师正在参与项目[某库存管理Demo]的开发。项目技术栈前端ReactTSVite后端FastAPISQLAlchemyPostgreSQL。 请完成下面的任务并严格遵守以下规则 1. 文件必须放在指定路径路径我会逐一给出。 2. 禁止引入任何新的第三方依赖。 3. 类型必须引用src/types.ts中已有的类型定义。 4. 请输出文件路径、完整代码、变更说明、运行/测试方式、潜在风险点。 5. 完成后请自我检查一遍代码说明你检查了什么。 任务[在这里描述具体需求]这套模板我用了大半年判断下来适合所有基于大模型做代码生成的工作可能是性价比最高的“投喂”方式。核心思路就是让AI变成一个有纪律的执行者而不是自由创作人。5.2 双层校验机制AI生成代码必须过编译和过“提问”AI生成的代码我非常不建议直接合并进主分支。至少要做两层校验。第一层是机器校验也就是编译、跑测试、跑lint这层通常很快能过滤掉大部分语法和类型错误。第二层是我自己称为“提问校验”的环节——每次AI生成完我会让它先写一段自述解释它的实现思路而我则要看代码时脑子里不断提问自己“这个分支什么条件下会触发这个函数被谁调用如果输入为空会怎样这个方法的事务在异常时会不会回滚”如果我在这个过程中发现任何一个地方回答不出明确答案就必须回读代码搞明白或者直接让AI重写那一部分。这里必须要多句嘴AI写代码经常会“用上Inception式的聪明”。比如我在让AI写一个批量删除商品的功能时它内部用一种“先查全部符合条件的ID再逐条删除”的方式实现。功能本身没问题但当数据量上万时这个方案会产生大量查询和慢事务非常影响性能。这种问题是不会编译报错的也不会在测试接口时暴露直到生产环境数据量上来才爆发。所以我的建议是AI生成代码对任何涉及循环操作数据库、批量任务、文件IO的操作你都必须额外专项检查一遍复杂度轻易不要相信“AI已经优化过”这种话。5.3 从“靠AI生成”到“用AI管理”的转变代码库整体认知的提升用AI的时间长了以后你会发现一件事情AI编程真正能改变效率上限的能力不在于你让它生成了多少代码而在于你用它的方式是否从“点对点完成任务”升级成了“用AI管理整个项目的开发节奏”。什么意思呢就是你可以让AI帮你审阅全量代码列出当前项目的技术债可以让AI帮你整理接口文档并在接口变更时同步更新可以让AI根据你的commit记录生成阶段性的周报说白了就是让AI承担更多的项目管理和知识沉淀工作。比如我每完成一个模块会做一次“全量代码快照提示词”把涉及的目录结构和关键文件都贴给AI请它做一个模块级别的代码审查提出潜在的性能问题、安全问题和可维护性建议。这种事如果靠人工做非常耗费精力而且容易漏掉低频的边界分支——AI在这方面反而有优势因为它有足够的“耐心”一条条过你的代码而且不会因为看多了而疲劳。拿我上个月做的一个某任务协作Demo来说我把图片上传、评论、任务分配、消息通知四个模块写完以后用AI做了一次整体验收它居然在评论列表的接口里发现了一个未加索引的userId字段查询——在数据量大时会全表扫描这个点是我自己review时完全没注意到的。这类人均会犯的低频错误AI反而是最佳的检查者。5.4 实践出真知哪类任务适合AI哪类任务必须自己来最后我把这段时间使用AI编程攒下的一些判断标准分享给大家。这个标准既来源于大量成功案例也总结于反复翻车的教训希望你在使用过程中少走弯路。适合AI的任务典型特征逻辑清晰、功能边界明确、重复性高、依赖标准库常见模式。比如CRUD接口、页面骨架、表单组件、Dockerfile、正则校验、日期处理、数据转换脚本以及测试用例的基础框架。这类任务AI生成质量稳定返工率低能大幅压缩工期。不适合AI的任务典型特征需要深度业务判断、涉及全局副作用、对性能和安全高度敏感、需要行业经验来拍板的。比如数据库最终建模、付费与权限体系、支付回调处理、复杂事务回滚逻辑、高并发链路设计、以及任何需要“面向未来评估”的架构选型。这类任务你让AI参与提建议、做评估都可以但最终写代码和做决策我更建议人工完成。写在最后的一个实用建议如果你看完这篇文章想立刻实践我给你一个最小可行方案拿一个你之前自己写过的小项目不要开新项目而是把旧项目作为上下文喂给AI让它完成一个新增的小功能模块。这样你能同时对比“自己过往的思路”和“AI建议的方案”之间的差异同时验证接口契约、类型约束这些方法论在你的项目上是否生效。我在脱离自己熟悉项目让AI从零搭全栈时吃过很多亏反而是回到熟悉的项目里AI生成的东西我一眼就能判断是否可用再逐步放开范围最后才建立了对AI生成代码的信任和安全感。AI编程这条路最有趣的地方也是最有风险的地方在于它会给你一种“一切尽在掌握”的感觉。你生成的代码越多越需要审慎地确认它们是否符合你的真实意图。我的体会是保持“人做决策AI做执行”的边界你就是AI的主人一旦连决策权都交给AI你大概率会在某个凌晨三点被生产环境的电话叫醒。
