微信友好模式（WeChat-Friendly）

把一段啰嗦、堆在一起的文字，整理成能直接在微信里发出去的样子。主要场景：给老板/同事汇报、在工作群同步进展或确认事项。

核心目标只有一个：让对方在手机上 3 秒内扫到重点。 微信是窄屏、快节奏的聊天场景，一大坨密密麻麻的文字会被手指直接划过去。你要做的是用换行和中文标点把信息切开、把重点顶出来，再把废话拧干——但不编造、不失真，也不改变说话人的语气。风格是「有事直说」的对话感，不是公文通告。

两条硬约束：不用 Markdown、不用 emoji

这是这个 skill 存在的根本前提。

• 微信聊天框是纯文本，不渲染 Markdown。 **加粗**、# 标题、- 列表、> 引用 统统失效，只会原样显示出 ** # - 这些符号，反而更乱。所以绝不输出任何 Markdown 语法——所有排版只能靠换行和中文标点。
• 不加 emoji、不加颜文字。 工作汇报场景里 emoji 显得不正式。

排版：靠换行 +「」+【】三档轻重

把信息切开、把重点顶出来，就靠下面这套由轻到重的工具。关键词是克制——工具用过头，本身就变成新的噪音。

换行与空行（最主要的手段）

• 一个要点一行，别让两件事挤在一行。
• 逻辑块之间空一行（比如"进展"和"风险"之间），给眼睛一个停顿。
• 单行别太长——手机上一行大约 15–20 个汉字就折行，所以在语义自然的地方断开，别拦腰截断一个完整意思。

「」直角引号——句内点关键词

框住值得让目光落上去的关键名词：项目名、模块、交付物、关键条件、专有名词。例：正在做「数据上报」/ 需在「2.4e 商品传入前」完成。它比【】轻得多，是日常点重点的主力。

【】方头括号——聚光灯，最关键也最需要克制

把【】当成整条消息里唯一的一束聚光灯：打在"要害"上——就是对方哪怕只扫到这一处，也必须让他看见的那一小段。

• 尺度：默认一个都不打。 真有那么一处不能被错过的落点，才打一个；只有很长的多段消息，才允许最多两个。
• 判断方法（不靠清单，靠这一问）："如果对方只扫到一处，必须是哪处？" 只有那一处确实是这条消息的要害时，才给它打上【】。
• 不要预设"哪些类型该打"的清单。 截止时间、数字、结论……都可能是要害，也都可能不是，全看这条消息在说什么。列清单只会诱导你逢时间就打、逢数字就打，反而打滥。
• 拿不准就不打。 【】的全部威力来自稀缺：它是最重的符号，一条消息里出现三个，三个就都不亮了；而且括号一多，就从"对话"变成"填表格"，恰好毁掉"有事直说"的口语感。所以干净的零括号版，几乎总比满屏括号好。

（反面例子见下方"容易踩的坑"，直观感受一下打滥是什么样。）

其他中文标点

• 序号：并列或有先后的要点用 1. 2. 3.。一律用阿拉伯数字，不用中文的「一、二、三」。 也不要用 Markdown 的 - / *。
• 冒号「：」：标签后接内容，如"风险：测试环境异常"。
• 顿号「、」：同类短项在一行内并列，避免硬拆成好几行，如"已询 A、B、C 三家"。
• ""全角引号：引用原话或带点语气的强调，频率比「」更低。
• 《》书名号：文档/报告/方案/产品等"作品、文件"的标题，如《Q2 复盘》。

两种力度：标准版（默认）与精简版

先看用户的话里有没有"精简"的信号——"精简一点 / 简洁版 / 再短点 / 压一压 / 太长了再缩缩"之类。有就用精简版，没有就用标准版（默认）。

标准版（默认）：基本不动原来的句子，只做断行、加中文标点、点出重点，顺手删掉明显的口水（"其实""然后就是""这一块""……的话"）。改动幅度小，读起来还是本人说话的样子。

精简版：结构和标准版完全一样——标准版分几点，精简版还是几点，换行也照旧——只是每一句再拧干一道，砍掉啰嗦的连接词和铺垫。例如"所以你们评测时可能会发现"→"评测时会发现"。

精简版有个重要前提：它不是把内容浓缩成一小段，也不保证一定短很多。如果原文本来就紧、每句没什么水分，精简版和标准版会几乎一样——这是对的，没水分就别硬挤。

拧干，但不失真

能砍：客套铺垫、口水词、口头禅、重复表述、可有可无的修饰、把话说圆的赘语。

要留：事实、数字、人名 / 项目名、时间节点、结论、待办、卡点，以及对方需要回应的"问题 / 请求"（"您看呢""麻烦…沟通下"这类——这是消息的目的，删了就白发了）。

两条底线：
- 不编造、不脑补。 原文没说的进度、结论、数字，绝不替对方补上；拿不准的信息宁可原样保留，也不要"优化"成更漂亮但失真的说法。（顺手修明显的笔误是可以的，比如重复的"是否…是否"。）
- 保持原文语气。 原文随和就别改得一本正经，原文严谨就别改得轻佻。也别自作主张添加称呼、问候、落款或 emoji——原文有才保留。

贴着内容搭结构

让结构服从内容，别硬套模板。

• 有并列要点 → 用序号 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.，不要"一、二、"。
• 强行分行到支离破碎。 不是字越少的行越好，在语义边界断行。
• 改写过头丢了信息或语气。 "精简"是拧干水分，不是重写；砍废话可以，砍事实和语气不行。
• 加了原文没有的东西。 不脑补进度、不编数字、不自作主张加问候 / 落款 / emoji。
• 输出了 Markdown。 再说一遍：微信不渲染，** # - 只会变成碍眼的符号。