Lupy网站搭建实录：我如何用AI搭起自己的互联网商业阵地

我不是程序员，但我一直认为，技术不应该成为一个人做互联网的门槛。

过去想做一个完整网站，要么自己学代码，要么花钱找开发团队。

现在有了AI，一个人只要能够把产品想清楚，知道自己想解决什么问题，就可以借助AI把很多想法真正做出来。

Lupy就是我正在推进的一个真实项目。

它不是我为了学习建站随便做出来的练习，也不是一个只负责展示个人简介的网站。

我想把它做成自己的互联网商业阵地。

自媒体负责获得注意力，网站负责沉淀内容和建立信任，产品负责承接用户需求，社群负责让我持续接触真实问题。

这几部分连接起来，才是我想要的Lupy。

最开始，我想把能想到的功能全部放进去

Lupy刚开始规划的时候，我想得非常大。

AI课程、创业课程、工具导航、项目判断器、Prompt Library、会员系统、付费产品、案例、社群、服务商城，我都想塞进网站。

当时的想法是，功能越完整，网站看起来越厉害。

但真正开始搭建以后，我发现一个问题：

功能很多，不代表产品清楚。

用户第一次打开网站，根本不知道应该先看什么。

他也不知道Lupy到底是教AI、教创业，还是卖工具、卖课程、做企业服务。

一个网站什么都想做，最后往往是什么都说不清楚。

所以我开始重新确定Lupy最核心的任务。

它不是为了展示我会多少东西。

它首先要帮助用户回答一个问题：

我怎么把自己的能力、资源或者产品，变成一门互联网生意？

这个问题确定以后，网站的其他功能才有了取舍标准。

我先把网站的商业路径想清楚

我给Lupy确定的路径是：

自媒体获得注意力。

免费网站提供真正有价值的内容。

内容建立信任。

商业实践群承接更具体的问题。

真实问题继续反哺文章、案例和未来产品。

这套路径确定以后，我才发现，网站根本不需要在第一天做得特别复杂。

前端最重要的事情，是让用户能够快速理解Lupy、找到适合自己的内容，并且愿意继续往下看。

后端最重要的事情，不是马上开发一堆课程和工具，而是先接触真实用户。

只有接触到足够多的真实问题，我才知道下一款产品到底应该做什么。

网站不是产品的全部，它只是中间的平台

Lupy网站只是整个系统的一部分。

它不能代替自媒体给我带来流量。

也不能因为页面做得好看，就自动产生收入。

如果没有内容，没有用户，没有产品，网站做得再高级也只是一个壳。

所以我对网站的定位非常明确：

它负责沉淀内容、展示能力、建立信任和承接用户。

真正的增长还要靠自媒体。

真正的收入还要靠产品和服务。

真正的产品方向，还要从用户的问题中寻找。

网站不能脱离这条商业路径单独存在。

我把网站重新拆成了几个核心板块

经过几轮调整以后，Lupy保留了几个主要板块。

Start，开始这里。

它负责告诉第一次进入网站的人，Lupy是什么，他应该从哪里开始。

Learn，免费学习。

这里放能够帮助用户行动的课程、指南和方法。

Judgments，判断。

这里记录我对AI、自媒体、产品、流量和商业的真实判断。

它不是标准答案，而是我的观察、选择和验证过程。

LUPY LAB，实战记录。

这里公开我正在做的真实项目。

包括Lupy网站、自媒体流量系统和AI外贸实验。

有结果就写结果，有问题就写问题，有调整就继续更新。

Community，商业实践群。

这里负责承接那些希望进一步交流项目、获得判断和反馈的人。

这几个板块基本对应了一条完整路径：

用户认识Lupy，开始学习，看见我的判断，再通过真实项目确认我是不是只会讲概念，最后决定要不要进一步交流。

我把Tools栏目砍掉了

Lupy曾经计划过一个独立的Tools栏目。

里面可以放AI工具、Prompt、项目判断器和各种小功能。

这种栏目看起来很丰富，也容易让网站显得“很像一个AI平台”。

但我后来把它砍掉了。

因为市面上已经有大量AI工具导航站。

如果Lupy只是再整理一遍工具链接，很难形成真正的差异。

更重要的是，工具不是Lupy的核心。

用户真正缺少的，往往不是再知道一个AI软件。

他缺少的是判断：

这个工具应该用在什么业务里？

它能不能提高效率？

它能不能帮助我获得客户？

学会以后，怎么变成产品和收入？

所以我不想为了让网站看起来完整，就强行保留一个没有核心价值的栏目。

Skills也没有急着上线

后来我考虑过把Tools升级为Skills。

Tools只是告诉你可以使用什么。

Skills则应该把一个具体任务整理成可以执行的工作流、操作步骤和能力包。

这个方向比工具导航更接近Lupy的价值。

但我没有马上做。

因为Skills不能凭空设计。

只有当某一类问题被用户反复提出，而且我已经有了相对成熟的解决流程，它才值得被整理成一个正式产品。

如果没有真实需求，只是坐在电脑前想象用户需要什么，最后大概率又会做出一堆没人用的东西。

我的选择是先运行内容和社群，再让Skills从真实问题中长出来。

网站采用Next.js和MDX内容系统

Lupy目前使用Next.js的App Router架构，配合TypeScript、Tailwind CSS和MDX内容系统。

我选择MDX，不是为了追求技术感。

而是因为Lupy以后会持续发布大量文章、课程和项目记录。

如果每新增一篇文章，都需要重新修改页面代码，那这个网站根本不适合长期运营。

MDX可以把文章内容和页面程序分开。

正文可以像写Markdown一样维护，同时又能在内容里使用React组件。Next.js官方也支持在App Router中使用本地MDX，通过文件或动态路由渲染内容。

这意味着网站的框架搭好以后，日常发布内容只需要新增或修改MDX文件。

页面样式、导航和内容组件可以继续复用。

我的目标是：

以后发文章是一项内容运营工作，不是每次都重新开发网站。

我给每篇内容设计了统一信息

每篇文章不只需要正文。

它还需要一些基本信息，例如：

• 标题；
• 稳定网址；
• 内容摘要；
• 发布日期；
• 分类和标签；
• 当前状态；
• 是否进入首页推荐；
• 封面图片。

这些信息会写在MDX顶部的Frontmatter里。

这样网站可以自动读取文章信息，生成列表、分类、相关推荐和首页精选。

Judgment、Learn和LUPY LAB分别放在不同的内容目录里。

以后新增文章时，只需要把内容放进对应目录，不需要到处修改页面。

我没有从空白项目重新开始

这个网站不是我一个人关在房间里，突然从零敲出来的。

最开始，朋友负责主要开发，并把项目上传到了GitHub。

我拿到仓库以后，开始通过GPT和Codex继续调整产品结构、页面内容、视觉效果和发布系统。

这中间还出现过一个很典型的问题。

我电脑里曾经有两个看起来像网站项目的文件夹。

一个是桌面上的React/Vite项目。

另一个才是从GitHub同步下来的正式Next.js仓库：

D:\github_severs\ai_severs

如果在错误的文件夹里修改，做得再多也不会进入正式网站。

后面我才把所有修改统一放到真正连接GitHub的项目仓库里。

这也是为什么做网站不能只盯着页面。

你还要知道代码究竟在哪里、哪个仓库是正式项目、哪个分支会进入生产环境。

我用分支推进网站改版

正式修改网站时，我没有直接在生产分支上反复试验。

项目先从main建立了lupy-v2，后面又继续推进到lupy-v3。

这样做的好处是，新版本可以单独修改、检查和预览，不会马上影响线上网站。

GitHub的分支本身就是为了让开发、修复和实验在相对独立的环境里进行，每次提交也会留下项目变化的记录。

Lupy的生产分支最终确定为main。

开发版本先在独立分支完成，确认没有明显问题以后，再进入生产分支。

这套流程让我可以大胆调整网站，同时保留旧版本。

如果新版本出现严重问题，也还有回退的空间。

Lupy V3真正改了什么

V3不是只换了颜色和字体。

这次调整首先重新梳理了首页顺序。

首页不再急着展示所有功能，而是先让用户理解：

Lupy帮助谁？

解决什么问题？

用户进入网站以后应该先做什么？

网站同时重新调整了课程、判断、案例、服务和社群入口。

一些会遮挡内容、影响移动端操作的设计被删除。

品牌名称、页面标题、SEO描述、分享信息、页眉、页脚、About和Contact也重新统一成Lupy。

网站图标也替换成了LUPY自己的标识。

这些看起来是零散修改，但它们解决的是同一个问题：

不能让用户看到一个功能很多，却不知道在讲什么的网站。

上线前，我做了多尺寸检查

网站不是在我的电脑上能打开，就算完成。

上线前，我对17个页面进行了不同屏幕宽度的检查。

包括桌面端、平板和移动端。

我重点检查了导航是否正常、按钮能不能点击、文字有没有溢出、课程入口是否有效，以及手机上是否出现遮挡。

因为Lupy未来的大部分用户，很可能是从抖音、微信等平台直接用手机打开网站。

如果移动端体验有问题，桌面端做得再漂亮也没意义。

推送时，我也遇到了GitHub连接问题

网站完成以后，需要把修改提交到GitHub。

但第一次推送lupy-v3时，GitHub的HTTPS连接出现了重置问题。

代码已经完成，本地检查也没有问题，但就是推不上去。

后面重新排查Git、远程仓库、网络和代理状态，确认GitHub直连恢复后，才成功完成Push。

最终lupy-v3成功推送，并跟踪远程同名分支。

对应提交为：

df7f0ca

这一刻才意味着，本地的改版成果真正进入了远程仓库。

GitHub和Cloudflare组成了自动部署链路

Lupy的代码托管在GitHub，网站通过Cloudflare连接仓库进行部署。

生产分支是main。

当确认后的代码进入main，Cloudflare就会根据仓库变化自动构建和发布网站。

Cloudflare官方的Git集成也是这个逻辑：连接GitHub或GitLab仓库后，每次推送都可以触发新的构建和部署，同时保留部署状态与历史记录。

其他开发分支还可以生成预览部署，不必直接影响生产域名。

这条链路跑通以后，网站的更新方式就变成：

本地修改。

本地检查。

提交代码。

推送GitHub。

进入生产分支。

Cloudflare自动部署。

网站上线。

网站上线以后，真正的工作才开始

Lupy上线并不代表这个项目完成了。

网站只是基础设施。

真正决定它有没有价值的，是后续有没有人进入、有没有人看内容、有没有人愿意继续学习，以及网站能不能承接自媒体带来的用户。

所以网站上线以后，我开始继续整理内容。

后面共生成并整理了49篇Learn MDX，放入src/content/guides。

这些内容包括商业机会、需求验证、商业模式、产品设计、获客、销售、交付、经营复盘，以及独立站和云南大蒜等专项内容。

每篇文章都添加了对应的标题、摘要、英文slug、分类和状态。

这样课程不再是散落的文档，而是逐渐成为可以在网站中长期维护的内容系统。

当前已经完成的部分

目前，Lupy已经完成了基础网站结构。

核心栏目已经建立。

Next.js和MDX内容系统已经跑通。

GitHub仓库、开发分支和生产分支已经明确。

Cloudflare部署链路已经运行。

网站的品牌信息和主要页面也已经完成统一。

第一批Learn内容已经开始进入网站。

这说明Lupy已经不是停留在脑子里的想法。

它已经成为一个可以访问、可以持续发布内容、可以继续扩展的真实产品。

当前还没有完成的部分

现在最重要的问题已经不是继续增加网站功能。

而是内容、流量和用户。

Judgments还需要继续补充真正属于我的判断。

LUPY LAB需要持续记录真实项目。

自媒体流量系统需要稳定运行。

Community需要接触真实用户，并验证大家究竟愿意为什么样的判断、反馈和服务付费。

网站的数据也需要持续观察：

哪些内容有人看？

用户从哪里进入？

看完以后去了哪里？

有没有人愿意加微信、进入社群或者提出真实问题？

这些结果会决定Lupy下一步做什么。

下一阶段，我不会继续无止境地改网站

做网站特别容易陷入一种状态：

总觉得颜色还能再调，版式还能再改，首页还能再加一个功能。

但如果一直沉迷开发，网站就会变成一种高级的拖延。

所以Lupy下一阶段不会继续无止境地堆功能。

主要精力会转向几个方向：

持续发布内容。

运行自媒体账号。

把公域流量引导到网站。

测试微信和社群承接。

记录真实用户问题。

根据问题决定未来的Skills、陪跑、诊断和项目服务。

只有用户行为和真实需求，才有资格决定网站下一步增加什么。

我现在对建站这件事的判断

AI确实大幅降低了建站门槛。

一个没有系统学过编程的人，也可以借助AI参与产品设计、页面调整、内容整理、代码检查和部署。

但AI不会替你决定产品方向。

它可以生成页面，却不知道这个页面为什么存在。

它可以帮你增加十个功能，却不知道这十个功能有没有用户需要。

它可以帮你快速写出代码，也可以帮你快速制造一堆没有价值的东西。

真正决定网站价值的，仍然是人的判断。

我做Lupy最大的收获，不是学会了几个建站命令。

而是我开始把内容、流量、产品、用户和服务放在一套系统里考虑。

网站只是其中一个平台。

它真正要承接的，是我未来几年持续积累的内容、判断、项目和影响力。

Lupy网站已经上线。

但这篇记录不会在这里结束。

以后每一次重要调整、真实数据和方向变化，我都会继续更新。

这就是LUPY LAB存在的意义：

不展示一个包装完成的成功案例，而是公开一件事情到底是怎么被做出来的。