创作日志
从一个想法到公网可访问:我怎样把个人网站真正做上线
我用两个多月,把一个停留在脑海里的个人网站构想,逐步变成了可以通过 yongleai.com 访问的真实网站。整个过程经历了需求收缩、品牌设计、概念与详细设计、架构选择、仓库治理、人工智能协作开发、后台建设、备案、云资源配置、故障排查和生产部署。本文保留其中最值得复用的判断、方法和教训,帮助准备独立建站的人看清完整路径,提前避开那些在本地看不出来、到了真实环境才会暴露的问题。
2026 年 7 月 16 日,yongleai.com 在公网正常打开。
浏览器里没有特别戏剧性的画面。首页、创作日志、青铃学堂、关于、留言等页面依次加载出来,健康检查返回正常,服务器上的应用进程也在稳定运行。看起来只是一个网站终于上线了,背后却压着两个多月的需求推演、视觉调整、任务拆分、代码实施、故障调查和部署验证。
很多天,我从上午一直做到深夜。入口页的效果推翻过,页面背景的衔接重做过,后台方案走过弯路,上传功能也曾在生产环境里突然失效。每次看到页面终于恢复正常,我都很清楚,这种“正常”只能说明当前这一小段链路通了,后面还有下一段。
真正把网站做出来以后,我才发现,建站最难的部分很少集中在某一段代码里。困难通常藏在产品目标、视觉设计、数据结构、服务器环境、安全规则和人工验收的接缝处。
下面这条路,是我走完之后留下来的完整方法。
一个想法先经过删减,才有机会落地
最初的想法很大。
我希望有一个长期属于自己的独立空间,可以发布人工智能知识、实践经验和项目复盘,也能承载以后做出来的学习产品和工具。人工智能四级单词视觉记忆卡、需求转译工具、项目管理资源、提示词方法、学习资料,都曾经出现在最初的设想中。
这些内容放在愿景里没有问题,一旦全部进入第一版开发,项目很快就会失去边界。
一个产品页面会带出数据模型、权限、文件存储和发布规则;一个在线工具会带出模型调用、费用、限流和安全;一个用户系统会继续带出注册、登录、找回密码、用户数据和隐私责任。每增加一个看起来很小的入口,后面都会跟着一条很长的行为链。
我做的第一个重要决定,是把第一版压缩成一个能够长期生长的网站基座:
- 用户可以看见品牌、内容和公开页面;
- 用户可以提交留言和反馈;
- 站长可以登录后台、管理内容和处理信息;
- 内容、图片和操作记录可以持久保存;
- 网站具备备案、加密访问、备份、恢复和回滚能力;
- 尚未完成的产品继续留在规划和工程预留中,不提前向用户作出承诺。
这个决定看起来像是减少功能,实际保住了项目。
准备做个人网站时,最先需要写清楚的内容很少涉及技术。先确认用户来到网站后要完成哪些行为,站长要完成哪些运营行为,哪些能力必须进入第一版,哪些内容可以等到真实反馈出现后再建设。
第一版的范围一旦失控,后面的设计、开发、测试和部署都会同时失控。
品牌先长出骨架,页面才有统一的方向
“青风铃的 AI 树屋”最初只是一个名字。
我希望它带有东方幻想的气质,有风、铃、水、树屋、山雾和轻微的灵气,也要让人感受到这里与人工智能、知识和创造有关。这个方向很容易产生漂亮的单张图片,却很难直接变成一个长期可用的网站。
一张好看的图无法自动解决导航、正文阅读、移动端适配、内容列表、后台界面和错误提示。网站需要的是一套能够反复使用的视觉规则。
我逐步把品牌拆成了几个稳定部分:
- 青绿色、雾白和淡金色构成主要色彩;
- 青风铃、玉简、树屋和水面承担品牌识别;
- 留白、雾气和柔和光线控制画面的呼吸感;
- 公开站保持东方幻想气质;
- 后台降低装饰强度,把可读性和操作效率放在前面;
- 图片、标志、图标和字体全部建立资产记录,明确来源、用途和公开边界。
备案通过后,网站名称需要与审核结果保持一致,“青风铃树屋”承担正式网站名称,人工智能方向继续通过内容、栏目和品牌表达传递。这次调整也让我意识到,品牌名、域名、备案信息、页面标题和搜索展示需要在同一套逻辑中工作。
视觉设计阶段花掉了很多时间。
入口页中的人物、远山、水面、金线和玉简被拆成独立图层,再通过网页动效组合。雾气需要有电影感,背景需要适配不同尺寸,页面中段和页脚之间不能出现明显色块断层。部分方案在单张截图里很好看,换到另一台显示器或手机后,比例、裁切和层级马上出现问题。
后来我不再只看一张设计图,而是同时检查:
- 桌面宽屏是否成立;
- 普通笔记本尺寸是否成立;
- 手机竖屏是否成立;
- 动效关闭后是否仍能使用;
- 图片加载失败时是否有可接受的降级;
- 页面内容增加后,整体结构是否仍然稳定。
品牌设计从审美选择逐渐变成了一套约束。每次新增页面,只要沿用这些约束,网站就能保持同一种气质。
概念设计开始连接真实行为
页面草图解决的是“看起来放什么”,网站产品还需要回答“用户完成什么”。
我开始用行为链来检查每一项功能。
一篇创作日志的完整链路大致是:
站长进入后台
→ 创建内容
→ 保存草稿
→ 刷新后内容仍存在
→ 添加封面和正文图片
→ 发布内容
→ 数据写入数据库
→ 产生审计记录
→ 前台创作日志列表出现新内容
→ 用户可以打开详情页阅读
→ 站点地图同步更新
→ 内容下架后前台入口消失任何一环断掉,功能都只完成了一部分。
留言功能也有自己的链路:
用户打开留言页
→ 填写内容并同意隐私政策
→ 服务端校验
→ 数据写入数据库
→ 后台出现新留言
→ 管理员查看和处理
→ 状态修改写入审计记录
→ 用户请求删除时可以找到并处理对应数据概念设计在这个阶段变得非常具体。页面、接口、数据库、权限、安全、审计、前台展示和失败处理开始出现在同一张图里。
这套方法也改变了我的验收方式。
页面能打开,只能证明路由存在。接口返回成功,只能证明请求得到了响应。自动测试通过,只能证明测试覆盖到的条件没有失败。真正的功能验收,需要由一个人按照真实操作顺序走完整条链路,检查刷新、重进、错误输入、未登录、网络失败和数据持久化后的表现。
当一个功能能在正常路径和异常路径下都保持清晰,它才具备真实使用价值。
架构要选择自己长期养得起的规模
早期方案曾经考虑过静态网站、托管平台和更轻量的建站方式。随着后台、数据库、留言、内容发布、审计和图片管理进入范围,网站逐渐需要一个完整的应用架构。
我最终采用了模块化单体结构。
公开站、后台、接口和数据访问都放在一个主仓库和一个主应用中,内部按照职责分层。它比多个服务更容易理解、部署和回滚,也能为以后增加新产品保留空间。
主要技术组合包括:
- Next.js(全栈网页框架)负责公开页面、后台页面和服务端接口;
- TypeScript(类型安全编程语言)约束数据和接口结构;
- PostgreSQL(关系型数据库)保存内容、留言、资产、会话和审计数据;
- Drizzle ORM(对象关系映射工具)管理数据库访问和迁移;
- Nginx(网页服务器与反向代理)负责加密访问、请求转发和维护页;
- ECS(云服务器)运行网站应用;
- OSS(对象存储服务)保存公开图片和受控文件;
- Git(版本管理工具)与独立工作树保存每次任务的变更和回滚点。
这套架构的价值来自边界清楚。
页面负责展示和交互,接口负责接收请求,服务层负责业务规则,数据访问层负责持久化,审计记录保存重要操作。图片上传也通过统一存储服务处理,应用代码不直接依赖某一个文件目录。
我没有在第一版引入微服务、复杂消息队列、多人审批和大规模数据平台。当前访问量、运营人数和产品状态都用不上这些能力,提前建设只会增加排查难度和维护成本。
架构选择需要同时考虑未来扩展和当前能力。能够稳定维护三年的简单系统,通常比只能在架构图里显得先进的复杂系统更有价值。
人工智能能加快执行,边界仍要由人守住
这个网站的大量代码由人工智能编码代理协助完成。
它能快速读取文件、实现功能、补测试、修改样式和执行命令,也会在上下文不完整时误解目标,扩大修改范围,或者把自动测试的通过当成整个功能的完成。
为了让协作可控,我逐步建立了一套执行规则:
一项任务
→ 一个独立工作树
→ 一个功能分支
→ 一张任务卡
→ 明确允许修改的文件
→ 明确禁止触碰的路径
→ 明确必跑命令
→ 明确停止条件
→ 人工检查差异
→ 人工完成业务验收
→ 通过后再合流任务卡里不能只写“完善后台”“实现上传”“优化页面”。
它需要明确站长要完成什么行为,用户能看到什么结果,数据写入哪里,哪些接口参与,哪些审计记录必须产生,失败时页面如何表现,什么条件下必须停止,以及怎样撤销本次变更。
这套流程看起来比一句提示词慢,实际减少了大量返工。
人工智能尤其容易在视觉微调和跨层功能中产生偏差。一个数值改动可能在当前屏幕上成立,换到其他分辨率后马上失效;一个保存按钮可能提示成功,刷新后数据却消失;一个发布接口可能返回成功,前台仍然读取旧的数据源。
我后来把人工智能的角色固定在“受控执行者”上。范围、优先级、产品判断、最终验收和生产发布仍然由我负责。
真正耗时间的地方,通常位于链路接缝
项目中有几类问题反复出现。
视觉效果在另一块屏幕上失效
最初有些页面在我的电脑上看起来完整,换一个屏幕尺寸后,背景图、内容区域和页脚之间出现明显断层。
原因并不只在某一条样式。背景图片原本按照固定尺寸制作,页面容器又有自己的最大宽度,图片裁切、遮罩和内容高度叠加后,整体只能在少数尺寸下成立。
最终的解决方案是重新设计场景层级,让背景、主视觉、色调和尾部过渡成为完整的响应式场景。验收也从“截图看起来正常”升级为多尺寸浏览器检查。
这件事给我的经验很直接:响应式设计需要在结构层解决,不能长期依靠追加几个像素值补洞。
后台显示成功,数据链路没有完成
封面上传曾经在生产环境里失败。浏览器已经发出请求,服务器日志也能看到请求进入,数据库里却没有资产记录,审计表也没有对应操作。
这种问题无法通过反复点击按钮解决。
我需要沿着请求链逐层查:
浏览器
→ Nginx
→ 应用路由
→ 身份认证
→ 上传策略
→ 对象存储
→ 数据库
→ 审计记录
→ 前台读取哪一层开始没有证据,问题就集中在哪一段。
后来我把这套方法用于所有跨层故障。先收集日志、数据库记录、接口响应和运行环境信息,再进行修改。一次只改变一个变量,修复后重新走完整行为链。
部署脚本也会产生错误判断
一次生产部署被环境文件检查拦住。仓库里只有用于说明配置格式的 .env.example 模板,部署脚本却把它和真实密钥文件一同判定为风险。
如果直接关闭检查,真正的环境文件也可能被带入发布包。
最终处理方式是建立精确白名单:模板文件允许存在,真实环境文件继续阻断。修复后的脚本先做语法检查,再创建发布包、校验摘要、上传服务器、构建应用、替换运行目录、启动服务,最后执行本机和公网验证。
安全规则不能因为一次误报被整体拆掉。更稳妥的做法是缩小规则,使它准确区分允许项和禁止项。
合规上线包含一整套工程动作
本地运行和公网运行之间隔着很多层。
本地开发时,域名、证书、备案、网络入口、云数据库、对象存储权限、服务器用户、运行目录和生产密钥都可以暂时不存在。公网环境里的每一层都需要真实成立。
我选择中国内地服务器后,把这些工作放进同一条上线链路:
- 确认域名和网站名称;
- 准备并完成 ICP 备案(互联网信息服务备案);
- 按要求处理公安联网备案;
- 准备隐私政策和版权声明;
- 配置服务器、数据库和对象存储;
- 使用 HTTPS(加密传输协议)保护公开站和后台;
- 配置 DNS(域名解析);
- 隔离开发、测试和生产环境;
- 将密钥保存在服务器环境中;
- 准备数据库备份和恢复方法;
- 创建可追溯的发布包;
- 部署后检查健康接口、版本接口和公开页面;
- 由真实用户操作完成最终功能验收;
- 出现严重异常时回滚版本或切换维护页。
备案、公安联网备案和页脚信息需要以所在地主管部门和接入服务商的最新规定为准,不能照搬别人的材料。
云资源的角色也要分清。
服务器运行程序,数据库保存结构化业务数据,对象存储保存图片和文件,域名负责用户访问入口,域名解析把域名指向服务器,加密证书保护传输过程。缺少其中任何一环,网站都可能出现“页面能打开,核心功能却无法正常工作”的状态。
部署完成后,我没有只检查首页。
我检查了健康接口、版本接口、入口页、首页、创作日志、青铃学堂、关于和留言页面;同时核对服务器正在运行的代码版本、服务进程、运行目录和依赖版本。公网访问这一步已经完成,内容发布和其他业务能力仍然按照各自的验收剧本继续核验。
准备独立建站的人,可以直接沿用这条路径
第一步:写一页范围说明
写清网站服务谁、解决什么问题、第一版包含什么、暂缓什么。
一页范围说明能在后续每次增加功能时提供判断依据。
第二步:画出核心行为链
至少覆盖访问、阅读、留言、内容发布、图片上传、下架和管理员登录。
每条链路都要包含页面、接口、数据库、安全、审计、前台结果和异常处理。
第三步:冻结信息架构和品牌规则
确认导航、栏目、页面层级、色彩、字体、图片风格、移动端原则和资产管理方法。
视觉稿需要接受真实内容和不同屏幕的检验。
第四步:选择能够长期维护的架构
个人项目优先考虑单仓库、单应用、清晰分层和简单部署。
技术选择要服从真实需求、维护能力和成本上限。
第五步:建立版本和任务治理
每个任务使用独立分支和工作目录,提前写清范围、验收、证据和回滚方法。
人工智能生成的报告只能作为线索,仓库差异、命令输出、数据库记录和真实页面才构成验收证据。
第六步:先打通一条最小真实闭环
可以从留言功能开始:
前台提交
→ 数据库保存
→ 后台查看
→ 管理员处理
→ 审计记录一条真实闭环能够尽早暴露架构、安全和数据设计中的问题。
第七步:让合规工作与开发并行
域名、备案、网站名称、隐私政策、版权声明、服务器和证书都可能影响上线时间。
等代码全部完成后再处理这些事项,很容易让项目在最后阶段停住。
第八步:把部署和验收当成独立阶段
发布包、服务器环境、数据库、对象存储、权限、版本、健康检查、人工功能验收和回滚需要单独规划。
部署成功只代表代码进入了服务器。用户能够完成真实行为,才代表产品进入可用状态。
走到公网之后
两个多月里,我花了很多时间处理那些外人看不到的细节。
一条背景接缝可能需要重新拆图,一次上传失败可能要查完整条请求链,一次看似简单的部署可能因为环境检查重新设计脚本。很多晚上结束时,页面和早上相比只变化了一点,底下的系统却已经换了一套更稳定的逻辑。
这段经历最后留下了两样东西。
一个是已经可以通过公网访问的青风铃树屋。
另一个是我逐渐建立起来的方法:先控制范围,再建立行为链;先确认事实,再修改代码;自动测试和人工验收同时存在;每次变更都留证据,每个关键动作都准备回滚。
网站上线以后,真正的运营才刚刚开始。内容需要持续积累,用户反馈需要处理,成本和安全需要观察,功能也会继续变化。
至少从今天开始,这些工作已经有了一个真实的落脚点。