职场沟通写作免费版

为技术团队生成结构清晰、重点突出、行动明确的状态更新邮件、升级请求及Slack/Teams消息，提升职场沟通效率与效果。

Professional Communication Free

写出清晰、有效、会被读到并被行动的职场消息。技术团队的写作问题通常不是文笔问题，而是结构问题——关键信息埋在第三段、行动请求模糊、渠道错配。本 Skill 用结构化模板与硬规则消除这些病灶.

输入格式

参数名	类型	必填	说明
input	string	是	职场沟通写作免费版处理的输入数据或指令
options	object	否	附加配置选项,如模式选择、格式偏好等
callback_url	string	否	异步处理完成后的回调通知URL

核心能力

关键信息优先。可扫描格式。明确行动请求。

每条职场消息回答三个问题：

• 你需要知道什么？
• 为什么重要？
• 需要什么行动（若有）？

这三问决定主题行、首句、结构、结尾。任何不回答这三问的消息都需要重写.

快速开始

1. 确认运行环境满足依赖说明中的要求
2. 在AI Agent对话中调用本技能,提供必要的输入参数
3. 检查输出结果,根据需要进行后续处理

详细的输入输出格式请参考下方章节说明。

使用流程

1. 环境确认: 确认Agent平台已加载本skill，检查依赖说明中的环境要求
2. 指令输入: 向Agent描述需要执行的任务，引用professional-communication-free的相关能力
3. 执行处理: Agent按照核心能力章节的指令执行任务
4. 结果验证: 检查输出结果是否符合预期，参考错误处理章节处理异常

四条规则

规则一：主题行讲清故事

"Project X: Decision Needed by Friday"胜过"Question"。主题行必须包含主题、目的、时间敏感性三个维度中的至少两个。收件人扫一眼主题行就知道要不要立刻打开、要不要回复.

规则二：项目符号替代段落

没人读文字墙。把段落拆成项目符号，每条一个完整想法，不超过两行。段落仅用于叙事性背景，且不超过两句.

规则三：具体行动请求带时间

"Please review by Thursday"胜过"Let me know"。行动请求必须包含：谁、做什么、什么时候。模糊请求等于没有请求.

规则四：渠道匹配正式度

聊天（Slack/Teams）用于快速、非正式、即时回复；邮件用于记录、正式、跨时区。渠道错配是职场沟通最常见的浪费——把本该发邮件的内容丢进聊天，三天后就找不到了.

消息结构速查

text

Subject: [主题]: [具体目的]
# ...
[1-2 句：关键点或请求前置]
# ...
**Context:** (若需要)
- 项目符号，不是段落
# ...
**Action Needed:**
- 具体请求 + 时间线

这是默认骨架。不同场景在这个骨架上变形，但关键信息优先与行动请求明确两条不变.

永不清单

• 领先句没有明确目的。任何"Hi"、"Hope you're well"、"Just reaching out"开场后不接正题的消息都要重写.
• "Just checking in"无上下文。要么说在跟进什么、上次说到哪、这次需要什么，要么不要 check in.
• 段落代替项目符号。可扫描格式是硬规则，文字墙是违约.
• 把请求埋在底部。请求必须在首句或第二段开头出现，不在结尾.
• 聊天里发文字墙。超过 5 行就开 thread 或转邮件.
• 不必要的回复全部。回复全部前问自己：所有人都需要看到这条吗？大多数答案是不.
• 被动语态当主动语态用。"We decided"胜过"It was decided"。被动语态隐藏责任人.

适用场景

状态更新邮件

每周或每两周向经理发送项目进度。结构：主题行含项目名与"Status Update + 日期"；首句一句话总结整体状态（on track / at risk / blocked）；项目符号列出本周完成、下周计划、风险与阻塞；结尾明确是否需要决策或行动。拒绝流水账——经理不需要知道你开了多少会，只需要知道项目是否能按时交付.

升级请求

项目遇到阻塞需要上级介入。结构：主题行含"Escalation"与项目名与阻塞点；首句直接说需要什么决策或资源；项目符号列出已尝试的方案与结果；结尾给出建议的决策与时间窗口。升级邮件不是抱怨邮件——必须包含你已经做了什么、为什么需要上级、建议的解决方案。没有建议的升级等于把猴子甩给上级.

Slack/Teams 即时消息

快速同步、非正式确认、即时反馈。结构：开头明确这是请求还是 FYI；正文不超过 5 行，超出就开 thread；结尾若需要行动，给出具体动作与时间。聊天消息的最大敌人是模糊——"稍后看一下"等于没说，"今天下午三点前回复能否采用方案 A"才是有效请求.

案例示范

案例一：状态更新邮件

输入背景：项目代号 Atlas；本周完成 API 迁移与性能测试；下周计划灰度发布；风险是第三方依赖延迟两天；需要经理决定是否推迟灰度. 输出：

text

Subject: Atlas: Status Update — On Track, Decision Needed by Wed
# ...
Atlas 本周按计划推进，灰度发布前需要一个决策.
# ...
**Completed this week:**
- API v2 迁移完成，旧端点已下线
- 性能测试通过，p99 延迟从 420ms 降到 180ms
# ...
**Planned for next week:**
- 周二开始 5% 灰度
- 周四 review 灰度指标
# ...
**Risks:**
- 第三方风控依赖延迟两天，可能影响灰度期间的异常订单处理
# ...
**Action Needed:**
- 周三前决定：灰度按计划推进，还是推迟到下周等依赖就位
- 我的建议：按计划推进，灰度期间手动兜底异常订单，预计每天 3-5 单

案例二：Slack 即时消息

输入背景：需要同事张三在今天下午前 review 一份迁移文档；不紧急但有时间约束. 输出：

text

@张三 请求 review：API v2 迁移文档，今天 18:00 前回复能否采用方案 A.
# ...
背景：方案 A 保留旧端点两周，方案 B 直接下线。我倾向 A，风险低.
若今天无异议，明天按 A 推进.

异常处理

用户只给主题没给背景

用户说"帮我写一封项目延期通知邮件"但不提供项目名、延期原因、影响范围、新时间线。处理：先按通用结构生成草稿，所有需要用户补充的位置用方括号占位标出（如 [项目名]、[新时间线]），并在草稿末尾列出"发布前请确认"的清单。不要编造项目名或时间线.

用户要求用非正式语气写正式场合

用户要求用"轻松一点"的语气写发给 VP 的升级邮件。处理：区分"清晰简洁"与"非正式"。清晰简洁是默认风格，VP 也欢迎；非正式（俚语、缩写、表情符号）在升级邮件里是违约。坚持正式但简洁的语调，向用户说明为什么这里不能太随意.

行动请求模糊

用户写"希望大家关注一下这个问题"。处理：追问三个具体化——谁、做什么、什么时候。把模糊请求改写为"张三在本周三前给出迁移方案，李四在周五前 review"。若用户无法提供具体信息，提示这条消息可能不该发——没有具体行动请求的消息通常是 FYI 而非 Action.

渠道选择错误

用户要把一份需要留档的决策发到 Slack 群。处理：提示决策类内容应走邮件或文档，Slack 适合讨论不适合留档。若用户坚持发 Slack，建议在 Slack 讨论后用邮件总结决策并发送留档链接.

收件人列表过大

用户在回复全部时抄送了整个部门。处理：提示"回复全部"前先问"所有人都需要看到这条吗"。多数情况下只需要保留直接相关方。给一个判定标准：若某人在未来一周不会基于这条消息采取行动或决策，就移出收件人列表.

常见问题

Q1: 主题行多长合适？

主题行长度以收件人预览面板能完整显示为准，桌面端约 50-60 字符，移动端约 30-40 字符。关键信息（项目名、目的、时间敏感性）放在前 30 字符内。不要写成句子，写成"主题: 目的 + 时间"的紧凑格式.

Q2: 什么时候用邮件，什么时候用聊天？

需要留档、跨时区、正式决策、长背景——邮件。需要即时反馈、快速确认、非正式讨论——聊天。简单判定：三天后还需要找到这条消息吗？需要则邮件，不需要则聊天.

Q3: 升级邮件会不会显得我没能力？

不会，前提是升级邮件包含你已经尝试的方案、为什么需要上级、建议的解决方案。这种升级是职责清晰的表现。没有建议、没有尝试记录的升级才会显得甩锅.

Q4: 项目符号每条多长合适？

每条不超过两行，一个完整想法。若一个想法需要超过两行，要么拆成两条，要么说明信息密度太高需要重新组织。项目符号不是段落的换行版，是独立的信息单元.

错误处理

错误场景	原因	处理方式
LLM响应超时或无响应	网络延迟或模型负载过高	检查网络连接和配置后重试；确认Agent平台LLM服务正常
输入内容格式不正确	用户输入不符合skill预期格式	检查输入是否符合skill使用说明中的格式要求，参考示例章节
执行结果与预期不符	指令描述不够明确或上下文不足	提供更详细的指令描述，补充必要的上下文信息
命令执行失败	运行环境不满足要求或权限不足	确认运行环境符合依赖说明中的要求；检查命令权限设置

已知限制

• 仅覆盖状态更新邮件、升级请求、Slack/Teams 消息三个基础场景，不包含技术概念转译、异步团队协作、跨文化沟通、会议议程与纪要等深度场景.
• 基于结构化模板与硬规则，不替代对具体业务语境的判断。涉及政治敏感、文化差异、个人冲突的沟通需要人工审阅.
• 主题行与行动请求的有效性依赖用户对收件人优先级的准确判断。Skill 无法知道某位 VP 是否真的关心某个项目.
• 不生成法律、合规、HR 类正式函件。这类文档需要法务或 HR 团队审核.
• 不替代面对面沟通。涉及情绪、冲突、绩效问题的对话应优先当面或视频.
• 模板反映主流技术团队的沟通习惯，传统行业或非技术团队可能需要调整风格.

升级提示

本免费版覆盖状态更新邮件、升级请求、Slack/Teams 消息三个基础场景与四条核心规则。若你需要技术概念向非技术受众转译、异步跨时区团队协作、会议议程与纪要、远程团队沟通规范、跨文化正式度调整等更细颗粒度的场景模板，可升级到付费版 professional-communication，解锁完整场景矩阵与更深入的异常处理清单.

依赖说明

运行环境

• Agent平台: 支持SKILL.md的任意AI Agent（Claude Code / Cursor / Codex / Gemini CLI等）
• 操作系统: Windows / macOS / Linux

依赖项

依赖项	类型	是否必需	获取方式
LLM API	API	必需	由Agent内置LLM提供

API Key 配置

需要配置对应API Key，详见上文环境配置章节

可用性分类

• 分类: MD+EXEC（）

API Key配置方式:

bash

export API_KEY=${API_KEY:?请设置环境变量}

配置后需重启会话或开启新终端生效。API Key应妥善保管,避免泄露到版本控制系统.