企业官网建设流程全解析

说实话，我过去半年对“AI写代码”这件事的态度一直有点拧巴。一方面日常确实在用Copilot补全，确实能省不少敲键盘的时间；另一方面总觉得它离“独立交付一个完整项目”还差得远，更别提什么“全程不写几行代码”。直到前阵子，我用AI端到端交付了一个真实上线的项目——从需求梳理、技术选型、数据库建表、后端接口到前端页面，甚至测试用例和部署文档，全程几乎没亲手写代码。这个项目不大，但完整走完了从0到上线的生命周期，整个过程让我对AI辅助开发的边界和正确姿势有了完全不同的理解。

先说结论：AI确实能帮你交付一个完整项目，但前提是你得把自己从“编码者”切换成“架构师+产品经理+测试工程师”的复合角色。AI写代码的能力早就够用了，真正不够用的是人这边——你能不能把需求说清楚，能不能把任务拆到足够细，能不能在每个环节用对Prompt，能不能在关键时刻介入而不是全盘放手。这篇文章我会完整拆解整个交付流程，包括每个环节怎么和AI配合、具体提示词怎么写、哪些地方AI会翻车、哪些地方必须人来兜底，希望能给正在犹豫要不要用AI做全栈开发的朋友一些参考。

1. 项目从哪来，为什么敢让AI全程主导

1.1 项目背景：一个典型的小型全栈应用

先说项目本身长什么样。我要做的是一款面向小团队的项目协作工具，核心功能包括任务看板、成员管理、评论通知和简单的数据统计。业务上不算复杂，但横截面不小——得有用户登录注册、权限区分、看板拖拽、多人协同、WebSocket实时推送、数据可视化报表。技术栈我一开始就定为前端React + 后端Node.js + 数据库PostgreSQL + Redis做缓存和实时推送。这个选型也算是我比较熟悉的家底，但真让我自己手写，保守估计也要四周左右，还得天天熬夜调样式修Bug。

之所以决定让AI主导，背后有一个我观察到的信号：我花了一个下午测试了几款主流的AI代码生成工具，发现它们对于“有清晰文件结构、有明确接口定义、有完整数据库Schema”的中小型全栈项目，生成代码的准确率已经高到离谱。与其自己从第一行写到最后一行业，不如把精力花在怎么把需求翻译成AI能理解的精确指令上。我给自己定的评估周期是两周，如果跑不通就切回手写，结果实际六天就完成了第一版可演示的成果。

1.2 先摸清AI能力的边界：什么能交、什么不能交

动手之前，我先花了一天时间整理出“AI擅长什么、不擅长什么”的清单，这步决定了后面整个流程的节奏。

AI擅长的部分包括：根据清晰需求生成基础代码骨架、写CRUD接口、生成数据库表结构、写样式组件、翻译代码逻辑、生成单元测试。这些工作技术含量不算高，但量大、琐碎、容易出错，正好是人类的痛点。

AI不擅长的部分也很明确：需求模糊时做决策、复杂的业务状态管理、多模块间隐性依赖关系、性能瓶颈的定位、安全边界的设计。这些恰恰需要人来兜底。

我不建议任何人一上来就让AI“全权负责”，因为它在模糊场景下会非常自信地编造一个看起来合理的方案，而你可能要到很晚才发现这方向根本不对。正确的打开方式是：人负责把模糊变得清晰，AI负责把清晰变成可运行的代码。

2. 我把项目拆成七个环节，每个环节都交给AI

整个交付流程我拆成了七个环节，每个环节都有独立的交付目标和验收标准。这个拆法来自我以前用瀑布流思想管理项目的经验——先定义清楚输入和输出，再往中间填过程，AI的执行效率会指数级提升。

2.1 需求拆解与用户故事生成

第一步不是写代码，而是做需求梳理。我建了一个空的Git仓库，然后在里面新建了一个docs/目录，把我的原始需求文档切碎喂给AI。

这一环节的Prompt核心逻辑是：让AI扮演产品经理，把模糊的自然语言需求改写成标准用户故事。我给的提示词是：

你是一名资深产品经理。请把我下面的需求改写成标准的用户故事，格式为 “作为[角色]，我希望[功能]，以便[价值]”，并自动拆出优先级、验收标准 和关联业务规则。需求原文如下：...

这一步的作用被很多人低估了。用户故事这个东西看似只是格式转换，实际是在强制你思考每个功能的价值闭环——谁在用、怎么用、用了之后得到什么。AI生成的用户故事质量相当高，它会自动补出很多我原本没考虑的边界规则，比如“任务逾期时应该通知创建人”“删除任务前应该二次确认”这类细节。

最后我得到了30多个用户故事，按优先级分成P0、P1、P2三档。P0是核心闭环功能，必须全部交付；P1是体验增强功能，时间允许就做；P2直接砍掉。整个需求梳理过程不到一天，比我以前手动写需求文档快了不止一倍。

2.2 架构设计与技术选型

拿到用户故事之后，下一步是技术方案设计。这一步也是让AI扮演架构师角色，但有个关键细节：我不允许它自由发挥，而是给了它约束条件。

我的提示词结构是这样的：

你是全栈架构师。基于下面的技术栈和业务需求，输出： 1. 推荐的目录结构（前端和后端分开，标清每个目录职责） 2. 数据库表设计（含表名、字段、类型、索引、外键关系） 3. API接口清单（含方法、路径、请求参数、响应结构） 4. 核心业务流程时序说明 技术栈：React + Node.js + PostgreSQL + Redis 业务需求：{上一步产出的用户故事，按P0优先} 约束：不使用微服务；不使用ORM，用原生SQL；单机可部署；开发周期两周

重点在“约束”四个字。AI默认会倾向复杂方案，比如给你上个Kubernetes、搞个消息队列，你如果不摁住它，生成的方案会让你后期运维想哭。我明确加了“不用微服务、不用ORM、单机部署”这几个硬约束，它输出的方案就干净利落得多。数据库表一共设计了11张表，接口清单列了47个，目录结构清晰到可以直接照着建项目。

2.3 数据库设计与建表脚本

架构方案评审通过后，我让AI直接输出数据库建表脚本。这一步的Prompt要非常具体，需要把字段类型、约束、索引策略都讲清楚。

基于以下表结构定义，生成完整的PostgreSQL建表DDL脚本。 要求： 1. 所有主键使用UUID类型，默认值用gen_random_uuid() 2. 所有表必须包含created_at、updated_at字段，类型为TIMESTAMPTZ 3. 外键必须命名规范为fk_表名_字段名 4. 为高频查询字段添加索引，并在注释中说明索引用途 5. 输出前先检查字段完整性，不要遗漏必填字段 表结构定义：{上一步输出的11张表}

生成完DDL之后，我没有直接执行，而是做了一次“双人复核”——让AI反向检查自己的建表脚本，再让AI生成一份“检查清单”供我人工确认。AI检查出的几个问题确实命中要害，比如漏了任务状态字段的默认值、评论表少了一个楼层号字段、通知表缺少已读状态索引。这种来回校验的机制，比我自己盯着DDL一遍遍硬啃高效得多。

2.4 后端接口与业务逻辑开发

后端开发环节是整个交付流程中主导性最强的部分。我按接口清单把47个接口分批喂给AI，每批通常5到8个，提示词模板统一为：

请实现以下API接口。技术栈：Node.js + Express + PostgreSQL（原生SQL）。 接口清单： {接口列表，含方法、路径、请求参数、响应结构} 通用要求： 1. 所有接口必须做参数校验，非法参数返回400及错误码 2. 涉及业务规则的逻辑要写在事务中 3. 接口返回结构统一为{code, data, message}格式 4. 每段代码必须带完整注释，说清逻辑 5. 错误处理必须覆盖常见异常情况

这一步的核心经验是：接口颗粒度要足够细。

一次给AI太多接口，它的输出质量会明显下降——不是漏了参数校验，就是接口之间的逻辑互相打架。我一开始试过把47个接口一次性全喂进去，结果生成的代码能用但问题非常多，排查还挺费劲，后来果断改成按模块分批处理。每个模块完成后，先让AI生成简单的接口自测脚本，我本地跑通了再进入下一个模块。

后端代码AI写得快，但业务规则这部分绝对不能只让AI自己发挥。比如任务看板的“状态流转权限校验”——只有任务创建者和项目建设者能移动任务状态，这条规则AI从需求文档里能概括出大概方向，但做不到完全贴合实际意图。它生成的代码会在某个环节多放行一层判断，或者把校验逻辑放在不该放的位置。这种时候就得人工介入，在Prompt里明确告知规则细节，甚至直接给伪代码。

2.5 前端页面与组件开发

后端接口写完一个模块，我就开始让AI同步开发对应的前端页面。我觉得这是这次交付里体验最爽、也最容易被低估的部分。

前端开发的Prompt模板长这样：

根据以下UI示意和接口文档，用React + Tailwind CSS实现该页面。 UI要求： 1. 整体风格为简洁专业，主色调为#1E3A5F，辅色调为#4A90D9 2. 桌面端优先，适配1280px以上宽度，不需要做移动端适配 3. 所有表单要有校验提示，提交失败时以Toast方式反馈 4. 无数据时展示空状态插画和引导文案 5. 组件拆分要复用，列表项独立为组件 接口定义：{接口文档片段} 页面功能描述：{该页面的功能说明}

你可能会觉得前端比后端好写，其实恰恰相反。前端代码的验证成本更高——逻辑对没对，跑一眼就知道；样式差多少，同样跑一眼就知道。AI生成的页面最大的问题不是能不能跑，而是好不好看、交互顺不顺手。它默认生成的样式总是千篇一律的居中卡片加蓝色按钮，看多了会产生一种“这是AI做的”的感觉。

解决这个问题的方法很土但很有效：先让AI快速生成一版能跑通的页面骨架，然后我逐页人工过一遍，把不顺眼的区域单独截图描述给AI去改。比如“看板列标题区域加粗，任务卡片增加左边框颜色标记优先级”“侧边栏导航增加折叠按钮，折叠后只显示图标”，AI收到这种指令后改得飞快。整个前端开发用了大约三天，UI不能说惊艳，但绝对干净整齐可用。

2.6 联调与自动化测试

前后端联调这个环节，AI的优势在于能帮你自动编写高覆盖率的测试脚本。

我的做法是让AI先分析接口文档，输出测试用例清单，然后根据测试用例生成自动化测试代码。接口测试用的工具是Postman + Newman，前端E2E测试用的Playwright。AI生成的测试覆盖程度比我手写的高很多，因为它会快速穷举参数组合，把各种边界值都枚举出来。

有一个Python脚本生成的测试用例我记得很清楚。在测“任务列表分页”这个接口时，AI自动生成了页码为负数、页大小超过上限、排序字段不存在、过滤条件格式非法等12个用例。这些边界点我自己写的话大概率会漏掉两三个。

不过我并不建议完全放手让AI跑测试。至少要有一个高级别的冒烟测试集合由人自己过一遍，因为AI的测试很容易陷入“自洽但错误”的状态——代码和测试都基于同一个错误假设，两边都跑得通，但业务上一用就有问题。这种虚假安全感是最危险的。

2.7 部署与上线

部署这一步我用的是Docker + Docker Compose，音频服务、PostgreSQL、Redis、前端静态文件全部用容器搞定。AI在这里的发挥空间不大，主要是生成Dockerfile和docker-compose.yml文件，以及写一份部署说明。

但这里有个坑，AI生成的Dockerfile质量堪忧。它会默认使用latest标签的基础镜像、漏掉分层缓存的优化、不加健康检查。对于内网部署，这倒无所谓；但你要是打算公网上线的，安全扫描一定得自己做。我给AI加了明确的安全要求后，它生成的配置才达标：

请生成生产环境的Dockerfile和docker-compose.yml，要求： 1. 前端使用多阶段构建，用nginx作为最终运行镜像 2. 后端使用非root用户运行，端口绑定必须显式声明 3. 安装依赖时锁定版本，不使用latest 4. 数据库和Redis必须设置持久化卷 5. 必须配置健康检查指令

部署到云服务器后，全流程测试一遍，项目在第六天晚上正式对外可用。整个过程从需求到上线只用了六天，其中还包括了我大概半天时间被其他事情打断。

3. 实操实录：一条典型功能的完整交付链路

理论的流程说完了，我拿实际项目里“任务拖拽换列”这个功能做例子，完整展示一遍AI交付的链路。

3.1 从用户故事到数据库变更

“任务拖拽换列”背后的用户故事是“作为项目成员，我希望在看板中拖动任务卡片到不同列表，以便更新任务状态”。需求拆解下来的业务规则包括：只有项目成员才能执行拖动；任务状态只能按流程顺序流转，不能跳列；拖动后要记录操作日志，并实时通知其他在线成员。

我先让AI基于这些规则补充数据库设计。它给出的结论是：任务表增加一个position字段用于标识同列内的排序，新增一个task_activity_log表用于记录操作日志。这两个变更AI在几分钟内生成完了，附带完整的DDL脚本和索引建议，比如position字段需要和看板列ID建立联合索引以支持排序查询。

3.2 后端接口的Prompt迭代过程

数据库确定后，开始写后端接口。需求的接口有两个：更新任务列和排序，获取看板完整数据。Prompt写得比较详细：

请实现两个API接口： 接口1：PUT /api/tasks/{taskId}/move 请求参数：targetColumnId（目标列ID）、position（目标排序位置） 业务规则： 1. 只有项目成员可以调用，非成员返回403 2. 目标列必须属于同一看板 3. 更新任务列的同时，更新对应列内所有受影响任务的position值 4. 所有更新操作必须放在同一数据库事务中 5. 操作完成后，向Redis指定频道推送一条事件通知，频道为 board:{boardId}:events 6. 返回更新后的完整看板数据 接口2：GET /api/boards/{boardId} 返回该看板全部列、任务、成员信息，要求一次查询完成，不要出现N+1问题

第一版生成后我Review了一遍，发现一个问题：AI在更新position值时只处理了目标列，没处理原列剩余任务的position回移。这种隐性逻辑缺失在复杂业务场景里非常普遍。我不直接改代码，而是把缺陷描述反馈给它：

你生成的move接口有缺陷。当前实现只更新了目标列内的position，没有处理 源列中剩余任务的position回移。请分析原列剩余任务的position应当如何 调整，生成修正后的完整接口代码。

AI很快给出了正确的修正版本。整个迭代过程大约四次来回，最终接口代码逻辑完整，通过了我预设的测试场景。

3.3 前端交互的开发过程

前端做拖拽功能，技术选型用的是经典的react-beautiful-dnd库。AI按我的UI说明生成了看板页面的代码，包括拖拽监听、列高亮、任务卡片动画等。

第一版跑通后，我发现拖拽时的性能不太好，卡片轻微卡顿。AI分析后给出的原因是：任务卡片组件没有使用React.memo进行记忆化处理，拖拽导致整个看板树频繁重渲染。它给出的修复方案是给每个卡片组件添加记忆化，并把dragId状态从全局上下文改为局部状态。修复后明显流畅了。

有意思的是，修复性能问题的这段代码，AI没有写任何注释，逻辑也不复杂。我反而觉得这才是正确的判断——不是所有代码都要配注释，有些优化措施在代码层面一眼就能看懂。

3.4 联调和测试的环节记录

功能开发完成后，进入联调测试。我让AI在Playwright里写了一段自动测试脚本，覆盖拖拽换列、拖拽超范围回弹、非项目成员试图拖动等场景。

这里AI踩了一个值得记录的坑——拖拽在Playwright里和人工操作有细微差别，AI写的脚本用mouse.move模拟拖拽，但没有考虑到拖动过程中的动画时长，断言老是提前执行导致测试挂掉。修复方式是增加等待动画结束的显式等待，代码片段如下：

await page.mouse.move(startX, startY); await page.mouse.down(); await page.mouse.move(targetX, targetY, { steps: 10 }); await page.mouse.up(); await page.waitForTimeout(300); // 等待拖拽动画结束 // 进行断言

这种问题在人工测试时根本不会遇到，反而是自动化测试常常踩的坑。AI能把脚本生成出来，但处理这种真实环境下的时序问题就需要人介入判断。最终这个功能的完整交付周期大约一天，其中AI生成代码占用的时间不到三小时。

4. 全程AI交付踩过的坑与排查实录

六天交付整体算顺利，但过程中踩的坑也不少，有些是AI本身能力限制，有些是我自己使用姿势不对导致的。整理几个最典型的案例供参考。

4.1 AI的“幻觉数据库”问题

这个坑发生在我让AI生成某个报表查询接口时。项目里有一个需求是统计每个成员本周完成的任务数，AI生成的SQL里引用了一个叫做user_weekly_stats的视图，但项目里根本没建过这个视图。AI非常自信地解释“建议先创建一个物化视图来优化查询”。

当时如果直接执行这段SQL必然报错，排查时你还会怀疑是不是自己漏建了表。这算是AI典型的幻觉问题——它在训练数据里见过类似模式，就没意识到当前项目里没有这个视图。解决办法简单粗暴：每个生成的SQL必须先在数据库执行一遍，执行前把所有涉及的表名和字段名列出与Schema核对。

4.2 上下文窗口裂缝：改A崩B

AI代码生成工具都有上下文长度限制，项目大了之后你不可能把所有代码都塞进一次对话里。我吃了好几次“改A崩B”的亏——让AI修改某个模块的工具函数，它基于不完整的上下文重写了这个函数，导致调用它的另一个模块直接报错。

后来我总结出的解决方式是：每次修改前，把受影响的文件内容和依赖关系一起告诉AI。比如我要改任务列表的排序逻辑，我会把相关接口代码、前端列表组件代码、以及数据流的传递路径一起贴进Prompt，然后明确要求“只改我指定的函数，不要改动其他任何逻辑”。AI在这种强约束下表现靠谱得多。

4.3 Prompt定义越细，交付越稳

这个坑是反向的。前期有几个接口我图省事，Prompt只写了“根据接口文档实现任务相关接口”，结果AI生成了一版“能用但乱”的代码——错误处理风格不统一、事务边界乱设置、日志打印满天飞。这些不致命但后期维护成本高的问题，根源就是我Prompt定义不够细。

同一个AI，在明确的约束下和模糊的指令下，产出的代码质量天差地别。这个差异比模型本身版本差异还大。后面我开始建立自己的Prompt模板库，把接口实现、页面实现、DDL生成、Bug修复等常见任务的Prompt模板固定下来，每次只改业务部分。这套模板在我后续的项目里也一直在复用。

4.4 安全隐患排查要人工兜底

安全方面AI的表现两极分化严重。让AI写登录注册模块，它默认会用JWT做身份认证，会用bcrypt做密码哈希，这部分基础功能够扎实。但当你让它写“忘记密码”流程时，它生成的重置密码接口没有做临时令牌过期校验，任何人都能通过一个不长久的链接修改密码。这种漏洞在功能测试阶段测不出来，只有做安全评审才会发现。

我的做法是：所有涉及认证、授权、支付这类安全敏感代码，必须做一次人工安全专项审查，不让AI做最终确认。你用AI写代码可以接受，但你不能用AI的安全判断当安全边界。这个底线绝对不能松。

4.5 常见问题速查表

5. 哪些环节最该人工介入，AI的边界在哪

六天用下来，我对“AI端到端交付”的体会是：它可行，但不是每个环节都可以做到端到端。有些环节AI的参与度能到90%，有些环节你如果放手就是给自己挖坑。

5.1 我建议AI参与度最高（90%+）的环节

数据库表结构生成、CRUD接口实现、前端页面骨架搭建，这三个环节AI的完成度最高。它们的特点是目标明确、模式固定、验收标准清晰——这类工作本质上就是“翻译”，把需求翻译成代码，AI做翻译的能力现在已经相当可靠。

复盘下来，这三个环节省了我大概70%的时间。以前写一个列表页面的增删改查，前后端加一起怎么都得大半天；现在让AI动手，一个多小时全部搞定，剩下的时间主要用于样式微调和边界逻辑补充。

5.2 我建议AI只做辅助（50%左右）的环节

架构设计、复杂业务状态管理、跨模块功能联调，这几个环节AI的输出只能当草稿用。它能在你给定约束后快速生成候选方案，但方案的取舍判断得人来做。比如架构设计时，AI给了单数据库方案和读写分离方案，它推荐读写分离的原因是“性能更优”，但它没考虑到我们的业务量下，单库完全够用且运维成本低得多。

如果让AI独自决策，它总是倾向于选择看起来“更先进”的方案。这时候你一定要有自己的判断力，这个判断力不来自于编程能力，而是来自于对业务规模、团队能力、运维成本的综合理解。

5.3 我建议人全面主导（0-20%）的环节

安全设计、权限模型、数据备份与恢复策略，这三个环节我建议人全面主导，AI至多做执行层的工作。权限模型是项目里最容易埋雷的地带——多角色多层级的数据隔离，每个角色能看哪些数据、能操作哪些功能，这种规则用自然语言描述给AI，它经常会在某些分支上多放行一层判断。

数据备份与恢复也一样，AI生成的备份方案通常只是简单定时备份，但真正出问题时怎么恢复、恢复到什么时间点、恢复后数据一致性怎么校验，这些需要人来定策略。AI能帮你写执行脚本，但它对“你这个项目的数据到底多重要”没有概念。

5.4 什么类型的项目适合AI端到端交付

最后聊一下AI端到端交付的适用范围。纯前端展示页面、小型全栈CRUD管理系统、内部工具、原型验证型项目，这类项目用AI效率提升极其明显。特别是原型验证类项目，你有个想法想快速验证市场反馈，用AI几天撸一版可用产品出来，比传统开发模式成本低太多。

反之，实时性要求极高、并发量很大、安全合规要求严格的项目，比如交易系统或医疗数据处理，我个人建议谨慎再谨慎。技术上AI生成的代码也许没毛病，但这类项目需要的严谨流程、安全评审、架构论证，AI目前替代不了。AI是个加速器，不是保险箱，边界认清，它就能成为你的利器。

最后再分享一个我自己的心得体会。这次项目交付完，我复盘最大的变化不是“少了多少行代码”，而是我的工作重心彻底转移了——以前我花大量时间在“怎么实现”上面，现在我全部精力放在“做什么”和“为什么做”上面。需求定义足够清晰，AI执行起来几乎不用返工；需求本身模糊，AI再强也做不出对的东西。这可能就是AI时代开发者的新基本功吧。