--- slug: "professional-communication-free" name: "professional-communication-free" version: "1.0.0" displayName: "职场沟通写作免费版" summary: "为技术团队生成状态更新邮件、升级请求与 Slack/Teams 消息，遵循关键信息优先、可扫描、明确行动项的核心原则。" summary_zh: "为技术团队生成状态更新邮件、升级请求与 Slack/Teams 消息，遵循关键信息优先、可扫描、明确行动项的核心原则。" license: "MIT" description: |- 面向技术团队的入门级职场沟通写作助手。覆盖状态更新邮件、升级 请求、Slack/Teams 即时消息三个基础场景。核心原则是关键信息优先、 可扫描格式、明确行动请求。每条消息回答三个问题：你需要知道什么、 为什么重要、需要什么行动。内置四条基础规则与永不清单：主题行 讲清故事、项目符号替代段落、具体行动请求带时间、渠道匹配正式度. 拒绝"Just checking in"无上下文、被动语态、文字墙、不必要的回复 全部等典型职场沟通病灶。覆盖场景与模板深度为本系列免费版本， 付费版扩展至技术概念转译、异步团队协作、跨文化沟通等更多场景. tags: - 邮件 - agent - slack - 项目符号 - api - 行动请求 tools: - read - exec - write homepage: "" category: "Automation" --- # 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="your_api_key_here" ``` 配置后需重启会话或开启新终端生效。API Key应妥善保管,避免泄露到版本控制系统.