专业博客结构与成稿指南

问题：技术博客容易写成「内部叙事」

很多技术内容最终写成了产品发布稿或会议纪要。开头花时间铺垫背景，读者却不知道能解决什么问题；标题含糊，缺少具体承诺；代码示例不可运行，架构描述与实际系统不一致；结尾变成空洞的口号，没有下一步动作。

技能如何工作：围绕读者问题组织

这个技能将博客写作拆解为可执行的步骤。开场必须在两句内完成：要么直接陈述问题，要么给出结论，不要从公司历史或客套开始。正文结构按读者疑问推进：问题是什么、底层机制、取舍与替代方案、如何使用。工程深潜还要补充 尝试过但失败的方向 和 已知限制。

标题必须传递具体信息，避免 Introducing our new metrics product 这类模糊公告。性能声明必须附带指标，例如 p99 从 340ms 降到 45ms；代码必须包含导入、配置和上下文；涉及两个以上交互组件的系统，需要提供带真实服务名的图表。

审校与边界

成稿前执行三层检查。技术审校核对声明、代码、架构和基准数据；编辑审校确认开头钩住读者、标题具体、没有套话；最终检查真实作者署名、文档链接，并确认内容不与 changelog 重复。

禁止使用 We're excited to announce、seamless、cutting-edge 等空泛词汇。该技能仅用于博客结构与成稿场景，不能替代环境测试、事实核查或专家评审。当缺少必要输入或权限时，先标记缺口并询问，不要猜测事实或数据。