大多数独立内容站不是死于内容差，而是死于发布不稳定。连续 12 周猛发、然后沉默 4 个月，比稳定发一半的量更差。数据也支持这一点：Orbit Media 2025 年对 808 位博主的调查显示，发布更频繁、更稳定的人更可能拿到”明显效果”，而所有人的基线只有 21%。节奏的目的不是把产量做到最大，而是可预测——而且要从你真实的 git log 里量，不是从愿望里量。
一句话总结
- 用
git log量过去 8 周，别凭记忆。 - 乘 0.8 得到你状态差也守得住的下限，再向下取整成干净排期。
- 把固定发布日写进
CONTENT.md，常备 2-3 篇 backlog 缓冲。 - 每周只追踪一个布尔值：这周发了吗，发了/没发。别管字数和工时。
- 每 13 周复盘一次，月产上下调一篇，中途绝不调整。
为什么稳定胜过猛冲
Google 不会真的奖励”每周二发”这种模式，但它的 Query Deserves Freshness（值得新内容的查询）机制会奖励长期持续输出相关内容的站；而且一篇有实质内容的新文，比一篇改了日期却没改内容的旧文，是更强的信号。AI 回答引擎把赌注抬得更高：截至 2026 年 6 月，多份 SEO 分析指出，过去 30 到 90 天内更新过的页面，被 ChatGPT、Perplexity 这类工具引用的概率明显更高，而被 AI 引用的页面整体也比传统 Google 自然结果”新鲜”得多。
但更硬的约束是你自己。没有节奏，内容会被无限推到”以后”。“可量化节奏 + 小 backlog + 每周发文检查”，是真正撑得住的最小系统。
节奏跑偏的信号
- 你发文呈”波”：猛冲几周然后沉默。
- 几个月前定了目标，没撑住。
- 对发布频率有负罪感（说明目标错，不是你错）。
- 过去 8 周的平均产出，远低于你对外承诺的数字。
快速结论： 挑一个你 90% 确定能连续 12 个月、哪怕状态差也做得到的最低节奏。这才是你真实的节奏，超出的都算 bonus。
现实里的节奏长什么样
对一个单人独立站，2026 年多数调查指向的可持续甜区是每周 1 篇有分量的文章，每周 2-3 篇留给团队或竞争激烈的细分领域。把预期锚在真实基准上，而不是别人嘴上说的数字：
| 指标（Orbit Media 2025，n=808） | 数值 |
|---|---|
| 平均文章长度 | 1,333 词 |
| 平均写一篇耗时 | 3 小时 46 分 |
| 拿到”明显效果”的博主（基线） | 21% |
| 2,000 词以上长文的”明显效果”比例 | 39% |
对节奏算法的启示：每篇按 4 小时左右预算，且假设你的均值会偏长文。如果”每周 2 篇”意味着状态差那周你拿不出 8+ 小时专注时间，那你真实的下限比你以为的更低。
实操步骤
1. 用 git log 老实量
frontmatter 里有发布日期，但 git log 证明你真正何时 ship 了：
# 过去 8 周变动过的文章数（去重）
git log --since="8 weeks ago" --pretty=format:'%ai' --name-only -- 'src/content/articles/' \
| grep '\.mdx$' | awk -F/ '{print $NF}' | sort -u | wc -l
# 过去 8 周新增（A = added）的文章数
git log --since="8 weeks ago" --pretty=format:'%ai' --diff-filter=A --name-only \
-- 'src/content/articles/' \
| grep '\.mdx$' \
| awk -F/ '{print $NF}' | sort -u | wc -l或者更简单地直接看 frontmatter：
grep -rh '^publishedAt:' src/content/articles \
| awk '{print $2}' \
| awk -F- '{print $1"-"$2}' | sort | uniq -c
# 按年-月计数，最近几个月的数据说真话2. 乘 0.8 得到下限
8 周发了 16 篇 → 真实节奏 16 × 0.8 / 8 = 1.6 篇/周。向下取整成干净排期（1/周、2/周）。这个 0.8 就是给生病、出差、倦怠那些周留的缓冲。一个只有状态好才达得到的下限，根本不是下限。
3. 定固定发布日
周二 + 周五是常见模式。把排期写进 CONTENT.md，让它扛得住你将来的自我怀疑：
# 发布节奏
- 目标: 2 篇/周
- 日期: 周二 10:00 ET、周五 10:00 ET
- backlog 缓冲: 任何时刻有 2-3 篇待发
- 每季度复盘；中途不调整4. 建 backlog 缓冲
一个简单的 drafts/ 目录，放好可以随时发的稿子，专门吸收你状态差的那几周：
ls drafts/*.mdx | wc -l
# 低于 2 就告警：
[ "$(ls drafts/*.mdx 2>/dev/null | wc -l)" -lt 2 ] && echo "WARN: backlog 低于 2"挂到每周清单里。告警前的告警，就是告警。
5. 只追踪”本周发了/没发”
别追字数和工时——它们跟你真正在意的结果（一个已发布的页面）没相关性。一个极小的追踪脚本：
// scripts/cadence-check.mjs
import { execSync } from 'node:child_process';
const since = new Date(Date.now() - 7 * 86400 * 1000).toISOString().slice(0, 10);
const out = execSync(
`git log --since="${since}" --diff-filter=A --name-only -- 'src/content/articles/'`
).toString();
const newArticles = out.split('\n').filter(l => l.endsWith('.mdx')).length / 2; // en + zh
console.log(`本周: ${newArticles} 篇新文`);
if (newArticles === 0) console.log('断更');挂到每周 cron，或者周五早晨人工跑一遍。
6. 每 13 周复盘
按周做一份季度总结：
grep -rh '^publishedAt:' src/content/articles \
| awk '{print $2}' \
| awk -F- '{print $1"-W"int(($2*30+$3)/7)}' \
| sort | uniq -c | tail -1312 周都觉得轻松，月产 +1；觉得吃力，降一档。中途不要调，否则你会一路给自己找理由滑回混乱。
7. 不要前置猛冲
20 篇上线周 + 8 周沉默，比稳定 2/周差得多——既伤新鲜度信号，也伤你自己的习惯。第一批至少匀着发满第一个季度。
执行检查清单
- 8 周基线从
git log量，不是凭记忆。 - 公开节奏 ≤ 实测 × 0.8。
- 固定发布日写进
CONTENT.md。 - backlog 缓冲常备 2 篇以上。
- 每周”发了吗”检查已自动化或仪式化。
验证它撑住了
- 12 周后：
git log显示的连续周数与目标一致。 - backlog 从未掉到 1 篇以下。
- Search Console 的”已发现页面”平稳上行，不再尖刺。
容易踩的坑
- 照搬别的站的数字。 你不是他们，你的生活也不是。量你自己的 log。
- 第一个月猛冲。 一周发 20 篇看着漂亮，接着 8 周沉默就把收益抹平了。
- 不留 backlog。 没有它，一周状态差就断更。
- 内容日历工具过度。 Google Sheet 或 Notion 表格就够，工具不是瓶颈。
- 追踪输入（字数、工时）而非输出（发布数）。 输入不是承诺。
FAQ
- 一周两篇够吗？ 如果能撑一年，够。独立站上，稳定 2 篇/周几乎总赢过撑不住的 5 篇/周；2026 年多数 SEO 调查也把每周 1-2 篇优质文放在可持续增长的甜区。
- 断更一周怎么办？ 用 backlog 补。backlog 空了，就第二天发一篇短的，别跳到”下周”。
- 要不要提前几个月批量囤稿？ 适当囤可以，但别超过 4-6 周。你的兴趣和话题环境会变，囤太久的稿子读起来会陈旧。
- 发布的时间点重要吗？ 对 SEO 基本不重要。对社交和邮件分发，受众时区有一点影响。别过度优化。
- 假期 / 出差怎么办？ 提前从 backlog 发。栈支持就排定时（
publishedAt设为未来 + 每日 build cron）。 - 能不能改改旧文当”新鲜”，省得发新的？ 只有做了实质改动才算。搜索引擎和 AI 回答引擎看的是一次更新里真实改动的体量；只改日期、不改内容，换不来新鲜度信号。
相关阅读
外部参考：Orbit Media 2025 博主调查 提供了上述基准数据。