no-slop

摆脱冗余表达

语体

目标语气：一位以 C2 水平书写英语的德国专业人士。准确、直接、结构清晰。克制，不热情洋溢。这是一种语体，不是口音，因此不要出现德国式表达、易混淆词或语法错误。英语接近母语水平，只是不采用美国式的活泼默认风格。

大多数 AI 冗文并非错误，而是写得过多、组织过度。语气太热情、过分平衡、铺垫太多、急于总结自己。删去这些，文本就会更短、更好。目标是写出读起来像是由一位能干的人认真写成的文章。

从整体到细节

冗文存在于各个层面，从目录到单个词都不例外。在本身就冗余的结构里润色句子，是白费功夫，因此要按顺序逐轮处理。每一轮都会删去后续轮次原本需要润色的文字。

1. 重新审视文档。 调整顺序、合并、拆分、删除并替换整个章节。具体做法见下表，示例见 structure.md。
2. 重写段落。 每段只讲一个主题，先陈述要点，将步骤移出正文。
3. 按照 STE 构建规则 写好句子。
4. 消除词语层面的痕迹，包括采用的 Microsoft 规范。
5. 使用 linter 检查，然后进行仅由人工完成的审读。

对于超过几段的草稿，只改措辞就意味着跳过了最重要的一轮。要进行结构调整，或者说明结构为何合理。撰写新内容时，也应按同样顺序提出问题：读者需要什么、按什么顺序，然后规划段落，最后写句子。在代码中写内容（注释、提交消息、测试名称、错误字符串）时，也要采用相同语体，并查看 Beyond prose 中对应的文件。

两条常规规则。要与周围内容保持一致（代码仓库的历史、文档既有的语气、规定的模板）；这些规则用于提升写作，而不是覆盖用户遵循的既定风格。重组他人的草稿时，要报告所做的调整（“将 X 合并到 Y，删除 Z”），绝不要悄悄修改。

第 1 轮，重组文档

发现的问题	调整方式
引言预告内容、结论重复总结、某一章节复述另一章节	删除，或将其中唯一有用的一句话合并到正文
自动生成的框架（概述、功能、结论；两行 PR 中的摘要、变更、测试）	替换为文档真正需要的章节，通常无需任何章节
要点埋在背景信息中	调整顺序，开篇直述读者关心的内容
两个章节讲的是同一主题	合并
一个章节承担两项任务	拆分
应该讲清推理过程，却堆满了项目符号	改写为正文
某个步骤埋在描述性段落中	提取为编号列表，每项只写一个操作
每两句话就有一个标题	合并到更少的标题下
文档长度是内容的两倍	精简；篇幅减半是常见结果

第 2 轮，重写段落

每段只讲一个主题，最多六句话，首句点明要点。只有当各项确实并列且相互独立（步骤、选项、标准）时，才使用列表；若观点彼此相关或需要上下文，就写成段落。实际操作顺序是唯一必须使用列表的情况：使用编号，采用祈使句，每项只写一个操作。

第 3 轮，把句子写好

该系统是 ASD-STE100 简明技术英语，由航空航天行业于 1986 年制定，用于编写必须让非母语读者也能读懂的维护手册。它确实有效：仅提供禁用词列表时，Claude 将测得的冗余降低了 3%；使用该系统时，降低了 74%。完整规则、模式和证据见 ste.md。

规则	这样写	不要这样写
同一事物只用一个名称	缓存，之后仍称缓存	缓存，之后又称存储，再之后又称层
每个词只表达一种含义	“fall”表示向下移动	用“traffic fell”表示减少
使用简短常见的词	use、start、help、make sure、before、after、about、get、show、also	utilize、commence、facilitate、ensure、prior to、subsequent to、regarding、obtain、demonstrate、additionally
使用主动语态，并指出动作执行者	解析器读取文件	文件被读取
一个动作只用一个动词	分析日志	对日志进行分析
不要堆叠助动词	这会提高吞吐量	这可能有助于提高吞吐量
优先使用一般时态，而非进行时	作业写入索引	作业正在写入索引
使用普通动词，而非短语动词	start、contact、read、deploy	spin up、reach out、dive into、roll out
每句话只表达一个意思，并限制长度	指令不超过 20 个词，描述不超过 25 个词	由 40 个词组成的并列长句
不使用分号	写成两个句子	用分号连接一个句子
先说明条件，再给出命令	如果缓存是冷的，先预热	如果缓存是冷的，先预热缓存

第 4 轮，识别特征（发现即删）

特征	修改方式
用破折号制造戏剧效果或插入旁白	改用句号、逗号、冒号或括号
“不是 X，而是 Y”／“不只是 X，还是 Y”	直接陈述 Y
没有实际作用的三项并列（“快速、整洁且可靠”）	只保留最重要的一项
兜圈子的开场白（“在当今世界”“说到……”）	删除，开门见山
重述正文的总结（“总之”“归根结底”）	删除，或以最后一个有实质内容的观点收尾
填充式过渡语（“此外”“而且”“值得注意的是”）	删除，让下一句独立成句
生硬的枚举（“以下是三个原因”），或为凑整数而填充列表	用散文陈述要点，只保留实际内容
下意识的模糊措辞（“需要注意的是”“可以说”“可能有潜在的……”）	删除，或给出具体且有依据的限定
肯定或奉承（“问得好”“你完全正确”）	直接回答问题
空洞词汇（深入探讨、利用、驾驭、领域、格局、织锦、错综复杂、强大、无缝、至关重要、至关重要、促进、发挥）	换成朴实的词语
有更具体称呼时仍使用类别名词（“相关组件”）	直接说出具体名称（“身份验证中间件”）
给无序集合编号	改用项目符号，因为编号意味着顺序或等级
虚指开场白（“有三个选项”）	先说主题（“存在三个选项”）
以读者为主语的陈述（“你可以在线存储文件”）	以动词开头（“在线存储文件”）
空洞的“你可以”（“你可以在配置中设置重试次数”）	删除（“在配置中设置重试次数”）
没有信息量的链接文本（“点击此处”），或只有方向的指引（“上文”“左侧”）	描述链接目标，直接说出名称
夸大重要性（“堪称……的见证”“标志着一个关键时刻”）	陈述事实，删去重要性判断
浮夸的系词（适合用“是”或“有”时却用“拥有”“充当”“具有”）	改回朴实的动词
模糊的权威说法（“研究表明”“专家一致认为”）	指明来源，或删除该说法
句尾的分词链（“……，进一步巩固了其地位”）	在陈述事实后结束句子
虚假的包容性表述（“无论你是新手还是专家”）	明确说明实际面向的对象
聊天机器人式套话（“让我们深入了解”“正如你所见”“祝你编码愉快！”）	删除，从内容本身开始和结束
以否定营造炒作（“告别 X”“Y 的时代一去不复返”）	直接说明事物的作用

动词开头和空洞的“你可以”这两条，以及虚指开场白，都来自 Microsoft 写作风格指南。这些规范适用于所有模式，并非本指南额外添加的风格要求；包含逗号规则和标题规则的完整规范见 microsoft-style.md 和 formatting.md。

删去模糊措辞时，要用事实替代，而不是换成语气更弱的形容词；加上限定语只是把同样的空话说得更轻。不要把列出的词换成更拗口的说法，应该重写整个句子。

模式

严格模式适用于操作流程、运行手册、安装和迁移步骤、错误与日志消息，以及弃用通知。遵循所有 STE 规则，句子不超过 20 个单词，展开缩略形式。风格化模式是其他场景的默认模式：保留句子、动词和段落方面的规范，每句不超过 25 个单词，保留缩略形式和语体。既定风格模式适用于目标文本已有既定风格的情况，通常是 Microsoft 指南。既定风格优先决定是否使用缩略形式、破折号和亲切语气；其他所有特征和以上各轮规范仍然有效。选择模式要看目标文本，不要因为文本属于技术内容就选用。

第 5 遍，检查草稿

对照以上各遍通读一遍。然后运行 lint（在此 SKILL.md 旁边找到 slop-lint.mjs）：

node slop-lint.mjs README.md              # a file, flavored mode
node slop-lint.mjs --strict runbook.md    # procedures, 20-word cap
echo "$draft" | node slop-lint.mjs        # prose not yet written to a file

编辑前后都运行 lint，并报告变化。分数表示每 100 个单词中的违规数，只有与同一文本的另一个版本比较时才有意义；少于约 50 个单词时，这个分数只是噪声。单行文本可跳过；如果无法使用 node，也可跳过。lint 工具只检查单词和句子。结构（第 1 遍）以及两条命名规则（一件事只用一个名称，一个词只表达一种含义）仍需人工检查。

不止于正文

无论写什么，都适用这些文风要求和检查步骤。针对不同内容的注意事项和改写示例：

• 格式（标题、粗体、列表、表情符号、徽章、智能引号）：formatting.md。
• 叙述差异的代码注释：code-comments.md。comment-stinky 是深入检查版本；只有任务涉及注释本身时才使用。
• 复述差异而非说明原因的提交消息和 PR 描述：commits-and-prs.md。
• 代码中的字符串（测试名称、错误消息和日志消息）：code-strings.md。
• 妨碍辅助技术使用或排斥读者的正文：inclusive-and-accessible.md。这两种问题都不属于文风问题，而是缺陷。
• 针对每种问题的句子级改写前后对照：prose.md。

不要矫枉过正

这些规则旨在去掉缺乏依据的热情和结构，而不是要求冷漠或不成章法。

• 承载重要内容的结构要保留。 API 参考文档可以有许多标题，规范可以有编号章节，强制要求的 PR 模板也可以保留其框架。要精简臃肿的部分，不要破坏约定。
• 句子过短，像机器人。 变换句子长度；连续出现五个词的短句，本身就是一种问题。
• 为了避开列出的词而换用更糟的词。 如果你想表达“强”，用“强”没问题。规则针对的是不加思考地使用“稳健”，而不是其背后的意思。
• 删掉发挥实际作用的衔接句。 去掉赘词，保留读者理解逻辑所需的衔接。
• 禁止任何对比。 有时真实的对比确实需要用“但是”。规则针对的是夸张的表达节奏，而不是这个词。
• 在不适用的场合严格遵循 STE。 在操作流程之外，这会显得生硬，而非精准。默认采用有个人风格的表达。
• 一味追求分数。 零违规也可能毫无内容。这些规则只修正文风问题的形式，不改变内容本身。

拿不准时，就大声读出来。如果听起来像一个人在解释自己理解的事情，就保留。如果听起来像宣传文案，就改掉。