企业官网建设流程全解析

做博客网站这件事，过去一直有点“杀鸡用牛刀”的意思。服务器、数据库、后台管理、域名解析，这些跟写作本身毫无关系的杂活堆在一起，往往就把真正想发内容的人劝退了。现在用Bolt.new，这个流程被大幅简化了。Bolt.new是StackBlitz推出的AI编程工具，它在浏览器里直接运行完整的前端开发环境，你只需要用对话描述需求，它就能把项目代码生成出来，并在预览窗口里实时运行给你看。这篇内容，我用它从头到尾开发了一个博客网站——文章列表、详情页、标签筛选、响应式样式、Markdown内容读取，一直到部署上线——把完整过程和踩过的坑都整理在这里。刚接触Bolt.new的读者可以把它当入门指南，已经用过但觉得生成结果不好控制的同学，建议重点看提示词和排查技巧这两章。

1 为什么我会把Bolt.new当作博客开发的主力工具

1.1 它和低代码平台、传统脚手架的本质差异

很多人第一次打开Bolt.new，会把它和那些“拖拽生成网站”的低代码平台搞混。实际用下来，两者的底层逻辑是完全不一样的。低代码平台给你的是一个个封装好的组件，你能改的只是属性面板上那几个选项，换了平台等于重新学一套系统。Bolt.new则直接生成源代码——React、Vue、Vite项目，所有文件都是真实可编辑的。你用一段时间后把代码下载下来，它就是一套标准的前端工程，交给谁都能维护。

这一点对博客网站来说非常重要。博客的内容是长期积累的资产，你肯定不希望五年前写的文章因为某个平台停止运营而全部蒸发。Bolt.new生成的是标准代码，哪天不想用这个工具了，代码还能继续跑。我用它做博客项目时，一直是抱着“随时可以脱手”的心态来验收代码质量的，而不是把希望都寄托在平台本身。

1.2 WebContainers带来的开发体验变化

Bolt.new背后是StackBlitz的WebContainers技术，它让Node.js环境直接在浏览器标签页里运行。听起来很玄乎，实际体验就是：你不需要在本地装Node、配npm、处理各种依赖冲突，打开网页就开始开发，依赖安装和项目启动都在浏览器里自动完成。

我最早接触这个技术的时候持怀疑态度，觉得浏览器里跑Node肯定各种限制。用了Bolt.new做博客项目之后，发现自己担心过头了。生成完第一版代码，预览窗口里就是一个已经启动完毕、可以点击跳转的真实网站，不是一张截图、不是一段伪代码，而是真正在ESM模块环境里跑起来的应用。

这种体验对博客开发最大的价值，是让“边聊需求边改页面”这个流程变得极其顺畅。你看到一个页面布局，不满意就直接说“把卡片间距调大一点”“标题字号改成36”，十几秒后预览窗口就变了。过去改一次UI要启动本地服务、切编辑器、调样式表，现在全程在对话里完成。迭代速度上去了，做设计的胆子也就大了，敢试各种布局方案，反正改起来成本低。

1.3 博客网站为什么特别适合用Bolt.new来做

我也用Bolt.new做过一些更复杂的项目，比如带用户登录的SaaS应用、连接第三方API的数据看板。这些项目Bolt.new也能做，但随着功能叠加，AI在实际业务逻辑上的错误率会上升，排查成本也跟着增加。博客网站恰好是那种在最合适区域里的项目：

• 页面结构高度固定：首页、文章列表、文章详情、标签页，翻来覆去就这几个模板。
• 内容与展示天然分离：文章用Markdown文件或CMS管理，前端只负责渲染。
• 交互复杂度低：以读为主，少量导航和筛选，不需要复杂的实时同步逻辑。
• 项目体积可控：即使加一些扩展功能，单页应用也能承载，不需要一开始就上微服务。

这些特点让博客网站成了Bolt.new这种AI生成式开发工具的最佳受众。需求边界清晰，AI的生成结果就不容易跑偏；代码规模适中，即使偶尔需要手动修复也不会太痛苦。如果你想认真评估Bolt.new的能力，拿博客网站当第一个练手项目，是非常明智的选择。

2 从空白到骨架：用第一段提示词搭起博客框架

2.1 第一个提示词怎么写

Bolt.new的使用模式是给提示词、看生成结果、继续给提示词。第一段提示词尤其关键，因为它决定了项目的骨架，后面所有迭代都是在这个骨架上叠加的。我写博客项目的第一个提示词，一般会一次性说清四件事：技术栈、页面结构、样式方向、内容管理方式。

这是我实际用过的第一段提示词，直接拿来做示例：

请帮我创建一个基于React + Vite的博客网站。使用Markdown格式作为文章内容来源，文章放在public/posts目录下。需要支持首页展示文章列表、文章详情页面、按标签筛选文章。页面整体风格简洁干净，以阅读体验为主，桌面端左侧为主内容区，右侧边栏放最近文章和标签云。配色使用白底、深灰文字、一个强调色，字体偏现代无衬线。移动端需要响应式适配，导航栏可以收起。

这段提示词覆盖了项目的基础方向，同时没有过度限制细节。比如我没有指定用哪一套UI组件库，是因为博客这种偏内容的项目，Tailwind CSS或纯CSS就能搞定，坚持用某个组件库反而会让页面风格千篇一律。我也没规定具体要哪些依赖，这些交给Bolt.new自己判断，它会根据你提到的“React + Vite + Markdown”挑选必要的库。

2.2 生成完了别急着加需求，先做一次全面检查

第一版生成出来之后，我给自己定了一条规矩：前五分钟不做任何新需求，只做检查。在预览窗口里把整个站点点一遍，看有没有明显问题。

对于博客网站，我重点关注这几个点：

• 首页能不能正常列出文章，文章列表的标题、日期、摘要是否完整显示。
• 点击任意一篇文章，能否进入详情页，Markdown正文能否正确渲染。
• 标签筛选功能是否可用，点击标签后是否只显示对应文章。
• 页面在窄屏下是否变形，导航栏和边栏是否正常收起。
• 控制台有没有报错，特别是请求404或者依赖加载失败。

这一步很多人会跳过，原因是“AI生成的，应该没问题吧”。实际上AI生成代码是一种概率行为，偶尔会有小瑕疵。特别常见的现象是：文章文件里放了中文字符，某些库的编码处理上出了问题，标题乱码了——这种问题等到后面开发时再回头排查，会浪费更多时间。

2.3 迭代的节奏：一次只修改一个模块

检查完基础骨架没问题，接下来就是按功能迭代。这个阶段的坑不在技术难度，而在需求管理。很多人用Bolt.new的体验差，是因为他们一次性丢给它太多修改要求：“把首页改成双栏布局、加一个深色模式、顺便把Logo换掉、文章卡片加个封面图”。结果AI一顿操作后，改了A模块却把B模块弄崩了。

我的习惯是一条消息只说一个修改目标。想改布局，就先说“首页改成左右双栏，左边文章列表、右边边栏”；确认效果没问题后，再发下一条“右侧边栏增加最近文章模块”。这样做的好处是出了问题你能准确定位是哪一步引入的，也让AI在每一轮对话中保持清晰的上下文。Bolt.new虽然能记住多轮会话，但模糊的需求堆叠会让它的理解出现偏差。

3 博客网站三个核心模块的技术拆解

3.1 数据层：Markdown文件如何读取和渲染

用Bolt.new搭建博客，最省事的内容管理方式就是Markdown文件。原因很简单：你不需要做后台，不需要数据库，文章就是一个带格式的文本文件，扔到指定目录里就能被网站读取。写完一篇新文章，只要把文件放进posts目录，前端列表会自动更新。

实际操作中，第一版生成出来的代码未必直接就是按Markdown思路走的，可能只是写死了一组示例数据。需要你通过提示词让它把数据层接上。下面是我在Bolt.new里用过的一套技术组合：

• gray-matter：解析Markdown文件头部的frontmatter，也就是标题、日期、标签这些元信息。
• react-markdown或marked：把Markdown语法渲染成HTML。
• import.meta.glob：Vite内置的批量导入方法，用来一次性读取所有Markdown文件。

比如读取文章列表可以这么写：

const modules = import.meta.glob('../posts/*.md', { eager: true }) const posts = Object.entries(modules).map(([path, module]) => { return { path, ...module.frontmatter, content: module.html } })

这里有个细节值得注意：import.meta.glob的路径需要用相对路径，并且不能使用动态变量，这是Vite的静态分析限制。很多人在这一步卡住，把路径写成了变量形式，结果运行时报错。遇到这种情况，直接把写法改成字面量的glob模式就能解决。

Markdown渲染还有一个安全问题必须提一下。如果你用了marked这类直接输出HTML的库，文章内容里如果夹带了<script>标签或者危险链接，浏览器会直接执行。博客网站如果允许别人投稿，这就是一个很大的安全漏洞。我的做法是默认使用react-markdown，它内部做了HTML白名单过滤；如果实在要用marked，至少要把breaks选项关掉，并且在渲染前对dangerous HTML做一次清理。

3.2 展示层：列表页与详情页的设计边界

博客网站的展示层看起来简单，但有两个边界问题需要正面处理。

第一个是列表页显示哪些信息。很多AI生成的第一版列表会把整篇文章全文塞进卡片里，页面瞬间变得非常长。正确做法是列表页只显示标题、发布日期、摘要和标签，摘要可以手动写在frontmatter里，也可以自动截取正文的前若干字。我在提示词里会明确说“摘要从正文前200字截取，不能全文展开”，这样生成出来的列表页节奏感就是对的。

第二个是详情页的排版边界。博客的核心审美在文章排版上。AI默认生成的正文样式往往比较薄弱，字间距、行高、标题层级都处理得不够讲究。我的做法是单独给文章正文区域写一段CSS：

article.post-content { max-width: 720px; margin: 0 auto; line-height: 1.85; font-size: 17px; letter-spacing: 0.01em; } article.post-content h2 { font-size: 1.5em; margin-top: 2em; margin-bottom: 0.8em; border-left: 4px solid var(--accent-color); padding-left: 0.6em; } article.post-content pre { background: #f6f8fa; border-radius: 8px; padding: 16px; overflow-x: auto; }

给正文设置一个最大宽度是有讲究的。太宽的行，读者视线来回移动的长度会变大，阅读很容易疲劳；700到750像素是公认的舒适阅读宽度。这个细节就算你不懂设计，只要按这个数字设置，出来的博客页面阅读体验都不会差。

3.3 增强功能：标签筛选、文章推荐、移动端适配

骨架搭好、数据层打通后，博客网站基本上已经能用了。接下来的增强功能，我的建议是保持克制。标签筛选是值得做的，这也是博客内容组织的常用方式；文章推荐这种功能可以等文章数量多起来之后再考虑；移动端适配则是必须在第一步就要做好的，因为现在很多流量都来自手机浏览器。

标签筛选的实现不复杂，核心就是拿到所有文章后，按文章frontmatter里的tags字段做过滤。我让Bolt.new生成的是这样一套逻辑：页面顶部有一排标签按钮，点击某个标签后，文章列表只展示带该标签的文章，标签按钮本身高亮显示当前筛选状态。初次生成时，AI可能会把筛选逻辑做成一次路由跳转，即从/跳到/tags/xxx页面。这种实现方式也不算错，但用户体验会显得割裂。我更倾向单页内完成状态的切换，在提示词里补一句“点击标签后在当前页面直接筛选，不要跳转路由”就行了。

文章推荐功能的模型很简单：取出当前文章的标签集合，与其他文章计算标签重叠数，按分数排序展示前三篇。如果你对这部分逻辑细节不确定，可以让Bolt.new先生成一个基本版本，再逐步调优。我实际测试下来，Bolt.new对这种“计算相似度并排序”的需求理解得比较准确，生成出来的代码基本可以直接用。

4 在Bolt.new里“指挥”AI的具体技巧

4.1 说清“不想要什么”，比说清“想要什么”更重要

用Bolt.new一段时间之后，我总结出一个反直觉的经验：提示词里最重要的往往是那些否定约束。AI对积极描述的响应通常很积极，但容易用力过猛，把不该加的样式、不该有的库、不该做的交互都给你加上。

举个例子，你说“做一个简洁的博客首页”，它可能给你塞进来一个自动轮播的Banner、三块特性图标展示、一个新闻简报订阅表单。这些东西不是不能用，但做博客的初衷通常是内容优先。我后来在提示词里都会补一句：“不要Banner轮播，不要弹窗，不添加任何动画特效；页面以文章列表为主体，不使用任何外部字体库和图标库。”

这段否定约束的价值，是在项目早期拦住AI那些“顺手发挥”的手笔。删改总比从头重来轻松。

4.2 一次调整的范围越小，生成结果越稳定

Bolt.new的底层模型在处理多轮对话时，虽然能记住上下文，但如果一条消息里塞了太多互相牵连的改动，它的处理结果会呈现出“局部正确、全局崩塌”的状态。最常见的翻车现场是：你同时改了导航栏和文章列表的布局，结果AI把两者之间的间距属性串了，整个页面的排版变得奇怪。

我的操作节奏是每次只发一条指令，一条指令只针对一个模块。改完，等预览窗口更新，看一下效果，有偏差就再补一条描述，直到满意再看下一个模块。把这套流程走下来，Bolt.new的成功率会明显提高。

我一般把迭代会话拆成几个循环：先做页面结构的迭代，再做样式细节的迭代，然后做数据层的迭代，最后做功能模块的增补。混着来的话，AI在样式和逻辑之间频繁切换，错误率会指数级上升。

4.3 混合模式：AI生成加手动修复才是最省时间的方式

很多人误以为用了Bolt.new就不需要自己写代码了，这是一个很大的误解。Bolt.new的价值在于把大量重复性的样板代码、样式编写、组件搭建工作揽下来，但碰到精细调整时，直接在源码上动手往往比来回对话更快。

我在Bolt.new编辑器里会直接修改生成的代码，改完看预览更新。比如调整一个间距、加一个边框圆角、修改某个文案，这些操作敲键盘比陈述需求更直接。当手动改动的范围越来越大时，我会反过来把修改后的状态作为上下文，告诉Bolt.new“现在页面整体风格是某种状态，从这边再继续生成XXX功能”。

这种混合模式，等于让AI承担大头工作，把人类的时间集中在需要决策和判断的地方。用Bolt.new效率最高的状态，不是全程对话、自己一行代码都不碰；而是自己把关键技术节点把控住，把脏活累活交给AI。

5 从Bolt.new到正式上线：博客部署的完整链路

5.1 导出代码的几种方式

博客开发完毕，需要在互联网上让其他人访问。Bolt.new提供了几种导出路径，我的建议是按需选择。

最直接的方式是在Bolt的部署面板里直接发布，它会给你一个由Bolt托管的临时域名。这种方式适合快速预览和分享，我不建议直接作为正式博客的唯一入口，因为项目更新控制不够灵活。

更推荐的做法是把项目同步到GitHub仓库。在Bolt中登录之后可以让它创建一个公开或私有的仓库，把生成的代码推送上去。之后你就在GitHub上有了一份完整的、可版本管理的代码，后续所有修改都能通过提交记录来追踪。从GitHub出发再去接部署平台，是一个标准的工作流。

还有一种是直接下载源代码包。如果你只是想把代码拿回来，在本地继续开发或者迁移到自己的服务器，下载源码包最干净。下载下来的代码就是我们前面提到的标准Vite工程，你在本地跑npm install和npm run dev就能完全复现。这套所写即所得的过程在Bolt.new里已经验证过，所以迁移到本地通常也会比较顺利。

5.2 部署平台怎么选

博客网站是静态站点，部署方式非常灵活。我自己试过几个平台，各有特点，整理成一个表格给大家参考：

我的习惯是博客项目无脑选Vercel。它支持每次推送GitHub代码就自动构建和部署，还能自动申请HTTPS证书，域名绑定操作也在控制台里点几下就能完成。如果你对国内访问速度更在意，可以把Cloudflare Pages作为备选。上面这几项配置都在Bolt控制台或部署平台本身就能完成，不需要特殊技能。

5.3 域名、HTTPS与SEO的入门配置

部署平台给你分配的默认域名通常是xxx.vercel.app这样的子域名。正式博客我建议绑定自己的域名，成本也就每年几十块。在域名服务商处把DNS解析指向Vercel指定的域名，然后在Vercel项目设置里填入你的域名，平台会自动帮你申请Let‘s Encrypt证书并开启HTTPS。这个过程现在基本是零门槛了，不需要自己维护证书文件。

SEO这块，博客网站至少要做三件事：

• 首页设置title和description，文章详情页根据frontmatter动态生成这些信息。
• 生成sitemap.xml和robots.txt，帮助搜索引擎收录文章页。
• 使用语义化HTML，比如article、h1、time标签。这些标签本身就是SEO的一部分，不需要额外插件。

如果你用的是React Vite项目，SEO还有一个坑必须注意：单页应用的内容是JavaScript渲染出来的，搜索引擎的爬虫在渲染JS时的行为不完全一致。博文非常重要的，最好一开始就选择能输出预渲染结果的方案。我的做法是使用vite-plugin-ssg插件，在构建时把每个页面预渲染成静态HTML，这样爬虫拿到的就是完整内容，不会出现收录不到新文章的问题。

6 我在实际过程中踩过的坑

6.1 “页面怎么没更新”：缓存和构建的问题

用Bolt.new开发过程中，最容易让人误判的问题就是改了代码但页面没变化。我遇到过好几次，自己也观察过别人犯同样的错误——先怀疑AI生成错了代码，实际上Bolt的预览窗口在重新构建时是有延迟的，浏览器的缓存也会造成页面旧内容残留。

遇到这种情况，先别急着重新生成。我的排查顺序是：检查代码编辑器里的文件内容是否已经修改，控制台是否在运行构建任务且有没有报错，最后在预览窗口里强制刷新一下。如果这三步都检查完还是旧页面，再考虑是不是缓存或者网络问题。

6.2 样式错乱背后的几个原因

Bolt.new在样式生成上经常会犯两类错误。一类是Tailwind CSS类和原生CSS混用，优先级互相覆盖，导致页面样式不可预期；另一类是样式文件里语义不清的类名，例如container-2、card-final-final。类名重复，但样式函数内部的属性却不一样，造成组件看起来一致但行为不同。

解决这类问题的思路是规范化。我通常会在项目早期就指定一个唯一的主样式方案，要么用Tailwind，要么用原生CSS Modules。然后在每次对话里反复强调这一点，例如“所有样式使用Tailwind原子类，不要使用内联CSS，不要把类名写死”。这样能让Bolt.new在后续生成中更大概率沿用统一风格。

6.3 提示词语义歧义带来的连锁反应

有一次我让Bolt.new“在文章列表卡片上增加一个阅读时间”，它会自动根据字数计算出一个数字展示。听起来没问题，但我发现它把“阅读时间”直接写进frontmatter里，每次新文章都要手动填时间。这不是一个致命问题，但多出一个人工环节，迟早会漏填。

这种语义歧义在AI生成工具里非常常见：你说要什么，它给你的是一个“看起来像是你要的东西”，但它采用的实现路径可能跟你的预期不符。我的修复办法是不断追问一句“数据从哪里来”。在实际操作中，你可以直接把这句加上：比如“阅读时间根据文章正文自动计算，不要写入frontmatter”，就让“自动”计算这样的状态信息变得明确。

这类错误在Bolt.new里改起来成本并不高，加一句说明它就会重新生成对应逻辑。但如果是在项目后期才暴露出来，改动会牵连许多文件，代价比较大。所以我在每一步迭代时，都会在提示词里尽量把“逻辑边界”画清楚。

6.4 项目膨胀了，怎么控制复杂度

博客网站一开始小，后面随着需求增加，很容易变得复杂：加评论系统、加流量统计、加邮件订阅、加SEO插件……Bolt.new的项目规模增长之后，AI生成代码时开始出现忘记上下文、组件重复定义、依赖版本不一致的问题。

我的经验是把博客的复杂度可视化。每次做功能决策前问一个问题：这个功能真的属于一个“博客”，还是属于一个“内容平台”？如果是后者，先别做。做博客网站，克制是一门必修课。等基础功能稳固、文章内容充盈后，再一步步添加扩展功能，心态会更稳健。

写在最后

我实际用Bolt.new做的博客项目，从写第一段提示词到部署上线，大概用了不到一个下午。这个速度在传统开发流程里不敢想象。它从“敲代码”转向了“讲需求”，本质上是把工程能力前置了：代码生成的活儿由AI做了，但架构的判断、细节的验收、迭代的节奏，仍然需要你自己拿主意。

最后再分享一个小技巧。使用Bolt.new时，我的习惯是每完成一个重要功能点，就在对话里总结一句“当前项目的状态是XXX，已完成A和B，下一步准备做C”，然后再发具体需求指令。相当于在关键时刻帮AI做一次记忆整理，能显著减少它在中后期犯糊涂的概率。这个办法对Bolt.new，对几乎所有AI编程工具，都适用。