跳到主要内容

生活类 Blog 写作工作流

这篇文档是这个仓库里“生活记录类 blog”的长期规范。

目标很明确：

  • 让以后“给一组照片链接和一点补充信息，就能稳定产出一篇可发布的生活 blog”这件事可以重复执行
  • 让生活类 blog 和旅行类页面在“图片可点击放大”这件事上保持统一，但在版式上区分开，不混成同一种相册页

如果后续继续写聚餐、小聚、日常散步、看展、去某家店、阶段性生活片段这类内容，建议以这篇文档为准。

先理解当前约定​

当前仓库里，生活类 blog 的默认技术实现是：

  1. 文章放在 blog/ 目录下
  2. 文件格式默认使用 .mdx，不是普通 .md
  3. 图片默认复用 src/components/TravelGallery 的灯箱能力
  4. 但图片排版不使用旅行页那种瀑布/拼图布局，而是使用文章模式 layout="article"
  5. 文章模式下，图片按原始宽高比显示，不裁切、不强行限高，只在正文宽度内自适应
  6. 图片点击后仍然可以放大查看

这意味着：

  • 生活类 blog 默认是“图文文章”
  • 不是“旅行相册”
  • 不是“纯文字散文”
  • 也不是“只插几张普通 Markdown 图片”

当前可直接参考的成稿样例是：

  • blog/2026-04-18-friends-meet-firepot-bbq.mdx

生活类 blog 的默认定位​

生活类 blog 的核心不是攻略、评测或者流水账，而是把一个值得留下来的片段写清楚。

默认写法是：

  • 以场景和氛围为主，不以打分或推荐为主
  • 以“我和朋友们/我当时的感受”为主，不以完整复盘事件经过为主
  • 以真实细节为主，不强行拔高，不硬写成抒情散文
  • 以可发布为目标，不写太私人、太识别化的信息

一句话概括：

生活类 blog 默认写成“温暖纪实 + 一点感受 + 少量有用细节”。

默认写作风格​

如果没有额外说明，统一按下面这些默认值执行：

  • 语气：温暖纪实
  • 视角：第一人称
  • 隐私级别：克制泛写，不点朋友姓名，不给出可识别身份信息
  • 文章长度：通常 800 到 1600 字
  • 文章结构：2 到 4 个小节，不写得太散
  • 文章目标：记录一个晚上、一顿饭、一次见面、一次日常体验
  • 文风边界：可以有情绪，但不要故作深沉；可以有细节，但不要写成菜单堆砌

默认不做的事：

  • 不把文章写成店铺测评
  • 不写“推荐指数”“人均”“环境几星”这类内容，除非你明确要求
  • 不虚构对话、人物反应和未发生的情节
  • 不为了文采牺牲真实感

什么时候适合写生活类 blog​

下面这些场景都适合按这套流程写：

  • 和朋友小聚、聚餐、烧烤、火锅、夜宵
  • 去了某家很有记忆点的小店
  • 某个普通但很舒服的晚上
  • 一次短暂散步、看展、逛街、喝酒、聊天
  • 某个时间点很想记一下的生活片段

如果内容明显更偏“旅行线路、城市风景、照片为主”，那还是优先归到 docs/Travel，不要混到生活类 blog 里。

以后给 AI 的素材格式​

后续如果你想继续沿用这套流程，建议直接按下面这份模板给素材。

最少需要这些内容：

- 事件：
- 日期：
- 地点 / 店名：
- 照片链接：
- 明确的菜品 / 物品 / 场景：
- 明确的酒水 / 饮料：
- 我想强调的细节：

推荐补充这些内容：

- 想要的语气：温暖纪实 / 轻松有趣 / 更文艺一点
- 隐私要求：只写朋友们 / 可以写更多个人感受
- 是否加入知识内容：不要 / 少量 / 单独一小节
- 是否需要提交 git：是 / 否

最推荐的完整输入模板如下：

- 事件：和朋友们烧烤小聚
- 日期：2026-04-18
- 地点 / 店名：川西火焰山西昌火盆烧烤(新都格林城市花园店)
- 照片链接：
  - https://...
  - https://...
- 明确菜品：
  - 跑山小香猪
  - 麻辣嫩牛肉
  - 香烤五花肉
- 明确酒水：
  - 汾酒
  - 朝日啤酒
- 想强调的细节：
  - 调料盘里有黄豆粉
  - 第一次蘸黄豆粉吃烧烤，十分惊艳
- 想要的语气：温暖纪实
- 隐私要求：克制泛写
- 是否加入知识内容：单独一小节

图片处理规则​

1. 生活类 blog 默认使用 MDX​

原因很简单：普通 Markdown 图片不方便复用现有的点击放大能力。

所以默认使用：

  • blog/*.mdx

而不是：

  • blog/*.md

2. 默认使用 TravelGallery，但必须用文章模式​

生活类 blog 默认图片写法：

import TravelGallery from '@site/src/components/TravelGallery';

然后使用：

<TravelGallery images={photos} layout="article" />

这里有两条必须记住：

  • 生活类 blog 默认 layout="article"
  • 不使用旅行板块的瀑布/拼图布局，除非我明确要求“这篇就做成相册感”

3. 图片按原始比例显示​

生活类 blog 中的图片默认行为是：

  • 不裁切
  • 不做固定高度展示框
  • 不做旅游相册那种拼接对齐
  • 按原始宽高比显示
  • 只在正文宽度内自适应缩放

这条是固定默认值，后续不要再改回瀑布式逻辑，除非我明确要求。

4. 图片数量不多时，优先按“场景组”来放​

推荐不是把所有图塞成一个大相册，而是按场景拆成 2 到 4 组。

例如：

  • 第一组：桌面、炭火、肉串
  • 第二组：倒酒、小杯、调料盘
  • 第三组：主菜、鱼盘、配菜

这样比“一整坨图片堆在一起”更像文章。

5. 每张图尽量有 alt 和 caption​

推荐写法：

export const photos = [
  {
    src: 'https://picture.nevergpdzy.cn/xxx.jpg',
    alt: '朋友倒酒',
    caption: '小杯里倒上汾酒，桌边已经有了朋友局该有的松弛感。',
  },
];

默认要求：

  • alt 说清图里是什么
  • caption 用一句短话补足那张图的情绪或信息
  • 不要把 caption 写成长段正文

文章结构默认模板​

如果没有特别要求，生活类 blog 默认使用下面这套结构。

1. 开头：先交代场景​

第一段负责交代：

  • 时间
  • 地点
  • 这次是个什么局
  • 为什么值得记一下

这段通常也应该放在 <!--truncate--> 之前，方便博客列表页展示摘要。

2. 中段：写场景和食物，但不要写成点单清单​

中段的重点不是把所有菜报一遍，而是：

  • 抓住最有画面的场景
  • 抓住最有记忆点的吃法
  • 抓住一两个真正值得写的细节

比如：

  • 炭火慢慢把肉烤出焦香
  • 桌上有人看火、有人翻面、有人倒酒
  • 第一次尝试某种吃法，结果很惊艳

如果用户已经明确给了完整菜品列表，可以在正文中自然带进去，但不要生硬罗列。

3. 知识内容：可加，但必须克制​

如果你明确要求“加一点知识进去”，默认做法是：

  • 单独开一个短小节
  • 只写和这顿饭直接相关的知识
  • 占比不要压过整篇生活记录

最常见的是：

  • 某种酒的风格、背景、口感路线
  • 某种食材或吃法的小知识

默认不要做成：

  • 百度百科式长科普
  • 大段品牌史
  • 一堆来源堆砌到正文里

知识段的作用是“增加一点层次”，不是抢走生活记录本身。

4. 结尾：回到“为什么值得记一下”​

结尾默认收回到人和场景本身。

比较合适的落点通常是：

  • 这一晚真正留下来的是什么
  • 让人记住的不只是吃了什么，还包括什么氛围
  • 一个普通夜晚为什么仍然值得记录

默认不建议在结尾硬上价值，也不建议强行写成鸡汤。

内容判断优先级​

以后生成文章时，信息使用顺序固定如下：

  1. 你明确口头给出的信息
  2. 你给的文字补充
  3. 从图片中能稳定识别出的内容
  4. 最后才是谨慎推断

也就是说：

  • 如果你明确说酒是汾酒，那就按汾酒写
  • 如果图片看不清品牌，但你口头确认了，就以你的确认为准
  • 如果图片只能模糊看出“像某种肉串”，而你没确认，就不要写得太死

文件命名与 frontmatter 规范​

默认命名：

  • blog/YYYY-MM-DD-short-slug.mdx

例如：

  • blog/2026-04-18-friends-meet-firepot-bbq.mdx

默认 frontmatter：

---
title: 一篇短标题
authors: DingZhiyu
tags: [life-log]
---

默认规则：

  • title 用中文短标题，不要太长
  • authors 固定为 DingZhiyu
  • tags 默认使用 [life-log]

如果明显更偏思考随笔，而不是生活记录，再考虑改成 [thoughts]。

生活类 blog 的固定技术模板​

以后默认按下面这个骨架来组织：

---
title: 标题
authors: DingZhiyu
tags: [life-log]
---

import TravelGallery from '@site/src/components/TravelGallery';

export const scenePhotos = [
  {
    src: 'https://picture.nevergpdzy.cn/xxx.jpg',
    alt: '图片说明',
    caption: '一句简短图注。',
  },
];

# 标题

开头第一段。

<!--truncate-->

正文第二段。

<TravelGallery images={scenePhotos} layout="article" />

后续正文。

如果一篇文章里有多组图，就继续定义：

  • foodPhotos
  • drinkPhotos
  • detailPhotos

这样的变量名即可。

发布前检查清单​

每次写完以后，至少检查下面这些点：

  • 文件是否放在 blog/ 下
  • 是否使用 .mdx
  • 是否正确引入 TravelGallery
  • 是否明确使用了 layout="article"
  • 图片是否按原比例显示
  • 图片是否可点击放大
  • title、authors、tags 是否正确
  • <!--truncate--> 是否放在合适位置
  • 是否误写了菜品、酒名、店名、日期
  • 是否暴露了不该写的隐私
  • 如果用户要求了知识内容，是否控制在合理篇幅内
  • 最后是否执行 npm run build

如果用户要求版本更新和提交 git​

如果任务不只是写文章，还包括版本更新和提交代码，统一按下面执行：

  1. 先读 VERSIONING.md
  2. 判断应该升 patch、minor 还是 major
  3. 运行对应的版本命令
  4. 确认 package.json 和 package-lock.json 都已更新
  5. 执行 npm run build
  6. 再提交 git

默认理解：

  • 单纯修错字：PATCH
  • 新增一篇生活类 blog，或者新增一个非破坏性的可见功能：MINOR
  • 破坏路由或大改结构：MAJOR

以后执行这类任务时的默认结论​

如果我以后只给一组生活照片和一点补充信息，而没有说太多额外要求，那么默认按下面执行：

  • 输出到 blog/
  • 使用 .mdx
  • 用 TravelGallery
  • 强制 layout="article"
  • 图片按原比例显示
  • 文章语气为温暖纪实
  • 隐私写法为克制泛写
  • 结构按“开头场景 -> 中段细节 -> 可选知识小节 -> 结尾收束”
  • 如果有特别鲜明的细节，就把它写成整篇文章的记忆点
  • 如果我要求“加一点知识”，就单独开短小节，不喧宾夺主
  • 最后跑 npm run build

这份文档的目的不是把文章写死，而是把默认决策写清楚。以后大部分生活类 blog，可以直接按这份规范落地，不需要每次从头重新定流程。