企业官网建设流程全解析

1. 为什么“把需求发给AI”这条路经常走不通：提示词不是聊天

我见过太多人兴冲冲地打开ChatGPT或者Claude，敲下一句“帮我写一个Web应用”，然后等来的是一大段看起来像模像样的代码，复制到本地一运行——报错，缺依赖，版本对不上，甚至直接把“示例代码”里的占位符也当成真东西。多数人到这里就放弃了，觉得“AI编程不靠谱”。

先别怪AI，问题往往出在提示词本身。

你回想一下，平时和同事交代工作的时候，如果说一句“把这个页面做一下”，对方大概率会追问：用什么技术栈、页面长什么样、要不要调接口、数据放哪、什么时候要。但换成和AI对话，我们却默认它应该全知道。大模型本质是个“续写机器”，你给它的上下文越模糊，它越会基于训练数据里的“平均情况”来续写——而“平均情况”恰恰是什么都不适配的最常见方案。

我试过几次之后逐渐摸到一个规律：让AI生成可运行Web应用这件事，真正的难点不在代码，而在提示词的结构。只要把提示词拆成几个固定模块，把约束说清楚，AI写出来的东西从“理论可用”变成“真能跑”，成功率能翻好几倍。

这个方法我叫它“提示词五模块法”。核心思路很简单：把一次模糊的“帮我做个应用”大请求，拆成五个有明确分工的小模块，每个模块解决一类确定性问题，然后再组合成一个完整的提示词。这样AI既不会跑偏，也不会在某个细节上自作主张。

2. 提示词五模块法的完整拆解：生成可运行Web应用的必备骨架

2.1 第一模块：角色与目标设定

第一模块要解决“AI以什么身份、做什么事”的问题。这看起来简单，但很多人会忽略。

我常做的写法是：

你是一名全栈Web开发工程师，精通HTML、CSS、JavaScript以及现代前端框架。请为我开发一个××应用，它的核心目标是××。

这个模块的价值在于给AI一个“行为锚点”。如果你告诉它“你是一名资深全栈工程师”，它在写代码时会默认加入工程化思维；如果你不设定角色，它可能会用一种极其基础、学院派的方式写代码，虽然逻辑正确但完全不具备实际运行条件。

目标设定也要具体。不要只说“开发一个待办事项应用”，要说“开发一个支持增删改查、状态标记、本地数据持久化的待办事项应用”。目标写得越具体，AI后续的取舍就越准确。

2.2 第二模块：约束条件与技术栈锁定

第二个模块是用来“圈地”的。Web应用的实现方式太多了，纯HTML页面能跑、Vue项目能跑、React项目也能跑，但它们的运行条件天差地别。你不锁技术栈，AI就会按它自己舒服的方式来，等你拿到手才发现本地环境根本不匹配。

以我常用的一个写法为例：

技术栈要求：纯前端实现，使用HTML + CSS + 原生JavaScript，不依赖任何框架和外部库，所有代码在一个单独的HTML文件中完成。不使用Node.js，不需要构建步骤，只需要浏览器打开即可运行。

这段提示词至少解决了三个问题：免去安装依赖的麻烦、避免版本冲突、傻瓜式运行。对于原型验证和内部工具来说，这比追求技术先进性重要得多。

同理，如果你确实需要Vue/React项目，那就要把脚手架版本、Node版本、包管理器都交代清楚。比如：

使用Vue 3 + Vite 构建，使用npm作为包管理器，Node版本需要18以上。组件库使用Element Plus，其余工具库尽量少用。

版本这种东西你不说，AI默认会用训练数据里出现频率最高的那个版本。而训练数据是有滞后性的，这往往就是报错的根源。

2.3 第三模块：功能清单与优先级

第三个模块是给AI列“需求清单”。最好用列表形式逐条列清楚：

• 用户可以输入新待办事项，按回车或点击按钮添加
• 每个事项前有复选框，勾选后标记为完成，显示删除线
• 支持删除单条事项
• 支持编辑已有事项的文字内容
• 数据保存在localStorage中，刷新页面后不丢失
• 支持筛选全部/未完成/已完成

功能清单要按优先级排序。把P0（必须有，没有就不能用）放在最前面，把P1（最好有，影响体验）放在中间，把P2（锦上添花，暂时没有也行）放到最后。

为什么要排序？因为大模型生成代码时有“注意力衰减”问题——它生成完前面的功能之后，到后面会产生遗漏或者简化。核心功能放前面，AI会更卖力地实现它们。这招我试过非常多次，效果实打实。

2.4 第四模块：数据模型与页面结构

这是五个模块里最容易被忽略、但最重要的一个。

很多人的提示词只写了“有什么功能”，没有交代“数据长什么样”“页面分几块”。结果AI生成出来的代码，数据库结构和页面布局全是自己瞎猜的，看起来功能齐全，实际组合在一起别扭得很。

写数据模型不需要你懂数据库设计，只需要说清楚业务上有哪些“实体”和“属性”。比如待办应用：

每条待办事项包含：id（唯一标识）、title（事项内容）、completed（是否完成，true/false）、createdAt（创建时间）、updatedAt（更新时间）。

就这么一句，AI写代码就有据可依了，localStorage存数组的时候字段也不会乱。

页面结构也要说明。用极简的话描述就行：

页面顶部为标题栏，中部为待办事项输入区域，下方为列表区域，列表底部为筛选工具栏（全部/未完成/已完成），并显示当前未完成数量。

你把页面布局用几句话描述清楚，AI生成出来的CSS样式和DOM结构会合理十倍，因为它在“搭建已知蓝图”，而不是“凭空想象”。

2.5 第五模块：输出格式与交付标准

最后一个模块，用来约定AI输出的呈现方式。这个模块最实用，但也最常被忽略。

你需要明确告诉AI：输出的代码应该是完整可运行的、是否需要分文件、每个文件的路径是什么、有没有额外说明。

我常写的交付标准是：

请输出完整可运行的HTML文件代码。所有CSS和JavaScript都写在HTML文件内部的style和script标签中。代码需要使用中文注释，关键逻辑处必须解释清楚。输出格式为：先给出整体实现思路说明，再输出完整HTML代码，最后列出本地运行步骤。

要求“先给思路再给代码”是个很妙的技巧。它强迫AI在生成代码之前先“理清思路”，相当于让大模型在输出代码之前先自己演算一遍。实测下来，加了这个要求之后代码逻辑错误的概率会下降不少。

3. 实战演示：用五模块法让AI生成一个可运行的待办清单应用

3.1 一份可直接复制使用的完整提示词

前面拆解了原理，这里上真东西。下面这份提示词是我在多个模型上都验证过的——ChatGPT、Claude、文心一言、Kimi都跑通过，第一次生成的可运行率大概在七成左右，稍作纠错就能到九成以上。

你是一名资深全栈开发工程师，精通HTML、CSS、JavaScript。

请为我开发一个“待办事项管理”Web应用。核心目标是：用户可以在浏览器中管理自己的日常待办事项，所有数据保存在本地浏览器中，不需要服务器。

技术栈要求：

• 纯前端实现，使用HTML + CSS + 原生JavaScript
• 不依赖任何框架、外部库或CDN资源
• 所有代码位于一个index.html文件中
• 不使用构建工具，浏览器直接打开即可运行

功能需求（按优先级排列）： 1.（P0）用户可以输入待办事项内容，按回车键或点击“添加”按钮添加 2.（P0）每条待办事项前方有复选框，勾选后该事项显示为已完成状态（文字加删除线、颜色变灰） 3.（P0）支持删除单条待办事项 4.（P0）待办事项数据保存到localStorage，页面刷新后数据不丢失 5.（P1）支持编辑已有待办事项的文字内容 6.（P1）底部提供筛选栏：全部/未完成/已完成，点击后列表只显示对应状态的事项 7.（P2）底部显示当前未完成事项的数量 8.（P2）提供“清除已完成”按钮，一键删除所有已完成事项

数据模型： 每条待办事项包含：id（唯一标识）、title（事项内容）、completed（是否完成）、createdAt（创建时间）。 数据以数组形式存储在localStorage中。

页面结构：

• 页面顶部为标题栏
• 中间为输入区域，包括输入框和“添加”按钮
• 下方为待办事项列表区域
• 最底部为筛选工具栏和状态统计
• 页面整体宽度控制在600px以内，居中显示

输出要求： 请先简要说明你的实现思路，再输出完整的、直接可运行的HTML文件代码，所有CSS和JavaScript写在HTML内部的style和script标签中，使用中文注释。最后说明在本地打开运行的方式。

你把这整段复制进任何一个主流大模型，得到的代码基本都能直接双击运行。里面每一个字段都是“五模块法”的具象化：角色目标、技术约束、功能优先级、数据结构、页面布局、交付形式，一个都没少。

3.2 为什么这份提示词能一次跑通

我第一次用这份提示词的时候，生成的代码是一次跑通的，当时自己都有点意外。后来复盘了一下，能跑通的原因其实很清晰。

技术栈锁定做到了极致。“纯HTML + CSS + 原生JS”“不需要构建工具”这两条直接消灭了95%的报错可能——不用管Node版本、不用管包依赖、不用管模块路径。这是初学者最容易翻车的地方，却在这份提示词里被前置规避了。

数据模型和页面结构明确了，AI不用猜。README风格的分段描述，让大模型在每一步都知道自己要生成什么：“现在我该写列表渲染的循环了”“该写筛选逻辑了”。它的输出会更有条理。

“先给思路再给代码”让AI在动笔之前先规划。大模型的推理能力其实比很多人想象的要强，只是默认情况下它“懒得推理”，直接开写。你逼它先写思路，等于是强行开启了它的“思维链”，错误率自然下降。

4. 从单次生成到持续迭代：五模块法在项目开发中的完整用法

4.1 把大需求拆成多个小回合

很多人用AI写应用，指望一次会话把所有功能都做完。这在简单原型场景下可行，但一旦应用稍微复杂，比如要十个页面、要接后端接口、要多种角色登录，单次生成就不够用了。

我的做法是拆成多个回合。第一个回合让AI生成整个应用的框架，包括数据模型和所有可点击页面的静态版本。第二个回合开始逐页交互，先做列表页，再做详情页，再做表单提交页。第三个回合再做联调和优化。

每个回合开始时，把上一回合的代码贴回去，然后加上新的需求指令。这相当于你既是产品的需求方，又是把它一步步落地的开发者。五模块法在每个回合里都可以灵活复用：新一回合里，角色目标可能不变，技术栈锁死，功能清单换成新需求，数据模型在原有的基础上追加字段。

4.2 上下文窗口快用完时的续接策略

还有一个挺实际的问题：对话长了，上下文窗口总有满的时候。特别是用五模块法持续迭代时，代码占用的token量很大，聊到后面经常会出现“忘记”前面约定内容的情况。

我一般会在每个回合结束前，让AI写一个“项目状态说明”。类似这样：

请用50字以内的篇幅总结这个项目的当前状态：已完成哪些功能、使用了什么技术栈、数据模型有哪些字段、下一步准备做什么。在下一轮对话开始时，我将让你根据这个总结继续开发。

等上下文真的被截断之后，新开一个会话，把上一轮的“项目状态说明”粘贴进去，再加上一句“基于以上状态继续开发”，AI基本能无缝接上。

4.3 拿到AI代码后的三个必查项

即便提示词写得再完备，我也建议养成检查代码的习惯。不是说你得一行行读，而是重点检查三个地方：

第一，检查是否存在外部CDN引用。有些AI模型会把“使用外部库”当成默认行为，尽管你说了不要，它还是可能偷偷给你引用一个jQuery的CDN链接。没有网的时候应用会直接瘫掉，这个要第一时间删掉。

第二，检查事件绑定是否有误。AI生成的代码里，最常见的bug就是按钮点击事件的绑定方式错误，或者绑定了但没有阻止表单默认提交行为。你把页面打开点两下按钮，如果控制台报错，九成是这类问题。

第三，检查数据读写键名是否一致。AI有时候保存数据用的键叫“todos”，读取时却写的“todoList”，这种低级错误其实不少见。打开开发者工具里的Application面板，看一眼localStorage里存的什么，再对比代码里的读取逻辑，就能快速定位。

5. 三个实战场景：五模块法的不同用法

5.1 快速原型验证：给需求方看效果

有次产品经理跟我说，想做一个“团队周报汇总工具”，但需求文档写得模模糊糊。我懒得先写一版原型再等他确认反馈，直接用五模块法写了一个提示词，两分钟生成了一个可交互的单页应用——录入功能、汇总视图、导出文本功能全都有。

那次最大的感受是：AI生成的原型不是为了给你“凑合看”，而是为了让需求方“亲手玩”。人只有在交互中才能发现自己真正想要什么。与其花一整天做高保真原型，不如花十分钟做一个真实可点的Web应用，后者对需求的验证效率高得多。

5.2 内部工具：数据库查询后台

另一类非常适合五模块法的场景是“内部一次性工具”。比如我经常要查测试环境的数据，但公司内部的数据库管理工具权限卡得严，我就让AI写了一个简单的查询页面：输入SQL语句，点击执行，把返回值渲染成表格。

这个应用的提示词里，技术栈约束是“纯前端 + 只负责把接口返回值渲染为表格”，数据模型就一行——“返回结果是一个JSON数组，每个元素代表一行”。两句说明，一个能用的内部工具就出来了。

5.3 基于Cursor/Copilot做增量开发

如果你用的是Cursor这类AI编程工具，五模块法同样适用，只是用法稍有不同。不需要一次性生成整个应用，而是把五模块里的内容嵌到对话里，让它分步实现。

比如先让它创建项目文件结构，再让它用“数据模型”作为输入，生成对应的数据层代码，之后单独生成页面组件。配合Cursor对项目上下文的感知能力，每一轮生成的代码都会自动关联到已有的项目结构里。这种情况下，数据模型模块的价值体现得最明显：你只要把数据结构定义清楚，AI生成的各个组件之间自然能对齐字段。

6. 生成失败的高频原因与排查链路：提示词没问题，应用还是跑不起来

6.1 技术栈不一致：提示词里写了，AI还是给别的

有一回我明确写了“使用Vue 3 + Vite”，生成结果是Vue 2语法。排查之后发现，根源在模型的训练数据里Vue 2样本占了绝对多数，AI默认往高概率方向“续写”。解决办法很粗暴：在提示词里加一句“特别注意：不使用Vue 2语法，生命周期钩子必须使用Vue 3的Composition API写法”。加一个“特别注意”前缀，模型的注意力会明显聚焦。

6.2 生成了代码但无法运行：锚定“最小可运行单元”

还有一回，AI生成的一个React项目报错，报错信息指向一个第三方库版本不兼容。我看了一下，其实那个库本身可有可无。根治的办法是在提示词的约束条件里加“使用最少的外部依赖，能不用就不用”，并且要求“代码中不要出现未安装的npm包引用”。

这个“最小依赖”原则，目前帮我把AI项目的一次运行成功率提高到了八成以上。很多人以为依赖越多功能越强，实际在AI生成代码的场景里，依赖越多报错点越多，AI对每个依赖版本的“记忆”还不一定完全准确。

6.3 功能做出来了但交互很别扭

这类问题不报错，但体验拉胯。比如列表没有空状态提示，数据加载中一片空白，点击编辑之后不知道如何保存。这类问题靠提示词本身优化空间不大，更好的办法是加一个交互要求模块：

所有操作必须有即时视觉反馈：添加后输入框自动清空；删除后列表平滑刷新；筛选状态变化时按钮高亮；空列表时显示提示文案。

一段简单的话，能让AI生成的代码瞬间从“能跑的demo”变成“像一个认真做过的应用”。

7. 五模块法的最终形态：把它变成你自己的可复用模板

写到这里，我想强调一件事：五模块法最大的价值不是给了我一份万能的提示词，而是让我养成了“结构化工单”的习惯。

现在不管是对着AI还是对着团队里的开发人员，我都会下意识地先把角色、约束、功能、数据、交付这五件事想清楚。当你对AI表达的时候，这五件事越清晰，结果越可控；当这五件事本身模糊的时候，AI再怎么厉害也救不了你。

我自己整理了一份提示词模板，存在笔记软件里常年置顶。每次要生成Web应用，先复制模板，然后只改动两个地方：功能清单和数据模型。其他部分基本不动。这个习惯帮我节省了大量重复描述的时间。

提示：建议你参照本文的待办事项案例，搭建自己的“五模块提示词库”。不用追求一次成型，每在实际项目里跑通一次，就把提醒词里有用的约束积累下来。用不了几次，你手里就会有一份针对你自己业务场景的、高命中率提示词包。

最后说一个我的观察：AI编程工具越来越强，但“会提需求”反而成了更稀缺的能力。那些能把需求拆清楚的人，用AI的时候效果就是比只会说“帮我做个网站”的人好上一个数量级。这不是技术差距，是思维习惯的差距。五模块法说穿了就是一种思维习惯的强制落地，习惯了之后，你会发现它不只是提示词技法，更是和AI协作的基本工作方法。