关于
执行 Sentry 博客写作标准的 Skill，确保每篇文章——无论是工程师写作还是技术内容——都符合质量要求。
name: blog-writing-guide description: "本技能在每篇博文中执行 Sentry 的博客写作标准——无论你是在帮助工程师撰写第一篇博文，还是帮助营销人员起草产品公告。" risk: unknown source: community date_added: '2026-03-06'
Sentry 博客写作技能
本技能在每篇博文中执行 Sentry 的博客写作标准——无论你是在帮助工程师撰写第一篇博文，还是帮助营销人员起草产品公告。
标准线： 每篇 Sentry 博文都应该是资深工程师愿意分享到团队 Slack 频道、或在技术决策中引用的内容。
以下是需要内化并应用于每篇内容的核心原则。
适用场景
- 你需要起草或编辑一篇 Sentry 博文。
- 任务涉及技术叙事、产品公告或以 Sentry 博客风格撰写的工程深度文章。
- 你希望博客内容有观点、有细节、技术上可信，而非泛泛的营销文案。
Sentry 的声音
我们听起来像： 一位资深开发者在技术大会的 afterparty 上解释他们真正兴奋的事情——聪明、具体、略带不羁、知识渊博。
我们不像： 企业博客、新闻稿、销售演示文稿或 AI 生成的摘要。
要技术精确、有观点、直接。幽默可以有，但应服务于内容而非替代内容。讽刺可以用。每篇文章一个好笑话就够了。
使用"我们"（Sentry）和"你"（读者）。这是对话，不是论文。
禁用语言
绝对不要使用以下表达，它们是自动红旗：
- "我们很高兴/激动地宣布"——直接宣布就好
- "业界领先" / "一流的" / "前沿的"——用事实说话，别自吹
- "无缝" / "无缝地"——没有什么是无缝的
- "赋能" / "利用" / "解锁"——说你真正想表达的意思
- "强大的"——描述是什么让它强大
- "在[公司]，我们相信..."——直接陈述观点
- "优化流程"——所有人都在优化流程，别再说了
- 填充性过渡词："话虽如此，" "值得注意的是，" "归根结底，" "废话不多说，" "众所周知"
- "在这篇博文中，我们将探讨..."——直接开始，别绕弯子
开头（前 2-3 句话）
开头必须做到以下两件事之一：陈述问题 或 陈述结论。永远不要以背景介绍、公司历史或炒作开头。
好的示例： "发布前两周，我们砍掉了整个指标产品。以下是为什么预聚合时间序列指标在调试中行不通，以及我们如何从零重建系统。"
差的示例： "在 Sentry，我们一直在寻找改善开发者体验的方法。今天，我们很高兴分享一些令人兴奋的指标产品更新，我们认为你会喜欢的。"
结构：跟随读者的问题
围绕读者真正想知道的内容来组织每篇文章，而非你的内部叙事：
- 这解决了什么问题？（最多 1-2 段）
- 它实际上是怎么工作的？ 不是你点击了哪些按钮，而是底层技术。（文章主体——要具体）
- 有哪些权衡或替代方案？（这是区分好文章和优秀文章的关键）
- 我如何使用/尝试/实现它？（具体的下一步操作）
对于工程深度文章，还需要回答： 5. 我们尝试了什么但没有成功？（建立信任） 6. 已知的局限性是什么？（展示知识诚实）
章节标题必须传达信息
弱标题： "背景"、"架构"、"结果"、"结论"
强标题： "为什么时间序列预聚合会破坏调试上下文"、"分布式 GROUP BY 的 scatter-gather 方法"、"瓶颈所在：基数墙"
技术质量标准
数字优于形容词。 如果你提出性能声明，必须包含数字。
- 差：「这显著减少了我们的错误处理时间。」
- 好：「这将我们的 p99 错误处理时间从 340ms 降低到 45ms——提升了 7.5 倍。」
代码必须能运行。 如果文章包含代码，要测试它。包含 import、配置和上下文。注释应解释"为什么"，而非"是什么"。
系统需要图表。 如果你描述的系统有两个以上交互组件，需要包含图表。用真实的服务名称标注，而非通用方框。
诚实优于炒作。 永远不要夸大功能的作用。承认局限性。如果某功能在 beta 阶段，就说明。如果竞争对手某方面做得好，可以提及。不要声称 AI 功能比实际更强——"Seer 建议一个可能的根因" 不等于 "Seer 找到了根因"。
标题指南
标题是文章中杠杆效应最高的一句话。它必须让开发者在滚动 RSS 订阅或 Twitter 时停下来。
强标题 提出具体主张、讲述故事或承诺具体收益：
- "我们构建的指标产品运行良好。但我们还是砍掉了它，从头开始"
- "我们如何通过修复 Salt 将发布延迟减少了 5%"
- "你的 JavaScript 没有你想的那么快"