企业官网建设流程全解析

先交代一下背景：上个月我刚用 AI 端到端交付了一个内部项目，从需求梳理、原型设计、数据库建模、后端接口、前端页面到部署上线，全程自己手敲的代码加起来不超过 50 行。这句话听起来很像标题党，但它是我最近一次真实到不能再真实的 AI 工程实践。

项目本身不复杂，是个典型的内部效率工具：给某公司项目管理部门做的“周报自动汇总与风险预警系统”。各项目组把每周进度、人力投入、风险和阻塞项填到一个统一表单里，系统自动汇总成周报、按规则做风险评分，并把异常项目自动提醒给负责人。这类系统需求边界清晰、不涉及高并发、没有太复杂的业务逻辑，是典型的适合 AI 辅助开发的场景。整个过程里，我的角色更像产品经理、测试和部署运维的合体，真正需要我动手写的代码，只有几段把模块粘起来的胶水代码。

这篇文章没有打算吹嘘“AI 取代程序员”，相反，我想把这次端到端交付过程中踩过的坑、总结出的提示词方法、以及最后“没写几行代码”的真实含义全部拆开讲清楚。如果你是独立开发者、内部工具负责人，或者正在观望能不能让 AI 帮忙扛项目，这篇应该能给你一些可直接复用的参考。

1. 项目背景与整体思路：为什么敢让 AI 主导交付

1.1 这个项目到底做了什么

需求源头很朴素：公司里面项目管理一直靠邮件和共享表格，每周各项目助理把内容填进 Excel，再由管理部门的人加班粘贴汇总，再做一版没什么人看的 PPT 周报。这个过程每周消耗大量人力，而且数据一多就容易漏、容易错。

所以这个系统的核心价值就三条：统一收数、自动汇总、异常预警。各项目组通过一个网页表单提交每周数据；后端按项目和周数做汇总计算，生成结构化的周报内容；按照延期天数、风险等级、人力占比等规则打风险分；负责人登录后可以看到风险看板，异常项目自动触发邮件提醒。权限模型也很简单：普通成员提交数据，项目负责人看汇总，管理部门看全量。

这类项目有一个共同特征：它不性感，但足够典型。功能模块相对独立，数据流转清晰，没有复杂的实时性要求。正因为它“普通”，AI 生成的代码质量才足够高。我见过很多人一上来就让 AI 写电商中台、写高并发系统，然后抱怨 AI 代码不可用——这其实是选错了场景，不是 AI 不行。

1.2 我的决策依据：什么样的项目适合 AI 端到端交付

这次我敢让 AI 主导，是提前过了一遍判断条件。我把它总结成四个问题：

• 需求是否足够清晰，能不能用 30 分钟写出完整的用户故事？
• 涉及的领域知识是否常见，比如 CRUD、表单、权限、报表，不需要资深行业专家才能理解？
• 性能和稳定性要求是否在合理范围内，内部工具用户量通常只有几十上百人？
• 失败成本是否可控，最坏情况就是退回人工表格，不会造成严重事故？

这四个问题全部回答“是”，才值得做 AI 端到端交付的尝试。如果其中有一条踩线，比如涉及核心交易链路、有复杂算法、需要对接老旧系统，我建议还是老老实实自己写核心部分，AI 只做辅助。

这里有个很多人容易忽略的点：AI 生成代码的能力边界，其实和“这个需求的公共知识密度”高度相关。越是常见的需求，网上类似实现越多，AI 的输出质量就越高。越是冷门、需要通过特殊业务规则才能理解的需求，AI 输出越容易偏，改起来成本反而比从零写更高。

1.3 工具组合与分工思路

我没有用某一个“超级工具”一把梭，而是按阶段组合了三种角色：对话式大模型负责架构设计、方案讨论和代码初稿生成；AI 编程助手负责补齐前后端脚手架和代码补全；代码审查工具负责帮我盯着 AI 生成的代码里有没有明显逻辑漏洞。工具不在多，关键是分工清楚。

整体流程我划分成了五个阶段：需求澄清与方案设计、数据库与接口设计、核心代码生成、测试与修复、部署与文档。每个阶段的入口，我都要求 AI 先输出“计划”，再输出“执行产物”。比如在设计阶段，我先问 AI 要一份技术选型对比表；在开发阶段，我要求它先给出接口契约，再写代码实现。这个习惯帮我省掉了大量返工，因为 AI 在计划里暴露出来的问题，远比在代码里暴露出来更好修。

2. 需求、原型与数据库设计：AI 介入的第一站

2.1 需求拆解提示词：把模糊需求变成可执行条目

很多人第一句话就问“帮我做一个周报系统”，然后 AI 输出一堆天马行空的东西。我试过几次之后学乖了：需求阶段不能偷懒，但也不用手写完整 PRD，而是让 AI 通过连续提问帮你把需求补全。

我用的提示词是这样设计的：

我准备做一个内部工具，场景如下：各项目组每周提交一次项目周报数据，包含项目进度、风险、阻塞项、人力投入。我作为管理部门，需要系统自动汇总所有项目的周报，并生成风险预警。在我开始开发之前，请你先作为资深产品经理，向我提问至少 10 个会影响功能设计的问题。问完之后，再根据我的回答整理一份功能清单和数据字段清单。

这一招非常好用。AI 会主动问：项目有多少个、周报的统计口径是什么、风险等级怎么定义、要按角色区分权限吗、是否需要历史趋势、需要在移动端看吗、邮件提醒还是企业微信通知、数据量大概多少……这些问题看着普通，但恰恰是决定数据表设计的关键。我把这些问题逐一回答完，相当于已经有了一份高质量的轻量 PRD。

接下来我会让 AI 把功能清单转成用户故事格式，并标注优先级。这一步的作用不是给人看，而是给后续开发阶段的 AI 建立统一的上下文。后续每次写代码，我都会把这份用户故事清单贴在提示词前面，让 AI 始终围绕同一套需求实现，避免生成到一半就开始自由发挥。

2.2 让 AI 出技术方案，我负责挑剔

技术选型阶段，我先给 AI 限制边界，不直接问“用什么技术栈”，而是问“这个场景下推荐什么技术栈，理由是什么，有没有更轻量的替代方案”。我刻意在提示词里加了约束：

我只需要一个内部工具，预计 50 人使用，不需要微服务，不需要容器化，但需要部署简单、维护成本低、一个人能搞定。请给出技术选型建议，必须包含：前端方案、后端方案、数据库方案、部署方案、各自的取舍、你的最终推荐。

AI 最终推荐的是前后端不分离的轻量方案：服务端渲染加简单页面、一个关系型数据库、一个进程就能跑完。这个方案我认为是合理的。很多人一上来就用前后端分离加重型框架，对内部工具来说完全是过度设计，后续维护和部署都在给自己挖坑。

这里我有一个习惯：AI 给完方案后，我一定会追问一句“这个方案的瓶颈在哪里，什么情况下会撑不住”。这次 AI 指出，如果同时提交人数超过 200，数据库写入会开始出现排队，建议后续加缓存。这个信息让我对系统边界有了清晰认知，而不是想当然觉得系统能无限扛量。技术方案里的每一个建议，我都会让 AI 给出“基于什么假设”。假设明确，方案才可信。

2.3 数据库表结构设计评审

数据库设计是这次项目中 AI 表现最超预期的环节之一。我先给它一段话描述业务对象，然后让它输出建表语句，包括字段类型、索引和注释。AI 生成的表结构大致合理，但我并没有直接采用，而是做了一次严格评审。

让我印象最深的是风险评分字段。AI 最初的设计是直接把风险等级写到项目表里，每次读取时判断。我追问了一句：“风险等级是通过规则计算出来的，还是用户手动填写的？”这个问题的实际意义是：如果用计算规则得出，就不该存储，应该实时计算或在写入时统一计算，否则会出现数据不一致。AI 被我提醒后修正了设计：项目表存原始数据（延期天数、风险标记、人力数据），风险等级由后端统一计算后落库。这就是典型的需要人来把关设计、而不是无脑拷贝 AI 输出的场景。

我还让它给每张表补充了 created_at、updated_at 两个审计字段，并给所有外键建了索引。这些细节如果让 AI 主动做，它偶尔会漏，但只要你点一下，它能补得很完整。我自己的体会是：数据库设计阶段，人的价值不在于自己画 ER 图，而在于能把业务规则问题变成 AI 能理解的字段级问题。

3. 核心功能实现：从零生成代码到落地

3.1 后端接口的生成与修改

整体架构定下来之后，后端部分我让 AI 按照接口契约来生成代码。我先要求 AI 输出一份接口清单，标注请求方法、路径、入参和出参。有了契约，后续生成代码就有章法，也不会前后端各说各话。

我采取的生成方式是一次性给 AI 一个完整上下文，包含用户故事清单、表结构、接口契约，然后用一段标准化提示词开始生成：

请根据以下表结构和接口契约，生成完整的业务代码。要求：使用 [技术栈]，遵循 [项目目录结构]，每个接口必须包含参数校验、异常处理和统一返回格式。先列出你准备创建的文件清单，再逐个文件生成代码。

第一版代码生成后，我做的第一件事不是跑起来，而是让 AI 自己给自己做代码审查。我会用这样的提示词：

请检查你刚才生成的代码，找出至少 5 个可能的问题，包括空指针、SQL 注入、事务缺失、状态码不规范、接口返回结构不一致。找到问题后直接给出修复后的代码。

这一步非常有效，因为 AI 对自己生成的代码有全局上下文，让它做“自我批评”比人肉去翻代码快得多。它找出来的问题里，有一部分是真问题，也有一些是它自己纠结出来的伪问题，但整体上帮我省掉了大量 review 工作量。

真正需要我动手写代码的场景出现在接口之间的数据联动上。比如计算风险分时，需要调用项目进度查询接口，再结合人力数据做加权。业务小众、AI 没有直接参考，生成出来的逻辑总差一点意思。我最后动手写了大概三十行代码，用最简单直接的方式实现规则计算。这部分我完全不指望 AI 能替我做，因为规则本身来自业务经验，AI 猜不准才是正常的。

3.2 前端页面：AI 生成 UI，我负责接入

前端部分我用的策略更省力：分模块生成，先出页面骨架，再让 AI 按统一的风格补齐。核心页面就四个：登录页、周报提交表单、周报汇总查看页、风险看板。

我最开始的提示词比较简陋，只说“帮我做一个风险看板页面”，结果 AI 生成得五花八门，风格混乱。后来我改成先定设计规范，再生成页面。设计规范其实就是一句话：左侧固定导航栏、顶部栏显示当前用户、主内容区域使用卡片布局、主色使用深蓝色、表格统一带筛选和导出。AI 一旦有了风格约束，后面所有页面的观感就统一了，瞬间摆脱了“拼凑感”。

前端实现里出现的比较典型的坑是：AI 喜欢把所有交互都塞在一个文件里，页面一长代码就开始臃肿。我的处理方法是，在提示词里强制它遵守组件拆分规则，例如表单组件、表格组件、布局组件单独成文件。这样后期调试时，我不需要在一坨几百行的代码里大海捞针。

我自己的工作量集中在页面跳转逻辑和接口联调。AI 生成的表单组件本身很好用，但提交后跳转哪些页面、权限按钮怎么显示、接口报错时怎么提示，这些业务相关的逻辑需要人来定。我会把它写成伪代码注释，让 AI 按注释补齐细节，而不是自己重写前端。

3.3 胶水代码：唯一要我动手的部分

我不止一次说过，真正让我手写代码的部分就两类：一类是冷门业务规则，一类是胶水代码。胶水代码指的是把 AI 生成的各个独立模块连接起来的部分。

最典型的一段出现在初始化流程里：系统启动时要读取配置文件、初始化数据库连接、检查数据表是否存在、然后把初始管理员账号写进去。这些逻辑单个拎出来 AI 都会写，但把它们串在一个符合这个项目目录结构的启动文件里，AI 生成出来的总会有偏差，比如引错模块路径、漏掉配置项、或者初始化顺序不对。我干脆自己写了这个文件，总共二十多行。

还有一段是定时任务入口。系统需要一个定时器，每周五下午五点扫描所有未提交周报的项目并发送提醒。AI 生成的定时任务逻辑本身能用，但触发时间表达式是用死配置写死的。我手动把时间参数改成了从环境变量读取，这样后续调整不需要改代码。这里并不算复杂，但说明一个事实：AI 端到端交付，不代表交付物可以直接脱离人的判断，边界和配置口子依然需要人来决定。

4. 测试、部署与文档：AI 也包了？

4.1 自动化测试与边界用例

很多人在 AI 生成完功能代码之后就直接收工，这在我看来风险极高。代码可以生成得很快，但能不能在真实场景里跑通完全是另一回事。这次项目我花了不少时间在测试上，而且测试用例本身也是用 AI 生成的。

我采用的方式是让 AI 针对每个接口生成边界测试用例。例如提交周报接口，我要求的用例包括：正常提交、缺少必填字段、提交重复周数据、提交非本周数据、无权限用户提交、超长文本提交。AI 生成的测试用例覆盖非常全面，还会主动提醒我哪些字段需要数据库层面的唯一约束。

执行测试时，我发现了一个只有真实数据才会踩到的问题：某个项目组提交了包含特殊字符的内容，接口直接返回 500。AI 最初生成的代码里没有对特殊字符做处理，我让 AI 在所有输入字段上统一加过滤函数，并补了对应的测试。这看起来是小事，但在内部工具里特别容易发生，因为用户根本不会按规范输入数据。

这里有一个经验：不要相信 AI 生成的测试用例覆盖度，但可以让 AI 帮你提升覆盖度。最有效的方法是把项目里所有接口的边界场景列成一张表，然后逐条让 AI 确认“这个场景你们测了没有”。AI 在“审查自己”的模式下，会比直接生成时严谨不少。

4.2 部署脚本与运维文档

部署环节我同样没有手写脚本，而是让 AI 基于目标服务器环境生成部署方案。由于系统是轻量架构，部署过程只需要三步：安装运行时、还原数据库、启动服务。我把服务器环境告诉 AI，让它生成一键部署脚本和配置说明。

部署脚本要注意的最关键问题是幂等性。重复执行脚本不应导致服务挂掉或数据被清空。我在提示词里特别加了说明：“这个脚本可能会被重复执行，请确保重复执行是安全的”。AI 给出的脚本里包含了目录检查、进程检查、备份逻辑，这个质量在我预期之上。

运维文档方面，我让 AI 直接生成了三份内容：部署手册、环境变量说明、常见故障排查手册。其中故障排查手册我用得最多。手册里列出了一些典型问题，比如端口被占用、数据库连不上、定时任务不触发、邮件发送失败。后来实际操作中，定时任务不触发的问题就真的被我遇到了，手册直接告诉我先去查服务器时区和 cron 日志，省了我不少排查时间。

4.3 项目文档：AI 续写和整理

这个环节看起来不起眼，但让我很惊喜。项目验收的时候，管理部门要求提供一份简要的说明文档，包括系统架构、使用流程、权限说明、后续扩展点。我本来以为要自己花一晚上整理，结果我把功能清单、代码目录结构、数据库表清单丢给 AI，让它直接生成项目说明文档的第一版。

AI 生成的文档结构清晰，语言也比较干练，没有太多废话。不过文档里有几处描述和实际实现不一致，比如权限配置部分写成了“管理员可修改所有项目”，实际实现是“管理员只能修改分管项目”。这种细节问题需要人来核对，不能直接交付。

我的方法是不把文档当一次性产物，而是建立了一个“代码变更记录”，每改一次功能，就把变更点、影响范围、修改后的行为粘贴给 AI，让它同步更新文档。这样项目收尾时文档已经非常接近真实状态，几乎不需要额外整理。

5. 最坑的问题与排查技巧实录

5.1 典型问题速查表

AI 交付不是一路顺风，这次项目里我也踩了不少坑。有些坑是 AI 生成代码的通病，我整理成了一张速查表，方便以后直接对照：

这张表里的问题有一个共同特征：都不是复杂技术难题，而是细节校验和边界设置的问题。AI 生成代码时，一般不会主动去处理这种“不发生就不发生、一旦发生就特别烦”的细节。这就需要交付过程中有人做系统性检查。

排查技巧上我只有一个套路：遇到问题先截日志、把日志贴回给 AI、让它对比代码逻辑推断根因。通常 AI 能在一两轮内给出正确答案。我最怕的是自己不看日志直接让 AI 猜，这样它也只能瞎猜，来回拉扯浪费时间。

5.2 提示词微调实战

这次项目中，我调整最频繁的其实是提示词。同一个功能，第一版生成的效果和第二版可能天差地别，关键差异往往就在提示词里的两个词。

我举一个真实例子。生成风险看板时，我最初写的是“做一个项目风险看板，列出各项目的风险”，AI 生成的表格信息很全，但没有任何视觉层次，重要风险项目被淹没在表格里。我修改后的提示词是：

请生成风险看板。要求：高风险项目用红色卡片置顶，中风险用黄色卡片按分数排序，低风险用绿色卡片折叠展示。卡片必须展示项目名、负责人、延期天数、风险分数、最近更新时间。点开卡片后显示风险详情和关联周报。

加上了颜色、层级和交互细节之后，AI 输出的页面基本可以直接用。这说明一个道理：AI 可以把一个模糊想法实现出来，但“这个想法在真实场景里该怎么表现”，依然需要人来注入具体业务视角。提示词越接近“你和同事交代需求”的细节程度，生成结果越接近你的预期。

另一个技巧是让 AI 生成多套方案再选。比如表单布局我让它一次给三套不同密集度的样式，再由我选择一套。这个过程不费太多时间，但能明显提升最终效果。毕竟 AI 第一次出的方案，往往只是“正确”，不一定“合适”。

6. “全程没写几行代码”的真相与适用边界

6.1 我的代码量统计

看到这里你应该已经意识到，“没写几行代码”这个说法需要拆开看。我自己敲进编辑器的字符确实只有不到 50 行，包括启动文件、环境变量读取、冷门规则计算。但我阅读 AI 生成的代码、修改配置参数、调整提示词、核对日志的时间，加起来至少是正常开发工作量的八成。

换句话说，AI 帮我省掉的主要是“把想法翻译成代码”的时间，但它完全没有省掉“理解业务、定义规则、检查质量”的时间。在一次干净的 AI 端到端交付里，人的精力分布会从“写代码”转移到“下指令、做判断、盯质量”。如果一个人没有能力判断 AI 输出对不对，那他即便全程不写代码，项目也照样做不成。

这里也给想复制这个流程的人一个参考：代码量不是衡量交付模式的唯一指标。更真实的指标是“我自己写的逻辑占比”和“我处理异常的次数”。这次项目里，凡是常见逻辑，AI 完成度都在 90% 以上；凡是需要结合业务经验的特殊逻辑，AI 完成度可能连 60% 都不到。把有限的手写精力集中在后者，才是这个模式最大的价值。

6.2 AI 交付模式的边界

这次项目能成，很大程度是因为我严格守住了 AI 交付的边界。反过来，如果我把它用在不合适的项目上，大概率会翻车。

我总结出三类 AI 不擅长的项目：第一类是强业务约束型，比如财务审批流程必须匹配公司审计规范、资金台账必须满足对账标准；第二类是强交互体验型，比如面向客户的复杂后台系统，需要反复的人性化微调；第三类是强遗留系统集成型，比如对接几十个低代码平台和内部系统的老接口，每个接口都有历史包袱。这三类项目，AI 可以作为辅助工具，但不适合端到端交付。

即便在适合 AI 的内部工具里，代码审查也不能省。我在很多关键环节都要求 AI 做“二次评审”或“逻辑推演”，实际上就是把审查工作重心从人肉 review 变成了“人审 AI 审”。这种方式更适合大规模生成代码的场景，但审查的深度和严格程度不能因为代码是 AI 写的而降级。

6.3 给还在观望的人的建议

如果你也想尝试 AI 端到端交付一个项目，我的建议是先从小工具开始，千万不要拿核心生产系统练手。可以先选一个模型清晰、数据量小、失败代价低的内部需求，完整跑一遍这个流程，体验一下 AI 在哪个环节体验最好、哪个环节最让你头大。

另一个建议是从一开始就建立“交付清单”。我这次用的清单包含：需求确认、技术方案、接口契约、表结构、功能实现、测试报告、部署记录、文档归档。每完成一项，就把结果丢给 AI 做一次同步更新。这样做的好处是，AI 始终在一个明确的轨道里推进，不会越做越偏。

最后，别把全程不写代码当成目标。AI 端到端交付的本质是让你把时间花在更重要的判断和决策上，而不是让你彻底告别编辑器。该动手的时候果断动手，该让 AI 干的时候放权让 AI 干，这种“人机分工”的节奏感，才是真正值钱的经验。

我在这次项目里最深的体会是：AI 不是一个偷懒工具，而是一个放大工具。它放大了你的需求分析能力、逻辑判断能力和工程习惯；如果你本身没有这些东西，它只会放大混乱。

最后再分享一个小技巧：不管 AI 生成的代码看起来多完整，正式上线之前，一定让它从头到尾给自己写一份“这次交付中最可能出问题的三个地方”的复盘报告。这个操作我每次都做，而且命中率非常高。它会逼着 AI 跳出生成模式做一次理性回顾，也会逼着你认真看一遍自己到底交付了什么。