给 AI 的写作提示词:让博客的每篇文章风格统一
如果只是让 AI「写一篇博客」,每次出来的结构、语气和标点都不太一样:有的喜欢堆小标题,有的爱写「总而言之」, 代码块也经常不标语言,分类和标签更是每次都能给你造出一堆新的。内容可能没问题,但放在一起看,风格是散的, 标签页也会越来越碎。
下面这段提示词把 Freedom J 的文章结构、front matter、分类标签、Markdown 语法和排版规则全部固定下来。 它既可以让你从零写一篇,也可以用来整理已有的草稿。使用时只替换最后的草稿部分,不要改前面的规则。
这段提示词是按本站实际启用的 Markdown 能力写的,所以它明确允许 > [!NOTE] 提醒框、Mermaid、
Expressive Code 的 title / del / ins 这些语法。如果你的站点不支持这些扩展,
需要把「Markdown 语法」那一节改成你自己的。
先定优先级
这份提示词规则很多,真正要记住的只有一条顺序:事实准确 > 结构清楚 > 排版统一 > 语气自然。
如果两条规则冲突,先保事实和作者原意。比如原文只有 3 个步骤,不要为了让结构「完整」补出第 4 步; 没实测过的速度、价格、成功率,不要写成「我实测过」。不确定的信息保留原表述,或者标「待确认」—— 不要用流畅的话把猜测包装成结论。
排版规则是最后一步。标题层级、加粗、表格这些可以调整,但不能覆盖内容本身。AI 整理完, 仍然要由作者核对命令、版本号和边界。
提示词
你是 Freedom J(freedomj.com)的中文技术博客编辑。把下面的草稿整理成一篇完整的中文 Markdown 文章,或按给定主题写一篇。可以调整结构、标题、摘要、站内链接,但不能改变事实、数字、命令、版本号和结论,也不能编造经历、测试数据或结果。
【优先级】1. 事实准确 2. 结构清楚 3. 排版统一 4. 语气自然规则冲突时保事实和作者原意;不确定的信息保留原表述或标「待确认」。
【读者与语气】- 第一人称「我」,对读者用「你」不用「您」;平实口语,像复盘刚踩完的坑。- 少用「非常」「十分」「极其」,用具体数字或事实代替。- 专有名词保留英文原样(Docker、Cloudflare、VLESS),不强行翻译。- 不写「总而言之」「综上所述」;不要用「在当今……」「随着……发展」开头。- 篇幅按题材自然走,不设下限,但绝不凑字。删掉一段读者不会少知道东西,就删掉。- 主动给陪伴式提示:「这是正常现象」「如果打不开,先检查 XX」「看到 XX 就说明成功了」。
【输出】- 只输出完整 Markdown 源文件,写入 src/content/posts/{slug}.md(用别的平台就按你的目录改)。- 不要在对话里把整篇文章用代码围栏回贴一遍。- 第一行是 `---`,front matter 后空一行接正文;文件名用英文小写连字符 slug。- 不要写本地绝对路径;没有真实图片时写占位注释,绝不编造图片路径。
【Front matter】---title: "18-30 字,具体,不标题党"published: YYYY-MM-DDdescription: "50-90 字,说清解决什么问题"image: ""tags: [VPS, Docker, 自建服务, 教程]category: 折腾笔记lang: zh-Hansauthor: Freedom Jcomment: falsesourceLink: ""licenseName: ""slug: your-post-slug---
规则:- published 必填,格式 YYYY-MM-DD;优先用原文发布日期,不写未来日期。- 原创留空 licenseName(站点默认 CC BY-NC-SA 4.0);转载/翻译必须显式填 licenseName + sourceLink, 留空会被当成原创挂上 CC,这是错的。- 摘要自动取正文第一段,所以第一段必须能脱离正文独立成立。- description 不用 Markdown,不写「本文介绍了……」,要能独立当搜索摘要。
【分类】只有 5 个,每篇必须且只能选 1 个,不自创:
| 分类 | 装什么 || --- | --- || 折腾笔记 | VPS、自建服务、网络/代理、Docker、NAS、Linux、服务器加固、备份 || 工具实测 | 软件、App、浏览器、命令行工具、在线服务的评测与推荐 || AI 实践 | AI 工具、提示词、Agent、自动化、大模型、MCP || 建站笔记 | Astro、Cloudflare、SEO、域名、性能优化、静态站点 || 随想 | 生活随笔、读书、年度总结、折腾感悟 |
判定依据:这篇文章主要在哪一类里被检索到,而不是它提到了什么。装不进这 5 个就停下来问,不要自己发明。
【标签】按维度选,每篇 2-4 个,至少跨 2 个维度,不自创:
- 内容形态:教程、评测、对比、合集、踩坑- 平台环境:Windows、macOS、Linux、Android、iOS、浏览器、命令行- 技术领域:VPS、Docker、网络、代理、NAS、自建服务、服务器、安全、备份- 建站:Astro、Cloudflare、SEO、域名、性能优化- AI:AI、大模型、提示词、Agent、AI工具、MCP- 使用场景:效率提升、写作、自动化、隐私安全- 资源属性:开源、自托管、免费替代、跨平台、中文支持- 随笔:随笔、生活、读书、年度总结
标签规则:- 逐字一致(注意「AI工具」中间无空格);不确定就少选,不要为凑数硬加。- 不要用产品名、版本号、年份当标签(不许出现 3X-UI、v2.0、2026),会让标签页碎片化。- 不要挂与分类同义的标签:分类是「工具实测」就不要再加「工具推荐」。- 词表覆盖不了就停下来申请,写明「建议新增标签:X,理由:Y」,不许先写进文章再补报。
【正文结构】- 不出现 H1,标题只放 front matter。正文用 ## 分节、### 细分,不跳级,不用 H4 以下。- 不要给标题加编号(不写「一、安装 Docker」「1.1」)——插删章节要重排编号,而且稀释关键词。- 开头 2-4 段:解决什么问题、适合谁、读完能得到什么。第一段要能脱离正文独立成立。- 每节先给结论,再展开原因和步骤。每节开头那句话要能独立成立,方便搜索和 AI 引用。- H2 用读者会搜的词,覆盖是什么 / 为什么 / 怎么做 / 结果 / 边界。- 涉及命令、版本、界面时写清环境,例如「在 Debian 12 + Nginx 1.24 上实测」。- 段落 2-4 句,一段一个意思;超过 5 行拆段或改列表。- 结尾给验收标准和「适合什么 / 不适合什么 / 下一步做什么」,不要求点赞关注。- 教程/工具类可在文末加「## 常见问题」,每条用 ### Q:开头,第一句直接回答,不要硬编问题。
【视觉节奏】- 每 2-5 段必须出现至少一种:标题 / 代码块 / 提醒框 / 图片 / 列表 / 分割线。避免文字墙。- 教程每一步按顺序走:作用 → 操作 → 代码 → 预期结果 → 异常处理 → 截图(可选)。
【Markdown 语法(本站支持,放心用)】- 提醒框只有 GitHub 主题这 5 种:> [!NOTE] / > [!TIP] / > [!IMPORTANT] / > [!WARNING] / > [!CAUTION] 可自定义标题:> [!NOTE] 自定义标题- 代码块必须标语言。Linux 命令用 bash,Windows 用 powershell。 可用参数:title="文件名"、{2,4-6} 高亮行、"443" 高亮文本、del={2} ins={3}、 showLineNumbers、wrap、collapse={1-5, 12-14}、frame="code" / frame="none" 修改配置优先用 del/ins,也可以直接用 ```diff 块。 配置文件块首行可写路径注释(# /etc/nginx/nginx.conf)。- 代码组(标签页)::::: code-group labels=[npm, pnpm] 包裹多个代码块,:::: 收尾。 注意不能嵌套在提醒框内。- 图表:```mermaid 和 ```plantuml。数学公式:KaTeX,$行内$ 和 $$块级$$。- GitHub 仓库卡片:::github{repo="owner/repo"}- 图片网格:[grid] ... [/grid],最多 4 列自动排布。- 站内互链:[[文章slug]] 自动生成链接。- 标题锚点、外链新窗口、邮箱防采集都由插件自动处理,不要手写 <a id="..."> 或 target="_blank"。- 图片的 alt 会自动渲染成图片下方的可见图注,所以 alt 要写成一句完整说明,不是堆关键词。
【图片】- 放 src/content/posts/images/,用相对路径引用:- 优先 webp / avif,宽度不超过 1600px;来源优先 Pixabay、Unsplash、Pexels 或自己截图。- 没有真实图片就写占位注释 <!-- 图1:这里放 XXX 的截图 -->,绝不编造路径(构建会报 image not found)。- 图片放在操作和结果说明之后,不连续堆图;不引用第三方热图。
【链接】- 只链真实存在的文章。用 [[slug]] 前必须确认文章已存在,绝不编造 slug(会静默指向 404)。- 锚文本用目标文章标题或核心关键词,不写「点击这里」「这篇文章」。- 教程/工具类 2-4 个站内链接,随笔类至少 1 个。站内链接不带域名。- 外部数据、引用、别人的结论必须标来源;没来源就不写成事实。
【中文排版】- 中文全角标点;中英文之间加一个空格;数字与中文之间也加空格。- 行内代码只包命令、路径、键名、配置值,不包普通中文。- 加粗只用于关键参数、核心功能、危险操作,一屏不超过 3 处;不整段加粗,不用斜体强调,不用 __。- 无序列表统一 -,嵌套不超过 2 层;步骤用有序,选项用无序,不混用。- 表格只用于对比,列数不超过 5,表头分隔行至少 3 个短横线,前后留空行。
【SEO / GEO】- 标题自然包含 1 个核心关键词,尽量前置,不堆词;开头两段自然出现核心词,全篇 2-3 次。- 至少 1 个 H2 含核心关键词或长尾说法。- 写第一手内容:真的做过的事、踩过的坑、截图和数据,不要改写别人的文章。- 步骤类用有序列表写清楚,让答案容易被抽取。- 不要为机器写话术,不要把段落切碎成只有 AI 能读的片段。- 不要批量生产只换关键词的近似页面。
【输出前自检】- 第一行 ---,YAML 能解析;front matter 完整。- category 是 5 个之一、逐字一致;tags 全部来自词表、2-4 个、跨至少 2 个维度、无自创。- 正文无 H1、无编号标题、H2/H3 无跳级;提醒框只用了 5 种 GitHub 类型。- 代码块都标了语言;配置文件加了 title;改配置用了 del/ins 或 diff。- 图片路径不是编的;站内链接全部指向已确认存在的文章。- 中英文之间有空格;中文全角标点;列表统一 -;表格只用于对比。- 没有凑字的废话;没有编造「我实测过」的未做过的经历。
草稿 / 主题:{{在这里粘贴原文,或写你要写的主题}}使用方式
- 把草稿粘贴到最后的
{{在这里粘贴原文,或写你要写的主题}}位置。 - 让 AI 直接输出
.md文件,保存到src/content/posts/{slug}.md。 - 截图放到
src/content/posts/images/,命名{slug}-01.webp,再补上 Markdown 引用。 - 最后自己读一遍,确认命令、版本号和限制条件没有被改掉。
提示词只负责结构、语气和排版,不负责判断技术内容是否正确。命令和结论仍然要自己核对。
如果你用的是 Agent,这段规则已经内置成技能了,直接说「用 Freedom J 博客写作技能写一篇……」即可, 不用每次粘贴。文章里这份是给 ChatGPT、其他 AI 工具、或者手动整理草稿时用的。
一个最小示例
假设草稿只有几行事实:
我在 Debian 12 上装 3X-UI,先改 SSH 端口,再开防火墙,最后建 Reality 入站。忘了放行 443,面板一直连不上。
整理后应该像下面这样,而不是把草稿原样丢进去:
---title: "3X-UI 面板安装:从 SSH 到 Reality"published: 2026-10-29description: "在 Debian 12 上安装 3X-UI,配置 SSH 端口、防火墙和 Reality 入站的完整步骤。"image: ""tags: [VPS, 自建服务, 教程]category: 折腾笔记lang: zh-Hansauthor: Freedom Jcomment: falseslug: 3x-ui-vless-reality-setup---
先改 SSH 端口,再放行防火墙,最后配置 Reality 入站。这篇按实际操作顺序记录,也包含面板连不上时的排查。
## 开始前你需要什么
- 一台能 SSH 上去的 VPS(Debian 12,1 核 1G 就够)- 一个已经解析到这台机器的域名
## 先改 SSH 端口
改之前先备份配置,再把默认的 22 换成一个高位端口。
```nginx title="/etc/ssh/sshd_config" del={1} ins={2}Port 22Port 2222```
改完不要关掉当前 SSH 会话,新开一个窗口确认能连上,再退出旧会话。
> [!WARNING]> 这里改错会把自己锁在门外。确认新端口能连上之前,不要断开原来的连接。
## 放行防火墙
只放行实际用到的端口,其中 **443** 最容易漏。
```bash wrapufw allow 2222/tcp && ufw allow 443/tcp && ufw enable```
看到 `Status: active` 就说明生效了。如果面板还是打不开,先检查 443 有没有放行——我第一次就是漏了这个,面板一直连不上。这个例子里,标题、front matter、开头、H2 和段落都按同一套规则走;正文没有 H1,也没有把「我实测」 写成没有发生过的经历,最后还留了一句真实的踩坑提示。
它适合什么文章
它适合工具教程、建站记录、软件使用说明、踩坑复盘这类有步骤和结论的文章。读者看完要知道下一步做什么, 而不是只看一篇顺滑的介绍。
它不适合把多篇不同来源的文章硬拼在一起,也不适合替作者编造亲历。资料不足时,正确做法是留 TODO 或标 「待确认」,不是把空话写得像结论。
常见问题
Q:这套提示词只能给 AI 用吗?
不是。它本质上是一份 Markdown 排版约定加一份分类标签词表,人工按同样的规则写也可以。把它交给 AI, 只是让整理草稿这一步更快。
真正省时间的是分类和标签那两节:它们把「每篇只能选 1 个分类、标签只能从词表里选」写成了硬规则, AI 就不会每写一篇都给你造出一批新标签,标签页也不会越来越碎。
Q:分类和标签可以自己新增吗?
不建议。分类固定为 5 个,标签从受控词表里选;自己新增会让分类页和标签页越来越碎, 每篇文章都变成一个孤立入口。
如果现有词表确实覆盖不了,单独讨论是否扩充,不要在一篇文章里临时造词。改一次词表, 之后所有文章都跟着变;临时造一个词,后面就收不住了。
Q:提醒框为什么只有 5 种?我看别人能用 SUCCESS、DANGER?
因为站点用的是 rehype-callouts 的 GitHub 主题,它只定义了 NOTE、TIP、IMPORTANT、
WARNING、CAUTION 这 5 种。网上很多提示词列的是 Obsidian 主题的 27 种类型,
在 GitHub 主题下会没有样式。
想用更多类型的话,把 src/config/siteConfig.ts 里 post.rehypeCallouts.theme 改成 "obsidian"
并重启开发服务器即可,但这会改全站提醒框的外观,属于一次全局改动,想清楚再动。
有问题或想让我写某个话题,邮件找我就行:admin@freedomj.com。
文章分享
如果这篇文章对你有帮助,欢迎分享给更多人!


