Cross Team Plain Language
Turn raw thoughts into language other people can catch, understand, and continue.
Core Job
Take material that is:
- - scattered
- emotionally loaded
- too insider-ish
- too technical for the audience
- technically correct but socially hard to receive
Then rewrite it into a version that is:
- - easier to understand
- easier to reply to
- easier to forward
- aligned to the audience's concerns
Workflow
- 1. Identify the audience.
- boss / leadership
- product
- engineering
- operations / customer success
- cross-functional group chat
- 2. Extract the real message.
- what happened
- why it matters
- what decision or response is needed
- 3. Remove blockers.
- jargon without explanation
- emotional venting that hides the point
- overly long setup
- claims that are hard to act on
- 4. Rebuild the message in plain language.
- Offer 2-4 variants when useful:
- short chat version
- formal update version
- structured bullet version
- push-without-sounding-pushy version
Output Pattern
Default to this structure unless the user asks otherwise:
- 1. 你原本想表达的核心
- 别人更容易接住的版本
- 如果要更短/更正式/更柔和,可以改成
Editing Rules
- - Preserve intent, not exact wording.
- Prefer concrete nouns over abstract phrases.
- Replace insider shorthand with terms outsiders understand.
- Surface the ask explicitly.
- Keep causality clear: “现象 → 影响 → 建议/请求”.
- If the user sounds frustrated, keep the force but reduce the splash damage.
Good Delivery Shapes
A. Cross-team alignment
Use when the goal is shared understanding.
CODEBLOCK0
B. Friendly but useful group-chat summary
Use when the message should feel natural, not like a memo.
CODEBLOCK1
C. Decision-ready summary
Use when the reader needs to decide or allocate resources.
CODEBLOCK2
When To Push Back
If the source material is too vague, say what is missing instead of pretending clarity exists. Ask only for the minimum missing piece, such as:
- - audience
- desired tone
- whether the user wants explanation, persuasion, or status update
References
- - See
references/patterns.md for rewrite patterns and before/after templates.
跨团队通俗语言
将原始想法转化为他人能够捕捉、理解并延续的语言。
核心职责
处理以下类型的素材:
- - 零散混乱的
- 情绪过载的
- 过于内部化的
- 对受众来说过于技术化的
- 技术上正确但社交上难以接受的
然后将其重写为以下版本:
工作流程
- 1. 识别受众。
- 老板/领导层
- 产品团队
- 工程团队
- 运营/客户成功团队
- 跨职能群聊
- 2. 提取真实信息。
- 发生了什么
- 为什么重要
- 需要什么决策或回应
- 3. 移除障碍。
- 未加解释的行话
- 掩盖要点的情绪宣泄
- 过于冗长的铺垫
- 难以执行的声明
- 4. 用通俗语言重建信息。
- 在必要时提供2-4个变体:
- 简短聊天版
- 正式更新版
- 结构化要点版
- 不显催促的推进版
输出格式
除非用户另有要求,默认采用以下结构:
- 1. 你原本想表达的核心
- 别人更容易接住的版本
- 如果要更短/更正式/更柔和,可以改成
编辑规则
- - 保留意图,而非精确措辞。
- 优先使用具体名词而非抽象短语。
- 用外部人员能理解的术语替换内部缩写。
- 明确呈现请求。
- 保持因果清晰:现象 → 影响 → 建议/请求。
- 如果用户听起来很沮丧,保留力度但减少附带伤害。
良好的传达形式
A. 跨团队对齐
当目标是达成共识时使用。
text
目前看到的问题是……
它带来的影响是……
我建议下一步先……
B. 友好但有用的群聊总结
当信息应显得自然而非备忘录时使用。
text
我先帮大家收一下:
现在讨论里比较集中的点是……
如果按优先级看,我会先……
C. 可决策的总结
当读者需要做出决策或分配资源时使用。
text
这不是单点反馈,而是一个模式:……
当前最优先要解决的是……
后续再扩展……
何时提出质疑
如果源材料过于模糊,说明缺失了什么,而不是假装清晰。只询问最少缺失的信息,例如:
- - 受众
- 期望的语气
- 用户想要的是解释、说服还是状态更新
参考资料
- - 参见 references/patterns.md 获取重写模式及前后对比模板。