Management Talk prompt

把面向工程师的技术内容，改写成给工程组织领导层（VP、总监、产品经理、发布经理、高管）看的更新，并按投放渠道成型——JIRA 评论、Slack 帖、异步站会、邮件或会议要点。读者能看懂产品名和代号，但不看代码。

改写规则：
1）保留：产品名、框架名、团队负责的组件名、JIRA 单号、PR 编号、客户/负载标识（如 PyTorch、vLLM、JIRA-12345、PR #5751）——这些是工程与管理层之间的对照桥梁。
2）删除：函数名、文件路径、结构体字段、commit SHA、代码表达式、环境变量名、行号等代码级细节，读者用不上。
3）翻译机制：用一两句大白话讲清因果，不撒谎——竞态还是竞态，回退还是回退。
4）不要过度简化：领导层能读懂“竞态、同步、未初始化缓冲区、快路径、临时规避、内核（GPU 语义）”这类概念词。别把“竞态”降格成“时序问题”，那是在轻视读者。
5）多用主动语态、具体主语、短段落。别对着领导教他们怎么做事——给事实，让他们决定。

按渠道成型：
1）JIRA 评论：完整结构块，加粗小标题（状态/TL;DR、影响、出了什么问题、责任人、后续步骤、临时规避、风险）。
2）Slack：单条消息，首行一句加粗 TL;DR，下面 2-4 个短要点，内联一个链接，无问候无落款。
3）异步站会：1-3 行，动词打头，“<状态> <事项>。<责任人>。<下一步>。”
4）邮件：主题行是名词短语版 TL;DR；正文用流畅段落，两三段即可；结尾点明需对方拍板的下一个决策点。
5）会议要点：项目符号列表，每条一句短语，按你要讲的顺序排列，把要念的编号写进要点里。

红线：绝不编造事实让改写更漂亮；绝不在去术语化时删掉 JIRA 单号、PR 编号或客户/负载名；绝不编造责任人——原文没写就问用户，别靠 git blame 猜。

待改写的源内容：____
目标渠道（JIRA/Slack/站会/邮件/会议要点，若不明确先只问这一句再停）：____