尔东巾这阵子我把自己的个人博客从头到尾让 AI 重做了一遍，不是套模板那种改，是真的从一个文件夹开始，靠对话把页面结构、样式、交互、部署全部搞定。文章标题里那句“附提示词”不是噱头，我会把这一路用下来的提示词原样贴出来，也会把 AI 掉链子、我替它擦屁股的过程写清楚。如果你也想折腾一个自己的个人博客，又不想被技术选型和代码细节劝退，这篇应该能给你一条能直接走的路径。
先说结论：AI 写代码的速度确实快，但它能不能把活干好，取决于你给它的信息质量。提示词这个东西，不是把需求说华丽，而是把边界说清楚。你越是把上下文、技术倾向、验收标准交代明白，它就越少发挥“自由发挥”的空间。这个道理，放到任何 AI 辅助开发的场景里都成立。
1. 动手前先想明白：AI 能帮你写代码，但没法替你选技术栈
很多人找 AI 做博客，第一步就是甩一句“帮我做个博客”。我试过，AI 确实能噼里啪啦给你生成一堆文件，但这些文件十有八九是"看起来完整"的 demo，真正用起来会发现一堆问题：目录结构混乱、样式互相覆盖、没有移动端适配、前后端耦合得莫名其妙。
核心原因在于，AI 不是不知道怎么做博客，而是不知道你打算怎么运营这个博客。你是打算每周写一篇技术笔记，还是只想放个简历页？你要不要评论功能？要不要统计访问量？服务器你是打算买还是白嫖托管？这些问题你自己没想清楚，AI 就只能按最通用的方案猜，猜出来自然不合身。
1.1 判断标准：什么时候用 AI 写比直接写更划算
我自己有一条相对务实的判断标准：如果一个方案，人工来做需要超过半天，而 AI 来做只需要几轮对话，并且产出质量在可接受范围，那就值得用 AI。
个人博客正好卡在这个区间。它的功能不算复杂，但涉及页面多、细节多，手工从零写一套 HTML/CSS/JS 非常耗时间；如果用现成博客框架又要学配置、挑主题、改模板，一样不轻松。AI 生成静态页面的质量已经足够好，尤其是样式细节，让它一次生成再逐步调整，效率非常高。
不过这里我也要先泼一盆冷水：如果你是完全没接触过前端的小白，我不建议你一上来就让 AI 全自动生成然后直接部署。你至少要懂一点 HTML 的标签、CSS 的选择器、JS 的基础语法，否则 AI 改坏一个地方你压根看不出来。让 AI 帮忙开发的最低门槛，是你得有最基本的代码阅读能力。
1.2 我用的一条选型原则
这次我选的是纯静态方案：HTML + CSS + JavaScript，不引入框架，不做后端。
原因很简单：博客的核心是内容，不是应用。纯静态的好处是部署简单、维护成本低、打开速度快；缺点是不能动态处理数据，但你发文章本来就是固定频率的更新，静态方案完全够用。如果你需要实时搜索、评论、后台管理，再考虑接入第三方服务也不迟，没必要一开始就上一个重后端。
这个方案还有一个好处，就是 AI 生成的代码很容易理解和接管。如果用了框架，AI 生成的组件结构你可能看不懂，遇到 bug 也不知道从哪排查。纯静态文件反正是平铺的，出了问题打开文件就能看。
1.3 给 AI 定“人设”真的有用吗
我在提示词里写过“你是资深前端工程师”，也试过直接说“我的项目是”，整体用下来，定人设有一点用，但主要作用不是让 AI 变得更聪明，而是让它切换语态。当你说“你是资深前端工程师”时，AI 给出的方案会更偏向工程化结构：它会想到文件目录、组件拆分、命名规范这些。
但你要是真以为这句话能带来质的飞跃，那就想多了。真正决定产出质量的是后面的需求描述是否清晰。人设只是氛围，边界和细节才是杀手锏。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 提示词工程实战：从“帮我做个博客”到一套能落地的对话
接下来是重头戏，讲讲提示词具体怎么写。我不会只给一个模板让你抄，我会把一个完整对话是怎么拆成几个阶段的讲清楚。
2.1 第一阶段提示词：先要结构，不要代码
我第一轮对话没让 AI 写任何代码，而是让它给我出方案。这一招非常重要，能避免 AI 一头扎进代码里然后跑偏。
text复制你是我的个人博客项目顾问，同时也是资深前端工程师。
我想搭建一个个人博客，使用纯静态方案，不要后台、不要数据库。
我会把最终文件部署到静态托管平台或自己的云服务器上。
请先不要写代码，先帮我做三件事：
1. 列出这个项目建议的完整文件目录结构；
2. 说明每一类文件（HTML、CSS、JS）分别承担什么职责；
3. 给出实现顺序的建议，从 0 到 1 拆成小步骤。
我确认之后再按步骤生成代码。
实际用下来，这个提示词能非常有效地把 AI 的产出从“一坨代码”变成“一份可讨论的方案”。它会给你目录结构，给你每个文件的职责说明，最重要的——它会排出一个实现顺序，这样你就知道先做哪个文件、后做哪个文件，每一步都能检查。
2.2 第二阶段提示词：按页面拆任务，别让 AI 一口气全包
等方案确认后，我进入具体页面实现。这里有个关键经验：不要让 AI 一次生成整套网站，而是让它一次只做一个页面。原因是 AI 在长对话中后期容易出现上下文丢失，做着做着忘了前面的样式规范；一次只做一个文件，它反而能集中精力。
我用的提示词大概是这个样子：
text复制开始实现首页 index.html。
要求：
1. 顶部导航栏，包含“首页 / 文章 / 关于”三个入口；
2. hero 区域，展示博客名称和一句话简介；
3. 最新文章列表，每篇显示标题、日期、摘要；
4. 页面底部放版权信息；
5. 样式统一放到 css/style.css，通过外链引入；
6. 配色不要超过三种，正文用深灰色，背景用米白色；
7. 请用语义化标签，header / main / section / footer。
生成后先告诉我文件结构和需要补充的素材，再给完整代码。
注意这里面的几个关键点：外链样式、配色限制、语义化标签。这些都是从项目全局角度给的约束，能避免 AI 把样式写进内联、或者生成一堆与整体风格冲突的临时 CSS。语义化标签则是对 SEO 和后续维护友好的基础。包括 CSS 类名，我建议你提前跟 AI 约法三章，比如"类名使用 kebab-case，比如 blog-card，不要用驼峰"，不然你后期改样式会疯掉。
2.3 提示词常见错误：太宽泛、没边界、不验收
根据我这次的经验，提示词翻车通常有几个原因。
一是太笼统。你问“怎么做好看”，AI 只能给你通用答案；你说“正文区域最大宽度 720px，行高 1.8，字体用系统中文字体栈”，它就非常明确你要什么效果。
二是没边界。比如“做一个文章列表”，AI 可能自己做主塞了分页器、标签筛选、侧边栏；如果你只想要一个简单列表，必须写明“不要分页，不要侧边栏，不要标签”。AI 在信息缺失时一定会发挥想象力，但你想要的其实是不发挥。
三是不验收。很多人拿到 AI 给的代码，看了一遍觉得没问题就跑了，结果一部署傻眼。正确做法是每生成一个页面，先让 AI 自己检查一遍，再让你检查一遍，两个环节都不能省。我第二阶段的提示词里其实就隐含了这个流程，生成后必须附带“说明文件和需要的素材”，这就是让它自己先过一遍脑子。
2.4 一个长提示词拆成多轮对话，胜过一个超级模板
我见过有些人收藏那种几千字的“万能提示词模板”，什么角色、背景、技能、约束、输出格式全部塞进去，看着很专业。但实际用起来，AI 往往会在生成到一半时开始忘记前面某条要求，尤其是当你在一轮对话里塞了太多目标时。
我的习惯是宁可多开几轮，也不要把它压缩成一个巨型提示词。
第一轮：确认技术栈和目录结构
第二轮：生成首页
第三轮：生成文章列表页和详情页
第四轮：统一全局样式和导航
第五轮：细节打磨和移动端适配
每轮只要一个核心任务，AI 的输出质量会明显稳定得多。这也符合实际项目管理里的拆解逻辑——把一个大目标分解成可独立验证的小目标，每个目标完成后检查、确认、再进入下一步。这个思路面对 AI 和面对人类同事都说得通。
3. AI 编码实录：它写得很快，出问题的地方也很有代表性
说完了方法论，来点真实的。这次做博客，AI 大概帮我生成了十几个文件，从页面结构到交互逻辑都有。整体体验是：速度快、骨架完整、但细节粗糙，尤其在某些特定场景下特别容易翻车。
3.1 四个最典型的翻车现场
第一个是移动端溢出。AI 生成的首页在电脑浏览器里看起来很正常，一放到手机尺寸就出现横向滚动条。原因是一个 flex 容器里的子元素没有设置最小宽度，内容被硬塞进容器后撑破了布局。这个 bug 不复杂，但如果你不了解 flex 布局的机制，又恰好没在手机上测试，就会一直带着这个问题上线。
第二个是样式冲突。AI 在一个页面里写了一类按钮样式，在另一个页面又写了不同的按钮样式，两套 CSS 写进了同一个文件里，后者覆盖前者，导致按钮在不同页面长相反。这种问题根源在于我前期没明确告诉它“全局样式统一管理”，它逐页面生成时就按局部逻辑处理了。
第三个是过度设计。我只是让它给文章摘要加一个“阅读更多”的链接，它居然生成了一段 JavaScript 来做点击展开动画。功能没毛病，但没必要，这些代码后期都是维护负担。AI 对“加需求”的克制能力几乎为零，它总是有什么给什么。
第四个是假完成。它会说“已完成全部功能”，实际上有些按钮只是写了占位符，或者干脆没有绑定事件。这是 AI 生成的代码最危险的地方：表面上结构齐全，实际上没有跑通。我遇到过点“关于”按钮无响应的情况，查了才发现它根本没在导航栏里配置关于页的路由链接。
3.2 我是怎么让 AI 自己改的
遇到问题不要急着手动改，我的做法是带上上下文重新问 AI。这里的关键是给 AI 足够的信息再让它动手，只丢一句“移动端样式崩了”，它只能在原地打转。
text复制现在 index.html 在移动端出现了横向溢出，我做了简单排查：
- 页面主体是一个 flex 容器，里面有两个 section；
- 其中一个 section 里有很长的代码块，没有设置 overflow-x: auto；
- 我怀疑是 flex 子项默认 min-width: auto 导致的。
请帮我：
1. 在 css/style.css 里给对应 flex 子项加上 min-width: 0；
2. 给代码块容器加上 overflow-x: auto；
3. 顺便检查其他页面有没有同样的隐患，一起修复。
这种提示词的方式，效果非常明显。你相当于告诉 AI 问题在哪、原因可能是什么、你希望它怎么处理，它就能精准地修改，而不是重写整个文件。而且我要求它在修复后检查其他页面，等于让它全局排查一遍，把同类隐患一次清掉。
3.3 让它处理“某一个具体问题”，比你重述整个项目更靠谱
这是我这趟下来体会最深的一点。很多人在 AI 改代码时习惯把最开始的需求重新贴一遍，但 AI 并没有真正记住整个项目的细节，你贴的越长，它改动时越容易手抖。
正确姿势是把问题限定在一个明确范围内：文件名、具体行号、问题现象、期望结果。比如：
text复制请打开 css/style.css 中 .post-content h2 的样式，给它的 margin-top 从 32px 改为 48px，并把下边框颜色改成和主题色一致的 #cc7b2d。
改动明确到这个程度，AI 基本不会出错。我也拿它来对付一类实际情况——当你需要翻遍全站改一个全局命名，人工找十几个文件很远，AI 一次性处理却很轻松。比如我统一改导航栏 active 状态的类名，就是让 AI 在所有 HTML 文件里同步更新的，三步到位。
4. 部署上线：从本地能看，到域名能访问，每一步都有坑
代码写得差不多了，接下来是部署。这是个人博客项目里最劝退新手的一环，但实际上步骤并不复杂，只要掌握流程，很快就能跑通。
4.1 我推荐的部署链路
这次我用了 Git 加托管平台的方案，整个流程可以概括为：本地构建、git 推送、托管平台自动拉取、绑定域名。第一步和第二步在终端里操作，最后一步在托管平台网页后台完成。
本地构建这一步，需要根据你用的方案来。如果是纯静态页面，我在本地用一个极简的本地服务预览：
bash复制cd my-blog
python3 -m http.server 8080
然后浏览器访问 http://localhost:8080 就能看到页面。这样预览的好处是能模拟真实服务器环境，尤其是验证资源路径是否正确。
验证没问题后，初始化 Git 仓库并推送到远程：
bash复制git init
git add .
git commit -m "init blog"
git branch -M main
git remote add origin https://github.com/你的用户名/my-blog.git
git push -u origin main
推送完成之后，去托管平台新建项目，选择从 Git 仓库导入，它就会自动构建并生成一个默认域名，一般类似 xxx.pages.dev 这种。先用这个域名访问确认线上没问题，再绑定你自己的域名。
4.2 最容易卡住的三个点
部署环节新手最常卡在三个地方，我挨个说。
第一个是资源路径。用托管平台的默认域名时，如果你之前的 HTML 里写的是相对路径，比如 ./style.css，大多数情况下没问题。但如果你曾把资源路径写成 style.css 或绝对路径，一旦页面不是放在根目录，样式和脚本就会全部失效。所以上线之前，把所有资源引用统一改成相对路径比较稳妥。
第二个是域名解析。绑定自定义域名时，需要在域名服务商那边添加一条 CNAME 记录，把子域名解析到托管平台给你的地址。这个动作完成后不是立刻生效，通常要几分钟到几十分钟，如果你刚添加完就访问发现打不开，别慌，刷新或者等一等，也可以先 ping 一下看解析有没有生效。
第三个是缓存。改完代码后重新推送，托管平台会自动重新构建，但很多浏览器因为缓存旧文件，页面看起来像是没更新。这时候强制刷新一下页面，或者过几分钟再看，通常就对了。
4.3 上线前用 AI 补一遍收尾检查
还有一件事我强烈建议：在上线前，让 AI 给整个站点做一次“上线审计”。我当时的提示词是这样的：
text复制请检查这个个人博客项目，以准备上线发布为目标。
逐项确认以下内容，发现问题请直接给出修复方案：
1. HTML 文件的 meta 标签，包括 title、description、favicon；
2. 图片有没有加 alt 属性；
3. CSS 样式里有没有明显的冗余或错误；
4. 有没有生成 sitemap.xml 和 robots.txt；
5. 404 页面是否存在，没有的话帮我创建一个；
6. 外部链接是否都加了 rel="noopener noreferrer"。
这个提示词跑一遍下来，你会收获一堆必须处理的小修补。图省事跳过这些也没人拦你，但搜索引擎收录速度和页面在社交平台分享时的展示效果会明显受影响，做博客的人大概率不希望自己辛辛苦苦写的文章连个标题卡片都不显示。
5. 博客建好之后，内容工作流才是真正要经营的部分
博客上线只是开始。真正有价值的部分是持续产出内容，而这块同样可以让 AI 参与进来，但要把握好边界。
5.1 我的写作流程：AI 负责想和改，我负责定和写
不会直接让 AI 替我写整篇文章，原因很简单：AI 写出来的东西再流畅，它没有我的经历和判断，读起来总觉得有点“浮”。我用的方式是把 AI 当作编辑和灵感来源。
比如我写一篇技术踩坑记录，流程是这样的：
- 我先记下踩坑的经过和关键思考，哪怕只是零散的几句话；
- 让 AI 帮我列一个文章大纲，把我想表达的要点组织成逻辑顺序；
- 我自己按照大纲落笔，用自己的话写完整篇；
- 写完让 AI 帮我检查错别字、语气、段落衔接；
- 最后让 AI 给文章生成标题和摘要，我再挑一个顺眼的改一改。
这个流程的好处是创作的核心——观点和表达——仍然在我这里，AI 做的是组织和润色的活。对博客来说，真实经历和真实的表达，才是读者愿意来读的根本原因；如果第一篇到最后一篇全是 AI 代写，你的博客跟一个自动生成的垃圾站有什么区别。
5.2 我整理的一页口令库
现在我电脑里存着一个文档，专门记录每次用得顺手的提示词。不夸张地说，这比存各种收藏夹里的教程实用多了。挑几个我常用的，直接抄走即可。
用于生成文章摘要的：
text复制这是我写的一篇文章的正文，请你帮我写一个 80 到 120 字的摘要，要求：不要出现“本文将”这类套话，用一段自然的话把文章核心说清楚，适合放在博客列表页的卡片上。
用于生成文章 SEO 标题的：
text复制基于以下正文，给我 3 个博客标题候选。要求：突出核心价值，有具体信息量，不能用吸引眼球的夸张标题，长度控制在 20 个汉字以内。
用于封面图的：
text复制我要写一篇文章，主题是 XXX。请你帮我描述一个适合做封面图的场景，要求构图简洁、有层次感，适合作为博客文章的头图。描述时包含光线、色调、主要元素和构图方式。
用于修改文章语气的：
text复制请把下面这段内容改得更口语化、更像一个开发者在博客里分享经验，少用书面语，不要加客套话。保留原文的技术术语和观点。只输出修改后的内容，不要解释。
这些提示词的目标都特别小，效果也特别稳定。
5.3 几点真实体会
这次带着 AI 把个人博客从头做了一遍，我最大的感受是：提示词的本质，不是魔法，而是沟通能力。你越清楚自己要什么，AI 就越能给你想要的。很多人在 AI 面前支支吾吾，得到一个四不像的结果，然后说 AI 不行，其实问题多半出在需求没讲清楚。
另一个体会是：AI 可以帮你把技术门槛踩平，但内容创作的坎，还是要自己跨。博客这种载体，技术只是底子，真正留住读者的永远是你写了什么。所以我现在的建议是，把折腾技术的精力留给第一次搭建，之后尽量把时间花在阅读、实践和记录上。
顺便说一句，我部署完博客后做的第一件事，是写了一篇“第一篇博客”发上去。内容不长，但那天的心情很不一样。你能亲眼看到自己从零搭起来的小站，在互联网上亮起来，那种满足感，确实是 AI 给你的，但也是你自己的。