我去年用 Cursor 做过一个企业官网。从确定网站内容、规划页面，到让 AI 生成代码，再到最终上线，前前后后不到两个小时。
整个过程非常快，最终呈现的效果也相当不错。当时确实让我感受到，AI 在软件开发上的效率提升有多明显。
最近更换了域名，我又重新考虑了一下官网的事情。既然要重新做，干脆就不只是换个域名、改改页面，而是从头规划一次，反正有AI，都不算事吧。加上现在GEO那么火，可以以这个主题来规划。
这次我给自己定了一个目标：不仅要把官网做好看，还要从 SEO 和 GEO 的角度考虑，让网站具备长期内容运营和搜索收录的基础。
结果，一个原本以为很快就能完成的事情，前前后后竟然花了一个星期。
但有意思的是，这一个星期里，真正花在 AI 编写代码上的时间并不多。更多时间反而花在了产品设计、技术架构和反复验证上。
先想清楚，官网到底要解决什么问题
如果只是做一个展示型官网，其实没有太多复杂的事情。
首页展示品牌，几个页面介绍产品和服务，再加上联系方式，也没有什么API对接的，全部静态页面，发给AI，基本就可以交付了。AI 完全有能力在十几分内生成并优化好这样一套网站。
但我这次的目标不一样！我不是纯粹做展示，而是要考虑SEO+GEO的。
从产品角度来看，我希望这个官网至少承担两个作用：一是让访问者快速了解品牌、产品和服务，建立基本的信任；二是成为一个长期的内容入口，通过持续发布文章，让搜索引擎和大模型有机会发现、理解和收录网站内容。
这两个目标看起来简单，但会直接影响后续的页面结构、内容组织、技术选型和发布机制。
所以，我没有一开始就让 AI 生成整套页面，而是先把业务目标、网站模块、内容组织方式和发布流程梳理清楚。
.jpg)
为什么这次我特别关注 SEO 和 GEO
SEO 大家应该比较熟悉，简单来说，就是通过网站内容、页面结构和技术规范，让搜索引擎更好地理解网站，从而获得自然搜索流量。
GEO 则是生成式引擎优化，关注的是如何让大模型和 AI 搜索工具更容易理解、识别和引用网站中的内容。
两者的实现方式和评价机制并不完全相同，但对于企业官网来说，有一个共同点：网站不能只考虑人打开之后看到什么，还要考虑搜索引擎和 AI 系统能不能正确读取页面内容。
这也是我这次在技术方案上做的一个重要决定：网站的主要内容尽量直接生成静态 HTML，而不是依赖前端通过 API 请求数据，再动态渲染页面。
为什么这么做？
因为如果一个页面打开之后，标题、正文等核心内容还需要通过 JavaScript 请求接口才能加载出来，那么不同爬虫对页面的抓取和渲染能力，就可能影响最终的内容识别效果。
虽然现在不少搜索引擎已经具备 JavaScript 渲染能力，但这并不意味着所有爬虫和 AI 检索工具都能稳定、完整地执行前端请求。
相比之下，静态 HTML 可以直接把标题、正文、描述等核心内容放在页面源码里，减少对接口和运行环境的依赖，也更方便控制页面结构。
当然，静态页面并不代表完全不能使用 API。比如后台管理、用户交互等场景，依然可以正常使用动态接口。我的思路是：面向搜索和内容展示的核心页面，优先采用静态输出。
技术框架怎么选，取决于实际需求
确定了产品方案之后，才开始考虑技术框架。
这次官网的主要需求其实很明确：前端负责展示，后台负责文章管理，发布时自动生成静态页面。
所以，我没有选择特别复杂的技术架构。
前端使用 Vue3 + Tailwind CSS，负责官网页面的开发。首页、关于我们、服务介绍、联系我们等固定内容，直接使用项目内的 JSON 文件维护。
这些内容本身变化频率不高，没有必要为了修改一段介绍文字，就额外引入数据库查询和接口请求。
文章内容则单独处理，使用微信云开发存储文章数据，再通过 Express 搭建后端服务，负责文章数据读取、静态页面生成和发布流程。
后台管理部分，我使用 Element Plus 搭建了一个比较简单的管理系统，主要包含文章编辑、SEO 和 GEO 信息配置、文章预览、发布以及基础站点配置。
没有必要为了一个内容管理后台，把它做成一个庞大的 CMS 系统。能满足实际使用需求，后续维护方便，就足够了。
整个技术框架的核心思路是：固定内容直接维护，可变内容交给后台管理，发布时统一生成静态页面。
真正花时间的，是把发布流程设计好
这次开发中，我觉得比较重要的一部分，就是文章发布机制。
如果每次发布一篇文章，都需要修改代码、重新构建和部署，那么即使网站采用了静态页面，后续的内容维护成本也会很高。
所以，我把文章管理和静态页面生成设计成了一套完整流程。
首先，在后台编辑文章，填写标题、正文、摘要、关键词，以及对应的 SEO 和 GEO 信息。
文章确认之后，点击发布，后端服务读取数据库中的文章数据，按照预先设计好的 HTML 模板，将文章内容和相关元信息填充进去，生成一份独立的静态 HTML 文件。
同时，系统会更新 sitemap.xml，把新发布的文章地址加入网站地图，方便搜索引擎发现网站中的页面。
这样一来，后台负责内容管理，发布服务负责生成静态文件，最终部署到网站上的就是可以直接访问的完整 HTML 页面。
这套机制设计好之后，后续发布文章就不需要再关注底层代码怎么实现了，只需要按照后台的内容规则填写和发布即可。
我认为这才是产品设计真正有价值的地方：不是单纯把一个功能做出来，而是把后续反复发生的事情变成一套稳定、可重复的流程。
AI 全程辅助，但不是把所有事情都交给 AI
这次开发，AI 基本参与了整个过程。
从页面结构规划、文案整理、组件设计，到前端页面、后台功能、接口逻辑和静态页面生成，都有 AI 的参与。
但我自己的工作方式并不是把所有需求一次性丢给 AI，然后等着它交付一个完整项目。
我更习惯先把需求和技术方案确定下来，再拆分成具体任务，让 AI 按照已经确定的方向完成实现。
每完成一部分，就放到 IDE 中运行，检查页面效果和实际逻辑，发现问题再继续调整。
尤其是一些涉及数据结构、页面生成规则和发布流程的功能，如果前面的设计没有确定好，AI 即使能够很快生成代码，也可能只是更快地实现一个不合理的方案。
AI 编码的响应速度已经很快了。很多时候，生成代码、复制到 IDE、运行查看效果，整个过程非常短。
真正需要反复思考的，是这个功能到底应该怎么设计，数据应该怎么组织，模块之间应该如何协作，以及后续有没有扩展和维护的空间。
为什么做一个官网，最后花了一个星期？
回头看这次的开发过程，我觉得这个时间并没有主要花在写代码上。
更多时间花在了几个方面：确定官网的业务目标、规划页面和内容结构、设计 SEO 和 GEO 的实现方式、选择技术框架、梳理文章发布流程，以及不断验证整个方案是否合理。
这些事情做好之后，真正进入编码阶段，反而没有想象中那么复杂。
这也让我再次意识到一个问题：无论有没有 AI，产品设计和技术架构设计始终都很重要。
以前做项目，大家经常觉得开发周期长，是因为一个项目需要产品、设计、前端、后端、测试等不同角色协作，大量时间消耗在沟通、开发、联调和修改上。
但如果回到项目本身，前期需求分析、业务逻辑梳理和技术框架设计，依然是决定项目能不能做好、后续能不能持续迭代的重要环节。
现在 AI 把编码实现的成本降低了很多，但它并没有让产品设计和架构设计变得不重要。
相反，当代码可以越来越快地生成时，前面设计得是否合理，反而会更加直接地影响最终结果。
一个需求没有想清楚，AI 可以很快生成一堆代码，但这些代码未必能解决真正的问题。
一个技术架构没有考虑清楚，前期可能看不出问题，等到需要增加功能、调整业务逻辑或者维护系统时，就会慢慢暴露出来。
好的设计不一定能让你少写几行代码，但它能够减少后面大量不必要的修改，让产品更容易扩展，也让维护变得轻松。
把所有事情交给 AI，也没有什么问题
现在经常能看到一种观点：做产品不需要想那么复杂，把需求告诉 AI，让 AI 自己规划、自己开发就可以了。
我觉得这种方式也没有什么问题。因为我有个完全不懂代码的朋友，就是这样使用workbuddy上线了个小程序的。
每个人做产品的目的不一样，对产品的要求也不一样。
如果只是做一个简单的个人网站，或者一个一次性使用的小工具，那么直接让 AI 生成，能够满足自己的需求就可以了。没有必要为了一个简单的东西，专门设计一套复杂的技术架构。
但如果这个产品需要长期运营，后续还要不断增加功能、管理内容、维护数据，甚至承载实际业务，那么前期就值得多花一些时间考虑产品结构和技术方案。
至于选择自己用 AI 开发，还是交给专业团队来做，本质上也是根据自己的需求和能力来决定。
我一直觉得，做事情没有必要为了追求某种技术方式而增加不必要的复杂度。当前够用，就先把事情做好；等到需求发生变化，原来的方案不够用了，再寻找合适的解决办法。
但有一点我比较坚持：无论项目大小，都应该尽量想清楚自己到底要解决什么问题。
AI 可以帮助我们快速实现想法，但一个产品最终能不能真正解决问题，还是取决于我们对业务、用户和产品本身的理解。
这次用一个星期重新做企业官网，对我来说也是一次很好的实践。
从去年不到两个小时做出一个官网，到这次花一周时间重新规划、设计和开发，我并不觉得这是效率变低了。因为两次做的同一个事情，本来就不是同一个目标。
一个是快速把网站做出来，另一个是希望把它做成一个能够长期维护、持续发布内容，并兼顾搜索引擎和 AI 检索需求的网站，并且可以当作模板，很快的复制给别人使用。
页面能不能做出来，AI 已经帮我们解决了很多问题。但页面背后应该承载什么业务、采用什么架构、如何支撑后续发展，这些事情依然值得认真思考。
如果现在让你用 AI 做一个长期运营的软件产品，你会选择先把功能快速做出来，后面遇到问题再调整，还是愿意在开始之前多花一些时间，把产品和技术框架先设计清楚？
这也是我最近一直在实践和思考的事情。
我目前也在持续探索自己的独立产品，包括 SaaS 小程序和 AI 全自动流程运营助手。后续会继续记录这些产品从需求设计、技术开发到功能迭代的真实过程，也会分享一些实际开发中遇到的问题和解决思路。
如果你也对产品设计、全栈开发和 AI 应用落地感兴趣，可以一起交流，看看 AI 时代做产品这件事，还能有哪些新的可能。