AI × Web · 10 MIN
建议 0:30

让 AI 做网页，
先会拆需求，再谈写代码

用 10 分钟建立一个“网页最小知识框架”：知道该做哪种网页、如何让 AI 生成、怎样修改，以及如何发给别人访问。

不讲 深奥原理 只讲 工作中马上能用 最终目标 一次生成，快速迭代
01选类型
02让 AI 生成
03修改与检查
04发布分享

大家好，今天不教大家成为前端工程师，只帮助大家建立一个最小但够用的网页知识框架。

听完以后，你至少能判断：应该让 AI 做一个简单静态网页，还是需要完整系统；也能知道怎样改、怎样发布，而不是拿到代码后无从下手。

01 · 先选对类型
建议 1:20

先做一个判断：静态网页，还是动态系统？

静态网页

像一张排版精美、可以点击的电子海报

所有人看到的核心内容基本相同
无需登录、无需写入数据库
适合知识分享、成果展示、说明页、个人主页
HTML + CSS + 少量 JavaScript 即可

动态网页 / Web 系统

像一个现场接单、处理数据、返回结果的服务窗口

不同用户可能看到不同内容
通常需要登录、权限、数据库或实时数据
适合业务系统、查询平台、评论区、数据看板
需要前端、后端、存储与部署环境配合
三个问题都回答“否”： 是否需要登录？是否需要保存用户提交的数据？是否需要把私密 API 密钥放在服务器？ 优先静态 HTML

网页最关键的第一步不是选颜色，而是先判断它是不是一个“系统”。

如果只是分享信息、展示成果，而且大家看到的内容一样，就不要上来就做数据库、账号和服务器。三个判断问题都是否定时，静态 HTML 通常已经足够。

02 · 看懂 AI 给你的文件
建议 1:00

对非前端同事，最优起点通常是：一个 HTML 文件

推荐：第一次交付 
我的分享页/
└── index.html
    ├── 页面内容（HTML）
    ├── 页面样式（CSS）
    └── 页面动作（JavaScript）

优点：双击就能打开；方便发送；
不丢文件；最适合 AI 一次性生成。
内容、样式、交互各管什么 
<h1>项目成果展示</h1>
↑ HTML：页面上“有什么”

<style>
  h1 { color: #55d6be; }
</style>
↑ CSS：页面“长什么样”

<script>
  button.onclick = showNext;
</script>
↑ JavaScript：点击后“发生什么”
内容找 HTML标题、段落、表格、图片、按钮文字
样式找 CSS颜色、字体、字号、间距、布局、阴影
交互找 JavaScript翻页、筛选、弹窗、复制、图表更新

当网页长期维护或多人协作时，再拆成 index.html + style.css + script.js；第一次分享不必先增加复杂度。

很多人拿到 AI 生成的网页，会被文件结构吓到。其实只要记住一句话：内容找 HTML，样式找 CSS，交互找 JavaScript。

为了减少丢文件和路径错误，第一次可以明确要求 AI 交付一个单文件 HTML。等网页需要长期维护，再拆成三个文件。

03 · 让 AI 一次做对
建议 1:30

不要只说“做得好看一点”，要给 AI 一份可执行的设计任务书

目的+ 受众与场景+ 内容结构+ 视觉约束+ 交互要求+ 交付格式
✕ 模糊指令

帮我做一个介绍项目的网页，要高级、科技、好看。

✓ 可执行指令

请生成一个适合会议投屏的单文件 HTML，用于 10 分钟介绍“XX 项目”。受众是非技术同事。共 8 页，每页只表达一个观点；深色简洁科技风，中文系统字体，不使用外部图片或第三方库；支持左右键翻页、全屏和打印。请直接交付可运行的完整 HTML，不要只给代码片段。

修改时也遵循同一原则： 指出“哪一页、哪个元素、改成什么、哪些内容保持不变”，比“整体优化一下”稳定得多。 具体 > 抽象

AI 做网页的质量，很大程度上取决于我们能不能把模糊偏好变成约束。

一份好指令至少包含六项：做什么、给谁看、有哪些内容、想要什么风格、需要哪些交互、最终交付什么文件。尤其要明确“给我完整可运行文件”，避免只拿到零散代码。

04 · 修改网页
建议 1:40

三条修改路线：从零门槛到可控预览

A

继续让 AI 改

默认首选。适合结构调整、整体排版、批量修改。

  • 上传当前完整文件
  • 指出页码与目标元素
  • 说明“其他内容不变”
  • 要求返回完整新文件
B

用 VS Code 改文字

适合改标题、段落、颜色、字号和图片路径。

  • 改文字：直接搜索原句
  • 改颜色：搜索 color / background
  • 改字号：搜索 font-size
  • 换图片：搜索 <img 和 src
C

浏览器 F12 试效果

像“试衣间”：先看效果，再决定怎么改源文件。

  • 右键目标元素 → 检查
  • 临时改文字、颜色、间距
  • 记录满意的数值
  • 刷新页面后修改会消失
F12 定位 → 现场试值 → 给 AI 精确要求 → 替换完整文件

修改网页最稳妥的方式不是直接在大段代码里乱找，而是分三条路线。

结构性修改交给 AI；简单文字可以在 VS Code 搜原句；不确定颜色和间距时先用 F12 试。F12 只是临时预览，刷新后会消失，所以最终仍要修改本地源文件。

05 · 发布分享
建议 1:10

从电脑上的文件，到同事能打开的网址，只需要四步

STEP 01

整理文件

确保入口文件名为 index.html；图片和附件放在同一项目文件夹内。

STEP 02

本地检查

双击打开，检查文字、链接、图片、翻页；再用手机尺寸测试一次。

STEP 03

上传托管

选择静态托管平台，上传文件夹或连接 Git 仓库。

STEP 04

发送链接

在无痕窗口再打开一次，确认别人不登录也能访问。

常见静态托管选择

GitHub Pages适合代码版本管理与长期维护
Netlify适合快速部署简单静态页面
Vercel适合前端项目与持续部署
Cloudflare Pages适合静态站点与全球分发
图片使用相对路径，例如 images/photo.jpg
不要引用 C:\ 或 /Users/... 这类本机路径
正式发布前，用手机和无痕窗口各检查一次

静态网页不一定需要购买服务器。只要把文件交给静态托管平台，就能获得一个网址。

最容易出错的是图片路径：网页在自己电脑上能看，不代表上传后还能看。要使用相对路径，而且发布后要用无痕窗口和手机再检查一次。

06 · 什么时候升级为系统
建议 1:20

出现这些需求，才需要后端、数据库和服务器

🔐用户登录
与权限控制
🗄保存、修改
业务数据
🔑保护 API 密钥
与敏感逻辑
⏱定时任务
或后台计算
🏢内网、审计
与合规要求
用户浏览器 看到界面、点击按钮、展示结果
云服务器 / 公司服务器
Caddy 接收请求、配置 HTTPS、把请求分发到正确服务
React 前端 负责页面体验、状态与图表，在浏览器中运行
FastAPI 后端 负责权限、规则、数据处理和 API 返回
数据库 / 文件 负责持久保存账号、业务数据、Excel 与附件
第一性原理： 只有当“浏览器本地无法安全完成”时，才把能力放到服务器。前端负责体验，后端负责规则、数据与安全。 按需升级

什么时候必须上服务器？不是页面看起来复杂，而是浏览器无法安全完成任务的时候。

例如登录、保存数据、保护密钥、执行后台任务或满足内网合规。这时前端负责用户体验，后端负责规则、数据与安全，服务器为它们提供运行环境。

07 · 前后端如何配合
建议 1:00

用户点击一次“查询”，背后发生了什么？

用户点击“查询近一年数据”
前端收集筛选条件
React
浏览器发送请求
例如 GET /api/data?range=1y
HTTP
入口服务判断请求去哪里
/api/ 转给后端，其余页面交给前端
Caddy
后端检查权限并执行规则
验证登录、参数与数据范围
FastAPI
读取数据并返回 JSON
查询数据库、Excel 或文件
Storage
前端把结果渲染成图表
用户最终看到可交互结果
React
一句话理解

前端负责“让人用”，后端负责“把事办对”。

数据库密码、模型密钥、权限规则等不能写进公开网页；它们必须留在服务器端。

用一个具体例子就能理解前后端。用户点击查询，前端负责发请求；Caddy 负责分流；FastAPI 验证权限并处理数据；数据库返回结果；最后前端再把 JSON 变成图表。

所以前端不是数据库，后端也不是界面。两者分工的核心是体验、规则、数据和安全。

08 · 三句话带走
建议 0:30

把简单的事做简单，再按真实需求升级

01
做知识分享与成果展示：先要一个单文件静态 HTML

不用账号、数据库和服务器，也能做出完整、可交互、可发布的页面。

02
修改网页：F12 试效果，AI 改源码，本地再验证

需求越具体，修改越稳定；正式发布前检查图片路径、手机显示和公开访问。

03
只有登录、数据写入、私密密钥等需求，才升级前后端

遵循“满足需求的最小架构”，不要为了显得专业而增加不必要的复杂度。

下一次，让 AI 先交付一个能打开的版本。
再通过明确反馈，把它迭代成真正适合工作的网页。

最后只记住三件事：分享页优先静态 HTML；修改用 F12、AI 和本地验证组合；只有真正涉及账号、数据和安全时，才升级为前后端系统。

我们的目标不是堆技术，而是用满足需求的最小架构，尽快做出能工作的版本。谢谢大家。

01 / 09