AI辅助开发高品质Web应用：完整工作流与实战指南

做Web应用开发这些年我最近一年的编码节奏发生了很大变化从以前一个人硬扛需求到现在每天至少有三分之一时间在和AI结对写代码。最初我也怀疑过AI生成的东西到底能不能上生产环境但当我用AI辅助完成了一套包含用户权限、飞书登录、数据报表和审批流的企业级Web应用后态度彻底变了。现在的“用AI打造高品质Web应用”不是口号而是一条已经跑通的工作流。它不负责替你拍板但能帮你把架构设计、接口开发、测试用例、部署脚本这些原本需要大量时间的环节压缩到让人不太适应的速度。这篇文章我会完整拆解这套工作流包括怎么选技术栈、怎么写提示词、怎么让AI从0到1帮你生成Flask/FastAPI/Django应用以及AI Agent在业务逻辑里到底能承担什么。适合正在尝试用AI写业务代码的前后端工程师、全栈开发者也适合技术负责人用来评估AI辅助开发的真实边界。我不会只聊概念而是把能直接抄的步骤和踩过的坑都写出来。1. 项目整体设计与思路拆解1.1 为什么是“AI辅助开发”而不是“AI自动开发”很多人对AI写代码的第一反应是把需求丢给它出门喝杯咖啡回来就有一个完整系统。这种期待我用半年时间终于彻底放弃了。现实中AI更像一个知识面极广、手速极快但偶尔会一本正经胡说八道的初级工程师。你在旁边当架构师它负责执行你把需求说清楚它帮你生成代码但你如果完全放权没多久就会得到一堆看似能跑、实则难以维护的“代码屎山”。我做的企业级Web应用涉及多表关联、角色权限、第三方登录、审批流引擎这类业务逻辑环环相扣任何一个生成错误都会在后期暴露成严重问题。所以整体设计思路是把开发拆成需求分析、技术选型、骨架生成、数据库设计、业务编码、测试部署六个阶段让AI在每个阶段都担任不同角色。它可以是需求讨论时的“业务分析师”技术选型时的“行业顾问”写代码时的“高级程序员”排错时的“代码审查员”。这种做法的好处很明显AI不会累也不会有“差不多就行”的心态。只要提示词写得足够具体它给出来的代码比团队里很多初级开发更规范。坏处也很明显它的上下文窗口有限一旦代码库变大它会开始遗忘之前的约定甚至在一百行代码里自己打自己的脸。因此你需要人工维护“关键决策文档”和“项目规范文件”并频繁把它们喂给AI这样才能让AI辅助开发持续稳定地保持质量。1.2 目标拆解从需求到上线的AI切入点一个高品质Web应用的定义不只是“功能能跑”还包括响应性能、安全性、可维护性、可观测性。如果你想用AI做全流程提效先得知道自己要在哪些环节投入多少人力和提示词成本。我建议按下面这个表格规划切入点。阶段传统工作量AI能力的切入点人工必须守住的部分需求分析高生成调研提纲、竞品功能清单、用户故事业务判断、价值优先级排序技术选型中对比框架优缺点、根据团队能力推荐栈真实业务约束、长期可维护性数据库设计中高生成建表SQL、补充索引和约束核心业务关系、数据一致性边界接口开发很高生成RESTful接口、参数校验、接口文档鉴权模型、异常处理策略前端页面中高生成Vue/React组件、样式骨架交互体验、设计一致性测试高生成单元测试、集成测试、边界用例关键业务规则、断言准确性部署运维中生成Dockerfile、CI/CD配置、监控告警规则基础设施权限、故障应急方案你会发现AI在“生成型任务”上表现惊人在“决策型任务”上只能当顾问。这决定了整套工作流的核心设计原则尽量让AI产出内容然后由人来做选择题和判断题而不是让AI去做开放题。每次开启新的功能模块前我会让AI先给我三套实现方案再从可维护性、团队熟悉度、未来扩展性三个维度打分。这个过程看起来多花了几分钟但能省掉后面几小时的返工。2. 工程准备选型与提示词工程基础2.1 技术栈选型时的AI辅助决策在“用AI打造高品质Web应用”的工作流里选什么技术栈直接影响AI生成代码的质量。我个人的偏好是给AI一个明确的主流框架而不是让它自由发挥。如果你对它说“帮我做一个Web应用”它可能会返回Node.js、Python、Go、Java混合方案最后你根本不知道项目怎么落地。如果你要做一个快速验证的产品原型Flask或FastAPI是很干净的选项。Python的生态让AI训练数据覆盖率高生成代码时不容易出现离奇Bug。如果你的项目业务比较重需要ORM迁移、Admin后台、权限系统Django框架几乎是AI最擅长的领域因为社区案例和海量教程让AI对Django的类视图、信号、迁移机制都非常熟悉。如果团队技术栈是Java且有AI Agent相关需求Spring Boot加Spring AI的组合值得认真考虑尤其是做企业内部系统时Spring的生态规范和事务管理能让AI生成的内容更可控。我做过一个真实选型一个内部系统需要对接飞书登录后端要求认证安全、数据权限灵活。当时用AI分别生成了Flask版本和Django版本的登录集成示例对比后选择了Django。原因不是AI代码多漂亮而是Django自带的User模型、权限中间件和迁移机制能把认证这类安全敏感逻辑收敛在框架默认能力里降低AI错误代码造成安全漏洞的可能性。这个决策就是AI辅助完成的它负责举例对比我负责看到背后的风险模型。2.2 高质量提示词的三个底层逻辑想用AI生成高品质代码提示词不能是“帮我写一个登录接口”这种一句话需求。我总结出三个底层逻辑几乎适用于所有AI编程工具。第一个逻辑是给AI一个明确的角色和工作上下文。不要只说“你是Python专家”而是“你是一位拥有十年Django开发经验的后端工程师在项目中负责设计RESTful API。现在要开发一个用户登录接口技术栈是Django 5 Django REST Framework数据库采用PostgreSQL。项目里有统一的响应格式所有接口都要求写单元测试”。角色限定之后AI的语气、代码风格、默认假设都会更加贴近目标框架。第二个逻辑是给AI限制条件。限制条件包括不要使用某个已废弃的库、只允许使用ORM操作数据库、禁止在视图里处理复杂业务逻辑、状态码必须符合HTTP语义。没有边界约束的AI会自由发挥最后产出一堆“能跑但没人敢维护”的代码。限制条件越严苛AI生成的内容越接近团队规范。第三个逻辑是给AI提供例子。你要什么风格的代码就直接贴一段现有代码片段说“请按照这种风格继续写”。AI最擅长模式补全给它模板和例子它能以极高保真度模仿上下文。这套方法论在文档生成、测试用例生成、前端组件开发时同样有效核心就是让AI从“想象需求”变成“模仿范例”。2.3 适配不同模型的实操技巧目前主流AI编程工具有两类一类是IDE插件专注代码补全比如Cursor、GitHub Copilot它们能读取整个项目上下文适合“把光标放在注释后面写函数实现”这种交互另一类是大模型对话窗口比如ChatGPT、Claude和国内大模型产品它们适合项目启动期的大段代码生成和方案推演。两类工具我都用但用法完全不同。IDE插件类工具的关键在于注释质量。我以前习惯先写代码后补注释但用AI编程后我养成了先写详细注释和函数签名、再让模型补全实现的习惯。举个例子在Cursor里写“从请求头获取Token调用第三方接口校验有效性如果无效抛出特定异常如果有效返回用户ID”AI接着生成的代码比直接给它一个空函数要准确很多。写注释不是浪费时间而是把需求结构化传给模型的低成本方式。对话窗口的大模型更适合生成完整模块。我遇到过一个麻烦项目里有几十个文件一次性全告诉AI根本不现实而且它的输出长度通常有限制。我的破解方法是让它分步骤生成并告诉它“先生成models.py再生成serializers.py等我说继续之后再生成views.py”。模块之间的依赖关系我会在每轮对话开头重复描述避免AI因为上下文遗忘而产生前后矛盾。对于代码生成结果我反复提醒自己AI生成的代码只是“初稿”它的价值是帮你把80%的流水线代码写完剩下的20%业务细节才是需要你一字一句审视的部分。3. 核心实操用AI完成Web应用从0到13.1 需求分析与数据库建模高品质Web应用的起点不是代码而是数据模型。如果你上来就逼AI“生成整个系统”结果一定是灾难。我的做法是先把业务对象想清楚然后让AI帮我补全细节。举一个实际例子。我要做一个“企业审批系统”分析到主要对象有用户、部门、审批单、审批记录。我会这样给AI提问“我们是一个50人规模的公司内部系统需要实现差旅报销审批。以下是核心业务规则员工提交报销单部门经理审批金额超过5000需要总经理审批财务复核后打款要求记录每一步操作人和时间。请帮我分析实体关系并生成PostgreSQL建表语句要求包含必要的软删除标记和创建时间索引。”这个时候AI通常能生成一张非常合理的表user表、expense_sheet表、approval_record表外加deadline字段。但也不要完全照单全收。AI很容易在金额字段上使用float而财务金额应该用decimal类型AI也容易忘记给外键建索引AI在枚举状态字段上可能生成varchar实战中我更倾向用smallint或数据库枚举。所以生成完建表SQL后我会自己过一遍把不合理的数据类型、缺失的唯一约束修补好然后再贴回给AI让它写CRUD接口。数据库建模中另一个容易被AI“糊弄”的是软删除和逻辑外键。AI默认很多开源项目模板都有软删除字段但你的业务可能并不需要。如果你没有在提示词里讲清楚它会把一切都加上软删除导致后续每次查询都带上一堆过滤条件。我现在会明确写出“本项目不需要软删除物理删除即可”AI就能少生成很多多余代码。3.2 快速生成项目骨架Flask到Django5有了数据模型之后项目骨架的生成就极其高效。如果你是做一个API服务用Flask可以非常快速地把Hello World级别的应用扩展开来。比如我先让AI生成下面的最小骨架from flask import Flask, request, jsonify from flask_sqlalchemy import SQLAlchemy from flask_migrate import Migrate app Flask(__name__) app.config[SQLALCHEMY_DATABASE_URI] postgresql://user:passlocalhost/dbname db SQLAlchemy(app) migrate Migrate(app, db) class User(db.Model): id db.Column(db.Integer, primary_keyTrue) username db.Column(db.String(64), uniqueTrue, nullableFalse) email db.Column(db.String(120), uniqueTrue, nullableFalse) def to_dict(self): return {id: self.id, username: self.username, email: self.email} app.get(/health) def health(): return jsonify({status: ok})这个骨架虽然简单但已经包含了数据库连接、模型定义和健康检查。如果要让AI继续生成用户注册和登录接口我会提醒它“密码只能存哈希使用werkzeug.security生成哈希禁止明文保存”。AI在这一步通常会遵循得很好因为安全要求足够明确。如果是企业级应用我更喜欢让AI直接生成Django5工程结构。我常用的指令是# 项目名和使用虚拟环境 python -m venv venv source venv/bin/activate pip install django djangorestframework django-cors-headers django-admin startproject config . python manage.py startapp account然后我会让AI在描述里写明“批量生成Django项目配置、用户模型、自定义权限、JWT认证、基础表结构”。Django的迁移系统非常适合AI辅助因为它不需要手动维护数据库脚本模型一旦确定执行python manage.py makemigrations python manage.py migrate即可。这也是比起Flask我用Django承担大型任务更顺手的原因AI生成后迁移是否成功可以立即得到反馈。3.3 登录鉴权与飞书登录的AI实现飞书登录是热搜词里出现的一个真实场景我也在公司的Web应用里落地过。第三方登录本质是OAuth2.0授权码流程AI对这套流程的训练数据很充足但涉及具体App ID、App Secret、回调URL时AI编造的配置经常对不上。因此我会把协议流程告诉AI然后让它帮我实现回调处理逻辑而不是让它猜飞书开放平台的接口地址。在实际项目中飞书登录的流程可以简化为三步。第一步前端跳转到飞书授权页携带client_id、redirect_uri和state参数。第二步飞书回调地址会带上一个临时授权码code。第三步后端用这个code换access_token再拿access_token获取用户信息。AI最适合生成的是第二步和第三步的代码。下面是一段AI辅助生成并经过我人工修正的Django视图import requests from django.conf import settings from django.shortcuts import redirect from rest_framework.views import APIView from rest_framework.response import Response from .models import User from .utils import generate_jwt FEISHU_TOKEN_URL https://open.feishu.cn/open-apis/authen/v1/oidc/access_token FEISHU_USERINFO_URL https://open.feishu.cn/open-apis/authen/v1/user_info class FeishuCallbackView(APIView): def get(self, request): code request.query_params.get(code) if not code: return Response({error: missing code}, status400) token_resp requests.post(FEISHU_TOKEN_URL, json{ grant_type: authorization_code, code: code, client_id: settings.FEISHU_APP_ID, client_secret: settings.FEISHU_APP_SECRET, }, timeout10) token_json token_resp.json() if token_json.get(code) ! 0: return Response({error: token_json}, status400) access_token token_json[data][access_token] user_resp requests.get(FEISHU_USERINFO_URL, headers{ Authorization: fBearer {access_token} }, timeout10) user_json user_resp.json() union_id user_json[data][union_id] user, created User.objects.get_or_create( feishu_union_idunion_id, defaults{name: user_json[data][name]} ) return Response({token: generate_jwt(user)})这段代码看起来不错但有几个坑是AI不会主动告诉你的。比如飞书不同版本的接口域名和参数格式有差异部分旧接口返回结构不一样比如如果用户之前用手机号注册过单纯用union_id去get_or_create会生成一个重复账号。这个业务冲突必须由你来定策略AI能提供的只是“是否允许绑定已有账号”的实现选项。还有安全细节state参数要校验防止CSRF攻击AI生成的代码里经常忽略。自己在用AI写第三方登录时一定要把“校验state防止跨站请求伪造”写进提示词。AI知道有这个知识点但不会每次都主动做。3.4 用AI Agent处理复杂的多步业务流程除了AI辅助编码AI Agent本身也可能成为Web应用业务逻辑的一部分。现在越来越多Web应用会把大模型封装成对话接口用户问“我的报销单到哪一步了”后端让模型检索工单状态后自然语言回答。这里的关键不是聊天本身而是让AI Agent能够调用内部接口我们一般称之为Function Calling。用Python实现一个简单Agent时我会让AI先生成函数定义列表告诉大模型有什么函数可以调用。例如获取审批单状态、获取用户报销额度、提交新的审批请求。当用户输入“帮我查一下上月报销状态”时模型解析意图后返回一个需要调用get_approval_status动作的JSON后端再执行真实查询最后把结果交给大模型整理成自然语言。这个实现最考验提示词和数据结构设计的统一。如果你让AI直接生成整套Agent框架往往会得到一个非常复杂、包含向量数据库和记忆模块的重型系统。对于大多数企业Web应用你需要的只是一个轻量的规则增强式对话服务。我倾向于用FastAPI加一个简单的路由函数from openai import OpenAI client OpenAI(api_keyyour-key) tools [ { type: function, function: { name: get_approval_status, description: 根据工单号查询当前审批状态, parameters: { type: object, properties: { ticket_id: {type: string} }, required: [ticket_id] } } } ] def call_agent(user_message: str): resp client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: user_message}], toolstools, tool_choiceauto, ) return resp.choices[0].messageAI在这里只负责意图解析和参数抽取真正的业务查询由本地代码完成因此能保持很高的可靠性。要记住AI Agent绝不能直接连接数据库让它自由生成SQL否则用户一句“把账单表删了”就可能触发严重事故。所有高风险操作都应该收敛到白名单函数里。4. 质量保障AI辅助测试与性能排查4.1 让AI生成单元测试的正确姿势高品质应用离不开测试而AI写测试用例的速度确实远超人工。最开始我让AI“给登录接口写测试”它确实生成了十几条用例但不少断言是错误的。后来我把提示词改成“根据以下业务规则生成pytest测试1. 用户名和密码正确返回200和token2. 密码错误返回4013. 用户名不存在返回4044. 同一IP连续失败5次后锁定10分钟”。规则明确后测试代码的精确度一下子高了很多。测试生成时AI一个很大的毛病是“自嗨式断言”。它会生成一个用例调用接口后断言response.status_code 200但它不一定知道你的接口成功时返回的是201还是200。因此让AI先生成测试用例清单而不是直接生成代码可能是一个更安全的做法。你可以先问它“针对这个接口有哪些边界条件需要覆盖”让AI列出清单你审阅后再让它“按清单一个个生成测试函数”。这样既发挥了AI的整理能力又保证断言逻辑经过人的判断。依赖外部服务的测试也需要提前约束。飞书登录接口、短信发送接口这些无法在测试环境真实调用的服务要让AI用Mock或者依赖注入来模拟。如果不加说明AI生成的测试会真正发起网络请求让整个测试套件变得又慢又不稳定。现在我在项目里已经习惯了用pytest的monkeypatch工具替换外部客户端而这些修改思路往往是我在要求AI“不要访问真实网络”之后它主动给出的方案。4.2 SQL慢查询与缓存设计Web应用性能不行十有八九出在数据库。AI在这方面能做两件事分析慢查询日志以及帮忙优化ORM代码。有次我在Django项目里发现一个接口响应特别慢后端日志显示某个count查询执行了1.2秒。我把这条SQL和涉及的模型定义发给AI它很快指出EXISTS子查询没有建索引而且因为ORM里使用了select_related但没有加上only一次查询拉回了七张表的全部字段。用AI优化性能时我习惯把真实执行计划一起贴给它。PostgreSQL里执行EXPLAIN (ANALYZE, BUFFERS)的输出AI是能读取并给出具体建议的。比如它看到Seq Scan后建议改成索引扫描看到Nested Loop行数膨胀后建议调整关联顺序。不过这些建议的价值取决于你提供的信息是否准确。你不能只丢一句“系统很慢”而是要把接口代码、模型定义、数据库版本、慢查询日志原样贴进去AI才能定位到真正的瓶颈。在高频读取场景下AI也很擅长生成Redis缓存代码。一个典型的用户Token校验缓存我会让它“查询用户信息前先查Redis缓存时间300秒用户资料更新时主动失效缓存”。这种代码模式非常成熟AI几秒钟就能给你一个包含回退逻辑的正确实现。但缓存一致性始终是业务问题如果允许用户多端登录用Redis存Token列表的方案会导致旧Token失效逻辑复杂化这些业务限定词必须在需求里写清楚否则AI只会给你一个通用且未必适合你的实现。4.3 安全测试与依赖漏洞扫描高品质Web应用的安全防线不能依赖AI自动兜底。AI能帮你生成很多安全相关代码但它也很容易错过业务逻辑漏洞。我更推荐把AI用在“代码审查”环节。写完一段接口代码后我会把它贴回大模型并问“请从安全角度审查这段代码重点关注越权访问、SQL注入、XSS、CSRF和不安全的反序列化问题。”这种审查经常能发现一些低级但致命的错误。比如有一次我让AI生成一个按ID更新订单的视图函数它默认任何登录用户都能修改任意订单。AI如果只考虑功能实现完全不会意识到这个接口存在水平越权漏洞。审查提示词里必须加上一条“所有涉及用户私有数据的API必须先验证当前请求用户是否有权限操作该资源。”它能识别这条原则并在生成代码时加入一行行权限判定。依赖漏洞扫描则不用麻烦AI直接在CI里挂上pip-audit、npm audit这类工具更靠谱。AI更适合做的是漏洞修复指导扫描结果告诉你某个库有漏洞但升级之后可能带来破坏性变更你可以把当前代码中涉及该库的用法和报错信息发给AI让它给出的升级迁移方案往往比看官方文档更快因为它能理解你的具体上下文。5. 部署上线与模型集成5.1 Dockerfile与CI/CD自动化配置部署环节可能是AI辅助开发中“性价比”最高的部分。它生成Dockerfile、Nginx配置、docker-compose编排、GitLab CI或GitHub Actions的速度远超人工手写。而且这个领域的AI训练数据极其丰富常见的坑它基本都知道。我之前生成过一个Python Web应用的DockerfileAI给的版本会根据requirements.txt安装依赖、使用gunicorn运行Web服务、暴露端口后执行CMD。但它默认的Python镜像版本太旧直接导致某些新依赖安装失败。后来我把提示词修改为“使用python:3.12-slim镜像先安装gcc等构建工具再安装requirements.txt”并把构建过程中遇到的错误信息贴给它AI很快给出了修复版本。CI/CD流水线的生成也是同样思路。让AI生成“每次push到main分支时先运行pytest再用Docker build镜像然后推到私有仓库最后ssh登录服务器执行docker compose up -d”。这种流程描述非常清晰AI会直接生成一份可用的GitHub Actions配置。但是服务器地址、密钥管理这些敏感信息要使用仓库的Secrets功能注入绝不能写死在配置文件里。这属于安全红线AI虽然知道但你还是要在审查时睁大眼睛。5.2 大模型API接入与私有化部署取舍如果你的Web应用要接AI能力比如做一个智能客服、自动生成文案的工具你必然面临一个选择调用云端大模型API还是私有化部署开源模型。用AI辅助开发时这个选型决策同样可以让AI帮你整理利弊。云端大模型API接入速度最快比如OpenAI兼容接口、国内大模型平台通常一个API Key就能开始联调。我的做法是做一个统一的大模型客户端封装层内部通过环境变量切换不同的服务商。这样模型升级或供货商变化时业务代码不需要改。AI很擅长写这种适配器让它从一个LLMProvider抽象类分别生成OpenAIProvider、本地OllamaProvider整个接入过程几乎无痛。但私有化部署的复杂度是另一个量级。你得考虑显存、量化、推理框架、并发队列和模型效果调优。如果你只是做企业内部员工问答一个7B或14B量级的中文模型在专业显卡上做量化部署基本够用但如果是高并发面向C端的复杂推理预算和延迟都会成倍上升。这个时候让AI写部署脚本反而意义不大关键是你对成本和场景的判断。我的做法是先用AI快速浏览几十份开源模型的技术评测并列出候选再人工做一些基准测试确认效果达标后才让AI去生成部署相关代码。5.3 可观测性日志、链路追踪与告警高品质Web应用的另一个标志是可观测性。平时开发中你还能靠本地日志排查问题上线之后如果服务挂了但不报错整个团队都会抓瞎。AI在这个环节能帮我们生成标准化的日志埋点和监控规则。在Python项目中我用的是structlog加Prometheus指标。我要求AI在关键接口打结构化日志包含request_id、user_id、path、status_code、duration_ms。AI通常能很准确地完成这些埋点。但是要它生成监控告警规则时会出现比较明显的套模板问题它可能给你一个CPU使用率超过80%告警的PromQL但你的业务更关心“订单接口成功率低于99%”或“消息队列积压数量超过阈值”。所以与其让AI凭空生成监控规则不如把你已经能感知到的服务级别指标告诉它让它生成默认阈值和查询语句。AI可以作为告警规则初稿的生成器但阈值要不要调整只能由熟悉业务的人决定。毕竟如果阈值设得太敏感告警轰炸会让团队对告警失去信任这种隐形代价比代码Bug更麻烦。6. 常见问题与避坑指南6.1 AI辅助开发常见问题速查表为了让后来者少踩坑我把这段时间反复遇到的问题整理成一个速查表。问题现象根本原因解决思路AI生成代码用了不存在的库模型幻觉库名与真实包名不相符提示词要求“只使用PyPI上主流稳定版本”报错后贴回给AI修正代码风格前后不一致上下文过长导致模型遗忘早期约定维护项目规范文档每次让AI阅读后再生成代码接口路径或参数与前端对不上前后端由AI分别生成缺少对照先统一生成OpenAPI文档再分别实现前后端数据库迁移反复失败AI修改模型后没有同步检查已有数据要求AI先生成迁移计划再单独执行makemigrations测试用例能跑但断言无意义AI“自嗨式断言”未理解业务规则先让AI写测试用例清单人工审阅后再生成代码安全漏洞被忽略AI默认只关注功能实现主动要求AI做安全审查并加入越权、注入等专项检查第三方登录回调报错回调地址或OAuth参数配置错误先用真实回调参数进行本地联调再让AI修正回调逻辑这个表格里的问题我基本都踩过一遍。尤其“AI生成代码用了不存在的库”这条是我建议每个团队都建立防范机制的。比如Python的flask-login真的存在flask_login也能用但AI偶尔会给你一个完全虚构的“flask-security-plus”安装时才发现根本没有这个包。被坑几次后我会强制要求AI在代码开头用注释标注所有第三方库并且运行前先手工核对一遍requirements.txt。6.2 我踩过的“AI幻觉”代码坑在AI辅助开发的真实项目中最让我痛苦的是一次企业微信机器人回调接口开发。AI告诉我某个加密库有现成的decrypt_message方法我按照生成的代码写完测试后一直报解码错误。排查了半小时后才发现办法那个方法在真实库中根本不存在。AI自信地生成了一段API几乎正确、但函数名完全虚构的代码。从那时开始我养成了一个习惯AI生成的代码不是不能用但是必须先跑通一个最小可执行样例。只要你把成功跑通的结果告诉AI它后续会在新代码中仿照这个可用模式不再自由发挥。另一个典型幻觉是AI对时间时区的处理。很多企业应用要处理北京时间、UTC时间之间的转换。AI生成代码时经常混用datetime.now()和datetime.utcnow()导致上线后数据统计差了八小时。这类问题不是AI单独能解决的因为时区策略属于业务规则。我的建议是在提示词里写清楚“本项目所有时间存储均使用UTC展示层转北京时间”如果AI生成的代码中还有datetime.now()就在审查时全局搜索出来一个一个修正。6.3 使用AI编码的个人心得如果让我给团队提一个最重要的建议那就是不要一开始就让AI去生成一个几百上千行的大模块而是从一个最小的垂直切片开始。一个垂直切片就是一个最简单但完整的功能链路比如“用户输入手机号后端生成验证码验证后返回Token”。让AI完成这个链路然后你亲手把它跑通再逐渐增加功能。AI辅助开发的上限其实取决于人的判断力和工程素养。它能输出大量高质量代码但决定这些代码是否“高品质”的依然是人的审查、约束和取舍。你会写代码、懂业务、有良好的架构直觉AI就是一把极其锋利的工具反之工具越锋利失控风险也越大。我始终把AI当成“随叫随到的结对程序员”而不是甩手掌柜。每次拿到AI生成的代码我会先做三件事检查它是否符合项目共同约定、是否满足接口文档契约、是否覆盖了关键的异常分支。这三遍检查听起来耗时但因为AI生成的代码绝大多数情况非常工整所以实际耗时比完全手写少得多。最后再分享一个实用小技巧。我现在做任何AI相关代码任务都会在项目根目录放一个AGENTS.md或PROJECT_RULES.md文件里面写清楚技术栈、目录结构、编码规范、禁止事项和常用命令。每次和AI对话时我先把这个文件发送给它再分配具体任务。这比每次重复描述上下文高效得多也是我目前维持AI输出稳定性的最关键手段。AI辅助开发的工具迭代很快但这一套“明确约束、垂直切片、人工审查”的方法论不管工具怎么变应该都能继续用下去。