Back to Details

written-communication

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Written Communication

书面沟通

Scope

适用范围

Covers
  • Turning messy notes into a clear email, memo, doc, or async update
  • Making the “how” explicit (what happens next, by whom, by when)
  • Editing for clarity at scale (scanability, definitions, single source of truth)
  • Creating/maintaining a canonical doc for an ongoing project
When to use
  • “Draft an email to stakeholders explaining a change and what I need from them.”
  • “Turn these bullets into a 1-page memo with a recommendation and next steps.”
  • “Rewrite this doc to be clearer, shorter, and more actionable.”
  • “Create a canonical doc as the source of truth for this project.”
When NOT to use
  • You need marketing/brand copy (landing pages, ads) more than internal/executive clarity.
  • You need a full product spec/PRD from scratch (use 
    writing-prds
    or 
    writing-specs-designs
    ).
  • You’re writing legal/HR/regulated communications without expert review.
  • The real issue is alignment via facilitation (you may need a meeting/offsite plan, not a rewrite).
涵盖内容
  • 将杂乱的笔记转化为清晰的邮件、备忘录、文档或异步更新内容
  • 明确说明**“后续行动”**（下一步做什么、负责人、截止时间）
  • 批量优化内容清晰度（易读性、术语定义、单一信息源）
  • 为持续推进的项目创建/维护标准文档（canonical doc）
适用场景
  • “起草一封给利益相关者的邮件，说明变更内容以及我对他们的需求。”
  • “将这些要点转化为1页纸的备忘录，包含建议和后续步骤。”
  • “重写这份文档，使其更清晰、简洁且更具可操作性。”
  • “创建一份标准文档作为该项目的单一信息源。”
不适用场景
  • 你需要的是营销/品牌文案（着陆页、广告）而非内部/管理层沟通的清晰表达。
  • 你需要从零开始撰写完整的产品需求文档/PRD（请使用
    writing-prds
    或
    writing-specs-designs
    ）。
  • 在没有专家审核的情况下撰写法律/HR/合规类沟通内容。
  • 核心问题是通过协作达成共识（你可能需要会议/线下计划，而非重写内容）。

Inputs

输入要求

Minimum required
  • Artifact type + channel (email / memo / doc / status update; where it will live)
  • Audience (roles/seniority) + what they care about
  • Goal + ask (inform/align/decide; what you want the reader to do, by when)
  • Key context (facts, constraints, timeline, links) + what must be avoided (sensitivities)
  • Source material (notes, existing draft, Slack threads, etc.)
Missing-info strategy
  • Ask up to 5 questions from references/INTAKE.md (3–5 at a time), then proceed.
  • If critical info remains missing, make explicit assumptions and offer 2–3 options (structure/tone/ask).
最低要求输入
  • 文件类型+发布渠道（邮件/备忘录/文档/状态更新；发布位置）
  • 受众（角色/职级）+他们的关注点
  • 目标+诉求（告知/对齐/决策；你希望读者做什么、截止时间）
  • 关键背景（事实、约束条件、时间线、链接）+需要避免的内容（敏感点）
  • 原始素材（笔记、现有草稿、Slack对话等）
缺失信息处理策略
  • 从references/INTAKE.md中最多提出5个问题（每次3-5个），然后继续推进。
  • 如果关键信息仍缺失，明确做出假设并提供2-3个选项（结构/语气/诉求）。

Outputs (deliverables)

交付成果

Produce a Written Communication Pack in Markdown (in-chat; or as files if requested):
  1. Message brief (audience, goal, ask, constraints)
  2. Outline (TL;DR + key points + “how/next steps”)
  3. Draft artifact (email/memo/doc/status update) in final-ready format
  4. Canonical doc skeleton (optional; when the project needs a single source of truth)
  5. Risks / Open questions / Next steps (always)
Templates: references/TEMPLATES.md
Expanded guidance: references/WORKFLOW.md
生成Markdown格式的书面沟通包（可在对话中展示；或按要求生成文件）：
  1. 沟通简报（受众、目标、诉求、约束条件）
  2. 大纲（TL;DR+核心要点+“后续行动”）
  3. 文件草稿（邮件/备忘录/文档/状态更新），格式可直接使用
  4. 标准文档框架（可选；当项目需要单一信息源时）
  5. 风险/待解决问题/后续步骤（必含）
模板：references/TEMPLATES.md
扩展指南：references/WORKFLOW.md

Workflow (8 steps)

工作流程（8步）

1) Intake + choose the lightest artifact

1) 信息收集+选择最简文件类型

  • Inputs: user request + references/INTAKE.md.
  • Actions: Clarify the channel and pick the smallest artifact that works (email vs memo vs doc vs status update vs canonical doc).
  • Outputs: Message brief (draft) + artifact selection.
  • Checks: You can answer: “Who is this for, and what should they do after reading?”
  • 输入：用户请求 + references/INTAKE.md
  • 行动：明确发布渠道，选择最适用的最简文件类型（邮件vs备忘录vs文档vs状态更新vs标准文档）
  • 输出：沟通简报（草稿）+ 文件类型选择结果
  • 校验：能够回答“这份内容是给谁的，读者看完后需要做什么？”

2) Lock the reader outcome + ask (one sentence)

2) 锁定读者预期结果+明确诉求（一句话）

  • Inputs: brief.
  • Actions: Write one sentence: “After reading, the audience will ____.” Make the ask explicit (decision/options, approval, feedback, or FYI) and include a deadline if relevant.
  • Outputs: Outcome/ask line + decision/feedback request.
  • Checks: The ask is unambiguous and doesn’t require a meeting to interpret.
  • 输入：沟通简报
  • 行动：用一句话表述：“读者看完后会____。” 明确诉求（决策/选项、批准、反馈或仅告知），若相关则包含截止时间。
  • 输出：预期结果/诉求说明 + 决策/反馈请求
  • 校验：诉求清晰明确，无需通过会议进一步解读。

3) Convert “what/why” into “how” (actionable next steps)

3) 将“内容/原因”转化为“行动”（可落地的后续步骤）

  • Inputs: source material + outcome/ask.
  • Actions: Identify the 3–7 concrete steps, responsibilities, and dependencies. If proposing a change, include what changes, what stays the same, and what happens next.
  • Outputs: “How / Next steps” bullets (owner + date where possible).
  • Checks: A reader could execute without asking “so what do you want me to do?”
  • 输入：原始素材 + 预期结果/诉求
  • 行动：梳理出3-7个具体步骤、责任人及依赖关系。若提议变更，需说明变更内容、保留内容及后续行动。
  • 输出：“后续行动”要点（尽可能包含负责人+截止时间）
  • 校验：读者无需追问“那我该做什么？”即可执行。

4) Structure for skim (clarity at scale)

4) 优化结构以提升易读性（批量优化清晰度）

  • Inputs: brief + next steps.
  • Actions: Create a TL;DR, then headings in the order readers scan: Ask → Context → Details → Next steps. Use bullets, short paragraphs, and explicit labels.
  • Outputs: Outline with headings.
  • Checks: A skim-reader can capture the point in < 60 seconds.
  • 输入：沟通简报 + 后续步骤
  • 行动：撰写TL;DR（摘要），然后按读者阅读顺序设置标题：诉求→背景→细节→后续步骤。使用要点、短段落和明确标签。
  • 输出：带标题的大纲
  • 校验：快速浏览的读者能在60秒内抓住核心要点。

5) Draft the artifact (write to be forwarded)

5) 起草文件（内容需适合转发）

  • Inputs: outline + templates.
  • Actions: Draft in plain language; avoid jargon; put key numbers and decisions in writing. If this is ongoing work, link to (or create) the canonical doc.
  • Outputs: Draft email/memo/doc/status update.
  • Checks: The draft is safe to forward; it stands alone without verbal context.
  • 输入：大纲 + 模板
  • 行动：用平实语言撰写；避免行话；将关键数据和决策落实到书面。如果是持续推进的工作，链接到（或创建）标准文档。
  • 输出：邮件/备忘录/文档/状态更新草稿
  • 校验：草稿可直接转发，无需额外口头说明即可独立理解。

6) “Letter to yourself” clarity pass (then rewrite for the audience)

6) “写给自己”的清晰度校验（再按受众视角重写）

  • Inputs: draft.
  • Actions: If the content is fuzzy, write a quick internal version (“what am I actually saying?”), then rewrite in the audience’s language and incentives.
  • Outputs: Clarified rewrite with cleaner logic.
  • Checks: The message has a single through-line; no contradictions or buried ledes.
  • 输入：草稿
  • 行动：若内容模糊，先快速写一份内部版本（“我实际想表达什么？”），再按受众的语言和关注点重写。
  • 输出：逻辑更清晰的重写版本
  • 校验：内容有单一主线；无矛盾或隐藏核心信息。

7) Canonical doc check (single source of truth)

7) 标准文档校验（单一信息源）

  • Inputs: draft + project context.
  • Actions: If readers will keep asking “where is the latest?”, create/update a canonical doc (links, owners, last updated, decisions, next update cadence).
  • Outputs: Canonical doc skeleton or link section.
  • Checks: There is one obvious place to find the current state and decisions.
  • 输入：草稿 + 项目背景
  • 行动：若读者会反复询问“最新内容在哪里？”，则创建/更新标准文档（包含链接、负责人、最后更新时间、决策内容、下次更新周期）。
  • 输出：标准文档框架或链接板块
  • 校验：存在一个明确的渠道可获取当前状态和决策信息。

8) Quality gate + finalize

8) 质量校验+最终定稿

  • Inputs: full pack.
  • Actions: Run references/CHECKLISTS.md and score with references/RUBRIC.md. Add Risks/Open questions/Next steps.
  • Outputs: Final Written Communication Pack.
  • Checks: Clarity, actionability, and ownership meet the bar (≥ 3 on each rubric dimension).
  • 输入：完整沟通包
  • 行动：对照references/CHECKLISTS.md检查，并使用references/RUBRIC.md评分。添加风险/待解决问题/后续步骤。
  • 输出：最终版书面沟通包
  • 校验：清晰度、可操作性和责任归属达到标准（每个评分维度≥3分）。

Quality gate (required)

质量校验环节（必做）

  • Use references/CHECKLISTS.md and references/RUBRIC.md.
  • Always include: Risks, Open questions, Next steps.
  • 使用references/CHECKLISTS.md和references/RUBRIC.md。
  • 必须包含：风险、待解决问题、后续步骤。

Examples

示例

Example 1 (stakeholder email): “Draft an email to exec stakeholders: the launch is slipping 2 weeks; we need approval to cut scope and a decision by Friday.”
Expected: TL;DR + explicit ask/options + what changes + next steps with owners.
Example 2 (project memo + canonical doc): “Turn these notes into a 1-page memo that aligns the team on the new onboarding approach, and create a canonical doc outline for ongoing updates.”
Expected: memo with recommendation + tradeoffs + next steps, plus a source-of-truth doc skeleton.
Boundary example: “Write a legal/HR disciplinary notice.”
Response: decline to fabricate legal/HR guidance; request expert review; offer to help with neutral structure, tone, and clarity if the user provides approved language.
示例1（利益相关者邮件）：“起草一封给高管利益相关者的邮件：发布时间将推迟2周；我们需要获批缩减范围，并在周五前得到决策。”
预期输出：TL;DR + 明确诉求/选项 + 变更内容 + 带责任人的后续步骤。
示例2（项目备忘录+标准文档）：“将这些笔记转化为1页纸的备忘录，让团队对齐新的入职流程，并创建一个标准文档框架用于后续更新。”
预期输出：包含建议+权衡+后续步骤的备忘录，以及作为单一信息源的文档框架。
边界示例：“撰写一份法律/HR纪律通知。”
回应：拒绝生成未经审核的法律/HR指导内容；请求专家审核；若用户提供已获批的内容，可协助优化结构、语气和清晰度。