纸媒长文 → 新媒体推文
这个 skill 解决什么问题
企业内刊、季刊、年报里的稿件，是按"记录"的逻辑写的：交代背景、罗列成果、职务全称、层层铺垫。放到公众号里，读者三屏之内就划走了。
改编的目标不是"删短一点"，而是换一套阅读契约——纸媒读者是被要求读完的，公众号读者是随时可以走的。所以每一段都要挣得下一段的注意力。
唯一的验收标准：如果一篇文章能让不在这个业务领域的同事也愿意一口气读完，它就是一篇合格的新媒体稿件。改稿过程中每做一个取舍，都回到这句话上判断。
核心原则：留事实，砍连接组织
这是压缩时最重要的直觉，也最容易搞反。
内刊长文的价值几乎全在具体的东西上：人名、项目代号、数字、案例细节、原话引语。臃肿的部分几乎全在抽象的东西上：过渡句、预告句、重述句、"意义在于……"式的评论。
所以压缩 30% 通常不需要牺牲任何一个案例——把下面这几类整段删掉，字数自然就下来了：
| 该砍的 | 长什么样 | 为什么 |
|---|---|---|
| 预告句/预告段 | "他常用自己总结的一套 L1 到 L5 框架来判断……" | 直接讲框架就行，宣告"接下来要讲X"是纸媒的礼貌，线上是浪费 |
| 过渡桥句 | "这个判断，直接影响了公司整体战略。" | 小标题已经在做转场，不需要文字再转一次 |
| 抽象归因段 | "这背后有几股力量同时推进：认知在提升、投入在加大……" | 没有具体细节的因果分析，读者记不住也不会转发 |
| 收尾总结段 | "真正重要的，是把看得见的场景一件件做深……" | 重述全文，读到这儿的人不需要被总结 |
| 职务全称的重复 | 第二次出现还写"TCL科技数字化转型部总经理李冰博士" | 首次出现给足，之后只留姓名 |
不能砍的：任何人名、项目名/代号、具体数字、直接引语。这在企业传播里不只是内容问题，是政治问题——把某个团队的项目删掉，是会出事的。宁可在别处多压一点。
同样不能加的：原稿里没有的事实。改编时手会痒——想给"0.005毫米"加一句"大约是头发丝的十四分之一"，想把散落的数字汇总成一张"数字里的某某"卡片。前者是你自己查来的、编辑部没法核实的外部数据，后者会让读者以为原文有这个统计。企业稿件是要署名发出去的，任何一个没经过核实的数字都是风险。术语可以解释（用原稿已有的信息解释），事实不能补。要是实在觉得某处需要一个参照物才讲得清，把这个建议单独告诉用户，让他去找编辑部确认，别自己写进去。
工作流程
1. 读原稿，摸底
pandoc -t markdown 原稿.docx # 读正文
pandoc -t plain 原稿.docx | tr -d '[:space:]' | wc -m # 中文字数
unzip -l 原稿.docx | grep media # 有没有配图
配图要保留并放到开头钩子之后——公众号读者看到图才愿意往下滑。
读的时候在心里标记三样东西：最有冲击力的一个细节（往往埋在第三、四段）、所有必须保留的具体事实、能当小标题的短句。
2. 定钩子和标题
先找钩子，再写标题——标题往往就是钩子的浓缩。
翻遍全文，找那个"讲给朋友听会先说这句"的东西：一个反常的数字、一次冲突、一句有态度的原话、一个具体场景。它在原稿里通常被埋在铺垫之后，把它提到第一句。
标题不要"关于……""……工作纪实""……进行时"这类写法。可以用冲突、数字、悬念、人物。详细的正反例和几种可靠的标题句式见 references/hooks-and-headlines.md——写标题前读一下，那里有比这里更细的东西。
3. 重搭结构，写小标题
原稿的小标题一般是主题词（"一场紧紧咬合的竞速""进度不均，但都在加速"），抽象、对仗、不勾人。换成短、准、醒目的：能提到具体名字就提具体名字，能设悬念就设悬念。
- 抽象 → 具体：
一场紧紧咬合的AI竞速→中国企业，还是慢半年 - 汇报 → 现场：
AI在公司：进度不均→华星的"大本营"、中环的"蓝鲸" - 陈述 → 悬念：
组织形态的未来演变→"人给AI打工"，是不是有可能
小标题控制在 12 字以内，3-5 个为宜。每个小标题下的内容应该能独立成一个小故事。
4. 逐段改写
结构定了之后，一段一段过。几个具体的手法：
拆长段。 手机上一屏很窄，200 字的段落是一堵墙。控制在 2-4 句、80-150 字，一段只讲一件事。
换动词。 公文动词换成人话动词：推进/开展 → 在做/在推、实现效率提升 → 快了 / 省了多少时间、赋能/抓手/闭环 → 直接删掉重写。
加节奏。 破折号和冒号能救很多平铺直叙的句子。"参数一致后，含氧率下降，A品率上升"比"通过提升参数一致性，实现了含氧率的下降和A品率的提升"好读得多——因为前者是三个短句，后者是一个名词堆。
引语单独成段。 有态度的原话不要塞在段落中间，拎出来单独一段，读者会停下来看。
术语随手解释。 "L4 级应用""数字孪生""含氧率"这类词，第一次出现时用半句话说清楚。判断标准还是那句：不在这个领域的同事读不读得懂。
5. 收尾
不要用总结段收尾。落在最强的那句引语上，或者一个具体的画面上。读者读完最后一句应该还有余味，而不是被告知"综上所述"。
6. 输出
默认输出 .docx（编辑部要的格式）。用 skill 自带的脚本，不要每次现写：
node <skill目录>/scripts/build_article_docx.js content.json 输出.docx
content.json 的格式和用法见脚本开头的注释，或直接看 references/output-format.md。脚本处理了标题层级、行距、配图嵌入和 A4/Letter 页面设置——这些每次都一样，没必要重复解决。
如果用户想要 Markdown 或者 HTML 预览版，也可以出，但没特别说的时候出 .docx。
渲染出来看一眼再交付：
soffice --headless --convert-to pdf 输出.docx && pdftoppm -jpeg -r 90 输出.pdf page
然后 Read 生成的图片。中文字体、图片位置、标题换行这些问题，肉眼一看就知道，比检查 XML 快。
7. 自检
交付前对照过一遍：
- [ ] 第一句就是钩子，没有背景铺垫
- [ ] 字数比原稿少了 30% 左右（除非用户另有要求）
- [ ] 原稿里的人名、项目名、数字、引语一个没丢
- [ ] 没有任何原稿之外的新事实、新数字、新对比
- [ ] 小标题短、具体、不对仗
- [ ] 没有一段是纯过渡或纯总结
- [ ] 配图保留了
- [ ] 一个外行读得下去
最后交付时，简单说明改了哪几处、字数从多少压到多少，让用户能快速判断。不用逐段解释——文件他自己会看。
压缩强度
默认压 30% 左右：砍连接组织，全部案例和引语保留。这是最安全的档位，绝大多数内刊稿件适用。
用户要求"再狠一点"（50%+）时，才开始做取舍：合并同类案例、只留最有代表性的一两个引语、砍掉次要人物。这时候要主动告诉用户砍掉了什么，因为可能涉及内部关系。
原稿本身就很紧凑（比如 1500 字以内）时，不要硬压——告诉用户结构和标题改了但字数变化不大，比交一篇被削瘦的稿子好。
参考文件
references/hooks-and-headlines.md— 标题写法、开头钩子的正反例，写标题前读references/output-format.md— content.json 的结构和排版约定scripts/build_article_docx.js— 生成 .docx 的脚本
