2026/9/6 5:18:16
FEATURED · 精选文章 
1. 先把话说清楚AI 写代码和 AI 做产品是两码事最近总有同行问我为什么别人用 AI 一天能出一个 Web 应用我自己用 AI 生成的东西永远停留在“能跑”的阶段界面丑、逻辑乱、漏洞多稍微改点需求就崩。这个问题我太有感触了——过去半年我用 AI 从零搭了好几个 Web 应用从内部工具到对外服务都有踩了无数坑之后才摸清楚门道。先给一个可能反直觉的结论AI 编程的核心难点从来不是让 AI 写出代码而是让 AI 在你设定的约束下写出能上线、能维护、经得起攻击的代码。很多人的用法停留在“帮我写个登录功能”“帮我写个列表页”这确实能出活但出来的东西跟“高品质 Web 应用”之间隔着一条巨大的鸿沟没有工程结构、没有异常处理、没有安全防护、没有测试、没有部署方案。那什么是“高品质”我自己的判断标准有五条功能完整性核心业务链路能跑通不只是 Demo 级别的交互安全性不出现 SQL 注入、XSS、越权这类低级但致命的漏洞可维护性代码结构清晰命名规范换一个人也能接得住可部署性不是在你电脑上能跑而是能在服务器上一键跑起来性能达标响应时间、并发能力、资源占用在合理范围。用这个标准回看市面上大量号称“AI 生成的应用”其实连门槛都没摸到。问题不出在 AI出在使用 AI 的方法上。这篇文章我想完整复盘一下我是怎么把 AI 从一个“代码生成器”变成一条完整的“Web 应用生产流水线”的。文章会覆盖技术选型、工程初始化、核心业务开发、安全加固、测试部署这几个关键环节每个环节都会给具体的提示词、代码和我在实践中踩过的坑。如果你正准备用 AI 做一个正经的 Web 应用不管你是独立开发者、初创团队的技术负责人还是企业内部想提效的工程师这篇文章应该能帮你少走至少一个月的弯路。2. 技术选型阶段让 AI 当参谋而不是当打字员2.1 选型才是第一个决定成败的战场很多人一上来就打开 AI 对话框说“帮我用 Python 写个网站”这是最大的误区。AI 在代码生成上确实强但代码生成之前的技术选型才真正决定这个项目能不能走到最后。Python 系、Java 系、Node.js 系、Go 系每个生态适合的场景完全不同——你要是做一个企业级管理系统选了 Flask做到后面路由、ORM、权限、Admin 后台全得自己造轮子那才是真正的灾难。我自己做项目的时候技术选型是让 AI 深度参与的。思路不是问它“我该用什么”而是把业务情况、团队背景、部署环境全部喂给它让它输出一个选型评估报告然后我再结合自己的经验判断。下面这个案例是我最近做的一个企业级管理后台的需求描述也是我实测下来效果很好的提示词结构我正在规划一个 Web 应用请基于以下约束条件帮我做技术选型评估 - 业务类型企业内部管理系统包含用户认证、角色权限、数据报表、文件上传 - 预计用户量初期 200 人以内后续可能扩展到 2000 人 - 团队背景3 人小团队熟悉 Python希望快速迭代 - 部署环境公司内网服务器资源有限2核4G - 时间要求6 周内上线 请对比 Django、Flask、FastAPI、Spring Boot 四种方案从开发效率、生态成熟度、内置功能、性能、学习成本、部署难度六个维度进行评分最后给出推荐方案和理由。AI 给的答案在多数情况下会指向 Django这个判断是合理的。Django 自带 Admin 后台、ORM、认证系统、表单处理、安全防护对于“企业内部管理系统”这个场景几乎是量身定做。如果换个场景比如你要做一个高并发的 API 服务那 FastAPI 的异步性能优势就会凸显出来如果团队是 Java 背景、或者要跟 Spring Cloud 微服务家族打通那 Spring Boot 才是正解。2.2 选型阶段最容易忽略的三个隐藏成本我让 AI 帮我做过很多次选型过程中发现有三个指标是 AI 默认不会主动暴露的必须主动问否则后面全是坑长期维护成本框架大版本升级的时候迁移成本有多高Django 的 LTS 版本支持周期长达三年多这对企业系统来说非常重要。我会让 AI 列出所选框架的版本策略这能避免两三年后被迫大重构。招人成本你选的框架在人才市场上好不好招人这是个很现实的问题。Django 和 Spring Boot 在国内都有成熟的生态但 FastAPI 相对小众如果你不是核心团队亲自维护后面接手的工程师可能连文档都要啃半天。第三方库的成熟度你要用的核心功能在这个框架生态里有没有成熟的第三方库举个具体的例子如果要做飞书登录集成Django 有很多现成的social-auth扩展如果用 FastAPI恐怕就得自己对着飞书 API 文档手写整个 OAuth 流程了。每次让 AI 做选型决策我都会加一句追问“以上方案中你推荐的那个有哪些潜在风险和短板是否有被替代的可能”这一步非常关键——AI 的第一轮回答往往会把推荐方案说得近乎完美你不主动要求它不会主动暴露风险。我见过太多人因为没问这一句用了 AI 拍的方案做到一半发现生态不配套硬着头皮重构那才是真正的浪费时间。2.3 AI 辅助选型的正确打开方式总结一句话选型的最终决策必须是人做的AI 的作用是帮你把决策所需要的信息尽量完整地摊开在你面前。我在完成技术选型后会单独拉一个文档记录决策背景、备选方案、评分依据、风险点然后把这个文档作为后续所有 AI 对话的“项目上下文”喂进去。这一步很多人不做但恰恰是它能保证你后面让 AI 生成的代码跟你当初的选型完全一致而不是每次对话都像失忆一样重新发明一遍轮子。3. 从零到一AI 辅助搭建工程骨架的正确姿势3.1 目录结构和依赖管理让 AI 先给你搭脚手架选型定下来之后大多数人会直接让 AI “帮我写登录注册”。我先劝你按下这个念头。工程化开发的第一步是初始化项目结构——目录怎么分层、配置文件怎么组织、依赖怎么管理、环境变量怎么处理这些直接决定了项目后续的可维护性。如果你一上来就让 AI 生成散装代码后面大概率迎来一场“代码重构”的噩梦。拿 Django 5 来讲标准的企业级项目骨架大概长这样config/ # 项目配置目录settings 拆分 settings/ __init__.py base.py # 基础配置 dev.py # 开发环境配置 prod.py # 生产环境配置 urls.py # 根路由 accounts/ # 用户认证模块 core/ # 核心业务模块 templates/ # 模板目录 static/ # 静态资源 manage.py requirements.txt .env.example # 环境变量示例文件我的做法是让 AI 先按这个结构把整个目录建起来并且给出每个文件的初始内容。这里有个非常关键的提示词技巧不要只给一个笼统的需求而是主动给约束条件比如“settings 要按环境拆分”“数据库连接必须从环境变量读取”“密码不能出现在代码里”这些约束决定了代码质量的上限。请基于 Django 5 创建一个企业级项目骨架要求 - 使用 project 和 app 分离结构项目配置目录名为 config - settings 拆分为 base.py、dev.py、prod.py 三个文件 - 数据库配置、密钥、调试开关全部从环境变量读取并提供 .env.example - requirements.txt 按环境分文件基础依赖与开发依赖分离 - 预留静态文件、媒体文件、日志的目录结构 请依次生成每个文件并附上简短的说明。3.2 用 AI 生成核心模型数据库设计也可以不头痛目录搭好之后我习惯先让 AI 生成数据库模型而不是先写视图。因为模型是整个应用的“地基”模型设计得烂后面所有代码都会拧巴。以“内容管理 用户体系”为例我会把业务规则告诉 AI让它产出 Django 模型代码from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): 自定义用户模型扩展手机号和头像字段 mobile models.CharField(手机号, max_length20, blankTrue) avatar models.URLField(头像地址, blankTrue) department models.CharField(部门, max_length50, blankTrue) class Meta: verbose_name 用户 verbose_name_plural verbose_name class Article(models.Model): 内容管理模块的文章模型 title models.CharField(标题, max_length200) content models.TextField(正文) author models.ForeignKey(User, on_deletemodels.CASCADE, verbose_name作者) status models.CharField( 状态, max_length10, choices[(draft, 草稿), (published, 已发布), (archived, 已归档)], defaultdraft, ) view_count models.PositiveIntegerField(浏览量, default0) created_at models.DateTimeField(创建时间, auto_now_addTrue) updated_at models.DateTimeField(更新时间, auto_nowTrue) class Meta: ordering [-created_at] verbose_name 文章 verbose_name_plural verbose_name这一份代码我会要求 AI 一次性把所有模型定义完并且要求它自动补充__str__、Meta这些看起来琐碎但对后台管理很重要的细节。生成完之后我会亲自过一遍重点检查外键关系是不是合理、字段类型是不是合适、有没有明显的索引缺失。这一步千万别省模型一旦定下来后面改起来成本是成倍增加的。3.3 工程初始化阶段的三个纪律纪律一分批次验收不要一次性让 AI 生成整个项目。我在最初踩过的坑就是让 AI “一次性创建一个完整的博客系统”结果生成了一大坨文件目录结构混乱、配置文件互相冲突根本没法定位问题。正确的方式是按模块逐个生成每生成一个模块就本地跑一遍确认能运行再进入下一个。纪律二版本管理要从第一天开始。项目一初始化就git init每完成一个功能点就提交一次。AI 生成的代码有时候会莫名其妙地“越改越坏”有了版本管理你可以随时回退到上一个稳定的状态再对比看看 AI 到底改了什么东西导致问题出现。这个习惯在 AI 驱动开发里比传统开发更重要因为 AI 修改代码时的副作用往往不可预期。纪律三环境隔离必须做。我见过太多直接在系统 Python 里装依赖的案例几个项目一混依赖冲突让整个环境崩溃。用venv或者 Poetry 把项目的依赖隔离好这个步骤看起来无关紧要实际上能省掉后面大量排错时间。AI 生成的代码里如果出现了requirements.txt中不存在的依赖你也能一眼发现。4. 核心业务开发认证、权限与业务模块的 AI 加速4.1 用户认证最不该自己手写、也最容易被 AI 坑的部分用户认证是所有 Web 应用里最容易出问题的模块同时也是最适合让 AI 来做、但必须人工严格审查的模块。先说为什么适合认证流程高度标准化登录、登出、密码重置、第三方集成业界已经有非常成熟的模式Django 自带auth模块很多基础功能根本不用自己写。再说为什么容易坑AI 一旦自己手写认证逻辑容易忽略会话管理、密码加密、CSRF 防护这些安全细节。基础登录认证我的建议是用 Django 自带的authLoginView这部分完全不需要 AI 参与。真正值得交给你和 AI 协作完成的是各种第三方登录的集成。最近很多国内企业都会要求 Web 应用支持飞书登录我就在这里举一个飞书登录集成的完整例子把这个流程拆开讲透。飞书开放平台的授权登录走的是标准的 OAuth 2.0 授权码模式业务流程分三步前端引导用户跳转到飞书的授权页面附带app_id、redirect_uri、state用户授权后飞书回调到你配置的回调地址带上临时授权码code后端拿着code向飞书换access_token再拿着access_token获取用户信息完成登录。AI 可以帮你把第三步的整个后端流程生成出来而且能写得很标准。下面这个代码片段是 AI 生成、我审查修改后的一个版本import requests from django.conf import settings from django.contrib.auth import login from django.shortcuts import redirect from django.views import View class FeishuOAuthCallbackView(View): 处理飞书授权回调 def get(self, request): code request.GET.get(code) state request.GET.get(state) # 校验 state防止 CSRF 攻击这里省略了 session 验证步骤 # 1. 用 code 换取 access_token token_resp requests.post( https://open.feishu.cn/open-apis/authen/v1/oidc/access_token, headers{Content-Type: application/json}, json{ grant_type: authorization_code, code: code, client_id: settings.FEISHU_APP_ID, client_secret: settings.FEISHU_APP_SECRET, }, ) token_data token_resp.json() if token_data.get(code) ! 0: return redirect(settings.LOGIN_REDIRECT_URL ?errortoken_failed) access_token token_data[data][access_token] # 2. 用 access_token 获取用户身份信息 user_resp requests.get( https://open.feishu.cn/open-apis/authen/v1/user_info, headers{Authorization: fBearer {access_token}}, ) user_data user_resp.json() if user_data.get(code) ! 0: return redirect(settings.LOGIN_REDIRECT_URL ?erroruserinfo_failed) feishu_user user_data[data] # 3. 根据 open_id 查找或创建本地用户 user, created User.objects.get_or_create( usernameffeishu_{feishu_user[open_id]}, defaults{email: feishu_user.get(email, ), nickname: feishu_user.get(name, )}, ) login(request, user) return redirect(settings.LOGIN_REDIRECT_URL)这个流程里有几个安全细节我专门对比着说明一下。首当其冲的是state参数这部分在类里我刻意没有写全因为实际执行时必须要在跳转飞书前生成一个随机state并存到 session、回调时做比对防止攻击者构造回调地址诱导用户登录。第二个是client_secret的管理绝对不能写死在代码里要放到环境变量里读取因为代码一旦提交到仓库密钥泄露就等于把你的账号体系暴露给了所有人。第三个是回调地址必须和飞书开放平台配置的完全一致否则飞书会直接拒绝回调。4.2 权限控制让 AI 生成 RBAC 模型但一定要人工过一遍几乎在所有企业内部系统里你都会遇到权限管理这个需求。RBAC基于角色的访问控制是目前最主流的权限模型它的核心是权限不直接挂在用户身上而是通过“角色”这一层进行间接绑定。比如“编辑”这个角色拥有“创建文章”和“编辑文章”的权限用户被授予“编辑”角色就自动获得了这两项权限。Django 本身就内置了一个非常简单好用的权限框架auth应用里有Group和Permission模型。AI 对这套机制的理解非常准确你只要给它明确的指令它就能快速生成需要的权限初始化代码和数据迁移文件。下面是让 AI 在项目里创建角色并分配权限的management command示例from django.core.management.base import BaseCommand from django.contrib.auth.models import Group, Permission class Command(BaseCommand): help 初始化默认角色和权限 def handle(self, *args, **options): editor_group, _ Group.objects.get_or_create(name编辑) permissions Permission.objects.filter( codename__in[add_article, change_article, view_article] ) editor_group.permissions.set(permissions) self.stdout.write(self.style.SUCCESS(编辑角色权限初始化完成))但这里我要特别提醒一个 AI 不擅长的地方AI 对“越权漏洞”的敏感度普遍不足。它可以帮你生成 RBAC 模型但你如果在视图层不加一行校验代码用户还是可以直接通过构造 URL 去修改别人的文章。这是一类非常经典的 Web 安全漏洞叫“水平越权”。我通常会追加一条提示词让 AI 在生成的每个视图函数里都写上权限校验在以下所有涉及对象操作的视图函数中请确保 1. 当前登录用户只有具备对应权限时才可访问 2. 对象属于其他用户时必须返回 404 而不是 403避免泄露对象存在性 3. 使用基于类的视图时要校验对象的所有者4.3 AI Agent 模式让它帮你跑通多步任务现在的 AI 工具已经比早期强大了很多像 Claude Code、Cursor、GitHub Copilot Workspace 这些工具都开始支持 Agent 模式——不再是你一句它一句地对话而是你给它一个目标它能自主地读代码、改文件、跑命令一步步完成任务。我在开发业务模块的时候大量使用了这种模式让效率有了非常明显的提升。举个真实的例子。我在开发一个数据报表模块时需求是“展示每个用户在过去 30 天内的文章发布数量用柱状图显示并提供 CSV 导出”。如果让我自己写可能要对齐好几个文件模型查询方法、视图逻辑、模板、路由、前端图表库引入。交给 Agent 模式之后它会自己定位到相关的文件修改视图和模板然后跑一遍测试给我看。过程中如果有报错它会自己读日志、自己修复、再重新跑。这个体验确实很爽但我必须提醒两个使用 Agent 模式的关键经验每次只让它做一个完整的、可验收的任务。如果任务太大它会在中途“迷失方向”改着改着连自己之前改过什么都不记得了。把大需求拆成三层粒度史诗级需求整个模块→ 特性级任务单个功能→ 原子级操作单个文件单次修改Agent 适合处理后两级。每一步都要有代码审查。即使 Agent 自己跑通了测试那也只能说明“代码运行没有报错”不说明“代码质量和业务逻辑是对的”。我会用git diff查看所有修改把每一处改动都过一遍。5. 安全加固AI 生成代码最容易被攻击的五个缺口5.1 AI 代码里的“默认不安全”做 Web 应用开发安全是绕不开的话题。如果忽略了安全应用上线后一个低水平的攻击者可能就能把你的系统搞瘫痪。根据我观察到的数据AI 生成代码最容易踩中的安全坑有五个漏洞类型AI 的典型表现危害程度SQL 注入直接用字符串拼接 SQL 查询严重可导致拖库XSS 存储型用户输入直接渲染到模板不转义严重可窃取用户会话硬编码密钥把密码、Token 写死在代码里严重相当于把钥匙贴门上CSRF处理 POST 请求时不校验来源中高可诱导用户执行危险操作水平越权查询数据时只校验登录不校验归属严重可操作他人数据拿 XSS 来举例。你让 AI 生成一个“用户评论展示”功能如果不给它明确指出必须转义它在 Django 模板里很可能给你写成{{ comment.content | safe }}。那个safe过滤器一旦出现意味着用户的评论内容会被当作 HTML 代码原样渲染。用户可以在评论里写一段script任何浏览到这个页面的用户都会中招。而正确的方式是默认不转义Django 模板默认会转义所有 HTML 标签但 AI 有时候画蛇添足主动加safe过滤器去“修复”样式问题这就把安全防线打开了。5.2 让 AI 站在攻击者视角做审查在一次安全复盘会上我用过一个很有效的方法把 AI 当成“外部渗透测试工程师”让它从攻击者的角度审视 AI 生成的代码。提示词大概是这样的请扮演一名 Web 安全渗透测试工程师从攻击者视角审查以下代码 1. 找出所有可能的 SQL 注入点和绕过方式 2. 找出所有可能被利用的 XSS 注入面 3. 检查 CSRF 防护是否在所有 POST 表单上生效 4. 检查是否存在越权漏洞用户 A 是否可以操作用户 B 的数据 5. 检查密钥、密码、Token 是否有硬编码 请针对每个发现的问题给出漏洞描述、攻击路径、修复代码。实测下来这个“反过来问”的方式效果相当好。当 AI 被要求攻击而不是防守时它更愿意主动找自己的漏洞给出的修复方案也常常比原来的代码严谨不少。但这绝不意味着你可以完全放心把代码交给 AI 审查就完事AI 还是会出现“看了半天看出了几个无关痛痒的问题真正致命的漏洞反而没发现”的情况。AI 安全审查更合适的定位是“辅助巡检”用工具和你自己的经验做最终把关。5.3 安全扫描工具链让 AI 和工具双保险除了让 AI 做代码审查我在 CI/CD 流程里还接入了自动化安全扫描工具形成了“AI 审查 静态扫描 依赖漏洞检查”三道防线静态代码扫描Semgrep / Bandit针对 Python 代码做模式匹配能快速识别硬编码密钥、SQL 拼接、危险函数调用等问题。配置好后每次提交代码都会自动跑一遍有高危问题直接“阻断合并”。依赖漏洞检查pip-audit检查项目里引用的第三方库有没有已知安全漏洞。这个非常重要因为你项目里 90% 的依赖都不是你写的但一旦被曝出漏洞你一样受影响。交互式安全测试OWASP ZAP对运行中的站点做一轮自动扫描模拟攻击者从外部发起请求能发现一些静态扫描发现不了的运行时问题。下面是一个基本的 Bandit 使用示例一行命令就能把整个项目的安全风险扫出来bandit -r . -f json -o bandit_report.json执行完成后bandit_report.json里会列出每个文件的风险等级和具体行号你可以把报告丢给 AI让它根据报告逐项修复。我实际用下来AI 对 Bandit 报告里的问题修复速度极快基本上十几分钟就能把中等以上风险全部清掉。但记住报告里标记为“低风险”的内容也别全忽略有时候真实漏洞只是用了常见模式的变体。6. 测试策略用 AI 生成用例但不被“覆盖率”骗了6.1 AI 生成测试用例的正确姿势给出业务规则和边界条件高质量的 Web 应用测试是不可或缺的。很多独立开发者和团队把测试当作“上线前的形式”跑一下看没报错就完事这恰恰是产品质量会持续滑坡的根源。我现在的习惯是每写一个功能模块就让 AI 配套生成测试代码并且要求它覆盖正常路径、异常路径、边界条件三种场景。让 AI 生成测试用例关键同样在提示词。直接说“帮我写单元测试”得到的结果往往很平庸大概率是只测了“能跑通”的 happy path。更好的方式是给它具体的业务规则和边界条件请为文章发布功能编写完整的测试用例覆盖以下场景 1. 正常发布登录用户提交合法的标题和正文发布成功 2. 权限不足未登录用户调用发布接口应返回 401 3. 数据校验标题为空、超过 200 字符应返回校验错误 4. 越权测试用户 A 尝试修改用户 B 的文章应返回 404 5. 状态流转草稿状态下不能出现在已发布列表中 6. 边界条件正文正好为空字符串、正文为超长文本100KB 请使用 pytest Django TestCase 编写并确保断言覆盖每一步响应状态码和关键字段。6.2 覆盖率数字背后的陷阱我见过太多团队把“测试覆盖率 90%”当作质量目标结果覆盖率高得吓人、线上还是一堆 bug。为什么因为覆盖率只能说明“代码的哪些行被执行了”不能说明“业务逻辑是否被验证了”。你完全可能写出一个覆盖率 100% 但断言全是无效断言的测试套件——代码跑了一遍但什么都证明不了。解决这个问题的关键是审查 AI 生成的测试用例时重点看断言质量而不是覆盖率数字。好的测试每一句断言都要回答一个业务问题差的测试断言全是“响应状态码是 200”这种没有信息量的内容。我一个比较实用的做法是在需求文档里把业务规则列清楚然后让 AI 根据业务规则逐条生成对应的测试用例最后人工核对“业务规则 ↔ 测试用例”的对应关系看有没有漏掉逻辑分支。6.3 用测试反向驱动 AI 修复代码测试还有一个非常重要的作用当 AI 生成的代码跑不过测试时把测试输出和失败信息回传给 AI让它在上下文中自行修复。这是一个效果拔群的闭环先让 AI 生成功能代码再让 AI 生成测试代码本地运行测试把完整报错信息喂给 AI让 AI 定位问题原因并修复。这个流程看似简单但效果远好于“让 AI 凭空检查代码”。因为测试失败给你的是具体、客观的输入AI 不需要猜“哪里可能有问题”而是直接针对失败原因做修正。而且每修复一次你手里就多了一个防止回归的测试用例项目测试套件的厚度会逐渐积累起来。我现在项目里的测试用例数量已经超过两百个大部分就是在这个循环里积累下来的。7. 部署上线AI 从“写好代码”到“跑稳服务”的最后一公里7.1 容器化与编排让 AI 帮你写 Dockerfile 和编排配置代码写得再好部署方案烂应用照样上不了线。“最后一公里”恰恰是很多开发者用 AI 提效最少、踩坑最多的地方。先说容器化。如果你用过 Docker应该会认同写一个合理的 Dockerfile 并不难难的是把镜像做到“构建快、体积小、运行稳”。让 AI 生成 Dockerfile 的时候我给它附加了几个明确的约束条件请为 Django 5 应用编写生产环境 Dockerfile要求 1. 使用多阶段构建最终运行镜像尽量小 2. 基础镜像使用 python:3.12-slim 3. 建议不要以 root 用户运行应用 4. 设置合理的 WORKDIR、环境变量 5. 加入健康检查指令 6. 说明构建和启动命令多阶段构建是 AI 经常漏掉的一个优化点你必须主动提。它的思路是第一个阶段装所有编译依赖、安装 Python 包第二个阶段只拷贝编译好的文件和一个精简运行环境。这样能大幅减小最终镜像的体积也让攻击面更小。我见过一个胖镜像接近 1GB用多阶段构建瘦身之后只有 120MB部署速度和安全性完全不是一个量级。Django 应用在部署时的静态文件处理也是个高频问题用 Django 自带的 runserver 开发时一切正常一上生产环境 CSS、JS 全部 404。这类问题让 AI 提前指出来比你在部署现场手忙脚乱地查半天要舒服得多。正确的部署方式是用 Nginx 处理静态文件、用 Gunicorn 跑应用AI 能把这些配置都生成好。7.2 CI/CD 流水线把“人肉发布”变成自动化发布部署里我最推崇的实践是持续集成/持续部署CI/CD。一个简单的 CI/CD 流水线可以帮你自动完成代码提交后自动跑测试、自动做静态扫描、自动构建镜像、自动部署到服务器。整个过程中人只需要审核代码变更。我通常用 GitHub Actions 来搭建这条流水线下面是一个基本的工作流配置涵盖了测试和构建两个核心阶段name: CI on: push: branches: [ main ] jobs: test-and-build: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Set up Python uses: actions/setup-pythonv5 with: python-version: 3.12 - name: Install dependencies run: | pip install -r requirements.txt pip install pytest pytest-django - name: Run tests run: pytest env: DJANGO_SETTINGS_MODULE: config.settings.dev - name: Security scan run: bandit -r . -f json -o bandit_report.json || true - name: Build Docker image run: docker build -t myapp:${{ github.sha }} .这段配置也可以让 AI 根据你的项目情况微调但核心的思想是固定不变的把人工操作一条条变成自动化检查让人只能把代码推到主分支之后剩下的全部交给流程。要是没有 CI/CD全靠人肉去测试和部署你的“AI 开发效率”最终会全折在“发布流程不稳定”上面。7.3 应用内嵌 AI 能力的部署模型推理与性能调优这一节要单独说一下如果你的 Web 应用不只是“被 AI 辅助开发”而是在应用本身里嵌入了 AI 能力比如接入了大模型 API或者自己部署了一个开源模型部署的复杂度会再多一个量级。热搜词里频繁出现的“AI 应用开发”“AI 模型部署”“AI infra”对应的就是这个场景。方案有两种我分别说一下适用场景调用 API如 OpenAI、DeepSeek 等实现最简单、成本最可控但你必须重点处理三个问题网络延迟、API 密钥泄漏、费用上限。密钥只放在服务端环境变量里前端永远不要接触费用上限在服务商后台配置一个报警阈值防止有人刷爆你的账单。自部署开源模型如 Qwen、Llama 等数据可控、长期成本更低但你需要准备 GPU 资源。如果没有 GPU那些上百亿参数的大模型根本跑不起来用 CPU 推理一个请求可能要等几十秒体验完全没法看。不管哪种方案有一个工程细节是通用的AI 请求的耗时远高于普通 Web 请求所以处理 AI 请求的接口必须设计成异步任务或将超时时间设长。网页应用常见的交互方式是用户提交文本 → 后端先返回“任务已受理”→ 前端轮询或通过 WebSocket 接收 AI 处理结果。如果同步等 AI 返回一个推理请求耗 30 秒网关那边的超时设置很可能已经把你的请求断掉了。7.4 上线不是结束监控和日志部署到线上之后最后一块拼图是监控和日志。没有监控的应用等于闭着眼睛开车。我每次上线都会确保至少有以下三项应用日志集中收集到日志系统方便排查问题。Django 的 logging 配置可以交给 AI 生成要确保 SQL、异常堆栈、请求耗时都有记录。基础监控CPU、内存、磁盘、网络连接数这些服务器指标要有可视化面板。最好配一个简单的告警比如 CPU 持续高于 90% 十分钟就发消息提醒。业务告警如果是做给用户的服务要监控核心业务指标的异常波动比如注册成功率突然下降、AI 接口的失败率飙升这些比服务器指标更早反映业务故障。上线后的第一次故障往往发生在你最意想不到的地方磁盘空间被日志占满了、数据库连接数被打满了、内存泄漏导致 OOM。有了监控你能在用户发现之前先发现问题、解决问题。这也是“高品质 Web 应用”和“能跑的 demo”之间的分水岭。8. 最后分享三个我个人最有用的实操习惯这篇文章写到这里主线已经梳理完了。按照惯例最后分享三个我习惯用、且经过多次项目验证有效的实操技巧供你参考第一维护一个项目级提示词文档。每做一个项目我会建一个prompts/目录把项目的技术选型、目录结构、编码规范、常用提示词模板都存起来。每次和 AI 对话时先把这个文档里最相关的内容贴进去相当于给 AI 一份“项目说明书”再让它干活。你会发现 AI 的输出质量显著提升因为它不需要靠猜来补齐项目背景了。第二每次 AI 修改代码后第一时间跑 git diff 并让 AI 自己解释改动原因。很多问题在 AI “解释改动”的时候自己就暴露了——它的逻辑和现有代码的设计不一致或者它引入了一个看似无关的改动。一旦出现这种情况果断回退到上一个版本用更小的任务粒度重新来。第三永远保留至少一台能手工操作的生产服务器。自动化部署再成熟也要给自己留一条应急路径。当 CI/CD 管道因为某个依赖问题整体卡死的时候一个能手工 SSH 上去修修补补的入口往往能救回整个上线窗口。AI 没有取代 Web 开发这件事它只是把开发者从“手写重复代码的日常”里解放了出来让你有更多精力去关注架构、安全、稳定性和用户体验。但工具越强使用者的判断力就越重要——AI 生成代码的速度快到几分钟一个模块如果你没有自己的工程标准和安全底线造出来的只是一个同样几分钟就能被攻破的“花架子”。把这篇文章里提到的每个环节当成一把尺子丈量一下你的 AI 开发流程补齐短板你才能真正享受到 AI 给你带来的效率红利。
用AI打造高品质Web应用：选型、安全、测试与部署全攻略
1. 先把话说清楚AI 写代码和 AI 做产品是两码事最近总有同行问我为什么别人用 AI 一天能出一个 Web 应用我自己用 AI 生成的东西永远停留在“能跑”的阶段界面丑、逻辑乱、漏洞多稍微改点需求就崩。这个问题我太有感触了——过去半年我用 AI 从零搭了好几个 Web 应用从内部工具到对外服务都有踩了无数坑之后才摸清楚门道。先给一个可能反直觉的结论AI 编程的核心难点从来不是让 AI 写出代码而是让 AI 在你设定的约束下写出能上线、能维护、经得起攻击的代码。很多人的用法停留在“帮我写个登录功能”“帮我写个列表页”这确实能出活但出来的东西跟“高品质 Web 应用”之间隔着一条巨大的鸿沟没有工程结构、没有异常处理、没有安全防护、没有测试、没有部署方案。那什么是“高品质”我自己的判断标准有五条功能完整性核心业务链路能跑通不只是 Demo 级别的交互安全性不出现 SQL 注入、XSS、越权这类低级但致命的漏洞可维护性代码结构清晰命名规范换一个人也能接得住可部署性不是在你电脑上能跑而是能在服务器上一键跑起来性能达标响应时间、并发能力、资源占用在合理范围。用这个标准回看市面上大量号称“AI 生成的应用”其实连门槛都没摸到。问题不出在 AI出在使用 AI 的方法上。这篇文章我想完整复盘一下我是怎么把 AI 从一个“代码生成器”变成一条完整的“Web 应用生产流水线”的。文章会覆盖技术选型、工程初始化、核心业务开发、安全加固、测试部署这几个关键环节每个环节都会给具体的提示词、代码和我在实践中踩过的坑。如果你正准备用 AI 做一个正经的 Web 应用不管你是独立开发者、初创团队的技术负责人还是企业内部想提效的工程师这篇文章应该能帮你少走至少一个月的弯路。2. 技术选型阶段让 AI 当参谋而不是当打字员2.1 选型才是第一个决定成败的战场很多人一上来就打开 AI 对话框说“帮我用 Python 写个网站”这是最大的误区。AI 在代码生成上确实强但代码生成之前的技术选型才真正决定这个项目能不能走到最后。Python 系、Java 系、Node.js 系、Go 系每个生态适合的场景完全不同——你要是做一个企业级管理系统选了 Flask做到后面路由、ORM、权限、Admin 后台全得自己造轮子那才是真正的灾难。我自己做项目的时候技术选型是让 AI 深度参与的。思路不是问它“我该用什么”而是把业务情况、团队背景、部署环境全部喂给它让它输出一个选型评估报告然后我再结合自己的经验判断。下面这个案例是我最近做的一个企业级管理后台的需求描述也是我实测下来效果很好的提示词结构我正在规划一个 Web 应用请基于以下约束条件帮我做技术选型评估 - 业务类型企业内部管理系统包含用户认证、角色权限、数据报表、文件上传 - 预计用户量初期 200 人以内后续可能扩展到 2000 人 - 团队背景3 人小团队熟悉 Python希望快速迭代 - 部署环境公司内网服务器资源有限2核4G - 时间要求6 周内上线 请对比 Django、Flask、FastAPI、Spring Boot 四种方案从开发效率、生态成熟度、内置功能、性能、学习成本、部署难度六个维度进行评分最后给出推荐方案和理由。AI 给的答案在多数情况下会指向 Django这个判断是合理的。Django 自带 Admin 后台、ORM、认证系统、表单处理、安全防护对于“企业内部管理系统”这个场景几乎是量身定做。如果换个场景比如你要做一个高并发的 API 服务那 FastAPI 的异步性能优势就会凸显出来如果团队是 Java 背景、或者要跟 Spring Cloud 微服务家族打通那 Spring Boot 才是正解。2.2 选型阶段最容易忽略的三个隐藏成本我让 AI 帮我做过很多次选型过程中发现有三个指标是 AI 默认不会主动暴露的必须主动问否则后面全是坑长期维护成本框架大版本升级的时候迁移成本有多高Django 的 LTS 版本支持周期长达三年多这对企业系统来说非常重要。我会让 AI 列出所选框架的版本策略这能避免两三年后被迫大重构。招人成本你选的框架在人才市场上好不好招人这是个很现实的问题。Django 和 Spring Boot 在国内都有成熟的生态但 FastAPI 相对小众如果你不是核心团队亲自维护后面接手的工程师可能连文档都要啃半天。第三方库的成熟度你要用的核心功能在这个框架生态里有没有成熟的第三方库举个具体的例子如果要做飞书登录集成Django 有很多现成的social-auth扩展如果用 FastAPI恐怕就得自己对着飞书 API 文档手写整个 OAuth 流程了。每次让 AI 做选型决策我都会加一句追问“以上方案中你推荐的那个有哪些潜在风险和短板是否有被替代的可能”这一步非常关键——AI 的第一轮回答往往会把推荐方案说得近乎完美你不主动要求它不会主动暴露风险。我见过太多人因为没问这一句用了 AI 拍的方案做到一半发现生态不配套硬着头皮重构那才是真正的浪费时间。2.3 AI 辅助选型的正确打开方式总结一句话选型的最终决策必须是人做的AI 的作用是帮你把决策所需要的信息尽量完整地摊开在你面前。我在完成技术选型后会单独拉一个文档记录决策背景、备选方案、评分依据、风险点然后把这个文档作为后续所有 AI 对话的“项目上下文”喂进去。这一步很多人不做但恰恰是它能保证你后面让 AI 生成的代码跟你当初的选型完全一致而不是每次对话都像失忆一样重新发明一遍轮子。3. 从零到一AI 辅助搭建工程骨架的正确姿势3.1 目录结构和依赖管理让 AI 先给你搭脚手架选型定下来之后大多数人会直接让 AI “帮我写登录注册”。我先劝你按下这个念头。工程化开发的第一步是初始化项目结构——目录怎么分层、配置文件怎么组织、依赖怎么管理、环境变量怎么处理这些直接决定了项目后续的可维护性。如果你一上来就让 AI 生成散装代码后面大概率迎来一场“代码重构”的噩梦。拿 Django 5 来讲标准的企业级项目骨架大概长这样config/ # 项目配置目录settings 拆分 settings/ __init__.py base.py # 基础配置 dev.py # 开发环境配置 prod.py # 生产环境配置 urls.py # 根路由 accounts/ # 用户认证模块 core/ # 核心业务模块 templates/ # 模板目录 static/ # 静态资源 manage.py requirements.txt .env.example # 环境变量示例文件我的做法是让 AI 先按这个结构把整个目录建起来并且给出每个文件的初始内容。这里有个非常关键的提示词技巧不要只给一个笼统的需求而是主动给约束条件比如“settings 要按环境拆分”“数据库连接必须从环境变量读取”“密码不能出现在代码里”这些约束决定了代码质量的上限。请基于 Django 5 创建一个企业级项目骨架要求 - 使用 project 和 app 分离结构项目配置目录名为 config - settings 拆分为 base.py、dev.py、prod.py 三个文件 - 数据库配置、密钥、调试开关全部从环境变量读取并提供 .env.example - requirements.txt 按环境分文件基础依赖与开发依赖分离 - 预留静态文件、媒体文件、日志的目录结构 请依次生成每个文件并附上简短的说明。3.2 用 AI 生成核心模型数据库设计也可以不头痛目录搭好之后我习惯先让 AI 生成数据库模型而不是先写视图。因为模型是整个应用的“地基”模型设计得烂后面所有代码都会拧巴。以“内容管理 用户体系”为例我会把业务规则告诉 AI让它产出 Django 模型代码from django.contrib.auth.models import AbstractUser from django.db import models class User(AbstractUser): 自定义用户模型扩展手机号和头像字段 mobile models.CharField(手机号, max_length20, blankTrue) avatar models.URLField(头像地址, blankTrue) department models.CharField(部门, max_length50, blankTrue) class Meta: verbose_name 用户 verbose_name_plural verbose_name class Article(models.Model): 内容管理模块的文章模型 title models.CharField(标题, max_length200) content models.TextField(正文) author models.ForeignKey(User, on_deletemodels.CASCADE, verbose_name作者) status models.CharField( 状态, max_length10, choices[(draft, 草稿), (published, 已发布), (archived, 已归档)], defaultdraft, ) view_count models.PositiveIntegerField(浏览量, default0) created_at models.DateTimeField(创建时间, auto_now_addTrue) updated_at models.DateTimeField(更新时间, auto_nowTrue) class Meta: ordering [-created_at] verbose_name 文章 verbose_name_plural verbose_name这一份代码我会要求 AI 一次性把所有模型定义完并且要求它自动补充__str__、Meta这些看起来琐碎但对后台管理很重要的细节。生成完之后我会亲自过一遍重点检查外键关系是不是合理、字段类型是不是合适、有没有明显的索引缺失。这一步千万别省模型一旦定下来后面改起来成本是成倍增加的。3.3 工程初始化阶段的三个纪律纪律一分批次验收不要一次性让 AI 生成整个项目。我在最初踩过的坑就是让 AI “一次性创建一个完整的博客系统”结果生成了一大坨文件目录结构混乱、配置文件互相冲突根本没法定位问题。正确的方式是按模块逐个生成每生成一个模块就本地跑一遍确认能运行再进入下一个。纪律二版本管理要从第一天开始。项目一初始化就git init每完成一个功能点就提交一次。AI 生成的代码有时候会莫名其妙地“越改越坏”有了版本管理你可以随时回退到上一个稳定的状态再对比看看 AI 到底改了什么东西导致问题出现。这个习惯在 AI 驱动开发里比传统开发更重要因为 AI 修改代码时的副作用往往不可预期。纪律三环境隔离必须做。我见过太多直接在系统 Python 里装依赖的案例几个项目一混依赖冲突让整个环境崩溃。用venv或者 Poetry 把项目的依赖隔离好这个步骤看起来无关紧要实际上能省掉后面大量排错时间。AI 生成的代码里如果出现了requirements.txt中不存在的依赖你也能一眼发现。4. 核心业务开发认证、权限与业务模块的 AI 加速4.1 用户认证最不该自己手写、也最容易被 AI 坑的部分用户认证是所有 Web 应用里最容易出问题的模块同时也是最适合让 AI 来做、但必须人工严格审查的模块。先说为什么适合认证流程高度标准化登录、登出、密码重置、第三方集成业界已经有非常成熟的模式Django 自带auth模块很多基础功能根本不用自己写。再说为什么容易坑AI 一旦自己手写认证逻辑容易忽略会话管理、密码加密、CSRF 防护这些安全细节。基础登录认证我的建议是用 Django 自带的authLoginView这部分完全不需要 AI 参与。真正值得交给你和 AI 协作完成的是各种第三方登录的集成。最近很多国内企业都会要求 Web 应用支持飞书登录我就在这里举一个飞书登录集成的完整例子把这个流程拆开讲透。飞书开放平台的授权登录走的是标准的 OAuth 2.0 授权码模式业务流程分三步前端引导用户跳转到飞书的授权页面附带app_id、redirect_uri、state用户授权后飞书回调到你配置的回调地址带上临时授权码code后端拿着code向飞书换access_token再拿着access_token获取用户信息完成登录。AI 可以帮你把第三步的整个后端流程生成出来而且能写得很标准。下面这个代码片段是 AI 生成、我审查修改后的一个版本import requests from django.conf import settings from django.contrib.auth import login from django.shortcuts import redirect from django.views import View class FeishuOAuthCallbackView(View): 处理飞书授权回调 def get(self, request): code request.GET.get(code) state request.GET.get(state) # 校验 state防止 CSRF 攻击这里省略了 session 验证步骤 # 1. 用 code 换取 access_token token_resp requests.post( https://open.feishu.cn/open-apis/authen/v1/oidc/access_token, headers{Content-Type: application/json}, json{ grant_type: authorization_code, code: code, client_id: settings.FEISHU_APP_ID, client_secret: settings.FEISHU_APP_SECRET, }, ) token_data token_resp.json() if token_data.get(code) ! 0: return redirect(settings.LOGIN_REDIRECT_URL ?errortoken_failed) access_token token_data[data][access_token] # 2. 用 access_token 获取用户身份信息 user_resp requests.get( https://open.feishu.cn/open-apis/authen/v1/user_info, headers{Authorization: fBearer {access_token}}, ) user_data user_resp.json() if user_data.get(code) ! 0: return redirect(settings.LOGIN_REDIRECT_URL ?erroruserinfo_failed) feishu_user user_data[data] # 3. 根据 open_id 查找或创建本地用户 user, created User.objects.get_or_create( usernameffeishu_{feishu_user[open_id]}, defaults{email: feishu_user.get(email, ), nickname: feishu_user.get(name, )}, ) login(request, user) return redirect(settings.LOGIN_REDIRECT_URL)这个流程里有几个安全细节我专门对比着说明一下。首当其冲的是state参数这部分在类里我刻意没有写全因为实际执行时必须要在跳转飞书前生成一个随机state并存到 session、回调时做比对防止攻击者构造回调地址诱导用户登录。第二个是client_secret的管理绝对不能写死在代码里要放到环境变量里读取因为代码一旦提交到仓库密钥泄露就等于把你的账号体系暴露给了所有人。第三个是回调地址必须和飞书开放平台配置的完全一致否则飞书会直接拒绝回调。4.2 权限控制让 AI 生成 RBAC 模型但一定要人工过一遍几乎在所有企业内部系统里你都会遇到权限管理这个需求。RBAC基于角色的访问控制是目前最主流的权限模型它的核心是权限不直接挂在用户身上而是通过“角色”这一层进行间接绑定。比如“编辑”这个角色拥有“创建文章”和“编辑文章”的权限用户被授予“编辑”角色就自动获得了这两项权限。Django 本身就内置了一个非常简单好用的权限框架auth应用里有Group和Permission模型。AI 对这套机制的理解非常准确你只要给它明确的指令它就能快速生成需要的权限初始化代码和数据迁移文件。下面是让 AI 在项目里创建角色并分配权限的management command示例from django.core.management.base import BaseCommand from django.contrib.auth.models import Group, Permission class Command(BaseCommand): help 初始化默认角色和权限 def handle(self, *args, **options): editor_group, _ Group.objects.get_or_create(name编辑) permissions Permission.objects.filter( codename__in[add_article, change_article, view_article] ) editor_group.permissions.set(permissions) self.stdout.write(self.style.SUCCESS(编辑角色权限初始化完成))但这里我要特别提醒一个 AI 不擅长的地方AI 对“越权漏洞”的敏感度普遍不足。它可以帮你生成 RBAC 模型但你如果在视图层不加一行校验代码用户还是可以直接通过构造 URL 去修改别人的文章。这是一类非常经典的 Web 安全漏洞叫“水平越权”。我通常会追加一条提示词让 AI 在生成的每个视图函数里都写上权限校验在以下所有涉及对象操作的视图函数中请确保 1. 当前登录用户只有具备对应权限时才可访问 2. 对象属于其他用户时必须返回 404 而不是 403避免泄露对象存在性 3. 使用基于类的视图时要校验对象的所有者4.3 AI Agent 模式让它帮你跑通多步任务现在的 AI 工具已经比早期强大了很多像 Claude Code、Cursor、GitHub Copilot Workspace 这些工具都开始支持 Agent 模式——不再是你一句它一句地对话而是你给它一个目标它能自主地读代码、改文件、跑命令一步步完成任务。我在开发业务模块的时候大量使用了这种模式让效率有了非常明显的提升。举个真实的例子。我在开发一个数据报表模块时需求是“展示每个用户在过去 30 天内的文章发布数量用柱状图显示并提供 CSV 导出”。如果让我自己写可能要对齐好几个文件模型查询方法、视图逻辑、模板、路由、前端图表库引入。交给 Agent 模式之后它会自己定位到相关的文件修改视图和模板然后跑一遍测试给我看。过程中如果有报错它会自己读日志、自己修复、再重新跑。这个体验确实很爽但我必须提醒两个使用 Agent 模式的关键经验每次只让它做一个完整的、可验收的任务。如果任务太大它会在中途“迷失方向”改着改着连自己之前改过什么都不记得了。把大需求拆成三层粒度史诗级需求整个模块→ 特性级任务单个功能→ 原子级操作单个文件单次修改Agent 适合处理后两级。每一步都要有代码审查。即使 Agent 自己跑通了测试那也只能说明“代码运行没有报错”不说明“代码质量和业务逻辑是对的”。我会用git diff查看所有修改把每一处改动都过一遍。5. 安全加固AI 生成代码最容易被攻击的五个缺口5.1 AI 代码里的“默认不安全”做 Web 应用开发安全是绕不开的话题。如果忽略了安全应用上线后一个低水平的攻击者可能就能把你的系统搞瘫痪。根据我观察到的数据AI 生成代码最容易踩中的安全坑有五个漏洞类型AI 的典型表现危害程度SQL 注入直接用字符串拼接 SQL 查询严重可导致拖库XSS 存储型用户输入直接渲染到模板不转义严重可窃取用户会话硬编码密钥把密码、Token 写死在代码里严重相当于把钥匙贴门上CSRF处理 POST 请求时不校验来源中高可诱导用户执行危险操作水平越权查询数据时只校验登录不校验归属严重可操作他人数据拿 XSS 来举例。你让 AI 生成一个“用户评论展示”功能如果不给它明确指出必须转义它在 Django 模板里很可能给你写成{{ comment.content | safe }}。那个safe过滤器一旦出现意味着用户的评论内容会被当作 HTML 代码原样渲染。用户可以在评论里写一段script任何浏览到这个页面的用户都会中招。而正确的方式是默认不转义Django 模板默认会转义所有 HTML 标签但 AI 有时候画蛇添足主动加safe过滤器去“修复”样式问题这就把安全防线打开了。5.2 让 AI 站在攻击者视角做审查在一次安全复盘会上我用过一个很有效的方法把 AI 当成“外部渗透测试工程师”让它从攻击者的角度审视 AI 生成的代码。提示词大概是这样的请扮演一名 Web 安全渗透测试工程师从攻击者视角审查以下代码 1. 找出所有可能的 SQL 注入点和绕过方式 2. 找出所有可能被利用的 XSS 注入面 3. 检查 CSRF 防护是否在所有 POST 表单上生效 4. 检查是否存在越权漏洞用户 A 是否可以操作用户 B 的数据 5. 检查密钥、密码、Token 是否有硬编码 请针对每个发现的问题给出漏洞描述、攻击路径、修复代码。实测下来这个“反过来问”的方式效果相当好。当 AI 被要求攻击而不是防守时它更愿意主动找自己的漏洞给出的修复方案也常常比原来的代码严谨不少。但这绝不意味着你可以完全放心把代码交给 AI 审查就完事AI 还是会出现“看了半天看出了几个无关痛痒的问题真正致命的漏洞反而没发现”的情况。AI 安全审查更合适的定位是“辅助巡检”用工具和你自己的经验做最终把关。5.3 安全扫描工具链让 AI 和工具双保险除了让 AI 做代码审查我在 CI/CD 流程里还接入了自动化安全扫描工具形成了“AI 审查 静态扫描 依赖漏洞检查”三道防线静态代码扫描Semgrep / Bandit针对 Python 代码做模式匹配能快速识别硬编码密钥、SQL 拼接、危险函数调用等问题。配置好后每次提交代码都会自动跑一遍有高危问题直接“阻断合并”。依赖漏洞检查pip-audit检查项目里引用的第三方库有没有已知安全漏洞。这个非常重要因为你项目里 90% 的依赖都不是你写的但一旦被曝出漏洞你一样受影响。交互式安全测试OWASP ZAP对运行中的站点做一轮自动扫描模拟攻击者从外部发起请求能发现一些静态扫描发现不了的运行时问题。下面是一个基本的 Bandit 使用示例一行命令就能把整个项目的安全风险扫出来bandit -r . -f json -o bandit_report.json执行完成后bandit_report.json里会列出每个文件的风险等级和具体行号你可以把报告丢给 AI让它根据报告逐项修复。我实际用下来AI 对 Bandit 报告里的问题修复速度极快基本上十几分钟就能把中等以上风险全部清掉。但记住报告里标记为“低风险”的内容也别全忽略有时候真实漏洞只是用了常见模式的变体。6. 测试策略用 AI 生成用例但不被“覆盖率”骗了6.1 AI 生成测试用例的正确姿势给出业务规则和边界条件高质量的 Web 应用测试是不可或缺的。很多独立开发者和团队把测试当作“上线前的形式”跑一下看没报错就完事这恰恰是产品质量会持续滑坡的根源。我现在的习惯是每写一个功能模块就让 AI 配套生成测试代码并且要求它覆盖正常路径、异常路径、边界条件三种场景。让 AI 生成测试用例关键同样在提示词。直接说“帮我写单元测试”得到的结果往往很平庸大概率是只测了“能跑通”的 happy path。更好的方式是给它具体的业务规则和边界条件请为文章发布功能编写完整的测试用例覆盖以下场景 1. 正常发布登录用户提交合法的标题和正文发布成功 2. 权限不足未登录用户调用发布接口应返回 401 3. 数据校验标题为空、超过 200 字符应返回校验错误 4. 越权测试用户 A 尝试修改用户 B 的文章应返回 404 5. 状态流转草稿状态下不能出现在已发布列表中 6. 边界条件正文正好为空字符串、正文为超长文本100KB 请使用 pytest Django TestCase 编写并确保断言覆盖每一步响应状态码和关键字段。6.2 覆盖率数字背后的陷阱我见过太多团队把“测试覆盖率 90%”当作质量目标结果覆盖率高得吓人、线上还是一堆 bug。为什么因为覆盖率只能说明“代码的哪些行被执行了”不能说明“业务逻辑是否被验证了”。你完全可能写出一个覆盖率 100% 但断言全是无效断言的测试套件——代码跑了一遍但什么都证明不了。解决这个问题的关键是审查 AI 生成的测试用例时重点看断言质量而不是覆盖率数字。好的测试每一句断言都要回答一个业务问题差的测试断言全是“响应状态码是 200”这种没有信息量的内容。我一个比较实用的做法是在需求文档里把业务规则列清楚然后让 AI 根据业务规则逐条生成对应的测试用例最后人工核对“业务规则 ↔ 测试用例”的对应关系看有没有漏掉逻辑分支。6.3 用测试反向驱动 AI 修复代码测试还有一个非常重要的作用当 AI 生成的代码跑不过测试时把测试输出和失败信息回传给 AI让它在上下文中自行修复。这是一个效果拔群的闭环先让 AI 生成功能代码再让 AI 生成测试代码本地运行测试把完整报错信息喂给 AI让 AI 定位问题原因并修复。这个流程看似简单但效果远好于“让 AI 凭空检查代码”。因为测试失败给你的是具体、客观的输入AI 不需要猜“哪里可能有问题”而是直接针对失败原因做修正。而且每修复一次你手里就多了一个防止回归的测试用例项目测试套件的厚度会逐渐积累起来。我现在项目里的测试用例数量已经超过两百个大部分就是在这个循环里积累下来的。7. 部署上线AI 从“写好代码”到“跑稳服务”的最后一公里7.1 容器化与编排让 AI 帮你写 Dockerfile 和编排配置代码写得再好部署方案烂应用照样上不了线。“最后一公里”恰恰是很多开发者用 AI 提效最少、踩坑最多的地方。先说容器化。如果你用过 Docker应该会认同写一个合理的 Dockerfile 并不难难的是把镜像做到“构建快、体积小、运行稳”。让 AI 生成 Dockerfile 的时候我给它附加了几个明确的约束条件请为 Django 5 应用编写生产环境 Dockerfile要求 1. 使用多阶段构建最终运行镜像尽量小 2. 基础镜像使用 python:3.12-slim 3. 建议不要以 root 用户运行应用 4. 设置合理的 WORKDIR、环境变量 5. 加入健康检查指令 6. 说明构建和启动命令多阶段构建是 AI 经常漏掉的一个优化点你必须主动提。它的思路是第一个阶段装所有编译依赖、安装 Python 包第二个阶段只拷贝编译好的文件和一个精简运行环境。这样能大幅减小最终镜像的体积也让攻击面更小。我见过一个胖镜像接近 1GB用多阶段构建瘦身之后只有 120MB部署速度和安全性完全不是一个量级。Django 应用在部署时的静态文件处理也是个高频问题用 Django 自带的 runserver 开发时一切正常一上生产环境 CSS、JS 全部 404。这类问题让 AI 提前指出来比你在部署现场手忙脚乱地查半天要舒服得多。正确的部署方式是用 Nginx 处理静态文件、用 Gunicorn 跑应用AI 能把这些配置都生成好。7.2 CI/CD 流水线把“人肉发布”变成自动化发布部署里我最推崇的实践是持续集成/持续部署CI/CD。一个简单的 CI/CD 流水线可以帮你自动完成代码提交后自动跑测试、自动做静态扫描、自动构建镜像、自动部署到服务器。整个过程中人只需要审核代码变更。我通常用 GitHub Actions 来搭建这条流水线下面是一个基本的工作流配置涵盖了测试和构建两个核心阶段name: CI on: push: branches: [ main ] jobs: test-and-build: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Set up Python uses: actions/setup-pythonv5 with: python-version: 3.12 - name: Install dependencies run: | pip install -r requirements.txt pip install pytest pytest-django - name: Run tests run: pytest env: DJANGO_SETTINGS_MODULE: config.settings.dev - name: Security scan run: bandit -r . -f json -o bandit_report.json || true - name: Build Docker image run: docker build -t myapp:${{ github.sha }} .这段配置也可以让 AI 根据你的项目情况微调但核心的思想是固定不变的把人工操作一条条变成自动化检查让人只能把代码推到主分支之后剩下的全部交给流程。要是没有 CI/CD全靠人肉去测试和部署你的“AI 开发效率”最终会全折在“发布流程不稳定”上面。7.3 应用内嵌 AI 能力的部署模型推理与性能调优这一节要单独说一下如果你的 Web 应用不只是“被 AI 辅助开发”而是在应用本身里嵌入了 AI 能力比如接入了大模型 API或者自己部署了一个开源模型部署的复杂度会再多一个量级。热搜词里频繁出现的“AI 应用开发”“AI 模型部署”“AI infra”对应的就是这个场景。方案有两种我分别说一下适用场景调用 API如 OpenAI、DeepSeek 等实现最简单、成本最可控但你必须重点处理三个问题网络延迟、API 密钥泄漏、费用上限。密钥只放在服务端环境变量里前端永远不要接触费用上限在服务商后台配置一个报警阈值防止有人刷爆你的账单。自部署开源模型如 Qwen、Llama 等数据可控、长期成本更低但你需要准备 GPU 资源。如果没有 GPU那些上百亿参数的大模型根本跑不起来用 CPU 推理一个请求可能要等几十秒体验完全没法看。不管哪种方案有一个工程细节是通用的AI 请求的耗时远高于普通 Web 请求所以处理 AI 请求的接口必须设计成异步任务或将超时时间设长。网页应用常见的交互方式是用户提交文本 → 后端先返回“任务已受理”→ 前端轮询或通过 WebSocket 接收 AI 处理结果。如果同步等 AI 返回一个推理请求耗 30 秒网关那边的超时设置很可能已经把你的请求断掉了。7.4 上线不是结束监控和日志部署到线上之后最后一块拼图是监控和日志。没有监控的应用等于闭着眼睛开车。我每次上线都会确保至少有以下三项应用日志集中收集到日志系统方便排查问题。Django 的 logging 配置可以交给 AI 生成要确保 SQL、异常堆栈、请求耗时都有记录。基础监控CPU、内存、磁盘、网络连接数这些服务器指标要有可视化面板。最好配一个简单的告警比如 CPU 持续高于 90% 十分钟就发消息提醒。业务告警如果是做给用户的服务要监控核心业务指标的异常波动比如注册成功率突然下降、AI 接口的失败率飙升这些比服务器指标更早反映业务故障。上线后的第一次故障往往发生在你最意想不到的地方磁盘空间被日志占满了、数据库连接数被打满了、内存泄漏导致 OOM。有了监控你能在用户发现之前先发现问题、解决问题。这也是“高品质 Web 应用”和“能跑的 demo”之间的分水岭。8. 最后分享三个我个人最有用的实操习惯这篇文章写到这里主线已经梳理完了。按照惯例最后分享三个我习惯用、且经过多次项目验证有效的实操技巧供你参考第一维护一个项目级提示词文档。每做一个项目我会建一个prompts/目录把项目的技术选型、目录结构、编码规范、常用提示词模板都存起来。每次和 AI 对话时先把这个文档里最相关的内容贴进去相当于给 AI 一份“项目说明书”再让它干活。你会发现 AI 的输出质量显著提升因为它不需要靠猜来补齐项目背景了。第二每次 AI 修改代码后第一时间跑 git diff 并让 AI 自己解释改动原因。很多问题在 AI “解释改动”的时候自己就暴露了——它的逻辑和现有代码的设计不一致或者它引入了一个看似无关的改动。一旦出现这种情况果断回退到上一个版本用更小的任务粒度重新来。第三永远保留至少一台能手工操作的生产服务器。自动化部署再成熟也要给自己留一条应急路径。当 CI/CD 管道因为某个依赖问题整体卡死的时候一个能手工 SSH 上去修修补补的入口往往能救回整个上线窗口。AI 没有取代 Web 开发这件事它只是把开发者从“手写重复代码的日常”里解放了出来让你有更多精力去关注架构、安全、稳定性和用户体验。但工具越强使用者的判断力就越重要——AI 生成代码的速度快到几分钟一个模块如果你没有自己的工程标准和安全底线造出来的只是一个同样几分钟就能被攻破的“花架子”。把这篇文章里提到的每个环节当成一把尺子丈量一下你的 AI 开发流程补齐短板你才能真正享受到 AI 给你带来的效率红利。 
