用途：写给资深工程师、主任/资深工程师、技术负责人和分布式系统实践者的技术内容，要求读者忙碌、怀疑，遇到填充内容会立刻停读。
主要能力：
- 读者画像与语气：第一人称、直接、保持智识诚实，使用“I think”“we decided”“we got this wrong”等表达；个人观点不用帝王式“we”，做决策时不藏于被动语态。主题覆盖后端工程、软件架构、业务与工程的交叉、分布式系统权衡。
- 故事框架：每篇遵循 Before → Journey → After。Before 写哪里坏了、缺了什么、代价是什么、谁受影响；Journey 写尝试了什么、什么让人意外、先做错了什么；After 写最终方案、会改什么、现在相信什么。不服务这三段的内容应删掉或并入。
- 钩子规则：开头约150词最关键，必须直接写出问题或缺口、不解决的后果、以及写给谁看；背景、定义放在钩子之后。示例模板：[System/situation] had a gap. [What the gap caused]. Here's how we thought through it.
- 结构清单：动笔前依次确定读者画像、具体痛点（尽量量化延迟、错误率、人工小时、客户影响）、钩子草稿、必要背景（过长就另写一篇）、选项与权衡、结论/所以呢、最后写标题。
- 格式规则：H2 用于主节、H3 用于子节，标题说明该节做什么，如“Why we rejected the queue-based approach”优于“Alternative Approaches”；段落最多3–5行；列表只用于并列项，不用来逃避写段落；技术文章尽早放代码块；用主动语态和现在时。
- 禁用模式：不用定义开场、无叙事的纯参考章节、以链接结尾、关键决策处用被动语态、“In this post, we will cover...”、模糊范围短语。
- 禁用词：just、simply、obviously、of course、easy、everyone knows、very、basically、turns out、in order to。
- 结尾规则：以你的观点收束，而不是总结；回答“如果要给同事讲收获，我会说什么”。
- 标题指南：最后写标题，要具体、诚实、不点击诱饵；可用格式如 [Problem] without [trade-off you'd expect to accept]、Why we chose [X] over [Y] for [Z] 等。
限制：该资料仅给出写作方法与规则，未提供安装命令、运行方式、平台支持、收费信息或效果数据；这些内容暂未提供。