Vibe Coding不是“一键建站”：AI写代码时代，SEO人必须重新理解网站生产

基于 Google《Search Off the Record》第110期关于 Vibe Coding 的讨论整理与延展。

---

一、Vibe Coding到底是什么

Vibe Coding，直译可以理解为“凭感觉编码”或“氛围式编码”。它不是一种新的编程语言，也不是某个固定工具，而是一种新的软件生产方式：用户不再直接从函数、变量、框架、接口开始写代码，而是用自然语言告诉AI“我要什么”，再由AI生成对应的网站、应用、脚本或自动化流程。

在传统开发流程中，一个网站从需求到上线，通常要经历需求沟通、技术选型、页面结构设计、前端开发、后端配置、部署、测试、修复等多个环节。Vibe Coding把其中一部分环节压缩到了一个连续对话中。你可以直接告诉AI：“帮我做一个个人网站，要有首页、关于我、项目展示和联系方式。”AI会根据自己的判断生成HTML、CSS、JavaScript，甚至直接选择Next.js、Hugo、React、静态站点生成器、CMS或数据库方案。

这正是Vibe Coding最有吸引力的地方：它让很多非程序员第一次感受到“我好像也能做网站”。过去需要开发者完成的基础代码搭建，现在可以通过一句话快速生成。对SEO、内容运营、产品经理、小型创业者来说，这种能力会显著降低试错成本。

但问题也恰恰出在这里。AI能生成代码，并不代表它理解你的业务目标、长期维护成本、安全边界、SEO策略和数据风险。它会做出“看起来合理”的选择，但这些选择未必适合你的真实场景。

---

二、它真正降低的是“启动成本”，不是“判断成本”

Vibe Coding最容易被误解成“一句话建站”。这种理解只看到了AI生成代码的速度，却忽略了网站建设中更重要的部分：判断。

当你对AI说“帮我做一个网站”，AI必须自己补全大量隐含条件。它可能默认使用静态站点，也可能选择JavaScript框架，也可能搭建一个带数据库后台的CMS。每一种方案都有合理性，但它们对应的成本、性能、SEO可控性、安全要求和维护方式完全不同。

静态站点适合展示型页面、测试项目、个人网站、轻量工具。它部署简单，攻击面较小，加载速度通常更容易控制。JavaScript框架适合交互复杂的产品，但如果渲染、路由、链接、内容输出处理不好，可能影响搜索引擎抓取和页面可访问性。CMS适合频繁更新内容的团队，但也会引入权限管理、插件安全、数据库维护和性能优化问题。

所以，Vibe Coding降低的是“从0开始写代码”的门槛，不是“做正确技术决策”的门槛。越是复杂的网站，越不能把技术选型完全交给AI。因为AI并不知道你未来是否要多人协作，是否要持续更新，是否要承载用户数据，是否需要国际化，是否涉及支付，是否需要结构化数据，是否有合规要求。

真正有效的使用方式不是让AI“随便做一个”，而是明确告诉它边界：我要静态站点，页面必须可被搜索引擎直接读取；我要使用某个指定框架；不要引入数据库；不要生成无用依赖；所有页面必须有独立URL；必须生成sitemap；robots.txt不能阻止核心资源；部署前要进行基础检查。

这意味着，AI越强，使用者越需要清楚自己要什么。

---

三、为什么“让AI给网站加点SEO”是一个危险指令

在对话中，一个非常关键的观点是：如果你只是告诉AI“给这个网站加点SEO”，结果很可能不可靠。这个问题不只存在于AI，也存在于很多人与开发者的协作中。

“加点SEO”本身不是一个明确需求。它可能意味着写title和description，也可能意味着优化页面结构、生成canonical、修复内部链接、创建sitemap、开放资源抓取、改善HTML语义、优化性能、处理重复页面、添加结构化数据、设置hreflang、控制索引策略、改善移动端体验。

如果需求不明确，AI通常会选择最表层、最容易生成的东西。它可能机械地添加meta标签，塞入一段结构化数据，生成一个robots.txt，却不一定理解这些配置是否与网站实际架构一致。比如，canonical指向错误域名，sitemap包含不存在的URL，robots.txt误封JS/CSS资源，结构化数据与页面可见内容不一致，这些问题都不是“有没有SEO标签”能解决的。

SEO不是装饰层，而是网站工程的一部分。它贯穿页面生成、链接架构、内容呈现、索引控制、性能体验和部署流程。一个真正适合搜索引擎理解的网站，不能只靠最后一步“补SEO”。

因此，用AI建站时，SEO需求必须前置，而不是后置。正确的指令应该是：

这个网站需要使用服务端或静态HTML输出核心内容；每个页面必须有唯一title、description、canonical；导航链接必须使用可抓取的a标签；图片需要alt文本；生成sitemap.xml；robots.txt不得阻止核心页面和静态资源；所有页面返回200状态码；不存在空页面、孤岛页面和重复URL；部署前检查HTML语义和内部链接。

这类指令才是可执行的。AI可以帮你生成，但前提是你把SEO从“玄学要求”拆成“工程约束”。

---

四、AI建站最容易出问题的四个环节

1. 技术选型被AI自动决定

AI通常会根据训练数据和上下文选择一个“常见方案”。这并不等于最适合你的方案。比如，一个简单的企业展示站，本可以用静态HTML或轻量CMS完成，但AI可能生成一个复杂的前端工程，包含大量依赖、构建流程和运行时逻辑。

技术复杂度不是越高越专业。对多数内容型网站、品牌官网、落地页和工具页来说，稳定、可抓取、易维护，比炫技更重要。AI如果引入过多框架，可能会让后续维护变得困难，也会增加性能和安全风险。

2. AI会重复造轮子

在实际使用中，AI经常会自己写一段函数，而不是复用已有库或已有组件。短期看，它确实完成了任务；长期看，代码会越来越碎片化。每次修复问题，AI可能再加一层补丁，而不是重构已有逻辑。

这会带来典型的“补丁堆叠”问题：功能能跑，但代码越来越难理解；页面能打开，但结构越来越混乱；问题能临时修复，但后续每次修改都可能引发新的问题。

对个人测试项目来说，这种风险可以接受。对商业网站、客户项目、长期运营项目来说，这就是技术债。

3. 部署与密钥管理容易出风险

网站不是在本地能运行就结束了，还要部署到服务器、托管平台或云服务。部署过程可能涉及API Key、数据库连接、环境变量、访问令牌和权限配置。

如果使用AI生成部署脚本，而使用者又不理解这些文件的作用，就可能出现敏感信息误上传到公开仓库的问题。现实中，API Key泄露、配置文件暴露、测试环境误公开，并不是罕见事故。

所以，AI建站必须配合版本管理、环境变量隔离、部署前检查和权限控制。GitHub能帮助保留历史版本，GitHub Actions能自动部署，但这些工具只有在配置正确时才安全。

4. 测试不能只靠“页面看起来正常”

AI生成的网站，最容易骗过人的地方是“视觉上像一个网站”。页面能打开，按钮能点，颜色还不错，并不代表它是一个合格网站。

一个合格网站至少需要检查这些问题：核心页面是否返回200状态码；移动端是否可用；导航是否真实链接而非不可抓取按钮；内容是否在HTML中可见；图片、JS、CSS是否被错误屏蔽；表单是否可提交；错误页是否正确处理；sitemap是否包含有效URL；canonical是否准确；结构化数据是否与页面内容一致。

AI可以帮助写测试，也可以借助浏览器代理、自动化工具或插件访问页面、点击按钮、读取日志。但测试目标必须由人定义。AI不知道什么叫“业务成功”，它只能根据你的描述判断。

---

五、Vibe Coding适合哪些网站，不适合哪些网站

Vibe Coding最适合低风险、低复杂度、快速验证型项目。

比如，个人网站、小型展示页、临时活动页、内部工具、SEO测试站、数据清洗脚本、页面原型、静态落地页、简单计算器、内容模板生成器。这类项目的共同特点是：即使出错，损失也有限；没有大量用户数据；不涉及支付；不承担关键业务流程；维护周期短或可随时重做。

它不适合直接用于高风险业务系统。

比如，电商交易系统、会员中心、支付流程、客户数据库、医疗法律金融类系统、复杂权限后台、大型内容平台、多语言企业站、依赖长期SEO资产的网站。如果这些项目完全由AI“凭感觉生成”，后续风险会集中爆发在安全、性能、索引、权限、维护和数据一致性上。

判断一个项目能不能用Vibe Coding，不是看AI能不能做出来，而是看出错之后代价有多大。

如果只是做一个测试工具，AI生成80分已经很有价值。如果是客户官网、品牌资产或业务系统，80分远远不够。因为网站上线后，不只是“能不能访问”，还关系到搜索引擎能不能抓取、用户能不能信任、团队能不能维护、数据会不会泄露、未来能不能扩展。

---

六、SEO人员应该如何使用Vibe Coding

对SEO人员来说，Vibe Coding最大的价值不是替代开发，而是让SEO从“提需求的人”变成“能验证假设的人”。

过去，SEO想测试一个抓取问题，可能要等开发排期。现在，可以快速生成一个测试站，模拟不同的robots.txt、canonical、重定向、分页、JavaScript渲染、内部链接结构，再观察搜索引擎或测试工具如何响应。

这对技术SEO尤其重要。很多SEO问题不是靠经验判断就能下结论，而是要搭建环境验证。比如：

不同渲染方式下，核心内容是否可被读取；
robots.txt阻止JS/CSS后，页面理解是否受影响；
canonical冲突时，搜索引擎可能如何选择；
分页和筛选URL是否会造成重复抓取；
结构化数据错误是否会影响富结果资格；
内部链接从按钮变成a标签后，抓取路径是否改善。

Vibe Coding可以让SEO更快构造实验环境。它降低了搭建测试页面的成本，也降低了SEO与开发之间来回沟通的摩擦。

但SEO人员不能因此跳过技术理解。恰恰相反，越使用AI，越要理解HTTP状态码、HTML语义、robots规则、sitemap、canonical、渲染方式、日志分析和基础部署逻辑。否则，AI生成的测试结果可能本身就是错的。

---

七、AI内容生成与AI建站必须分开看

这期对话中还有一个非常重要的分界：用AI生成网站结构，与用AI批量生成内容，不是一回事。

AI可以帮助搭建页面框架、组件、工具、部署流程和测试脚本。但如果进一步让AI自动生成大量营销页面、趋势文章、产品介绍，并试图用这些内容获取搜索流量，就会进入另一个风险区。

问题不是“AI写的内容一定不好”，而是“没有真实经验、真实信息增量、真实验证过程的内容没有竞争力”。如果用户可以直接问AI得到同样答案，为什么还要访问你的网站？如果网站只是把AI答案包装成页面，搜索引擎和用户都没有理由认为它更有价值。

真正有价值的内容，来自企业自身的数据、案例、经验、产品细节、服务过程、行业判断和用户反馈。AI可以帮助整理、重写、扩展、结构化，但不能替代真实信息来源。

所以，在AI建站时代，内容站更要回答一个根本问题：你的网站提供了什么AI无法凭空知道的东西？

如果答案只是“更多页面”，那不是增长策略，而是低质量内容扩张。

---

八、未来网站生产方式的真实变化

Vibe Coding不会让传统开发消失，也不会让WordPress、Drupal、PHP、CMS这类成熟系统突然失去价值。很多企业仍然需要稳定、可控、权限完善、插件生态成熟的建站系统。

真正会改变的是网站生产链条中的低价值重复劳动。

项目初始化、基础模板搭建、组件草稿、测试脚本、部署配置、页面原型、简单自动化流程，这些过去需要花费数小时甚至数天的工作，未来可能被压缩到几分钟或几十分钟。开发者、SEO、运营人员的价值会从“手工搭建”转向“定义标准、审查结果、处理复杂问题”。

这对代理商、独立站团队和内容团队都意味着工作方式变化。

过去，一个新项目往往从安装主题、配置插件、搭建页面模板开始。未来，这些步骤可以由AI快速完成。人的时间应该更多投入到需求澄清、信息架构、转化路径、内容策略、技术审核、数据监控和长期维护上。

换句话说，AI会吃掉“重复搭建”的时间，但不会替代“系统判断”的能力。

---

九、给SEO和网站负责人的实操建议

第一，使用Vibe Coding前，先写清楚网站类型。不要只说“做一个网站”，而要明确是静态站、博客、工具站、落地页、文档站还是带后台的业务系统。

第二，提前指定技术边界。比如是否允许使用数据库，是否必须静态输出HTML，是否必须使用某个框架，是否禁止引入不必要依赖。

第三，把SEO要求写成检查项，而不是抽象目标。不要说“做好SEO”，要说“生成sitemap.xml、设置canonical、页面内容必须在HTML中可见、导航使用a标签、robots.txt不能屏蔽核心资源”。

第四，必须使用版本管理。每次AI修改代码前后，都应该能回退。GitHub或其他版本管理系统不是可选项，而是安全网。

第五，部署前做基础审查。至少检查页面状态码、移动端显示、内部链接、robots.txt、sitemap、canonical、title、description、结构化数据和核心资源访问。

第六，涉及用户数据、支付、会员、数据库和权限系统时，不要完全依赖AI。此类项目必须由懂安全和架构的人审查。

第七，把AI当成助理，不要当成负责人。AI适合生成、补全、重构、测试、解释和加速，但最终责任仍在使用者。

---

十、结语：AI写代码越快，人越要懂系统

Vibe Coding的出现，确实改变了网站建设的起点。过去，很多人卡在“不会写代码”；现在，很多人会卡在“不会判断AI写得对不对”。

这才是更深层的变化。

当AI可以快速生成网站时，代码本身会变得越来越便宜。但正确的架构、清晰的需求、稳定的部署、可维护的结构、可靠的SEO基础和真实有价值的内容，会变得更加重要。

未来的网站竞争，不会只是“谁能更快生成页面”。真正的竞争会变成：谁能更准确地定义问题，谁能更好地约束AI，谁能把技术、内容、搜索、用户体验和业务目标放在一个系统里管理。

Vibe Coding不是终点，而是新起点。

它让更多人拥有了建站能力，也让更多人暴露出系统能力的不足。对于SEO人、内容团队和网站负责人来说，最重要的不是追逐每一个AI工具，而是建立一套可复用的网站生产标准。

AI可以帮你写代码。

但它不能替你承担判断。