2026 全栈博客开发实战：从十年博客迁移到一套自研内容系统

在 AI 正在深刻重塑开发范式的今天，我这套完全自研的全栈博客，正式完成开发并上线。

很多人会问：现成的博客系统已经足够成熟，为什么还要自己从零搭建一套？

原因很简单：这次我想做的，已经不只是一个“能写文章的网站”，而是一套真正属于自己的内容系统。它既是我记录技术、验证方案、沉淀经验的长期载体，也是我在 AI 时代持续进行全栈实践的一块技术试验田。

对我来说，博客从来不只是输出内容的工具。过去十年，它一直伴随着我的技术成长：从最初依赖开源系统和模板修改，到今天能够独立完成前后端设计、后端实现和部署上线。某种意义上，这次自研博客的完成，不只是一次项目交付，更像是对过去十年技术积累的一次阶段性总结。

从现在开始，这里会更专注于三个方向：AI 编程实践、MCP 与 Agent 相关探索，以及全栈开发在 AI 时代的演进方式。除了关注 Copilot、Cursor、Claude Code、通义灵码这类已经广泛进入开发流程的工具，我也会持续跟进 OpenClaw、龙虾等近期热度很高的新工具，重点记录它们在真实项目场景中的表现，而不只是停留在概念讨论和短期热度上。

一、十年博客演进：从开源系统到自研全栈

2016：第一次搭博客，也是技术起点

2016 年，我用 Emlog 搭建了自己的第一个博客，域名是 52xbc.cn。那时的我几乎从零开始，配置虚拟主机、折腾运行环境、修改模板、发布第一篇文章，每一步都带着初学者特有的生疏和兴奋。

现在回头看，那段经历真正重要的，并不是博客本身，而是它让我第一次意识到：代码不只是语法和教程里的示例，它可以直接用来解决实际问题。也是从那个时候开始，我逐步接触了服务器配置、PHP 修改、CSS 调整，以及最基础的 Web 系统运行逻辑。

同样是在 2016 年，我第一次系统接触 Java。从 Hello World 到面向对象基础，我开始真正理解“编程语言”作为工程工具的意义。那时我也曾经想过：以后能不能用 Java 自己写一套完整的系统？只是当时能力还远远不够，这个念头只能先放在心里。

后来迁移到 Typecho：开始关注“好不好用”

之后我把博客迁移到了 Typecho。相比之前，Typecho 更简洁，也更容易维护。这次迁移让我第一次开始认真思考技术选型背后的问题：一个系统为什么这样设计？什么叫轻量？什么叫可维护？什么叫扩展性？

也是从那时起，我对“博客系统”的理解开始发生变化。它不再只是一个拿来用的现成工具，而是一个可以研究、可以修改、可以逐步接近自己需求的系统。对 PHP 的理解，也从“会安装、会配置”慢慢走向“看得懂、改得动”。

2019：域名固定下来，博客变成长期技术试验场

2019 年，我启用了 songzixian.com，并一直使用到今天。随着内容积累和技术视野的变化，博客逐渐从“写点东西的地方”变成了一个更长期的技术试验场。

那几年里，我持续折腾 LNMP 环境、Nginx 配置、数据库优化、站点性能和部署流程。每一次踩坑和修复，都会让我对前端、后端、服务器和运维之间的关系理解得更清楚一点。很多时候，技术成长并不是来自某门课程或某篇教程，而是来自你一次次把问题真正解决掉。

十年之后，终于从“改系统”走到“写系统”

这十年里，我见过很多博客搭起来又很快荒废，也见过很多站点随着兴趣变化而被放弃。对我来说，博客能够持续保留下来，本身就是一件很有意义的事。

从 2016 到 2026，从 PHP 到 Java，从修改别人的模板到独立实现完整的前后端系统，博客几乎记录了我整个技术成长过程。它不只是一个网站，更像是一条持续可见的技术轨迹。

而这一次，我决定把“想用 Java 自己写一套系统”这件事真正做完。

二、为什么在 2026 年重新做一套博客系统

过去十年，我一直在使用开源博客系统记录技术和生活。但到了 2026 年，我越来越明确一件事：如果博客要继续承担更重要的角色，仅仅依赖现成方案已经不够了。

这不是因为开源系统不好，而是因为我的需求变了。

我希望这个博客具备更强的可控性：

• 我可以完全决定前台展示和后台管理的结构
• 我可以按照自己的方式组织内容模型和功能边界
• 我可以随时针对新需求做扩展，而不用受限于现成系统的设计框架

更重要的是，在 AI 时代，博客对我而言已经不只是“发布文章”的地方，而是一个长期记录技术变革、测试新工具、沉淀实践经验的内容平台。

我不想只是零散地在社交平台上追逐热点，也不想把对 AI 编程、MCP、Agent 和全栈实践的理解分散在不同平台里。我需要一个足够稳定、足够自由、足够可持续维护的空间，用来系统记录这些正在发生的变化。

所以，这次自研博客的目标并不是“重复造轮子”，而是基于过去十年的积累，重新构建一套真正适合自己长期使用的内容系统。

三、这套博客系统的技术实现

这次我选择了自己最熟悉、也最适合长期演进的一套技术方案：

• 前台：Vue 3 + 响应式布局
• 后台：Vue 3 + 现代化组件体系
• 后端：Java + Spring Boot
• 部署：支持一键打包与上线

从工程角度看，这并不是为了追求“技术栈越新越好”，而是为了在开发效率、系统可维护性和后续扩展能力之间取得平衡。

前台部分主要服务于内容展示和阅读体验，需要足够轻量、清晰，并兼顾不同终端的访问效果。后台部分则更关注内容管理、文章维护和系统配置，因此在交互结构和组件化设计上要更稳定。后端部分使用 Java 和 Spring Boot，是因为我希望整个系统具备更明确的分层结构、更好的可维护性，以及后续继续扩展接口、权限、数据管理和服务能力的空间。

对我个人来说，这套系统还有一层很特殊的意义。2016 年那个还在折腾 Java 环境变量、刚刚学会写基础代码的自己，大概很难想象，十年后真的会用 Java 独立完成一整套博客系统。

所以，这次开发的价值不只在于“博客上线了”，更在于它完成了一个拖了很多年的技术愿望。

四、从 AI 工具到 AI 工作流：这三年的变化比想象中更快

如果说自研博客是这次实践的载体，那么 AI 则是推动我重新定义这个博客主题的核心背景。

过去三年，AI 对开发工作的影响几乎是阶段性跃迁的。

2023：AI 足够惊艳，但还更像“增强型工具”

大模型刚出现时，几乎所有开发者都会感到震撼。它能回答问题、生成代码、解释概念，很多过去需要查文档、搜博客、翻论坛才能完成的事情，第一次变得像对话一样直接。

但放到真实项目里，问题也很明显：它缺少完整上下文，不理解系统边界，不掌握项目状态，很多输出看起来“像那么回事”，实际却很难直接落地。那个阶段的 AI 更像一个非常聪明的辅助工具，而不是开发流程的一部分。

2024 到 2025：AI 进入 IDE，焦虑开始扩散

随着 Copilot、Cursor 等工具深入编辑器，AI 开始真正进入日常编码流程。它可以补全代码、生成注释、改写函数、辅助理解项目结构，很多开发者第一次真切感受到：AI 带来的不是“新奇”，而是工作方式的变化。

也正因为如此，焦虑开始迅速蔓延。很多人会问：AI 会不会取代开发者？是不是以后写代码本身都不再重要？

但在真实开发中，很快也会发现另一件事：AI 可以提高局部效率，但架构怎么设计、边界怎么划分、服务怎么拆、需求怎么抽象、风险怎么控制，这些关键问题依然需要人来负责。

2026：Agent 出现后，开发逻辑开始真正改写

到了 2026 年，变化开始进入另一阶段。随着 MCP 协议和 Agent 能力逐步成熟，AI 不再只是“在对话框里回答问题”，而是开始具备理解项目、获取上下文、规划步骤和执行任务的能力。

这意味着，AI 在开发中的角色正在从“工具”升级为“协同者”。

当模型能够读取项目结构、理解文件关系、结合上下文调用工具并完成多步任务时，开发流程本身就不再和过去一样了。很多原本需要开发者手动串联的操作，现在已经可以由 AI 参与甚至主导执行。

这不是简单的效率提升，而是工作流层面的改变。

而且这种变化并不只体现在少数头部产品上。从 Copilot、Cursor 到 Claude Code、通义灵码，再到 OpenClaw、龙虾这类近期热度迅速上升的工具，AI 编程产品的竞争已经不再只是“谁能生成代码”，而是在比拼谁更懂上下文、谁更能融入工作流、谁更接近真正可用的工程协作能力。

五、为什么我依然认为“人”的能力更重要

AI 的能力越来越强，这一点已经没有太多争议。但我始终认为，真正决定上限的，依然是使用它的人。

AI 可以帮你生成代码、整理思路、补全实现，甚至协助完成一部分复杂流程，但它并不能天然替代架构判断、业务理解和边界把控。一个项目应该怎样拆分、什么地方需要灵活、什么地方必须收敛、哪些设计会导致未来维护成本失控，这些问题仍然需要开发者自己做决策。

如果没有过去这些年一点点积累起来的工程经验，没有那些折腾环境、修复问题、重构结构、踩坑回滚的经历，AI 带来的未必是放大，反而可能是更快地产生混乱。

正因为经历过从开源系统到自研系统的过程，我反而更清楚 AI 最适合放在哪个位置：它应该是能力放大器，而不是思考替代品；是效率乘数，而不是工程判断的替身。

六、这个博客接下来会重点写什么

未来一段时间，这个博客会围绕三个方向持续更新。

1. AI 编程工具的实战测试与复盘

包括 Copilot、Cursor、通义灵码、Claude Code、Trae、CodeBuddy，以及最近热度很高的 OpenClaw、龙虾等工具，我都会尽量放到真实项目场景里去测试，而不是只做表面的功能体验。

我更关心的问题是：

• 它们在实际项目里到底能提升多少效率
• 在什么场景下真正好用
• 在什么场景下仍然容易出错
• 哪些任务适合交给 AI
• 哪些关键决策仍然必须由人来把控

从 Copilot、Cursor 到 OpenClaw、龙虾，AI 编程工具的竞争已经不再只是“谁能生成代码”，而是在比拼谁更懂上下文、谁更能融入工作流、谁更接近真正可用的工程协作能力。相比简单地下结论“哪个好用”，我更想记录它们在真实开发中的效果、限制和适用边界。

尤其是像 OpenClaw、龙虾这样讨论度很高的新工具，我会更关注它们在工程上下文理解、多步骤任务执行、IDE 协作体验以及真实项目接入成本上的表现，而不只是看一时的热度。

2. MCP 协议与 Agent 的实践探索

这是我在 2026 年最关注的方向之一。

从协议原理到具体接入，从工具调用到任务编排，从单点能力到多步骤工作流，MCP 和 Agent 正在改变开发工具和工程协作的组织方式。这个方向现在看起来很热，但真正能落地的经验还不算多。

我会把自己做过的接入、实验和踩坑过程尽量完整记录下来，包括：

• MCP 的理解方式
• Agent 在项目中的实际应用模式
• 工作流设计中的关键问题
• 哪些场景适合自动化，哪些不适合
• 真正落地时会遇到什么工程层面的限制

3. 全栈开发与 AI 协同模式的融合

AI 进入开发之后，受影响的不只是“写代码”这件事，而是整个工程流程。

一个问题会越来越值得讨论：当 AI 成为默认协作者之后，前端、后端、测试、部署、运维、文档这些环节的组织方式要不要跟着变化？

这些问题目前并没有标准答案，所以我更希望通过自己的项目逐步验证，包括：

• 架构设计是否需要为 AI 协作做调整
• 测试流程是否要重新定义
• 部署和交付方式是否会发生变化
• 团队协作中的角色边界会不会被重新划分

这些内容，我会尽量基于真实项目，而不是停留在概念讨论上。

七、写这个博客，对我来说到底意味着什么

对很多人来说，博客可能只是一个内容载体；但对我来说，它一直更像一套长期陪伴自己的技术记录系统。

这次重做博客，并不是为了证明“我也能自己写一套系统”，也不是为了追求形式上的独立。真正重要的是，我希望在这个开发范式正在快速变化的阶段，给自己留下一块足够稳定的空间，用来持续记录真实实践，而不是被信息洪流裹挟着只做旁观者。

技术更新会越来越快，工具也会越来越强，但一个开发者真正长期有效的能力，依然是理解问题、抽象问题、拆解问题和组织系统的能力。未来的核心竞争力，不只是写代码的速度，更是你能否在复杂上下文中做出正确判断，以及能否有效调度 AI 为你服务。

所以接下来，我不会刻意追逐空洞的热点，也不会只做泛泛而谈的概念搬运。我更想做的，是把自己在 AI 编程、MCP 协议、Agent 实践、全栈开发和实际落地过程中的代码、问题、方案、复盘和经验，尽量真实地写下来。

一方面，这是在逼自己沉淀，避免“学过就忘、用过即过”；另一方面，我也希望这些记录能对后来者有一点实际价值。哪怕只是帮别人少踩一个坑、少走一段弯路，这些文章就已经足够有意义。

八、奔赴下一个十年

从 2016 到 2026，从 52xbc.cn 到 songzixian.com，从基于开源系统搭博客，到在春节期间闭门完成一套自研全栈系统；从最初手写代码、查资料、改模板，到今天开始系统性地与 AI 协同开发，这十年的很多成长节点，博客都参与其中。

如果说这套新博客有什么特别的意义，那大概就是：它把过去十年的积累，真正转化成了一套可以继续向前生长的系统。

走过十年，初心没变。 接下来，我会继续在这里记录技术、验证想法、沉淀经验，也带着这份持续折腾的习惯，奔赴下一个十年。