用途
该技能用于在撰写或编辑 Sentry 博客文章时，强制执行 Sentry 的博客写作标准。无论你是帮助工程师撰写第一篇博客文章，还是帮助营销人员起草产品公告，都适用。其标准是：每一篇 Sentry 博客文章都应该是资深工程师愿意在团队 Slack 中分享、或在技术决策中引用的内容。
主要能力
- 定义 Sentry 语气：听起来像会议后派对上一位资深开发者讲解自己真正兴奋的内容——聪明、具体、略带不敬、知识渊博。不像企业博客、新闻稿、销售演示或 AI 生成的摘要。要求技术精确、有观点、直接。幽默应服务于内容，每篇一个好笑点足够。使用“我们”（Sentry）和“你”（读者），是对话而非论文。
- 禁用语言清单：禁止使用“我们很兴奋/激动地宣布”“同类最佳/行业领先/前沿”“无缝/无缝地”“赋能/利用/解锁”“稳健”“在[公司]，我们相信……”“简化”“话虽如此/值得注意的是/归根结底/闲话少说/如你所知”“在这篇博客文章中，我们将探讨……”等填充过渡和套话。
- 开头要求：前 2-3 句必须陈述问题或陈述结论。绝不以背景、公司历史或炒作开头。
- 结构要求：围绕读者真正想知道的内容组织，而非内部叙事。包括：解决什么问题（最多 1-2 段）、实际如何工作（文章主体，要具体）、有哪些权衡或替代方案、如何使用/尝试/实现。工程深度文章还需回答：尝试过什么但没成功、已知限制是什么。
- 标题要求：标题是文章中杠杆率最高的一句话，必须让开发者在 RSS 或 Twitter 上停止滚动。强标题提出具体主张、讲述故事或承诺具体回报；弱标题是模糊的公告。
- 技术质量标准：用数字而非形容词（如“将 p99 错误处理时间从 340ms 降至 45ms——提升 7.5 倍”）；代码必须可运行，包含导入、配置和上下文，注释解释为什么而非是什么；描述超过两个交互组件的系统时配图，使用真实服务名而非通用方框；诚实高于炒作，不夸大功能，承认限制，测试版就说是测试版，不声称 AI 功能超出其实际能力。
- 结尾要求：以有用的内容结束——文档链接、试用方式、反馈呼吁。绝不以通用炒作或复述结尾。
- 文章类型映射：工程深度（由构建它的工程师署名）、产品发布（PM、工程师或 DevEx，除非营销构建否则不由 PMM）、事后复盘（工程领导层）、数据/研究（数据团队、工程或研究）、教程/指南（DevEx、工程师或社区贡献者）。
- “我会分享这个吗”测试：发布前问：开发者会分享这篇文章吗？有机会上 Hacker News 吗？值得分享的文章至少包含：用权衡解释的技术决策、别处找不到的原创数据或研究、有具体细节的真实调试故事、对出错事情的诚实交代、节省读者时间的方法指南。
- 不可妥协清单：绝不发布没有真实姓名的文章（不用“Sentry 团队”署名）；绝不发布不能运行的代码；绝不说“我们很兴奋地宣布”；描述系统就配图；做性能声明就附数字；讨论决策就解释没选什么及原因；每篇文章写作前作者心中必须有明确的“这是给谁看的”；变更日志留在变更日志中；有疑问时写得更深入。
- 审阅或编辑草稿：运行技术审阅（技术声明准确、代码示例可运行、架构描述符合现实、数字和基准正确、没有让专家尴尬的过度简化）和编辑审阅（开头两句话内吸引读者、通过“我会分享这个吗”测试、没有企业语言/填充/废话、标题传达信息、长度合适、标题具体有吸引力），以及最终检查（作者署名正确、包含文档/入门链接、文章不与变更日志重复）。提供反馈时要具体且有建设性，引用薄弱段落，解释为何薄弱，并重写以展示标准。
使用方式
当用户请求起草或编辑 Sentry 博客文章时使用。该技能会应用上述原则和清单。
适用场景
- 需要起草或编辑 Sentry 博客文章。
- 任务涉及技术故事讲述、产品公告或 Sentry 博客语气的工程深度文章。
- 希望博客内容有观点、具体、技术可信，而非通用营销文案。
限制
- 仅在任务明确匹配上述范围时使用此技能。
- 不要将输出视为环境特定验证、测试或专家审查的替代品。
- 如果缺少所需输入、权限、安全边界或成功标准，应停止并请求澄清。