把一段啰嗦、堆在一起的文字，整理成能直接在微信里发出去的样子。主要场景：给老板/同事汇报、在工作群同步进展或确认事项。
核心目标只有一个：让对方在手机上 3 秒内扫到重点。 微信是窄屏、快节奏的聊天场景，一大坨密密麻麻的文字会被手指直接划过去。你要做的是用换行和中文标点把信息切开、把重点顶出来，再把废话拧干——但不编造、不失真，也不改变说话人的语气。风格是「有事直说」的对话感，不是公文通告。
这是这个 skill 存在的根本前提。
加粗、# 标题、- 列表、> 引用 统统失效，只会原样显示出 # - 这些符号，反而更乱。所以绝不输出任何 Markdown 语法**——所有排版只能靠换行和中文标点。把信息切开、把重点顶出来，就靠下面这套由轻到重的工具。关键词是克制——工具用过头，本身就变成新的噪音。
| 工具 | 作用 | 频率 |
|---|---|---|
| ------ | ------ | ------ |
| 换行 / 空行 | 把不同的事切开 | 随结构，自由用 |
「」 | 让眼睛有落点的关键词 | 适量，可多次 |
【】 | 聚光灯，打在唯一的要害上 | 极少：默认 0，最多 1，长消息最多 2 |
框住值得让目光落上去的关键名词：项目名、模块、交付物、关键条件、专有名词。例：正在做「数据上报」/ 需在「2.4e 商品传入前」完成。它比【】轻得多，是日常点重点的主力。
把【】当成整条消息里唯一的一束聚光灯：打在"要害"上——就是对方哪怕只扫到这一处，也必须让他看见的那一小段。
（反面例子见下方"容易踩的坑"，直观感受一下打滥是什么样。）
1. 2. 3.。一律用阿拉伯数字，不用中文的「一、二、三」。 也不要用 Markdown 的 - / *。先看用户的话里有没有"精简"的信号——"精简一点 / 简洁版 / 再短点 / 压一压 / 太长了再缩缩"之类。有就用精简版，没有就用标准版（默认）。
标准版（默认）：基本不动原来的句子，只做断行、加中文标点、点出重点，顺手删掉明显的口水（"其实""然后就是""这一块""……的话"）。改动幅度小，读起来还是本人说话的样子。
精简版：结构和标准版完全一样——标准版分几点，精简版还是几点，换行也照旧——只是每一句再拧干一道，砍掉啰嗦的连接词和铺垫。例如"所以你们评测时可能会发现"→"评测时会发现"。
精简版有个重要前提：它不是把内容浓缩成一小段，也不保证一定短很多。如果原文本来就紧、每句没什么水分，精简版和标准版会几乎一样——这是对的，没水分就别硬挤。
能砍：客套铺垫、口水词、口头禅、重复表述、可有可无的修饰、把话说圆的赘语。
要留：事实、数字、人名 / 项目名、时间节点、结论、待办、卡点，以及对方需要回应的"问题 / 请求"（"您看呢""麻烦…沟通下"这类——这是消息的目的，删了就白发了）。
两条底线：
让结构服从内容，别硬套模板。
1. 2. 列开。判断标准始终是：对方扫一眼，能不能立刻抓到"什么事、卡在哪、要我干嘛"。
示例 1 —— 标准版（无需聚光灯，靠「」和分点就够）
输入：
> 我们可以重新跑一次数，附带原始prompt重新刷出。但是发货地现在有一些填写错误的情况，看铭箴要不要先检查修改一下？现在"浙江杭州"的请求结构是取并集逻辑，如果结构改正确的话 填充率会更低一些；还有"福安"是县级市，底表数据不存在这个发货地。这些因素会导致实际召回率低于我们跑出来的结果。
输出：
可以重新跑一次数，附带原始 prompt 重刷。
不过发货地目前有些填写错误，看铭箴要不要先检查修改下：
1.「浙江杭州」的请求结构现在是取并集逻辑，结构改对后，填充率会更低一些；
2.「福安」是县级市，底表里没有这个发货地。
这两点会导致实际召回率低于我们现在跑出来的结果。
（两个发货地问题拆成 1./2.，地名用「」点出；没有哪一句是"唯一要害"，所以不打【】。）
示例 2 —— 标准版（用一次【】聚光灯 + 多个「」）
输入：
> 想再确认下，这个2-3周的预估，是从AMS交付到【元宝侧全量上线】的时间吗？这个时间已经包含了你们开发、积累和观测数据、增益评估等环节的工作量么？因为我们开发团队还有技术方案需要在2.4e商品传入前完成开发，希望先把握下整体的节奏。同时也看看是否我们是否要管理下客户预期，之前给的预期上线时间是6月下旬。
输出：
想再确认下这个 2-3 周的预估：
1. 是指从「AMS 交付」到「元宝侧全量上线」的时间吗？
2. 是否已包含你们开发、数据积累与观测、增益评估等环节的工作量？
我们开发团队的技术方案需要在「2.4e 商品传入前」完成开发，想先把握整体节奏；也想看看是否要管理下客户预期——之前给客户的预期上线时间是【6 月下旬】。
（两个确认问题拆成 1./2.；条件、里程碑用「」；全条唯一的要害是那个对客户承诺的时间点，所以只给「6 月下旬」打一次【】。原文里的【元宝侧全量上线】属于里程碑引用，降级成「」，把【】省给真正的落点。顺手修了"是否…是否"的笔误。）
示例 3 —— 精简版（同示例 1 的结构，逐句再拧干）
输入（同示例 1，但用户说了"精简一点"）：
输出：
可以重跑一次数，带原始 prompt 重刷。
但发货地有填写错误，看铭箴要不要先检查下：
1.「浙江杭州」现在是取并集逻辑，结构改对后填充率会更低；
2.「福安」是县级市，底表里没有这个发货地。
这两点会导致实际召回率低于现在跑出来的结果。
（骨架、分点、「」、关键信息全和示例 1 一样，只是每行更紧："重新跑一次"→"重跑一次"、"目前有些填写错误"→"有填写错误"、"我们现在跑出来"→"现在跑出来"。）
示例 4 —— 短内容，轻处理（别过度排版）
输入：
> 刚跟客户那边开完会，对方对我们的方案整体上还是比较满意的，他们说下周二之前会把盖章的合同发给我们。
输出：
刚跟客户开完会，对方对方案整体满意，下周二前给我们盖章的合同。
（内容本就短，捋顺即可——不套分点、不打【】。）
```
【可重跑数】可以重新跑一次数。
【发货地问题】发货地有填写错误：
1.【浙江杭州】取并集逻辑……
2.【福安】是县级市……
【结论】实际召回率会偏低。
```
——五个【】，一个都不突出，对话感也没了。对照示例 1：那条一个【】都不用，反而更清爽。
1. 2.，不要"一、二、"。** # - 只会变成碍眼的符号。共 1 个版本