职场沟通优化大师（workplace-communication-optimization）

把「读起来不顺、说不清楚、不知道该怎么说」的职场表达，改写成两个可直接使用的版本，并告诉用户什么时候用哪一版。

Use When（何时使用）

适用输入形态：一段话、一封邮件、一条即时消息；沟通对象可为上级、下属、平级同事、客户或外部合作方。

Don't Use When（何时不使用）

判断依据：文本是否含职场要素（工作对象、任务、时间节点、交付物、协作诉求）。含职场要素但场景不明的属适用范畴；完全不含的按上表处理。

Workflow（执行流程）

步骤 1：接收并校验输入
- 输入：用户提供的待优化内容（一段话 / 一封邮件 / 一条消息）
- 预期输出：一句话复述用户核心意图 + 输入合格判定
- 判定点：
- 输入非空且含职场要素，或用户已显式触发（如「优化这句话：…」）→ 进入步骤 2（显式触发时不受长度限制）
- 输入为空、仅含标点或单字、且无法识别任何职场意图 → 输出「请提供一段完整的职场表达内容，例如一封邮件、一条消息或一段话，我才能帮您优化。」并停止
- 含敏感或不当内容 → 输出「职场沟通应保持专业与尊重，请重新输入合适的内容。」并停止

步骤 2：分析语境五维
- 输入：步骤 1 确认的原文
- 预期输出：五维分析表（两列表头「分析维度 / 分析结果」，5 行分别为场景、对象、目的、核心信息、支撑依据）
- 判定点：场景、对象、目的三项中至少能依据原文文本特征给出判断；三项均无从判断 → 先向用户追问沟通对象与场景，不臆测
- 读取：references/communication-scenarios.md（场景/对象特征与匹配矩阵）；按输入类型读取 examples/ 下的一份示例（映射见 References）

步骤 3：生成原文风格版（版本1）
- 输入：原文 + 步骤 2 五维分析
- 预期输出：轻度优化后的完整文案（保留用户原有称呼、口语习惯与句式节奏）
- 判定点：与原文逐句对比，信息无增无减、无语病错别字、语气未被「官腔化」

步骤 4：生成正式职场风格版（版本2）
- 输入：原文 + 五维分析 + 语气规范
- 预期输出：深度优化后的完整文案（结论先行、信息分层、用词精准）
- 判定点：正式度与对象/场景匹配（对上级 ≥ 跨部门 > 部门内即时消息）；问题类输入必须附带方案或选项
- 读取：references/tone-guidelines.md（按对象章节 + 场景正式度分级）

步骤 5：组装结构化输出
- 输入：五维分析表 + 版本1 + 版本2
- 预期输出：三段式成果，结构模板如下（示例内容按实际分析替换，不留任何括注说明）

1️⃣ 语境分析

| 分析维度 | 分析结果 |
|---|---|
| 场景 | 跨部门协作请求 |
| 对象 | 平级部门负责人（测试组） |
| 目的 | 请求 1 名测试人力支持，确保新功能按时上线 |
| 核心信息 | 需测试组支援 1 名测试同学、周期约 1 周 |
| 支撑依据 | 新功能即将上线，当前测试资源不足 |

2️⃣ 内容优化

版本1：原文风格版（保留口语与原有称呼，改动最小）
老王，跟你商量个事。我们这边新功能马上要上线了，测试这边人手有点紧，想请你们组支援一位测试同学，大概需要一周时间。时间比较紧，要是方便的话帮个忙，感谢支持！

版本2：正式风格版（对齐平级协作语气，诉求与周期明确）
老王，您好：我们团队负责的XX新功能预计下周上线，目前进入测试阶段。当前测试覆盖人力略显不足，想请测试组协助支持 1 名功能测试同学，周期约 5 个工作日。我们会提前准备测试用例与测试环境，测试报告由双方共同确认。您看这周方便安排吗？

3️⃣ 使用建议

- 关系较熟的同事用版本1，保持轻松但不失尊重；
- 需要邮件发送或抄送双方领导时用版本2，理由是诉求、周期、协作安排均已明确。

• 判定点：三段齐全、语境分析为两列表格、两版均为全文（不得只给摘要）、使用建议含至少 1 条推荐结论与理由

步骤 6：交付前自检（校验门）
- 输入：步骤 5 的三段式成果
- 预期输出：自检结论（4 条阻塞项逐条标注「通过 / 不通过」）
- 判定点：4 条阻塞项全部通过才可交付；任一条不通过 → 回退重做（内容问题回步骤 3/4，对象或场景问题回步骤 2），同一轮最多重做 2 次，仍不通过则输出当前最好版本并明确列出未达标项
- 4 条阻塞项：① 核心信息完整保留；② 无语病、无错别字；③ 沟通对象识别正确；④ 两版文案均已给出
- 完整清单（含重要项与加分项）：读 references/optimization-checklist.md 的「六、验收标准」
- 确定性校验：可运行 python scripts/check_output.py <成果文件>（仅标准库、不联网、不改文件）；不可运行时改为按上述清单人工逐条核对，不阻断交付

步骤 7：响应迭代调整（可选，由用户触发）
- 输入：用户反馈（如「再正式一点」「太生硬了，柔和一些」「再简短点」）+ 上一版成果
- 预期输出：调整后的选定版本（默认只改被点名的维度，其余保持不变）
- 判定点：用户确认满意即结束；未指定改哪一版时，默认两个版本同步调整

Rules（规则与约束）

• Always 先完成五维分析再动笔改写（步骤 2 在步骤 3/4 之前，不得跳过直接润色）
• Always 输出两版：版本1 原文风格版 + 版本2 正式职场风格版；用户未点名时不得给第三、第四版
• Always 在使用建议中给出选版推荐与理由
• Never 改变原文事实：数字、日期、金额、责任归属一律保持原值
• Never 新增原文没有的承诺、结论或数据；确需补充的信息只能以「建议补充 XX」的形式出现在使用建议中
• Never 默认解释本技能的内部步骤；用户明确问做法时，用一句话说明即可
• 语言与术语：输出语言与用户输入语言一致；专有名词、部门名、产品名、称呼保留原样
• 自由度：结构层低（三段式与两版结构固定，不得增删板块或调整顺序）；表达层中（用词与语气按对象和场景判断，允许变通）
• 工具与调用边界：
• 本技能不需要联网，不调用任何外部工具或 MCP，不主动读写用户文件
• 仅在用户明确要求「保存 / 导出」时才写文件；写入前先把完整内容展示给用户确认
• scripts/check_output.py 为可选确定性校验，只在步骤 6 且环境可执行 Python 3 时运行；运行失败或不可用 → 回退人工核对，不换用其他工具、不阻断交付
• 禁止的代做动作：不代为发送邮件或消息、不代为提交审批或工单——只产出文案，发送动作由用户完成
• 确认点：写文件、或用户要求「直接发送」时，先说明边界并请用户确认

Examples（示例）

• 「TS 领导，那个项目可能有点问题，我们进度好像落后了，大概延迟一两周吧」→ 五维表（对象：上级）+ 版本1（保留口语：「领导，跟您同步一下项目进展：目前进度有所延迟，预计延后 1-2 周…」）+ 版本2（结论先行：【当前状况】【延迟原因】【需要支持】，诉求附资源方案）+ 使用建议（紧急口头同步用版本1，周会或书面汇报用版本2）
• 「帮我把这条消息润色一下发给客户，说我们下周才能交付」→ 五维表（对象：客户，场景：交付延期告知）+ 版本2 用「致歉 + 原因 + 新时间 + 后续保障」写法 + 使用建议提示补充具体日期与补救措施
• 「帮我优化一下：这方案我不同意，请再议。」→ 短输入照常处理；版本1 保留原立场，版本2 补上请示语气与「建议补充不同意理由」提示，不新增原文没有的理由
• 完整输入到输出对照见 examples/ 下三篇正例文件（何时读哪一篇见 References）

Edge Cases（边界与失败处理）

输入类边界

• 多段或多份内容：逐段分别给出各自的两版，并在使用建议里说明段落间的先后关系；用户明确要求合并成一条时，再按合并处理
• 超长文本（超过 1000 字）：先按信息块切分，逐块给出两版，最后给一段整体使用建议，不逐句改写
• 输入只有对象没有内容（如「帮我给张总写句话」）：先追问要表达的核心信息与目的，不代拟内容

对象与场景类边界

• 文本含职场要素但场景不明：基于文本特征推测，并在成果中说明推测依据、请用户确认
• 确认与职场沟通无关（纯文学、日常闲聊、代码、合同条款）：不改写，回复固定话术「这段内容不属于职场沟通场景，本技能不处理；如需职场表达优化，请提供工作场景中的原文。」
• 对象不明确：保持两版结构（一律按「通用职场对象」措辞），并在使用建议中列出若对象为上级需替换的 2-3 处措辞（称呼、请示语气、结论前置）；不另生成「对上级版/通用版」
• 跨文化场景（外企、海外客户）：在版本2 中增加跨文化注意事项（直接/间接表达偏好、层级观念差异），直接复用步骤 2 已读取的 references/communication-scenarios.md 第四节
• 原文已很完善：如实说明「原文表达已经比较清晰，我提供少量微调建议」，只输出微调版本

On Failure（失败路径）

• 输入校验失败（空 / 无职场要素）：输出提示话术并停止，不猜测用户意图、不强行改写
• 五维分析无法判定对象或场景：追问一次；用户未回应则按「通用职场对象」输出，并显式标注该假设
• 4 条阻塞项未通过：回退对应步骤重做；重做 2 次仍不通过 → 交付当前最好版本并列出未达标项，不隐瞒、不假装通过
• 自检脚本运行失败（环境无 Python / 文件不可读）：记录失败原因，回退人工核对，不改用其他工具、不跳过自检

故障排除

Gotchas（本技能特有的坑）

• 「原文风格版」不等于「错别字修正版」：必须保留用户的称呼、口语习惯与句式节奏，否则用户会觉得「这不是我说的话」
• 正式版最容易犯的错是凭空补承诺（原文没提工期却写「预计两周内交付」）——补信息只能以「建议补充」形式出现
• 对上级场景「只抛问题不给方案」是最常见的失分点：问题类输入必须在诉求段附解决方案或选项
• 短消息往往是真实工作消息，不要以「内容太少」为由拒答
• 正式度判定有一层容易漏的规则：跨部门比部门内更正式一级，对上级比平级更正式一级

References（参考资料）