企业官网建设流程全解析

这两年我用 AI 辅助做了不少 Web 应用，从内部工具到面向真实用户的产品都有，说实话踩的坑比收获的惊喜还多。网上铺天盖地都是“AI 十分钟生成一个应用”的演示视频，但真实开发里，AI 生成的代码能跑通 demo 和能上线稳定服务，中间隔着一条巨大的河。这篇博文我就想把“用 AI 打造高品质 Web 应用”这件事讲透：怎么让 AI 不只给你一堆能跑的代码，而是帮你交付一个结构清晰、安全可靠、可维护、可测试的 Web 应用。适合正在用或准备用 AI 编程助手（比如 Cursor、Copilot、通义灵码、文心快码这类工具）做实际项目的开发者，也适合想从“让 AI 写代码”升级到“让 AI 协作做工程”的团队。

我默认你已经有基本的 Web 开发常识，至少知道 Python、JavaScript 大概是什么，了解 HTTP 请求和数据库的基本概念。完全零基础的朋友也能看懂大部分内容，但动手实操的部分建议先补一点基础再上。

1. 内容整体设计与思路拆解

1.1 先把“高品质”三个字拆开

很多人在 AI 辅助开发时，一上来就丢一句“帮我做一个某某系统”，AI 唰唰生成几百行代码，看起来功能齐全，实际跑起来问题一堆。问题不在 AI，而在我们对“高品质”的定义太模糊。

我做了这么多年 Web 应用，心里有一套相对稳定的质量标准，分享给你参考：

• 功能正确性：核心业务流程能跑通，边界情况不崩溃。
• 安全性：不能随手就 SQL 注入、XSS 攻击，密码不能明文存储。
• 性能可接受：常规业务场景下接口响应足够快，数据库查询不拖垮服务。
• 可维护性：代码结构清晰，命名规范，注释得当，后续人能看懂能改。
• 可测试性：关键逻辑有自动化测试保护，改代码不慌。
• 可部署性：一键构建、一键部署，环境差异不影响运行。

用 AI 开发时，这六条标准不是自然发生的，而是需要我们在需求描述、代码生成、代码审查、测试验证各个环节，主动把这些约束“喂”给 AI。否则 AI 默认生成的代码，通常只能达到“功能正确性”的五六成，其他维度基本全靠运气。

我见过太多人让 AI 生成完代码，本地跑起来就以为完工了。结果往服务器上一部署，环境对不上、数据库连不上、静态文件 404、接口超时，各种问题轮番轰炸。所以这篇文章里，我会把“高品质”的每一项要求，和 AI 协作的具体动作一一对应起来。

1.2 把 AI 当成结对编程的实习生

我的核心思路其实很简单：AI 不是一个替你写作业的枪手，而是一个知识面广、反应快、但经常“不懂装懂”的结对编程实习生。你用得好，它能帮你省掉大量查文档、写样板代码、调格式的时间；你用不好，它能把你的项目搞成一团浆糊。

这个定位决定了我们的协作方式。对待实习生，你不会直接对他说“去做一个企业级系统”然后撒手不管，你会说清楚背景、约束条件、验收标准，然后让他先出方案，你来 review，发现问题及时纠正。对待 AI 也一样，甚至要更严格，因为 AI 比真人实习生更容易一本正经地胡说八道，不会主动承认自己不懂。

我在实际操作中总结了一套“三层递进”的协作流程，后面会详细展开：

1. 先让 AI 做架构设计和技术选型，把大方向定清楚。
2. 再让 AI 按照设计逐模块生成代码，每个模块都要给出明确的验收标准。
3. 最后让 AI 自己当“审查官”，交叉检查代码质量、补测试、优化性能。

这个流程的好处是，每一层都有 human in the loop，AI 的产出始终在可控范围内，而且每层之间是递进关系，不会出现“底层设计错了，顶层全推翻”的悲剧。

1.3 技术栈选型：越主流越安全

AI 生成代码的质量，和技术栈的“大众熟悉度”强相关。你让 AI 给你写一个冷门的框架、冷门的数据库 ORM，它生成的内容很可能是从文档里拼凑出来的，甚至带着上一代版本的语法。所以我强烈建议：AI 辅助开发时，技术栈选型走主流路线。

举几个例子：

• 后端框架：Python 首选 Django 或 FastAPI，Java 首选 Spring Boot，Node.js 首选 Express 或 NestJS。这些都是 AI 训练语料里出现频率极高的框架，生成质量明显更高。
• 数据库：PostgreSQL 和 MySQL 是 AI 最熟悉的，SQLite 适合原型，但生产环境尽量别用。
• 前端：React 和 Vue 是目前 AI 生成质量最好的两个方向，选哪个取决于团队熟悉度，不用太纠结。
• 部署：Docker + Nginx 几乎是标配，AI 对这套组合的熟悉程度非常高。

我一个前同事，去年非要用一个相对小众的 Python Web 框架，结果 AI 生成的代码几乎每个文件都有问题，光是排查框架自身的坑就花了两天。后来换回 Django，同样的需求半天就写完主体逻辑。这不是说小众框架不好，而是在 AI 辅助开发这个特定场景下，主流技术栈能让你少踩很多无辜的坑。

2. 核心细节解析与实操要点

2.1 提示词是第一步，也是最重要的一步

很多人觉得写提示词就是把需求说清楚，“铁律：所有字符串拼接绝不能直接进 SQL，参数化查询是底线；用户输入的文本默认全部转义；密码必须用 Django 内置的 make_password 处理；错误信息不能暴露内部实现细节。”

再比如你要求“接口响应时间控制在 200ms 以内”，AI 就会在生成代码时主动考虑加索引、避免 N+1 查询、做缓存。这些约束写和不写差别巨大，写了我实测生成代码的质量能提升一个档次。

第三层是验收标准。明确告诉 AI，代码生成后要满足哪些检查点，比如“所有新增的函数必须有对应的单元测试”“所有配置项必须通过环境变量注入，不允许硬编码”。AI 拿到这些验收标准，生成代码时会主动补齐额外的模块。

这套提示词模板，我直接用在了后面第 3 节的实操案例里，你顺手就能复制。

2.2 AI 辅助数据建模：从业务描述到表结构

数据建模是 Web 应用的地基。如果用 AI 开发时数据模型设计错了，后面所有代码都是白写。好消息是，AI 在“业务描述转表结构”这件事上表现非常可靠，只要你的业务描述足够具体。

我的做法是，先把业务规则和关键字段告诉 AI，让它输出完整的建表语句或 ORM 模型，然后我拿着这份模型去对照业务需求逐条检查。重点检查三件事：

• 字段类型是否合理（金额字段用 Decimal 而不用 Float，时间字段用 DateTime 而不用 String）。
• 关联关系是否正确（一对多还是多对多，外键放在哪一侧）。
• 约束条件是否完整（唯一约束、非空约束、默认值、索引）。

举个实际例子。我做一个项目周报系统，业务描述是这样的：

“每个用户有多条周报记录，周报包含本周工作内容、下周计划、遇到的问题，还有一个状态字段表示草稿还是已提交，用户只能看到自己和下属的周报。”

AI 生成的 Django 模型简化如下：

from django.db import models from django.contrib.auth.models import User class WeeklyReport(models.Model): STATUS_CHOICES = ( ('draft', '草稿'), ('submitted', '已提交'), ) user = models.ForeignKey(User, on_delete=models.CASCADE, related_name='reports') week_start = models.DateField() week_end = models.DateField() work_done = models.TextField(blank=True) next_plan = models.TextField(blank=True) issues = models.TextField(blank=True) status = models.CharField(max_length=10, choices=STATUS_CHOICES, default='draft') created_at = models.DateTimeField(auto_now_add=True) updated_at = models.DateTimeField(auto_now=True) class Meta: ordering = ['-week_start'] unique_together = ('user', 'week_start')

单看这个模型，AI 写得相当不错。week_start 和 week_end 两个字段很合理，unique_together 保证了不会重复提交同一周的周报。但我 review 时发现一个问题：需求里说“用户只能看到自己和下属的周报”，这意味着数据模型里需要有组织层级关系，或者至少需要引入一个汇报关系表。AI 不知道你的组织架构怎么设计，所以这个关键设计必须由人来补全。

我让 AI 补了这样一个模型：

class UserProfile(models.Model): user = models.OneToOneField(User, on_delete=models.CASCADE, related_name='profile') manager = models.ForeignKey('self', null=True, blank=True, on_delete=models.SET_NULL, related_name='subordinates')

有了这个模型，“看到自己和下属周报”的权限判断才有落地的依据。这就是人机协作的意义：AI 处理机械性的建模工作，人类补全业务上下文和隐性规则。

2.3 让 AI 补测试：从“能跑”到“能维护”

我见过的 AI 辅助开发项目，绝大多数没有自动化测试。大家都觉得让 AI 把功能跑通就不错了，哪还有心思写测试。但恰恰相反，AI 生成代码时最适合做测试，因为它生成速度太快，代码量一大，回归风险急剧上升，没有测试兜底，改一个功能崩三个地方属于家常便饭。

我的要求是：关键时刻的 prompt（身份限定词）可以提前固定：AI 在训练语料里对“单元测试”的案例积累非常厚，生成质量通常比业务代码还高。尤其是 Django、Spring Boot 这类框架，测试写法标准化程度极高，AI 基本上不会出错。

实际执行时，我一般让 AI 按测试优先级补测试：

1. 核心业务逻辑的单元测试（比如状态流转、金额计算）。
2. 关键接口的集成测试（比如登录鉴权、数据权限）。
3. 异常路径的测试（比如参数缺失、非法数据）。

第四步是性能优化。把一个太太文件几百行代码全部扔给 AI 让它优化，通常会得到一堆“正确但没用”的建议。更好用的是让 AI 做针对性优化，比如“找出这个接口的 N+1 查询并修复”。

# 优化前：昨天和今天的工作记录示例 # 这里以子查询为例，展示优化做法 submitted_reports = Report.objects.filter(status='submitted') for report in submitted_reports: print(report.user.profile.manager.username) # 触发 N+1 查询

# 优化后：用 select_related 减少查询次数 submitted_reports = Report.objects.filter(status='submitted').select_related('user__profile') for report in submitted_reports: print(report.user.profile.manager.username)

这一处的优化能把接口响应时间从 800ms 降到 100ms 左右，效果立竿见影。类似的优化技巧，AI 知道很多，关键是你要会精准地向它提问。

3. 实操过程与核心环节实现

3.1 场景定义：做一个“项目周报助手”

为了让你能完整看到 AI 辅助开发的闭环，我用一个真实的小项目来演示，我们就叫它“项目周报助手”。功能很典型，也是企业内部最常见的应用场景：

• 用户注册和登录（用户名密码）。
• 用户可以创建、编辑、提交自己的周报。
• 用户可以查看自己的所有周报，以及下属的周报（只读）。
• 周报支持导出为 Markdown 文件。

技术栈选择 Django 5 + Bootstrap 5 + SQLite（演示用，生产换 PostgreSQL）。之所以选 Django，是因为它对用户认证、ORM、后台管理都提供了现成的能力，AI 对 Django 的高度熟悉能让生成质量尽量高。

你可能会说这个项目不大，但别急，我们在这上面跑完整套 AI 协作流程，多一个功能少一个功能不是关键，关键是思路能迁移到更复杂的项目上。

3.2 从需求到骨架：让 AI 先给方案

我不会一上来就让它写代码。第一步先让 AI 做方案设计，这一步能避免后面大量的返工。我的 prompt 是这样写的：

“我要开发一个项目周报助手 Web 应用，核心功能包括：用户注册登录、周报创建编辑提交、查看自己和下属的周报、导出 Markdown。技术栈使用 Django 5 + Bootstrap 5，数据库先用 SQLite。请给出项目目录结构建议、数据模型设计、每个模块的功能拆解、关键 API 设计。不需要写代码，先出设计方案。”

AI 给出的方案通常包含目录结构和模块拆解，例如：

weekly_report/ ├── manage.py ├── requirements.txt ├── config/ │ ├── __init__.py │ ├── settings.py │ ├── urls.py │ └── wsgi.py ├── accounts/ │ ├── __init__.py │ ├── models.py │ ├── views.py │ ├── urls.py │ ├── forms.py │ └── tests.py ├── reports/ │ ├── __init__.py │ ├── models.py │ ├── views.py │ ├── urls.py │ ├── forms.py │ └── tests.py └── templates/ ├── base.html ├── accounts/ └── reports/

这个结构是 Django 标准的 app 拆分方式。accounts 管用户相关，reports 管周报相关，模板单独放，后续找文件、加功能都很顺。如果 AI 给出的是把全部代码塞到 project 根目录的方案，你要警惕它的工程素养不够，及时纠正。

方案评审通过后，我再让 AI 生成项目骨架。这里我强烈建议：项目骨架用命令手动生成，别让 AI 生成。Django 官方命令又快又准：

python -m venv venv source venv/bin/activate pip install django django-admin startproject config . python manage.py startapp accounts python manage.py startapp reports

为什么手动？因为 AI 生成的 manage.py、settings.py 经常带着各种不必要的修改，很可能在第一步就给你埋雷。官方命令生成的骨架干净可靠，花费的时间不超过一分钟，完全没必要让 AI 代劳。

然后把 AI 生成的数据模型填到对应 models.py 里。这一步我在 2.2 已经演示过，这里不再重复。

3.3 核心模块开发实战：从认证到周报流程

创建完骨架和模型之后，接下来用 AI 开发三个核心模块。每个模块我都会先描述需求和约束，再加一句明确的验收标准，让 AI 生成代码。

第一个模块是用户注册和登录。我用的 prompt 是：

“在 Django 项目中实现用户注册和登录功能。要求：注册时使用 Django 内置的 UserCreationForm，登录使用内置的 LoginView，密码存储使用 Django 默认的 make_password 机制。注册成功后自动登录并跳转到项目首页。首页显示 欢迎，用户名。请生成 views.py、urls.py、templates/accounts/ 目录下的模板代码，模板使用 Bootstrap 5 样式。验收标准：注册、登录、登出三个功能都能正常使用。”

AI 生成的 views.py 大概长这样：

from django.shortcuts import render, redirect from django.contrib.auth import login from django.contrib.auth.forms import UserCreationForm from django.contrib.auth.views import LoginView from django.urls import reverse_lazy def register(request): if request.method == 'POST': form = UserCreationForm(request.POST) if form.is_valid(): user = form.save() login(request, user) return redirect('home') else: form = UserCreationForm() return render(request, 'accounts/register.html', {'form': form}) class CustomLoginView(LoginView): template_name = 'accounts/login.html' redirect_authenticated_user = True next_page = reverse_lazy('home')

AI 这道题交得不错。它没有重造轮子，用的全是 Django 内置组件，代码简洁且安全。如果你指定的技术栈不是 Django，换成 Flask 也一样，让 AI 优先用生态内成熟库，而不是自己手写认证逻辑。

第二个模块是周报的创建、编辑、提交。这是业务核心，prompt 必须把状态流转讲清楚：

“实现周报管理功能。模型参见 reports/models.py，包含草稿（draft）和已提交（submitted）两种状态。要求：用户创建周报时默认状态为草稿；用户可以编辑状态为草稿的周报；点击提交按钮后，状态变为已提交，之后不能再编辑。已提交的周报需要在列表中标记。创建和编辑只能操作自己的周报。请生成 reports/views.py、reports/urls.py、reports/forms.py 以及对应模板代码。验收标准：草稿可以反复修改，提交后不可修改；越权操作返回 403。”

这个模块的难点是“提交后不可修改”和“越权返回 403”。AI 如果提示词里没写清楚验收标准，通常只会实现“能创建能编辑”，不会考虑状态约束。加了验收标准，AI 就会主动用 UpdateView 的 dispatch 方法或自定义 mixin 来做权限控制。

第三个模块是查看自己和下属的周报。这里要注意，性别化表述和权限判断逻辑，是 AI 最容易出现问题的点，因为向下的层级关系有很多业务规则。我的 prompt 是：

“实现周报查看列表。用户登录后，首页显示自己的周报列表和下属的周报列表（通过 UserProfile 的 manager 外键关联）。下属周报只能查看，不能操作。列表按周报开始时间倒序排列，分页展示，每页 10 条。请生成 home 视图及模板。验收标准：用户只能看到自己和直属下属的周报，看不到其他人的。”

这块 AI 生成的关键逻辑如下：

def home(request): if not request.user.is_authenticated: return redirect('login') my_reports = WeeklyReport.objects.filter(user=request.user) subordinate_user_ids = UserProfile.objects.filter(manager=request.user.profile).values_list('user_id', flat=True) subordinate_reports = WeeklyReport.objects.filter(user_id__in=subordinate_user_ids, status='submitted') # 分页处理略 return render(request, 'home.html', {'my_reports': my_reports, 'subordinate_reports': subordinate_reports})

这个逻辑基本对，但要注意一个细节：如果当前用户没有 UserProfile（比如刚注册还没分配 manager），request.user.profile 会抛异常。我 review 时发现了这个问题，加了一个 get_or_create 兜底。这种“用户画像不完整”的边界情况，AI 几乎不可能主动考虑到，必须靠人肉补全。

3.4 用 AI 做代码审查和自动化测试

主体功能开发完毕后，我会让 AI 交叉审查自己生成的代码。这个过程类似 code review，但做 review 的是 AI，效率极高。我的 prompt 是：

“请以资深 Django 工程师的身份，审查以下项目代码（贴代码）。重点检查：安全问题、权限漏洞、数据库查询性能、代码结构、异常处理。请列出每个问题的严重程度（高/中/低）、具体位置和修复建议。”

AI 的审查结果通常能发现一些我们忽略的问题，比如：

• 模板中直接渲染用户输入，存在 XSS 风险（应该用 Django 模板的 autoescape，它默认是开启的，但如果你用了 mark_safe 就危险了）。
• 某些视图没有加上 login_required 装饰器，未登录用户可能访问内部页面。
• 周报列表查询没有用 select_related，导致循环中访问外键字段产生 N+1 查询。
• 表单校验没有限制内容长度，用户可能提交超大数据量，压垮数据库。

这些问题有高有低，但每一条都有实际价值。AI 提了问题后，我会根据严重程度安排修复。高风险问题立刻改，低风险问题记录到待办清单，不影响当前上线。

测试环节我也完全让 AI 来写。我的要求是：“为 reports 应用的核心模型和视图编写单元测试，覆盖：周报创建成功、草稿编辑成功、提交后编辑返回失败、非本人周报返回 403、下属周报可见、非下属不可见。测试使用 Django TestCase。”

AI 生成的测试核心代码类似：

from django.test import TestCase from django.contrib.auth.models import User from django.urls import reverse from reports.models import WeeklyReport class WeeklyReportPermissionTest(TestCase): def setUp(self): self.user = User.objects.create_user(username='alice', password='pass12345') self.manager = User.objects.create_user(username='bob', password='pass12345') self.other = User.objects.create_user(username='eve', password='pass12345') def test_can_edit_draft_report(self): self.client.login(username='alice', password='pass12345') report = WeeklyReport.objects.create(user=self.user, week_start='2025-01-01', week_end='2025-01-07') response = self.client.post(f'/reports/{report.id}/edit/', {'work_done': '完成登录模块'}) self.assertEqual(response.status_code, 302) report.refresh_from_db() self.assertEqual(report.work_done, '完成登录模块')

这些测试跑一遍，就能把 3.3 里提到的“状态约束”和“越权操作”两条验收标准固化成自动化检查。以后任何人改代码，只要跑一下 python manage.py test，就知道有没有破坏核心逻辑。

3.5 用 AI 完成部署脚本与上线检查

开发完成不是终点，部署才是真正考验一个应用品质的环节。AI 在生成部署脚本方面同样很在行。我用它生成了 Dockerfile、docker-compose.yml 和 Nginx 配置。

Dockerfile 的核心内容如下：

FROM python:3.12-slim ENV PYTHONDONTWRITEBYTECODE=1 ENV PYTHONUNBUFFERED=1 WORKDIR /app COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt COPY . . EXPOSE 8000 CMD ["gunicorn", "--bind", "0.0.0.0:8000", "config.wsgi:application"]

Dockerfile 看起来简洁，但我 review 时发现一个潜在问题：它没把静态文件收集和迁移命令加进去。如果直接拿这个镜像部署，CSS 和数据库表都是空的。所以我在 CMD 之前加了：

RUN python manage.py collectstatic --noinput CMD ["sh", "-c", "python manage.py migrate && gunicorn --bind 0.0.0.0:8000 config.wsgi:application"]

这个细节 AI 很容易漏掉，因为它的训练语料里，很多项目是本地开发的，不会包含生产环境的完整步骤。所以生成部署脚本后，一定要在干净环境里完整跑一遍，别假设 AI 给你的就是对的。

Nginx 配置同样可以用 AI 生成，默认配置通常是监听 80 端口，转发到 8000 端口，并指定静态文件目录。生成后注意检查静态文件路径是否和 Django settings.py 里配置的 STATIC_ROOT 一致，不一致的话样式全丢，接口全通但页面丑到没法看。

上线前我还会让 AI 生成一份“上线检查清单”，包括：SECRET_KEY 是否用了环境变量、DEBUG 是否已关闭、ALLOWED_HOSTS 是否配置、数据库连接是否使用安全通道、备份策略是否就绪。不要让 AI 替你决定清单内容，而是让它根据你的项目去生成，你一条一条确认。

4. 常见问题与排查技巧实录

4.1 AI 生成代码最常见的高频问题

用 AI 开发这么久，我总结了一份“AI 代码问题高频 Top 8”，很大程度上能代表大部分项目的坑：

这张表每次项目 review 我都会过一遍。很多问题不是 AI 每次都会犯，但“每次都要检查”这个动作不能省。把检查项固化下来，形成 checklist，比临时发现再后悔高效得多。

4.2 排查思路：遇到 AI 代码报错怎么定位

AI 生成的代码报错，很多人第一反应是重新生成一遍。我的经验是：先别急着重新生成。让 AI 重新生成十次，可能错误逻辑相同或类似，而且会消耗大量时间和精力。更好的方法是把错误信息原封不动发给 AI，让它自己解释错误原因并给出修复方案。

举个例子，有次周报导出功能后台报错：

AttributeError: 'NoneType' object has no attribute 'name'

我直接把错误堆栈发给 AI，让它定位。AI 很快指出问题：代码中用report.user.profile.manager取上级名字，但这条周报的 user 没有关联 UserProfile，所以 profile 是 None，manager 就变成 NoneType。修复方案是加一个默认 manager 或者使用 getattr 兜底。这种定位速度远比人肉翻代码快。

第二种常见情况是“AI 生成的代码改了 A 导致 B 崩了”。这种回归问题靠 AI 自己解释不清，通常要借助调试工具一步步看。我把完整错误堆栈、相关代码、最近的改动记录发给 AI，它能很快识别出回归的原因。

第三种情况最棘手：代码不报错，但行为不符合预期。比如数据权限过滤没生效、缓存一直是旧数据。这个时候我会用“最小复现”的思路，让 AI 写一段本地脚本验证核心逻辑，快速定位问题出在哪一层。数据权限不生效，多半是查询条件漏了 user 过滤；缓存旧数据，多半是 cache key 设计不对。

总的来说，排查 AI 代码问题的思路和排查自己写的代码没本质区别，核心是“逐步缩小问题范围”。AI 的优势是它能快速阅读大量代码并给出候选原因，劣势是你得能判断它的候选原因是否可信。如果它给了一个感觉很离谱的答案，不要立刻接受，用日志和调试数据去验证。

4.3 避免被 AI 幻觉带偏：验证是底线

AI 生成代码时有一个很大的特点：它不会主动承认“我不确定”。你让它写一个不太常见的功能，它经常自信地给出一段看似合理但实际跑不通的代码，尤其依赖新版本库时。

我遇到最多的是数据库 ORM 层面的幻觉。比如让它生成 Django 5 的某个新特性查询，它可能实际用的是 Django 4 的语法，看着对，跑着错。所以我定了三条铁律：

1. 只要涉及框架特有 API 或新特性，生成代码后必须查官方文档确认。
2. 大型依赖库（Django、DRF、Spring Boot）的版本号写死在 requirements.txt 或 pom.xml 里，不跟着 AI 推荐走。
3. 任何 AI 生成的核心业务逻辑，必须有测试覆盖，用测试结果说话，而不是“我觉得 AI 写的应该没错”。

这三条铁律听起来严格，但执行起来成本并不高。所有代码生成后都要跑一遍测试、本地起服务验证关键流程，总共不过几分钟。这几分钟能省下后面数小时的线上排查时间，怎么算都值。

4.4 团队协作：让 AI 产出符合团队规范

如果你在一个团队里用 AI 开发，还会遇到一个更头疼的问题：AI 生成的代码风格五花八门，不同成员用不同工具、不同提示词，生成的代码混在一个仓库里，简直就是编程风格事故现场。

我的经验是先定团队规范，再让 AI 按规范生成。规范包括几个方面：Python 代码用 Black 格式化，import 排序用 isort，数据库迁移由 Django 统一管理，每个函数必须写 docstring，关键模块必须带测试。这些规范写死在提示词模板里，谁用 AI 开发都要先套这个模板。

举例，团队提示词模板的公共前缀可能是：

“你是本团队的资深开发工程师。项目技术栈为 Django 5 + Bootstrap 5 + PostgreSQL。编写代码时遵循以下规范：函数必须有类型注解和 docstring；所有配置项从环境变量读取；使用 Black 默认风格；为新增业务逻辑编写单元测试；禁止使用 mark_safe 渲染用户输入；数据库查询禁止出现 N+1。”

这样团队里不管谁用 AI 生成代码，风格和底线都是一致的。之后再配一个 AI 代码审查的流程，每次提交前让 AI 对照规范做一轮 review，基本能保证仓库代码质量稳定不跑偏。

我还试过把团队规范文档直接让 AI 生成一份“AI 协作开发规范”，包含提示词模板、代码审查清单、测试要求、上线检查清单。这样新成员进来，把这份文档丢给 AI，AI 就能照着规范和其他人对齐，不会出现“每个人都在跟不同版本的 AI 协作”的混乱局面。

5. 一点个人的体会

做 Web 开发这么多年，我最大的感受是：工具一直在变，但核心能力没有变。AI 让写代码的门槛降低了很多，但让应用真正“高品质”的那些东西，代码规范、安全意识、数据建模能力、测试习惯、工程判断力，依然牢牢掌握在开发者手里。AI 像是超级放大镜，你本身有清晰的工程思维，它能帮你放大产出；你本身思路混乱，它也会把你混乱的思路变成更混乱的代码。

我个人倾向的工作流是：AI 负责“手速”，我负责“方向”。它生成、我审查；它执行、我决策；它补测试、我定标准。每做完一个项目，我都会留出半小时，专门总结这个项目里 AI 在哪些环节帮了大忙、哪些环节拖了后腿，然后更新自己的提示词模板库。这也是我越来越顺手的原因，AI 模型在成长，我的工作流也在进化。

最后再分享一个小技巧：AI 生成代码后，不要只看最终代码，还要让它解释关键决策。问一句“为什么这里用事务？为什么这里要加索引？”它能讲出道理，说明代码大概率靠谱；它支支吾吾或答非所问，你就要警惕这段代码可能存在隐性缺陷。这个习惯帮我躲过不少坑。

希望这篇分享能让你在用 AI 打造 Web 应用的路上少走一些弯路。如果你也有自己的 AI 协作心得，欢迎在评论区一起聊。