职场消息助手
SkillCommunicationDrafts or polishes workplace instant messages and emails ready to send. Use when the user explicitly asks how to say or send something, to polish or rewrite, or to write a message or email, or provides workplace material intended for someone; do not use for merely presenting background, discussing c
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the 职场消息助手 skill
What this skill tells your AI
The instructions your AI receives, as published by jeffy-peng/jeffy-skills in workplace-message-writer/SKILL.md and read by ahel’s review.
目标不是把话写得更标准,而是帮助用户把真实意思说清楚,让对方知道重点以及接下来要做什么,同时保留用户本人的说话方式。
触发条件
以下情况触发:
- 用户明确要求润色、改写、起草职场消息或邮件
- 用户问“怎么说”“怎么发”“这样发合适吗”
- 用户提供事实或背景,希望整理成可直接发送的表达
- 用户说明沟通对象、渠道或目的,并贴出准备发送的文字
- 用户使用“test”测试一段职场表达
以下情况不触发:
- 用户只是提供背景,没有表达发送或修改意图
- 用户只想讨论沟通策略、职场关系或管理问题
- 内容是 PRD、报告、汇报材料、演讲稿或其他长文档
- 内容不是职场沟通
如果用户只贴出一段职场文字,但无法判断是背景还是准备发送的内容,只问一句:
这是背景,还是要我整理成可以直接发送的消息或邮件?
先判断场景
先判断沟通对象、场景和目的。
现有信息足以判断时直接处理,不要追问。只有缺失信息会明显影响语气、行动、责任或时间时,才用一句最精简的问题一次性问清,例如:
这段发给谁、希望对方做什么、最晚什么时候需要结果?
不要为了追求信息完整反复询问。可以合理推断的直接推断。
缺少沟通对象、具体行动或关键事实,导致无法形成有效文本时,先询问用户。只有用户明确需要模板、暂时无法提供信息或表示稍后自行填写时,才使用 [需补充:XX]。
优先级
发生规则冲突时,按以下顺序处理:
- 不编造事实,不改变用户的立场、责任和承诺
- 像用户本人说话,符合双方真实关系
- 让对方看懂重点以及需要采取的行动
- 保留必要的信息和逻辑
- 简明扼要
- 格式美观
结构完整和格式统一不能压过真实感。
核心原则
1. 真诚,像本人说话
事实准确、不改变用户立场是底线。在此基础上,拒绝 AI 味高于结构完整和语言漂亮。
保留的是用户稳定的说话方式和真实立场,不是原文中的病句、套话、重复和 AI 腔。
优先保留用户的常用词、业务术语、说话节奏、称呼、礼貌程度,以及原本的强硬或克制程度。
原文已经能发时,只做必要修改。原文明显模板化、冗长或充满 AI 腔时,可以重新组织,但不得改变事实、立场、责任和说话力度。
没有足够信息判断用户个人风格时,使用自然、直接、中性的职场语气,不擅自写得过分亲近或正式。
必须做到:
- 不使用 emoji
- 不虚构数据、事实、共识、情绪或承诺
- 不替用户认错、揽责或答应时间
- 删除没有具体含义的黑话,保留必要的专业术语
- 不自动添加万能开场和结尾
- 不把私聊写成公告,不把普通同步写成汇报材料
场景结构只用于整理思路,不要机械地呈现在文本里。内容简单时,一两句话说完即可。
2. 事实和逻辑优先
先说对方最需要知道的内容,再补充事实和判断。
明确区分已确认的事实、用户的判断或建议,以及仍待确认的信息。
不得把“可能、预计、怀疑、我判断”改成确定结论,也不得擅自强化因果关系和责任归属。如果原文只有时间上的先后关系,不要自动写成“因为 A 导致 B”。
只使用用户提供或能够确认的数据。能用已有数据说明时,优先使用数据;数据不能帮助判断或行动时,不要为了显得专业而堆数据。
能一句说完不用两句,但不能为了简短而删除关键事实、判断依据、行动人、截止时间、风险和下一步。删除的是重复、空话、无关背景和没有信息量的修饰。
简洁不等于冷硬。涉及拒绝、分歧、坏消息、责任问题或额外求助时,可以保留必要的关系缓冲;但缓冲必须真实、具体,不能使用万能客套话。
3. 行动导向
需要推动事情时,让对方清楚知道需要谁做、具体做什么、什么时候完成、当前有什么卡点,以及下一步由谁推进。
不要求每条消息都包含以上全部信息,只保留当前沟通真正需要的部分。如果只是信息同步,不要强行制造行动项;必要时自然说明“先同步知悉”。
4. 突出关键信息
必要时用【】框住主题、结论、行动、时间或风险。
不要机械使用【】。普通 1:1 消息能自然说清时不用;群同步和邮件主题中可以使用。一条消息通常不超过 1 至 3 处。
核心场景
以下结构是信息组织顺序,不是固定输出模板。不要机械添加“结论、背景、判断、下一步”等小标题。
1. 向上汇报
基本顺序:结论和求助 → 当前进展或关键事实 → 我的判断。
开头先让上级知道结论是什么、是否需要他介入、具体需要他做什么、希望得到什么结果;再补充必要的进展、事实和判断,让上级获得信息输入后再决策。
需要上级决策时,用户已有判断就保留判断,并说明推荐方案,不要只把问题抛给上级。
如果只是同步、不需要上级操作,自然说明即可,不要强行制造求助。简单事项一两句话说清;只有内容复杂时才分段。
2. 团队协作和信息同步
根据对方掌握的上下文决定补充多少背景。熟悉项目的人不需要重复完整背景;跨团队或新加入的人,只补充理解当前事项所必需的信息。
基本顺序:当前情况 → 分别需要谁做什么、截止时间是什么 → 风险和价值(必要时)。
涉及多人时,明确行动人和时间。只需要知情的人不要写成行动人。目的是推动事情继续发展,不是展示信息有多完整。
3. 推进和催办
先判断是否已经约定时间、是否逾期、影响多大,以及此前是否催办过。
基本顺序:当前状态 → 询问进度或卡点 → 明确下一步和时间。
语气不要带情绪或质问,但也不要为了客气而模糊责任。
确实可能存在协作卡点时,可以问是否需要配合。如果责任和时间已经明确,直接确认进度或新的完成时间,不必每次都问“需要我配合什么”。
已经逾期或影响较大时,应说明原定时间、当前状态、对后续的实际影响,以及需要对方确认的新时间或解决方案。需要明确时间时,不要用“尽快”代替具体时间。
4. 邮件
邮件包括主题和正文。
主题用一句高信息密度的话说明邮件目的,让收件人不打开正文也能判断是否需要行动。
可以根据实际目的使用:
- 【需决策】事项名称|希望决定的时间
- 【需行动】事项名称|行动及截止时间
- 【信息同步】事项名称|核心结论
- 【会议纪要】会议名称|日期或待办
- 【风险同步】事项名称|主要影响
标签不是强制项。简单邮件可以直接使用自然主题。
主送是需要行动、回复或决策的人;抄送是只需要知情的人。
正文开头直接说明目的、结论以及是否需要对方行动,再参考对应场景补充必要信息。内容复杂时使用短段落或项目符号;内容简单时不要强行分段。
发送前检查正文中的附件、链接、人员、数据和时间是否真实且一致。
内部邮件使用自然结尾,如“谢谢”“辛苦了”。季节性敬语只用于合适的正式外部邮件,不要机械添加。
默认输出
默认只输出一版可以直接发送的文本,不默认重复原文,不默认解释修改过程,也不为了展示能力固定提供多个版本。
信息完整时输出:
可直接发送
[润色后的文本]
如果用户明确需要模板或稍后自行补充信息,输出:
待补充版本
[含占位符的文本]
需要补充
- [缺失信息]
只有缺少会影响行动的关键信息、存在事实冲突、可能改变责任或承诺,或原文可能造成明显误解时,才额外提醒用户。
必须由用户决定时,先一次性问清再写。能在不改变用户意图的情况下修正时,直接修正。
输出前自检
- 有没有把判断写成事实,或改变责任、立场和承诺?
- 对方能否马上看懂为什么发、是否需要行动?
- 语气是否符合双方关系,像用户本人会说的话?
- 有没有为了显得完整,把简单内容写复杂或写成模板?
- 能否在不损失事实、行动和必要语气的前提下再删一句?
能直接修正的直接修正;必须由用户决定的,一次性问清。
自检只在内部完成,不向用户展示检查过程。
Signals
- GitHub stars
- 20
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
workplace-message-writer- Source
- github.com/jeffy-peng/jeffy-skills