write-tweet v0.2.0A

Immutable. This exact content is served forever at /api/v1/blob/c24fa30562c5149e.

---
name: write-tweet
description: 写简体中文 X 推文，参数 short / long 指定长短。用于“顺一下我写的这段”“帮我压成一条”“把这篇整理成推文”“写条推文”。
license: MIT
disable-model-invocation: true
metadata:
  author: simonwong
  version: "0.2.0"
---

# X 推文写作

一条推文围绕一个主要分享点展开：一个判断、一个结果、一件作品、一个观察或一个疑问都可以；几个关联的观察可以放在一条里，无关的内容分开。参考各管一层：[个人风格](references/voice.md) 管句子和说话位置，[结构骨架](references/formats.md) 管段落顺序，[开头](references/hooks.md) 管入口。参考里的方法用于启发，不适用时跳过，以这条推文为准；示例只演示写法，事实来自当前材料。

## 基本约定

- 事实、数字、原话和第一人称经历只来自材料：用户给的，和为核对查到的原始来源。拿不准的事实先查，产品功能、版本和数字查官方或原始来源；查不到的先在正文里限定，限定不了的问用户，删去对应说法是最后手段。
- 他人的测试结果、解释和判断保留范围与归属，与已核实的事实分开；在会被误认为作者亲测、普遍事实或作者立场的地方交代，其余地方直接写内容。链接放在哪里不改变这条。句式见 [个人风格](references/voice.md)「转述别人的内容」。
- 作者的参与体现在关注什么、选了哪些材料、怎样说、认可哪些判断。有经历写经历，没有经历按材料写转述、观察、判断、疑问或感受。
- 转述型：主要内容来自别人的文章、演讲或推文。

## 工作流

理解本次要求 → 看已有内容 → 写一稿 → 自查并交付。几十字的推文四步一口气做完；分歧和待确认项写进备注。

### 1. 理解本次要求

先按用户本次要求定处理方式，再看材料够不够：

- 只改错字、顺句：保留用户的句子、用词和段落顺序，下文称「严格顺稿」。
- 压缩、扩写、重组或重写：保留原意、用户的用词和指定的内容，只做要求的操作。
- 从关键词、方向、链接或别人的文章成文：整理后成文。

用户没说修改范围时，用户自己写的文字默认严格顺稿，哪怕零散、不成句或只有一行疑问；只有关键词、方向、链接或别人的文章时默认成文。链接是资料，不改变修改范围。

`short` / `long` 控制篇幅：`short` 压缩，`long` 展开；中文说的短推、长推与传参同义。严格顺稿带了篇幅参数时，按参数压缩或扩写，其余仍按严格顺稿的规则。未指定时按内容定：一个判断加一个依据是短推，约 140 字为参考；步骤、多条经验、原文的几个要点或有前后过程是长推。压缩时保留不可缺少的条件和数字；扩写先把已有材料之间的关系讲清楚，内容确实不够展开就说明原因。

完成标准：处理方式、篇幅和用户指定保留的内容已明确。

### 2. 看已有内容

严格顺稿只做一件事：用户附了链接时取来核对拿不准的事实，取不到就标注未核对，继续。

其他处理方式：找出这条最想分享的是什么，列出支撑它的材料，每件注明来路：用户亲历、原文所说、已核实的结果、推断。看文字是不是这次表达的全部：配图、视频或被引用的推文已经交代的内容，正文不重复；读者要结合它们才知道在说什么时，正文给足指代；一句话配一张图已经成立时直接写。

用户给的是链接时先取全文，取不到就请用户贴正文。材料不足以成文时，问本条缺的那一样：一件具体的事、作品的来由、原文的要点或一个疑问都可以。用户让直接写时按现有材料写。

完成标准：严格顺稿已核对或已标注；其他处理方式分享点一句话说得出，每件材料有来路，缺口已问或已按现有材料收窄。

### 3. 写一稿

严格顺稿做四件事：改错别字、语病和写错的成语（如「兴致冲冲」）；零散处补主语、连词和指代，补的部分只含用户已写的事实和判断；核对出入的事实按基本约定处理，每处进改动说明并带一句原因；按「排版」一节排版。

压缩、扩写、重组：在用户的句子上做要求的操作，用词和说法保持作者自己的；重组时读 [结构骨架](references/formats.md) 挑顺序，入口从用户已有的句子里选。

成文：段落顺序读 [结构骨架](references/formats.md) 挑候选，没有合适的按材料自然顺序写；句子按 [个人风格](references/voice.md) 写；正文成形后读 [开头](references/hooks.md) 定入口。长推围绕主线连贯展开，段落可以承担背景、解释、例子或转折；结尾按骨架的结尾项，有作者自己的内容才写。

完成标准：一稿完成，处理方式和篇幅与第 1 步一致。

### 4. 自查并交付

在当前上下文按顺序查，不适用的跳过：

- 原意与授权：用户指定保留的内容都在；严格顺稿时未列入改动说明的句子与原稿逐字相同。
- 事实与归属：每句在材料范围内；判断强度、数字的条件和归属与材料一致。
- 阅读：顺着一个意思读下来；哪里铺垫多余，哪里跳得太快、少了关键指代；开头兑现，收尾自然。
- 发布：结合配图、视频或引用内容，读者知道在说什么；篇幅与所选形式相称；按「排版」一节。

AI 味检查：调用 `/writing-ai-check` 只做诊断。短推和一般改写在当前上下文调用；长推、较大改写或用户要求时交给新开的子代理。子代理不共享上下文，交接这些：推文全文按纯文本传、用户材料、指定保留的内容、本次的发布方式（引用转发、首条回复或链接在正文）；说明这是 X 推文，换行和分段是平台排版，正文里的归属语指向该发布方式带出的来源，反应词和口语不论来自材料还是用户要求都是作者本人的表达；让它调用 `/writing-ai-check` 只做诊断，回报报告。严格顺稿在用户要求时才做这项检查。收到诊断后改法由你定，改完对照原意回查第一行的具体信息、判断强度和限定条件。环境不支持子代理时在当前上下文调用；该 skill 不可用时完成推文，交付里写明「AI 味专项检查未执行」。

交付：推文正文放在代码块里，保留换行和空行。待确认的事实已在正文里限定的，交付为可直接发的稿；严格顺稿下原句照留、没能限定的，交付为带待确认项的稿，备注列出它们和缺的材料。有原稿时给改动说明：严格顺稿一处一行，只写改动的词或短语，补的衔接写「补：第二句主语」，事实改动带来源，其余原因只在不看原句就猜不出时加一句；压缩、重组时写删了什么、改了什么顺序。转述型另给发布安排：用户给了原推链接就引用转发；没给时交付首条回复的文案，注明可换成引用转发；多个来源时首条回复列全部链接；用户要求链接放正文时照放。

```
改：兴致冲冲 → 兴冲冲；一下步 → 下一步；31% → 32%（链接原文）
补：第三句冒号引出原话
```

完成标准：正文可直接复制；待确认项、改动说明和发布安排在正文之外。

## 排版

交付可复制的纯文本，不依赖 Markdown 渲染；列表用「1.」或换行。换行帮助阅读：一段说一层意思，意思切换时空一行。话题标签、Emoji、线程序号（1/、2/）和 🧵 只保留用户材料里已有的。