ai-website-building

零代码用 AI 做官网：完整方法

这是给完全不懂代码的人（市场、运营、产品）准备的方法。目标是用 AI 大幅提升出原型的效率，让一个人就能完成从设计到交付的大部分流程，把过去需要多人、多轮排期的工作压缩到几天内。

核心理念：人做决策，AI 做执行。 AI 负责生成代码、改样式、处理图片、记录版本；人负责审美判断、品牌把关、信息取舍、最终拍板。AI 没有真正的审美，容易过度设计，必须靠人来说「够了」。

最重要的前提：先知道自己要什么，再去下指令。 这比用哪个工具都关键。让 AI 凭空给方案，大多数时候是来回改都不满意；自己心里先有清晰的目标和参考，再让 AI 实现，效率会高很多。下面所有方法都建立在这个前提上。

一、这个东西在哪里运行

用户不懂代码，所以先说清楚「东西在哪、怎么看见」。用大白话解释，不要丢术语。

• •写代码的地方：就是和 AI 对话的窗口（这个对话本身）。AI 会把网页写成一个 index.html 文件。
• •网页文件长什么样：一个 .html 文件就是一个完整网页，双击就能用浏览器打开看效果。不需要安装任何东西。
• •怎么实时看效果：让 AI 生成文件后，下载到电脑双击打开；或者让 AI 部署到一个临时网址，改完刷新就能看。
• •技术选型（AI 默认这么做即可，用户无需理解）：用 Tailwind CSS（通过 CDN 引入）+ 原生 HTML，零构建工具，一个文件搞定。这样用户拿到的就是一个能直接打开、也能直接交给开发的文件。
• •这个 skill 用在哪：从「我想做个官网」这句话开始，一直到「把文件交给开发」结束，全程都用这套方法。

如果用户问「我要先装什么软件吗」，回答：不用，全程在对话里完成，最后拿到一个 html 文件即可。

适用边界（什么时候不该用这个方法）：本方法适合做展示型静态页面——官网首页、落地页、产品介绍页、活动页这类「给用户看」的内容。但涉及真实功能逻辑的页面做不了，需要真开发介入：比如表单提交并存储数据、用户登录注册、从数据库读取动态内容、支付、账户后台等。这类页面 AI 可以做出「长得像」的静态外壳，但背后的逻辑必须开发实现。一句话：能「看」的它能做，要「用」的（提交、登录、动态数据）得交给开发。

二、省 token 策略（重要，先说）

做官网是个长任务，会消耗大量 token。先用低成本模型趟路，再用高能力模型攻坚，能省很多钱。

具体策略：

1. 先用低成本模型做大概。让低成本/快速的模型先把整体框架、布局、文案搭出来，看看大方向对不对、prompt 说得清不清楚。
2. 借低成本模型调 prompt。如果低成本模型做出来的东西方向不对，先反思是不是自己的需求没说清楚——低成本模型对模糊指令更敏感，反而能帮你发现 prompt 的问题。把需求改清楚，省下来的是后面高能力模型的钱。
3. 低成本模型反复做不好就换高能力模型。当你发现「不管怎么说，低成本模型就是做不出这个效果」——通常是涉及精细的视觉判断、复杂布局、或需要理解上下文的改动——这时候切换到高能力模型（如 Claude）来攻坚。
4. 判断标准：低成本模型适合「明确、机械」的活（改文案、调间距、批量替换）；高能力模型适合「需要审美和理解」的活（整体设计、复杂模块、反复调不好的细节）。

一句话：低成本模型测方向和 prompt，高能力模型做最终效果。

工具不限：除了对话式的 AI，命令行类工具（如 Codex 等）做网页也可以，调整很灵敏。但无论用哪个工具，前提都一样——先知道自己要什么再下指令，否则换什么工具都是来回改、都不满意。

三、多 agent 协作与备份

长任务里 AI 实例（俗称"虾"）可能会崩、会卡、会丢上下文。最好同时准备两个 agent 接管同一个项目，一个出问题时，另一个能立刻接手救场。

实践要点：

1. 两个 agent 共享同一份正式文件。约定唯一的「正式文件」位置，两个 agent 都改那一份，不要各改各的副本（否则会互相覆盖，见避坑清单坑 2）。
2. 一个崩了，另一个接管。某个 agent 卡死或上下文乱了，切到另一个继续，项目不中断。
3. 接管前先对齐认知。让接管的 agent 先看一遍当前文件状态和最近的改动记录，再继续动手。
4. 配合勤存档。两个 agent 都遵守「每次改动前先存档」，接管时从最近的存档点继续，丢失最小。

四、实际协作流程（主线）

整个流程分两个大阶段：先定大方向，再逐块微调。 不要一上来就让 AI 做全站，那样改起来是灾难。

阶段一：调研，知道自己要什么

动手之前先想清楚要什么，否则 AI 给什么你都觉得「好像不太对」但说不出哪不对。调研要做得足够细：

1. 找大量参考，三类都要看：

- 国内外竞品：看同行怎么做。竞品要结合自己的品牌实际情况来挑，不要照搬，重点看它怎么表达卖点、怎么组织信息。 - 优秀 SaaS 官网实践：看成熟产品（如 Stripe、Notion、Linear 等）的官网，学它们的设计语言和信息结构。 - 现成模板：直接看模板能快速找到可参考、可抄的结构。推荐几个来源： - Cruip（cruip.com）、Tailwind Plus（tailwindcss.com/plus）— 偏开发向的 HTML/Tailwind 模板，和本方法的技术栈直接对得上，让 AI 照着抄最顺手 - Webflow Templates（webflow.com/templates）、Framer Marketplace（framer.com/marketplace/templates）— 视觉参考好，但代码导出一般，适合看效果找灵感 - Hugo Themes（gethugothemes.com）— 主题模板 - Dribbble 的 saas-template 标签（dribbble.com/tags/saas-template）— 纯视觉灵感，设计稿为主，不能直接用代码

1. 明确要做哪些模块。列出页面要有的每一个板块（比如首页：导航 → 主视觉 → 核心卖点 → 使用场景 → 功能 → 信任背书 → 常见问题 → 页脚）。
2. 每个模块想清楚大概效果。不只是「有这个模块」，而是「这个模块大概长什么样、要传达什么」。
3. 大改务必给图片或模板参考。如果某个模块要做得复杂或特别，不要只用文字描述，直接给 AI 一张参考图片或一个现成模板让它「照着抄」——给视觉参考比纯文字描述快得多、准得多。实践证明：给模板让 AI 抄、给目标效果图让 AI 学，比反复用文字解释高效很多。
4. 文案先搞个大概，后期让 AI 按 SEO 优化。前期不用纠结文案完美，先把意思写出来、占住位置；等结构定了，再让 AI 根据 SEO 原则统一优化标题、描述、关键词。注意：很多网站的 SEO 信息（标题/描述/关键词）是在后台 admin 配置的，前端页面里的只是占位、不实际生效。动手前先确认 SEO 在哪生效，否则可能白改前端。详见 references/seo.md。

关键：调研不是一次性的。 做不同的页面（首页、落地页、定价页、功能页等）都要针对那个页面重新调研，而不是只在最开始调研一次就套用到所有页面。每个页面的目标、受众、信息结构都不同，参考对象也不同。换页面 = 重新调研，再推进。

阶段二：生成大方向 + 逐块微调

1. 先出一版完整框架。让 AI 按信息架构把整个页面搭出来，先看整体，不纠结细节。
2. 分模块逐个精修。框架 OK 后，一个模块一个模块地调。一次只盯一个模块，调好了再下一个。
3. 每个模块的微调原则：

- 重大改动前先确认方向，让 AI 给你「A 方案还是 B 方案」的选择题，不要让它盲改。 - 一次最多对比 2 个方案，不要一次给 5 个。 - 大改时把参考图片一起给，让 AI 照着学。 - 确认方向后再让 AI 执行，避免来回推翻。

1. 小步快跑。每改一个点就刷新看效果，确认 OK 再改下一个。不要一次堆十个改动。
2. 同步检查移动端。每个模块在电脑上调好后，一定要再看一遍手机上的效果（让 AI 模拟窄屏，或在手机浏览器打开）。桌面端好看不代表手机端好看，布局、字号、间距在小屏上经常出问题。移动端适配要和桌面端同步推进，不要全做完才发现手机端乱了。

真实经验：曾经有单个模块反复改了 20 多轮，就是因为没有先确认方向、AI 自作主张过度设计。先问「你要 A 还是 B」、大改时直接给参考图，能省掉一大半返工。

详细的避坑清单见 references/pitfalls.md，设计规范见 references/design-spec.md，图片处理见 references/images.md，交付给开发见 references/handoff.md，沟通方法见 references/communication.md，SEO 优化见 references/seo.md。在开始任何修改前，先读避坑清单，里面是真金白银踩出来的红线。

五、给 AI 执行时的强制规则

无论用哪个模型，以下规则必须执行（这些是踩坑换来的）：

1. 每次改动前先存档。在改任何东西之前先保存当前版本（git commit 或备份文件）。曾经因为没存档，AI 一次编辑把文件改坏，丢了大量内容，花一小时才从日志里恢复。
2. 一个改动 = 一次存档，不要积攒十个改动再一起存。
3. 删除操作必须先问。任何删除、覆盖、重置操作，先告知后果，得到同意再执行。删了就回不来。
4. 改完必须验证，且要看移动端。每次改动后刷新页面确认效果，并同时检查手机端显示。浏览器有缓存，看不到新效果时要硬刷新（Ctrl+Shift+R / Cmd+Shift+R）。
5. 图片处理要小心。带透明背景的图片（PNG）不能随便压缩或转格式，会把透明区域变黑。处理图片前先确认格式和透明通道（详见图片处理文档）。
6. 不要过度设计。AI 倾向于加动效、加装饰、加渐变。功能性模块优先简洁，做完问自己「这个动效/装饰真的需要吗」，多半不需要。

六、AI 强在哪、人必须管哪

帮用户建立正确预期，避免「全都交给 AI」的幻觉。

AI 很强的地方：速度快（一个模块 10-30 分钟）、改样式几乎零成本（改个间距 30 秒）、能同时搞定布局+代码+版本管理、能快速研究竞品提取规律、能建立并执行统一的设计规范、能按 SEO 原则批量优化文案。

AI 做不好的地方：

• •生成不了好看的图片。AI 直接生成的配图/产品图往往质量不行。解决办法：优先找现成的真实图片（产品截图、官方素材、图库），或者用专门的图像生成工具（如 GPT 的画图能力）单独做图，再放进页面。不要指望做网页的 AI 顺手生成可用的配图。
• •没有真正的审美：容易过度设计，需要人喊停。

必须靠人判断的地方：审美决策、品牌调性（什么「像我们」只有人知道）、信息取舍（放什么不放什么是战略）、最终验收（每个改动都要人刷新确认，含移动端）。

七、参考文件

需要时按下面指引读取：

• •references/pitfalls.md — 真实踩过的坑和对应红线规则。开始改动前必读。
• •references/design-spec.md — 间距、字号、颜色、圆角的具体标准，让 AI 输出有体系感。做整体设计或统一规范时读。
• •references/images.md — 配图从哪来、怎么处理、透明背景注意事项。涉及图片时读。
• •references/seo.md — 页面 SEO 优化清单：title、description、H 标签层级、图片 alt、语义化标签等。优化文案和元信息时读。
• •references/handoff.md — 交付物清单、需求文档模板、和开发沟通排期（含埋点）的要点。准备交付时读。
• •references/communication.md — 怎么和决策者对齐、怎么给选择题不给问答题。需要推进决策时读。