企业官网建设流程全解析

做完五六个AI全栈项目之后，我最大的感受不是AI多强，而是大多数人把AI用歪了——丢一句“帮我写个个人博客”就干等结果，出来的东西就像新同事凭想象写了一周代码，连数据库字段都对不上，页面上全是好看但不工作的假按钮。后来我总结出一套固定打法：任何全栈项目都拆成四个指令，按固定顺序喂给AI，顺序不能乱。第一指令做需求冻结，第二指令做技术选型与架构设计，第三指令分模块实现功能，第四指令做QA审查与修复。这套流程新手拿去做毕设、老手拿去接外包、产品经理拿去做Demo验证都成立，因为本质上是把“一个工程问题”拆成“四个有依赖关系的子任务”。这篇文章就把四个指令的定义、提示词模板、实操复盘和坑全写清楚。

1. 为什么AI全栈开发需要一套固定指令，而不是一句话开工

1.1 大模型没有记忆，它只有上下文

先说底层原因。大模型本质上是无状态的推理器，每一次生成内容都基于你当前这一轮给它的上下文，以及训练时见过的大量同类项目。工具里的上下文续传功能，本质也只是把之前的对话重新拼进输入，并不是模型真的“记住”了你的项目。

正因为这样，如果你直接丢一句“帮我做个全栈应用”，AI只能从训练数据里统计出“大众脸全栈应用长什么样”，然后按概率生成。你得到的结果往往是：需求被自由发挥、技术栈是它熟悉的而不是合适的、数据库字段和前端字段对不上、页面能打开但业务逻辑是假的。这不是AI能力不行，而是你把决策空间全留给了它。AI在缺乏约束时，最擅长做的事就是“自信地编”。

所以问题不是“怎么让AI一次生成全部代码”，而是“怎么把模糊需求逐步收敛成一套可执行、可验收的工程方案”。四个指令做的事，就是人为制造约束。

1.2 顺序的本质：上一步的产物是下一步的约束

我为什么强调顺序？因为软件工程本身就有一条依赖链：需求决定架构，架构约束实现，实现提供测试与审查的对象。AI当然可以跳过某些环节强行生成，但它每跳过一次约束，就多一分自由发挥的空间，而这个空间正是幻觉和烂代码的温床。

四个指令的本质，是把这条依赖链翻译成AI的执行顺序：先冻结需求，再画架构蓝图，然后按蓝图写实现，最后以QA视角审查。每一步的输出都作为下一步的输入。举个例子，没有需求冻结书，架构师就不知道要设计哪些数据表；没有接口契约，前端和后端就会各说各话；没有代码实体，QA拿着放大镜也审不出东西。顺序一旦乱了，前面缺失的决策会一直被传递到后面，越积越离谱。

1.3 这套顺序不止写代码能用

我后来发现，“冻结-蓝图-实现-审查”这四步几乎适用于任何用AI做多步骤创作的任务：写方案、写论文、做数据分析报告，甚至处理日常文档，都遵循同一个逻辑。先确定边界和验收标准，再定结构和选型，接着分节生成，最后整体查错。顺序颠倒，结果都会往失控的方向走。所以这个项目虽然是讲代码，但方法论是可以平移的。

2. 四个指令的完整定义与提示词模板

2.1 需求冻结指令：先立规矩，再谈实现

第一指令的目标非常明确：让AI产出一份可核对的需求说明书，而不是任何代码。你把自己对产品的模糊想法倒给它，让它整理成用户故事、优先级、验收清单和“不做清单”。

我实际用的提示词模板长这样：

我要做一个多用户待办清单网站。你作为资深全栈产品经理，先做需求分析，禁止编写代码。 输出内容： 1. 8到12条用户故事，格式为“作为...我希望...以便...” 2. 功能优先级表，分P0/P1/P2 3. MVP验收清单，至少10条可勾选的检查项 4. 明确写出“本版本不做”的清单 约束：不讨论技术栈，不设计界面，不写实现方案。

为什么必须第一步做？因为需求没冻结，第二步和第三步就没有衡量对错的标准。AI在需求模糊时最典型的反应是“多送功能”——你只说要登录，它顺手做了注册验证、找回密码、第三方登录、用户昵称头像，听着贴心，实际上全是后续要维护的包袱。需求说明书的最大作用，就是把“AI觉得应该有”和“你必须有”区分开。

2.2 架构蓝图指令：先画图纸，再砌墙

第二指令是让AI基于需求说明书做技术选型、数据库设计、API设计、目录结构。这个阶段依然不写业务代码，输出的是系统的图纸。

背景：以下是上一阶段输出的需求说明书（全部粘贴进来）。 任务：你作为资深系统架构师，基于该需求做技术选型和架构设计。 输出： 1. 技术栈选型对比，说明推荐组合和理由 2. 数据库表结构（表名、字段、类型、约束、索引） 3. REST API清单（路径、方法、参数、响应样例） 4. 项目目录结构 约束：不写业务代码；不擅自增删功能；若有需求不明确之处，列出假设清单。

这一步关键在选型理由和假设清单。AI给你推荐技术栈时，它会编得像模像样，所以必须要求它说理由；同时需求里总有不明确的地方，比如“用户数据怎么存”“密码规则是什么”，让AI把这些模糊点写进假设清单，然后你逐条确认，比让它闷头决定要稳得多。

2.3 模块实现指令：一次只喂一个模块

第三指令才是真正开始写代码。但要注意，不能把整个项目一次丢给AI，要按依赖关系拆成模块逐个实现：数据模型、数据访问、后端接口、前端页面、前后端对接。

你是资深全栈工程师。现在需要按上一阶段架构设计实现[模块名]。 背景：架构摘要（粘贴相关表结构、API约定、目录约束）。 约束： - 只实现指定模块，不越权改动其他模块 - 不改动架构设计中的接口定义和数据模型 - 完成时输出一段50字以内的实现说明，方便下一模块衔接

为什么一次只做一个模块？因为AI生成代码时，如果一个文件太大、职责太多，它后期维护上下文就开始混乱，容易在文件内部制造重复逻辑和隐藏依赖。模块化实现配合每次小验收，能把错误限制在小范围内，哪一步出了问题，立刻就能定位。

2.4 QA审查与修复指令：最后一道安全网

第四指令是让AI切换到QA工程师视角，把已经生成的整个项目从头到尾审查一遍，找出越权、注入、边界条件、异常处理等问题，并直接修复。

你是资深QA工程师和代码审查员。请对本项目代码进行质量审查。 范围：全部代码。 重点： - 越权、注入、敏感信息泄露 - 外键约束、空值、重复数据 - token过期、未登录、空数组、超长输入等边界情况 - 前端异常提示是否友好 输出：问题清单（严重程度/位置/描述/复现步骤/修复建议），直接修复P0和P1级问题，修复后输出整改说明。

很多人在AI开发里会跳过这一步，觉得“能跑就行”。但实际上能跑只是起点，越权和边界问题靠肉眼很难看出来，可一旦上线就是安全事故。这一步不是锦上添花，是兜底网。

四个指令的关系我用一张总览表总结：

3. 实操实录：多用户待办清单从0到1跑一遍

3.1 第一指令实录：AI输出了可以验收的需求书

为了不写空道理，我拿一个真实跑过的项目演示：多用户待办清单网站。它麻雀虽小五脏俱全，包含注册登录、多用户数据隔离、增删改查、前端页面。整套流程走下来不到两小时，非常适合拿来讲解。

我输入2.1的提示词后，AI输出的需求书比我预期的干净得多。用户故事大概八条：注册、登录、登出、创建待办、列出自有待办、更新标题、删除、标记完成状态。优先级分得很清楚，P0是核心流程，P1是排序和搜索，P2是换肤这类锦上添花的功能。“不做清单”里明确写了：不做过期提醒、不做子任务、不做团队协作。

但验收时我发现一个关键遗漏：需求里没有“用户只能看到自己的待办”这条。AI默认了一个待办系统的共享模型，如果没有多用户隔离，这个应用就跟公开白板没区别。于是我在需求书末尾人工补了一条P0用户故事，并在后续所有指令中明确标记“此需求为人工补充”。这一步非常值得记住：AI需求分析能帮你整理，但真正对着业务场景自问的人必须是你。

3.2 第二指令实录：架构选型和数据模型的落定

我把第一指令产出的需求说明书完整贴进2.2的模板。AI给出的推荐组合是React+Vite做前端，FastAPI做后端，SQLite做存储。理由是MVP阶段单机即可支撑，等数据量上来可以平滑迁到PostgreSQL。这个理由我可以接受。

数据表结构是两张表：user表存id、email、password_hash、created_at；todo表存id、user_id外键、title、completed、created_at、updated_at。API清单覆盖注册、登录、增删改查、统计数据，都是P0需求能对上的。

我的验收动作很简单：对照需求书，确认每一条P0用户故事都能在表结构和API里找到落脚点，再确认密码字段存的是hash而不是明文。都通过，才进入实现。这个阶段是成本最低的纠错点。表结构如果写错了，等代码生成完再改，迁移脚本能把人逼疯，所以哪怕多花十几分钟验证都值。

3.3 第三指令实录：四次小循环实现前后端

按照依赖关系，我把第三指令拆成了四个子步骤。每次都是用2.3的模板，只换模块名和背景摘要。

第一步，数据模型与迁移。AI输出SQLAlchemy模型和Alembic迁移脚本。我跑完迁移后，在SQLite里检查表结构，确认user_id外键存在。

第二步，认证API。实现注册、登录、JWT签发。我拿Postman试了注册和登录，拿到token后带token访问一个受保护接口，确认鉴权生效。

第三步，待办CRUD API。实现增删改查和完成状态切换，并把user_id写进查询条件里。这一步我验收时反复测试了“不带token返回401”和“带token创建成功”两个场景。

第四步，前端页面与对接。React写登录页、注册页、待办列表页，用axios调后端接口。

这个阶段我撞上了全栈项目的经典问题：跨域。前端在Vite的5173端口跑，后端在8000端口，浏览器直接把前端请求拦了，控制台报CORS错误。解法是给FastAPI加中间件：

from fastapi.middleware.cors import CORSMiddleware app.add_middleware( CORSMiddleware, allow_origins=["http://localhost:5173"], allow_methods=["*"], allow_headers=["*"], )

还有个很容易被忽略的坑：JWT过期后，前端拿旧token请求接口，后端返回401，前端页面当时直接白屏。我让AI补齐了“收到401就清理本地登录态并跳转登录页”的逻辑。这种问题不跑到实际联调，根本发现不了。

3.4 第四指令实录：QA审查揪出了越权漏洞

模块实现完，我输入2.4的QA审查提示词。AI审完后列出的问题非常有价值，这里挑三个印象深的。

第一个是P0级别的越权漏洞：删除待办接口没有校验todo.user_id，任何登录用户都可以删掉别人的待办。AI的修复方式很专业：在查询待办时直接加上“where id=xxx and user_id=当前用户”，如果查不到就返回404，而不是先查再比较再返回403。这样既能阻止越权，又不向攻击者泄露数据是否存在。这个思路值得记录，自己人肉写代码时都不一定想得到。

第二个是P1登录接口没有速率限制，容易被人用脚本撞库。AI建议接入简单的限流依赖，并把JWT_SECRET从代码里的硬编码改成读取环境变量。

第三个是P2待办标题没做长度限制，数据库TEXT字段可以无限长，用户前端粘贴几万字，页面直接崩。AI给标题加了最大长度校验和前端截断提示。

修完这些问题后，我让AI重新跑了一遍手工回归清单：注册新用户、登录、创建、修改、勾选、删除、退出，全部通过。到这里，项目才算真正可以交付。

4. 顺序颠倒会发生什么：三种典型翻车现场

4.1 直接写代码再补需求：AI会按“见过的大众脸”自由发挥

我见过最惨的一种写法是跳过需求冻结，直接说“帮我写个待办系统”。AI凭惯性把系统做成了后台管理工具：用户管理、标签分类、任务指派、数据报表全都有，但核心的用户登录反而做得潦草。结果前端多了一堆页面，后端多了一堆接口，代码库又大又混杂。

这种“多做”不是好事，是污染。后面每修一个功能，都要在无关代码里绕路，改需求的时间比从零开发还长。AI是“最积极的新员工”，不给明确边界，它一定会按训练数据里见过的项目自由发挥。

4.2 先拍架构再冻结需求：架构变成最贵的返工点

另一种做法规避需求阶段，直接让AI设计架构。有朋友做物流小工具，先让AI定了MySQL分区加微服务结构，结果需求方只需要一个日活一千的小平台，光维护微服务的部署和调用就折腾了半个月。为什么这么疼？因为架构是牵一发动全身的决策，改一个数据模型，接口、前端、测试全跟着动。

架构阶段唯一正确的输入是需求说明书。没有需求书，AI的所有设计都是拍脑袋，它甚至可能基于“你会在三个月内扩展到百万用户”这种幻觉搭重型架子。技术方案的过度设计，比需求缺失更难发现，因为它看起来特别专业。

4.3 跳过审查直接上生产：边界条件全是窟窿

我也偷过懒。有一段时间觉得AI生成的代码“应该没问题”，写完直接部署，结果用户提交空标题任务成功，后端往数据库里写入空记录，前端统计页直接显示NaN。最恶心的是空数据已经进去了，清洗比拦截难十倍。

跳过第四指令的典型症状：空值不校验、删除接口不鉴权、token过期没提示、输入超长没截断。这些问题在开发环境里因为数据都是“正常”的，全部隐形；一旦用户用奇奇怪怪的方式操作，立刻暴露。第四指令不是流程装饰，是所有隐性问题集中爆发的最后一道拦截。

5. 常见问题与避坑实录

5.1 按顺序跑了AI还是写飞：多半缺验收标准

有人问，我明明按顺序跑了，AI为什么还是在实现阶段写飞了？我检查他的指令后发现，提示词里只有“帮我实现登录功能”，没有约束、没有验收标准、没有背景摘要。一条可靠的指令应该包含五个要素：角色、任务、输入上下文、输出格式、验收标准。其中验收标准最容易被忽略。

比如第三指令里写“只实现指定模块”还不够，最好再补一句“输出时列出本模块的测试点，方便复验”。这样AI会主动把功能做收敛。

5.2 上下文太长AI忘了需求：试试指令间的交接仪式

用过AI工具时间长了都懂，上下文一长，模型就开始顾头不顾尾。前期定的“用户只能看到自己的待办”，到后期生成前端时又被忘掉，页面把所有用户的待办都渲染出来了。

我的解决办法是给每次阶段交接做一个仪式：让AI在本阶段结束时输出一段150字以内的《当前状态摘要》，包括已完成内容、关键决策、遗留风险。下一条指令里把摘要作为背景贴在开头。这等于给AI做了显式的短期记忆同步，效果比硬拉超长上下文好得多。

5.3 多AI协作时怎么分工：变成流水线

如果你手上有多个AI工具，或者用团队账号协作，完全可以把四个指令变成流水线。需求冻结阶段交给擅长产品分析的模型，输出需求书；架构蓝图阶段交给擅长系统设计的模型；模块实现和QA修复阶段交给接入了代码库的编辑器型AI。每个阶段的结果往下游传，交接仪式变得更重要。多AI协作最大的问题不是模型不够聪明，而是阶段之间的信息断层，有了明确的交接物，流水线才能跑顺。

5.4 AI代码有缝合感：把注释当验证线索

AI生成代码偶尔会有一种“缝合感”：风格不统一，命名忽长忽短，同一种操作换了三种写法。这让后期维护非常难受。

我的做法是让第三指令的每个模块输出里带上简短实现注释，然后在QA审查时加一条指令：“检查代码注释所声称的逻辑是否与实际代码一致。若不一致，标记为高风险项。”这一招很灵，AI在编造“它以为自己写了”的逻辑时，会被自己的注释戳穿。审查完再让它做一次全局重构，把命名和风格统一。

我个人现在跑新项目，基本都会先把四个指令的模板存成文档，每个项目开始时复制一份，只改需求描述。前几次可能觉得流程繁琐，跑过两个完整项目之后就会发现，按顺序跑省下来的是最贵的返工时间。真正需要约束的不是AI，而是我自己那颗想一步到位的心。