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

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

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

1. 先出一版完整框架。让 AI 按信息架构把整个页面搭出来，先看整体，不纠结细节。
2. 分模块逐个精修。框架 OK 后，一个模块一个模块地调。一次只盯一个模块，调好了再下一个。
3. 每个模块的微调原则：
   • 重大改动前先确认方向，让 AI 给你「A 方案还是 B 方案」的选择题，不要让它盲改。
   • 一次最多对比 2 个方案，不要一次给 5 个。
   • 大改时把参考图片一起给，让 AI 照着学。
   • 确认方向后再让 AI 执行，避免来回推翻。
4. 小步快跑。每改一个点就刷新看效果，确认 OK 再改下一个。不要一次堆十个改动。
5. 同步检查移动端。每个模块在电脑上调好后，一定要再看一遍手机上的效果（让 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 — 怎么和决策者对齐、怎么给选择题不给问答题。需要推进决策时读。