management-talk

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Management Talk

管理层沟通内容撰写指南

Same audience and translation rules as a written status report, but shaped for the channel — JIRA comment, Slack post, async standup, email, or meeting talking-points. The audience reads code names but not code. The channel decides the length, formatting, and how much structure to leave on the page.

Use this any time engineering content needs to flow up the org, sideways into product/release, or into a non-engineering meeting — regardless of the destination.

受众和翻译规则与书面状态报告一致，但需根据渠道调整形式——包括JIRA评论、Slack帖子、异步站会内容、邮件或会议讨论要点。受众能理解代码名称，但不会阅读代码内容。渠道决定了内容的长度、格式以及页面保留的结构复杂度。

每当工程内容需要向上汇报给管理层、横向同步给产品/发布团队，或用于非工程会议时，无论目标渠道是什么，都可使用本指南。

When to invoke

触发场景

"write something for management / exec / VP / director / PM / release manager"
"rewrite this for [non-eng audience]"
"make this non-technical" / "less techy" / "less jargony"
"send a slack update / standup note / email" about a piece of engineering work
"executive summary" / "exec summary" / "leadership update" / "status update"
"talking points for [meeting]" based on an engineering update

If the channel is unclear after the trigger, ask one short question — "JIRA, Slack, standup, or email?" — and stop.

"为管理层/高管/副总裁/总监/产品经理/发布经理撰写内容"
"将此内容改写为面向[非技术受众]的版本"
"让内容更通俗易懂"/"少点技术术语"/"少点行话"
"发送关于某项工程工作的Slack更新/站会备注/邮件"
"执行摘要"/"高管摘要"/"领导层更新"/"状态更新"
"基于工程更新内容准备[会议]讨论要点"

如果触发请求中未明确渠道，只需提出一个简短问题——"是JIRA、Slack、站会还是邮件？"——然后等待回复即可。

Audience — what "engineering-org leadership" means

受众定义——何为"工程组织领导层"

Engineering-savvy non-engineers: VPs, directors, PMs, release managers, execs in companies that ship technical products. They read product/framework names and cross-reference JIRA keys and PRs. They do not read code.

They want: what's the state, what does it mean for customers, who owns it, what's next. They do not want: how the bug works at the function level.

This is not for marketing, finance, customer-facing, or true ELI5 audiences — those need a different rewrite. Flag and confirm before producing one.

指懂技术的非工程师：在技术产品公司任职的副总裁、总监、产品经理、发布经理及高管。他们能理解产品/框架名称，会关联JIRA编号和PR，但不会阅读代码。

他们关注的信息：当前状态、对客户的影响、负责人、下一步计划。他们不关心的信息：函数层面的bug原理。

本指南不适用于营销、财务、客户-facing或完全零基础的受众——这类受众需要不同的改写方式。在产出内容前需先标记并确认受众类型。

Tone

语气规范

Keep. Product names, framework names, team-owned component names, JIRA keys, PR numbers, customer/workload identifiers (

Tada

DeepSpeed

PyTorch

Llama-2-70B

vLLM

JIRA-12345

PR #5751

). These are the bridge between engineering and leadership tracking.

Strip. Function names, file paths, struct fields, commit SHAs, code expressions, env var names, line numbers, internal data-structure jargon (

tadaLaunchPrepare

tada/prim.h::syncWaitPeer

scratchBuf

0e0a6bac

). None of this is actionable to the audience.

Translate. Mechanism into one or two sentences of plain-English cause-and-effect. Not "the kernel reads from
scratchBuf == NULL
" but "the GPUs end up reading from an uninitialized buffer and wait forever for a signal that never arrives." Translate without lying — a race stays a race; a regression stays a regression.

Don't over-strip. Engineering-org leadership reads concept-level technical vocabulary fluently — race condition, synchronization, uninitialized buffer, fast-path, workaround, registration, queue, driver, kernel (in the GPU sense). The line is between concept exists and matters here (keep) and here's the function/struct/file/SHA (strip). Replacing "race" with "timing issue" patronizes the reader.

Bias toward active voice, concrete subjects, short paragraphs. "We found the bug. Alex wrote the fix. PR is up for review." beats "The root cause has been identified and a fix has been authored and submitted for review."

Avoid:

Hedging that isn't really hedging ("we believe," "appears to," "may have"). State it or don't.
Re-stating the obvious for thoroughness ("This bug is in Tada, which is used for GPU communication, which is important for distributed training, which...").
Telling leadership how to do their job ("you should prioritize," "this needs to land before X"). Give them the facts; they decide.
Engineering-process minutiae: bisect runs, debug iterations, GDB sessions. They care that you found it, not how. (Exception: when the process itself is the story — "we burned three weeks before realising the bisect was misleading" — then a single sentence as a learning, not a play-by-play.)

保留内容：产品名称、框架名称、团队负责的组件名称、JIRA编号、PR编号、客户/工作负载标识（

Tada

、

DeepSpeed

、

PyTorch

、

Llama-2-70B

、

vLLM

、

JIRA-12345

、

PR #5751

）。这些是工程团队与领导层之间的跟踪桥梁。

删除内容：函数名称、文件路径、结构体字段、提交SHA值、代码表达式、环境变量名称、行号、内部数据结构行话（

tadaLaunchPrepare

、

tada/prim.h::syncWaitPeer

、

scratchBuf

、

0e0a6bac

）。这些内容对受众而言没有实际行动价值。

转化内容：将技术机制转化为1-2句通俗易懂的因果关系描述。不要写"内核读取

scratchBuf == NULL

"，而是写"GPU最终读取了未初始化的缓冲区，并永远等待一个不会到来的信号"。转化时不得歪曲事实——竞态条件仍需保留"竞态"表述；回归问题仍需明确为"回归"。

避免过度简化：工程组织领导层能熟练理解概念层面的技术词汇——如竞态条件、同步、未初始化缓冲区、快速路径、临时解决方案、注册、队列、驱动、内核（GPU领域术语）。判断标准是：概念本身存在且与当前内容相关则保留，涉及具体函数/结构体/文件/SHA值则删除。将"竞态"替换为"时序问题"会显得对读者不尊重。

优先使用主动语态、具体主语、短段落。例如"我们找到了bug。Alex编写了修复方案。PR已提交审核。"优于"根因已被识别，修复方案已编写并提交审核。"

需避免：

无意义的模糊表述（如"我们认为"、"似乎"、"可能"）。要么明确陈述，要么不提及。
为了全面性而重复显而易见的信息（如"此bug存在于Tada中，Tada用于GPU通信，这对分布式训练很重要，而……"）。
指导领导层如何工作（如"你应该优先处理"、"这需要在X之前完成"）。只需提供事实，由他们做决策。
工程流程细节：二分查找测试、调试迭代、GDB会话。他们关心的是你是否找到问题，而非解决过程。（例外情况：当流程本身是核心内容时——如"我们浪费了三周时间才意识到二分查找测试存在误导性"——此时可写一句话作为经验总结，而非详细步骤。）

Channel shapes

渠道适配形式

Same content, different shell. Pick the shape that matches where it's going.

核心内容一致，呈现形式不同。选择与目标渠道匹配的形式。

JIRA comment / written status report

JIRA评论 / 书面状态报告

Full structured block. Bolded section labels. Easy to scan from the ticket page.

Building blocks (use as many as fit):

Status / TL;DR. One bolded line. Reader can stop here and have the right answer. "Fixed pending merge." / "Root cause unknown — investigating." / "Blocked on vendor." / "Customer-visible regression in 7.2; rollback in flight."
Impact. Who's affected, how badly, what they see. Customer / workload / product terms, not test-suite terms. "Llama-2-70B fine-tuning hangs on every eval step" > "the test fails."
What broke. Short paragraph. Plain-English mechanism, one level of why, no code identifiers.
Why now / how it slipped through. Optional. Include when leadership will ask anyway: latent regression, CI gap, prior incomplete fix, change that landed during a freeze.
Owner. Person + team + their PR/branch/JIRA artifact. One link, not five.
Next steps. Concrete, near-term, ordered. "Code review → merge → backport to 7.2."
Workaround / mitigation. If customers are hitting it now, what can they do today? One sentence.
Risk. Optional. Real risks only — "fix touches the hot path; perf regression possible until benchmarked." Don't manufacture risk to look thorough.

Order by what matters most for this item.

完整结构化内容块，使用加粗的章节标题，便于从工单页面快速浏览。

可选用以下模块（按需组合）：

状态 / 摘要（TL;DR）：一行加粗内容。读者只需看这一行就能了解核心信息。例如"修复完成，待合并。"/"根因未知——正在调查。"/"受限于供应商。"/"7.2版本存在客户可见的回归问题；正在回滚。"
影响范围：受影响对象、影响程度、具体表现。使用客户/工作负载/产品术语，而非测试套件术语。例如"Llama-2-70B微调在每个评估步骤都会挂起"优于"测试失败。"
问题原因：简短段落。用通俗易懂的语言描述机制，说明一层原因，不包含代码标识。
为何现在出现 / 为何未被发现：可选模块。当领导层必然会询问时添加：潜在回归问题、CI漏洞、之前未彻底修复的问题、冻结期间上线的变更。
负责人：人员+团队+对应的PR/分支/JIRA链接。只需一个链接，无需多个。
下一步计划：具体、近期、有序的步骤。例如"代码审核 → 合并 → 回移植到7.2版本。"
临时解决方案 / 缓解措施：如果客户当前正遇到该问题，说明他们现在能采取的措施。一句话即可。
风险：可选模块。仅提及真实风险——如"修复涉及核心路径；在完成基准测试前可能存在性能回归。"不要为了显得全面而编造风险。

按当前事项的重要程度排序模块。

Slack — channel post or DM

Slack — 频道帖子或私信

Single message, no walls of text. Heavy bolded section labels read as "I escaped from JIRA" — don't.

One bolded TL;DR as the first line.
2–4 short bullets underneath: impact, owner+link, next step. Drop blocks that don't apply.
One link, embedded inline (
```
JIRA-12345
```
/
```
PR #5751
```
). Not a link wall.
No greeting, no signoff. The channel is the context.
If it's a thread reply rather than a new post, lose the TL;DR — just lead with the answer.

Length target: under ~80 words for a top-level post; under ~40 for a thread reply.

单条消息，避免大段文字。过多加粗的章节标题会显得"像从JIRA复制过来的"——请勿使用。

第一行是加粗的摘要（TL;DR）。
下方列出2-4个简短项目符号：影响范围、负责人+链接、下一步计划。删除不适用的模块。
嵌入一个链接（如
```
JIRA-12345
```
/
```
PR #5751
```
），不要堆砌多个链接。
无需问候语和结束语，频道上下文已足够。
如果是线程回复而非新帖子，无需摘要——直接给出答案。

长度目标：顶级帖子约80字以内；线程回复约40字以内。

Async standup note

异步站会备注

The audience scans 10 of these in 30 seconds. Front-load the verb.

1–3 lines, max.
Pattern: "<state> <thing>. <owner if not me>. <next>."
Examples:
- "Fixed Tada hang affecting dumbModel runs (JIRA-12345). PR #5751 in review. Backport to v7.2 next."
- "Still chasing the LLM-7B eval-step hang. Reproducer is reliable now; bisecting. No ETA yet."
No bullets, no bolded labels. The format is the sentence.

受众会在30秒内浏览10条此类备注。将动词放在开头。

最多1-3行。
格式："<状态> <事项>。<非本人时的负责人>。<下一步>。"
示例：
- "已修复影响dumbModel运行的Tada挂起问题（JIRA-12345）。PR #5751正在审核中。下一步回移植到v7.2版本。"
- "仍在排查LLM-7B评估步骤挂起问题。现已能稳定复现；正在进行二分查找测试。暂无预计完成时间。"
无需项目符号或加粗标题。句子本身就是格式。

Email — internal exec / cross-team

邮件 — 内部高管 / 跨团队

Subject line is half the value.

Subject: the TL;DR rewritten as a noun phrase. "Tada hang in dumbModel: fix in review (JIRA-12345)."
Greeting: match the recipient register (Hi Sam, / Hi all,).
Body: the JIRA-comment shape, but as flowing paragraphs separated by blank lines rather than bolded section labels. Two or three paragraphs is plenty.
Sign off with the next decision point that needs the recipient's attention, if any. If none, a plain "— [Name]" is fine.

主题行的价值占一半。

主题：将摘要改写为名词短语。例如"Tada在dumbModel中出现挂起：修复方案正在审核（JIRA-12345）。"
问候语：匹配收件人的风格（如"嗨Sam，"/"大家好，"）。
正文：采用JIRA评论的内容结构，但使用分段的流畅段落而非加粗章节标题。2-3段即可。
结束语：如果需要收件人关注某个决策点，可在结尾提及。如果没有，简单的"——[姓名]"即可。

Meeting talking-points

会议讨论要点

You're going to say this, not show it.

Bullet list, max one short clause per bullet.
Order is the order you'll speak in.
Include the numbers/keys you want to reference out loud, in the bullet itself, so you don't fumble.
Skip prose. "dumbModel LLM-7B fine-tuning was hanging." / "Root cause: skipped sync in Tada fast-path." / "Alex's fix in review, PR #5751." / "Backport to v7.2 once it lands."

这是用于口头陈述的内容，而非展示。

项目符号列表，每个项目符号最多包含一个短句。
顺序即为陈述顺序。
将需要口头提及的数字/编号直接放在项目符号中，避免临时查找。
省略散文式描述。例如"dumbModel的LLM-7B微调出现挂起。"/"根因：Tada快速路径中跳过了同步步骤。"/"Alex的修复方案正在审核，PR #5751。"/"合并后回移植到v7.2版本。"

Source material

素材来源

The input is one of:

A JIRA ticket key (e.g.
```
JIRA-12345
```
) → fetch via
```
GET /rest/api/3/issue/<KEY>?fields=summary,status,priority,assignee,comment
```
plus any custom fields your instance uses for technical evaluation — usually the cleanest source of current state. The most recent substantive comment is what to reframe; don't dump the full thread.
Pasted technical text → use directly.
The current conversation → if you (or the user) just produced engineering content and the user now says "now in slack" / "now for the VP," reuse what's in context.

If the source is ambiguous, ask one question and stop.

输入内容分为以下三类：

JIRA工单编号（如
```
JIRA-12345
```
）→ 通过
```
GET /rest/api/3/issue/<KEY>?fields=summary,status,priority,assignee,comment
```
接口获取，加上你的实例用于技术评估的自定义字段——通常这是当前状态最清晰的来源。需重构的是最新的实质性评论；不要直接粘贴整个对话线程。
粘贴的技术文本→ 直接使用。
当前对话内容→ 如果你（或用户）刚产出了工程内容，用户现在要求"转为Slack版本"/"转为给副总裁看的版本"，则复用上下文内容。

如果素材来源不明确，只需提出一个问题并等待回复。

Output flow

输出流程

Confirm the channel if it's not stated.
Produce the draft as a single chat block, formatted as the channel would render it.
Ask where it goes:
- Default: print-only — the user copies it.
- JIRA back-post: only if the user explicitly says so. Show the exact ADF payload, wait for explicit "post it" / "go ahead" / "yes," then
```
POST /rest/api/3/issue/<KEY>/comment
```
  .
- Never post to Slack, email, or any non-JIRA channel from this skill. Hand the draft to the user; they post it.
One iteration is normal, three is a smell. If the user is on the third revision, ask what specific framing/audience assumption you're missing — don't keep tweaking blindly.

确认渠道：如果未明确说明，先确认目标渠道。
生成草稿：作为单个聊天块，按渠道要求的格式呈现。
询问发布方式：
- 默认：仅生成草稿——由用户自行复制使用。
- 回帖到JIRA：仅当用户明确要求时才执行。展示完整的ADF payload，等待用户明确回复"发布"/"继续"/"是"后，再调用
```
POST /rest/api/3/issue/<KEY>/comment
```
  接口。
- 禁止通过本技能直接发布到Slack、邮件或非JIRA渠道。将草稿交给用户，由他们自行发布。
迭代次数：通常一次迭代即可，三次迭代则需警惕。如果用户要求第三次修改，询问具体的框架/受众假设遗漏点——不要盲目调整。

Worked example — same bug, three channels

示例——同一bug，三种渠道呈现

Source (engineering JIRA comment):

Mechanism: the single-stream fast-path in
tadaLaunchPrepare
/
tadaLaunchKernel
/
tadaLaunchFinish
(gated on
scheduler->numStreams == 1 && !plan->persistent
) skipped the cross-stream event between
launchStream
and
handle->shared->deviceStream
. dumbModel hits this gate exactly. Kernel launched before deviceStream's IPC publish / scratch-buffer writes (the ones that populate
scratchBuf
) were visible to launchStream →
scratchBuf == NULL
in the kernel → stray pointer dereference → ring ready-flag read from garbage → thread spins forever.

素材（工程师的JIRA评论）：

机制：
tadaLaunchPrepare
/
tadaLaunchKernel
/
tadaLaunchFinish
中的单流快速路径（由
scheduler->numStreams == 1 && !plan->persistent
触发）跳过了
launchStream
与
handle->shared->deviceStream
之间的跨流事件。dumbModel恰好触发了这个条件。内核在deviceStream的IPC发布/临时缓冲区写入（用于填充
scratchBuf
）对launchStream可见之前就已启动→ 内核中
scratchBuf == NULL
→ 野指针解引用→ 从垃圾数据中读取就绪标志→ 线程永久自旋。

As a JIRA comment

作为JIRA评论

Status: Fixed pending merge. Bug found, fix validated, PR up for review.

Impact: LLM-7B fine-tuning on 8 GPUs would hang every time it tried to evaluate the model — blocking the entire workload. Affects customers using dumbModel (a popular framework for training large models that don't fit on a single GPU), which means most large-model fine-tuning runs on the platform were exposed.

What broke: Our GPU communication library (Tada) skipped an internal synchronization step under a specific configuration that dumbModel happens to trigger. The GPUs ended up reading from an uninitialized buffer and got stuck waiting for a signal that would never arrive. The unsafe shortcut had been in the code for months but wasn't reached by any real workload until now.

A previous fix attempt added a defensive check that hid the symptom in some paths but left the underlying race in place. This new fix removes the unsafe shortcut entirely and tightens the safety check on the device side.

Owner: Alex (Tada team). PR org/platform#5751.

Next steps: code review → merge. Customers hitting this today can disable IPC registration as a temporary workaround.

状态：修复完成，待合并。 已找到bug，修复方案已验证，PR已提交审核。

影响范围： 8 GPU上的LLM-7B微调在每次评估模型时都会挂起——阻塞整个工作负载。影响使用dumbModel（一款流行的大模型训练框架，适用于无法在单GPU上运行的大模型）的客户，这意味着平台上大多数大模型微调任务都受影响。

问题原因： 我们的GPU通信库（Tada）在特定配置下跳过了内部同步步骤，而dumbModel恰好触发了该配置。GPU最终读取了未初始化的缓冲区，并陷入永久等待信号的状态。这个不安全的捷径已存在于代码中数月，但从未被真实工作负载触发，直到现在。

之前的修复尝试 添加了一个防御性检查，在某些路径上隐藏了症状，但未解决底层的竞态问题。本次新修复彻底移除了不安全的捷径，并收紧了设备端的安全检查。

负责人： Alex（Tada团队）。PR org/platform#5751。

下一步计划： 代码审核 → 合并。当前遇到该问题的客户可临时禁用IPC注册作为解决方案。

As a Slack post

作为Slack帖子

Tada hang affecting dumbModel LLM-7B fine-tuning is fixed pending merge. (JIRA-12345)

Skipped synchronization in the comms fast-path → GPUs read uninitialized memory → hang. Latent for months; dumbModel was the first workload to hit it.

Owner: Alex, PR #5751 in review.

Workaround until merge: disable IPC registration.

影响dumbModel LLM-7B微调的Tada挂起问题已修复，待合并。（JIRA-12345）

通信快速路径中跳过同步步骤→ GPU读取未初始化内存→ 挂起。该问题已潜伏数月；dumbModel是首个触发它的工作负载。

负责人：Alex，PR #5751正在审核中。

合并前的临时解决方案：禁用IPC注册。

As a standup note

作为站会备注

Fixed Tada hang on dumbModel LLM-7B (JIRA-12345). Alex's PR #5751 in review. Workaround posted in the ticket; backport to v7.2 next.

What changed between channels: same diagnosis, same owner, same next step. JIRA gets every block. Slack drops "why now" and "previous fix attempt" — too much for the channel. Standup keeps just state + key + owner + next. None of them mention

scratchBuf

tadaLaunchPrepare

已修复dumbModel LLM-7B上的Tada挂起问题（JIRA-12345）。Alex的PR #5751正在审核中。工单中已发布临时解决方案；下一步回移植到v7.2版本。

不同渠道的差异：诊断结果、负责人、下一步计划一致。JIRA包含所有模块。Slack省略了"为何现在出现"和"之前的修复尝试"——这些内容对该渠道来说过于冗长。站会仅保留状态+编号+负责人+下一步计划。所有版本均未提及

scratchBuf

或

tadaLaunchPrepare

。

Rules

规则

Never invent facts to make the rewrite cleaner. If the engineering source says "root cause unknown," the rewrite says "root cause unknown" — do not promote a speculation to a finding for narrative tidiness.
Never strip a JIRA key, PR number, or customer/workload name during de-jargoning. They're the cross-reference bridge — losing them breaks tracking.
Never invent owners. If the source doesn't name one, ask the user — don't guess from
```
git blame
```
or recent commits.
Get sign-off before posting to JIRA. Reuse the jira-check approval flow. Print-only output needs no approval.
Never post to Slack, email, or any non-JIRA channel from this skill. Hand the draft to the user; they post it.
Stay out of advocacy. This skill produces a status update, not a recommendation. If the user wants a recommendation memo, confirm before reframing.

不得编造事实来简化改写内容。如果工程素材中提到"根因未知"，改写后的内容也必须保留"根因未知"——不得为了叙事完整而将推测升级为结论。
在去行话过程中不得删除JIRA编号、PR编号或客户/工作负载名称。这些是跨团队跟踪的桥梁——丢失它们会破坏跟踪体系。
不得编造负责人。如果素材中未提及负责人，询问用户——不要从
```
git blame
```
或最近的提交记录中猜测。
发布到JIRA前需获得确认。复用JIRA审核流程。仅生成草稿无需确认。
禁止通过本技能直接发布到Slack、邮件或非JIRA渠道。将草稿交给用户，由他们自行发布。
避免主观建议。本技能仅产出状态更新内容，而非建议。如果用户需要建议备忘录，需先确认再进行重构。