Ink 内容日历

要解决的不是“排期”，而是产能与一致性的错配

内容团队常见的问题是选题积压、发布节奏不稳：创始人只能每周投入不到 4 小时，却按全职团队的频率排期；没有作者、截止时间、目标关键词和分发渠道，日历看起来完整，实际无法执行。对 SEO 和读者信任来说，不稳定的发布比低频但稳定更伤。@user_fccf428b/ink-calendar 把内容日历当作工程问题：先确认谁生产、每周多少时间、ARR 阶段和内容类型，再据此设定可执行节奏，而不是用愿望倒推排期。

它如何把积压变成可执行的 12 周滚动计划

技能先收集上下文：创作者是创始人、外包还是内容团队；每周可投入时间；ARR 阶段对应 1 post/2 weeks、2-4 posts/week 或 daily；范围包括 blog、tutorials、case studies、newsletter；分发渠道包括 email list、Twitter、LinkedIn、HN、Product Hunt 等。

接着按产能匹配发布节奏：

• Founder only, <4h/week：约 2 篇/月，优先 long-form evergreen
• Founder + 1 contractor：约 4 篇/月，evergreen 与 timely 混合
• Part-time content hire：约 2 篇/周，围绕 cluster-building
• Full-time content：3-5 篇/周，完整 editorial calendar

然后构建内容组合：40% evergreen tutorials，20% thought leadership，20% product use cases，10% comparison/alternatives，10% community roundups/curated。再产出 12 周滚动日历，每篇包含 working title、target keyword、content type、estimated word count、author、distribution plan 和 deadline。交付物是日历表格，外加分发 checklist 和 repurposing map；标题和关键词要具体，不能是 placeholder topics。输出遵循 docs/output-kit.md：CLI 最多 40 行、box-drawing skeleton、统一 severity indicators、压缩叙述；超过 40 行时委托给 /atlas-report。

适用边界

它适合需要从零建立发布节奏或清理积压的小型产品团队；不替代写作质量判断，也不负责选题验证、关键词难度分析或渠道账号运营。若产能数据不真实，日历会失真；若没有明确分发渠道，distribution workflow 只能空转。